1 2016-06-30T00:01:46  *** fengling has quit IRC
  2 2016-06-30T00:17:33  *** zooko has joined #bitcoin-core-dev
  3 2016-06-30T00:45:46  *** Ylbam has quit IRC
  4 2016-06-30T00:49:17  *** Chris_Stewart_5 has quit IRC
  5 2016-06-30T00:52:36  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  6 2016-06-30T00:52:47  *** fengling has joined #bitcoin-core-dev
  7 2016-06-30T00:57:33  *** gabridome has quit IRC
  8 2016-06-30T00:59:04  *** gabridome has joined #bitcoin-core-dev
  9 2016-06-30T01:04:26  *** molz has joined #bitcoin-core-dev
 10 2016-06-30T01:07:11  *** moli has quit IRC
 11 2016-06-30T01:20:41  *** zooko has quit IRC
 12 2016-06-30T01:52:30  <GitHub64> [bitcoin] luke-jr opened pull request #8293: Bugfix: Allow building libbitcoinconsensus without any univalue (master...sys_univalue_opt) https://github.com/bitcoin/bitcoin/pull/8293
 13 2016-06-30T01:55:30  *** xiangfu has joined #bitcoin-core-dev
 14 2016-06-30T01:59:33  *** Chris_Stewart_5 has quit IRC
 15 2016-06-30T02:17:49  *** justanotheruser has quit IRC
 16 2016-06-30T02:18:22  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 17 2016-06-30T02:23:12  *** justanotheruser has joined #bitcoin-core-dev
 18 2016-06-30T02:24:49  *** Chris_Stewart_5 has quit IRC
 19 2016-06-30T02:27:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 20 2016-06-30T02:28:18  *** dingus has joined #bitcoin-core-dev
 21 2016-06-30T02:33:07  *** Chris_Stewart_5 has quit IRC
 22 2016-06-30T02:37:55  *** Samdney has left #bitcoin-core-dev
 23 2016-06-30T03:44:52  *** justanotheruser is now known as justanother|NYY
 24 2016-06-30T03:49:46  *** fengling has quit IRC
 25 2016-06-30T04:17:01  *** Alopex has quit IRC
 26 2016-06-30T04:18:06  *** Alopex has joined #bitcoin-core-dev
 27 2016-06-30T04:24:33  *** fengling has joined #bitcoin-core-dev
 28 2016-06-30T04:29:26  *** fengling has quit IRC
 29 2016-06-30T04:31:12  *** moli has joined #bitcoin-core-dev
 30 2016-06-30T04:33:34  *** molz has quit IRC
 31 2016-06-30T05:25:55  *** fengling has joined #bitcoin-core-dev
 32 2016-06-30T05:30:06  *** fengling has quit IRC
 33 2016-06-30T06:09:09  *** kadoban has quit IRC
 34 2016-06-30T06:10:30  *** Ylbam has joined #bitcoin-core-dev
 35 2016-06-30T06:13:02  *** fengling has joined #bitcoin-core-dev
 36 2016-06-30T06:28:39  *** harrymm has quit IRC
 37 2016-06-30T06:36:27  *** davec_ has quit IRC
 38 2016-06-30T06:39:52  *** xiangfu has quit IRC
 39 2016-06-30T06:42:18  *** murch has joined #bitcoin-core-dev
 40 2016-06-30T06:44:01  *** davec_ has joined #bitcoin-core-dev
 41 2016-06-30T06:45:46  *** fengling has quit IRC
 42 2016-06-30T06:47:22  *** harrymm has joined #bitcoin-core-dev
 43 2016-06-30T06:47:51  *** fengling has joined #bitcoin-core-dev
 44 2016-06-30T06:53:39  *** davec_ has quit IRC
 45 2016-06-30T06:55:41  *** xiangfu has joined #bitcoin-core-dev
 46 2016-06-30T06:59:48  *** jannes has joined #bitcoin-core-dev
 47 2016-06-30T07:04:09  *** harrymm has quit IRC
 48 2016-06-30T07:25:43  *** harrymm has joined #bitcoin-core-dev
 49 2016-06-30T07:40:33  *** harrymm has quit IRC
 50 2016-06-30T07:41:26  *** paveljanik has quit IRC
 51 2016-06-30T07:55:12  *** harrymm has joined #bitcoin-core-dev
 52 2016-06-30T07:55:32  *** murch has quit IRC
 53 2016-06-30T08:15:39  *** murch has joined #bitcoin-core-dev
 54 2016-06-30T08:18:36  *** Giszmo has quit IRC
 55 2016-06-30T08:33:30  *** [b__b] has quit IRC
 56 2016-06-30T08:33:50  *** [b__b] has joined #bitcoin-core-dev
 57 2016-06-30T08:40:07  *** MarcoFalke has joined #bitcoin-core-dev
 58 2016-06-30T08:54:13  *** Guyver2 has joined #bitcoin-core-dev
 59 2016-06-30T08:58:26  *** slackircbridge1 has joined #bitcoin-core-dev
 60 2016-06-30T09:01:06  *** fengling has quit IRC
 61 2016-06-30T09:01:27  *** Michail1_ has joined #bitcoin-core-dev
 62 2016-06-30T09:01:54  *** hybridsole_ has joined #bitcoin-core-dev
 63 2016-06-30T09:03:31  *** pmienk_ has joined #bitcoin-core-dev
 64 2016-06-30T09:03:57  *** Amnez777- has joined #bitcoin-core-dev
 65 2016-06-30T09:04:54  *** roasbeef_ has joined #bitcoin-core-dev
 66 2016-06-30T09:05:42  *** aj_ has joined #bitcoin-core-dev
 67 2016-06-30T09:06:36  *** xiangfu has quit IRC
 68 2016-06-30T09:08:16  *** whphhg has quit IRC
 69 2016-06-30T09:08:16  *** pmienk has quit IRC
 70 2016-06-30T09:08:16  *** Amnez777 has quit IRC
 71 2016-06-30T09:08:17  *** sturles has quit IRC
 72 2016-06-30T09:08:17  *** slackircbridge has quit IRC
 73 2016-06-30T09:08:17  *** roasbeef has quit IRC
 74 2016-06-30T09:08:18  *** Michail1 has quit IRC
 75 2016-06-30T09:08:18  *** aj has quit IRC
 76 2016-06-30T09:08:18  *** luke-jr has quit IRC
 77 2016-06-30T09:08:18  *** wangchun has quit IRC
 78 2016-06-30T09:08:18  *** hybridsole has quit IRC
 79 2016-06-30T09:08:18  *** Michail1_ is now known as Michail1
 80 2016-06-30T09:08:21  *** hybridsole_ is now known as hybridsole
 81 2016-06-30T09:08:25  *** wangchun has joined #bitcoin-core-dev
 82 2016-06-30T09:08:38  *** luke-jr has joined #bitcoin-core-dev
 83 2016-06-30T09:08:46  *** paveljanik has joined #bitcoin-core-dev
 84 2016-06-30T09:08:55  *** paveljanik has quit IRC
 85 2016-06-30T09:08:55  *** paveljanik has joined #bitcoin-core-dev
 86 2016-06-30T09:10:37  *** whphhg has joined #bitcoin-core-dev
 87 2016-06-30T09:11:55  *** sturles has joined #bitcoin-core-dev
 88 2016-06-30T09:11:55  *** sturles has joined #bitcoin-core-dev
 89 2016-06-30T09:15:27  *** fengling has joined #bitcoin-core-dev
 90 2016-06-30T09:24:17  *** pedrobranco has joined #bitcoin-core-dev
 91 2016-06-30T09:28:06  *** fengling has quit IRC
 92 2016-06-30T09:32:54  *** afk11 has quit IRC
 93 2016-06-30T09:36:47  *** fengling has joined #bitcoin-core-dev
 94 2016-06-30T09:37:52  *** afk11 has joined #bitcoin-core-dev
 95 2016-06-30T09:37:52  *** afk11 has quit IRC
 96 2016-06-30T09:37:52  *** afk11 has joined #bitcoin-core-dev
 97 2016-06-30T09:42:22  *** xiangfu has joined #bitcoin-core-dev
 98 2016-06-30T09:56:58  *** xiangfu has quit IRC
 99 2016-06-30T10:21:46  *** fengling has quit IRC
100 2016-06-30T10:23:54  *** fengling has joined #bitcoin-core-dev
101 2016-06-30T10:25:35  *** davec_ has joined #bitcoin-core-dev
102 2016-06-30T10:29:48  *** afk11 has quit IRC
103 2016-06-30T10:31:45  *** paveljanik has quit IRC
104 2016-06-30T10:37:42  *** afk11 has joined #bitcoin-core-dev
105 2016-06-30T10:37:42  *** afk11 has quit IRC
106 2016-06-30T10:37:42  *** afk11 has joined #bitcoin-core-dev
107 2016-06-30T10:41:31  *** ratoder has quit IRC
108 2016-06-30T10:41:46  *** Alopex has quit IRC
109 2016-06-30T10:41:51  *** jonasschnelli has quit IRC
110 2016-06-30T10:49:22  *** jonasschnelli has joined #bitcoin-core-dev
111 2016-06-30T10:53:07  *** Alopex has joined #bitcoin-core-dev
112 2016-06-30T10:55:26  *** fengling has quit IRC
113 2016-06-30T11:01:33  *** cryptapus has joined #bitcoin-core-dev
114 2016-06-30T11:20:49  *** jonasschnelli has quit IRC
115 2016-06-30T11:20:49  *** jonasschnelli has joined #bitcoin-core-dev
116 2016-06-30T11:36:11  *** pmienk_ has quit IRC
117 2016-06-30T11:36:35  *** pmienk_ has joined #bitcoin-core-dev
118 2016-06-30T11:50:57  *** belcher has joined #bitcoin-core-dev
119 2016-06-30T12:15:51  *** paveljanik has joined #bitcoin-core-dev
120 2016-06-30T12:34:16  *** Chris_Stewart_5 has joined #bitcoin-core-dev
121 2016-06-30T12:48:54  *** Chris_Stewart_5 has quit IRC
122 2016-06-30T12:52:57  *** cryptapus_ has joined #bitcoin-core-dev
123 2016-06-30T12:56:21  *** cryptapus has quit IRC
124 2016-06-30T13:04:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
125 2016-06-30T13:49:02  *** murch has quit IRC
126 2016-06-30T13:49:28  *** murch has joined #bitcoin-core-dev
127 2016-06-30T14:00:18  *** murch1 has joined #bitcoin-core-dev
128 2016-06-30T14:01:12  *** murch has quit IRC
129 2016-06-30T14:13:02  *** harrymm has quit IRC
130 2016-06-30T14:20:19  <GitHub96> [bitcoin] jmcorgan closed pull request #8284: Backport remaining commits for out-of-tree builds from master to 0.12 branch (0.12...build-oot-0.12) https://github.com/bitcoin/bitcoin/pull/8284
131 2016-06-30T14:32:04  *** Giszmo has joined #bitcoin-core-dev
132 2016-06-30T14:34:52  *** harrymm has joined #bitcoin-core-dev
133 2016-06-30T14:38:32  *** rubensayshi has quit IRC
134 2016-06-30T14:40:13  *** rubensayshi has joined #bitcoin-core-dev
135 2016-06-30T14:56:15  *** bsm1175321 has joined #bitcoin-core-dev
136 2016-06-30T14:58:00  *** pmienk_ has quit IRC
137 2016-06-30T14:58:48  *** harrymm has quit IRC
138 2016-06-30T14:59:53  *** cryptapus_ is now known as cryptapus
139 2016-06-30T15:01:44  <sdaftuar> proposed topic for the meeting today: wrapping up the mining-related changes to 0.13.0 (please see #8294)
140 2016-06-30T15:04:26  *** [Author] has quit IRC
141 2016-06-30T15:06:49  *** cryptapus has quit IRC
142 2016-06-30T15:07:02  *** cryptapus has joined #bitcoin-core-dev
143 2016-06-30T15:09:37  *** [Author] has joined #bitcoin-core-dev
144 2016-06-30T15:25:41  *** zooko has joined #bitcoin-core-dev
145 2016-06-30T15:30:34  *** Chris_Stewart_5 has quit IRC
146 2016-06-30T15:40:17  *** frankenmint has joined #bitcoin-core-dev
147 2016-06-30T15:41:26  *** Chris_Stewart_5 has joined #bitcoin-core-dev
148 2016-06-30T15:59:36  *** spudowiar has joined #bitcoin-core-dev
149 2016-06-30T16:00:27  *** Chris_Stewart_5 has quit IRC
150 2016-06-30T16:09:14  *** jtimon has joined #bitcoin-core-dev
151 2016-06-30T16:10:57  <jtimon> since then does AcceptToMemoryPoolWorker take a bool* pfMissingInputs parameter instead of just logging a validation error and returning false?
152 2016-06-30T16:11:30  <jtimon> that's a consensus check, do we plan to pass bool* pfMissingInputs to libconsensus' veryfyTx too?
153 2016-06-30T16:12:31  <sipa> since 0.1.0
154 2016-06-30T16:12:43  <sipa> it's literally been there in every release ever
155 2016-06-30T16:13:01  *** davec_ has quit IRC
156 2016-06-30T16:13:56  *** davec_ has joined #bitcoin-core-dev
157 2016-06-30T16:15:00  <jtimon> mhmm, somehow I remember return state.DoS(missing inputs) in https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1236
158 2016-06-30T16:15:33  <jtimon> may have been in one of my consensus branches...
159 2016-06-30T16:17:02  *** Chris_Stewart_5 has joined #bitcoin-core-dev
160 2016-06-30T16:17:53  <jtimon> never mind, I must have dreamed it or something
161 2016-06-30T16:18:21  <sipa> Sounds like a nice dream.
162 2016-06-30T16:20:35  *** jtimon has quit IRC
163 2016-06-30T16:22:55  <GitHub6> [bitcoin] sdaftuar opened pull request #8295: Mining-related fixups for 0.13.0 (master...cnb-segwit) https://github.com/bitcoin/bitcoin/pull/8295
164 2016-06-30T16:27:46  *** Frederic94500 has joined #bitcoin-core-dev
165 2016-06-30T16:33:50  *** Sosumi has quit IRC
166 2016-06-30T16:36:05  *** Lysanders has joined #bitcoin-core-dev
167 2016-06-30T16:38:19  *** murch1 has quit IRC
168 2016-06-30T16:39:58  *** Chris_Stewart_5 has quit IRC
169 2016-06-30T16:40:27  *** Chris_Stewart_5 has joined #bitcoin-core-dev
170 2016-06-30T16:45:28  *** Chris_Stewart_5 has quit IRC
171 2016-06-30T16:46:19  *** kadoban has joined #bitcoin-core-dev
172 2016-06-30T16:48:44  *** [b__b] has quit IRC
173 2016-06-30T16:50:10  *** harrymm has joined #bitcoin-core-dev
174 2016-06-30T16:50:56  *** [b__b] has joined #bitcoin-core-dev
175 2016-06-30T16:52:51  *** MarcoFalke has left #bitcoin-core-dev
176 2016-06-30T16:54:40  *** harrymm has quit IRC
177 2016-06-30T16:55:57  *** bsm1175321 has quit IRC
178 2016-06-30T16:58:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
179 2016-06-30T17:01:29  *** dingus is now known as grubles
180 2016-06-30T17:02:03  *** bsm1175321 has joined #bitcoin-core-dev
181 2016-06-30T17:11:31  *** pmienk has joined #bitcoin-core-dev
182 2016-06-30T17:17:21  *** Chris_Stewart_5 has quit IRC
183 2016-06-30T17:20:52  *** pmienk has quit IRC
184 2016-06-30T17:25:06  *** frankenmint has quit IRC
185 2016-06-30T17:32:55  *** pmienk has joined #bitcoin-core-dev
186 2016-06-30T17:33:17  *** Chris_Stewart_5 has joined #bitcoin-core-dev
187 2016-06-30T17:39:24  *** [b__b] has quit IRC
188 2016-06-30T17:44:27  *** [b__b] has joined #bitcoin-core-dev
189 2016-06-30T17:55:45  <GitHub138> [bitcoin] MarcoFalke opened pull request #8296: [qa] Make setup_chain private (master...Mf1607-qaSetupChain) https://github.com/bitcoin/bitcoin/pull/8296
190 2016-06-30T17:57:30  *** roasbeef_ is now known as roasbeef
191 2016-06-30T18:00:12  *** spudowiar has quit IRC
192 2016-06-30T18:00:56  *** Sosumi has joined #bitcoin-core-dev
193 2016-06-30T18:04:08  *** rubensayshi has quit IRC
194 2016-06-30T18:09:33  *** Arnavion has quit IRC
195 2016-06-30T18:11:57  *** Arnavion has joined #bitcoin-core-dev
196 2016-06-30T18:18:49  *** pedrobranco has quit IRC
197 2016-06-30T18:19:22  *** pedrobranco has joined #bitcoin-core-dev
198 2016-06-30T18:20:46  *** pedrobra_ has joined #bitcoin-core-dev
199 2016-06-30T18:20:48  *** pedrobranco has quit IRC
200 2016-06-30T18:21:12  *** MarcoFalke has joined #bitcoin-core-dev
201 2016-06-30T18:25:25  *** pedrobra_ has quit IRC
202 2016-06-30T18:25:53  *** frankenmint has joined #bitcoin-core-dev
203 2016-06-30T18:30:44  *** frankenmint has quit IRC
204 2016-06-30T18:33:18  *** cjcj has quit IRC
205 2016-06-30T18:38:16  *** pedrobranco has joined #bitcoin-core-dev
206 2016-06-30T18:43:09  *** pedrobranco has quit IRC
207 2016-06-30T18:45:57  *** Prattler has joined #bitcoin-core-dev
208 2016-06-30T18:47:26  *** Prattler has left #bitcoin-core-dev
209 2016-06-30T18:49:55  *** spudowiar has joined #bitcoin-core-dev
210 2016-06-30T18:56:30  *** jtimon has joined #bitcoin-core-dev
211 2016-06-30T19:00:25  <MarcoFalke> no meeting?
212 2016-06-30T19:00:36  <sdaftuar> i'm here!
213 2016-06-30T19:00:36  <gmaxwell> Yes meeting.
214 2016-06-30T19:01:02  <sipa> i ' m   h e r e
215 2016-06-30T19:01:10  <gmaxwell> #startmeeting
216 2016-06-30T19:01:10  <lightningbot> Meeting started Thu Jun 30 19:01:10 2016 UTC.  The chair is gmaxwell. Information about MeetBot at http://wiki.debian.org/MeetBot.
217 2016-06-30T19:01:10  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
218 2016-06-30T19:01:13  <btcdrak> ping
219 2016-06-30T19:01:17  <wumpus> pong
220 2016-06-30T19:01:20  *** TheFactory7 has joined #bitcoin-core-dev
221 2016-06-30T19:01:20  <sipa> pang
222 2016-06-30T19:01:26  <gmaxwell> Welcome to the meeting. Hard start today, sorry to not get pings out earlier.
223 2016-06-30T19:01:35  <jonasschnelli> pong
224 2016-06-30T19:01:47  <wumpus> <sdaftuar> proposed topic for the meeting today: wrapping up the mining-related changes to 0.13.0 (please see #8294)
225 2016-06-30T19:02:01  <gmaxwell> wumpus: jtimon: jonasschnelli: petertodd: morcos: MarcoFalke: NicolasDorier: paveljanik:
226 2016-06-30T19:02:06  <jtimon> pong
227 2016-06-30T19:02:27  <gmaxwell> #topic wrapping up the mining-related changes to 0.13.0 (please see #8294)
228 2016-06-30T19:02:32  <wumpus> also segwit 0.12 backport status, maybe
229 2016-06-30T19:02:39  <sipa> unstarted.
230 2016-06-30T19:03:21  <sdaftuar> so i mentioned a few things in that issue that i think we need to address for 0.13.0
231 2016-06-30T19:03:22  <petertodd> hi
232 2016-06-30T19:03:30  <sdaftuar> a couple should be non-controversial bugfixes
233 2016-06-30T19:03:41  <kanzure> hi
234 2016-06-30T19:03:48  <gmaxwell> sdaftuar: blockminsize  should just go
235 2016-06-30T19:03:57  <sdaftuar> two things i wanted feedback on were (a) removing the old mining algorithm ("addScoreTxs") and (b) -blockminsize
236 2016-06-30T19:04:01  <sdaftuar> ok great, that's what i think too
237 2016-06-30T19:04:02  <sipa> in favor of just dropping -blockminsize
238 2016-06-30T19:04:21  <gmaxwell> sdaftuar: "Should we remove the old transaction selection algorithm"   I'm indifferent to favoring removing code.
239 2016-06-30T19:04:30  <gmaxwell> luke-jr: your thoughts?
240 2016-06-30T19:04:52  <wumpus> if the code is not used, it should be removed
241 2016-06-30T19:04:56  <gmaxwell> (like to sdaftuar's issue: https://github.com/bitcoin/bitcoin/issues/8294 )
242 2016-06-30T19:04:56  <sipa> i think we shouldn't keep the old algorithm just because we're not sure if the new one works
243 2016-06-30T19:05:02  <sipa> we can always revert code if needed
244 2016-06-30T19:05:35  <sipa> the current reason for keeping is because when -blockminsiz or -blockmaxsize are -blockprioritysize are given, the new algorithm does not work (due to missing accounting)
245 2016-06-30T19:05:49  <sipa> if we fix the accounting, and make the new algorithm support those parameters, the old algorithm can go
246 2016-06-30T19:05:55  <sdaftuar> sipa: right, and that is addressed in the first commit of #8295
247 2016-06-30T19:05:59  <gmaxwell> the only gain I see is if there is some stupidity in the new one the old one is a switch away... but the new one has a reasonable amount of testing and if it has some issue it seems unlikely that its so major that just fixing it wouldn't be the prefered solution.
248 2016-06-30T19:06:02  <sipa> ok, grea;t i haven't looked
249 2016-06-30T19:06:08  <jtimon> I don't remember addScoreTx, but ack on removing blockminsize
250 2016-06-30T19:06:43  <wumpus> it's a bit late in the release to be removing arguments, on the other hand it was already not working so let's do it...
251 2016-06-30T19:07:01  <wumpus> as long as it's documented in the release notes
252 2016-06-30T19:07:13  <gmaxwell> it should be removed but not cause the daemon to fail to start if specified.
253 2016-06-30T19:07:15  <sdaftuar> wumpus: agree, the release notes need a bunch of writeup for all the mining changes
254 2016-06-30T19:07:16  <wumpus> or e.g. emit a warning/error if it is provided
255 2016-06-30T19:07:31  <sipa> i am perfectly fine with just making -blockminsize work for 0.13 with CPFP, and removing it in 0.14
256 2016-06-30T19:07:52  <sipa> sdaftuar: unless you think that would be much more work (i think it would be deleting 2 lines to stop supporting it)
257 2016-06-30T19:08:08  <wumpus> sounds like that would be a waste of work, if it is going to be removed anyway, but I don't know how much work it is
258 2016-06-30T19:08:15  <sdaftuar> sipa: it'd be adding code to support it.  i think it's probably easy, but i haven't thought carefully about it.  probably a one line change.
259 2016-06-30T19:08:32  <sipa> i expect it to be trivial to make it work, and also trivial to remove
260 2016-06-30T19:08:48  <wumpus> if it's trivial to make it work, let's go for that
261 2016-06-30T19:08:50  <sipa> also, i think it's utterly pointless in the current mining encironment
262 2016-06-30T19:08:53  <sdaftuar> sipa: agreed.
263 2016-06-30T19:09:03  <jtimon> emit warning seems a good option
264 2016-06-30T19:09:19  <gmaxwell> I think it's a goofy option.
265 2016-06-30T19:09:20  <wumpus> if it's not trivial, or annoying to test, let's get rid of it
266 2016-06-30T19:09:26  <gmaxwell> less options good.
267 2016-06-30T19:09:28  <sipa> ack, we could just test for its value, and fail at startup if a nonzero value is passed
268 2016-06-30T19:09:31  <sdaftuar> we have no tests for it now, i believe.
269 2016-06-30T19:09:36  <sipa> it has no tests
270 2016-06-30T19:09:38  <sipa> pretty sure
271 2016-06-30T19:09:47  *** Chris_Stewart_5 has quit IRC
272 2016-06-30T19:09:54  <sdaftuar> my preference would be to get rid of it, rather than add a test to make sure it works.
273 2016-06-30T19:10:07  <sipa> sdaftuar: will review your patch
274 2016-06-30T19:10:08  <wumpus> right, that's fine
275 2016-06-30T19:10:26  *** Bootvis has joined #bitcoin-core-dev
276 2016-06-30T19:10:32  <jtimon> gmaxwell: why you don't want it to fail if the argument is provided ?
277 2016-06-30T19:11:04  <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon luke-jr cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
278 2016-06-30T19:11:14  <gmaxwell> (sorry, just creating a ping macro for future use)
279 2016-06-30T19:11:37  <michagogo> Oh
280 2016-06-30T19:11:38  <michagogo> Hi
281 2016-06-30T19:11:43  <sdaftuar> jtimon: my preference for not causing failure is that that would be extra code to write/test/review.  silent failure seems easier, and harmless in this situation.
282 2016-06-30T19:11:49  <gmaxwell> jtimon: because it's a mostly meaningless setting that some people are going to have by virtue of copy and pasting things.
283 2016-06-30T19:11:56  <sipa> meh, ok
284 2016-06-30T19:11:57  <kanzure> i nominate jtimon for double inclusion in the ping, but otherwise ACK
285 2016-06-30T19:12:02  <wumpus> I don't really like ignoring options, that can be really frustrating
286 2016-06-30T19:12:25  <wumpus> 'wtf doesn't this work', oh, then after an hour of debugging you notice that the functionality has been removed
287 2016-06-30T19:12:31  <sipa> agree
288 2016-06-30T19:12:36  <sdaftuar> wumpus: in this case though, you wouldn't have been noticing the old behavior "working"
289 2016-06-30T19:12:38  <wumpus> at least add a warning, I don't care about failing
290 2016-06-30T19:12:39  <jtimon> I'm fine with either failing or giving a warning
291 2016-06-30T19:12:46  <sdaftuar> i can add a warning, sure.
292 2016-06-30T19:12:54  <sipa> let's discuss this when the actual PR is created
293 2016-06-30T19:13:01  <jtimon> fair enough
294 2016-06-30T19:13:03  <sdaftuar> i included removal of -blockminsize in 8295
295 2016-06-30T19:13:14  <sdaftuar> i can fix to warn if the argument is given
296 2016-06-30T19:13:20  <wumpus> great
297 2016-06-30T19:13:23  <gmaxwell> okay warning fine.
298 2016-06-30T19:14:08  <sdaftuar> one thing i wanted to mention, if we do decide to remove addScoreTxs(), we could also remove the mining_score from the mempool multiindex
299 2016-06-30T19:14:15  <gmaxwell> wumpus: I agree in principle except for the fact that a LOT of people have copied the "example config" from the bitcoin wiki and are setting all kinds of crazy things. :)
300 2016-06-30T19:14:23  <sdaftuar> i didn't incldue that in 8295, but wanted to mention it in case we want to remove for 0.13
301 2016-06-30T19:14:39  <sdaftuar> it would give us a small memory savings in the mempool, but not sure if that's a change that we'd rather wait for 0.14 tomake
302 2016-06-30T19:14:43  <sdaftuar> i don't have a preference
303 2016-06-30T19:14:50  <sipa> ENOCARE
304 2016-06-30T19:15:00  <jtimon> sdaftuar: can't https://github.com/bitcoin/bitcoin/pull/8295/commits/27362dda4d583a43ebf687ae097d2f45ba1c4c32 be a trivial to review separate PR ?
305 2016-06-30T19:15:03  <wumpus> gmaxwell: yes, indeed, it's an option that's bound to be misinterpreted/misused anyway
306 2016-06-30T19:15:16  <gmaxwell> <meme text="Delete all the code."/>
307 2016-06-30T19:15:42  <sdaftuar> jtimon: it builds on removing addScoreTxs i think?
308 2016-06-30T19:15:51  <jtimon> sdaftuar: oh, I see
309 2016-06-30T19:15:59  <sdaftuar> jtimon: but yes i could have split those two commits out
310 2016-06-30T19:16:00  <jtimon> mhmm
311 2016-06-30T19:16:52  <gmaxwell> Okay, anything more on this that needs to happen in the meeting?
312 2016-06-30T19:16:54  <jtimon> whatever, minor point, I just don't think I can ack the pr like that because I haven't been following some of the refactors in miner much
313 2016-06-30T19:17:33  <sdaftuar> i think we can move on, thanks
314 2016-06-30T19:17:35  <jtimon> well, refactors and changes
315 2016-06-30T19:17:40  <wumpus> sdaftuar: I'd say if they are after your changes remove the mempool fields, it's not much of a risk, if everything is alright the compiler checks that nothing is referring to it
316 2016-06-30T19:17:54  <sdaftuar> wumpus: ok great, thanks
317 2016-06-30T19:18:00  *** Chris_Stewart_5 has joined #bitcoin-core-dev
318 2016-06-30T19:18:03  <sdaftuar> i'll defer that until after 8295 is merged anyway
319 2016-06-30T19:18:10  <wumpus> right, it's not a priority
320 2016-06-30T19:18:12  <sdaftuar> yep
321 2016-06-30T19:18:25  <wumpus> any other topics for today?
322 2016-06-30T19:18:53  <CodeShark> hmm
323 2016-06-30T19:19:05  <petertodd> anyone get a chnace to look at https://github.com/bitcoin/bitcoin/issues/8279 ? at a conf right now
324 2016-06-30T19:19:27  <sipa> petertodd: yes, i think it is a good point
325 2016-06-30T19:19:42  <petertodd> sipa: cool, thanks
326 2016-06-30T19:19:48  <sdaftuar> sipa: you noticed a related issue as well, right?
327 2016-06-30T19:19:56  <petertodd> sipa: (mainly wanted to know if I needed to post a retraction!)
328 2016-06-30T19:20:37  <sipa> sdaftuar: the sigops counting? i believe that is not vulnerable to mauling (the verb related to 'malleability', apparently)
329 2016-06-30T19:20:42  <sipa> (also not found by me)
330 2016-06-30T19:20:43  <gmaxwell> #topic segwit
331 2016-06-30T19:21:02  <sdaftuar> sipa: it is, because we don't verify that the witness script matches the commitment in the pubkey output
332 2016-06-30T19:21:08  <sdaftuar> right?
333 2016-06-30T19:21:28  <petertodd> sdaftuar: no, I think we do that prior to sigops checking
334 2016-06-30T19:21:48  <sdaftuar> i'll take another look.  pretty sure sipa and i discussed and concluded that we didn't.
335 2016-06-30T19:21:52  <sipa> sdaftuar: something to look into
336 2016-06-30T19:22:13  <petertodd> sdaftuar: yeah, wouldn't hurt to take another look - that review was a bunch of owrk and I may have been a bit faded by the end :)
337 2016-06-30T19:22:35  <sipa> i don't think these are serious problems (it allows preventing a node from getting a transaction, but there are other means for that, like announcing it and not responding)
338 2016-06-30T19:22:39  <sdaftuar> petertodd: i'm specifically referring to the sigopcount checks in accepttomemorypool, not consensus level checking
339 2016-06-30T19:22:43  <sipa> but they should be understood
340 2016-06-30T19:23:04  *** Chris_Stewart_5 has quit IRC
341 2016-06-30T19:23:16  <petertodd> sdaftuar: yeah, I _thought_ I looked at that, but may have missed it - mempool was the last thing I looked at
342 2016-06-30T19:23:51  <sipa> petertodd: i'm really glad you did that review, by the way - the writeup makes a lot of things more communicatable
343 2016-06-30T19:24:08  <petertodd> sipa: thanks! yeah, mainly wanted to demystify the process of doing review
344 2016-06-30T19:24:47  <gmaxwell> I don't think its of major importance, but "Bitcoin XT" recently started making only outbound connections to other XT nodes.  In combination with segwit, I believe this will partition them.  Because they are such a small number of nodes I don't think it warrents much attention, but something to be aware of.
345 2016-06-30T19:24:47  *** laurentmt has joined #bitcoin-core-dev
346 2016-06-30T19:25:28  <gmaxwell> petertodd: yea, nice work.
347 2016-06-30T19:25:30  <sdaftuar> gmaxwell: we have a little time before that will happen, as we haven't yet activated the preferential peering yet
348 2016-06-30T19:25:40  <gmaxwell> sdaftuar: indeed.
349 2016-06-30T19:26:22  <petertodd> gmaxwell: ...
350 2016-06-30T19:26:52  <sipa> segwit by the way does not _only_ make outbound connections to segwit
351 2016-06-30T19:26:58  <sipa> but it strongly prefers them
352 2016-06-30T19:27:12  *** Chris_Stewart_5 has joined #bitcoin-core-dev
353 2016-06-30T19:27:14  <petertodd> sipa: yeah, I noticed that - after 40 tries you connect to non-segwit outgoing
354 2016-06-30T19:27:22  <gmaxwell> sipa: right, I think that would be sufficient to partition there.
355 2016-06-30T19:27:26  <sipa> petertodd: yes, totally arbitrary number
356 2016-06-30T19:28:06  <jl2012> gmaxwell: they should fix that. We just need to let them know
357 2016-06-30T19:28:07  <petertodd> wouln't be a crazy idea to have a mode that disabled the DoS banning for incoming nodes btw...
358 2016-06-30T19:28:31  <sipa> petertodd: DoS banning, or also DoS disconnection?
359 2016-06-30T19:28:48  <gmaxwell> petertodd: one can set that threshold arbritarily high at least.
360 2016-06-30T19:28:56  <petertodd> sipa: both, to be able to (at least temproarily) work around bugs related to DoS banning
361 2016-06-30T19:29:24  <petertodd> sipa: equally, have a small subset of nodes that can be set to ignore the DoS banning
362 2016-06-30T19:29:38  <gmaxwell> Patch accepted to make low-dos-score a ranking criteria in eviction protection logic, which would also make running with a very high dos threshold more reasonable.
363 2016-06-30T19:29:56  <petertodd> gmaxwell: good idea
364 2016-06-30T19:30:50  <gmaxwell> jl2012: I was just made aware of it, but sure.
365 2016-06-30T19:31:02  <gmaxwell> my past expirence with that project has not been very good.
366 2016-06-30T19:31:14  <wumpus> so a different ban thrshold for incoming versus outgoing connections?
367 2016-06-30T19:31:25  <petertodd> jl2012: there's a issue open in the XT repo for it already
368 2016-06-30T19:31:37  <btcdrak> jl2012: there is a ticket open already
369 2016-06-30T19:31:54  <gmaxwell> petertodd: we should probably just brainstorm some about connection management stuff, there are a number of neat improvements we can make.
370 2016-06-30T19:32:11  <sipa> if we're thinking about such refactors, the DoS score should probably also attenuate over time
371 2016-06-30T19:32:14  <petertodd> wumpus: I think the main thing, is just to have different thresholds period for some nodes, so that while you won't wast bandwidth on everyone, keep a few peers connected regardless in case you're dealing with a DoS-related bug and should be distributing the data anyway
372 2016-06-30T19:32:31  <sipa> otherwise longer-lived connections will accumulate a score they don't deserve
373 2016-06-30T19:32:35  <wumpus> petertodd: so a sort of halfway-whitelisting
374 2016-06-30T19:32:39  <petertodd> wumpus: also, along those lines, distributing invalid blocks with valid PoW isn't a crazy idea
375 2016-06-30T19:32:42  <petertodd> wumpus: yup
376 2016-06-30T19:32:45  <gmaxwell> petertodd: such a thing could also turn those peers into blocksonly.
377 2016-06-30T19:32:51  <gmaxwell> since thats all we care about for anti-partitioning.
378 2016-06-30T19:32:52  <petertodd> gmaxwell: yeah, that's a good idea
379 2016-06-30T19:33:02  <gmaxwell> and yet it almost completely eliminates dos concerns.
380 2016-06-30T19:33:36  *** laurentmt has quit IRC
381 2016-06-30T19:34:42  <petertodd> blocksonly on-DoS + relaying of invalid blocks w/ valid PoW in a separate "may be invalid" message would satisfy everything I think
382 2016-06-30T19:34:53  <wumpus> sipa: attentuating theDoS score over time makes sense, a very slow DoS attack isn't really a DoS attack (apart from keeping a connection slot open, but that's not what the score is to protect against)
383 2016-06-30T19:35:27  <sipa> theDos? sister of GLaDoS?
384 2016-06-30T19:35:34  <petertodd> sipa: lol
385 2016-06-30T19:35:37  <btcdrak> omg
386 2016-06-30T19:36:03  <wumpus> then again it's not really a anti-DoS score is it, it won't get triggered on accidental over-use of resources, more a misbehavior score
387 2016-06-30T19:36:23  <wumpus> hehe
388 2016-06-30T19:36:37  <sipa> yes, i think there may be reasons to introduce something like a "resource usage score" which is distinct from "misbehaviour"
389 2016-06-30T19:36:40  <wumpus> the cake is a lie
390 2016-06-30T19:36:51  <sipa> and which gets used to decide which peers to disconnect in favor of others
391 2016-06-30T19:36:57  <sipa> but never causes a ban
392 2016-06-30T19:37:03  <wumpus> yes, indeed
393 2016-06-30T19:37:15  <sipa> not a disconnection, unless there is a pressing reason to disconnect someone anyway
394 2016-06-30T19:37:23  <petertodd> wumpus: might not be a bad idea to go through the DoS stuff and remove bans in cases where the misbehavior doesn't take much cpu time to detect (and then use it in the anti-partitioning score instead)
395 2016-06-30T19:37:46  <gmaxwell> yea, I think there is a lot we can do here.
396 2016-06-30T19:38:21  <gmaxwell> So-- the issue of dbcache that I brought up last week can we talk about that for a bit?
397 2016-06-30T19:38:27  <sipa> ack topic
398 2016-06-30T19:38:30  <wumpus> sure
399 2016-06-30T19:38:31  <gmaxwell> #topic dbcache
400 2016-06-30T19:38:50  <wumpus> petertodd: agreed
401 2016-06-30T19:38:56  <gmaxwell> Last week I brought up that reindex with defaults was SUPER slow on my laptop, been a while since I'd reindexed with default dbcache.
402 2016-06-30T19:39:29  <gmaxwell> This resulted in more benchmarking, and wumpus has a PR to increase the default dbcache to 300mb and also clamp the leveldb cache usage (so that it doesn't go gigantic as dbcache increases)
403 2016-06-30T19:39:30  <wumpus> the pull request to bump default dbcache to 300MiB is ready: https://github.com/bitcoin/bitcoin/pull/8273
404 2016-06-30T19:39:44  <gmaxwell> I did testing to confirm that the leveldb cache sizes don't have much effect.
405 2016-06-30T19:39:58  <gmaxwell> they seem like they have more effect with txindex enabled, however.
406 2016-06-30T19:40:03  * jonasschnelli will test 8273
407 2016-06-30T19:40:31  <wumpus> which makes sense, txindex has a completely different access pattern than the utxo set
408 2016-06-30T19:40:34  <wumpus> it's almost write-only
409 2016-06-30T19:40:43  <sipa> morcos: no more work on #6936?
410 2016-06-30T19:40:52  <gmaxwell> As a related aside txindex performance is fairly slow, makes an 'infinite' dbcache reindex by about 25%.
411 2016-06-30T19:40:56  <wumpus> so we could cap that at a different value
412 2016-06-30T19:41:20  <sipa> txindex adds many many more writes
413 2016-06-30T19:41:29  <gmaxwell> wumpus: yes, ran a test with 32mb which has finished but I didn't have time before the meeting to collect the results, will shortly after.
414 2016-06-30T19:41:31  <sipa> though they should be configured to bypass all caches
415 2016-06-30T19:41:33  <wumpus> yes txindex is very slow, just a lot of data
416 2016-06-30T19:41:47  <gmaxwell> my testing is on a fast spinning disk system, which I think is probaby the right thing to test for on this.
417 2016-06-30T19:42:00  <sdaftuar> sipa: oh, morcos and i were just talking about whether there were things we were working on that used the mining score index, but i think we had both forgotten about #6936.
418 2016-06-30T19:42:16  <wumpus> even the idea of indexing every transaction on the block chain is crazy
419 2016-06-30T19:42:32  <jonasschnelli> My last tests showd me that a reindex (master) was twice as long as a a normal IDB (from rnd peers) from the scratch...
420 2016-06-30T19:42:44  <wumpus> there's much slower implementations possible though, like stashing everything into mysql :-)
421 2016-06-30T19:42:55  <sipa> jonasschnelli: wut?!
422 2016-06-30T19:42:55  <gmaxwell> One result of my testing is showing that even the 300MB dbcache is really not big enough to give good reindex performance.  We should consider something for 0.14 to give mempool memory to dbcache during ibd/reindex or something.
423 2016-06-30T19:43:17  <gmaxwell> jonasschnelli: that last test was before the signature checking fix?
424 2016-06-30T19:43:19  <jonasschnelli> sipa: 5.5h reindex against ~3h IBD
425 2016-06-30T19:43:20  <wumpus> jonasschnelli: whoa
426 2016-06-30T19:43:28  <jonasschnelli> I'm redoing it now...
427 2016-06-30T19:43:32  <gmaxwell> jonasschnelli: when was it?
428 2016-06-30T19:43:36  <sipa> jonasschnelli: what part of that was real reindex, and what was chainstate rebuilding?
429 2016-06-30T19:43:39  <wumpus> I thought we solved that recently
430 2016-06-30T19:43:40  <jonasschnelli> a couple of weeks ago after sipas work
431 2016-06-30T19:43:51  <jonasschnelli> sipa: just a plain -reindex
432 2016-06-30T19:43:57  <jonasschnelli> wth dbcache=8000
433 2016-06-30T19:44:10  <sipa> that's painful
434 2016-06-30T19:44:15  <gmaxwell> Reindex now has that header scan, it adds about 20 minutes on my test hosts that a sync wouldn't have.
435 2016-06-30T19:44:32  <sipa> jonasschnelli: can you benchmark -reindex-chainstate vs IBD?
436 2016-06-30T19:44:35  <wumpus> that can't make the difference between 3h and 5.5h though
437 2016-06-30T19:44:44  <gmaxwell> but I tested with and without signature checking, and in both cases reindex in master is faster than 0.12.1.
438 2016-06-30T19:44:45  <jonasschnelli> sipa: okay. Will do.
439 2016-06-30T19:44:51  <wumpus> 20 minutes difference would be ok
440 2016-06-30T19:45:10  <sipa> it may depend on your disk
441 2016-06-30T19:45:29  <gmaxwell> I didn't test an IBD but I can easily do that. We do probably lose some time due to out of order blocks.
442 2016-06-30T19:45:34  <jonasschnelli> Also there is the potential_deadlock_detected that stops my node (-debug) every couple of minutes..
443 2016-06-30T19:45:35  <sipa> if it's a VM with a file-backed storage which is on a network filesystem stored on an encrypted ZFS container...
444 2016-06-30T19:46:05  <sipa> jonasschnelli: i hope your normal benchmarks are not with -debug builds
445 2016-06-30T19:46:06  <wumpus> lock debugging slows down the sync too
446 2016-06-30T19:46:29  <sipa> additionally, we need to fix that bug
447 2016-06-30T19:46:39  <sipa> i'll look into that lockorder
448 2016-06-30T19:46:44  <wumpus> but yes, the deadlock detected in the network code seems to be a real deadlock
449 2016-06-30T19:46:58  <jonasschnelli> wumpus: yes. Agree. But i have compare -debug IBD against -debug reindex
450 2016-06-30T19:47:07  <sipa> jonasschnelli: meh, don't do that
451 2016-06-30T19:47:17  <sipa> debug is not ever going to give you a realistic benchmark
452 2016-06-30T19:47:32  <jonasschnelli> developer are supposed to run --enable-debug software! :)
453 2016-06-30T19:47:36  <wumpus> do we have an issue open for that deadlock issue btw?
454 2016-06-30T19:47:42  <sipa> jonasschnelli: yes, but not for benchmarking
455 2016-06-30T19:47:49  <gmaxwell> #topic net deadlock
456 2016-06-30T19:47:50  <jonasschnelli> wumpus: no. Let me open one.
457 2016-06-30T19:47:56  <sipa> jonasschnelli: thanks
458 2016-06-30T19:48:07  <jonasschnelli> sipa: Yes. Agree... will benchmark again without -debug
459 2016-06-30T19:48:14  <sipa> jonasschnelli: please list your exact commit (so we can identify the line numbers)
460 2016-06-30T19:48:27  <jonasschnelli> okay. Good point.
461 2016-06-30T19:49:13  <gmaxwell> #action jonasschnelli to open issue on lockorder deadlock report that he's seeing
462 2016-06-30T19:49:17  <gmaxwell> Any other topics?
463 2016-06-30T19:50:25  <gmaxwell> okay Seems quiet, perhaps we can end a bit early.
464 2016-06-30T19:50:29  <sdaftuar> maybe bip152?
465 2016-06-30T19:50:31  <wumpus> seemingly not :)
466 2016-06-30T19:50:34  <gmaxwell> ah okay!
467 2016-06-30T19:50:37  <sdaftuar> not sure if that's worht bringing up here
468 2016-06-30T19:50:39  <gmaxwell> #topic BIP152
469 2016-06-30T19:50:53  <gmaxwell> So sipa has SW BIP 152 working on testnet and a number of people testing it.
470 2016-06-30T19:51:11  <wumpus> good to hear
471 2016-06-30T19:51:31  <petertodd> gmaxwell: as in, segwit bip152 right? +1
472 2016-06-30T19:51:39  <btcdrak> I dont recall seeing a PR for that yet?
473 2016-06-30T19:51:42  <gmaxwell> petertodd: yes.
474 2016-06-30T19:51:50  <wumpus> there's no PR for that
475 2016-06-30T19:51:50  <sipa> btcdrak: intentionally not
476 2016-06-30T19:52:11  <sipa> 1) this allows us to test interaction between non-SW-BIP152 testnet and changed
477 2016-06-30T19:52:24  <sipa> 2) needs some BIP changes (in BIP144, BIP152, or a separate bip entirely)
478 2016-06-30T19:52:41  <sipa> 3) not necessary before the segwit softfork
479 2016-06-30T19:52:41  <petertodd> sipa: +1
480 2016-06-30T19:53:34  <sipa> branch: github.com/sipa/bitcoin/commits/segwitcb
481 2016-06-30T19:53:41  <wumpus> not necessary, but would be good to have it before the activation, otherwise CB will suddenly disable
482 2016-06-30T19:53:59  <sipa> indeed; it is necessary imho before activation in mastdr
483 2016-06-30T19:54:29  <gmaxwell> Thats my view.
484 2016-06-30T19:54:54  <wumpus> right, for 0.12 it makes no different, there's no cb there anyhow
485 2016-06-30T19:54:59  <gmaxwell> jinx
486 2016-06-30T19:55:01  <sipa> agree
487 2016-06-30T19:55:12  *** zooko has quit IRC
488 2016-06-30T19:55:22  <gmaxwell> In any case, it's working, didn't require anything too complicated. (says the guy who didn't write it)
489 2016-06-30T19:56:01  <sdaftuar> sipa, gmaxwell: i still think it'd be better if the information in a blocktxn message could be understood without any state. did i make any progress trying to convince you?
490 2016-06-30T19:56:23  <wumpus> there's no need to hurry it anyhow, CB and segwit separately are already huge changes, better to test them in isolation for now
491 2016-06-30T19:56:45  <gmaxwell> sdaftuar: only a very small amount.
492 2016-06-30T19:57:12  <sipa> sdaftuar: no strong opinion yet
493 2016-06-30T19:57:19  <gmaxwell> sdaftuar: we can talk more post meeting.
494 2016-06-30T19:57:30  <sdaftuar> sure
495 2016-06-30T19:58:32  <gmaxwell> okay, Anything else, we're almost out of time? :)
496 2016-06-30T19:58:48  <petertodd> ack endmeeting
497 2016-06-30T19:58:51  <gmaxwell> #endmeeting
498 2016-06-30T19:58:51  <lightningbot> Meeting ended Thu Jun 30 19:58:51 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
499 2016-06-30T19:58:51  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-30-19.01.html
500 2016-06-30T19:58:51  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-30-19.01.txt
501 2016-06-30T19:58:51  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-30-19.01.log.html
502 2016-06-30T19:58:55  <gmaxwell> Hurrah we ended early.
503 2016-06-30T19:59:05  <gmaxwell> :P
504 2016-06-30T19:59:11  <jonasschnelli> 1min! :)
505 2016-06-30T19:59:19  <gmaxwell> May your usage of the remaining minute be productive.
506 2016-06-30T19:59:21  <petertodd> heh, my clock must be off... :)
507 2016-06-30T19:59:31  <petertodd> brb, gonna fix ntp :)
508 2016-06-30T20:00:04  <sipa> doh, too late
509 2016-06-30T20:01:55  <gmaxwell> sdaftuar: So; I'm still trying to come up with a case where the offsets would be useful where were are not already keeping an equiivlent amount of state.  There are DOS reasons why we can't, say,  loadbalance getblocktxn fragments to all peers that have inved. But even if we have, keeping a list of indexes per peer is negligible additional state.
510 2016-06-30T20:02:05  <sdaftuar> sipa: btw morcos was away from his desk, but says he can look at the coins cache stuff again after 0.13 is branched off
511 2016-06-30T20:02:17  <sipa> sdaftuar: sounds good
512 2016-06-30T20:02:59  <sdaftuar> gmaxwell: basically you'd be tracking your last getblocktxn request to each peer
513 2016-06-30T20:03:48  *** Frederic94500 has quit IRC
514 2016-06-30T20:03:49  <sdaftuar> i agree you could do something like that, but this is also complicated, as you'd have to ensure you don't have more than one in-flight
515 2016-06-30T20:04:10  <gmaxwell> right, effectively the same information the peer would send back over the wire, you'd keep in memory.  You can have more than one in-flight per peer but not more than one for a given block.
516 2016-06-30T20:04:42  <sdaftuar> i guess my point is that it's a trivial amount of bandwidth use in order to do less bookkeeping in code
517 2016-06-30T20:04:51  <gmaxwell> But at the same time we could probably even DOS a peer that getblocktxned the same block multiple times. (and we should perhaps consider doing that)
518 2016-06-30T20:05:27  <sdaftuar> i think that's a bit too aggressive -- there are legitimate reasons you could do that i think
519 2016-06-30T20:05:35  <sdaftuar> ie if block reconstruction failed in an unexpected place
520 2016-06-30T20:05:43  <gmaxwell> it's maybe 0.4% overhead
521 2016-06-30T20:05:44  <sdaftuar> but you got insight from another peer
522 2016-06-30T20:06:41  <sdaftuar> i just don't want to overly limit what we can do with the p2p messages we're adding
523 2016-06-30T20:07:24  <sdaftuar> .4% is probably an upperbound on the overhead
524 2016-06-30T20:07:31  <gmaxwell> yes.
525 2016-06-30T20:08:29  <gmaxwell> sdaftuar: I agree on not limiting the usefulness but I really am just trying to get a case where I agree that it's actually helpful beyond reducing the state size slightly in an already stateful exchange.
526 2016-06-30T20:09:08  <gmaxwell> Because there is a cost-- the admitably trivial overhead, and the extra error conditions to test for.
527 2016-06-30T20:09:15  <sdaftuar> yeah, it'd be more useful if i had an implementation of something that used it that i could point to, which i sadly don't
528 2016-06-30T20:09:24  *** spudowiar has quit IRC
529 2016-06-30T20:09:51  <gmaxwell> I had a couple ideas, but then found that they didn't actually work. :)
530 2016-06-30T20:10:04  <sdaftuar> my intuition is that messages which can be interpreted on their own is more helpful for writing code.  this isn't super relevant for bitcoind, but imagine how much better it would be to look at historical data that can stand on its own, versus require state
531 2016-06-30T20:10:21  <sdaftuar> or writing tests that do strange things
532 2016-06-30T20:11:02  <gmaxwell> hah but thats part of my point: it adds more corner cases that need to be tested. E.g. what happens when the indexes weren't what you asked for but were correct, what happens if the txn are what you asked for but the indexes are correct?
533 2016-06-30T20:11:13  * gmaxwell steps out for lunch and to ruminate.
534 2016-06-30T20:11:32  * sdaftuar has to leave to catch a train anyway, will think about it some more
535 2016-06-30T20:16:24  <midnightmagic> hrm.. I like meetbot.
536 2016-06-30T20:17:32  *** MarcoFalke has left #bitcoin-core-dev
537 2016-06-30T20:17:47  <morcos> sipa: yes i'm happy to take another pass at keeping the cache warm.  but whats your current state of thinking with keeping the utxos by txid instead of by individual utxo?  we had discussed at one point changing that?
538 2016-06-30T20:18:14  <sipa> i think we should switch to individual utxo
539 2016-06-30T20:18:22  <sipa> but it's a pretty nontrivial change
540 2016-06-30T20:18:27  <morcos> yeah...
541 2016-06-30T20:18:35  <morcos> i wonder what the current overhead is
542 2016-06-30T20:18:57  <sipa> the one pain point is storage of per-tx information (height and coinbaseness)
543 2016-06-30T20:19:01  <sipa> and nversion
544 2016-06-30T20:19:12  <sipa> copied into each utxo, or still have some per txid state
545 2016-06-30T20:21:28  <morcos>  yeah maybe there is some hybrid that makes the most sense..   anyway, ok, just food for thought
546 2016-06-30T20:22:59  <sipa> in the storage format that means refcounting per txid, though
547 2016-06-30T20:23:04  <sipa> yuckness
548 2016-06-30T20:23:31  <sipa> or a read after write to see if any entries remain, and if not, delete the txid data
549 2016-06-30T20:24:16  <morcos> yeah, i was thinking more the latter, we kind of already do that right?
550 2016-06-30T20:24:28  <morcos> at the disk level for pruning
551 2016-06-30T20:24:43  <morcos> ugh sorry, bad choice of words, but think its called that in the code
552 2016-06-30T20:26:53  <morcos> maybe you could keep a bit field of the spentness of various vout#s in the txid level state, so when its in memory, you know whether any uncached vout#s are still unspent.
553 2016-06-30T20:44:09  *** spudowiar has joined #bitcoin-core-dev
554 2016-06-30T20:53:34  *** spudowiar has quit IRC
555 2016-06-30T20:55:43  *** droark has joined #bitcoin-core-dev
556 2016-06-30T21:18:54  *** zooko has joined #bitcoin-core-dev
557 2016-06-30T21:20:41  *** jannes has quit IRC
558 2016-06-30T21:28:04  *** Prattler has joined #bitcoin-core-dev
559 2016-06-30T21:29:06  *** Prattler has quit IRC
560 2016-06-30T21:30:05  <gmaxwell> own't the key overhead make the dataset much larger? whats the average outputs per key in the database today?
561 2016-06-30T21:32:59  *** Amnez777 has joined #bitcoin-core-dev
562 2016-06-30T21:33:44  *** Amnez777- has quit IRC
563 2016-06-30T21:36:14  *** jtimon has quit IRC
564 2016-06-30T21:37:14  <luke-jr> I don't see why the new algorithm can't work with blockmaxsize etc?
565 2016-06-30T21:37:48  <gmaxwell> because it will produce wrong results if blockmaxsize is the limited commodity.
566 2016-06-30T21:38:15  <gmaxwell> wrong in the sense of not picking the optimal block subject to that constraint.
567 2016-06-30T21:41:46  *** Prattler has joined #bitcoin-core-dev
568 2016-06-30T21:45:37  *** bsm1175321 has quit IRC
569 2016-06-30T21:45:38  *** face has quit IRC
570 2016-06-30T21:45:38  *** Taek has quit IRC
571 2016-06-30T21:47:13  <zooko> Hey Bitcoin core devs. Over in the Zcash project we occasionally do things which might be independently useful to Bitcoin core.
572 2016-06-30T21:47:24  *** Chris_Stewart_5 has quit IRC
573 2016-06-30T21:48:06  <zooko> One of those is a performance measurement of a transaction with the maximal number of inputs.
574 2016-06-30T21:48:30  <zooko> We're currently talking about that test/measurement over in #zcash and Nathan mentioned that it might be of use to core.
575 2016-06-30T21:56:41  *** frankenmint has joined #bitcoin-core-dev
576 2016-06-30T21:59:22  *** instagibbs has quit IRC
577 2016-06-30T22:01:03  *** instagibbs has joined #bitcoin-core-dev
578 2016-06-30T22:02:02  <luke-jr> gmaxwell: if we're hoping to see that constraint unnecessary in the next year, I don't think we need it to be "ideal"; but if sdaftuar wants to support it better, that's fine with me too
579 2016-06-30T22:02:42  *** frankenmint has quit IRC
580 2016-06-30T22:03:23  *** Chris_Stewart_5 has joined #bitcoin-core-dev
581 2016-06-30T22:05:53  <gmaxwell> I think its fine if its not ideal. given the current climate we can expect people to just turn it as high as possible in any case.
582 2016-06-30T22:06:00  <gmaxwell> just as they're doing with the current target.
583 2016-06-30T22:08:22  *** BCBot has joined #bitcoin-core-dev
584 2016-06-30T22:09:01  *** BCBot has quit IRC
585 2016-06-30T22:09:18  *** BCBot has joined #bitcoin-core-dev
586 2016-06-30T22:12:12  *** afk11 has quit IRC
587 2016-06-30T22:12:27  *** belcher has quit IRC
588 2016-06-30T22:13:36  <dgenr8> regarding gmaxwell statement on XT above https://github.com/bitcoinxt/bitcoinxt/issues/153#issuecomment-229793755
589 2016-06-30T22:19:26  *** cryptapus has quit IRC
590 2016-06-30T22:20:12  *** afk11 has joined #bitcoin-core-dev
591 2016-06-30T22:20:12  *** afk11 has quit IRC
592 2016-06-30T22:20:12  *** afk11 has joined #bitcoin-core-dev
593 2016-06-30T22:22:03  *** belcher has joined #bitcoin-core-dev
594 2016-06-30T22:22:12  *** pmienk has quit IRC
595 2016-06-30T22:30:13  *** Guyver2 has quit IRC
596 2016-06-30T22:31:41  *** BCBot_ has joined #bitcoin-core-dev
597 2016-06-30T22:33:26  <gmaxwell> dgenr8: your intended behavior will partition the network and leave XT isolated.
598 2016-06-30T22:34:34  *** BCBot_ has joined #bitcoin-core-dev
599 2016-06-30T22:35:02  <gmaxwell> as your only connections from core nodes will be inbound and after segwit activates core will avoid making outbound connections to non-segwit enabled hosts; already that behavior is dangerous because there are relatively few hosts that it is willing to outbound connect to, making chance partitioning and vulnerability to sybil attacks worse.
600 2016-06-30T22:36:57  *** BCBot_ has quit IRC
601 2016-06-30T22:37:06  *** BCBot_ has joined #bitcoin-core-dev
602 2016-06-30T22:37:17  *** pmienk has joined #bitcoin-core-dev
603 2016-06-30T22:37:58  *** BCBot_ has quit IRC
604 2016-06-30T22:41:15  *** paveljanik has quit IRC
605 2016-06-30T22:41:28  *** BCBot_ has joined #bitcoin-core-dev
606 2016-06-30T22:43:43  *** BCBot_ has quit IRC
607 2016-06-30T22:43:53  *** BCBot_ has joined #bitcoin-core-dev
608 2016-06-30T22:45:43  *** BCBot_ has joined #bitcoin-core-dev
609 2016-06-30T22:46:32  *** Prattler has quit IRC
610 2016-06-30T22:46:45  *** Prattler has joined #bitcoin-core-dev
611 2016-06-30T22:46:47  *** BCBot_ has quit IRC
612 2016-06-30T22:48:53  *** Amnez777 has quit IRC
613 2016-06-30T22:48:58  *** BCBot has quit IRC
614 2016-06-30T22:50:09  *** justanother|NYY is now known as justanotheruser
615 2016-06-30T22:50:24  <sipa> gmaxwell: that's not the reason. the algorithm needs per-package byte sizes, which are not counted currently
616 2016-06-30T22:50:33  <sipa> gmaxwell: it's not just that it's suboptinal
617 2016-06-30T22:50:51  <sipa> without adding package-accounted sizes, it just cannot work
618 2016-06-30T22:51:21  *** Amnez777 has joined #bitcoin-core-dev
619 2016-06-30T22:51:27  <gmaxwell> sipa: hm why doesn't it just construct assuming that there is no size limit then truncate when the block is full.
620 2016-06-30T22:51:49  <gmaxwell> [pp.getblock(pp.getblockhash(x))['size'] for x in range(353213,417725)]  ... man rpc from python is slow, thats running at 9 blocks per second and is going to take two hours to finish.
621 2016-06-30T22:57:32  *** ybit has quit IRC
622 2016-06-30T22:57:44  *** ybit has joined #bitcoin-core-dev
623 2016-06-30T23:00:28  *** kanzure has quit IRC
624 2016-06-30T23:03:37  *** justanotheruser is now known as justanotherusr
625 2016-06-30T23:04:48  *** justanotherusr is now known as justanotheruser
626 2016-06-30T23:05:34  *** Chris_Stewart_5 has quit IRC
627 2016-06-30T23:09:00  *** Chris_Stewart_5 has joined #bitcoin-core-dev
628 2016-06-30T23:09:33  *** ybit has quit IRC
629 2016-06-30T23:09:43  *** ybit has joined #bitcoin-core-dev
630 2016-06-30T23:14:47  *** spudowiar has joined #bitcoin-core-dev
631 2016-06-30T23:19:03  *** ybit has quit IRC
632 2016-06-30T23:28:40  *** Chris_Stewart_5 has quit IRC
633 2016-06-30T23:29:29  *** ybit has joined #bitcoin-core-dev
634 2016-06-30T23:31:37  *** kanzure has joined #bitcoin-core-dev
635 2016-06-30T23:34:28  *** ybit has quit IRC
636 2016-06-30T23:39:48  *** ybit has joined #bitcoin-core-dev
637 2016-06-30T23:41:51  *** kanzure has quit IRC
638 2016-06-30T23:42:30  *** kanzure has joined #bitcoin-core-dev
639 2016-06-30T23:42:32  <sdaftuar> sipa: gmaxwell: i think the fix is straightforward, please see https://github.com/bitcoin/bitcoin/pull/8295/commits/f15c2cde455174c7c899833fd5792460ed49a472
640 2016-06-30T23:42:55  <sdaftuar> i guess i didn't test it very well though!
641 2016-06-30T23:43:15  <sdaftuar> oops, i should go back and do that more carefully
642 2016-06-30T23:43:50  <sdaftuar> also, that silly function name gets improved in the next commit of the PR, which adds witness checking as well.
643 2016-06-30T23:43:54  <sdaftuar> #8295
644 2016-06-30T23:44:15  *** spudowiar has quit IRC
645 2016-06-30T23:44:24  *** Chris_Stewart_5 has joined #bitcoin-core-dev
646 2016-06-30T23:44:45  *** ybit has quit IRC
647 2016-06-30T23:45:07  *** ybit has joined #bitcoin-core-dev
648 2016-06-30T23:49:51  *** kanzure has quit IRC
649 2016-06-30T23:50:24  *** ybit has quit IRC
650 2016-06-30T23:51:26  *** kanzure has joined #bitcoin-core-dev
651 2016-06-30T23:51:29  *** randy-waterhouse has joined #bitcoin-core-dev
652 2016-06-30T23:51:31  *** ybit has joined #bitcoin-core-dev
653 2016-06-30T23:53:58  *** zooko has quit IRC