1 2018-06-28 00:54:24	0|achow101|travis seems dead, nothing is being built
  2 2018-06-28 03:03:06	0|bitcoin-git|[13bitcoin] 15achow101 opened pull request #13557: BIP 174 PSBT Serializations and RPCs (06master...06psbt) 02https://github.com/bitcoin/bitcoin/pull/13557
  3 2018-06-28 05:07:42	0|bitcoin-git|[13bitcoin] 15Empact opened pull request #13558: Drop unused GetType() from CSizeComputer (06master...06c-size-computer) 02https://github.com/bitcoin/bitcoin/pull/13558
  4 2018-06-28 06:55:59	0|bitcoin-git|[13bitcoin] 15Empact opened pull request #13560: Drop unused serialization support from CAddresss (06master...06caddress-serialization) 02https://github.com/bitcoin/bitcoin/pull/13560
  5 2018-06-28 07:07:44	0|provoostenator|I'm getting crashes during IBD of a pruned node on one of my ARM devices. It tends to happen during later prune events (e.g. 2015). I set a fairly high dbcache, but during those events dbcache is << RAM (and there's a swap).
  6 2018-06-28 07:08:13	0|provoostenator|Worse, it sometimes tells me to reindex.
  7 2018-06-28 07:09:13	0|provoostenator|Log shows no indication of why it crashed, but my SSH connection to the machine tends to die when it happens, which does suggest OOM?
  8 2018-06-28 07:11:33	0|provoostenator|Perhaps it's just crappy hardware, but given the weird behavior with pruned nodes and large dbcache in IBD I saw in #12404, might indicate some subtle bug.
  9 2018-06-28 07:11:37	0|gribble|https://github.com/bitcoin/bitcoin/issues/12404 | Prune more aggressively during IBD by Sjors · Pull Request #12404 · bitcoin/bitcoin · GitHub
 10 2018-06-28 08:21:40	0|bitcoin-git|[13bitcoin] 15Empact closed pull request #13560: WIP: Drop unused serialization support from CAddresss (06master...06caddress-serialization) 02https://github.com/bitcoin/bitcoin/pull/13560
 11 2018-06-28 09:11:54	0|bitcoin-git|[13bitcoin] 15droark opened pull request #13561: Qt: Remove unnecessary image buffer for Mac dock icon (06master...06rm_icon_buffer) 02https://github.com/bitcoin/bitcoin/pull/13561
 12 2018-06-28 09:51:46	0|jonasschnelli|Anyone willing to pre-review a BIP proposal for encrypted wallet seeds https://gist.github.com/jonasschnelli/245f35894f6ff585b3f3d33c6f208991? gmaxwell, sipa, roasbeef
 13 2018-06-28 10:23:44	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #13562: travis: Switch back to trusty for now (06master...06Mf1806-qaTravisTrusty) 02https://github.com/bitcoin/bitcoin/pull/13562
 14 2018-06-28 10:31:25	0|promag|mac build in travis uses qt5.7.1?
 15 2018-06-28 10:50:02	0|bitcoin-git|[13bitcoin] 15promag opened pull request #13563: bench: Simplify CoinSelection (06master...062018-08-bench-coinselection) 02https://github.com/bitcoin/bitcoin/pull/13563
 16 2018-06-28 10:52:16	0|promag|MarcoFalke: is that what you mean?
 17 2018-06-28 12:05:44	0|bitcoin-git|13bitcoin/06master 14fa103a5 15MarcoFalke: [qa] wallet_basic: Specify minimum required amount for listunspent
 18 2018-06-28 12:05:44	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/d96bdd78307b...2328039bfc49
 19 2018-06-28 12:05:45	0|bitcoin-git|13bitcoin/06master 142328039 15MarcoFalke: Merge #13535: [qa] wallet_basic: Specify minimum required amount for listunspent...
 20 2018-06-28 12:06:41	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #13535: [qa] wallet_basic: Specify minimum required amount for listunspent (06master...06Mf1806-qaWalletBasic) 02https://github.com/bitcoin/bitcoin/pull/13535
 21 2018-06-28 12:09:39	0|bitcoin-git|13bitcoin/06master 14ea49e06 15practicalswift: tests: Fix incorrect documentation for test case cuckoocache_hit_rate_ok
 22 2018-06-28 12:09:39	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/2328039bfc49...c93c360eec4d
 23 2018-06-28 12:09:40	0|bitcoin-git|13bitcoin/06master 14c93c360 15MarcoFalke: Merge #13551: tests: Fix incorrect documentation for test case cuckoocache_hit_rate_ok...
 24 2018-06-28 12:10:29	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #13551: tests: Fix incorrect documentation for test case cuckoocache_hit_rate_ok (06master...06truth-in-advertising) 02https://github.com/bitcoin/bitcoin/pull/13551
 25 2018-06-28 13:33:16	0|promag|qt: funny thing, connect(..., &Foo::foo) doesn't work if foo is a private slot, BUT connect(..., SLOT(foo()) works..
 26 2018-06-28 13:33:55	0|bedo|Hi all, it's only me or the testnet are generating crazy amount of block?
 27 2018-06-28 13:42:59	0|jonasschnelli|bedo: yes. Someone mining with an ASIC farm I guess
 28 2018-06-28 13:43:29	0|jonasschnelli|4-5 seconds interval between blocks. :)
 29 2018-06-28 13:45:08	0|bedo|jonasschnelli: today is hard day for develop over bitcoin
 30 2018-06-28 13:46:08	0|jonasschnelli|bedo: use regtest. :)
 31 2018-06-28 13:46:46	0|Lightblock_|Hi
 32 2018-06-28 13:46:54	0|Lightblock_|happy to be here
 33 2018-06-28 13:48:18	0|Lightblock_|sorry if silly question, could anyone please suggest a proper way to the bitcoin transaction ID given that I know the blockheight txindex and outputindex ?
 34 2018-06-28 13:50:46	0|Lightblock_|sorry, seems like I have put in the worng channel
 35 2018-06-28 13:50:57	0|Lightblock_|nevermind, asked in the #bitcoin already
 36 2018-06-28 13:51:58	0|bedo|jonasschnelli: yep, is the only way,  will see you at BOB?
 37 2018-06-28 13:52:46	0|jonasschnelli|bedo: Yes. Sure!
 38 2018-06-28 13:55:00	0|bedo|jonasschnelli: perfect ;)
 39 2018-06-28 17:36:24	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #13564: [wallet] loadwallet shouldn't create new wallets. (06master...06dont_load_nonexistent_wallet) 02https://github.com/bitcoin/bitcoin/pull/13564
 40 2018-06-28 17:46:44	0|Alexandra|Holaaa
 41 2018-06-28 18:39:15	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #13461: Wallet: correctly deprecate accounts in getbalance, re-add minconf / include-watch-only (06master...062018/06/watch_only_balance) 02https://github.com/bitcoin/bitcoin/pull/13461
 42 2018-06-28 18:42:33	0|bitcoin-git|[13bitcoin] 15Empact opened pull request #13565: Fix AreInputsStandard test to reference the proper scriptPubKey (06master...06p2sh-tests-pub-key) 02https://github.com/bitcoin/bitcoin/pull/13565
 43 2018-06-28 18:59:30	0|wumpus|#startmeeting
 44 2018-06-28 18:59:31	0|lightningbot|Meeting started Thu Jun 28 19:00:56 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 45 2018-06-28 18:59:31	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
 46 2018-06-28 18:59:46	0|achow101|hi
 47 2018-06-28 18:59:51	0|sipa|hi
 48 2018-06-28 18:59:58	0|cfields|hi
 49 2018-06-28 18:59:58	0|jonasschnelli|hi
 50 2018-06-28 19:00:16	0|wumpus|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
 51 2018-06-28 19:00:40	0|promag|hi
 52 2018-06-28 19:00:42	0|kanzure|hi.
 53 2018-06-28 19:00:46	0|instagibbs|hi
 54 2018-06-28 19:00:57	0|jnewbery|half a hi. May be a little distracted for the next ~45 minutes
 55 2018-06-28 19:01:11	0|wumpus|I've had a really crappy week so haven't been able to do much, sorry for that
 56 2018-06-28 19:01:23	0|sipa|sorry to hear that
 57 2018-06-28 19:01:32	0|wumpus|#topic high priority for review
 58 2018-06-28 19:02:16	0|sipa|Currently on the list: #13425 #12196 #13062
 59 2018-06-28 19:02:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/13425 | Moving final scriptSig construction from CombineSignatures to ProduceSignature (PSBT signer logic) by achow101 · Pull Request #13425 · bitcoin/bitcoin · GitHub
 60 2018-06-28 19:02:21	0|cfields|wumpus: :(
 61 2018-06-28 19:02:23	0|gribble|https://github.com/bitcoin/bitcoin/issues/12196 | Add scantxoutset RPC method by jonasschnelli · Pull Request #12196 · bitcoin/bitcoin · GitHub
 62 2018-06-28 19:02:26	0|gribble|https://github.com/bitcoin/bitcoin/issues/13062 | Make script interpreter independent from storage type CScript by sipa · Pull Request #13062 · bitcoin/bitcoin · GitHub
 63 2018-06-28 19:02:26	0|wumpus|only three PRs!
 64 2018-06-28 19:02:59	0|jonasschnelli|For 12196, I'm not sure if it make sense to adopt sipas output scripts descriptors in the PR itself (or later)
 65 2018-06-28 19:03:07	0|sipa|i'd like to bring up an idea i've been working on for future wallet design/ismine logic, which may interact with #12196
 66 2018-06-28 19:03:09	0|jonasschnelli|(since it already has some reviews/acks)
 67 2018-06-28 19:03:11	0|gribble|https://github.com/bitcoin/bitcoin/issues/12196 | Add scantxoutset RPC method by jonasschnelli · Pull Request #12196 · bitcoin/bitcoin · GitHub
 68 2018-06-28 19:03:55	0|wumpus|jonasschnelli: I think it makes sense to merge something, as you say it has a lot of ACKs, further improvements can be done later unless the current state is really unacceptable
 69 2018-06-28 19:04:01	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #13566: Fix get balance (06master...06fix_get_balance) 02https://github.com/bitcoin/bitcoin/pull/13566
 70 2018-06-28 19:04:15	0|sipa|wumpus: it's more so that we create something that remains compatible with future APIs
 71 2018-06-28 19:04:22	0|meshcollider|Hi
 72 2018-06-28 19:04:34	0|wumpus|sipa: the API will have to be finalized before the 0.17 release
 73 2018-06-28 19:04:36	0|sipa|(but i understand the desire to merge something; my comment would only apply to the xpub functionality)
 74 2018-06-28 19:05:11	0|wumpus|so FWIW feature freeze for 0.17 is 2018-07-16, if the PR is already merged by then then improvement can be considered a bugfix
 75 2018-06-28 19:05:23	0|sipa|perhaps i should clarify the scope
 76 2018-06-28 19:05:30	0|jonasschnelli|Yes. Please
 77 2018-06-28 19:05:36	0|sipa|my idea for output descriptors is here: https://gist.github.com/sipa/e3d23d498c430bb601c5bca83523fa82
 78 2018-06-28 19:05:43	0|sipa|i also have a prototype implementation for most of it
 79 2018-06-28 19:05:57	0|wumpus|nice!
 80 2018-06-28 19:06:21	0|jonasschnelli|Yes. I really like it.
 81 2018-06-28 19:06:21	0|promag|wumpus: for 0.17, dyn multi-wallet in the UI is required?
 82 2018-06-28 19:06:25	0|sipa|it is a general language that encodes all information about how to spend a whole set of keys with associated addresses/scripts/private keys/.... into one string, including support for multisig etc
 83 2018-06-28 19:06:30	0|wumpus|promag: why?
 84 2018-06-28 19:06:49	0|promag|it's a question
 85 2018-06-28 19:07:04	0|wumpus|promag: we want toh ave things consistent before a release, at least, apart from that it's simply a matter of what makes it in
 86 2018-06-28 19:07:19	0|sipa|my desire is that the entire wallet moves to something like that (so it's an implementation of my wallet descriptor rant i wrote a while ago: https://gist.github.com/sipa/125cfa1615946d0c3f3eec2ad7f250a2)
 87 2018-06-28 19:07:29	0|wumpus|I recognized it :)
 88 2018-06-28 19:07:38	0|cfields|sipa: +1, that makes a ton of sense
 89 2018-06-28 19:07:45	0|sipa|so import/export would operate at the level of those descriptors, instead of individual keys/scripts/pubkeys/hdchains/...
 90 2018-06-28 19:08:13	0|sipa|importmulti is already compatible with that design, for a large extent
 91 2018-06-28 19:08:49	0|sipa|the entirety of that idea is certainly not for 0.17, however
 92 2018-06-28 19:09:20	0|sipa|but that doesn't mean it can't be used already in relatively small scoped things already
 93 2018-06-28 19:09:26	0|sipa|and scanutxoset is one of those
 94 2018-06-28 19:09:28	0|jonasschnelli|what API changes would you propose for scantxoutset so we can migrate towards the output descriptors in the same cycle as migrating importmulti?
 95 2018-06-28 19:09:35	0|wumpus|that would be very last minute, but at least using it as a guideline to be compatible with the current stuff makes sense
 96 2018-06-28 19:09:57	0|sipa|jonasschnelli: you may not like this, but what about just dropping xpub support from the PR right now
 97 2018-06-28 19:10:10	0|jonasschnelli|sipa: this makes the PR pretty useless... :(
 98 2018-06-28 19:10:16	0|sipa|and then i'll PR the descriptor language, together with integration into scanutxoset
 99 2018-06-28 19:10:40	0|sipa|jonasschnelli: i understand
100 2018-06-28 19:10:44	0|sipa|feel free to disagree
101 2018-06-28 19:10:49	0|wumpus|it makes sense to divide it up like that
102 2018-06-28 19:10:52	0|jonasschnelli|But if the API break would be complex and painful, we can do that.
103 2018-06-28 19:11:07	0|wumpus|makes tha change smaller and less complex
104 2018-06-28 19:11:12	0|jonasschnelli|I don't disagree... :)
105 2018-06-28 19:11:22	0|wumpus|(besides sipa's point of course)
106 2018-06-28 19:11:45	0|sipa|if your concern is that it may not make it in for 0.17, you can still PR the (already written) xpub support as is later, before feature freeze?
107 2018-06-28 19:12:11	0|jonasschnelli|Sure... I guess its also not utterly bad if the xpub will be in 0.18.
108 2018-06-28 19:12:20	0|jonasschnelli|Okay. Will remove the xpub stuff
109 2018-06-28 19:12:37	0|sipa|thank you. i promise i'll work on having a PRable implementation soon
110 2018-06-28 19:12:59	0|jonasschnelli|The question of a gap limit came up recently (related to the xpub situation) but this concept seems not to work with utxo based scans..
111 2018-06-28 19:13:06	0|jonasschnelli|So a fixed lookup window makes more sense IMO
112 2018-06-28 19:13:49	0|sipa|agree
113 2018-06-28 19:14:23	0|sipa|jonasschnelli: that's actually a good point against having a gap limit inside the descriptor language
114 2018-06-28 19:14:32	0|sipa|(as a gap limit is not relevant for all use cases)
115 2018-06-28 19:14:50	0|jonasschnelli|gap limit is a broken concept IMO
116 2018-06-28 19:15:32	0|jonasschnelli|I would not use it in the descriptors...
117 2018-06-28 19:16:40	0|sipa|in the context of high priority PRs that's all i have to say about it; but we can discuss this idea in more detail as a separate topic if there's interest
118 2018-06-28 19:17:00	0|jonasschnelli|Thanks for working on this sipa. will give more feedback soon.
119 2018-06-28 19:17:06	0|wumpus|any proposals for adding high-priority PRs, or rmaoving them?
120 2018-06-28 19:17:31	0|wumpus|heh I already considered doing a #topic change
121 2018-06-28 19:17:38	0|jonasschnelli|I have two topic requests: a) Cipherseed, b) Cores BIP32 derivation "standard"
122 2018-06-28 19:18:18	0|promag|wumpus: I'll complete #13100 soon and it could go to hp list
123 2018-06-28 19:18:20	0|gribble|https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add menu entry to open wallet by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
124 2018-06-28 19:18:37	0|wumpus|let's add it whwen it's ready then
125 2018-06-28 19:18:41	0|promag|once ready
126 2018-06-28 19:18:42	0|promag|yes
127 2018-06-28 19:19:04	0|wumpus|#topic cipherseed
128 2018-06-28 19:19:07	0|jonasschnelli|https://gist.github.com/jonasschnelli/245f35894f6ff585b3f3d33c6f208991
129 2018-06-28 19:19:07	0|jonasschnelli|I have a specification draft for a new seed format similar to BIP39 with some neat properties and – before sending to the ML – would appreciate feedback.
130 2018-06-28 19:19:56	0|jonasschnelli|(its more an announcement then a topic, sry)
131 2018-06-28 19:20:39	0|wumpus|#link https://gist.github.com/jonasschnelli/245f35894f6ff585b3f3d33c6f208991
132 2018-06-28 19:20:53	0|wumpus|thanks for letting us know, will have a look
133 2018-06-28 19:21:07	0|wumpus|right, as no one has read it, I don't think there's much to discuss now
134 2018-06-28 19:21:20	0|wumpus|#topic cores BIP32 derivation "standard"
135 2018-06-28 19:21:24	0|jonasschnelli|It came up today in a discussion: Cores BIP32 derivation scheme is not specified in a BIP
136 2018-06-28 19:21:46	0|jonasschnelli|Some people think its vanilla/native BIP32... but its not... while other do native BIP32
137 2018-06-28 19:22:00	0|jonasschnelli|I'm not sure if we should define a standard for out derivation scheme...
138 2018-06-28 19:22:08	0|jonasschnelli|(would be a very short proposal)
139 2018-06-28 19:22:15	0|wumpus|agree ti would be good if the difference would be documented somewhere
140 2018-06-28 19:22:20	0|sipa|jonasschnelli: my thinking is that with output descriptors we can pretty much freely change it
141 2018-06-28 19:22:21	0|jonasschnelli|The BIP32 based derivation scheme has that security risk
142 2018-06-28 19:22:42	0|sipa|(including unhardened etc)
143 2018-06-28 19:23:18	0|jonasschnelli|Changing the scheme is one point,... but there are wallets out there following a derivation scheme that is not specified in word
144 2018-06-28 19:23:20	0|jonasschnelli|*words
145 2018-06-28 19:23:35	0|luke-jr|how does it affect other implementations?
146 2018-06-28 19:23:37	0|sipa|we could have a doc in our source tree that describes it
147 2018-06-28 19:23:56	0|sipa|i don't think it needs to be a bip; there's no real desire to convince others to adopt the same, i think?
148 2018-06-28 19:23:56	0|wumpus|luke-jr: only in the sense that other implementations might want to replicate it
149 2018-06-28 19:24:05	0|jonasschnelli|luke-jr: in case someone wants to import Cores xprivs...
150 2018-06-28 19:24:07	0|luke-jr|wumpus: why?
151 2018-06-28 19:24:24	0|wumpus|luke-jr: I don't know
152 2018-06-28 19:24:31	0|luke-jr|jonasschnelli: but not import a proper wallet in entirety?
153 2018-06-28 19:24:46	0|jonasschnelli|I precautionally wrote a tiny BIP,... but could also be used as an internal document: https://gist.github.com/jonasschnelli/0d383888ac51d5120540571173e35451
154 2018-06-28 19:24:54	0|luke-jr|(if there were a BIP, I would think it should cover the whole wallet format, not *just* derivation)
155 2018-06-28 19:25:10	0|sipa|luke-jr: saw my descriptor proposal above? :)
156 2018-06-28 19:25:19	0|achow101|just documnting the derivation in the docs repo is sufficient imo
157 2018-06-28 19:25:26	0|jonasschnelli|I think following BIP32 for "hot" wallets with private key export options is not ideal... Electrum does that as example
158 2018-06-28 19:26:31	0|sipa|my point is that i don't think our scheme is particularly an improvement over alternatives, or has all that much design we want to convince others about
159 2018-06-28 19:26:42	0|sipa|it's just one of many choices, and the one we made
160 2018-06-28 19:26:51	0|jonasschnelli|Agree with that. Yes.
161 2018-06-28 19:26:57	0|sipa|so we should just document it
162 2018-06-28 19:27:01	0|jonasschnelli|ack
163 2018-06-28 19:27:28	0|achow101|+1
164 2018-06-28 19:27:29	0|gmaxwell|Seems good.
165 2018-06-28 19:27:56	0|wumpus|agree
166 2018-06-28 19:29:10	0|wumpus|I think this leaves sipa's topic, but I think that's more or less discussed already?
167 2018-06-28 19:29:44	0|sipa|yeah, probably needs people reading the idea first to discuss more; can be done offline
168 2018-06-28 19:30:18	0|wumpus|right
169 2018-06-28 19:30:21	0|jonasschnelli|sipa: how would it interact with the keypool, flexible keypath?
170 2018-06-28 19:30:30	0|jonasschnelli|and a xpub
171 2018-06-28 19:30:33	0|sipa|jonasschnelli: keypool goes away
172 2018-06-28 19:30:40	0|wumpus|good riddance
173 2018-06-28 19:31:09	0|sipa|there is ephemeral data in the wallet associated with the descriptor (which is a black box, and descriptor specific), but in practice contains the expanded pubkeys
174 2018-06-28 19:31:31	0|sipa|that takes the place of the keypool- but those things don't all translate to independent keys in the wallet
175 2018-06-28 19:31:40	0|sipa|there would just be a single private key in your wallet, for example
176 2018-06-28 19:31:56	0|sipa|(or none at all; it can be in a hardware device too)
177 2018-06-28 19:32:20	0|sipa|flexible keypath... the descriptor just contains the path
178 2018-06-28 19:32:45	0|sipa|you can change it to whatever you like (but default wallets would of course pick some standard scheme)
179 2018-06-28 19:33:24	0|sipa|or rather you can import things with whatever path you like
180 2018-06-28 19:34:43	0|wumpus|makes sense
181 2018-06-28 19:35:01	0|jonasschnelli|Would it make sense that the descriptor support pkh(d34db33f/44'/0'/0':<seed>/1/i). (seed along with xpriv)?
182 2018-06-28 19:35:06	0|jonasschnelli|for backward compatibility
183 2018-06-28 19:35:27	0|sipa|jonasschnelli: i've thought about that, but that makes descriptors non-canonical
184 2018-06-28 19:35:39	0|sipa|(as in: you can't convert them to "public" form and back, and retain all information)
185 2018-06-28 19:36:30	0|sipa|i'm unsure how to deal with that; my thinking is initially no
186 2018-06-28 19:36:46	0|sipa|you can always implement it as an extra utility that converts from seed based format
187 2018-06-28 19:36:54	0|jonasschnelli|There is always the option of externally converting the seed to an xpriv, yes
188 2018-06-28 19:37:40	0|jonasschnelli|we can encode seeds into xprivs *duck*
189 2018-06-28 19:38:18	0|gmaxwell|Not to hijack, but has there been any progress towards implementing P2P link ephemeral encryption lately?  I know we were kinda waiting for some other networking refactors.
190 2018-06-28 19:38:44	0|sipa|cfields: ping?
191 2018-06-28 19:38:45	0|wumpus|#topic  P2Plink ephemeral encryptio
192 2018-06-28 19:38:51	0|jonasschnelli|I'm ready to pick that up any moment but was under the impression that sipa had plans to implement it
193 2018-06-28 19:39:06	0|jonasschnelli|I started with the implementation but halted at some point...
194 2018-06-28 19:39:20	0|jonasschnelli|I'm also not sure if we should delay it further more for "refactors"
195 2018-06-28 19:39:29	0|gmaxwell|I believed sipa did too, but asformentioned delays.
196 2018-06-28 19:39:33	0|cfields|heh, I was waiting on it to firm up. Guess we were waiting in circles :)
197 2018-06-28 19:39:44	0|cfields|jonasschnelli: for sure
198 2018-06-28 19:39:44	0|wumpus|hehe
199 2018-06-28 19:39:56	0|jonasschnelli|BTW: armory has implemented it and has plans to PR it to Core
200 2018-06-28 19:40:00	0|gmaxwell|Sipa and I made some major advances in the authentication part but the encryption doesn't need to wait on that.
201 2018-06-28 19:40:01	0|jonasschnelli|(not sure how soon and in what quality)
202 2018-06-28 19:40:02	0|sipa|cfields: waiting for encryption proposal to firm up before implementing it? or before continuing with network refactors?
203 2018-06-28 19:40:18	0|wumpus|jonasschnelli: oh wow
204 2018-06-28 19:40:38	0|jonasschnelli|Agree with gmaxwell. Authentication can be added later.
205 2018-06-28 19:40:56	0|cfields|sipa: i've had to put the net stuff on the backburner for now, so certainly don't wait for that.
206 2018-06-28 19:41:04	0|sipa|cfields: cool
207 2018-06-28 19:41:40	0|jonasschnelli|cfields: I think BIP151 is almost final (there is some issues with the version handshake)... the only thing that was holding me back where possible network refactors to first wait for
208 2018-06-28 19:41:49	0|cfields|I'm happy to help with the implementation. I was thinking we were waiting on the auth stuff.
209 2018-06-28 19:41:58	0|luke-jr|jonasschnelli: it can't be Final until it is adopted..
210 2018-06-28 19:41:59	0|gmaxwell|no, they're designed to operated independantly.
211 2018-06-28 19:42:05	0|jonasschnelli|Auth is additional and implementation wise it comes after 151
212 2018-06-28 19:42:11	0|sipa|we can implement 151 without 150
213 2018-06-28 19:42:24	0|gmaxwell|I would rather not use the prior auth design, we have better ones now.
214 2018-06-28 19:42:28	0|jonasschnelli|Yes. 150 can also be replaced (coexist) with other auth proposals
215 2018-06-28 19:42:33	0|sipa|fair
216 2018-06-28 19:42:41	0|jonasschnelli|Agree with that.
217 2018-06-28 19:43:06	0|jonasschnelli|sipas prework is here AFAIK: https://gist.github.com/sipa/29118d3fcfac69f9930d57433316c039
218 2018-06-28 19:43:20	0|sipa|i need to pick that up again
219 2018-06-28 19:43:24	0|gmaxwell|but right, there is no need delay 151 on auth-- it's completely oblivious to auth.
220 2018-06-28 19:43:38	0|jonasschnelli|I guess it uses some non-standard crypto stuff though
221 2018-06-28 19:43:59	0|sipa|jonasschnelli: no, https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b
222 2018-06-28 19:44:12	0|jonasschnelli|Oh. Mistaken your gist. Thansk
223 2018-06-28 19:44:16	0|jonasschnelli|*thanks
224 2018-06-28 19:44:19	0|sipa|the other link is just some cool trick, not a serious proposal
225 2018-06-28 19:45:22	0|jonasschnelli|Okay. If no one else wants to work on the implementation, I will continue then with BIP151 impl.
226 2018-06-28 19:45:42	0|gmaxwell|Basically there was an open question of if we wanted the encryption handshake to operate in such a way that there are no fixed bytes for easy blocking/detection.  But I think we thought the benefits were too dubious.
227 2018-06-28 19:45:58	0|gmaxwell|Esp since traffic patterns will identify bitcoin p2p links very clearly.
228 2018-06-28 19:46:08	0|cfields|too dubious? you mean foiled by dpi anyway?
229 2018-06-28 19:46:14	0|gmaxwell|And so probably better to just stick to something simple.
230 2018-06-28 19:46:21	0|jonasschnelli|Agree
231 2018-06-28 19:46:29	0|wumpus|hiding what kind of connection something is is very difficult
232 2018-06-28 19:46:37	0|gmaxwell|cfields: foiled by traffic analysis or smarer DPI (that does EC operations to match traffic)
233 2018-06-28 19:46:42	0|gmaxwell|smarter*
234 2018-06-28 19:47:09	0|gmaxwell|People can always carry bitcoin over other transports in any case, ... ones that can do things like pad out to a constant bitrate...
235 2018-06-28 19:47:26	0|gmaxwell|but we're certantly not going to make BIP151 do that. :P
236 2018-06-28 19:47:30	0|cfields|mm, that's a good point
237 2018-06-28 19:47:57	0|wumpus|which is why tor went with pluggable obfuscation layers, this for example: https://arxiv.org/pdf/1305.3199.pdf
238 2018-06-28 19:48:20	0|wumpus|might be creeping the scope a bit too much
239 2018-06-28 19:48:52	0|gmaxwell|in any case, changing the handshake to be harder to detect was the only 'maybe' design change that I'm aware of any of us considering.
240 2018-06-28 19:48:59	0|gmaxwell|For 151.
241 2018-06-28 19:49:37	0|jonasschnelli|You mean an obfuscation of the encryption handshake?
242 2018-06-28 19:49:47	0|gmaxwell|So I think we're good to implement, and the only changes that might be proposed would be ones that arose as a side effect of implementing and benchmarking.
243 2018-06-28 19:49:52	0|gmaxwell|jonasschnelli: yes.
244 2018-06-28 19:50:35	0|jonasschnelli|Yes. I think there is freedom to change the specs during implementation...
245 2018-06-28 19:50:38	0|gmaxwell|And my view is that it's not worthwhile because without other more complex obfscuation (which will be bandwidth costly) it'll still be pretty detectable.
246 2018-06-28 19:50:42	0|jonasschnelli|It's not really deployed on the network yet
247 2018-06-28 19:51:24	0|gmaxwell|right.
248 2018-06-28 19:52:04	0|jonasschnelli|Yes. Better not obscure and put efforts in a long term solutions (stuff like the ScrambleSuit)
249 2018-06-28 19:52:47	0|cfields|my only complaint was that it required message parsing to complete the handshake, but it's been a while since I looked, so I'm not sure if that's still the case. I also got the impression that nobody else seemed all that bothered by that anyway.
250 2018-06-28 19:53:39	0|jonasschnelli|can you elaborate a bit more on " it required message parsing to complete the handshak"?
251 2018-06-28 19:54:51	0|cfields|jonasschnelli: we can discuss after the meeting, I need to take a look at the current spec
252 2018-06-28 19:54:59	0|jonasschnelli|sure. Thanks cfields
253 2018-06-28 19:58:20	0|wumpus|#endmeeting
254 2018-06-28 19:58:21	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-28-19.00.log.html
255 2018-06-28 19:58:21	0|lightningbot|Meeting ended Thu Jun 28 19:59:47 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
256 2018-06-28 19:58:21	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-28-19.00.html
257 2018-06-28 19:58:21	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-28-19.00.txt
258 2018-06-28 19:58:54	0|sipa|lunch?
259 2018-06-28 19:59:45	0|BlueMatt|sounds good
260 2018-06-28 19:59:47	0|BlueMatt|wait, no, already did that
261 2018-06-28 19:59:53	0|instagibbs|like 3 hours ago
262 2018-06-28 20:01:20	0|jonasschnelli|irclunch?
263 2018-06-28 20:08:55	0|cfields|jonasschnelli: If the first 32bytes over the wire are a pubkey, the network layer can do the handshake and notify us of a new connection only after it's done. The message processor wouldn't have to know or care about encryption, it just pushes messages, and the network layer handles the rest automatically.
264 2018-06-28 20:09:09	0|bitcoin-git|13bitcoin/06master 14c2e4fc8 15João Barbosa: bench: Simplify CoinSelection
265 2018-06-28 20:09:09	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c93c360eec4d...b330f3fdd56b
266 2018-06-28 20:09:10	0|bitcoin-git|13bitcoin/06master 14b330f3f 15MarcoFalke: Merge #13563: bench: Simplify CoinSelection...
267 2018-06-28 20:09:17	0|cfields|If, however, messages have to be parsed before doing the handshake, the net layer has to be told to switch to encryption, which imo is awkward.
268 2018-06-28 20:09:42	0|jonasschnelli|Yes. I think your right...
269 2018-06-28 20:09:59	0|jonasschnelli|We should probably do a dummy handshake in advance... what would you think about that cfields?
270 2018-06-28 20:10:09	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #13563: bench: Simplify CoinSelection (06master...062018-08-bench-coinselection) 02https://github.com/bitcoin/bitcoin/pull/13563
271 2018-06-28 20:10:16	0|cfields|(I'm assuming that encryption would be handled at the net layer, I suppose doing it at the message processing layer is an option is well, but that feels like a step in the wrong direction)
272 2018-06-28 20:10:38	0|cfields|jonasschnelli: dummy handshake?
273 2018-06-28 20:11:18	0|jonasschnelli|cfields: we do a normal unencrypted version/verack handshake, .. then p2p initiator sends encinit
274 2018-06-28 20:11:25	0|cfields|i only bring it up because it seems avoidable, not because it's really a big deal
275 2018-06-28 20:11:58	0|jonasschnelli|A... I guess now I understand your point...
276 2018-06-28 20:12:21	0|cfields|jonasschnelli: i'm not following. Net would still have to be told to switch to encryption.
277 2018-06-28 20:12:32	0|jonasschnelli|Yes. It's another issue...
278 2018-06-28 20:12:47	0|jonasschnelli|Wouldn't it be a problem for some clients if the first package would be a pubkey?
279 2018-06-28 20:13:00	0|jonasschnelli|Also,.. how would you know if the other side supports encryption?
280 2018-06-28 20:13:24	0|cfields|jonasschnelli: yea, I trivialized that part for the sake of the example :)
281 2018-06-28 20:13:32	0|jonasschnelli|Heh... yes.
282 2018-06-28 20:13:43	0|jonasschnelli|I guess leaving out the message processor is probably hard,...
283 2018-06-28 20:14:07	0|jonasschnelli|eventually we need to look at the protocol version in the handshake and only send an encinit message if the protocol version signals support
284 2018-06-28 20:14:29	0|jonasschnelli|Assuming that non-supported message types are just ignore may be a fragile concept
285 2018-06-28 20:15:03	0|jonasschnelli|(though unsure,... its probably okay)
286 2018-06-28 20:15:25	0|cfields|jonasschnelli: could just send some magic before the pubkey, which would signal support and require no parsing other than an equality check.
287 2018-06-28 20:17:01	0|jonasschnelli|But if you connect to a peer and send magic+33b-pubkey+cipertype, woudln't you get disconnected straight away?
288 2018-06-28 20:17:18	0|jonasschnelli|(if non BIP151 supporting peer)
289 2018-06-28 20:19:42	0|cfields|uhmm.. IIRC we allow more than one chance for the initial message? checking.
290 2018-06-28 20:20:54	0|jonasschnelli|Also,.. not sure if we should respect other implementations.
291 2018-06-28 20:21:05	0|jonasschnelli|(libbitcoin / btcd / bcoin)
292 2018-06-28 20:22:22	0|luke-jr|jonasschnelli: that's a disturbing thing to say.
293 2018-06-28 20:22:46	0|jonasschnelli|luke-jr: I'm only saying since there are no clear protocol specification for this
294 2018-06-28 20:23:02	0|jonasschnelli|(is it allow to send data before the version/verack handshake)
295 2018-06-28 20:23:22	0|jonasschnelli|(then s/allowed/tolerated)
296 2018-06-28 20:23:22	0|luke-jr|oh, I misinterpreted you I think
297 2018-06-28 20:23:44	0|jonasschnelli|I mean ethically, we should respect them. :)
298 2018-06-28 20:24:01	0|cfields|haha :)
299 2018-06-28 20:24:03	0|jonasschnelli|But we where talking on possible encinit p2p encryption disconnets
300 2018-06-28 20:26:01	0|cfields|jonasschnelli: ok, looks like we can send before version as long as the magic is correct.
301 2018-06-28 20:26:21	0|cfields|but yes, that's very much an implementation detail. No clue how other clients handle it.
302 2018-06-28 20:26:44	0|jonasschnelli|Yes. That sound a bit fragile...
303 2018-06-28 20:27:35	0|jonasschnelli|But we could reconnect once we got disconnected after that pre-handshake encryption request and try without encryption (if unencrypted connections are allowed)
304 2018-06-28 20:37:59	0|cfields|jonasschnelli: mm, it's not worth going that far I think
305 2018-06-28 20:45:10	0|Alexandra|holaaaaa?
306 2018-06-28 21:04:10	0|gmaxwell|jonasschnelli: we can coordinate if there is some incompatiblity.
307 2018-06-28 21:04:40	0|gmaxwell|And we should avoid gratitiously breaking, where its possible without significant harm.
308 2018-06-28 21:05:35	0|gmaxwell|But if at the end of the day an implementation which is almost non-existant on the public network needs updates to work right with sensible behavior, ... well then it is what it is. To be kind we could offer patches.
309 2018-06-28 21:09:07	0|gmaxwell|I'm really not a fan of the "try then retry if it fails" behavior, being stateful makes it more complex and have more ways to fail.
310 2018-06-28 21:09:33	0|gmaxwell|E.g. say the remote party is almost out of sockets, first try fails due to crypto snafu, second try just doesn't connect due to socket exhaustion.
311 2018-06-28 21:12:46	0|echeveria|jonasschnelli: gmaxwell: cfields: personally I'd do something a little more interesting. bind a new socket, say 8383 and *only* accept encrypted connections there. older implementations explicitly avoid non-standard ports, and it gives the option to selectively only use bip151.
312 2018-06-28 21:13:18	0|gmaxwell|echeveria: the downside there is that now everyone's firewall deployments need to change. :(
313 2018-06-28 21:13:21	0|echeveria|there's already logic for multiple bind interfaces with different properties (ie, whitebind). all this means is you gossip both of your ports.
314 2018-06-28 21:13:45	0|gmaxwell|one thing we could do in a slower migration is support two ports, one is legacy or encrypted, the other is encrypted only.
315 2018-06-28 21:14:15	0|gmaxwell|but I'm still skeptical that it's worth doing that.
316 2018-06-28 21:14:21	0|cfields|yea, I've considered that as well. But I was afraid that we'd get too much backlash from network admin
317 2018-06-28 21:14:30	0|cfields|^^ what gmaxwell said
318 2018-06-28 21:14:34	0|gmaxwell|one could, on the legacy port, hang up whenever encryption isn't used.
319 2018-06-28 21:14:48	0|cfields|also, we currently penalize non-8333 I believe.
320 2018-06-28 21:14:52	0|gmaxwell|that sounds silly now, but in two years when 99% of everything has BIP151 it'll be reasonable.
321 2018-06-28 21:15:01	0|echeveria|cfields: that's sort of why it's ideal.
322 2018-06-28 21:15:21	0|echeveria|cfields: bitcoin nodes won't ever reasonably connect to a non 8333 rumored port.
323 2018-06-28 21:15:27	0|gmaxwell|the idea there being that old peers won't rumor or connect to the encrypted ones...
324 2018-06-28 21:15:55	0|cfields|hmm. well I'd be all for it if we could get an idea of how many people it would piss off
325 2018-06-28 21:16:45	0|gmaxwell|echeveria: so what really does that gain over just the disconnection approach?  I think only that old peers will waste less time trying to connect to encrypted only nodes.
326 2018-06-28 21:17:01	0|cfields|also makes me curious about the reasoning for the historical http/https 80/443 split. I actually have no idea how that unfolded initially.
327 2018-06-28 21:17:55	0|gmaxwell|But I think there is relatively little reason to run encrypted-only for inbound. (for outbound connections, you don't need another port, service flags are sufficient)
328 2018-06-28 21:18:20	0|echeveria|gmaxwell: I like moving away from 8333 that's shared with bcash, and being able to be selectively restrictive about the type of traffic without necessarily inspecting it is nice. to me it's just easier to reason about, but that's possibly personal preference.
329 2018-06-28 21:18:34	0|gmaxwell|effectively, I think echeveria's proposal is to abuse the port number to create an implicit "old nodes don't connect here please" flag.
330 2018-06-28 21:18:43	0|echeveria|yup.
331 2018-06-28 21:19:03	0|cfields|yea. which I guess is exactly the net-level signal that I'm after.
332 2018-06-28 21:19:36	0|gmaxwell|Probably that idea should get incorporated in wumpus' new addr message proposal.  e.g. define some set of service flags where if you don't know their meaning you avoid connecting.
333 2018-06-28 21:19:49	0|gmaxwell|doesn't help old peers, but we'll probably have this desire in the future.
334 2018-06-28 21:20:00	0|cfields|gmaxwell: lol, we could use 18333 :)
335 2018-06-28 21:20:41	0|gmaxwell|Also, I'd rather bother network admins just once when we add a UDP based transport in the future. :)
336 2018-06-28 21:20:46	0|cfields|(not a serious suggestion, but it would make life a bit easier on the routing side)
337 2018-06-28 21:25:47	0|gmaxwell|I dunno if pieter has talked to y'all about what we came up with for authentication, it's pretty awesome.  We gain the property that an active MITM cannot detect if authentication is actually in use or not, so he can't monitor anyone at all or takes the risk that his interception is detected.  This is a major advance over auth everywhere else where an active MITM can detect users using auth and
338 2018-06-28 21:25:47	0|gmaxwell|just sever the link (like an innocent network failure) and stop MITMing between that user pair.
339 2018-06-28 21:32:30	0|sipa|i have
340 2018-06-28 21:32:52	0|sipa|though the best we have is something that only supports one pubkey and one privkey afaik
341 2018-06-28 21:42:33	0|cfields|gmaxwell: yes, that's very cool.
342 2018-06-28 21:45:02	0|cfields|sipa: thoughts on echeveria's suggestion to use a separate port?
343 2018-06-28 21:47:33	0|sipa|cfields: seems a nice and easy solution, but i see the possible administrative issues
344 2018-06-28 21:47:48	0|sipa|i also don't think there is that much of a problem with reconnecting
345 2018-06-28 21:48:55	0|gmaxwell|I think the only thing a new port would buy is avoiding old peers attempting to connect to us if we were only going to accept encrypted connections on inbound. Or am I missing some other benefit?
346 2018-06-28 21:51:25	0|sipa|well there are 3 approaches suggested (a) new port (b) reconnect on same port with wholly different protocol after learning peer supports encryption (c) upgrade the connection in flight
347 2018-06-28 21:51:40	0|cfields|gmaxwell: that's it, but it makes traffic significantly easier to handle imo
348 2018-06-28 21:52:58	0|gmaxwell|cfields: how so?
349 2018-06-28 21:53:06	0|cfields|sipa: (bi) always plan to reconnect to upgrade (bii) only do it if they boot us for trying
350 2018-06-28 21:55:41	0|gmaxwell|I think I'm confused. AFAIK the 'boot us for trying' isn't a real problem.
351 2018-06-28 21:56:07	0|cfields|gmaxwell: as described, bip151 would require us to send the first bytes up for parsing, then have the message handler tell the net handler to deal with encryption from that point on. If encryption could be assumed, net could just handle it transparently.
352 2018-06-28 21:56:37	0|gmaxwell|This is perhaps a sign that our layering is faulty. :P
353 2018-06-28 21:56:54	0|cfields|and this is me trying to avoid falling in the same trap again :)
354 2018-06-28 21:57:59	0|gmaxwell|but okay, I see that. I think forcing onto another port due to software layering in the networking is more than a little ugly.
355 2018-06-28 21:58:00	0|cfields|er... I say "net layer" and "message processing layer", but I mean those conceptually. Not our specific implementation.
356 2018-06-28 21:58:32	0|gmaxwell|if encryption must be on another port, rather than optionally on another port then we'd get a massive deployment loss due to users needing to punch new firewall holes.
357 2018-06-28 21:59:04	0|gmaxwell|E.g. I was thinking of echeveria's proposal as 8333 becomes legacy OR encrypted, and 8334 is encrypted only.
358 2018-06-28 22:00:05	0|cfields|Ah, ok.
359 2018-06-28 22:01:56	0|cfields|well, I suppose we could do that as well. Introduce the round-trip layer violation for 8333, and hope for some future that's nearly all 8334, and un-encrypted 8333 could be dropped at that point.
360 2018-06-28 22:02:29	0|cfields|I guess that doesn't provide much motivation to switch, though.
361 2018-06-28 22:02:47	0|sipa|echo $'\x3d\x20\x53\xd7\xff\x00\x00\x00' | base64
362 2018-06-28 22:02:47	0|sipa|PSBT1/8K
363 2018-06-28 22:02:54	0|cfields|blehk, and that would suck to rumor
364 2018-06-28 22:02:54	0|sipa|echo $'\x3d\x20\x53\xd7\xff\xff\xff\xff' | base64
365 2018-06-28 22:03:02	0|sipa|PSBT1/////8K
366 2018-06-28 22:03:35	0|sipa|so if the PSBT magic bytes are 0x3d 0x20 0x53 0xd7 0xff, the base64 encoding will always begin with "PSBT1/"
367 2018-06-28 22:10:04	0|sipa|or {a6 c6 ed fb ff} to encode as "psbt+/"