1 2016-12-15T00:02:30  *** TomMc has quit IRC
  2 2016-12-15T00:03:02  *** Chris_Stewart_5 has quit IRC
  3 2016-12-15T00:20:49  *** kalle__ has joined #bitcoin-core-dev
  4 2016-12-15T00:21:58  *** kalle__ is now known as kallle
  5 2016-12-15T00:29:56  *** alpalp has joined #bitcoin-core-dev
  6 2016-12-15T00:29:56  *** alpalp has joined #bitcoin-core-dev
  7 2016-12-15T00:34:25  *** dermoth_ has joined #bitcoin-core-dev
  8 2016-12-15T00:34:51  *** dermoth has quit IRC
  9 2016-12-15T00:34:53  *** dermoth_ is now known as dermoth
 10 2016-12-15T00:50:40  *** _biO_ has quit IRC
 11 2016-12-15T01:05:18  *** wasi has joined #bitcoin-core-dev
 12 2016-12-15T01:17:09  *** MarcoFalke has quit IRC
 13 2016-12-15T01:29:53  *** TomMc has joined #bitcoin-core-dev
 14 2016-12-15T01:38:06  *** calcyss has joined #bitcoin-core-dev
 15 2016-12-15T01:54:58  *** abpa has quit IRC
 16 2016-12-15T01:57:22  *** Ylbam has quit IRC
 17 2016-12-15T02:00:21  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 18 2016-12-15T02:03:40  *** calcyss has quit IRC
 19 2016-12-15T02:14:26  <bitcoin-git> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/b68685a16a81...b83264d9c7a8
 20 2016-12-15T02:14:27  <bitcoin-git> bitcoin/master c9e69fb Jeremy Rubin: Add CuckooCache implementation and replace the sigcache map_type with it...
 21 2016-12-15T02:14:27  <bitcoin-git> bitcoin/master 67dac4e Jeremy Rubin: Add unit tests for the CuckooCache...
 22 2016-12-15T02:14:28  <bitcoin-git> bitcoin/master b83264d Pieter Wuille: Merge #8895: Better SigCache Implementation...
 23 2016-12-15T02:20:21  *** windsok has quit IRC
 24 2016-12-15T02:26:10  *** TomMc has quit IRC
 25 2016-12-15T02:36:55  *** windsok has joined #bitcoin-core-dev
 26 2016-12-15T02:44:37  *** Chris_Stewart_5 has quit IRC
 27 2016-12-15T02:55:41  *** alpalp has quit IRC
 28 2016-12-15T03:01:53  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 29 2016-12-15T03:03:09  *** abpa has joined #bitcoin-core-dev
 30 2016-12-15T03:04:08  *** d9b4bef9 has joined #bitcoin-core-dev
 31 2016-12-15T03:08:01  *** alpalp has joined #bitcoin-core-dev
 32 2016-12-15T03:08:01  *** alpalp has joined #bitcoin-core-dev
 33 2016-12-15T03:18:13  *** wvr has quit IRC
 34 2016-12-15T03:26:50  *** PRab has joined #bitcoin-core-dev
 35 2016-12-15T03:27:03  *** PRab_ has joined #bitcoin-core-dev
 36 2016-12-15T03:29:57  *** PRab_ has quit IRC
 37 2016-12-15T03:29:57  *** PRab has quit IRC
 38 2016-12-15T03:30:44  *** PRab has joined #bitcoin-core-dev
 39 2016-12-15T03:31:47  *** PRab has joined #bitcoin-core-dev
 40 2016-12-15T03:32:18  *** PRab_ has joined #bitcoin-core-dev
 41 2016-12-15T03:32:51  *** PRab has left #bitcoin-core-dev
 42 2016-12-15T03:34:03  *** PRab_ is now known as PRab
 43 2016-12-15T03:37:22  *** PRab has quit IRC
 44 2016-12-15T03:37:52  *** PRab has joined #bitcoin-core-dev
 45 2016-12-15T03:38:07  *** PRab_ has joined #bitcoin-core-dev
 46 2016-12-15T03:39:15  *** Chris_Stewart_5 has quit IRC
 47 2016-12-15T03:41:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 48 2016-12-15T03:48:56  *** mr_burdell has quit IRC
 49 2016-12-15T03:49:05  *** mr_burdell has joined #bitcoin-core-dev
 50 2016-12-15T04:08:22  <bitcoin-git> [bitcoin] rebroad closed pull request #9338: [wip] Stripe downloads to reduce stallers occuring (master...ReduceStalling) https://github.com/bitcoin/bitcoin/pull/9338
 51 2016-12-15T04:09:04  *** alpalp has quit IRC
 52 2016-12-15T04:17:22  *** mr_burdell has quit IRC
 53 2016-12-15T04:19:26  *** mr_burdell has joined #bitcoin-core-dev
 54 2016-12-15T04:29:50  <luke-jr> BIPs 2 and 123 are now Active
 55 2016-12-15T04:38:56  *** btcdrak has quit IRC
 56 2016-12-15T04:41:07  *** Alopex has quit IRC
 57 2016-12-15T04:42:12  *** Alopex has joined #bitcoin-core-dev
 58 2016-12-15T04:44:44  *** To7 has quit IRC
 59 2016-12-15T05:00:25  *** kadoban has quit IRC
 60 2016-12-15T05:15:06  *** Alopex has quit IRC
 61 2016-12-15T05:16:12  *** Alopex has joined #bitcoin-core-dev
 62 2016-12-15T05:22:02  *** Victorsueca has quit IRC
 63 2016-12-15T05:23:41  *** Victorsueca has joined #bitcoin-core-dev
 64 2016-12-15T05:28:06  *** Alopex has quit IRC
 65 2016-12-15T05:29:11  *** Alopex has joined #bitcoin-core-dev
 66 2016-12-15T05:40:22  *** Alopex has quit IRC
 67 2016-12-15T05:41:27  *** Alopex has joined #bitcoin-core-dev
 68 2016-12-15T05:53:07  *** Alopex has quit IRC
 69 2016-12-15T05:54:12  *** Alopex has joined #bitcoin-core-dev
 70 2016-12-15T06:16:23  *** Giszmo has quit IRC
 71 2016-12-15T06:32:21  *** Cory has quit IRC
 72 2016-12-15T06:37:20  *** windsok has quit IRC
 73 2016-12-15T06:50:23  *** snowden69 has quit IRC
 74 2016-12-15T06:52:58  *** btcdrak has joined #bitcoin-core-dev
 75 2016-12-15T06:54:12  *** snowden69 has joined #bitcoin-core-dev
 76 2016-12-15T07:00:18  *** dermoth has quit IRC
 77 2016-12-15T07:01:06  *** dermoth has joined #bitcoin-core-dev
 78 2016-12-15T07:03:17  *** Alopex has quit IRC
 79 2016-12-15T07:04:05  *** kallle has quit IRC
 80 2016-12-15T07:04:22  *** Alopex has joined #bitcoin-core-dev
 81 2016-12-15T07:05:16  *** kallle has joined #bitcoin-core-dev
 82 2016-12-15T07:11:17  *** windsok has joined #bitcoin-core-dev
 83 2016-12-15T07:22:50  *** jtimon has quit IRC
 84 2016-12-15T07:30:13  *** snowden69 has quit IRC
 85 2016-12-15T07:53:20  *** snowden69 has joined #bitcoin-core-dev
 86 2016-12-15T07:59:03  <jonasschnelli> <gmaxwell:#bitcoin-core-dev> jonasschnelli: want to go comment on http://bitcoin.stackexchange.com/questions/50125/failing-to-build-bitcoin-core-v0-13-1-on-debian-stretch and point out its fixed in master
 87 2016-12-15T07:59:05  <jonasschnelli> ^ done
 88 2016-12-15T07:59:20  *** BashCo has quit IRC
 89 2016-12-15T08:11:31  *** Guyver2 has joined #bitcoin-core-dev
 90 2016-12-15T08:20:08  *** BashCo has joined #bitcoin-core-dev
 91 2016-12-15T08:27:17  *** Guyver2 has quit IRC
 92 2016-12-15T08:29:36  *** snowden69 has quit IRC
 93 2016-12-15T08:29:54  *** snowden69 has joined #bitcoin-core-dev
 94 2016-12-15T08:34:03  *** wvr has joined #bitcoin-core-dev
 95 2016-12-15T08:40:46  *** Alina-malina has quit IRC
 96 2016-12-15T08:45:03  *** LeMiner has joined #bitcoin-core-dev
 97 2016-12-15T09:12:05  *** Alina-malina has joined #bitcoin-core-dev
 98 2016-12-15T09:14:19  *** laurentmt has joined #bitcoin-core-dev
 99 2016-12-15T09:14:49  *** laurentmt has quit IRC
100 2016-12-15T09:15:29  *** Alina-malina has quit IRC
101 2016-12-15T09:15:29  *** Alina-malina has joined #bitcoin-core-dev
102 2016-12-15T09:24:33  *** Lauda has quit IRC
103 2016-12-15T09:25:55  *** Ylbam has joined #bitcoin-core-dev
104 2016-12-15T09:37:12  *** PaulCapestany has quit IRC
105 2016-12-15T09:38:31  *** abpa has quit IRC
106 2016-12-15T09:46:47  *** Lauda has joined #bitcoin-core-dev
107 2016-12-15T09:51:43  <gmaxwell> I triggered some kind of hang or deadlock today on master by running bitcoin-cli stop shortly after starting bitcoind but before it had come up.  Was in a rush to fix something else so I didn't attach a debugger before killing it.   Mentioning so that if someone else encounteres it, you're not imagining it.
108 2016-12-15T09:51:58  <gmaxwell> will try to reproduce tomorrow.
109 2016-12-15T09:52:37  *** PaulCapestany has joined #bitcoin-core-dev
110 2016-12-15T10:05:31  <gmaxwell> [OT] I was really impressed by the technical accuracy of today's SMBC, then I saw it had a co-author.
111 2016-12-15T10:09:08  *** sanada has quit IRC
112 2016-12-15T10:17:43  *** Cory has joined #bitcoin-core-dev
113 2016-12-15T10:19:38  *** cannon-c has joined #bitcoin-core-dev
114 2016-12-15T10:34:22  *** windsok has quit IRC
115 2016-12-15T10:41:05  *** Guest80396 has quit IRC
116 2016-12-15T10:43:50  *** MarcoFalke has joined #bitcoin-core-dev
117 2016-12-15T10:44:49  *** BashCo has quit IRC
118 2016-12-15T10:45:34  *** BashCo has joined #bitcoin-core-dev
119 2016-12-15T10:53:19  *** laurentmt has joined #bitcoin-core-dev
120 2016-12-15T10:53:19  *** laurentmt has quit IRC
121 2016-12-15T10:53:29  *** wvr has quit IRC
122 2016-12-15T10:53:50  *** wvr has joined #bitcoin-core-dev
123 2016-12-15T11:04:10  *** BashCo_ has joined #bitcoin-core-dev
124 2016-12-15T11:06:54  *** BashCo has quit IRC
125 2016-12-15T11:22:45  *** laurentmt has joined #bitcoin-core-dev
126 2016-12-15T11:22:50  *** laurentmt has quit IRC
127 2016-12-15T11:30:03  *** windsok has joined #bitcoin-core-dev
128 2016-12-15T11:42:28  *** luke-jr has quit IRC
129 2016-12-15T11:43:39  *** luke-jr has joined #bitcoin-core-dev
130 2016-12-15T12:09:41  *** lightningbot has joined #bitcoin-core-dev
131 2016-12-15T12:13:11  *** atroxes has joined #bitcoin-core-dev
132 2016-12-15T12:40:24  *** Atomicat_ has joined #bitcoin-core-dev
133 2016-12-15T12:42:06  *** Atomicat has quit IRC
134 2016-12-15T12:42:14  *** Atomicat_ is now known as Atomicat
135 2016-12-15T13:09:39  *** alpalp has joined #bitcoin-core-dev
136 2016-12-15T13:09:40  *** alpalp has joined #bitcoin-core-dev
137 2016-12-15T13:17:33  *** BashCo_ has quit IRC
138 2016-12-15T13:20:00  *** BashCo has joined #bitcoin-core-dev
139 2016-12-15T13:25:50  *** BashCo_ has joined #bitcoin-core-dev
140 2016-12-15T13:27:45  *** snowden66 has joined #bitcoin-core-dev
141 2016-12-15T13:29:22  *** Chris_Stewart_5 has quit IRC
142 2016-12-15T13:29:26  *** BashCo has quit IRC
143 2016-12-15T13:29:29  *** xiangfu has quit IRC
144 2016-12-15T13:30:14  *** snowden69 has quit IRC
145 2016-12-15T13:30:15  *** snowden66 has quit IRC
146 2016-12-15T13:30:16  *** snowden24 has joined #bitcoin-core-dev
147 2016-12-15T13:30:39  *** xiangfu has joined #bitcoin-core-dev
148 2016-12-15T13:31:18  *** Sosumi has joined #bitcoin-core-dev
149 2016-12-15T13:32:20  *** laurentmt has joined #bitcoin-core-dev
150 2016-12-15T13:32:28  *** Giszmo has joined #bitcoin-core-dev
151 2016-12-15T13:34:40  *** laurentmt has quit IRC
152 2016-12-15T13:36:22  *** cannon-c has quit IRC
153 2016-12-15T13:41:07  *** Chris_Stewart_5 has joined #bitcoin-core-dev
154 2016-12-15T13:42:35  *** snowden24 has quit IRC
155 2016-12-15T13:45:02  *** windsok has quit IRC
156 2016-12-15T14:00:05  *** shesek has joined #bitcoin-core-dev
157 2016-12-15T14:03:58  *** mturquette has joined #bitcoin-core-dev
158 2016-12-15T14:07:45  *** TomMc has joined #bitcoin-core-dev
159 2016-12-15T14:10:56  *** Chris_Stewart_5 has quit IRC
160 2016-12-15T14:25:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
161 2016-12-15T14:29:07  *** sanada has joined #bitcoin-core-dev
162 2016-12-15T14:37:54  *** MarcoFalke has quit IRC
163 2016-12-15T14:38:55  *** gjgkhfg has joined #bitcoin-core-dev
164 2016-12-15T14:43:22  *** MykelSIlver has joined #bitcoin-core-dev
165 2016-12-15T14:56:55  *** windsok has joined #bitcoin-core-dev
166 2016-12-15T15:27:18  *** Chris_Stewart_5 has quit IRC
167 2016-12-15T15:29:23  *** Chris_Stewart_5 has joined #bitcoin-core-dev
168 2016-12-15T15:58:34  *** abpa has joined #bitcoin-core-dev
169 2016-12-15T15:58:58  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/b83264d9c7a8...5bc209c73fb6
170 2016-12-15T15:58:59  <bitcoin-git> bitcoin/master a4153e2 Patrick Strateman: Simple fuzzing framework
171 2016-12-15T15:59:00  <bitcoin-git> bitcoin/master 8b15434 Wladimir J. van der Laan: doc: Add bare-bones documentation for fuzzing
172 2016-12-15T15:59:00  <bitcoin-git> bitcoin/master 5bc209c Wladimir J. van der Laan: Merge #9172: Resurrect pstratem's "Simple fuzzing framework"...
173 2016-12-15T15:59:12  *** abpa has quit IRC
174 2016-12-15T16:00:13  *** laurentmt has joined #bitcoin-core-dev
175 2016-12-15T16:01:22  <btcdrak> wumpus: #7562 is ready for merge.
176 2016-12-15T16:01:24  <gribble> https://github.com/bitcoin/bitcoin/issues/7562 | Bump transaction version default to 2 by btcdrak · Pull Request #7562 · bitcoin/bitcoin · GitHub
177 2016-12-15T16:01:51  <bitcoin-git> [bitcoin] laanwj closed pull request #9340: [0.13] Update secp256k1 subtree (0.13...Mf1612-013subtree) https://github.com/bitcoin/bitcoin/pull/9340
178 2016-12-15T16:01:54  <wumpus> btcdrak: thanks
179 2016-12-15T16:03:38  *** xiangfu has quit IRC
180 2016-12-15T16:03:51  <bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/5bc209c73fb6...1eef038b1bcf
181 2016-12-15T16:03:52  <bitcoin-git> bitcoin/master 1f0ca1a BtcDrak: Bump default transaction version to 2
182 2016-12-15T16:03:53  <bitcoin-git> bitcoin/master c5d746a Alex Morcos: tiny test fix for mempool_tests
183 2016-12-15T16:03:53  <bitcoin-git> bitcoin/master dab207e BtcDrak: Preserve tx version=1 for certain tests...
184 2016-12-15T16:04:56  *** laurentmt has quit IRC
185 2016-12-15T16:05:03  *** xiangfu has joined #bitcoin-core-dev
186 2016-12-15T16:07:19  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1eef038b1bcf...c6fd923886a3
187 2016-12-15T16:07:19  <bitcoin-git> bitcoin/master d8c0b9f Russell Yanofsky: [qa] Add test for rescan feature of wallet key import RPCs...
188 2016-12-15T16:07:20  <bitcoin-git> bitcoin/master c6fd923 Wladimir J. van der Laan: Merge #9331: [qa] Add test for rescan feature of wallet key import RPCs...
189 2016-12-15T16:07:33  <bitcoin-git> [bitcoin] laanwj closed pull request #9331: [qa] Add test for rescan feature of wallet key import RPCs (master...pr/test-import-rescan) https://github.com/bitcoin/bitcoin/pull/9331
190 2016-12-15T16:10:30  *** ryanofsky_ has left #bitcoin-core-dev
191 2016-12-15T16:10:44  *** ryanofsky_ has joined #bitcoin-core-dev
192 2016-12-15T16:14:07  *** MykelSIlver has quit IRC
193 2016-12-15T16:14:35  *** Atomicat has quit IRC
194 2016-12-15T16:16:35  *** Atomicat has joined #bitcoin-core-dev
195 2016-12-15T16:29:26  *** laurentmt has joined #bitcoin-core-dev
196 2016-12-15T16:31:01  *** laurentmt has quit IRC
197 2016-12-15T16:37:20  *** LeMiner has quit IRC
198 2016-12-15T16:39:01  *** TomMc has quit IRC
199 2016-12-15T16:45:06  *** kadoban has joined #bitcoin-core-dev
200 2016-12-15T16:47:35  <bitcoin-git> [bitcoin] laanwj opened pull request #9353: Add data() method to CDataStream (master...2016_12_cdatastream_data) https://github.com/bitcoin/bitcoin/pull/9353
201 2016-12-15T16:49:24  *** abpa has joined #bitcoin-core-dev
202 2016-12-15T16:54:33  *** laurentmt has joined #bitcoin-core-dev
203 2016-12-15T16:55:51  *** jtimon has joined #bitcoin-core-dev
204 2016-12-15T16:59:47  *** Guyver2 has joined #bitcoin-core-dev
205 2016-12-15T17:01:58  *** laurentmt has quit IRC
206 2016-12-15T17:03:14  *** windsok has quit IRC
207 2016-12-15T17:05:34  *** wasi has quit IRC
208 2016-12-15T17:08:23  *** wasi has joined #bitcoin-core-dev
209 2016-12-15T17:11:44  *** laurentmt has joined #bitcoin-core-dev
210 2016-12-15T17:18:33  *** laurentmt has quit IRC
211 2016-12-15T17:19:27  <bitcoin-git> [bitcoin] sipa opened pull request #9354: Make fuzzer actually test CTxOutCompressor (master...fixfuzz) https://github.com/bitcoin/bitcoin/pull/9354
212 2016-12-15T17:19:49  *** laurentmt has joined #bitcoin-core-dev
213 2016-12-15T17:28:48  *** instagibbs has quit IRC
214 2016-12-15T17:32:20  <bitcoin-git> [bitcoin] hoffmabc opened pull request #9355: Add welcome script to Bitcoin Ocho (master...master) https://github.com/bitcoin/bitcoin/pull/9355
215 2016-12-15T17:33:00  <bitcoin-git> [bitcoin] hoffmabc closed pull request #9355: Add welcome script to Bitcoin Ocho (master...master) https://github.com/bitcoin/bitcoin/pull/9355
216 2016-12-15T17:37:59  *** TomMc has joined #bitcoin-core-dev
217 2016-12-15T17:38:26  *** instagibbs has joined #bitcoin-core-dev
218 2016-12-15T17:46:02  *** windsok has joined #bitcoin-core-dev
219 2016-12-15T17:46:06  *** laurentmt has quit IRC
220 2016-12-15T17:50:28  *** windsok has quit IRC
221 2016-12-15T17:51:02  <wumpus> and another user banned. Fuck off with the Ocho trolling.
222 2016-12-15T17:52:03  *** windsok has joined #bitcoin-core-dev
223 2016-12-15T17:53:47  <Lauda> Calm down wumpus :/
224 2016-12-15T18:02:04  *** aalex has quit IRC
225 2016-12-15T18:02:23  *** aalex has joined #bitcoin-core-dev
226 2016-12-15T18:09:33  *** BashCo_ has quit IRC
227 2016-12-15T18:19:18  <gmaxwell> wumpus: I believe 9313 may be ready for merge.
228 2016-12-15T18:34:40  *** Chris_Stewart_5 has quit IRC
229 2016-12-15T18:38:23  *** abpa has quit IRC
230 2016-12-15T18:38:53  *** abpa has joined #bitcoin-core-dev
231 2016-12-15T18:50:33  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c6fd923886a3...756374c522c4
232 2016-12-15T18:50:33  <bitcoin-git> bitcoin/master 01fea7a Alex Morcos: If we don't allow free txs, always send a fee filter
233 2016-12-15T18:50:34  <bitcoin-git> bitcoin/master 756374c Wladimir J. van der Laan: Merge #9313: If we don't allow free txs, always send a fee filter...
234 2016-12-15T18:50:42  *** Chris_Stewart_5 has joined #bitcoin-core-dev
235 2016-12-15T18:50:52  <bitcoin-git> [bitcoin] laanwj closed pull request #9313: If we don't allow free txs, always send a fee filter (master...minminfee) https://github.com/bitcoin/bitcoin/pull/9313
236 2016-12-15T18:55:14  * jtimon shamelssly reminds people of https://github.com/bitcoin/bitcoin/pull/8855 (part of https://github.com/bitcoin/bitcoin/pull/8994 which needs rebase again)
237 2016-12-15T18:55:29  *** TomMc has quit IRC
238 2016-12-15T19:00:25  <achow101> meeting?
239 2016-12-15T19:00:42  <wumpus> #startmeeting
240 2016-12-15T19:00:42  <lightningbot> Meeting started Thu Dec 15 19:00:42 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
241 2016-12-15T19:00:42  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
242 2016-12-15T19:00:48  <jonasschnelli> here
243 2016-12-15T19:00:52  <wumpus> proposed topics?
244 2016-12-15T19:01:03  <gmaxwell> #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
245 2016-12-15T19:01:08  <sdaftuar> hi
246 2016-12-15T19:01:15  <wumpus> + jl2012
247 2016-12-15T19:01:24  <gmaxwell> I was going to talk about some backlog but almost all of it got merged.
248 2016-12-15T19:01:28  <instagibbs> oh right
249 2016-12-15T19:01:31  * gmaxwell looks
250 2016-12-15T19:01:44  <cfields> sick and useless, but here
251 2016-12-15T19:02:28  <BlueMatt> cfields: ouch you got it now, too?
252 2016-12-15T19:02:44  <cfields> BlueMatt: mine was nice enough to wait until the flight home :\
253 2016-12-15T19:02:47  <wumpus> #9322 seems to need discussion
254 2016-12-15T19:02:49  <gribble> https://github.com/bitcoin/bitcoin/issues/9322 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
255 2016-12-15T19:02:58  <phantomcircuit> hi
256 2016-12-15T19:03:01  <instagibbs> interesting issue
257 2016-12-15T19:03:04  <wumpus> "Don't set unknown rpcserialversion"
258 2016-12-15T19:03:12  <gmaxwell> #9322
259 2016-12-15T19:03:14  <gribble> https://github.com/bitcoin/bitcoin/issues/9322 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
260 2016-12-15T19:03:16  <BlueMatt> #9352 needs to move forward quickly for fibre/some current network issues
261 2016-12-15T19:03:18  <gribble> https://github.com/bitcoin/bitcoin/issues/9352 | Attempt reconstruction from all compact block announcements by sdaftuar · Pull Request #9352 · bitcoin/bitcoin · GitHub
262 2016-12-15T19:03:34  <wumpus> looks like there is disagreement about whether it should be done at all
263 2016-12-15T19:04:04  <BlueMatt> wumpus: on which?
264 2016-12-15T19:04:08  <wumpus> the one I just mentioned
265 2016-12-15T19:05:08  *** MarcoFalke has joined #bitcoin-core-dev
266 2016-12-15T19:05:11  <gmaxwell> I don't see the disagreement on 9332?
267 2016-12-15T19:05:31  <instagibbs> luke-jr seemingly does
268 2016-12-15T19:05:34  <wumpus> #9352 is 21 hours old, that could hardly be called backlog
269 2016-12-15T19:05:36  <gribble> https://github.com/bitcoin/bitcoin/issues/9352 | Attempt reconstruction from all compact block announcements by sdaftuar · Pull Request #9352 · bitcoin/bitcoin · GitHub
270 2016-12-15T19:05:41  <gmaxwell> The purpose of the change is to return an error if you ask for seralization version 9 on software that supports 0/1.
271 2016-12-15T19:05:52  <BlueMatt> wumpus: didnt say backlog, said critical to address current ongoing network issues
272 2016-12-15T19:05:54  <instagibbs> yes I think that's well understood
273 2016-12-15T19:06:01  <gmaxwell> we can talk about that next.
274 2016-12-15T19:06:18  <wumpus> would have been useful if luke-jr was here
275 2016-12-15T19:06:32  <kanzure> hi. late.
276 2016-12-15T19:06:37  <gmaxwell> oh missed his comment.
277 2016-12-15T19:06:41  <phantomcircuit> #9332
278 2016-12-15T19:06:43  <gribble> https://github.com/bitcoin/bitcoin/issues/9332 | Let wallet importmulti RPC accept labels for standard scriptPubKeys (on top of #9331) by ryanofsky · Pull Request #9332 · bitcoin/bitcoin · GitHub
279 2016-12-15T19:07:10  <gmaxwell> I read luke's comment as saying he wanted a "max you support" version.
280 2016-12-15T19:07:12  <phantomcircuit> you mean 9322?
281 2016-12-15T19:07:42  <gmaxwell> and the response was that this was expected to be the default. Or at least thats my understanding.
282 2016-12-15T19:07:46  <jtimon> is luke's comment related to https://github.com/bitcoin/bitcoin/pull/9322/files#r92147938 ?
283 2016-12-15T19:07:46  *** To7 has joined #bitcoin-core-dev
284 2016-12-15T19:08:19  <gmaxwell> I agree that being able to ask for a max possible is fine. (though 9999 isn't an especially good number for it. :P)
285 2016-12-15T19:08:26  <instagibbs> I think #9262 is ready, but some disagreement over default value?
286 2016-12-15T19:08:28  <gribble> https://github.com/bitcoin/bitcoin/issues/9262 | Prefer coins that have fewer ancestors, sanity check txn before ATMP by instagibbs · Pull Request #9262 · bitcoin/bitcoin · GitHub
287 2016-12-15T19:08:39  <jtimon> do we have a topic?
288 2016-12-15T19:08:46  <gmaxwell> jtimon: pr backlog
289 2016-12-15T19:09:03  <wumpus> gmaxwell: in any case that doesn't have to be done in that pull, so we can just go ahead and merge it
290 2016-12-15T19:09:16  <gmaxwell> ACK
291 2016-12-15T19:10:01  <gmaxwell> in 9262 I don't believe this should default to on, for the same reason that spending unconfirmed coins is enabled by default.
292 2016-12-15T19:10:27  <gmaxwell> The transactions will be queued in the wallet and periodically rebroadcast (due to other fixes) and go out once they're no longer overlimit.
293 2016-12-15T19:10:43  <gmaxwell> the meat of the change was avoiding those cases (sometimes) when it could.
294 2016-12-15T19:10:54  <cfields> #9289 is holding up the next round of changes, and I believe the linked issue is unrelated
295 2016-12-15T19:10:56  <gribble> https://github.com/bitcoin/bitcoin/issues/9289 | net: drop boost::thread_group by theuni · Pull Request #9289 · bitcoin/bitcoin · GitHub
296 2016-12-15T19:10:58  <instagibbs> with other fixes I'm completely comfortable with it off by default.
297 2016-12-15T19:10:59  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/756374c522c4...c9e00591cd3f
298 2016-12-15T19:11:00  <bitcoin-git> bitcoin/master 80d073c Pieter Wuille: Complain when unknown rpcserialversion is specified
299 2016-12-15T19:11:00  <bitcoin-git> bitcoin/master fa615d3 MarcoFalke: [qa] Don't set unknown rpcserialversion
300 2016-12-15T19:11:01  <bitcoin-git> bitcoin/master c9e0059 Wladimir J. van der Laan: Merge #9322: [qa] Don't set unknown rpcserialversion...
301 2016-12-15T19:11:06  <cfields> (though maybe #9212 deserves a topic of its own)
302 2016-12-15T19:11:07  <gribble> https://github.com/bitcoin/bitcoin/issues/9212 | Assertion failed: (nSendVersion != 0), function GetSendVersion, file ./net.h, line 775. · Issue #9212 · bitcoin/bitcoin · GitHub
303 2016-12-15T19:11:12  <bitcoin-git> [bitcoin] laanwj closed pull request #9292: Complain when unknown rpcserialversion is specified (master...nofutureserial) https://github.com/bitcoin/bitcoin/pull/9292
304 2016-12-15T19:11:53  <wumpus> cfields: agreed
305 2016-12-15T19:12:58  <wumpus> ok, so #9262 off by default? should it still be backported then?
306 2016-12-15T19:13:01  <gribble> https://github.com/bitcoin/bitcoin/issues/9262 | Prefer coins that have fewer ancestors, sanity check txn before ATMP by instagibbs · Pull Request #9262 · bitcoin/bitcoin · GitHub
307 2016-12-15T19:13:14  <BlueMatt> cfields/wumpus: I think there is a fix commit for 9212 on the issue page at the bottom (I havent pr'ed yet because testing, but I think it'd work)
308 2016-12-15T19:13:28  <gmaxwell> wumpus: yes, it should, the main thing in the change is that it avoids creating those poorly propagating transactions when it's possible.
309 2016-12-15T19:13:42  <gmaxwell> (My opinion)
310 2016-12-15T19:13:44  <sipa> wumpus: 9262 does 2 things 1) avoid long chains 2) pre-reject created wallet transactions that would exceed limits
311 2016-12-15T19:13:51  <wumpus> gmaxwell: so it still does something even if it's disabled? okay
312 2016-12-15T19:13:52  <sipa> wumpus: only 2 is optional
313 2016-12-15T19:13:59  <wumpus> okay, right, that wasn't clear to me
314 2016-12-15T19:14:19  <wumpus> BlueMatt: ok, will test that too
315 2016-12-15T19:14:38  <instagibbs> yes so with default off it will simply try harder to pick coins that have shorter chain length
316 2016-12-15T19:14:44  <instagibbs> rather than blindly
317 2016-12-15T19:15:06  <sipa> which won't have an effect if you're always sending your full change
318 2016-12-15T19:15:10  <sipa> but better is better
319 2016-12-15T19:15:32  <cfields> BlueMatt: the reason I didn't do that is that it hides the previous behavior. The current asserts point out issues that need to be backported to 0.13
320 2016-12-15T19:15:43  <cfields> (which admittedly should've been loud errors rather than asserts)
321 2016-12-15T19:15:46  <gmaxwell> The original suggestion to create that change was (1) based on me actually encountering users that could have avoided the long chains.
322 2016-12-15T19:16:02  *** MarcoFalke has quit IRC
323 2016-12-15T19:16:11  <btcdrak> here
324 2016-12-15T19:16:16  *** MarcoFalke has joined #bitcoin-core-dev
325 2016-12-15T19:16:39  <wumpus> cfields: critical issues? or nothing that needs to hold up 0.13.2?
326 2016-12-15T19:16:51  <gmaxwell> cfields: I had a node go down with-- we think-- that assert.. but can't tell where it was triggered from.
327 2016-12-15T19:16:59  <sipa> cfields: do they really need backporting?
328 2016-12-15T19:17:03  <cfields> wumpus: likely nothing critical, just possible data leaks
329 2016-12-15T19:17:14  *** MarcoFalke has quit IRC
330 2016-12-15T19:17:20  <wumpus> so if I get this right there are now two remaining unmerged pulls that need backport to 0.13.2 https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.13.2
331 2016-12-15T19:17:22  *** MarcoFalke has joined #bitcoin-core-dev
332 2016-12-15T19:17:26  <BlueMatt> cfields: why are those data leaks? anyway, I think we previously discussed not using nVersion != 0 for this check
333 2016-12-15T19:17:26  *** gribble has quit IRC
334 2016-12-15T19:17:38  <wumpus> just one I mean, the other *is* a a backport
335 2016-12-15T19:17:41  <sipa> cfields: i'd say that such issues are things where we're certainly violating some of our own assumptions about how the p2p implementation works, but unlikely things that cause issues in interaction with other nodes
336 2016-12-15T19:18:14  <cfields> any assert represents some case where we should be disconnected, but instead are still sending/responding.
337 2016-12-15T19:18:25  <jtimon> #8855 could need rebase if there's new uses of Params(std::string), but if there are, they won't necessarily cause git conflicts
338 2016-12-15T19:18:35  <BlueMatt> cfields: no, in this case it means we are sending, but havent yet sent version message
339 2016-12-15T19:19:00  <gmaxwell> wumpus: I believe #9352 will be tagged for backport-- but it's too green to comment on it for the moment.
340 2016-12-15T19:19:25  <wumpus> gmaxwell: that's too bad, I hoped we could finally get this over with this week
341 2016-12-15T19:19:41  <cfields> BlueMatt: right, which specifically here means that we've refused the connection due to missing connection flags, but we're still sending/responding
342 2016-12-15T19:19:47  <wumpus> gmaxwell: can't it wait for 0.13.3?
343 2016-12-15T19:19:48  <sdaftuar> gmaxwell: should i go ahead and open the backport version of #9352?
344 2016-12-15T19:19:58  <BlueMatt> wumpus: its a relatively simple patch, I'm hopeful we still can :)
345 2016-12-15T19:20:09  <instagibbs> I will review asap
346 2016-12-15T19:20:58  <cfields> BlueMatt: let's take it up after the meeting
347 2016-12-15T19:21:03  <BlueMatt> cfields: sure
348 2016-12-15T19:23:22  <wumpus> okay, any other topics to discuss?
349 2016-12-15T19:23:32  <gmaxwell> sdaftuar: I think that would be useful.
350 2016-12-15T19:23:49  <gmaxwell> wumpus: I really want 0.13.2 in RC ASAP. just have some specific conerns about needing that. We'll work through it.
351 2016-12-15T19:24:12  <MarcoFalke> Could 9262 delay the rc?
352 2016-12-15T19:24:20  <MarcoFalke> Is it well tested?
353 2016-12-15T19:24:20  <jtimon> #8498 has been in the backlog for a while too (before that, #6445 was waiting for #6526/#6625/#6557 and friends, which were merged or closed long ago)
354 2016-12-15T19:24:35  <gmaxwell> MarcoFalke: I've tested the heck out of it. dunno about others.
355 2016-12-15T19:24:35  <MarcoFalke> (Note that it was not yet merged into master)
356 2016-12-15T19:24:49  <MarcoFalke> (I haven't really looked at it)
357 2016-12-15T19:24:56  <cfields> wumpus: regarding the assertion backports, nothing would be a regression from 0.13, so no need to delay, only a bonus if we get fixes in.
358 2016-12-15T19:25:08  <btcdrak> sdaftuar: ack on backport #9352
359 2016-12-15T19:25:28  <gmaxwell> MarcoFalke: it's the oldest of thes long-chain wallet fixes, just last to merge. as it had lots of oppturnities for shed painting and resulted in deciding to fix the other issues. :)
360 2016-12-15T19:25:39  <wumpus> MarcoFalke: there was at least the discussion to disable the setting by default, but after that change I don't know why it should hold up anything
361 2016-12-15T19:25:56  <wumpus> MarcoFalke: I don't think there's any critical concerns with it left
362 2016-12-15T19:26:05  <gmaxwell> with the default off it only changes 'non-determinstic' behavior.
363 2016-12-15T19:26:19  <gmaxwell> (selectcoins)
364 2016-12-15T19:26:27  <sipa> the patch always had the setting off by default - i was the one arguing that it should be on by default instead (and it seems few people agree, fine)
365 2016-12-15T19:26:36  <instagibbs> Hm? it was on before
366 2016-12-15T19:26:42  <instagibbs> but this is pre other 2 changes
367 2016-12-15T19:26:45  <sipa> oh? maybe before i looked at it :)
368 2016-12-15T19:27:22  <wumpus> let's just settle on having it disabled by default in the initial merge and the backport, it can always be set to be enabled by default later...
369 2016-12-15T19:27:24  <gmaxwell> sipa: you could argue for that in 0.14 later.
370 2016-12-15T19:27:31  <gmaxwell> that.
371 2016-12-15T19:27:32  <MarcoFalke> Agree wumpus
372 2016-12-15T19:28:06  <wumpus> there's no need to fix everything in one pull, or one version for that matter, sometimes things are held up too long on minor discussion points
373 2016-12-15T19:28:18  <instagibbs> better is better
374 2016-12-15T19:28:22  <wumpus> right.
375 2016-12-15T19:28:26  <MarcoFalke> morcos: gmaxwell: Do you have a strong opinion about the fLimitFree flag in the #9290
376 2016-12-15T19:28:28  <MarcoFalke>  backport?
377 2016-12-15T19:28:33  <gmaxwell> sometimes better is worse, there is totally like an essay on this. :P
378 2016-12-15T19:28:47  <jtimon> sipa: just said fine on not having it on by default, didn't he?
379 2016-12-15T19:29:15  <wumpus> yes he did, I meant in general
380 2016-12-15T19:29:17  <sipa> jtimon: yes, i'm fine with it being off
381 2016-12-15T19:29:54  <wumpus> MarcoFalke: ah yes that's an important point
382 2016-12-15T19:29:55  <gmaxwell> MarcoFalke: Didn't see your question until now. will evaluate.
383 2016-12-15T19:30:13  <wumpus> so this is about this comment: https://github.com/bitcoin/bitcoin/pull/9347#discussion_r92503011
384 2016-12-15T19:30:22  <MarcoFalke> Imo it should not matter too much, but I'd rather have a second opinion
385 2016-12-15T19:30:25  <bitcoin-git> [bitcoin] sdaftuar opened pull request #9357: [0.13 backport] Attempt reconstruction from all compact block announcements (0.13...backport-optimistic-cb) https://github.com/bitcoin/bitcoin/pull/9357
386 2016-12-15T19:32:06  <MarcoFalke> I haven't checked if it caused issues with txes evicted from the pool due to low fee.
387 2016-12-15T19:32:49  *** droark has joined #bitcoin-core-dev
388 2016-12-15T19:32:53  <gmaxwell> I need to look into it carefully to make a decision on my view, not going to manage it during the meeting.
389 2016-12-15T19:33:10  <MarcoFalke> ok, other topics?
390 2016-12-15T19:34:02  <morcos> MarcoFalke: I hadn't seen the flimitFree thing before now, I'll take a look and get back to you after...  (same as gmaxwell)
391 2016-12-15T19:34:18  <MarcoFalke> great, thx
392 2016-12-15T19:34:31  <gmaxwell> We could talk about the compact block announcement stuff not the backports but the change; just so people know what the change is about.
393 2016-12-15T19:34:54  <wumpus> #topic compact block announcement stuff
394 2016-12-15T19:35:13  <gmaxwell> Right now, if someone sends us a header, we request a block and mark the block in flight. If a compact block (e.g. from a HB mode sender that sends unsolicited ones) shows up while we're waiting.. we just ignore it, instead of trying to reconstruct the block.
395 2016-12-15T19:35:55  <gmaxwell> This means that if a peer is broken and slowly transmits or fails to reply, the HB mode will fail to work around it.
396 2016-12-15T19:36:44  <gmaxwell> There is a deep rabbit hole we can go down towards optimal behavior, but what is proposed right now is a super minimal change where even if a block is in flight, we'll still see if we can recover the whole block from just the compact block. And if we can, we take it, and mark the block as complete.
397 2016-12-15T19:37:16  <wumpus> sounds sensible
398 2016-12-15T19:37:42  <gmaxwell> greater than 2/3rs of all blocks can be recovered from just the compact block (varries a lot based on miner/network behavior) so even this small improvement should be a pretty big help.
399 2016-12-15T19:37:44  <wumpus> there seems some potential for race conditions though
400 2016-12-15T19:37:46  <BlueMatt> this is especially important with prefill, where, if your peer upgrades to prefill txn in the announcement you can recover the block somtimes and recover from stalling without yourself upgrading
401 2016-12-15T19:38:25  <wumpus> what if the compact block is reconstructed, and then the inflight block comes in?
402 2016-12-15T19:38:39  <gmaxwell> wumpus: yes, though we don't count on the in-flight to protect against that, and if a full block shows up right now we'll accept it.
403 2016-12-15T19:38:54  <sdaftuar> wumpus: should not be a problem.  there's generally no downside to receiving a block you already have.
404 2016-12-15T19:38:58  <gmaxwell> wumpus: then its just like someone sending us an unsolicited full block, which we'll process if it's not best already.
405 2016-12-15T19:38:59  *** Chris_Stewart_5 has quit IRC
406 2016-12-15T19:40:02  <wumpus> sdaftuar: in general there's no downside, just thought it'd be a potential edge case, but if that's handled that's ok
407 2016-12-15T19:40:06  *** Chris_Stewart_5 has joined #bitcoin-core-dev
408 2016-12-15T19:40:44  <gmaxwell> In any case, I think that summarizes where that is, I have several nodes testing live right now.. obviously will need review and testing.. but I just wanted everyone to know what was going on there.
409 2016-12-15T19:42:16  *** chris2000 has joined #bitcoin-core-dev
410 2016-12-15T19:42:24  *** chris2000 has left #bitcoin-core-dev
411 2016-12-15T19:42:31  *** chris2000 has joined #bitcoin-core-dev
412 2016-12-15T19:44:01  <jtimon> thanks, I assume more questions about this or other topics?
413 2016-12-15T19:46:14  <achow101> when are we planning to start rc'ing for 0.13.2
414 2016-12-15T19:47:22  <wumpus> dunno, yesterday if it was up to me :p
415 2016-12-15T19:48:04  <wumpus> in any case there's still a few things open and you can help by testing and reviewing: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.13.2
416 2016-12-15T19:49:40  <wumpus> bah looks like the build is broken
417 2016-12-15T19:50:51  <wumpus> any other topics? if not we'll close the meeting early
418 2016-12-15T19:51:14  <sipa> very short report: gmaxwell and i have been experimenting with a per-txout utxo cache approach
419 2016-12-15T19:51:15  <gmaxwell> Close meeting early and make 0.13.2 great again ACK.
420 2016-12-15T19:51:25  <sipa> so far results don't look too promising
421 2016-12-15T19:51:27  <wumpus> heh
422 2016-12-15T19:51:42  <morcos> sipa: yeah i haven't looked at that yet
423 2016-12-15T19:51:46  <morcos> i'm surprised!
424 2016-12-15T19:51:56  <morcos> i was super optimistic
425 2016-12-15T19:52:00  <sipa> me too
426 2016-12-15T19:52:05  <wumpus> sipa: so grouping the utxos per transaction turns out to have been a good optimization? I'm surprised too
427 2016-12-15T19:52:12  <gmaxwell> Well when it's operating totally in memory it's 15% faster even though sipa has not exploited the new structure for better cache intelligence (so its still doing the same dumb flush thing). But when leveldb came into the picture it ate dirt.
428 2016-12-15T19:52:21  <morcos> 15% is for babies
429 2016-12-15T19:52:34  <instagibbs> what level are you on morcos :)
430 2016-12-15T19:52:52  <sdaftuar> i'm going to give a cheers for the sigcache cuckoocache merge now!
431 2016-12-15T19:53:05  <jtimon> mhm, haven't looked at the branch, are the utxo's catched per txout but stored per-tx?
432 2016-12-15T19:53:23  <sipa> jtimon: both per txout
433 2016-12-15T19:53:23  <gmaxwell> Assuming the issue isn't extra debugging sipa added, the downside is perhaps that it is just much harder on leveldb and writes a lot more traffic to the leveldb log.
434 2016-12-15T19:53:24  <BlueMatt> gmaxwell: seems like something where you can per-utxo in memory and per-tx on disk?
435 2016-12-15T19:53:46  <wumpus> BlueMatt: yes I was about to suggest that too
436 2016-12-15T19:53:51  <gmaxwell> The real gains from the change would come from making the cache smarter, so I thought 15% was great news.. since that likely came from reduced malloc traffic.
437 2016-12-15T19:53:52  <BlueMatt> i mean might lose all the performance on the boundary, but its worth a shot
438 2016-12-15T19:54:01  <jtimon> sipa: thanks. mhmm, yeah, this is surprising then
439 2016-12-15T19:54:05  <sipa> BlueMatt: that doesn't solve the O(n^2) issue with large transactions
440 2016-12-15T19:54:10  <gmaxwell> BlueMatt: yes, I made that observation too.... but it means that read modify write cycles would be needed.
441 2016-12-15T19:54:28  <wumpus> gmaxwell: yeah that would be bad...
442 2016-12-15T19:54:48  <wumpus> lookups are slow, if you need read-modify-write cycles it's not going to help performance
443 2016-12-15T19:54:55  <sipa> the O(n^2) issue is that a tx with many outputs on every spend needs to write n-i outputs to the database
444 2016-12-15T19:55:19  <gmaxwell> wumpus: yes, though it might pay for itself by the cache being much more effective. I guess we won't know until after more testing.
445 2016-12-15T19:55:19  <cfields> sdaftuar: +1. Still catching up, didn't see that got merged. Great to see :)
446 2016-12-15T19:56:08  <gmaxwell> the other negative is that it looks like this change will require a chainstate reindex. making it compatible with undo files seems really hard.
447 2016-12-15T19:56:44  <sipa> basically my reason for wanting per-txout cache is that the current behaviour may be good on average, but it's terrible for big transactions
448 2016-12-15T19:56:48  <jtimon> maybe somehow writting txouts in batches could help? (thinking out loud, may be a stupid thought)
449 2016-12-15T19:56:59  <wumpus> requiring everyone to do a chainstate reindex would be bad too :/
450 2016-12-15T19:57:05  <sipa> jtimon: we're already batching _all_ writes from many blocks
451 2016-12-15T19:57:37  <jtimon> sipa: I see, it was a stupid thought
452 2016-12-15T19:57:47  <sipa> anyway, just reporting on an experiment - nothing more at this point
453 2016-12-15T19:57:50  <morcos> gmaxwell: i'm not sure what you mean about making the cache smarter
454 2016-12-15T19:58:02  <gmaxwell> wumpus: right now everyone's chainstate is corrupted... to at some point we'll need to do something about that.  (TXversions)
455 2016-12-15T19:58:09  <wumpus> writes are pretty fast with leveldb, it's lookups/reads are slow, especially on slow disks
456 2016-12-15T19:58:09  <sipa> morcos: not wiping the cache after a write
457 2016-12-15T19:58:13  <morcos> in my view once its only keeping utxos that were actually accessed and not the rest that tagged along with the tx, then thats as smart as it gets
458 2016-12-15T19:58:29  <Chris_Stewart_5> Are we thinking txs are going to become larger in terms of inputs/outputs as Bitcoin grows? UTXO size is constantly growing right?
459 2016-12-15T19:58:34  <morcos> sipa: sure but you still have to do something when you hit memory limits
460 2016-12-15T19:58:43  <sipa> Chris_Stewart_5: i wish it were not growing at all
461 2016-12-15T19:59:01  <wumpus> batching writes more is not going to help, and batches are already huge in memory
462 2016-12-15T19:59:02  <morcos> you can save the things that are in blocks from the top of your mempool, but thats really small... small enough that it can be done pretty effectively with the existing model
463 2016-12-15T19:59:03  <sipa> Chris_Stewart_5: http://bitcoin.sipa.be/utxo_size.png
464 2016-12-15T19:59:05  <gmaxwell> morcos: yes the right thing to do is to expire only the oldest entrties at that point. Which is much cleaner when there is no such thing as entry mutation.
465 2016-12-15T19:59:12  <Chris_Stewart_5> I guess it is just interesting to hear the tidbit about terrible performance of large txs.
466 2016-12-15T19:59:14  <wumpus> gmaxwell: requiring everyone to reindex at the same time is not an acceptable solution though :)
467 2016-12-15T19:59:26  <morcos> ah, oldest, yes ok, but that requires extra state
468 2016-12-15T19:59:30  <wumpus> gmaxwell: maybe it could support two database versions for a while
469 2016-12-15T19:59:42  <sipa> Chris_Stewart_5: in general, we need to optimize worst-case performance, not average performance
470 2016-12-15T19:59:44  <wumpus> gmaxwell: new reindexes/syncs would use the new format
471 2016-12-15T20:00:01  <wumpus> in any acsae, thanks for trying this experiment
472 2016-12-15T20:00:08  <sipa> Chris_Stewart_5: as a large difference between worst-case and average means we could be missing DoS opportunities where an attacker can force us into the worsr
473 2016-12-15T20:00:10  <gmaxwell> wumpus: if it made it N fold faster, than reindex on a new version... might be something we could have happen. I think perhaps we'd want to finish your snapshooting work and other things at the same time. ... in any case it's just an expirement now.
474 2016-12-15T20:00:11  *** gribble has joined #bitcoin-core-dev
475 2016-12-15T20:00:16  <wumpus> even if it turns out it's not better it's good to know this for sure
476 2016-12-15T20:00:37  <gmaxwell> it also has resulted in some other optimizations, e.g. the flushing optimization PR that we have right now.
477 2016-12-15T20:00:41  <sipa> Chris_Stewart_5: but it's really sad when you need to decrease your average performance in order to improve the worst case... because people don't observe the worst case
478 2016-12-15T20:00:51  <wumpus> gmaxwell: if it was possible to convert the old database to the new database without a reindex (e.g. just rewriting) then an upgrade process would be acceptable. But a full reindex? no
479 2016-12-15T20:01:02  <gmaxwell> Good, the meeting has run over, so all is well with the world. :)
480 2016-12-15T20:01:08  <wumpus> #endmeeting
481 2016-12-15T20:01:08  <lightningbot> Meeting ended Thu Dec 15 20:01:08 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
482 2016-12-15T20:01:08  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-15-19.00.html
483 2016-12-15T20:01:08  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-15-19.00.txt
484 2016-12-15T20:01:08  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-15-19.00.log.html
485 2016-12-15T20:01:12  <sipa> wumpus: i believe it is convertible, but it's nontrivial
486 2016-12-15T20:01:15  <gmaxwell> wumpus: that would be possible, though perhaps a lot of code.
487 2016-12-15T20:01:34  <Chris_Stewart_5> sipa: Thanks for the food for thought. I appreciate the extra explanation :-)
488 2016-12-15T20:01:51  <wumpus> gmaxwell: ah yes thanks for reminding me of the snapshotting
489 2016-12-15T20:02:01  <sipa> the tx height/coinbase is currently only stored in the undo data for the last spend from one tx's outputs, and needs to be stored in all
490 2016-12-15T20:02:45  <sipa> but that can be done by walking the undo data backwards (which is always possible, even in pruned mode), and building a temporary database with tx->metadata maps, and using that to rebuild the undo data in the new format
491 2016-12-15T20:03:12  <jtimon> wumpus: what snapshotting?
492 2016-12-15T20:03:35  <wumpus> jtimon: automatic utxo database backups
493 2016-12-15T20:04:08  * jtimon nods
494 2016-12-15T20:05:08  <gmaxwell> morcos: my thought was that with the per-utxo model we could simply have a list of keys as they're read into the cache... and then when the cach is full, pop from the beginning of the list and flush those entries... to take it back to 90% or something (whatever is big enough to have a reasonable batch size for leveldb).
495 2016-12-15T20:05:13  <wumpus> sipa: btw I still get no results from "host seed.bitcoin.sipa.be"
496 2016-12-15T20:05:39  <gmaxwell> Sipa noticed that right now we end up using somewhat less than twice our memory limit; the flush process copies the data being flushed.
497 2016-12-15T20:05:59  <morcos> gmaxwell: wow, really... i didn't realize that
498 2016-12-15T20:06:47  <morcos> sdaftuar also points out that just deleting spent entries will help
499 2016-12-15T20:07:08  <gmaxwell> morcos: well their deletion needs to hit the disk if their creation ever did.
500 2016-12-15T20:07:12  <morcos> i had observed that it wasn't THAT helpful, but that was with requiring the whole TX to be spent... should be a much bigger effect
501 2016-12-15T20:07:33  <gmaxwell> oh yea, thats one of the benefits of the per txout model.
502 2016-12-15T20:07:34  <morcos> yes, so on flush, you can keep everything that isn't spent and your memory usage may reduce non-trivially
503 2016-12-15T20:09:08  <gmaxwell> in any case, because of that memory usage we should be limiting our leveldb batch sizes. I'm guessing there probably is no real performance benefit to a batch of 200MB (or 2000mb) over 20MB.
504 2016-12-15T20:09:37  <sipa> the size of batches is determined by how much has changed
505 2016-12-15T20:09:49  <morcos> yeah, thats what i was thinking a bit annoying to have to track that too
506 2016-12-15T20:10:03  <sipa> unless we maintain multiple checkpoints in-memory, to know which entries combined form a consistent state, that's very hard to reduce
507 2016-12-15T20:10:30  <sipa> multiple in-memory checkpoints also implies we can't do the fresh optimization until an entry is in no snapshot
508 2016-12-15T20:10:32  <wumpus> that sounds overly complicated
509 2016-12-15T20:10:35  <sipa> yes.
510 2016-12-15T20:11:10  <morcos> gmaxwell: one advnatage of bigger batch sizes is the ability to delete fresh pruned entries...  you lose all your freshness after a flush
511 2016-12-15T20:12:37  <gmaxwell> well, the alternative for memory usage is that we start making changes to the leveldb api so that it can do some kind of gather callback or something for the batch.
512 2016-12-15T20:13:15  <sipa> yes.
513 2016-12-15T20:13:25  <gmaxwell> (I'm not even sure if thats possible, but it looked like it with a quick glance at the leveldb code)
514 2016-12-15T20:13:26  <sipa> we discovered that a leveldb write batch is a wrapped std::string
515 2016-12-15T20:13:46  <sipa> which just gets writes and erased appended to in a binary format
516 2016-12-15T20:14:09  <wumpus> optimizing leveldb's batch representation/scheduling would certainly be possible, yes
517 2016-12-15T20:15:47  <wumpus> but in my experience it's reads / lookups that take lots of time, especially on slow disks, not so much writing, writing with leveldb is much faster than comparable databases such as lmdb
518 2016-12-15T20:16:25  <sipa> well writing 2GB of modified utxo entries required 90s in gmaxwell's benchmarks
519 2016-12-15T20:16:54  <gmaxwell> well it was 40s with master, 90s with the per-utxo.
520 2016-12-15T20:17:04  <wumpus> but that's hardly realistic for normal usage
521 2016-12-15T20:17:21  <wumpus> if you have a dbcache of gigabytes you hardly really need a database at all
522 2016-12-15T20:18:50  <gmaxwell> wumpus: so right now our initial sync performance is really poor with the default cache. it takes 21076 seconds to chainstate reindex even with all signature checking disabled on a fast machine.  We often tell people to crank their dbcache to big numbers to make ibd take more acceptable time.
523 2016-12-15T20:19:42  <wumpus> gmaxwell: but is that due to writing? as said, in my experience, it spends almost all the time connecting inputs - e.g. fetching and random lookups
524 2016-12-15T20:19:55  <wumpus> it could be I just have very strange hardware of course
525 2016-12-15T20:20:39  <gmaxwell> sorry, I thought you were saying that it wasn't realistic for people to run with a big dbcache; and I was just countering that running with a big dbcache is the only way to get ibd to run in a sane-ish amount of time. I guess I was on a tangent from your point.
526 2016-12-15T20:24:45  <wumpus> right - maybe the best solution for small memory usage and large memory usage is completely different
527 2016-12-15T20:26:47  <wumpus> another thing with writes is that things can be pipelined, as soon as the batch buffers have been filled it could be shipped off to a background thread doing the writing, there's no need to wait for it to continue
528 2016-12-15T20:31:19  <gmaxwell> wumpus: yes. Indeed. perhaps a little tricky with consistency between the chainstate and the blockindex.
529 2016-12-15T20:31:29  *** abpa has quit IRC
530 2016-12-15T20:31:33  *** droark has quit IRC
531 2016-12-15T20:40:30  <gmaxwell> ohh sipa's per utxo code had debugging code that was trashing performance, rebenchmarking is looking much more promising!
532 2016-12-15T20:43:09  <sdaftuar> yay!
533 2016-12-15T20:43:23  <sipa> (with large dbcache)
534 2016-12-15T20:43:46  *** BashCo has joined #bitcoin-core-dev
535 2016-12-15T20:44:26  <gmaxwell> Man.  Thomas Zander wrote some article attacking segwit today that says up front "Once a user gets a SegWit transaction, she will only be able to move that money forward in a SegWit wallet. So if a person doesn't upgrade they will eventually not be able to accept money from anyone." -- will there be no consequence in this ecosystem for this kind of incompetence or dishonesty?  damn.  It also rep
536 2016-12-15T20:44:32  <gmaxwell> eats Jeff Garzik's two buckets lie.
537 2016-12-15T20:44:35  <gmaxwell> https://bitcoinclassic.com/devel/FlexTrans-vs-SegWit.html
538 2016-12-15T20:46:22  <gmaxwell> Also deceptively claims to make transactions smaller (actually-- it increases the amount of information in a transaction-- because it makes the field ordering non-normative--, making the smallest possible representation larger...)
539 2016-12-15T20:51:40  <juscamarena> Just saw that. Was the site hacked? He can't really believe that?
540 2016-12-15T20:52:13  <sipa> i'm sure he believes it
541 2016-12-15T20:53:41  <gmaxwell> he's previously posted a number of absurd things, e.g. the posts claiming that BIP152 was going to "disrupt the network" and trying to get us to abort the 0.13 release.
542 2016-12-15T20:59:56  <btcdrak> gmaxwell: what the heck? that's just ...
543 2016-12-15T21:02:06  <juscamarena> Sigh. He might have gotten confused here: "When spending your bitcoins after the upgrade to segwit, you will still be able to pay the original type of Bitcoin addresses that start with a ‘1’ (a P2PKH address) as well as being able to pay other users of P2SH addresses."
544 2016-12-15T21:02:27  <juscamarena> Thinking upgrade meant upgrading the wallet.
545 2016-12-15T21:03:25  *** grubles_ is now known as grubles
546 2016-12-15T21:03:27  <gmaxwell> I'm having a really hard time believing that he is actually this confused.
547 2016-12-15T21:06:23  *** abpa has joined #bitcoin-core-dev
548 2016-12-15T21:26:30  *** crescendo has joined #bitcoin-core-dev
549 2016-12-15T21:28:32  *** Sosumi has quit IRC
550 2016-12-15T21:33:52  *** laurentmt has joined #bitcoin-core-dev
551 2016-12-15T21:36:14  <morcos> gmaxwell: just skimmed what he wrote.. i don't think hes confused.. (except about the 2 buckets crap, but you know "math is hard")
552 2016-12-15T21:37:16  <morcos> i think he was just trying to make a point that i don't think really makes any sense, that people with segwit wallets would prefer to send to other segwit addresses
553 2016-12-15T21:37:30  <morcos> well yes i guess maybe thats what you meant by confused, since there is no reason they would prefer that?
554 2016-12-15T21:38:14  <gmaxwell> there is no reason they would prefer that.
555 2016-12-15T21:38:21  *** laurentmt has quit IRC
556 2016-12-15T21:38:22  <gmaxwell> Doesn't cost them any more or less.
557 2016-12-15T21:38:33  <gmaxwell> it's indistinguishable to them.
558 2016-12-15T21:39:09  <morcos> it seems maybe the text changed if yours was an actual quote
559 2016-12-15T21:39:11  <gmaxwell> actually, since the only kind of address type right now used for segwit is p2sh-p2w* it is cryptographically indistinguishable.
560 2016-12-15T21:39:22  <gmaxwell> morcos: my test was an actual quote.
561 2016-12-15T21:39:24  <gmaxwell> er text.
562 2016-12-15T21:39:34  <morcos> it still says this which is at best badly misleading
563 2016-12-15T21:39:36  <morcos> "receiving a SegWit transaction requires a SegWit wallet which then will generate SegWit transactions forcing everyone around you to get one too."
564 2016-12-15T21:40:06  <gmaxwell> that is absurdly untrue too.
565 2016-12-15T21:41:14  <gmaxwell> amusingly one of the big reasons we didn't move foward with a new address type was specifically to avoid this class of misunderstanding.  (the other being that several people wanted time to establish a new base-32 based encoding with proper error detection)
566 2016-12-15T21:44:07  <MarcoFalke> morcos: Motivated from the rpc test failure: Should the feefilter rounder not return a fee that is less (or equal to) the target fee?
567 2016-12-15T21:44:28  <MarcoFalke> otherwise you might miss some tx if you "round up"
568 2016-12-15T21:44:42  <morcos> MarcoFalke: which test failure?
569 2016-12-15T21:44:50  <MarcoFalke> fundrawtx
570 2016-12-15T21:45:02  <MarcoFalke> Just a sync mempool issue due to feefilter, I guess
571 2016-12-15T21:45:12  <morcos> i mean is there a link to what you are talking about
572 2016-12-15T21:45:15  <MarcoFalke> #9313
573 2016-12-15T21:45:17  <gribble> https://github.com/bitcoin/bitcoin/issues/9313 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
574 2016-12-15T21:45:51  <MarcoFalke> If you run fundrawtransaciton on master it will fail randomly
575 2016-12-15T21:46:00  <morcos> i'm not following... ok, thats what i was wondering
576 2016-12-15T21:46:03  <morcos> really?
577 2016-12-15T21:46:13  <MarcoFalke> Likely due to current choice of the feefilter
578 2016-12-15T21:46:29  <MarcoFalke> It becomes visible when the transaction pays a fee close to the minrelayfee
579 2016-12-15T21:46:50  <MarcoFalke> your feefilter will be maybe minrelaytxfee+x, so you never see the tx
580 2016-12-15T21:46:59  <morcos> yeah i guess if you tried to pay exactly the minrelayfee it might not work
581 2016-12-15T21:47:52  <MarcoFalke> Would it make sense to always send feefilters that are less than the currentFeeFilter?
582 2016-12-15T21:47:57  <morcos> the variance was put in there to slightly obscure the exact state of your mempool..  but ehh, i'm not sure its worth the effort
583 2016-12-15T21:48:30  <MarcoFalke> You can keep the variance
584 2016-12-15T21:48:35  <morcos> realistically i doubt it would be a problem except in tests..
585 2016-12-15T21:48:53  <MarcoFalke> Sure, on current main net
586 2016-12-15T21:49:09  <MarcoFalke> with default minrelaytxfee
587 2016-12-15T21:49:25  <morcos> i mean its been like that since it came out, the only difference is it happens now before your mempool gets full
588 2016-12-15T21:49:34  <MarcoFalke> Right
589 2016-12-15T21:50:23  <morcos> i don't feel strongly...
590 2016-12-15T21:51:59  <MarcoFalke> As we send a feefilter now by default for all connections, it might not be too much wasted bandwith if we received some minrelaytxfee-dust txs
591 2016-12-15T21:52:00  <gmaxwell> I think it's okay to leak that you're at the floor. e.g. apply the max after the variance.
592 2016-12-15T21:55:24  <MarcoFalke> In which case your node is identifiable if you set a non-default value for the relay fee, no?
593 2016-12-15T21:56:54  <gmaxwell> it's identifyable by behavior in that case, regardless.
594 2016-12-15T22:08:52  *** Guyver2 has quit IRC
595 2016-12-15T22:13:06  <morcos> MarcoFalke: yeah the floor is a separate issue.  we already send under the floor all the time anyway... i think that could be a special case perhaps.
596 2016-12-15T22:13:55  <morcos> i'm just not sure how much any of this is worth it.  to make sure the tests work at exactly minrelaytxfee, need to check all the < vs <='s as well
597 2016-12-15T22:14:12  *** Taek has quit IRC
598 2016-12-15T22:16:27  *** Chris_Stewart_5 has quit IRC
599 2016-12-15T22:19:01  *** Taek has joined #bitcoin-core-dev
600 2016-12-15T22:28:03  *** gjgkhfg has quit IRC
601 2016-12-15T22:31:28  *** abpa has quit IRC
602 2016-12-15T22:32:37  *** Chris_Stewart_5 has joined #bitcoin-core-dev
603 2016-12-15T23:02:58  *** Chris_Stewart_5 has quit IRC
604 2016-12-15T23:04:10  *** Chris_Stewart_5 has joined #bitcoin-core-dev
605 2016-12-15T23:07:06  <luke-jr> instagibbs: more of a suggestion than disagreement re 9322
606 2016-12-15T23:28:43  *** wasi has quit IRC
607 2016-12-15T23:29:41  *** Chris_Stewart_5 has quit IRC
608 2016-12-15T23:34:23  *** JackH has quit IRC
609 2016-12-15T23:36:57  *** MarcoFalke has left #bitcoin-core-dev
610 2016-12-15T23:48:40  *** Chris_Stewart_5 has joined #bitcoin-core-dev