1 2018-06-28T00:13:18  *** luke-jr has quit IRC
  2 2018-06-28T00:13:30  *** luke-jr has joined #bitcoin-core-dev
  3 2018-06-28T00:28:31  *** Randolf has quit IRC
  4 2018-06-28T00:32:00  *** BashCo has quit IRC
  5 2018-06-28T00:34:48  *** BashCo has joined #bitcoin-core-dev
  6 2018-06-28T00:53:02  *** luke-jr has quit IRC
  7 2018-06-28T00:53:19  *** luke-jr has joined #bitcoin-core-dev
  8 2018-06-28T00:55:50  <achow101> travis seems dead, nothing is being built
  9 2018-06-28T01:15:09  *** Victorsueca has quit IRC
 10 2018-06-28T01:16:23  *** Victorsueca has joined #bitcoin-core-dev
 11 2018-06-28T01:17:31  *** bitconner has quit IRC
 12 2018-06-28T01:38:00  *** Murch has quit IRC
 13 2018-06-28T01:49:11  *** unholymachine has quit IRC
 14 2018-06-28T02:33:24  *** AaronvanW has quit IRC
 15 2018-06-28T02:33:33  *** BashCo has quit IRC
 16 2018-06-28T02:33:58  *** AaronvanW has joined #bitcoin-core-dev
 17 2018-06-28T02:34:08  *** bitconner has joined #bitcoin-core-dev
 18 2018-06-28T02:35:36  *** BashCo has joined #bitcoin-core-dev
 19 2018-06-28T02:38:39  *** bitconner has quit IRC
 20 2018-06-28T02:38:39  *** AaronvanW has quit IRC
 21 2018-06-28T03:04:32  <bitcoin-git> [bitcoin] achow101 opened pull request #13557: BIP 174 PSBT Serializations and RPCs (master...psbt) https://github.com/bitcoin/bitcoin/pull/13557
 22 2018-06-28T03:07:26  *** bitconner has joined #bitcoin-core-dev
 23 2018-06-28T03:32:59  *** dbt has joined #bitcoin-core-dev
 24 2018-06-28T03:43:28  *** BashCo has quit IRC
 25 2018-06-28T03:47:47  *** BashCo has joined #bitcoin-core-dev
 26 2018-06-28T04:03:10  *** _flow__ has quit IRC
 27 2018-06-28T04:12:25  *** _flow__ has joined #bitcoin-core-dev
 28 2018-06-28T04:15:47  *** Randolf has joined #bitcoin-core-dev
 29 2018-06-28T04:24:22  *** bitconner has quit IRC
 30 2018-06-28T04:25:39  *** veleiro has joined #bitcoin-core-dev
 31 2018-06-28T04:41:29  *** bitconner has joined #bitcoin-core-dev
 32 2018-06-28T05:09:07  <bitcoin-git> [bitcoin] Empact opened pull request #13558: Drop unused GetType() from CSizeComputer (master...c-size-computer) https://github.com/bitcoin/bitcoin/pull/13558
 33 2018-06-28T05:11:26  *** Krellan has quit IRC
 34 2018-06-28T05:12:04  *** Krellan has joined #bitcoin-core-dev
 35 2018-06-28T05:17:38  *** meshcollider has joined #bitcoin-core-dev
 36 2018-06-28T05:25:04  *** veleiro` has joined #bitcoin-core-dev
 37 2018-06-28T05:26:56  *** shesek has joined #bitcoin-core-dev
 38 2018-06-28T05:26:56  *** shesek has joined #bitcoin-core-dev
 39 2018-06-28T05:27:17  *** veleiro has quit IRC
 40 2018-06-28T05:32:21  *** zigen has joined #bitcoin-core-dev
 41 2018-06-28T05:51:25  *** Murch has joined #bitcoin-core-dev
 42 2018-06-28T06:11:48  *** arubi has quit IRC
 43 2018-06-28T06:12:11  *** arubi has joined #bitcoin-core-dev
 44 2018-06-28T06:17:35  *** jtimon has quit IRC
 45 2018-06-28T06:20:05  *** veleiro` has quit IRC
 46 2018-06-28T06:28:34  *** bitconner has quit IRC
 47 2018-06-28T06:29:48  *** bitconner has joined #bitcoin-core-dev
 48 2018-06-28T06:39:07  *** rex4539 has joined #bitcoin-core-dev
 49 2018-06-28T06:39:34  *** squarfed[m] has quit IRC
 50 2018-06-28T06:43:00  *** squarfed[m] has joined #bitcoin-core-dev
 51 2018-06-28T06:57:24  <bitcoin-git> [bitcoin] Empact opened pull request #13560: Drop unused serialization support from CAddresss (master...caddress-serialization) https://github.com/bitcoin/bitcoin/pull/13560
 52 2018-06-28T07:09:10  <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).
 53 2018-06-28T07:09:39  <provoostenator> Worse, it sometimes tells me to reindex.
 54 2018-06-28T07:10:39  <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?
 55 2018-06-28T07:12:59  <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.
 56 2018-06-28T07:13:02  <gribble> https://github.com/bitcoin/bitcoin/issues/12404 | Prune more aggressively during IBD by Sjors · Pull Request #12404 · bitcoin/bitcoin · GitHub
 57 2018-06-28T07:15:29  *** Squidicuz has quit IRC
 58 2018-06-28T07:18:21  *** Krellan has quit IRC
 59 2018-06-28T07:19:08  *** Krellan has joined #bitcoin-core-dev
 60 2018-06-28T07:26:24  *** Randolf has quit IRC
 61 2018-06-28T07:49:29  *** Murch has quit IRC
 62 2018-06-28T08:02:10  *** tripleslash has quit IRC
 63 2018-06-28T08:04:10  *** tripleslash has joined #bitcoin-core-dev
 64 2018-06-28T08:04:17  *** adam3us has quit IRC
 65 2018-06-28T08:04:17  *** warren has quit IRC
 66 2018-06-28T08:06:53  *** adam3us has joined #bitcoin-core-dev
 67 2018-06-28T08:06:55  *** warren has joined #bitcoin-core-dev
 68 2018-06-28T08:07:15  *** tripleslash has quit IRC
 69 2018-06-28T08:12:01  *** d9b4bef9 has quit IRC
 70 2018-06-28T08:13:15  *** d9b4bef9 has joined #bitcoin-core-dev
 71 2018-06-28T08:20:30  *** tripleslash has joined #bitcoin-core-dev
 72 2018-06-28T08:23:06  <bitcoin-git> [bitcoin] Empact closed pull request #13560: WIP: Drop unused serialization support from CAddresss (master...caddress-serialization) https://github.com/bitcoin/bitcoin/pull/13560
 73 2018-06-28T08:24:34  *** Krellan has quit IRC
 74 2018-06-28T08:26:55  *** tripleslash has quit IRC
 75 2018-06-28T08:31:50  *** tripleslash has joined #bitcoin-core-dev
 76 2018-06-28T08:33:33  *** timothy has joined #bitcoin-core-dev
 77 2018-06-28T08:57:18  *** promag has joined #bitcoin-core-dev
 78 2018-06-28T09:13:20  <bitcoin-git> [bitcoin] droark opened pull request #13561: Qt: Remove unnecessary image buffer for Mac dock icon (master...rm_icon_buffer) https://github.com/bitcoin/bitcoin/pull/13561
 79 2018-06-28T09:16:21  *** laurentmt has joined #bitcoin-core-dev
 80 2018-06-28T09:17:21  *** meshcollider has quit IRC
 81 2018-06-28T09:27:28  *** laurentmt has quit IRC
 82 2018-06-28T09:28:12  *** Sentineo has joined #bitcoin-core-dev
 83 2018-06-28T09:34:38  *** AaronvanW has joined #bitcoin-core-dev
 84 2018-06-28T09:37:57  *** Aaronvan_ has joined #bitcoin-core-dev
 85 2018-06-28T09:39:52  *** AaronvanW has quit IRC
 86 2018-06-28T09:39:58  *** Aaronva__ has joined #bitcoin-core-dev
 87 2018-06-28T09:42:39  *** arubi has quit IRC
 88 2018-06-28T09:43:30  *** Aaronvan_ has quit IRC
 89 2018-06-28T09:47:34  *** arubi has joined #bitcoin-core-dev
 90 2018-06-28T09:53:11  <jonasschnelli> Anyone willing to pre-review a BIP proposal for encrypted wallet seeds https://gist.github.com/jonasschnelli/245f35894f6ff585b3f3d33c6f208991? gmaxwell, sipa, roasbeef
 91 2018-06-28T09:58:01  *** ExtraCrispy has joined #bitcoin-core-dev
 92 2018-06-28T10:09:47  *** jtimon has joined #bitcoin-core-dev
 93 2018-06-28T10:17:07  *** quer has joined #bitcoin-core-dev
 94 2018-06-28T10:18:12  *** dbt has left #bitcoin-core-dev
 95 2018-06-28T10:25:10  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #13562: travis: Switch back to trusty for now (master...Mf1806-qaTravisTrusty) https://github.com/bitcoin/bitcoin/pull/13562
 96 2018-06-28T10:31:38  *** Guyver2 has joined #bitcoin-core-dev
 97 2018-06-28T10:32:51  <promag> mac build in travis uses qt5.7.1?
 98 2018-06-28T10:34:54  *** wolfspraul has joined #bitcoin-core-dev
 99 2018-06-28T10:41:23  *** bitconner has quit IRC
100 2018-06-28T10:51:28  <bitcoin-git> [bitcoin] promag opened pull request #13563: bench: Simplify CoinSelection (master...2018-08-bench-coinselection) https://github.com/bitcoin/bitcoin/pull/13563
101 2018-06-28T10:53:42  <promag> MarcoFalke: is that what you mean?
102 2018-06-28T11:05:44  *** unholymachine has joined #bitcoin-core-dev
103 2018-06-28T11:13:12  *** bitconner has joined #bitcoin-core-dev
104 2018-06-28T11:22:40  *** bitconner has quit IRC
105 2018-06-28T11:37:47  *** bitconner has joined #bitcoin-core-dev
106 2018-06-28T11:42:54  *** bitconner has quit IRC
107 2018-06-28T11:43:10  *** bitconner has joined #bitcoin-core-dev
108 2018-06-28T11:48:12  *** bitconner has quit IRC
109 2018-06-28T12:07:10  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d96bdd78307b...2328039bfc49
110 2018-06-28T12:07:10  <bitcoin-git> bitcoin/master fa103a5 MarcoFalke: [qa] wallet_basic: Specify minimum required amount for listunspent
111 2018-06-28T12:07:11  <bitcoin-git> bitcoin/master 2328039 MarcoFalke: Merge #13535: [qa] wallet_basic: Specify minimum required amount for listunspent...
112 2018-06-28T12:08:07  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #13535: [qa] wallet_basic: Specify minimum required amount for listunspent (master...Mf1806-qaWalletBasic) https://github.com/bitcoin/bitcoin/pull/13535
113 2018-06-28T12:10:18  *** Aaronva__ is now known as AaronvanW
114 2018-06-28T12:11:05  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2328039bfc49...c93c360eec4d
115 2018-06-28T12:11:05  <bitcoin-git> bitcoin/master ea49e06 practicalswift: tests: Fix incorrect documentation for test case cuckoocache_hit_rate_ok
116 2018-06-28T12:11:06  <bitcoin-git> bitcoin/master c93c360 MarcoFalke: Merge #13551: tests: Fix incorrect documentation for test case cuckoocache_hit_rate_ok...
117 2018-06-28T12:11:55  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #13551: tests: Fix incorrect documentation for test case cuckoocache_hit_rate_ok (master...truth-in-advertising) https://github.com/bitcoin/bitcoin/pull/13551
118 2018-06-28T12:22:35  *** BoxerJack3 has joined #bitcoin-core-dev
119 2018-06-28T12:25:42  *** bitconner has joined #bitcoin-core-dev
120 2018-06-28T12:26:27  *** quer has quit IRC
121 2018-06-28T12:27:23  *** quer has joined #bitcoin-core-dev
122 2018-06-28T12:31:29  *** quer has quit IRC
123 2018-06-28T12:31:38  *** quer_ has joined #bitcoin-core-dev
124 2018-06-28T12:32:17  *** BoxerJack3 has quit IRC
125 2018-06-28T12:32:44  *** BoxerJack3 has joined #bitcoin-core-dev
126 2018-06-28T12:32:57  *** intcat has quit IRC
127 2018-06-28T12:36:34  *** intcat has joined #bitcoin-core-dev
128 2018-06-28T12:38:00  *** BoxerJack3 has quit IRC
129 2018-06-28T12:40:34  *** bitconner has quit IRC
130 2018-06-28T12:42:51  *** schnerchi123 has joined #bitcoin-core-dev
131 2018-06-28T13:15:01  *** d9b4bef9 has quit IRC
132 2018-06-28T13:16:08  *** d9b4bef9 has joined #bitcoin-core-dev
133 2018-06-28T13:18:22  *** bitconner has joined #bitcoin-core-dev
134 2018-06-28T13:22:57  *** bitconner has quit IRC
135 2018-06-28T13:25:10  *** bedo has joined #bitcoin-core-dev
136 2018-06-28T13:34:42  <promag> qt: funny thing, connect(..., &Foo::foo) doesn't work if foo is a private slot, BUT connect(..., SLOT(foo()) works..
137 2018-06-28T13:35:21  <bedo> Hi all, it's only me or the testnet are generating crazy amount of block?
138 2018-06-28T13:44:25  <jonasschnelli> bedo: yes. Someone mining with an ASIC farm I guess
139 2018-06-28T13:44:55  <jonasschnelli> 4-5 seconds interval between blocks. :)
140 2018-06-28T13:46:34  <bedo> jonasschnelli: today is hard day for develop over bitcoin
141 2018-06-28T13:47:34  <jonasschnelli> bedo: use regtest. :)
142 2018-06-28T13:47:57  *** Lightblock_ has joined #bitcoin-core-dev
143 2018-06-28T13:48:12  <Lightblock_> Hi
144 2018-06-28T13:48:20  <Lightblock_> happy to be here
145 2018-06-28T13:48:46  *** Lightblock__ has joined #bitcoin-core-dev
146 2018-06-28T13:49:44  <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 ?
147 2018-06-28T13:50:11  *** lnostdal has quit IRC
148 2018-06-28T13:52:12  <Lightblock_> sorry, seems like I have put in the worng channel
149 2018-06-28T13:52:23  <Lightblock_> nevermind, asked in the #bitcoin already
150 2018-06-28T13:53:09  *** lnostdal has joined #bitcoin-core-dev
151 2018-06-28T13:53:23  <bedo> jonasschnelli: yep, is the only way,  will see you at BOB?
152 2018-06-28T13:54:12  <jonasschnelli> bedo: Yes. Sure!
153 2018-06-28T13:56:26  <bedo> jonasschnelli: perfect ;)
154 2018-06-28T14:14:13  *** piootr has joined #bitcoin-core-dev
155 2018-06-28T14:28:00  *** Lightblock_ has quit IRC
156 2018-06-28T14:28:16  *** echonaut8 has joined #bitcoin-core-dev
157 2018-06-28T14:28:40  *** echonaut has quit IRC
158 2018-06-28T14:30:04  *** unholymachine has quit IRC
159 2018-06-28T14:31:13  *** Murch has joined #bitcoin-core-dev
160 2018-06-28T14:34:35  *** bitconner has joined #bitcoin-core-dev
161 2018-06-28T14:54:04  *** belcher has joined #bitcoin-core-dev
162 2018-06-28T14:59:05  *** infernix has quit IRC
163 2018-06-28T15:00:09  *** rex4539 has quit IRC
164 2018-06-28T15:01:50  *** m8tion has joined #bitcoin-core-dev
165 2018-06-28T15:07:40  *** piootr has quit IRC
166 2018-06-28T15:19:10  *** ossifrage has quit IRC
167 2018-06-28T15:21:47  *** infernix has joined #bitcoin-core-dev
168 2018-06-28T15:38:11  *** bedo has quit IRC
169 2018-06-28T15:39:41  *** bitconner has quit IRC
170 2018-06-28T15:47:40  *** bitconner has joined #bitcoin-core-dev
171 2018-06-28T15:52:34  *** bitconner has quit IRC
172 2018-06-28T15:57:45  *** m8tion has quit IRC
173 2018-06-28T15:58:48  *** m8tion has joined #bitcoin-core-dev
174 2018-06-28T15:59:11  *** anthis has quit IRC
175 2018-06-28T16:00:18  *** anthis has joined #bitcoin-core-dev
176 2018-06-28T16:01:21  *** jtimon has quit IRC
177 2018-06-28T16:08:10  *** opdenkamp has quit IRC
178 2018-06-28T16:16:00  *** bitconner has joined #bitcoin-core-dev
179 2018-06-28T16:20:04  *** Krellan has joined #bitcoin-core-dev
180 2018-06-28T16:20:27  *** bitconner has quit IRC
181 2018-06-28T16:27:33  *** promag has quit IRC
182 2018-06-28T16:30:03  *** Murch has quit IRC
183 2018-06-28T16:31:11  *** Murch has joined #bitcoin-core-dev
184 2018-06-28T16:33:33  *** unholymachine has joined #bitcoin-core-dev
185 2018-06-28T16:39:20  *** ossifrage has joined #bitcoin-core-dev
186 2018-06-28T16:41:20  *** promag has joined #bitcoin-core-dev
187 2018-06-28T16:48:44  *** m8tion has quit IRC
188 2018-06-28T16:50:22  *** m8tion has joined #bitcoin-core-dev
189 2018-06-28T16:51:20  *** opdenkamp has joined #bitcoin-core-dev
190 2018-06-28T16:52:05  *** rex4539 has joined #bitcoin-core-dev
191 2018-06-28T16:57:19  *** Lightblock has joined #bitcoin-core-dev
192 2018-06-28T17:02:23  *** bitconner has joined #bitcoin-core-dev
193 2018-06-28T17:13:40  *** Lightblock has quit IRC
194 2018-06-28T17:17:02  *** d9b4bef9 has quit IRC
195 2018-06-28T17:17:47  *** Krellan has quit IRC
196 2018-06-28T17:18:08  *** d9b4bef9 has joined #bitcoin-core-dev
197 2018-06-28T17:20:46  *** bitconner has quit IRC
198 2018-06-28T17:21:56  *** Giszmo has joined #bitcoin-core-dev
199 2018-06-28T17:25:09  *** bitconner has joined #bitcoin-core-dev
200 2018-06-28T17:28:30  *** Murch has quit IRC
201 2018-06-28T17:29:43  *** promag has quit IRC
202 2018-06-28T17:32:54  *** Murch has joined #bitcoin-core-dev
203 2018-06-28T17:37:50  <bitcoin-git> [bitcoin] jnewbery opened pull request #13564: [wallet] loadwallet shouldn't create new wallets. (master...dont_load_nonexistent_wallet) https://github.com/bitcoin/bitcoin/pull/13564
204 2018-06-28T17:40:37  *** jtimon has joined #bitcoin-core-dev
205 2018-06-28T17:43:08  *** drexl has joined #bitcoin-core-dev
206 2018-06-28T17:45:27  *** bitconner has quit IRC
207 2018-06-28T17:47:58  *** Alexandra has joined #bitcoin-core-dev
208 2018-06-28T17:48:10  <Alexandra> Holaaa
209 2018-06-28T17:48:57  *** Alexandra has left #bitcoin-core-dev
210 2018-06-28T17:51:09  *** laurentmt has joined #bitcoin-core-dev
211 2018-06-28T17:52:51  *** laurentmt has quit IRC
212 2018-06-28T17:54:14  *** bitconner has joined #bitcoin-core-dev
213 2018-06-28T18:07:04  *** intcat has quit IRC
214 2018-06-28T18:07:05  *** bitconner has quit IRC
215 2018-06-28T18:08:45  *** intcat has joined #bitcoin-core-dev
216 2018-06-28T18:13:23  *** bitconner has joined #bitcoin-core-dev
217 2018-06-28T18:18:22  *** bitconner has quit IRC
218 2018-06-28T18:19:39  *** m8tion has quit IRC
219 2018-06-28T18:39:46  *** promag has joined #bitcoin-core-dev
220 2018-06-28T18:40:41  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #13461: Wallet: correctly deprecate accounts in getbalance, re-add minconf / include-watch-only (master...2018/06/watch_only_balance) https://github.com/bitcoin/bitcoin/pull/13461
221 2018-06-28T18:41:19  *** bitconner has joined #bitcoin-core-dev
222 2018-06-28T18:43:59  <bitcoin-git> [bitcoin] Empact opened pull request #13565: Fix AreInputsStandard test to reference the proper scriptPubKey (master...p2sh-tests-pub-key) https://github.com/bitcoin/bitcoin/pull/13565
223 2018-06-28T18:46:59  *** promag has quit IRC
224 2018-06-28T18:48:18  *** belcher_ has joined #bitcoin-core-dev
225 2018-06-28T18:50:21  *** Murch has quit IRC
226 2018-06-28T18:51:37  *** belcher has quit IRC
227 2018-06-28T18:58:48  *** promag has joined #bitcoin-core-dev
228 2018-06-28T19:00:56  <wumpus> #startmeeting
229 2018-06-28T19:00:56  <lightningbot> Meeting started Thu Jun 28 19:00:56 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
230 2018-06-28T19:00:56  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
231 2018-06-28T19:01:12  <achow101> hi
232 2018-06-28T19:01:17  <sipa> hi
233 2018-06-28T19:01:24  <jonasschnelli> hi
234 2018-06-28T19:01:24  <cfields> hi
235 2018-06-28T19:01:43  <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
236 2018-06-28T19:02:06  <promag> hi
237 2018-06-28T19:02:08  <kanzure> hi.
238 2018-06-28T19:02:12  <instagibbs> hi
239 2018-06-28T19:02:23  <jnewbery> half a hi. May be a little distracted for the next ~45 minutes
240 2018-06-28T19:02:37  <wumpus> I've had a really crappy week so haven't been able to do much, sorry for that
241 2018-06-28T19:02:49  <sipa> sorry to hear that
242 2018-06-28T19:02:58  <wumpus> #topic high priority for review
243 2018-06-28T19:03:42  <sipa> Currently on the list: #13425 #12196 #13062
244 2018-06-28T19:03:45  <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
245 2018-06-28T19:03:47  <cfields> wumpus: :(
246 2018-06-28T19:03:49  <gribble> https://github.com/bitcoin/bitcoin/issues/12196 | Add scantxoutset RPC method by jonasschnelli · Pull Request #12196 · bitcoin/bitcoin · GitHub
247 2018-06-28T19:03:52  <wumpus> only three PRs!
248 2018-06-28T19:03:52  <gribble> https://github.com/bitcoin/bitcoin/issues/13062 | Make script interpreter independent from storage type CScript by sipa · Pull Request #13062 · bitcoin/bitcoin · GitHub
249 2018-06-28T19:04:26  <jonasschnelli> For 12196, I'm not sure if it make sense to adopt sipas output scripts descriptors in the PR itself (or later)
250 2018-06-28T19:04:33  <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
251 2018-06-28T19:04:35  <jonasschnelli> (since it already has some reviews/acks)
252 2018-06-28T19:04:37  <gribble> https://github.com/bitcoin/bitcoin/issues/12196 | Add scantxoutset RPC method by jonasschnelli · Pull Request #12196 · bitcoin/bitcoin · GitHub
253 2018-06-28T19:05:22  <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
254 2018-06-28T19:05:27  <bitcoin-git> [bitcoin] jnewbery opened pull request #13566: Fix get balance (master...fix_get_balance) https://github.com/bitcoin/bitcoin/pull/13566
255 2018-06-28T19:05:30  *** meshcollider has joined #bitcoin-core-dev
256 2018-06-28T19:05:41  <sipa> wumpus: it's more so that we create something that remains compatible with future APIs
257 2018-06-28T19:05:48  <meshcollider> Hi
258 2018-06-28T19:06:00  <wumpus> sipa: the API will have to be finalized before the 0.17 release
259 2018-06-28T19:06:02  <sipa> (but i understand the desire to merge something; my comment would only apply to the xpub functionality)
260 2018-06-28T19:06:37  <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
261 2018-06-28T19:06:49  <sipa> perhaps i should clarify the scope
262 2018-06-28T19:06:56  <jonasschnelli> Yes. Please
263 2018-06-28T19:07:02  <sipa> my idea for output descriptors is here: https://gist.github.com/sipa/e3d23d498c430bb601c5bca83523fa82
264 2018-06-28T19:07:10  <sipa> i also have a prototype implementation for most of it
265 2018-06-28T19:07:23  <wumpus> nice!
266 2018-06-28T19:07:47  <jonasschnelli> Yes. I really like it.
267 2018-06-28T19:07:47  <promag> wumpus: for 0.17, dyn multi-wallet in the UI is required?
268 2018-06-28T19:07:51  <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
269 2018-06-28T19:07:56  <wumpus> promag: why?
270 2018-06-28T19:08:15  <promag> it's a question
271 2018-06-28T19:08:30  <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
272 2018-06-28T19:08:45  <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)
273 2018-06-28T19:08:56  <wumpus> I recognized it :)
274 2018-06-28T19:09:04  <cfields> sipa: +1, that makes a ton of sense
275 2018-06-28T19:09:11  <sipa> so import/export would operate at the level of those descriptors, instead of individual keys/scripts/pubkeys/hdchains/...
276 2018-06-28T19:09:17  *** vicenteH has quit IRC
277 2018-06-28T19:09:36  *** vicenteH has joined #bitcoin-core-dev
278 2018-06-28T19:09:40  <sipa> importmulti is already compatible with that design, for a large extent
279 2018-06-28T19:10:15  <sipa> the entirety of that idea is certainly not for 0.17, however
280 2018-06-28T19:10:46  <sipa> but that doesn't mean it can't be used already in relatively small scoped things already
281 2018-06-28T19:10:52  <sipa> and scanutxoset is one of those
282 2018-06-28T19:10:54  <jonasschnelli> what API changes would you propose for scantxoutset so we can migrate towards the output descriptors in the same cycle as migrating importmulti?
283 2018-06-28T19:11:01  <wumpus> that would be very last minute, but at least using it as a guideline to be compatible with the current stuff makes sense
284 2018-06-28T19:11:23  <sipa> jonasschnelli: you may not like this, but what about just dropping xpub support from the PR right now
285 2018-06-28T19:11:36  <jonasschnelli> sipa: this makes the PR pretty useless... :(
286 2018-06-28T19:11:42  <sipa> and then i'll PR the descriptor language, together with integration into scanutxoset
287 2018-06-28T19:12:06  <sipa> jonasschnelli: i understand
288 2018-06-28T19:12:10  <sipa> feel free to disagree
289 2018-06-28T19:12:15  <wumpus> it makes sense to divide it up like that
290 2018-06-28T19:12:18  <jonasschnelli> But if the API break would be complex and painful, we can do that.
291 2018-06-28T19:12:33  <wumpus> makes tha change smaller and less complex
292 2018-06-28T19:12:39  <jonasschnelli> I don't disagree... :)
293 2018-06-28T19:12:48  <wumpus> (besides sipa's point of course)
294 2018-06-28T19:13:11  <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?
295 2018-06-28T19:13:37  <jonasschnelli> Sure... I guess its also not utterly bad if the xpub will be in 0.18.
296 2018-06-28T19:13:47  <jonasschnelli> Okay. Will remove the xpub stuff
297 2018-06-28T19:14:03  <sipa> thank you. i promise i'll work on having a PRable implementation soon
298 2018-06-28T19:14:25  <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..
299 2018-06-28T19:14:32  <jonasschnelli> So a fixed lookup window makes more sense IMO
300 2018-06-28T19:15:15  <sipa> agree
301 2018-06-28T19:15:50  <sipa> jonasschnelli: that's actually a good point against having a gap limit inside the descriptor language
302 2018-06-28T19:15:59  <sipa> (as a gap limit is not relevant for all use cases)
303 2018-06-28T19:16:16  <jonasschnelli> gap limit is a broken concept IMO
304 2018-06-28T19:16:59  <jonasschnelli> I would not use it in the descriptors...
305 2018-06-28T19:18:06  <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
306 2018-06-28T19:18:26  <jonasschnelli> Thanks for working on this sipa. will give more feedback soon.
307 2018-06-28T19:18:32  <wumpus> any proposals for adding high-priority PRs, or rmaoving them?
308 2018-06-28T19:18:57  <wumpus> heh I already considered doing a #topic change
309 2018-06-28T19:19:04  <jonasschnelli> I have two topic requests: a) Cipherseed, b) Cores BIP32 derivation "standard"
310 2018-06-28T19:19:44  <promag> wumpus: I'll complete #13100 soon and it could go to hp list
311 2018-06-28T19:19:46  <gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add menu entry to open wallet by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
312 2018-06-28T19:20:03  <wumpus> let's add it whwen it's ready then
313 2018-06-28T19:20:07  <promag> once ready
314 2018-06-28T19:20:08  <promag> yes
315 2018-06-28T19:20:30  <wumpus> #topic cipherseed
316 2018-06-28T19:20:33  <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.
317 2018-06-28T19:20:33  <jonasschnelli> https://gist.github.com/jonasschnelli/245f35894f6ff585b3f3d33c6f208991
318 2018-06-28T19:21:22  <jonasschnelli> (its more an announcement then a topic, sry)
319 2018-06-28T19:22:06  <wumpus> #link https://gist.github.com/jonasschnelli/245f35894f6ff585b3f3d33c6f208991
320 2018-06-28T19:22:20  <wumpus> thanks for letting us know, will have a look
321 2018-06-28T19:22:34  <wumpus> right, as no one has read it, I don't think there's much to discuss now
322 2018-06-28T19:22:46  <wumpus> #topic cores BIP32 derivation "standard"
323 2018-06-28T19:22:50  <jonasschnelli> It came up today in a discussion: Cores BIP32 derivation scheme is not specified in a BIP
324 2018-06-28T19:23:12  <jonasschnelli> Some people think its vanilla/native BIP32... but its not... while other do native BIP32
325 2018-06-28T19:23:26  <jonasschnelli> I'm not sure if we should define a standard for out derivation scheme...
326 2018-06-28T19:23:34  <jonasschnelli> (would be a very short proposal)
327 2018-06-28T19:23:42  <wumpus> agree ti would be good if the difference would be documented somewhere
328 2018-06-28T19:23:46  <sipa> jonasschnelli: my thinking is that with output descriptors we can pretty much freely change it
329 2018-06-28T19:23:47  <jonasschnelli> The BIP32 based derivation scheme has that security risk
330 2018-06-28T19:24:08  <sipa> (including unhardened etc)
331 2018-06-28T19:24:44  <jonasschnelli> Changing the scheme is one point,... but there are wallets out there following a derivation scheme that is not specified in word
332 2018-06-28T19:24:47  <jonasschnelli> *words
333 2018-06-28T19:25:01  <luke-jr> how does it affect other implementations?
334 2018-06-28T19:25:03  <sipa> we could have a doc in our source tree that describes it
335 2018-06-28T19:25:22  <wumpus> luke-jr: only in the sense that other implementations might want to replicate it
336 2018-06-28T19:25:22  <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?
337 2018-06-28T19:25:31  <jonasschnelli> luke-jr: in case someone wants to import Cores xprivs...
338 2018-06-28T19:25:33  <luke-jr> wumpus: why?
339 2018-06-28T19:25:50  <wumpus> luke-jr: I don't know
340 2018-06-28T19:25:57  <luke-jr> jonasschnelli: but not import a proper wallet in entirety?
341 2018-06-28T19:26:13  <jonasschnelli> I precautionally wrote a tiny BIP,... but could also be used as an internal document: https://gist.github.com/jonasschnelli/0d383888ac51d5120540571173e35451
342 2018-06-28T19:26:20  <luke-jr> (if there were a BIP, I would think it should cover the whole wallet format, not *just* derivation)
343 2018-06-28T19:26:36  <sipa> luke-jr: saw my descriptor proposal above? :)
344 2018-06-28T19:26:45  <achow101> just documnting the derivation in the docs repo is sufficient imo
345 2018-06-28T19:26:52  <jonasschnelli> I think following BIP32 for "hot" wallets with private key export options is not ideal... Electrum does that as example
346 2018-06-28T19:27:57  <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
347 2018-06-28T19:28:08  <sipa> it's just one of many choices, and the one we made
348 2018-06-28T19:28:18  <jonasschnelli> Agree with that. Yes.
349 2018-06-28T19:28:23  <sipa> so we should just document it
350 2018-06-28T19:28:28  <jonasschnelli> ack
351 2018-06-28T19:28:54  <achow101> +1
352 2018-06-28T19:28:55  <gmaxwell> Seems good.
353 2018-06-28T19:29:22  <wumpus> agree
354 2018-06-28T19:30:36  <wumpus> I think this leaves sipa's topic, but I think that's more or less discussed already?
355 2018-06-28T19:31:10  <sipa> yeah, probably needs people reading the idea first to discuss more; can be done offline
356 2018-06-28T19:31:44  <wumpus> right
357 2018-06-28T19:31:47  <jonasschnelli> sipa: how would it interact with the keypool, flexible keypath?
358 2018-06-28T19:31:56  <jonasschnelli> and a xpub
359 2018-06-28T19:31:59  <sipa> jonasschnelli: keypool goes away
360 2018-06-28T19:32:06  <wumpus> good riddance
361 2018-06-28T19:32:35  <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
362 2018-06-28T19:32:57  <sipa> that takes the place of the keypool- but those things don't all translate to independent keys in the wallet
363 2018-06-28T19:33:06  <sipa> there would just be a single private key in your wallet, for example
364 2018-06-28T19:33:22  <sipa> (or none at all; it can be in a hardware device too)
365 2018-06-28T19:33:46  <sipa> flexible keypath... the descriptor just contains the path
366 2018-06-28T19:34:11  <sipa> you can change it to whatever you like (but default wallets would of course pick some standard scheme)
367 2018-06-28T19:34:51  <sipa> or rather you can import things with whatever path you like
368 2018-06-28T19:36:09  <wumpus> makes sense
369 2018-06-28T19:36:27  <jonasschnelli> Would it make sense that the descriptor support pkh(d34db33f/44'/0'/0':<seed>/1/i). (seed along with xpriv)?
370 2018-06-28T19:36:32  <jonasschnelli> for backward compatibility
371 2018-06-28T19:36:53  <sipa> jonasschnelli: i've thought about that, but that makes descriptors non-canonical
372 2018-06-28T19:37:06  <sipa> (as in: you can't convert them to "public" form and back, and retain all information)
373 2018-06-28T19:37:20  *** promag has quit IRC
374 2018-06-28T19:37:56  <sipa> i'm unsure how to deal with that; my thinking is initially no
375 2018-06-28T19:38:13  <sipa> you can always implement it as an extra utility that converts from seed based format
376 2018-06-28T19:38:20  <jonasschnelli> There is always the option of externally converting the seed to an xpriv, yes
377 2018-06-28T19:39:06  <jonasschnelli> we can encode seeds into xprivs *duck*
378 2018-06-28T19:39:15  *** promag has joined #bitcoin-core-dev
379 2018-06-28T19:39:44  <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.
380 2018-06-28T19:40:10  <sipa> cfields: ping?
381 2018-06-28T19:40:12  <wumpus> #topic  P2Plink ephemeral encryptio
382 2018-06-28T19:40:18  <jonasschnelli> I'm ready to pick that up any moment but was under the impression that sipa had plans to implement it
383 2018-06-28T19:40:32  <jonasschnelli> I started with the implementation but halted at some point...
384 2018-06-28T19:40:46  <jonasschnelli> I'm also not sure if we should delay it further more for "refactors"
385 2018-06-28T19:40:55  <gmaxwell> I believed sipa did too, but asformentioned delays.
386 2018-06-28T19:41:00  <cfields> heh, I was waiting on it to firm up. Guess we were waiting in circles :)
387 2018-06-28T19:41:10  <wumpus> hehe
388 2018-06-28T19:41:10  <cfields> jonasschnelli: for sure
389 2018-06-28T19:41:22  <jonasschnelli> BTW: armory has implemented it and has plans to PR it to Core
390 2018-06-28T19:41:26  <gmaxwell> Sipa and I made some major advances in the authentication part but the encryption doesn't need to wait on that.
391 2018-06-28T19:41:27  <jonasschnelli> (not sure how soon and in what quality)
392 2018-06-28T19:41:28  <sipa> cfields: waiting for encryption proposal to firm up before implementing it? or before continuing with network refactors?
393 2018-06-28T19:41:44  <wumpus> jonasschnelli: oh wow
394 2018-06-28T19:42:04  <jonasschnelli> Agree with gmaxwell. Authentication can be added later.
395 2018-06-28T19:42:22  <cfields> sipa: i've had to put the net stuff on the backburner for now, so certainly don't wait for that.
396 2018-06-28T19:42:30  <sipa> cfields: cool
397 2018-06-28T19:43:07  <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
398 2018-06-28T19:43:15  <cfields> I'm happy to help with the implementation. I was thinking we were waiting on the auth stuff.
399 2018-06-28T19:43:24  <luke-jr> jonasschnelli: it can't be Final until it is adopted..
400 2018-06-28T19:43:25  <gmaxwell> no, they're designed to operated independantly.
401 2018-06-28T19:43:31  <jonasschnelli> Auth is additional and implementation wise it comes after 151
402 2018-06-28T19:43:37  <sipa> we can implement 151 without 150
403 2018-06-28T19:43:51  <gmaxwell> I would rather not use the prior auth design, we have better ones now.
404 2018-06-28T19:43:54  <jonasschnelli> Yes. 150 can also be replaced (coexist) with other auth proposals
405 2018-06-28T19:43:59  <sipa> fair
406 2018-06-28T19:44:08  <jonasschnelli> Agree with that.
407 2018-06-28T19:44:32  <jonasschnelli> sipas prework is here AFAIK: https://gist.github.com/sipa/29118d3fcfac69f9930d57433316c039
408 2018-06-28T19:44:46  <sipa> i need to pick that up again
409 2018-06-28T19:44:50  <gmaxwell> but right, there is no need delay 151 on auth-- it's completely oblivious to auth.
410 2018-06-28T19:45:04  <jonasschnelli> I guess it uses some non-standard crypto stuff though
411 2018-06-28T19:45:25  <sipa> jonasschnelli: no, https://gist.github.com/sipa/d7dcaae0419f10e5be0270fada84c20b
412 2018-06-28T19:45:39  <jonasschnelli> Oh. Mistaken your gist. Thansk
413 2018-06-28T19:45:42  <jonasschnelli> *thanks
414 2018-06-28T19:45:45  <sipa> the other link is just some cool trick, not a serious proposal
415 2018-06-28T19:46:48  <jonasschnelli> Okay. If no one else wants to work on the implementation, I will continue then with BIP151 impl.
416 2018-06-28T19:47:08  <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.
417 2018-06-28T19:47:24  <gmaxwell> Esp since traffic patterns will identify bitcoin p2p links very clearly.
418 2018-06-28T19:47:34  <cfields> too dubious? you mean foiled by dpi anyway?
419 2018-06-28T19:47:40  <gmaxwell> And so probably better to just stick to something simple.
420 2018-06-28T19:47:47  <jonasschnelli> Agree
421 2018-06-28T19:47:55  <wumpus> hiding what kind of connection something is is very difficult
422 2018-06-28T19:48:03  <gmaxwell> cfields: foiled by traffic analysis or smarer DPI (that does EC operations to match traffic)
423 2018-06-28T19:48:09  <gmaxwell> smarter*
424 2018-06-28T19:48:35  <gmaxwell> People can always carry bitcoin over other transports in any case, ... ones that can do things like pad out to a constant bitrate...
425 2018-06-28T19:48:52  <gmaxwell> but we're certantly not going to make BIP151 do that. :P
426 2018-06-28T19:48:56  <cfields> mm, that's a good point
427 2018-06-28T19:49:24  <wumpus> which is why tor went with pluggable obfuscation layers, this for example: https://arxiv.org/pdf/1305.3199.pdf
428 2018-06-28T19:49:47  <wumpus> might be creeping the scope a bit too much
429 2018-06-28T19:50:18  <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.
430 2018-06-28T19:50:25  <gmaxwell> For 151.
431 2018-06-28T19:51:03  <jonasschnelli> You mean an obfuscation of the encryption handshake?
432 2018-06-28T19:51:13  <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.
433 2018-06-28T19:51:18  <gmaxwell> jonasschnelli: yes.
434 2018-06-28T19:52:01  <jonasschnelli> Yes. I think there is freedom to change the specs during implementation...
435 2018-06-28T19:52:04  <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.
436 2018-06-28T19:52:08  <jonasschnelli> It's not really deployed on the network yet
437 2018-06-28T19:52:51  <gmaxwell> right.
438 2018-06-28T19:53:31  <jonasschnelli> Yes. Better not obscure and put efforts in a long term solutions (stuff like the ScrambleSuit)
439 2018-06-28T19:54:13  <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.
440 2018-06-28T19:55:06  <jonasschnelli> can you elaborate a bit more on " it required message parsing to complete the handshak"?
441 2018-06-28T19:55:51  *** Dizzle has joined #bitcoin-core-dev
442 2018-06-28T19:56:18  <cfields> jonasschnelli: we can discuss after the meeting, I need to take a look at the current spec
443 2018-06-28T19:56:25  <jonasschnelli> sure. Thanks cfields
444 2018-06-28T19:59:47  <wumpus> #endmeeting
445 2018-06-28T19:59:47  <lightningbot> Meeting ended Thu Jun 28 19:59:47 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
446 2018-06-28T19:59:47  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-28-19.00.html
447 2018-06-28T19:59:47  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-28-19.00.txt
448 2018-06-28T19:59:47  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-28-19.00.log.html
449 2018-06-28T20:00:20  <sipa> lunch?
450 2018-06-28T20:01:11  <BlueMatt> sounds good
451 2018-06-28T20:01:13  <BlueMatt> wait, no, already did that
452 2018-06-28T20:01:19  <instagibbs> like 3 hours ago
453 2018-06-28T20:02:46  <jonasschnelli> irclunch?
454 2018-06-28T20:10:21  <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.
455 2018-06-28T20:10:35  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c93c360eec4d...b330f3fdd56b
456 2018-06-28T20:10:35  <bitcoin-git> bitcoin/master c2e4fc8 João Barbosa: bench: Simplify CoinSelection
457 2018-06-28T20:10:36  <bitcoin-git> bitcoin/master b330f3f MarcoFalke: Merge #13563: bench: Simplify CoinSelection...
458 2018-06-28T20:10:44  <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.
459 2018-06-28T20:11:08  <jonasschnelli> Yes. I think your right...
460 2018-06-28T20:11:25  <jonasschnelli> We should probably do a dummy handshake in advance... what would you think about that cfields?
461 2018-06-28T20:11:35  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #13563: bench: Simplify CoinSelection (master...2018-08-bench-coinselection) https://github.com/bitcoin/bitcoin/pull/13563
462 2018-06-28T20:11:42  <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)
463 2018-06-28T20:12:04  <cfields> jonasschnelli: dummy handshake?
464 2018-06-28T20:12:44  <jonasschnelli> cfields: we do a normal unencrypted version/verack handshake, .. then p2p initiator sends encinit
465 2018-06-28T20:12:51  <cfields> i only bring it up because it seems avoidable, not because it's really a big deal
466 2018-06-28T20:13:24  <jonasschnelli> A... I guess now I understand your point...
467 2018-06-28T20:13:25  * jonasschnelli thinking
468 2018-06-28T20:13:47  <cfields> jonasschnelli: i'm not following. Net would still have to be told to switch to encryption.
469 2018-06-28T20:13:59  <jonasschnelli> Yes. It's another issue...
470 2018-06-28T20:14:13  <jonasschnelli> Wouldn't it be a problem for some clients if the first package would be a pubkey?
471 2018-06-28T20:14:26  <jonasschnelli> Also,.. how would you know if the other side supports encryption?
472 2018-06-28T20:14:50  <cfields> jonasschnelli: yea, I trivialized that part for the sake of the example :)
473 2018-06-28T20:14:58  <jonasschnelli> Heh... yes.
474 2018-06-28T20:15:09  <jonasschnelli> I guess leaving out the message processor is probably hard,...
475 2018-06-28T20:15:34  <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
476 2018-06-28T20:15:55  <jonasschnelli> Assuming that non-supported message types are just ignore may be a fragile concept
477 2018-06-28T20:16:30  <jonasschnelli> (though unsure,... its probably okay)
478 2018-06-28T20:16:51  <cfields> jonasschnelli: could just send some magic before the pubkey, which would signal support and require no parsing other than an equality check.
479 2018-06-28T20:18:28  <jonasschnelli> But if you connect to a peer and send magic+33b-pubkey+cipertype, woudln't you get disconnected straight away?
480 2018-06-28T20:18:44  <jonasschnelli> (if non BIP151 supporting peer)
481 2018-06-28T20:21:02  *** d9b4bef9 has quit IRC
482 2018-06-28T20:21:08  <cfields> uhmm.. IIRC we allow more than one chance for the initial message? checking.
483 2018-06-28T20:22:15  *** d9b4bef9 has joined #bitcoin-core-dev
484 2018-06-28T20:22:20  <jonasschnelli> Also,.. not sure if we should respect other implementations.
485 2018-06-28T20:22:32  <jonasschnelli> (libbitcoin / btcd / bcoin)
486 2018-06-28T20:23:48  <luke-jr> jonasschnelli: that's a disturbing thing to say.
487 2018-06-28T20:24:13  <jonasschnelli> luke-jr: I'm only saying since there are no clear protocol specification for this
488 2018-06-28T20:24:26  *** Murch has joined #bitcoin-core-dev
489 2018-06-28T20:24:28  <jonasschnelli> (is it allow to send data before the version/verack handshake)
490 2018-06-28T20:24:48  <luke-jr> oh, I misinterpreted you I think
491 2018-06-28T20:24:48  <jonasschnelli> (then s/allowed/tolerated)
492 2018-06-28T20:25:10  <jonasschnelli> I mean ethically, we should respect them. :)
493 2018-06-28T20:25:20  *** Murch has quit IRC
494 2018-06-28T20:25:27  <cfields> haha :)
495 2018-06-28T20:25:29  <jonasschnelli> But we where talking on possible encinit p2p encryption disconnets
496 2018-06-28T20:27:21  *** Murch has joined #bitcoin-core-dev
497 2018-06-28T20:27:27  <cfields> jonasschnelli: ok, looks like we can send before version as long as the magic is correct.
498 2018-06-28T20:27:48  <cfields> but yes, that's very much an implementation detail. No clue how other clients handle it.
499 2018-06-28T20:28:10  <jonasschnelli> Yes. That sound a bit fragile...
500 2018-06-28T20:29:01  <jonasschnelli> But we could reconnect once we got disconnected after that pre-handshake encryption request and try without encryption (if unencrypted connections are allowed)
501 2018-06-28T20:30:57  *** promag has quit IRC
502 2018-06-28T20:33:53  *** rex4539 has quit IRC
503 2018-06-28T20:35:52  *** promag has joined #bitcoin-core-dev
504 2018-06-28T20:39:19  *** Victorsueca has quit IRC
505 2018-06-28T20:39:25  <cfields> jonasschnelli: mm, it's not worth going that far I think
506 2018-06-28T20:40:40  *** Victorsueca has joined #bitcoin-core-dev
507 2018-06-28T20:46:27  *** Alexandra has joined #bitcoin-core-dev
508 2018-06-28T20:46:36  <Alexandra> holaaaaa?
509 2018-06-28T20:50:23  *** Alexandra has left #bitcoin-core-dev
510 2018-06-28T20:52:02  *** Murch has quit IRC
511 2018-06-28T20:52:53  *** Murch has joined #bitcoin-core-dev
512 2018-06-28T21:05:36  <gmaxwell> jonasschnelli: we can coordinate if there is some incompatiblity.
513 2018-06-28T21:06:07  <gmaxwell> And we should avoid gratitiously breaking, where its possible without significant harm.
514 2018-06-28T21:07:01  <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.
515 2018-06-28T21:07:12  *** cbt has joined #bitcoin-core-dev
516 2018-06-28T21:10:33  <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.
517 2018-06-28T21:11:00  <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.
518 2018-06-28T21:14:13  <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.
519 2018-06-28T21:14:44  <gmaxwell> echeveria: the downside there is that now everyone's firewall deployments need to change. :(
520 2018-06-28T21:14:47  <echeveria> there's already logic for multiple bind interfaces with different properties (ie, whitebind). all this means is you gossip both of your ports.
521 2018-06-28T21:15:11  <gmaxwell> one thing we could do in a slower migration is support two ports, one is legacy or encrypted, the other is encrypted only.
522 2018-06-28T21:15:41  <gmaxwell> but I'm still skeptical that it's worth doing that.
523 2018-06-28T21:15:48  <cfields> yea, I've considered that as well. But I was afraid that we'd get too much backlash from network admin
524 2018-06-28T21:15:56  <cfields> ^^ what gmaxwell said
525 2018-06-28T21:16:00  <gmaxwell> one could, on the legacy port, hang up whenever encryption isn't used.
526 2018-06-28T21:16:15  <cfields> also, we currently penalize non-8333 I believe.
527 2018-06-28T21:16:18  <gmaxwell> that sounds silly now, but in two years when 99% of everything has BIP151 it'll be reasonable.
528 2018-06-28T21:16:27  <echeveria> cfields: that's sort of why it's ideal.
529 2018-06-28T21:16:48  <echeveria> cfields: bitcoin nodes won't ever reasonably connect to a non 8333 rumored port.
530 2018-06-28T21:16:53  <gmaxwell> the idea there being that old peers won't rumor or connect to the encrypted ones...
531 2018-06-28T21:17:01  *** d9b4bef9 has quit IRC
532 2018-06-28T21:17:21  <cfields> hmm. well I'd be all for it if we could get an idea of how many people it would piss off
533 2018-06-28T21:18:07  *** d9b4bef9 has joined #bitcoin-core-dev
534 2018-06-28T21:18:11  <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.
535 2018-06-28T21:18:27  <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.
536 2018-06-28T21:19:02  *** d9b4bef9 has quit IRC
537 2018-06-28T21:19:21  <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)
538 2018-06-28T21:19:46  <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.
539 2018-06-28T21:20:00  <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.
540 2018-06-28T21:20:09  <echeveria> yup.
541 2018-06-28T21:20:29  <cfields> yea. which I guess is exactly the net-level signal that I'm after.
542 2018-06-28T21:21:02  <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.
543 2018-06-28T21:21:15  <gmaxwell> doesn't help old peers, but we'll probably have this desire in the future.
544 2018-06-28T21:21:26  <cfields> gmaxwell: lol, we could use 18333 :)
545 2018-06-28T21:22:07  <gmaxwell> Also, I'd rather bother network admins just once when we add a UDP based transport in the future. :)
546 2018-06-28T21:22:09  *** d9b4bef9 has joined #bitcoin-core-dev
547 2018-06-28T21:22:12  <cfields> (not a serious suggestion, but it would make life a bit easier on the routing side)
548 2018-06-28T21:23:01  *** d9b4bef9 has quit IRC
549 2018-06-28T21:24:08  *** d9b4bef9 has joined #bitcoin-core-dev
550 2018-06-28T21:27:14  <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
551 2018-06-28T21:27:14  <gmaxwell> just sever the link (like an innocent network failure) and stop MITMing between that user pair.
552 2018-06-28T21:33:56  <sipa> i have
553 2018-06-28T21:34:18  <sipa> though the best we have is something that only supports one pubkey and one privkey afaik
554 2018-06-28T21:35:16  *** meshcollider has quit IRC
555 2018-06-28T21:43:59  <cfields> gmaxwell: yes, that's very cool.
556 2018-06-28T21:46:29  <cfields> sipa: thoughts on echeveria's suggestion to use a separate port?
557 2018-06-28T21:48:59  <sipa> cfields: seems a nice and easy solution, but i see the possible administrative issues
558 2018-06-28T21:49:14  <sipa> i also don't think there is that much of a problem with reconnecting
559 2018-06-28T21:50:21  <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?
560 2018-06-28T21:51:15  *** Guyver2 has quit IRC
561 2018-06-28T21:52:51  <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
562 2018-06-28T21:53:06  <cfields> gmaxwell: that's it, but it makes traffic significantly easier to handle imo
563 2018-06-28T21:54:25  <gmaxwell> cfields: how so?
564 2018-06-28T21:54:33  <cfields> sipa: (bi) always plan to reconnect to upgrade (bii) only do it if they boot us for trying
565 2018-06-28T21:57:07  <gmaxwell> I think I'm confused. AFAIK the 'boot us for trying' isn't a real problem.
566 2018-06-28T21:57:33  <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.
567 2018-06-28T21:58:03  <gmaxwell> This is perhaps a sign that our layering is faulty. :P
568 2018-06-28T21:58:20  <cfields> and this is me trying to avoid falling in the same trap again :)
569 2018-06-28T21:59:25  <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.
570 2018-06-28T21:59:26  <cfields> er... I say "net layer" and "message processing layer", but I mean those conceptually. Not our specific implementation.
571 2018-06-28T21:59:58  <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.
572 2018-06-28T22:00:30  <gmaxwell> E.g. I was thinking of echeveria's proposal as 8333 becomes legacy OR encrypted, and 8334 is encrypted only.
573 2018-06-28T22:01:31  <cfields> Ah, ok.
574 2018-06-28T22:01:40  *** Krellan has joined #bitcoin-core-dev
575 2018-06-28T22:03:23  <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.
576 2018-06-28T22:03:55  <cfields> I guess that doesn't provide much motivation to switch, though.
577 2018-06-28T22:04:13  <sipa> echo $'\x3d\x20\x53\xd7\xff\x00\x00\x00' | base64
578 2018-06-28T22:04:13  <sipa> PSBT1/8K
579 2018-06-28T22:04:20  <sipa> echo $'\x3d\x20\x53\xd7\xff\xff\xff\xff' | base64
580 2018-06-28T22:04:20  <cfields> blehk, and that would suck to rumor
581 2018-06-28T22:04:23  *** arubi has quit IRC
582 2018-06-28T22:04:29  <sipa> PSBT1/////8K
583 2018-06-28T22:04:47  *** arubi has joined #bitcoin-core-dev
584 2018-06-28T22:05:01  <sipa> so if the PSBT magic bytes are 0x3d 0x20 0x53 0xd7 0xff, the base64 encoding will always begin with "PSBT1/"
585 2018-06-28T22:10:13  *** Murch has quit IRC
586 2018-06-28T22:11:30  <sipa> or {a6 c6 ed fb ff} to encode as "psbt+/"
587 2018-06-28T22:16:09  *** Murch has joined #bitcoin-core-dev
588 2018-06-28T22:25:39  *** cbt has quit IRC
589 2018-06-28T22:30:12  *** booyah has quit IRC
590 2018-06-28T22:41:22  *** Dizzle has quit IRC
591 2018-06-28T22:50:04  *** drexl has quit IRC
592 2018-06-28T22:52:33  *** drexl has joined #bitcoin-core-dev
593 2018-06-28T22:53:12  *** Squidicuz has joined #bitcoin-core-dev
594 2018-06-28T23:14:46  *** vicenteH has quit IRC
595 2018-06-28T23:15:56  *** Victorsueca has quit IRC
596 2018-06-28T23:17:11  *** Victorsueca has joined #bitcoin-core-dev
597 2018-06-28T23:29:19  *** zautomata has joined #bitcoin-core-dev