1 2019-03-29T00:09:06  *** giesen has joined #bitcoin-core-dev
  2 2019-03-29T00:15:44  *** redj29 has joined #bitcoin-core-dev
  3 2019-03-29T00:16:15  *** redj29 has quit IRC
  4 2019-03-29T00:21:01  <achow101> sipa: how come expanding a descriptor returns a vector of scriptPubKeys? Isn't there only one possible scriptPubKey that a descriptor can return?
  5 2019-03-29T00:21:20  <sipa> achow101: combo does multiple
  6 2019-03-29T00:21:35  <achow101> ah, so that's the only descriptor that can have multiple?
  7 2019-03-29T00:21:47  <sipa> at a single position, yes
  8 2019-03-29T00:22:02  <sipa> for now (though i don't think there is any good reason to add more)
  9 2019-03-29T00:26:55  *** murchandamus has joined #bitcoin-core-dev
 10 2019-03-29T00:29:15  *** tyldis23 has joined #bitcoin-core-dev
 11 2019-03-29T00:33:28  *** Kvaciral has quit IRC
 12 2019-03-29T00:36:55  *** promag has quit IRC
 13 2019-03-29T01:10:04  *** jarthur has quit IRC
 14 2019-03-29T01:17:04  *** zhangzf has joined #bitcoin-core-dev
 15 2019-03-29T01:20:07  *** d1b15 has joined #bitcoin-core-dev
 16 2019-03-29T01:20:33  *** d1b15 has quit IRC
 17 2019-03-29T01:22:25  *** sipa has quit IRC
 18 2019-03-29T01:26:30  *** kee7a_5 has joined #bitcoin-core-dev
 19 2019-03-29T01:27:38  *** sipa has joined #bitcoin-core-dev
 20 2019-03-29T01:36:36  *** Krellan has quit IRC
 21 2019-03-29T01:41:24  *** EagleTM has quit IRC
 22 2019-03-29T01:56:32  *** mountaingoat20 has joined #bitcoin-core-dev
 23 2019-03-29T01:56:44  *** spinza has quit IRC
 24 2019-03-29T02:27:13  *** spinza has joined #bitcoin-core-dev
 25 2019-03-29T02:27:33  *** captjakk has joined #bitcoin-core-dev
 26 2019-03-29T02:30:02  *** ExtraCrispy has quit IRC
 27 2019-03-29T02:30:32  *** ExtraCrispy has joined #bitcoin-core-dev
 28 2019-03-29T02:31:42  *** captjakk has quit IRC
 29 2019-03-29T02:33:35  *** captjakk has joined #bitcoin-core-dev
 30 2019-03-29T02:37:34  *** promag has joined #bitcoin-core-dev
 31 2019-03-29T02:42:12  *** promag has quit IRC
 32 2019-03-29T03:08:09  *** roconnor has quit IRC
 33 2019-03-29T03:11:07  *** smgoller23 has joined #bitcoin-core-dev
 34 2019-03-29T03:46:16  *** tryphe has quit IRC
 35 2019-03-29T03:46:41  *** tryphe has joined #bitcoin-core-dev
 36 2019-03-29T03:50:32  *** tryphe_ has joined #bitcoin-core-dev
 37 2019-03-29T03:53:34  *** tryphe has quit IRC
 38 2019-03-29T04:04:48  *** roconnor has joined #bitcoin-core-dev
 39 2019-03-29T04:12:52  *** StopAndDecrypt_ has joined #bitcoin-core-dev
 40 2019-03-29T04:13:23  *** StopAndDecrypt has quit IRC
 41 2019-03-29T04:29:00  *** glyptographicGoa has joined #bitcoin-core-dev
 42 2019-03-29T04:33:11  *** glyptographicGoa has quit IRC
 43 2019-03-29T04:38:59  *** promag has joined #bitcoin-core-dev
 44 2019-03-29T04:43:25  *** promag has quit IRC
 45 2019-03-29T04:51:38  *** captjakk has quit IRC
 46 2019-03-29T04:52:55  *** mildly_risky has joined #bitcoin-core-dev
 47 2019-03-29T04:53:58  *** mildly_risky has quit IRC
 48 2019-03-29T04:59:22  *** dviola has quit IRC
 49 2019-03-29T05:06:07  *** niska has quit IRC
 50 2019-03-29T05:11:16  *** niska has joined #bitcoin-core-dev
 51 2019-03-29T05:30:29  *** DeanGuss has joined #bitcoin-core-dev
 52 2019-03-29T07:31:33  *** Krellan has joined #bitcoin-core-dev
 53 2019-03-29T07:36:00  *** Krellan has quit IRC
 54 2019-03-29T07:41:23  *** rex4539 has quit IRC
 55 2019-03-29T08:10:27  *** zhangzf has quit IRC
 56 2019-03-29T08:10:54  *** zhangzf has joined #bitcoin-core-dev
 57 2019-03-29T08:14:04  *** e4xit has quit IRC
 58 2019-03-29T08:14:52  *** e4xit has joined #bitcoin-core-dev
 59 2019-03-29T08:20:47  *** niska has quit IRC
 60 2019-03-29T08:26:18  *** rex4539 has joined #bitcoin-core-dev
 61 2019-03-29T08:30:31  *** niska has joined #bitcoin-core-dev
 62 2019-03-29T09:02:19  *** setpill has joined #bitcoin-core-dev
 63 2019-03-29T09:20:18  *** darosior has joined #bitcoin-core-dev
 64 2019-03-29T09:23:01  *** bitcoin-git has joined #bitcoin-core-dev
 65 2019-03-29T09:23:01  <bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9e7dc682e0f6...edc68d40e968
 66 2019-03-29T09:23:02  <bitcoin-git> bitcoin/master f6ee177 practicalswift: Remove unused AES-128 code
 67 2019-03-29T09:23:02  <bitcoin-git> bitcoin/master edc68d4 Jonas Schnelli: Merge #15663: crypto: Remove unused AES-128 code
 68 2019-03-29T09:23:15  *** bitcoin-git has left #bitcoin-core-dev
 69 2019-03-29T09:23:33  *** timothy has joined #bitcoin-core-dev
 70 2019-03-29T09:23:55  *** bitcoin-git has joined #bitcoin-core-dev
 71 2019-03-29T09:23:55  <bitcoin-git> [bitcoin] jonasschnelli merged pull request #15663: crypto: Remove unused AES-128 code (master...aes-128) https://github.com/bitcoin/bitcoin/pull/15663
 72 2019-03-29T09:23:58  *** bitcoin-git has left #bitcoin-core-dev
 73 2019-03-29T09:39:45  *** Zenton has joined #bitcoin-core-dev
 74 2019-03-29T10:07:26  *** DeanGuss has quit IRC
 75 2019-03-29T10:07:53  *** DeanGuss has joined #bitcoin-core-dev
 76 2019-03-29T10:18:49  *** spinza has quit IRC
 77 2019-03-29T10:24:55  *** spinza has joined #bitcoin-core-dev
 78 2019-03-29T10:42:16  *** rex4539 has quit IRC
 79 2019-03-29T10:45:05  *** internetworm is now known as badcc
 80 2019-03-29T10:45:08  *** badcc is now known as badccvoid
 81 2019-03-29T10:47:07  *** badccvoid has left #bitcoin-core-dev
 82 2019-03-29T10:48:08  *** badccvoid has joined #bitcoin-core-dev
 83 2019-03-29T10:58:21  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 84 2019-03-29T11:08:52  *** zhangzf has quit IRC
 85 2019-03-29T11:29:19  *** tryphe_ has quit IRC
 86 2019-03-29T11:29:46  *** tryphe_ has joined #bitcoin-core-dev
 87 2019-03-29T11:45:09  *** jonatack has joined #bitcoin-core-dev
 88 2019-03-29T11:52:43  *** darosior has quit IRC
 89 2019-03-29T11:59:32  *** Deacyde has joined #bitcoin-core-dev
 90 2019-03-29T12:14:12  *** jb55 has quit IRC
 91 2019-03-29T12:15:28  *** shesek has quit IRC
 92 2019-03-29T12:24:16  *** spinza has quit IRC
 93 2019-03-29T12:27:13  *** zhangzf has joined #bitcoin-core-dev
 94 2019-03-29T12:31:03  *** zhangzf has quit IRC
 95 2019-03-29T12:38:29  *** promag has joined #bitcoin-core-dev
 96 2019-03-29T12:39:48  *** spinza has joined #bitcoin-core-dev
 97 2019-03-29T12:41:20  *** jb55 has joined #bitcoin-core-dev
 98 2019-03-29T12:42:52  *** promag has quit IRC
 99 2019-03-29T12:45:52  *** promag has joined #bitcoin-core-dev
100 2019-03-29T12:46:39  *** rex4539 has joined #bitcoin-core-dev
101 2019-03-29T12:46:39  *** promag has quit IRC
102 2019-03-29T12:55:26  *** spaced0ut has joined #bitcoin-core-dev
103 2019-03-29T13:09:12  *** Soligor has quit IRC
104 2019-03-29T13:22:13  *** Soligor has joined #bitcoin-core-dev
105 2019-03-29T13:24:19  *** tryphe_ has quit IRC
106 2019-03-29T13:24:44  *** tryphe_ has joined #bitcoin-core-dev
107 2019-03-29T13:27:36  *** Bullitje has quit IRC
108 2019-03-29T13:30:20  *** zhangzf has joined #bitcoin-core-dev
109 2019-03-29T14:04:56  *** setpill has quit IRC
110 2019-03-29T14:22:10  *** tryphe_ has quit IRC
111 2019-03-29T14:22:38  *** tryphe_ has joined #bitcoin-core-dev
112 2019-03-29T14:23:13  *** Chris_Stewart_5 has quit IRC
113 2019-03-29T14:23:13  *** Guyver2 has joined #bitcoin-core-dev
114 2019-03-29T14:28:26  *** badccvoid is now known as asimo3089
115 2019-03-29T14:28:29  *** asimo3089 is now known as badcc
116 2019-03-29T14:28:34  *** badcc is now known as badccvoid
117 2019-03-29T14:34:06  *** saks has joined #bitcoin-core-dev
118 2019-03-29T14:41:32  *** shesek has joined #bitcoin-core-dev
119 2019-03-29T14:41:32  *** shesek has joined #bitcoin-core-dev
120 2019-03-29T14:42:14  <gkrizek> Could I get perhaps get another review on #15255. It's just a CI fix, but could probably use another look
121 2019-03-29T14:42:16  <gribble> https://github.com/bitcoin/bitcoin/issues/15255 | [tests] Remove travis_wait from lint script by gkrizek · Pull Request #15255 · bitcoin/bitcoin · GitHub
122 2019-03-29T14:49:59  *** zhangzf has quit IRC
123 2019-03-29T14:53:40  *** shesek has quit IRC
124 2019-03-29T14:54:30  *** EagleTM has joined #bitcoin-core-dev
125 2019-03-29T14:55:38  *** jonatack has quit IRC
126 2019-03-29T14:59:03  *** badccvoid is now known as badccv
127 2019-03-29T14:59:52  *** promag has joined #bitcoin-core-dev
128 2019-03-29T15:08:50  *** EagleTM has quit IRC
129 2019-03-29T15:13:58  *** Deadhand has quit IRC
130 2019-03-29T15:14:20  *** Deadhand has joined #bitcoin-core-dev
131 2019-03-29T15:22:22  *** farmerwampum_ has joined #bitcoin-core-dev
132 2019-03-29T15:22:23  *** tryphe_ has quit IRC
133 2019-03-29T15:22:34  *** tryphe_ has joined #bitcoin-core-dev
134 2019-03-29T15:24:06  *** MarcoFalke has quit IRC
135 2019-03-29T15:24:19  *** spinza has quit IRC
136 2019-03-29T15:24:22  *** MarcoFalke has joined #bitcoin-core-dev
137 2019-03-29T15:24:48  *** Ll1i1lL has quit IRC
138 2019-03-29T15:25:08  *** bitcoin-git has joined #bitcoin-core-dev
139 2019-03-29T15:25:09  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/edc68d40e968...904129b35dd6
140 2019-03-29T15:25:09  <bitcoin-git> bitcoin/master 8b8d8ee Graham Krizek: Remove travis_wait from lint script
141 2019-03-29T15:25:10  <bitcoin-git> bitcoin/master 904129b MarcoFalke: Merge #15255: [tests] Remove travis_wait from lint script
142 2019-03-29T15:25:12  *** bitcoin-git has left #bitcoin-core-dev
143 2019-03-29T15:25:13  *** farmerwampum__ has quit IRC
144 2019-03-29T15:25:13  *** luke-jr has quit IRC
145 2019-03-29T15:25:18  *** jarthur has joined #bitcoin-core-dev
146 2019-03-29T15:25:48  *** bitcoin-git has joined #bitcoin-core-dev
147 2019-03-29T15:25:48  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15255: [tests] Remove travis_wait from lint script (master...remove-travis_wait) https://github.com/bitcoin/bitcoin/pull/15255
148 2019-03-29T15:25:53  *** bitcoin-git has left #bitcoin-core-dev
149 2019-03-29T15:26:43  *** luke-jr has joined #bitcoin-core-dev
150 2019-03-29T15:27:00  *** Ll1i1lL has joined #bitcoin-core-dev
151 2019-03-29T15:27:05  *** badccv has quit IRC
152 2019-03-29T15:28:18  <gkrizek> Thanks MarcoFalke
153 2019-03-29T15:31:50  *** spinza has joined #bitcoin-core-dev
154 2019-03-29T15:36:47  *** dermoth has quit IRC
155 2019-03-29T15:44:19  *** dermoth has joined #bitcoin-core-dev
156 2019-03-29T15:49:45  *** captjakk has joined #bitcoin-core-dev
157 2019-03-29T15:52:31  *** dqx_ has joined #bitcoin-core-dev
158 2019-03-29T15:54:12  *** captjakk has quit IRC
159 2019-03-29T15:57:38  *** lnostdal has quit IRC
160 2019-03-29T15:57:53  *** lnostdal has joined #bitcoin-core-dev
161 2019-03-29T16:00:34  *** captjakk has joined #bitcoin-core-dev
162 2019-03-29T16:16:22  *** justanotheruser has quit IRC
163 2019-03-29T16:18:10  *** Urgo has joined #bitcoin-core-dev
164 2019-03-29T16:27:05  *** jnewbery has joined #bitcoin-core-dev
165 2019-03-29T16:44:38  *** qu4ku has joined #bitcoin-core-dev
166 2019-03-29T17:00:56  *** lnostdal has quit IRC
167 2019-03-29T17:01:22  *** adiabat has quit IRC
168 2019-03-29T17:04:00  *** adiabat has joined #bitcoin-core-dev
169 2019-03-29T17:05:56  *** lnostdal has joined #bitcoin-core-dev
170 2019-03-29T17:20:23  *** Zenton has quit IRC
171 2019-03-29T17:21:33  *** bitcoin-git has joined #bitcoin-core-dev
172 2019-03-29T17:21:34  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/904129b35dd6...dc5c2e440746
173 2019-03-29T17:21:35  <bitcoin-git> bitcoin/master 1c29ac4 John Newbery: [tests] style fixes in feature_pruning.py
174 2019-03-29T17:21:35  <bitcoin-git> bitcoin/master 03d6d23 John Newbery: [tests] make pruning test faster
175 2019-03-29T17:21:36  <bitcoin-git> bitcoin/master dc5c2e4 MarcoFalke: Merge #15686: [tests] make pruning test faster
176 2019-03-29T17:21:38  *** bitcoin-git has left #bitcoin-core-dev
177 2019-03-29T17:22:10  *** tryphe_ has quit IRC
178 2019-03-29T17:22:25  *** bitcoin-git has joined #bitcoin-core-dev
179 2019-03-29T17:22:25  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15686: [tests] make pruning test faster (master...2019_03_faster_pruning_test) https://github.com/bitcoin/bitcoin/pull/15686
180 2019-03-29T17:22:37  *** tryphe_ has joined #bitcoin-core-dev
181 2019-03-29T17:22:37  *** bitcoin-git has left #bitcoin-core-dev
182 2019-03-29T17:23:25  *** bitcoin-git has joined #bitcoin-core-dev
183 2019-03-29T17:23:25  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/dc5c2e440746...0baf4b1f9663
184 2019-03-29T17:23:26  <bitcoin-git> bitcoin/master 2a1408c Peter Bushnell: Comment for seemingly duplicate LIBBITCOIN_SERVER
185 2019-03-29T17:23:26  <bitcoin-git> bitcoin/master 0baf4b1 MarcoFalke: Merge #15683: Comment for seemingly duplicate LIBBITCOIN_SERVER
186 2019-03-29T17:23:27  *** owowo has quit IRC
187 2019-03-29T17:23:28  *** bitcoin-git has left #bitcoin-core-dev
188 2019-03-29T17:24:10  *** bitcoin-git has joined #bitcoin-core-dev
189 2019-03-29T17:24:10  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15683: Comment for seemingly duplicate LIBBITCOIN_SERVER (master...patch-1) https://github.com/bitcoin/bitcoin/pull/15683
190 2019-03-29T17:24:11  *** bitcoin-git has left #bitcoin-core-dev
191 2019-03-29T17:27:20  *** bitcoin-git has joined #bitcoin-core-dev
192 2019-03-29T17:27:20  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15696: [qa] test_runner: Move feature_pruning to base tests (master...1904-qaPruning) https://github.com/bitcoin/bitcoin/pull/15696
193 2019-03-29T17:27:27  *** bitcoin-git has left #bitcoin-core-dev
194 2019-03-29T17:27:30  *** jnewbery has quit IRC
195 2019-03-29T17:28:45  *** owowo has joined #bitcoin-core-dev
196 2019-03-29T17:31:46  *** jnewbery has joined #bitcoin-core-dev
197 2019-03-29T17:32:56  *** linksxxx has joined #bitcoin-core-dev
198 2019-03-29T17:41:24  *** bitcoin-git has joined #bitcoin-core-dev
199 2019-03-29T17:41:24  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #15697: qa: Make swap_magic_bytes in p2p_invalid_messages atomic (master...1904-qaMagicAtomic) https://github.com/bitcoin/bitcoin/pull/15697
200 2019-03-29T17:41:34  *** bitcoin-git has left #bitcoin-core-dev
201 2019-03-29T18:06:01  *** Sentineo has quit IRC
202 2019-03-29T18:13:34  *** obsrver has joined #bitcoin-core-dev
203 2019-03-29T18:22:11  *** tryphe_ has quit IRC
204 2019-03-29T18:22:36  *** tryphe_ has joined #bitcoin-core-dev
205 2019-03-29T18:29:20  *** bitcoin-git has joined #bitcoin-core-dev
206 2019-03-29T18:29:20  <bitcoin-git> [bitcoin] practicalswift opened pull request #15699: Remove no-op CClientUIInterface::[signal_name]_disconnect. Disconnect BlockNotifyGenesisWait and RPCNotifyBlockChange properly. (master...remove-CClientUIInterface-signal_name_disconnect) https://github.com/bitcoin/bitcoin/pull/15699
207 2019-03-29T18:29:21  *** bitcoin-git has left #bitcoin-core-dev
208 2019-03-29T18:31:55  <meshcollider> Apologies, I'm travelling to Portugal for ICPC at the moment so my timezone is completely messed up, I missed the meeting yesterday and will have to miss the wallet meeting today too if its on
209 2019-03-29T18:32:36  <meshcollider> Do people have topics they want to discuss? It should start in half an hour if my calculation is right, anyone who wants to can chair it
210 2019-03-29T18:38:19  *** qu4ku has quit IRC
211 2019-03-29T18:50:02  *** jimmysong_ has quit IRC
212 2019-03-29T19:02:01  <MarcoFalke> Doesn't seem like it :)
213 2019-03-29T19:02:31  <achow101> I have a topic, but not at computer now. Give me a few minutes
214 2019-03-29T19:03:41  *** andcoisqu has quit IRC
215 2019-03-29T19:04:43  <jnewbery> hi! I had a small topic.
216 2019-03-29T19:05:14  <jnewbery> shall I wait until achow101 is back?
217 2019-03-29T19:05:30  <sipa> i'm here, but don't have anything
218 2019-03-29T19:05:36  <sipa> let's wait
219 2019-03-29T19:10:03  <achow101> here now
220 2019-03-29T19:10:28  <jnewbery> sipa: care to chair?
221 2019-03-29T19:10:38  <sipa> #startmeeting
222 2019-03-29T19:10:38  <lightningbot> Meeting started Fri Mar 29 19:10:38 2019 UTC.  The chair is sipa. Information about MeetBot at http://wiki.debian.org/MeetBot.
223 2019-03-29T19:10:38  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
224 2019-03-29T19:10:42  <sipa> yow, topics?
225 2019-03-29T19:10:52  <jnewbery> suggested topic: rebroadcast behaviour
226 2019-03-29T19:10:55  <instagibbs> hmm calendar is off by a week, here
227 2019-03-29T19:11:29  <jnewbery> instagibbs: it was delayed by a week during FC and didn't revert
228 2019-03-29T19:12:05  <achow101> suggested topic: non-hardened derivation paths
229 2019-03-29T19:12:12  <sipa> #topic rebroadcast behaviour
230 2019-03-29T19:12:51  <instagibbs> I see we finally have rebroadcast tests :)
231 2019-03-29T19:13:01  <jnewbery> I've been looking at wallet rebroadcasts. The current behaviour is: set a timer for random (0, 30). When it pops rebroadcast all unconfirmed wallet txs. Set timer again.
232 2019-03-29T19:13:15  *** DeanGuss has quit IRC
233 2019-03-29T19:13:25  <sipa> but only if there has been a new block since the previous rebroadcast?
234 2019-03-29T19:13:29  <jnewbery> (it's not quite as bad as that because each peer has a bloom filter so we won't actually rebroadcast until it's been purged from there)
235 2019-03-29T19:13:35  <jnewbery> ah yes, as long as there's been a block
236 2019-03-29T19:13:44  <jnewbery> I have a couple of suggested changes
237 2019-03-29T19:14:03  <jnewbery> 1. separate the scheduling, so each tx is on its own timer, instead of sending them all at once
238 2019-03-29T19:14:28  <jnewbery> 2. have the wallet remember some number of random txs it sees from the mempool, and add those to its rebroadcast list as decoys
239 2019-03-29T19:14:43  <jnewbery> wanted to get some concept feedback on those before I started coding up
240 2019-03-29T19:15:16  <sipa> so (1) is problematic if there are interdependent unconfirmed transactions in your wallet
241 2019-03-29T19:15:31  <sipa> as you may end up sending a child to a different peer than the parent
242 2019-03-29T19:15:35  <sipa> gmaxwell: opinions? ^
243 2019-03-29T19:16:01  <jnewbery> in (1), I'd think we'd still send each tx to all peers
244 2019-03-29T19:16:08  <sipa> oh!
245 2019-03-29T19:16:18  <jnewbery> just not all at the same time
246 2019-03-29T19:16:28  <instagibbs> trickle rather than flood
247 2019-03-29T19:16:38  <sipa> right, but you may send the child before the parent
248 2019-03-29T19:16:58  <sipa> (they get sorted in the broadcast buffer before actual sending, but that's just a few-seconds timer)
249 2019-03-29T19:17:29  <sipa> i don't know whether the rebroadcast mechanism in the wallet currently actually cares about that
250 2019-03-29T19:17:39  <jnewbery> I think it doesn't, but I'd have to recheck
251 2019-03-29T19:17:55  <sipa> yeah, but if it sends all unconfirmed txn, they'll get sorted before broadcast
252 2019-03-29T19:18:05  <jnewbery> oh, where does that happen?
253 2019-03-29T19:18:30  <sipa> sendmessages
254 2019-03-29T19:19:29  <sipa> there's a poisson distributed per-peer timer (but simultaneous for all inbound connections) that flushes a buffer of to-be-broadcast txn
255 2019-03-29T19:20:00  <jnewbery> yeah, I see it now
256 2019-03-29T19:20:05  <sipa> and it sorted first by dependency order and then lexicographically
257 2019-03-29T19:20:09  <sipa> *sorts
258 2019-03-29T19:20:37  <sipa> so if you announce an txid within a few seconds of each other, there's a high chance they'll end up being sorted correctly before actual broadcast
259 2019-03-29T19:20:44  <jnewbery>  // Topologically and fee-rate sort the inventory we send for privacy and priority reasons.
260 2019-03-29T19:20:51  <sipa> yeah, that
261 2019-03-29T19:21:00  <sipa> oh yes, feerate; not lexicographically
262 2019-03-29T19:21:10  <gmaxwell> (1) could consider only the deepest ancestors and announce all the parents at once.
263 2019-03-29T19:21:19  <gmaxwell> ignoring the details (1) sounds like a very important improvement.
264 2019-03-29T19:22:12  *** tryphe_ has quit IRC
265 2019-03-29T19:22:29  <jnewbery> is the wallet aware of dependencies in its transactions?
266 2019-03-29T19:22:33  <sipa> yes
267 2019-03-29T19:22:37  *** tryphe_ has joined #bitcoin-core-dev
268 2019-03-29T19:22:49  <gmaxwell> er only the deepest children.
269 2019-03-29T19:24:02  *** captjakk has quit IRC
270 2019-03-29T19:24:08  <gmaxwell> (2) I don't have a problem with but I think the benefit is a bit dubious, like random txn by itself very likely provides no privacy improvement, because only the real sender or recipent will send txn for all of a single address/linked address consistently.   It's sometimes hard to tell where the line is between snake oil that just adds complexity to the codebase for no protection against an
271 2019-03-29T19:24:09  <gmaxwell> even slightly incompetent attacker, vs fuzzing things up in a way that provides incremental privacy even though far from perfect
272 2019-03-29T19:24:18  <sipa> jnewbery: mapTxSpends
273 2019-03-29T19:24:22  *** Sentineo has joined #bitcoin-core-dev
274 2019-03-29T19:24:27  <gmaxwell> I would think though that matching random addresses would be a lot better than random txn.
275 2019-03-29T19:25:16  <gmaxwell> I think a (3) avoiding pointles retransmissions would be more helpful.  But I would happily review an implementation of (2), reservations aside.
276 2019-03-29T19:25:31  <jnewbery> Do we know what percentage of txs are re-used addresses? And what number of those re-used addresses have multiple unconfirmed txs at the same time?
277 2019-03-29T19:25:59  <gmaxwell> jnewbery: 'most' (I expect sipa will provide some numbers) But it's not just a same time question:
278 2019-03-29T19:26:04  <sipa> jnewbery: also, poisson distributed rebroadcast events are probably more private than uniform distributed ones
279 2019-03-29T19:26:24  <gmaxwell> what I think it should do is per node pick a random value (e.g. the addr man randomizer) and use that to consistently select some small portion of addresses to rebroadcast.
280 2019-03-29T19:26:42  <gmaxwell> so that over months of time we're consisently rebroadcasting the same other addresses.
281 2019-03-29T19:26:47  *** captjakk has joined #bitcoin-core-dev
282 2019-03-29T19:26:57  *** spaced0ut has quit IRC
283 2019-03-29T19:27:12  <gmaxwell> Yeah uniform leaks information that possion doesn't, possion is the distribution you get from memoryless processes.
284 2019-03-29T19:27:27  *** captjakk has joined #bitcoin-core-dev
285 2019-03-29T19:27:53  <jnewbery> if you're talking about months of time, then presumably you'd need to save this to disk
286 2019-03-29T19:28:08  <sipa> the addrman randomizer is stored on disk
287 2019-03-29T19:28:20  <gmaxwell> Thats why I specified that one.
288 2019-03-29T19:28:37  <jnewbery> So you're saying this behaviour should live in the node rather than the wallet?
289 2019-03-29T19:28:47  <sipa> wallet is easier i think
290 2019-03-29T19:29:01  <gmaxwell> also if you wipe out your peers.day because you're trying to avoid addrman based fingerprinting then you'll also wipe rebroadcast fingerprinting.
291 2019-03-29T19:29:01  <jnewbery> the wallet isn't aware of peers
292 2019-03-29T19:29:06  <gmaxwell> I think nodes without wallets should d this too.
293 2019-03-29T19:29:07  <sipa> but it would possibly result in identifiable behavior that can be detected if a wallet file moves to another node
294 2019-03-29T19:29:23  <gmaxwell> because there are many walletless nodes that would provide cover...
295 2019-03-29T19:29:41  <gmaxwell> maybe thats not realistic for engineering reasons. ::shrugs:: I'm just talking spherical cows here.
296 2019-03-29T19:30:16  <gmaxwell> In any case, if it isn't consistent like this, it's really obvious to me how attackers will filter it out. Monitor, and look for dispositive failures to rebroadcast. The real source won't have them, the fake sources will.
297 2019-03-29T19:30:19  <jnewbery> I think the implementation can be quite minimal if the wallet just keeps its own list of txs and doesn't try to distinguish behaviour between peers
298 2019-03-29T19:30:53  <gmaxwell> and given someone that already has network wide monitoring that filtering is probably only a dozen lines of code/query.
299 2019-03-29T19:31:13  <jnewbery> are you saying genuine wallet rebroadcasts should also be to only one peer?
300 2019-03-29T19:31:40  <jnewbery> because if its to all peers that's different behaviour than decoy rebroadcasts and would be easy to spot
301 2019-03-29T19:32:07  <gmaxwell> no, both should be to all peers.
302 2019-03-29T19:32:33  <jnewbery> then I've misunderstood your 'per node' comment above
303 2019-03-29T19:33:05  <gmaxwell> jnewbery: my node being different from yours.
304 2019-03-29T19:33:18  <jnewbery> ok
305 2019-03-29T19:33:19  <gmaxwell> I prefer to rebroadcast 1apple you prefer to rebroadcast 1spatula.
306 2019-03-29T19:33:25  <jnewbery> yep
307 2019-03-29T19:33:34  <gmaxwell> and if I restart I still prefer 1apple.
308 2019-03-29T19:33:54  <gmaxwell> so an attacker can't tell if I like 1apple's addresses because of my random number or because I am 1apple.
309 2019-03-29T19:34:16  *** bitcoin-git has joined #bitcoin-core-dev
310 2019-03-29T19:34:16  <bitcoin-git> [bitcoin] promag opened pull request #15700: rfc: Synchronize validation interface registration (master...2019-03-sync-validation-interface-registration) https://github.com/bitcoin/bitcoin/pull/15700
311 2019-03-29T19:34:17  *** bitcoin-git has left #bitcoin-core-dev
312 2019-03-29T19:34:34  <sipa> so what if the address you pick for rebroadcasts suddenly gets a ton of transactions
313 2019-03-29T19:34:52  <gmaxwell> sipa: well you're going to relay them on the network regardless.
314 2019-03-29T19:35:00  <gmaxwell> So I don't think thats actually a major cost?
315 2019-03-29T19:35:41  <sipa> ah right, if it's per node they'd just be broadcast from the mempool directly; no need to copy/store them elsewhere
316 2019-03-29T19:36:10  <sipa> though you do need to keep track of txn that spend outputs assigned to the addresses you've chosen
317 2019-03-29T19:36:33  <sipa> but that could just be a boolean per-tx i guess
318 2019-03-29T19:37:34  <gmaxwell> right. all these considerations is why I'm a little dubious. I think the simplest version does little to nothing. And I'm not sure of the bound of the complexity on an effort to really be indistinguishable. I mean mean one way would be to effectively importaddress on random addresses you see with a flag to hide them in the wallet but implemented that way would have too many DOS potentials.
319 2019-03-29T19:38:06  <gmaxwell> it would, however, have a pretty strong guarentee that you'd treat them the same, making them very hard to distinguish.
320 2019-03-29T19:38:18  <gmaxwell> though it would also only work if you have a wallet.
321 2019-03-29T19:38:49  <jnewbery> I think just selecting random txs is surely better than little to nothing
322 2019-03-29T19:39:04  <sipa> another approach is having the rebroadcast mechanism be purely in the node, and have it mark some subset of transactions... but then have the wallet forcibly set that mark on its own transactions too
323 2019-03-29T19:39:15  *** owowo has quit IRC
324 2019-03-29T19:39:20  <sipa> but the wallet doesn't do the rebroadcasting
325 2019-03-29T19:40:22  <gmaxwell> jnewbery: I think any existing deanon attackers can filter out random tx rebroadcasts fairly reliably with a line of code, maybe its still worth doing. We have other paper thin privacy mechenisms (e.g. most of the node anti-fingerprinting).
326 2019-03-29T19:41:08  <jnewbery> but if they're random, some of them will be for addresses that aren't re-used. How would the attacked filter those out?
327 2019-03-29T19:41:27  *** owowo has joined #bitcoin-core-dev
328 2019-03-29T19:42:52  <gmaxwell> jnewbery: A couple ways: for rebroadcast purposes every coin that isn't lost is reused, since senders and recipents both rebroadcast. Also even when addresses aren't reused, they're co-used in inputs with other transactions. So broadcasting of the complete address cluster is also a fairly strong hurestic.
329 2019-03-29T19:43:28  <gmaxwell> I think you've convinced me that in at least some cases it would be indistinguishable.
330 2019-03-29T19:43:46  <jnewbery> Many txs don't get rebroadcast at all and are confirmed in the next block
331 2019-03-29T19:43:53  <gmaxwell> e.g. one side of send/recieve doesn't need any rebroadcast, no reuse, no useful information from clustering.
332 2019-03-29T19:44:28  <jnewbery> Right. An attacker can't tell if you would have rebroadcast
333 2019-03-29T19:44:59  <gmaxwell> (thats also, aside, a reason rebroadcasts should be possion timed)
334 2019-03-29T19:45:03  <sipa> maybe we should move to achow101's topic?
335 2019-03-29T19:45:15  *** saks has quit IRC
336 2019-03-29T19:45:32  <jnewbery> I don't think I need anything else on this for now. Thanks for the input!
337 2019-03-29T19:45:56  <achow101> I've started working native descriptor wallets and I just wanted some opinions on some parts of the design.
338 2019-03-29T19:46:05  <sipa> cool
339 2019-03-29T19:46:27  <sipa> #topic non-hardened derivation paths
340 2019-03-29T19:46:51  <achow101> right now I have the wallet make 6 descriptors, in pairs of 3. each pair has an internal and external descriptor, and each pair for each of the address types
341 2019-03-29T19:47:14  <sipa> makes sense
342 2019-03-29T19:47:20  <achow101> it uses derivation paths that we currently use in the wallet, but I think it would be better if we used bip 44/49/89
343 2019-03-29T19:47:51  <achow101> thoughts? it would mean that we use non-hardened derivation paths
344 2019-03-29T19:47:53  <sipa> i think using non-hardened derivation paths is fine if there is no way to export the individual private keys
345 2019-03-29T19:48:29  <gmaxwell> I think it's necessary to disable key export on anything non-hardened.
346 2019-03-29T19:48:35  <achow101> as it is now, we need to have a new seed for each address type or we'll end up using keys accidentally
347 2019-03-29T19:48:56  <achow101> I think that the only export that will be possible is exporting the entire private descriptor itself
348 2019-03-29T19:48:57  <sipa> achow101: you would certainly use distinct paths for each of the address types
349 2019-03-29T19:49:03  <sipa> achow101: agree
350 2019-03-29T19:49:10  <gmaxwell> Also, I don't think we should be defaulting to using non-hardened unless we're actually making real use of its abilityies (like to cogenerate addresses with an external signer).
351 2019-03-29T19:49:13  <achow101> i'll be disabling dumpprivkey and all of the imports for descriptor wallets
352 2019-03-29T19:50:08  <sipa> gmaxwell: it also has the advantage of not needing to decrypt the wallet to generate more addresses
353 2019-03-29T19:50:26  <gmaxwell> so generate 100,000 addresses the first go. :)
354 2019-03-29T19:50:44  <gmaxwell> it's a lot of fragility to save a megabyte of file size. :P
355 2019-03-29T19:50:46  <achow101> gmaxwell: it has the advantage of making the wallet file extremely small
356 2019-03-29T19:51:16  <gmaxwell> the wallet file grows from transactions regardless. if you're actually using addresses it'll get big.
357 2019-03-29T19:51:50  <sipa> anyway, i think it certainly makes sense to support nonhardened derivation
358 2019-03-29T19:51:58  <gmaxwell> Sure.
359 2019-03-29T19:52:05  <achow101> right now the thing I don't like is that it needs 3 different seeds, one for each address type
360 2019-03-29T19:52:28  <sipa> achow101: that shouldn't be needed; you can use distinct derivation paths even when using hardened?
361 2019-03-29T19:52:46  <gmaxwell> as far as making wallets small, that I think is mostly interesting for backups, and for that it might be best to have tools/rpcs that strips wallets for backup purposes.
362 2019-03-29T19:52:52  <achow101> sipa: yes, but I don't really like having to introduce yet another set of derivation paths that people have to consider
363 2019-03-29T19:53:00  <achow101> vs. using existing standards
364 2019-03-29T19:53:15  *** timothy has quit IRC
365 2019-03-29T19:53:22  <sipa> achow101: that's why you encode it as a descriptor; it's universal :)
366 2019-03-29T19:53:41  <sipa> but sure- i agree at a high level it's unnecessary to introduce new standards when existing ones exist
367 2019-03-29T19:54:01  <sipa> the question is whether hardened or unhardened is more desirable - i don't know, and it may depend on the situation
368 2019-03-29T19:54:07  <gmaxwell> This is just broken.
369 2019-03-29T19:54:23  <achow101> ?
370 2019-03-29T19:54:47  <gmaxwell> 'existing standards' were made by people considering entirely different use cases and deployment enviroments (hardware wallets)
371 2019-03-29T19:55:17  <gmaxwell> and with a different focus on security (a lot closer to 'who cares')
372 2019-03-29T19:55:32  <sipa> well when we'd use a nonhardened derivation (for external reasons) it makes sense to follow those standards
373 2019-03-29T19:55:46  <sipa> the question remains whether or not to use hardened or not
374 2019-03-29T19:55:58  *** DeanGuss has joined #bitcoin-core-dev
375 2019-03-29T19:56:00  <gmaxwell> sipa: it might, if it is otherwise fine and would actually result in some kind of useful compatibility.
376 2019-03-29T19:56:33  <gmaxwell> like we'll never be compatible with electrum (say) by using the same path, simply because we generate parllel native and compatibility addresses.
377 2019-03-29T19:56:54  <achow101> gmaxwell: the plan for descriptor wallets is not generate them in parallel
378 2019-03-29T19:57:15  <achow101> each address type will have it's own derivation path base
379 2019-03-29T19:57:48  <sipa> yeah, so your bitcoin core wallet will correspond to a union of several things that are (possibly) compatible with an electrum wallet individually
380 2019-03-29T19:58:55  <gmaxwell> a wallet where you can recover part of the funds and the rest are just invisibly lost isn't compatible though, if anything its a liability.
381 2019-03-29T19:59:13  <sipa> right
382 2019-03-29T20:00:42  <achow101> anywys, it seems like the preference is to use hardened
383 2019-03-29T20:01:11  <gmaxwell> Generally thats my strong preference, except in cases where there is a 'application layer' gain from otherwise.
384 2019-03-29T20:01:43  <gmaxwell> Not just some 'its easier to write this way' or 'wallet file is somewhat smaller for unspecified benenfits'
385 2019-03-29T20:02:43  <sipa> seems we're out of time
386 2019-03-29T20:03:05  <gmaxwell> I really regret ever coming up with public derrivation and wish I could take it back,  The original application I had for it is still unavailable to people (so your web server could securely generate fresh addresses for you) in practice... and it gets applied *everywhere* simply because reusing a key is simpler to implement.
387 2019-03-29T20:03:26  <achow101> well that's all I had for today. there was something else I wanted to discuss, but I don't remember what that was
388 2019-03-29T20:03:40  <achow101> so clearly it wasn't very important
389 2019-03-29T20:04:19  <gmaxwell> .. and its resulted in funds loss, and it also results in expectations we won't be able to support for post ECC keys.
390 2019-03-29T20:04:46  <sipa> #endmeeting
391 2019-03-29T20:04:46  <lightningbot> Meeting ended Fri Mar 29 20:04:46 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
392 2019-03-29T20:04:46  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-29-19.10.html
393 2019-03-29T20:04:46  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-29-19.10.txt
394 2019-03-29T20:04:46  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-03-29-19.10.log.html
395 2019-03-29T20:05:57  <achow101> gmaxwell: well it's been useful for hardwre wallets. asking a hardware wallet for a few thousand keys is not exactly a fun time
396 2019-03-29T20:06:14  *** Krellan has joined #bitcoin-core-dev
397 2019-03-29T20:07:05  <gmaxwell> achow101: yes, though really that isn't at all fundimental.
398 2019-03-29T20:07:31  <gmaxwell> like if it didn't exist, hardware wallets would just cost $5 have a 10x faster cpu, and a faster interface, and no one would notice otherwise.
399 2019-03-29T20:07:44  <gmaxwell> (or alternatively they'd just support a single address... :P)
400 2019-03-29T20:07:51  <gmaxwell> er cost $5 more
401 2019-03-29T20:08:48  <gmaxwell> I also agree that they're not terribly bad for the hardware wallet case.  That isn't really all that different from the orignal 'webserver' usecase, except your wallet is the webserver.
402 2019-03-29T20:09:31  <gwillen> this is more generally the "not having to expose your private key in more places than necessary" usecase, which seems laudable
403 2019-03-29T20:10:04  <gmaxwell> though also the security of generating addresse on an untrusted device is kinda dubious. eventually the bad guys will have taken all the low hanging fruit and the next set of attacks will just be to make createnewaddress like interfaces return attacker addresses. :P
404 2019-03-29T20:10:08  <gwillen> although due to not trusting software, these days I always check new addresses against each other on both machines anyway
405 2019-03-29T20:10:11  <gwillen> yeah
406 2019-03-29T20:10:37  <gwillen> you could very well generate new addresses independently in parallel on multiple devices and check them that way
407 2019-03-29T20:10:41  <gwillen> with none of them being the private device
408 2019-03-29T20:10:45  <gwillen> but ain't nobody got time for that
409 2019-03-29T20:11:20  <gmaxwell> gwillen: there are goals in conflict, "reuse private keys" = bad. "use keys too much" =bad.  Essentially all non-hardened keys share the same private key, so it's reuse of a private key.
410 2019-03-29T20:11:41  <gmaxwell> gwillen: indeed.
411 2019-03-29T20:13:44  <gwillen> reuse of private keys being bad seems very implementation- and UX-specific somehow
412 2019-03-29T20:14:13  <gwillen> like, if you treat it as "a series of addresses generated by a single master key, there are no separate individual keys and the software will never give you such a thing" then you mitigate the user-confusion issue
413 2019-03-29T20:20:36  *** jonatack has joined #bitcoin-core-dev
414 2019-03-29T20:22:12  *** tryphe_ has quit IRC
415 2019-03-29T20:22:39  *** tryphe_ has joined #bitcoin-core-dev
416 2019-03-29T20:22:59  *** dviola has joined #bitcoin-core-dev
417 2019-03-29T20:38:00  *** StopAndDecrypt has joined #bitcoin-core-dev
418 2019-03-29T20:38:09  *** StopAndDecrypt has quit IRC
419 2019-03-29T20:38:10  *** StopAndDecrypt has joined #bitcoin-core-dev
420 2019-03-29T20:38:54  *** StopAndDecrypt_ has quit IRC
421 2019-03-29T20:39:51  *** obsrver has quit IRC
422 2019-03-29T20:49:55  *** dviola has quit IRC
423 2019-03-29T20:54:08  *** harrymm has joined #bitcoin-core-dev
424 2019-03-29T21:17:24  *** belcher has quit IRC
425 2019-03-29T21:18:46  *** e4xit has quit IRC
426 2019-03-29T21:22:11  *** tryphe_ has quit IRC
427 2019-03-29T21:22:39  *** tryphe_ has joined #bitcoin-core-dev
428 2019-03-29T21:23:13  *** e4xit has joined #bitcoin-core-dev
429 2019-03-29T21:38:02  *** Zenton has joined #bitcoin-core-dev
430 2019-03-29T21:43:22  *** bitcoin-git has joined #bitcoin-core-dev
431 2019-03-29T21:43:22  <bitcoin-git> [bitcoin] jnewbery closed pull request #15010: [wallet] Fix getbalance with minconf (master...fix_getbalance_with_minconf) https://github.com/bitcoin/bitcoin/pull/15010
432 2019-03-29T21:43:33  *** bitcoin-git has left #bitcoin-core-dev
433 2019-03-29T21:43:38  *** mn94958851 has joined #bitcoin-core-dev
434 2019-03-29T21:43:38  *** mn94958856 has joined #bitcoin-core-dev
435 2019-03-29T21:43:38  *** mn9495882 has joined #bitcoin-core-dev
436 2019-03-29T21:47:08  *** mn9495881 has quit IRC
437 2019-03-29T21:47:22  *** mn94958855 has quit IRC
438 2019-03-29T21:47:22  *** mn949588 has quit IRC
439 2019-03-29T21:54:45  *** DeanGuss has quit IRC
440 2019-03-29T22:04:32  *** zivl has joined #bitcoin-core-dev
441 2019-03-29T22:06:07  *** Guyver2 has quit IRC
442 2019-03-29T22:17:20  *** justanotheruser has joined #bitcoin-core-dev
443 2019-03-29T22:20:04  <achow101> sipa: how come ExpandFromCache returns ExpandHelper(..) == 0 ? Seems like a bug to me
444 2019-03-29T22:21:17  <achow101> oh, nvm. I misread part of it
445 2019-03-29T22:22:13  *** tryphe_ has quit IRC
446 2019-03-29T22:22:39  *** tryphe_ has joined #bitcoin-core-dev
447 2019-03-29T22:25:59  *** bitcoin-git has joined #bitcoin-core-dev
448 2019-03-29T22:25:59  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/0baf4b1f9663...00ca24b68fc4
449 2019-03-29T22:26:00  <bitcoin-git> bitcoin/master 1111f07 MarcoFalke: test: .style.yapf: Set column_limit=160
450 2019-03-29T22:26:00  <bitcoin-git> bitcoin/master 00ca24b MarcoFalke: Merge #15533: test: .style.yapf: Set column_limit=160
451 2019-03-29T22:26:11  *** bitcoin-git has left #bitcoin-core-dev
452 2019-03-29T22:26:45  *** bitcoin-git has joined #bitcoin-core-dev
453 2019-03-29T22:26:45  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15533: test: .style.yapf: Set column_limit=160 (master...1903-testNoPep8Collim) https://github.com/bitcoin/bitcoin/pull/15533
454 2019-03-29T22:26:46  *** bitcoin-git has left #bitcoin-core-dev
455 2019-03-29T22:28:03  *** bitcoin-git has joined #bitcoin-core-dev
456 2019-03-29T22:28:03  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/00ca24b68fc4...79c345a0114c
457 2019-03-29T22:28:04  <bitcoin-git> bitcoin/master afc06fc Torkel Rogstad: rpc: Fix help text for signtransactionwithXXX
458 2019-03-29T22:28:04  <bitcoin-git> bitcoin/master 79c345a MarcoFalke: Merge #15669: rpc: Fix help text for signtransactionwithXXX
459 2019-03-29T22:28:06  *** bitcoin-git has left #bitcoin-core-dev
460 2019-03-29T22:28:53  *** bitcoin-git has joined #bitcoin-core-dev
461 2019-03-29T22:28:53  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15669: rpc: Fix help text for signtransactionwithXXX (master...signrawtx-rpc-help) https://github.com/bitcoin/bitcoin/pull/15669
462 2019-03-29T22:28:54  *** bitcoin-git has left #bitcoin-core-dev
463 2019-03-29T22:29:24  *** jnewbery has quit IRC
464 2019-03-29T22:36:03  *** dqx__ has joined #bitcoin-core-dev
465 2019-03-29T22:38:56  *** dqx_ has quit IRC
466 2019-03-29T22:43:58  *** spinza has quit IRC
467 2019-03-29T22:49:58  *** spinza has joined #bitcoin-core-dev
468 2019-03-29T22:58:00  *** passedpawn has joined #bitcoin-core-dev
469 2019-03-29T23:02:15  *** passedpawn has quit IRC
470 2019-03-29T23:03:54  *** ctrlbreak_MAD has joined #bitcoin-core-dev
471 2019-03-29T23:07:30  *** ctrlbreak has quit IRC
472 2019-03-29T23:22:04  *** tryphe_ has quit IRC
473 2019-03-29T23:22:32  *** tryphe_ has joined #bitcoin-core-dev
474 2019-03-29T23:23:57  *** captjakk has quit IRC
475 2019-03-29T23:24:13  *** schmidty has quit IRC
476 2019-03-29T23:28:31  *** tryphe_000 has joined #bitcoin-core-dev
477 2019-03-29T23:31:46  *** tryphe_ has quit IRC
478 2019-03-29T23:41:36  *** tryphe has joined #bitcoin-core-dev
479 2019-03-29T23:42:07  *** tryphe_000 has quit IRC
480 2019-03-29T23:46:43  *** tryphe has quit IRC
481 2019-03-29T23:48:19  *** tryphe has joined #bitcoin-core-dev