1 2016-09-01T00:25:51  <GitHub77> [bitcoin] fanquake opened pull request #8640: [depends] Remove Qt46 package (master...remove-qt46-depends) https://github.com/bitcoin/bitcoin/pull/8640
  2 2016-09-01T00:29:56  *** murch has quit IRC
  3 2016-09-01T00:33:14  *** isis is now known as isis_
  4 2016-09-01T00:45:54  *** Ylbam has quit IRC
  5 2016-09-01T00:47:45  *** fengling has joined #bitcoin-core-dev
  6 2016-09-01T00:51:56  *** belcher has joined #bitcoin-core-dev
  7 2016-09-01T00:52:46  *** fengling has quit IRC
  8 2016-09-01T01:02:01  *** Alopex has quit IRC
  9 2016-09-01T01:02:42  *** isis_ is now known as isis
 10 2016-09-01T01:03:06  *** Alopex has joined #bitcoin-core-dev
 11 2016-09-01T01:03:16  *** Samdney has left #bitcoin-core-dev
 12 2016-09-01T01:19:19  *** randy-waterhouse has joined #bitcoin-core-dev
 13 2016-09-01T01:31:27  *** Chris_Stewart_5 has quit IRC
 14 2016-09-01T01:32:27  *** pmienk has quit IRC
 15 2016-09-01T01:32:57  *** pmienk has joined #bitcoin-core-dev
 16 2016-09-01T01:33:40  *** grubles has quit IRC
 17 2016-09-01T01:35:06  *** Alopex has quit IRC
 18 2016-09-01T01:36:11  *** Alopex has joined #bitcoin-core-dev
 19 2016-09-01T01:49:15  *** fengling has joined #bitcoin-core-dev
 20 2016-09-01T01:51:47  *** jtimon has quit IRC
 21 2016-09-01T01:52:46  <instagibbs> am I the only one who never types in those types of commands in chat windows? :)
 22 2016-09-01T01:54:21  <gmaxwell> yea, man, who does that. Next thing we're going to find out that someone used their same password on github and the bitcoin core slack. :P
 23 2016-09-01T01:55:06  *** fengling has quit IRC
 24 2016-09-01T01:55:37  <achow101> not me! :D Changed all those passwords
 25 2016-09-01T01:56:28  <instagibbs> hypothetically speaking of course >_>
 26 2016-09-01T01:58:59  <kanzure> we should probably tell achow101 that he should use better passwords :)
 27 2016-09-01T02:00:28  <achow101> It was for my computer actually (synergy screwed something up when I typed it). I don't actually use passwords like that since I use a password manager to randomly generate all of my other passwords.
 28 2016-09-01T02:00:31  <warren> That's the combination on my luggage!
 29 2016-09-01T02:05:34  *** achow101 has quit IRC
 30 2016-09-01T02:05:53  *** achow101 has joined #bitcoin-core-dev
 31 2016-09-01T02:06:09  *** fengling has joined #bitcoin-core-dev
 32 2016-09-01T02:21:06  *** fengling has quit IRC
 33 2016-09-01T02:31:22  *** Alopex has quit IRC
 34 2016-09-01T02:32:27  *** Alopex has joined #bitcoin-core-dev
 35 2016-09-01T02:53:09  *** fengling has joined #bitcoin-core-dev
 36 2016-09-01T02:54:22  *** Alopex has quit IRC
 37 2016-09-01T02:55:27  *** Alopex has joined #bitcoin-core-dev
 38 2016-09-01T03:21:08  *** dcousens has quit IRC
 39 2016-09-01T03:22:28  <luke-jr> are we actively trying to remove boost in non-consensus code, or is it okay to use?
 40 2016-09-01T03:23:10  *** dcousens has joined #bitcoin-core-dev
 41 2016-09-01T03:26:13  <gmaxwell> We are now using C++11-- so could you consider using that instead?  I don't think we're quite at 'actively trying to remove' yet.
 42 2016-09-01T03:33:39  *** TomMc has joined #bitcoin-core-dev
 43 2016-09-01T03:34:56  *** naco has joined #bitcoin-core-dev
 44 2016-09-01T03:39:21  *** spudowiar has quit IRC
 45 2016-09-01T03:43:21  *** TomMc has quit IRC
 46 2016-09-01T03:49:05  <luke-jr> gmaxwell: C++11 doesn't include all of boost, for better or worse. Particularly, I'm looking at boost::any for #7289
 47 2016-09-01T03:52:26  <gmaxwell> ugh, do you really want boost::any? we like static typing..
 48 2016-09-01T03:54:21  <luke-jr> maybe not. I was thinking having each option-definition parse the param string to its correct type in a parse virtual, and then call that result into a check/set. The reason boost::any is needed with this design, is that the caller to parse+set doesn't necessarily need to know the types it's parsing
 49 2016-09-01T03:54:29  <luke-jr> but perhaps there's a way to workaround this
 50 2016-09-01T03:55:14  <luke-jr> (eg, move the parse internal to the setter, and set by string)
 51 2016-09-01T04:14:33  *** justan0theruser has joined #bitcoin-core-dev
 52 2016-09-01T04:16:31  *** justanotheruser has quit IRC
 53 2016-09-01T04:34:17  *** slackircbridge1 has joined #bitcoin-core-dev
 54 2016-09-01T04:35:01  *** pavel_ has joined #bitcoin-core-dev
 55 2016-09-01T04:36:56  *** paveljanik has quit IRC
 56 2016-09-01T04:37:58  *** NicolasDorier has quit IRC
 57 2016-09-01T04:37:58  *** slackircbridge has quit IRC
 58 2016-09-01T04:38:14  *** CodeShark has quit IRC
 59 2016-09-01T04:39:28  *** NicolasDorier has joined #bitcoin-core-dev
 60 2016-09-01T04:39:49  *** CodeShark has joined #bitcoin-core-dev
 61 2016-09-01T04:48:46  *** cfields has quit IRC
 62 2016-09-01T04:48:53  *** cfields has joined #bitcoin-core-dev
 63 2016-09-01T04:48:58  *** Giszmo has quit IRC
 64 2016-09-01T04:50:00  *** Giszmo has joined #bitcoin-core-dev
 65 2016-09-01T04:50:18  *** pavel_ has quit IRC
 66 2016-09-01T04:51:39  *** Giszmo has quit IRC
 67 2016-09-01T04:54:38  *** justanotheruser has joined #bitcoin-core-dev
 68 2016-09-01T04:58:16  *** justan0theruser has quit IRC
 69 2016-09-01T05:03:08  *** zmanian__ has quit IRC
 70 2016-09-01T05:03:08  *** ibrightly has quit IRC
 71 2016-09-01T05:05:21  *** ibrightly has joined #bitcoin-core-dev
 72 2016-09-01T05:06:17  *** zmanian__ has joined #bitcoin-core-dev
 73 2016-09-01T05:13:06  *** michagogo has quit IRC
 74 2016-09-01T05:14:52  *** michagogo has joined #bitcoin-core-dev
 75 2016-09-01T05:27:33  *** paveljanik has joined #bitcoin-core-dev
 76 2016-09-01T05:46:53  *** AtashiCon has quit IRC
 77 2016-09-01T06:04:12  *** AtashiCon has joined #bitcoin-core-dev
 78 2016-09-01T06:07:01  *** Alopex has quit IRC
 79 2016-09-01T06:08:07  *** Alopex has joined #bitcoin-core-dev
 80 2016-09-01T06:19:24  *** PaulCape_ has joined #bitcoin-core-dev
 81 2016-09-01T06:21:32  *** PaulCapestany has quit IRC
 82 2016-09-01T06:21:33  *** instagibbs has quit IRC
 83 2016-09-01T06:21:33  *** limpkin has quit IRC
 84 2016-09-01T06:21:45  *** instagibbs has joined #bitcoin-core-dev
 85 2016-09-01T06:22:00  *** mn3monic has quit IRC
 86 2016-09-01T06:22:31  *** limpkin has joined #bitcoin-core-dev
 87 2016-09-01T06:22:51  *** justanotheruser has quit IRC
 88 2016-09-01T06:26:41  *** kadoban has quit IRC
 89 2016-09-01T06:50:52  *** aalex has quit IRC
 90 2016-09-01T06:52:45  *** aalex has joined #bitcoin-core-dev
 91 2016-09-01T06:59:38  *** BashCo has quit IRC
 92 2016-09-01T07:02:39  *** laurentmt has joined #bitcoin-core-dev
 93 2016-09-01T07:04:23  *** kyletorpey has quit IRC
 94 2016-09-01T07:06:21  *** laurentmt has quit IRC
 95 2016-09-01T07:08:09  *** assder has joined #bitcoin-core-dev
 96 2016-09-01T07:08:18  *** randy-waterhouse has quit IRC
 97 2016-09-01T07:11:54  <GitHub15> [bitcoin] rebroad reopened pull request #8622: [WIP] Clarify variable names (master...ClarifyVariableNames) https://github.com/bitcoin/bitcoin/pull/8622
 98 2016-09-01T07:12:05  *** dcousens has quit IRC
 99 2016-09-01T07:18:49  *** BashCo has joined #bitcoin-core-dev
100 2016-09-01T07:20:55  *** adiabat has quit IRC
101 2016-09-01T07:23:06  *** warren has quit IRC
102 2016-09-01T07:24:21  *** warren has joined #bitcoin-core-dev
103 2016-09-01T07:24:47  *** jtimon has joined #bitcoin-core-dev
104 2016-09-01T07:32:14  *** FNinTak has joined #bitcoin-core-dev
105 2016-09-01T08:01:27  *** Evel-Knievel has quit IRC
106 2016-09-01T08:01:42  *** Evel-Knievel has joined #bitcoin-core-dev
107 2016-09-01T08:02:12  *** jtimon has quit IRC
108 2016-09-01T08:05:12  <GitHub2> [bitcoin] sipa closed pull request #8597: Move code from VERACK to VERSION (since VERACK is not requied) (master...NotDependentOnVerack) https://github.com/bitcoin/bitcoin/pull/8597
109 2016-09-01T08:05:35  <GitHub45> [bitcoin] sipa closed pull request #8622: [WIP] Clarify variable names (master...ClarifyVariableNames) https://github.com/bitcoin/bitcoin/pull/8622
110 2016-09-01T08:05:42  *** jonasschnelli has quit IRC
111 2016-09-01T08:06:47  *** jonasschnelli has joined #bitcoin-core-dev
112 2016-09-01T08:07:05  *** laurentmt has joined #bitcoin-core-dev
113 2016-09-01T08:07:06  *** laurentmt has quit IRC
114 2016-09-01T08:15:46  *** laurentmt has joined #bitcoin-core-dev
115 2016-09-01T08:17:37  *** mn3monic has joined #bitcoin-core-dev
116 2016-09-01T08:19:14  *** Guyver2 has joined #bitcoin-core-dev
117 2016-09-01T08:24:45  *** laurentmt has quit IRC
118 2016-09-01T08:25:04  <GitHub22> [bitcoin] rebroad opened pull request #8642: Less reliance on node version (master...LessRelianceOnNodeVersion) https://github.com/bitcoin/bitcoin/pull/8642
119 2016-09-01T08:25:20  <luke-jr> sigh
120 2016-09-01T08:28:26  <gmaxwell> I dunno whats going on there.
121 2016-09-01T08:28:38  <gmaxwell> I feel like I am being fuzz tested.
122 2016-09-01T08:28:42  <luke-jr> lol
123 2016-09-01T08:30:24  <gmaxwell> we need pulltester tests that test against a fixed point, so that if you break the protocol in a self-compatible way, the CI tests will still fail.
124 2016-09-01T08:31:02  <gmaxwell> those changes will throughly break communications with at least some versions.
125 2016-09-01T08:32:47  <sipa> gmaxwell: it seems intentional
126 2016-09-01T08:33:30  <gmaxwell> it's completely wildly handled though, sending garbage messages to peers that will tell who knows what malfunction.
127 2016-09-01T08:35:24  <sipa> one of the commits mentions that a protocol change introduced in 2010 should be supported by everyone
128 2016-09-01T08:35:37  <sipa> but he kills pre-bip31 nodes as well, which dates from 2012
129 2016-09-01T08:38:48  <gmaxwell> yea, I was looking at the BIP31 changes and scratching my head.
130 2016-09-01T08:39:15  <luke-jr> I guess there's a safe way one /could/ do that.. not sure it's worth the effort though
131 2016-09-01T08:39:30  <luke-jr> (if vRecv has nonce data, read and use it; otherwise, don't)
132 2016-09-01T08:43:34  <gmaxwell> I don't see why we'd touch old, working, functional code-- if there was some big reworking of those parts for other reasons, then sure it might be justifyable to break compatiblity at least back to the point where compatability is already likely broken for other reasons.
133 2016-09-01T08:48:36  *** slackircbridge has joined #bitcoin-core-dev
134 2016-09-01T08:50:14  *** lukedashjr has joined #bitcoin-core-dev
135 2016-09-01T08:50:47  *** Arnavion has quit IRC
136 2016-09-01T08:50:52  *** Arnavion has joined #bitcoin-core-dev
137 2016-09-01T08:51:05  <warren> Big reworking of the network layer is happening in the rewrite.  It makes no sense to change anything before the rewrite, especially working code.
138 2016-09-01T08:52:34  <sipa> can someone else other than me comment there?
139 2016-09-01T08:53:55  *** ybit_ has joined #bitcoin-core-dev
140 2016-09-01T08:54:02  *** ybit_ has quit IRC
141 2016-09-01T08:54:02  *** ybit_ has joined #bitcoin-core-dev
142 2016-09-01T08:54:27  <gmaxwell> last comment from his is you're right.
143 2016-09-01T08:56:13  *** lukedashjr has quit IRC
144 2016-09-01T08:56:23  *** lukedashjr has joined #bitcoin-core-dev
145 2016-09-01T08:56:55  <warren> I don't understand why he's citing nodes that are INTENDED to be incompatible as reason to change anything.
146 2016-09-01T08:58:49  *** mn3monic has quit IRC
147 2016-09-01T08:58:49  *** aalex has quit IRC
148 2016-09-01T08:58:49  *** slackircbridge1 has quit IRC
149 2016-09-01T08:58:50  *** sanada` has quit IRC
150 2016-09-01T08:58:51  *** Bootvis has quit IRC
151 2016-09-01T08:58:51  *** jyap has quit IRC
152 2016-09-01T08:58:51  *** go1111111 has quit IRC
153 2016-09-01T08:58:52  *** morcos has quit IRC
154 2016-09-01T08:58:53  *** ybit has quit IRC
155 2016-09-01T08:58:53  *** crudel has quit IRC
156 2016-09-01T08:58:53  *** luke-jr has quit IRC
157 2016-09-01T08:58:54  *** harding has quit IRC
158 2016-09-01T08:58:54  *** gijensen3 has quit IRC
159 2016-09-01T08:58:55  *** Taek has quit IRC
160 2016-09-01T08:59:09  *** jyap has joined #bitcoin-core-dev
161 2016-09-01T08:59:09  *** jyap has joined #bitcoin-core-dev
162 2016-09-01T08:59:11  *** gijensen has joined #bitcoin-core-dev
163 2016-09-01T09:00:17  *** cdecker has joined #bitcoin-core-dev
164 2016-09-01T09:00:28  *** go1111111 has joined #bitcoin-core-dev
165 2016-09-01T09:00:38  *** lukedashjr is now known as luke-jr
166 2016-09-01T09:01:11  *** JackH has joined #bitcoin-core-dev
167 2016-09-01T09:02:31  *** morcos has joined #bitcoin-core-dev
168 2016-09-01T09:02:43  *** aalex has joined #bitcoin-core-dev
169 2016-09-01T09:03:03  *** mn3monic has joined #bitcoin-core-dev
170 2016-09-01T09:03:04  *** sanada` has joined #bitcoin-core-dev
171 2016-09-01T09:03:04  *** Bootvis has joined #bitcoin-core-dev
172 2016-09-01T09:03:04  *** crudel has joined #bitcoin-core-dev
173 2016-09-01T09:03:04  *** harding has joined #bitcoin-core-dev
174 2016-09-01T09:03:04  *** Taek has joined #bitcoin-core-dev
175 2016-09-01T09:20:51  *** laurentmt has joined #bitcoin-core-dev
176 2016-09-01T09:34:11  *** dcousens has joined #bitcoin-core-dev
177 2016-09-01T09:50:48  *** laurentmt has quit IRC
178 2016-09-01T09:59:37  *** isis is now known as isis_
179 2016-09-01T10:04:18  *** isis_ is now known as isis
180 2016-09-01T10:11:27  *** AaronvanW has joined #bitcoin-core-dev
181 2016-09-01T10:11:28  *** AaronvanW has quit IRC
182 2016-09-01T10:11:28  *** AaronvanW has joined #bitcoin-core-dev
183 2016-09-01T10:15:18  *** Ginnarr has joined #bitcoin-core-dev
184 2016-09-01T10:21:06  <GitHub97> [bitcoin] sipa pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/84decb54f259...19b0f33de0ef
185 2016-09-01T10:21:07  <GitHub97> bitcoin/master d2c5d04 Pieter Wuille: Precompute sighashes...
186 2016-09-01T10:21:07  <GitHub97> bitcoin/master ab48c5e Nicolas DORIER: Unit test for sighash caching
187 2016-09-01T10:21:08  <GitHub97> bitcoin/master 35fe039 Pieter Wuille: Rename to PrecomputedTransactionData
188 2016-09-01T10:21:12  <GitHub100> [bitcoin] sipa closed pull request #8524: Precompute sighashes (master...noprecomputecachedhashes) https://github.com/bitcoin/bitcoin/pull/8524
189 2016-09-01T10:25:39  <gmaxwell> \O/
190 2016-09-01T10:25:41  *** FNinTak has quit IRC
191 2016-09-01T10:26:02  *** FNinTak has joined #bitcoin-core-dev
192 2016-09-01T10:33:48  *** FNinTak has quit IRC
193 2016-09-01T10:34:13  *** FNinTak has joined #bitcoin-core-dev
194 2016-09-01T10:37:08  <jl2012> great, one big step closer to 0.13.1
195 2016-09-01T10:37:36  *** FNinTak has quit IRC
196 2016-09-01T10:39:20  *** cdecker has quit IRC
197 2016-09-01T10:39:37  *** Ylbam has joined #bitcoin-core-dev
198 2016-09-01T10:39:53  *** cdecker has joined #bitcoin-core-dev
199 2016-09-01T10:53:07  *** cdecker has quit IRC
200 2016-09-01T11:04:53  *** cdecker has joined #bitcoin-core-dev
201 2016-09-01T11:36:27  *** Ginnarr has quit IRC
202 2016-09-01T11:42:22  *** Ylbam has quit IRC
203 2016-09-01T11:42:22  *** jl2012 has quit IRC
204 2016-09-01T11:56:41  <GitHub89> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/2663e5149dc06dedb8c29672abe4b1c645768e52
205 2016-09-01T11:56:41  <GitHub89> bitcoin/master 2663e51 Wladimir J. van der Laan: Merge #8640: [depends] Remove Qt46 package...
206 2016-09-01T11:56:51  <GitHub131> [bitcoin] laanwj closed pull request #8640: [depends] Remove Qt46 package (master...remove-qt46-depends) https://github.com/bitcoin/bitcoin/pull/8640
207 2016-09-01T11:56:59  *** Ylbam has joined #bitcoin-core-dev
208 2016-09-01T12:00:51  *** jl2012 has joined #bitcoin-core-dev
209 2016-09-01T12:02:36  *** pmienk has quit IRC
210 2016-09-01T12:17:33  *** jtimon has joined #bitcoin-core-dev
211 2016-09-01T12:17:57  *** pmienk has joined #bitcoin-core-dev
212 2016-09-01T12:19:09  *** dermoth_ has joined #bitcoin-core-dev
213 2016-09-01T12:19:33  *** dermoth has quit IRC
214 2016-09-01T12:19:35  *** dermoth_ is now known as dermoth
215 2016-09-01T12:32:32  *** cryptapus has joined #bitcoin-core-dev
216 2016-09-01T12:37:48  *** Chris_Stewart_5 has joined #bitcoin-core-dev
217 2016-09-01T12:42:26  <GitHub162> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2663e5149dc0...0e563d89c075
218 2016-09-01T12:42:27  <GitHub162> bitcoin/master 33d15a3 Pavel Janík: Do not shadow LOCK's criticalblock variable for LOCK inside LOCK
219 2016-09-01T12:42:27  <GitHub162> bitcoin/master 0e563d8 Wladimir J. van der Laan: Merge #8472: Do not shadow LOCK's criticalblock variable for LOCK inside LOCK...
220 2016-09-01T12:42:36  <GitHub159> [bitcoin] laanwj closed pull request #8472: Do not shadow LOCK's criticalblock variable for LOCK inside LOCK (master...20160806_Wshadow_LOCK) https://github.com/bitcoin/bitcoin/pull/8472
221 2016-09-01T12:51:23  *** aalex_ has joined #bitcoin-core-dev
222 2016-09-01T12:52:06  *** gijensen is now known as gijensen3
223 2016-09-01T12:52:21  *** aalex has quit IRC
224 2016-09-01T13:05:20  *** Chris_Stewart_5 has quit IRC
225 2016-09-01T13:11:35  *** grubles has joined #bitcoin-core-dev
226 2016-09-01T13:13:11  *** slackircbridge has quit IRC
227 2016-09-01T13:14:27  *** slackircbridge has joined #bitcoin-core-dev
228 2016-09-01T13:20:32  *** slackircbridge has quit IRC
229 2016-09-01T13:20:44  *** slackircbridge has joined #bitcoin-core-dev
230 2016-09-01T13:20:58  *** laurentmt has joined #bitcoin-core-dev
231 2016-09-01T13:25:06  *** TomMc has joined #bitcoin-core-dev
232 2016-09-01T13:26:02  *** slackircbridge has quit IRC
233 2016-09-01T13:26:15  *** slackircbridge has joined #bitcoin-core-dev
234 2016-09-01T13:34:20  *** aalex_ has quit IRC
235 2016-09-01T13:36:24  *** laurentmt has quit IRC
236 2016-09-01T13:36:29  *** aalex has joined #bitcoin-core-dev
237 2016-09-01T13:36:45  *** laurentmt has joined #bitcoin-core-dev
238 2016-09-01T13:37:01  *** aalex has quit IRC
239 2016-09-01T13:40:41  <GitHub84> [bitcoin] laanwj closed pull request #7376: Payments: Allow zero value OP_RETURN in PaymentRequests (master...zeropayments) https://github.com/bitcoin/bitcoin/pull/7376
240 2016-09-01T13:44:52  *** aalex has joined #bitcoin-core-dev
241 2016-09-01T13:45:34  *** aalex has quit IRC
242 2016-09-01T13:47:37  *** aalex has joined #bitcoin-core-dev
243 2016-09-01T13:57:29  <GitHub140> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/0e563d89c075...44691f3c51c9
244 2016-09-01T13:57:30  <GitHub140> bitcoin/master fab1f92 MarcoFalke: [contrib] verifybinaries: Adjust parsing to new rc path
245 2016-09-01T13:57:30  <GitHub140> bitcoin/master fa917f6 MarcoFalke: [contrib] verifybinaries: Keep downloads by default
246 2016-09-01T13:57:31  <GitHub140> bitcoin/master faaed88 MarcoFalke: [contrib] verifybinaries: Mention mandatory preparation step
247 2016-09-01T13:57:42  <GitHub143> [bitcoin] laanwj closed pull request #8557: [contrib] Rework verifybinaries (master...Mf1608-verifyBins) https://github.com/bitcoin/bitcoin/pull/8557
248 2016-09-01T13:58:09  *** timothy has quit IRC
249 2016-09-01T13:58:12  *** drizztbsd has joined #bitcoin-core-dev
250 2016-09-01T13:58:38  *** drizztbsd is now known as timothy
251 2016-09-01T13:59:03  <GitHub10> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/44691f3c51c9...f061415d12ce
252 2016-09-01T13:59:03  <GitHub10> bitcoin/master f012a85 djpnewton: rest.cpp: change HTTP_INTERNAL_SERVER_ERROR to HTTP_BAD_REQUEST
253 2016-09-01T13:59:04  <GitHub10> bitcoin/master f061415 Wladimir J. van der Laan: Merge #8638: rest.cpp: change HTTP_INTERNAL_SERVER_ERROR to HTTP_BAD_REQUEST...
254 2016-09-01T13:59:13  <GitHub78> [bitcoin] laanwj closed pull request #8638: rest.cpp: change HTTP_INTERNAL_SERVER_ERROR to HTTP_BAD_REQUEST (master...patch-2) https://github.com/bitcoin/bitcoin/pull/8638
255 2016-09-01T14:03:53  *** LeMiner2 has joined #bitcoin-core-dev
256 2016-09-01T14:05:01  *** LeMiner has quit IRC
257 2016-09-01T14:05:01  *** LeMiner2 is now known as LeMiner
258 2016-09-01T14:14:46  *** fengling has quit IRC
259 2016-09-01T14:18:54  *** aalex has quit IRC
260 2016-09-01T14:19:27  *** aalex has joined #bitcoin-core-dev
261 2016-09-01T14:20:42  *** Giszmo has joined #bitcoin-core-dev
262 2016-09-01T14:22:29  *** aalex has quit IRC
263 2016-09-01T14:23:00  *** aalex has joined #bitcoin-core-dev
264 2016-09-01T14:25:57  <GitHub130> [bitcoin] laanwj pushed 5 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/15502d7b2543...ec0afbd52b78
265 2016-09-01T14:25:57  <GitHub29> [bitcoin] laanwj closed pull request #8176: [0.12.x]: Versionbits: GBT support (0.12...gbt_bip9-0.12.x) https://github.com/bitcoin/bitcoin/pull/8176
266 2016-09-01T14:25:58  <GitHub130> bitcoin/0.12 ddd8c01 Luke Dashjr: Implement BIP 9 GBT changes...
267 2016-09-01T14:25:58  <GitHub130> bitcoin/0.12 40e81f5 Luke Dashjr: qa/rpc-tests: bip9-softforks: Add tests for getblocktemplate versionbits updates
268 2016-09-01T14:25:59  <GitHub130> bitcoin/0.12 65ee332 Luke Dashjr: getblocktemplate: Explicitly handle the distinction between GBT-affecting softforks vs not
269 2016-09-01T14:28:27  <paveljanik> sipa, PrecomputedTransactionData is defined as struct, but: src/main.h:class PrecomputedTransactionData;
270 2016-09-01T14:29:29  <sipa> will fix
271 2016-09-01T14:29:37  <paveljanik> ok, thanks.
272 2016-09-01T14:32:04  *** slackircbridge has quit IRC
273 2016-09-01T14:39:50  *** [b__b] has quit IRC
274 2016-09-01T14:40:13  *** Samdney has joined #bitcoin-core-dev
275 2016-09-01T14:41:07  *** [b__b] has joined #bitcoin-core-dev
276 2016-09-01T14:47:35  *** laurentmt has quit IRC
277 2016-09-01T14:47:59  *** laurentmt has joined #bitcoin-core-dev
278 2016-09-01T15:05:15  *** dcousens has quit IRC
279 2016-09-01T15:06:50  *** Chris_Stewart_5 has joined #bitcoin-core-dev
280 2016-09-01T15:11:49  *** BashCo has quit IRC
281 2016-09-01T15:16:52  *** slackircbridge has joined #bitcoin-core-dev
282 2016-09-01T15:17:16  *** Cheeseo has quit IRC
283 2016-09-01T15:17:38  *** Cheeseo has joined #bitcoin-core-dev
284 2016-09-01T15:17:38  *** Cheeseo has joined #bitcoin-core-dev
285 2016-09-01T15:53:19  *** BashCo has joined #bitcoin-core-dev
286 2016-09-01T16:01:49  *** goregrin1 has quit IRC
287 2016-09-01T16:07:47  *** goregrind has joined #bitcoin-core-dev
288 2016-09-01T16:17:50  *** achow101 has quit IRC
289 2016-09-01T16:21:56  *** achow101 has joined #bitcoin-core-dev
290 2016-09-01T16:22:16  *** laurentmt has quit IRC
291 2016-09-01T16:34:18  *** Cheeseo has quit IRC
292 2016-09-01T16:38:21  *** HoloIRCUser13 has joined #bitcoin-core-dev
293 2016-09-01T16:40:17  *** HoloIRCUser13 is now known as yep555
294 2016-09-01T16:43:02  *** Cheeseo has joined #bitcoin-core-dev
295 2016-09-01T16:43:02  *** Cheeseo has joined #bitcoin-core-dev
296 2016-09-01T16:52:29  <jtimon> it seems travis is failing walletbackup.py no matter what I push https://travis-ci.org/bitcoin/bitcoin/jobs/156853453#L2310
297 2016-09-01T17:01:18  *** gabridome has joined #bitcoin-core-dev
298 2016-09-01T17:02:38  <jtimon> mhmm, no, just randomly it seems, nothing to see here, sorry
299 2016-09-01T17:04:48  *** gabridome has quit IRC
300 2016-09-01T17:07:55  *** Yv7trNY has joined #bitcoin-core-dev
301 2016-09-01T17:13:11  <wumpus> jtimon: travis is a tad flakey at the moment
302 2016-09-01T17:15:04  <jtimon> I see
303 2016-09-01T17:16:39  *** kyletorpey has joined #bitcoin-core-dev
304 2016-09-01T17:18:36  *** Yv7trNY has quit IRC
305 2016-09-01T17:26:26  *** niska has quit IRC
306 2016-09-01T17:37:02  *** assder has quit IRC
307 2016-09-01T17:47:12  *** spudowiar has joined #bitcoin-core-dev
308 2016-09-01T17:48:48  <jeremyrubin> Yeah my lockfree checkqueue work should be passing all tests now; but has failures due to flaky pulltester :/
309 2016-09-01T17:51:26  <jeremyrubin> Ah
310 2016-09-01T17:52:07  <jeremyrubin> actually I did pass them on the last run; but I hadn't really made any changes that should have affected pass/fail
311 2016-09-01T17:58:35  *** niska has joined #bitcoin-core-dev
312 2016-09-01T17:58:43  *** BashCo has quit IRC
313 2016-09-01T17:58:59  *** pmienk has quit IRC
314 2016-09-01T18:03:24  *** BashCo has joined #bitcoin-core-dev
315 2016-09-01T18:06:00  *** laurentmt has joined #bitcoin-core-dev
316 2016-09-01T18:12:34  *** pmienk has joined #bitcoin-core-dev
317 2016-09-01T18:25:10  *** spudowiar has quit IRC
318 2016-09-01T18:44:57  *** yep555 has quit IRC
319 2016-09-01T18:50:44  *** jcorgan has joined #bitcoin-core-dev
320 2016-09-01T18:53:34  *** w00t88 has joined #bitcoin-core-dev
321 2016-09-01T18:54:03  *** ybit_ has quit IRC
322 2016-09-01T18:54:15  *** ybit has joined #bitcoin-core-dev
323 2016-09-01T18:55:21  *** laurentmt has quit IRC
324 2016-09-01T18:59:21  <wumpus> meeting time?
325 2016-09-01T18:59:29  <helo> <3
326 2016-09-01T18:59:35  <jonasschnelli> yes
327 2016-09-01T18:59:37  <luke-jr> big storm here, I may lose power
328 2016-09-01T19:00:09  <paveljanik> Hi
329 2016-09-01T19:00:13  <sipa> ohai
330 2016-09-01T19:00:21  <achow101> hi
331 2016-09-01T19:00:24  <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
332 2016-09-01T19:00:30  <kanzure> greetz.
333 2016-09-01T19:00:30  *** grubles_ has joined #bitcoin-core-dev
334 2016-09-01T19:00:33  <sdaftuar> hi
335 2016-09-01T19:00:39  <cfields> here
336 2016-09-01T19:00:42  <gmaxwell> luke-jr: I miss thunderstorms.
337 2016-09-01T19:00:43  *** gabridome has joined #bitcoin-core-dev
338 2016-09-01T19:01:02  <btcdrak> here
339 2016-09-01T19:01:41  <sipa>  there
340 2016-09-01T19:01:57  <wumpus> #startmeeting
341 2016-09-01T19:01:57  <lightningbot> Meeting started Thu Sep  1 19:01:57 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
342 2016-09-01T19:01:57  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
343 2016-09-01T19:02:21  <wumpus> proposed topics?
344 2016-09-01T19:02:47  <sipa> remaining 0.13.1 issues
345 2016-09-01T19:02:48  <jtimon> hi
346 2016-09-01T19:03:00  <instagibbs> present
347 2016-09-01T19:03:03  <wumpus> there are lots of 0.13.1-tagged pull requests open, any that should be prioritized for review?
348 2016-09-01T19:03:04  <jeremyrubin> present
349 2016-09-01T19:03:16  <sipa> wumpus: in fact, some conflict
350 2016-09-01T19:03:19  <wumpus> (e.g. what should go in first)
351 2016-09-01T19:03:24  <wumpus> yes, I thought so
352 2016-09-01T19:03:26  <jonasschnelli> https://github.com/bitcoin/bitcoin/milestones/0.13.1
353 2016-09-01T19:03:56  <wumpus> #link https://github.com/bitcoin/bitcoin/milestones/0.13.1
354 2016-09-01T19:04:04  *** grubles has quit IRC
355 2016-09-01T19:04:04  <sipa> 8393 (segwit + compact blocks) is a big blocker
356 2016-09-01T19:04:07  <jeremyrubin> I'd like to mention that my Checkqueue Lockfree is passing tests, would like to hear what people need to see for it to merge (will be restructuing my commits later today.tomorrow)
357 2016-09-01T19:04:09  <wumpus> #topic remaining 0.13.1 issues
358 2016-09-01T19:04:32  <jeremyrubin> (also can't stick around meeting past 12:15 FYI)
359 2016-09-01T19:04:38  <sipa> beyond that, we still need to choose a solution to the mempool dos issue around segwit
360 2016-09-01T19:04:51  <instagibbs> yes cb and then dos issues are probably 2 biggest?
361 2016-09-01T19:04:58  <sipa> this has been brought uo several times the past few meetings
362 2016-09-01T19:05:10  *** grubles_ is now known as grubles
363 2016-09-01T19:05:10  <wumpus> #action #8393 (segwit + compact blocks) is a blocker, needs review testing and be merged
364 2016-09-01T19:05:10  <sdaftuar> sipa: do we think that the BIP for cb+segwit is basically in final substantive form?  i saw there were some language discussions
365 2016-09-01T19:05:35  <sipa> sdaftuar: matt had more comments on the bip, but just on wording, not on semantics
366 2016-09-01T19:05:40  <jtimon> sorry what was cb ?
367 2016-09-01T19:05:45  <instagibbs> compact blocks
368 2016-09-01T19:05:46  <sipa> compact blocks
369 2016-09-01T19:05:47  <wumpus> jeremyrubin: great to hear it is passing the tests, we can talk about the topic later, but not if you have to leave that soon probably
370 2016-09-01T19:05:50  <jtimon> compact blocks
371 2016-09-01T19:05:54  <jtimon> sorry
372 2016-09-01T19:05:56  <sdaftuar> sipa: ok, i intend to review/test 8393 soon
373 2016-09-01T19:06:00  <sipa> thank you
374 2016-09-01T19:06:05  <sipa> beyond that, the dos issue
375 2016-09-01T19:06:24  <sipa> i'm not confortable with the previous suggestion of fully validating everything
376 2016-09-01T19:06:35  <sipa> as a change for a minor point release
377 2016-09-01T19:06:45  <jeremyrubin> wumpus: I'll try to swing back in the last few minutes of the meeting if possible?
378 2016-09-01T19:07:18  <wumpus> it's a major change to how things have been done for the last few versions, that's for sure
379 2016-09-01T19:07:37  <sdaftuar> so in a previous IRC meeting morcos had suggested mandatory feefilter + rejection cache only for non-witness tx, is that right?
380 2016-09-01T19:07:50  <sipa> so that leaves us with not storing witness txn in the rejection cache, feefilter (possibly mandatory), and heuristics to detect invalid bloating before validation
381 2016-09-01T19:07:54  <jonasschnelli> shouldn't we tag https://github.com/bitcoin/bitcoin/issues/8279 for 0.13.1?
382 2016-09-01T19:08:14  <sipa> sdaftuar: yes, there have been other suggestions in other talks to
383 2016-09-01T19:09:01  <luke-jr> I feel like I don't fully understand the issue, but couldn't the rejection cache use the [witness] hash instead of txid?
384 2016-09-01T19:09:19  <sdaftuar> luke-jr: that's the approach i prefer, but it requires redoing tx relay to use wtxid, which is probably a big change
385 2016-09-01T19:10:03  <sdaftuar> (and i don't think anyone has started work on it)
386 2016-09-01T19:10:07  <sipa> yes, that's a bigger change, and there are complications
387 2016-09-01T19:10:13  <sipa> like duplicating several indexes
388 2016-09-01T19:10:30  <sipa> and always risking downloading twice, because old nodes may announce using the txid
389 2016-09-01T19:10:50  <sipa> twice is better than $CONNECTIONS times, but still
390 2016-09-01T19:11:04  <luke-jr> old nodes won't relay witness transactions at all.. (or if they do, they'll be incomplete)
391 2016-09-01T19:11:07  <gmaxwell> On CB, I'm due to test the latest version-- I had tested the earlier version.. just been testing other things recently. Those things are now merged.
392 2016-09-01T19:11:42  <sipa> i very much like the idea of mandatory feefilter
393 2016-09-01T19:11:47  <CodeShark> me too
394 2016-09-01T19:11:57  <sipa> moving the responsibiloty of resource cost to the sender
395 2016-09-01T19:12:19  <jtimon> can someone summarize the idea?
396 2016-09-01T19:12:19  <CodeShark> it's the least hackish approach
397 2016-09-01T19:12:20  <sdaftuar> would we get rid of free tx relay at the same time, or not necessarily?
398 2016-09-01T19:12:45  <gmaxwell> I think mandatory feefilter should be done, though I think it is not as much of a silverbullet as some thing. Feerate is only one of several resource related limitations that get imposed.
399 2016-09-01T19:12:47  <sipa> but are we fine for 0.13.1 with only rejection cache for non-witness, and heuristics for detecting invalid witness bloating for the most common transaction types
400 2016-09-01T19:12:50  <BlueMatt> sdaftuar: would be nice to get rid of that code
401 2016-09-01T19:13:01  <sdaftuar> BlueMatt: i don't object in theory, but it's a sudden change for a point release
402 2016-09-01T19:13:03  <gmaxwell> s/thing/think/
403 2016-09-01T19:13:08  <CodeShark> what sort of heuristics?
404 2016-09-01T19:13:09  <sipa> sdaftuar: agree
405 2016-09-01T19:13:10  <BlueMatt> sdaftuar: sure, i wouldnt recommend it for that
406 2016-09-01T19:13:16  <jtimon> just stop allowing free transactions?
407 2016-09-01T19:13:24  <gmaxwell> sdaftuar: in practice it's not enabled in any case.
408 2016-09-01T19:13:28  <jtimon> s/allowing/relaying/
409 2016-09-01T19:13:30  <BlueMatt> jtimon: we effectively already do...
410 2016-09-01T19:13:35  <instagibbs> jtimon, it's about particular feerate, not just free
411 2016-09-01T19:13:37  <sipa> CodeShark: check whether the witness program's embedded scriot hash matches the hash of the witness script, for example
412 2016-09-01T19:13:39  <gmaxwell> jtimon: they're already not relayed on nodes that are up for more than a few hours.
413 2016-09-01T19:13:48  <sdaftuar> jtimon: because mempools are full
414 2016-09-01T19:13:55  <jtimon> so what's the mandatory feefilter changing?
415 2016-09-01T19:13:57  <instagibbs> sipa, yes that would be an easy fix, early on
416 2016-09-01T19:14:07  <sipa> instagibbs: there is a PR for this
417 2016-09-01T19:14:19  <gmaxwell>   "mempoolminfee": 0.00001812
418 2016-09-01T19:14:19  <instagibbs> is that jls? I can't remember
419 2016-09-01T19:14:24  <jtimon> if it's too long to summarize that's fine
420 2016-09-01T19:14:40  <sipa> instagibbs: yes, on a phonr, i can't seatch the pr number
421 2016-09-01T19:14:49  <instagibbs> #8593
422 2016-09-01T19:15:01  <sipa> jtimon: mandatory feefilter is that you can ban a node if it does not obey the feefilter you sent it
423 2016-09-01T19:15:02  <sdaftuar> so mandatory fee filter would only apply to witness transactions?
424 2016-09-01T19:15:11  <sdaftuar> er, NODE_WITNESS peers?
425 2016-09-01T19:15:18  <sipa> sdaftuar: that's a possibility
426 2016-09-01T19:15:23  <instagibbs> he moves full input validation up front in #8539
427 2016-09-01T19:15:30  <sdaftuar> it doesn't make sense otherwise, we can't stop relaying transactions from older clients right
428 2016-09-01T19:15:33  <sipa> instagibbs: oh, no, not that one
429 2016-09-01T19:15:43  <instagibbs> would be abusive to disconnect older nodes imo
430 2016-09-01T19:15:52  <gmaxwell> sdaftuar: It has to be negoiated somehow, node witness would be one way.. though a bit disruptive on testnet.
431 2016-09-01T19:16:03  <gmaxwell> instagibbs: no one is going to do that.
432 2016-09-01T19:16:04  <sipa> instagibbs: full validation has some kinks to work out; something for 0.14 imho
433 2016-09-01T19:16:11  <luke-jr> mandatory feefilter seems liable to cause issues with 1) diverging fee policies; 2) ancestor feerate (CPFP) relay stuff
434 2016-09-01T19:16:14  <jtimon> sipa: I see, thanks, like an additional filter per peer
435 2016-09-01T19:16:16  <BlueMatt> sdaftuar: well you could gate it on something else (protocol version/message/whatever), but I'm not against fucking up testnet to do it for NODE_WITNESS
436 2016-09-01T19:16:30  *** thestringpuller has joined #bitcoin-core-dev
437 2016-09-01T19:16:31  <instagibbs> sipa, I don't see the PR you are talking about then
438 2016-09-01T19:17:12  <sdaftuar> conceptually though: the idea is that we only download witness transactions from peers with whom we've negotiated mandatory feefilter semantics?
439 2016-09-01T19:17:24  <jonasschnelli> instagibbs: i think there is no PR right now for that proposal
440 2016-09-01T19:17:30  <gmaxwell> sdaftuar: that would be fine too.
441 2016-09-01T19:17:37  <petertodd> sdaftuar: yes
442 2016-09-01T19:17:38  <sipa> instagibbs: 8499
443 2016-09-01T19:17:47  <sipa> yes there is
444 2016-09-01T19:17:49  <instagibbs> oh that one
445 2016-09-01T19:18:02  <jonasschnelli> Indeed: https://github.com/bitcoin/bitcoin/pull/8499/files
446 2016-09-01T19:18:20  <sipa> so, i would like to request review on 8499 and 8525
447 2016-09-01T19:18:34  <sipa> neither of those is a policy change
448 2016-09-01T19:18:35  <instagibbs> wumpus, can you tag that PR please #8499
449 2016-09-01T19:18:47  <sdaftuar> sipa: will do
450 2016-09-01T19:19:07  <wumpus> sure
451 2016-09-01T19:19:15  <instagibbs> I will review 8499
452 2016-09-01T19:19:38  <sipa> and untag 8593
453 2016-09-01T19:20:15  <wumpus> done
454 2016-09-01T19:20:38  <sipa> so the only remaining thing is enforcing feefilter stronger as sdaftuar suggests only for witness peers
455 2016-09-01T19:20:53  <BlueMatt> I'd ACK that
456 2016-09-01T19:20:54  <gmaxwell> luke-jr: CPFP relay is already inhibited to the maximum extent that it could be by feefilter in the current non-mandatory form. Improving that will require some kind of package relay. Mandatory fee filter won't make it worse.
457 2016-09-01T19:20:57  <sipa> does that sound reasonable for 0.13.1?
458 2016-09-01T19:21:07  <gmaxwell> FWIW, mandatory fee filter would couple well with 8525, rejection cache mostly exists due to a lack of feefilter.
459 2016-09-01T19:21:22  <sipa> besides fixing known bugs, obviously
460 2016-09-01T19:21:24  <petertodd> gmaxwell: yup
461 2016-09-01T19:21:29  <sdaftuar> sipa: yes
462 2016-09-01T19:21:36  <petertodd> sipa: sure
463 2016-09-01T19:21:45  <sipa> great
464 2016-09-01T19:21:55  <sdaftuar> you started a PR that did that, yes?
465 2016-09-01T19:22:05  <sipa> sdaftuar: not yet, i will
466 2016-09-01T19:22:12  <sdaftuar> ok
467 2016-09-01T19:22:19  <gmaxwell> I'd like feelers (and my addrman insert fix) to get backported. (I'm happy to do the 'backport')  I think it will be important to have feelers to compensate for any loss of network density for witness enabled nodes.
468 2016-09-01T19:22:29  <instagibbs> gmaxwell, ack
469 2016-09-01T19:22:34  <sdaftuar> sounds reasonable
470 2016-09-01T19:22:51  <sipa> ack on backporting feelers
471 2016-09-01T19:22:59  <sdaftuar> curious to know if anyone has experimented with that on testnet and has any results?
472 2016-09-01T19:23:17  <sipa> i think it will take a while for network wide effects of feelers to become visible
473 2016-09-01T19:23:41  <sdaftuar> oh maybe i misunderstood, i thought your own node would benefit from that by itself?
474 2016-09-01T19:23:43  <sipa> and testnet is not particularly in a sane p2p state
475 2016-09-01T19:23:49  <CodeShark> if a node with low feefilter connects to peers that all have a higher feefilter the higher filters would dominate. is that a problem?
476 2016-09-01T19:23:53  <gmaxwell> we had repeated minor problems with isoloation on testnet early on when we deployed segwit there. I expect less of those on mainnet, and more proactive efforts to avoid them (eg spinning up nodes), but belt and suspenders is good.
477 2016-09-01T19:24:01  <sipa> right, but indirectly the results of addr messages will get better too from feelers
478 2016-09-01T19:24:12  <sipa> if the overall quality of addrmans improves
479 2016-09-01T19:24:13  <sdaftuar> sipa: ah, yes
480 2016-09-01T19:24:14  <gmaxwell> CodeShark: the filters are one way.  "Here is what you can send me"
481 2016-09-01T19:24:21  <instagibbs> https://github.com/bitcoin/bitcoin/pull/8282
482 2016-09-01T19:25:00  <CodeShark> gmaxwell: sure...but your peers would filter stuff you wanted to see
483 2016-09-01T19:25:10  <sipa> next topic?
484 2016-09-01T19:25:12  <gmaxwell> CodeShark: has nothing to do with fee filter.
485 2016-09-01T19:25:14  <sipa> i'm in a mildly unconfortable position here (irl meetup in milan, where BlueMatt spoke)
486 2016-09-01T19:25:21  <gmaxwell> CodeShark: peers already filter anything they won't relay.
487 2016-09-01T19:26:04  <BlueMatt> sipa: you can irc from my laptop if you prefer
488 2016-09-01T19:26:06  <jtimon> its kind of "please, don't bother sending me things below X or I'll disconnect from you"
489 2016-09-01T19:26:39  <luke-jr> gmaxwell: no particular p2p protocol changes would be needed right now afaik (would just need to send the children first, and then teach the receiver to use the feerate including orphan txs)
490 2016-09-01T19:27:39  *** cdecker has quit IRC
491 2016-09-01T19:27:40  <luke-jr> if we're not careful, mandatory feefilter could in practice make fee policy code as sensitive as consensus code
492 2016-09-01T19:27:58  <petertodd> luke-jr: how?
493 2016-09-01T19:28:08  <jtimon> luke-jr: I'm not following, how does the peer know your rate X
494 2016-09-01T19:28:10  <jtimon> ?
495 2016-09-01T19:28:43  <luke-jr> petertodd: if you change your fee policy code, you could be partitioned off from the other peers, no?
496 2016-09-01T19:28:46  *** cdecker has joined #bitcoin-core-dev
497 2016-09-01T19:28:48  <sdaftuar> luke-jr: no
498 2016-09-01T19:28:49  <instagibbs> suggested topic: "Extra" softforks low_s and nulldummy
499 2016-09-01T19:28:59  <luke-jr> what am I missing?
500 2016-09-01T19:29:06  <sdaftuar> only if you lie about it to your peers
501 2016-09-01T19:29:14  <sipa> instagibbs: ack topic
502 2016-09-01T19:29:26  <jtimon> I believe low_s was discussed already?
503 2016-09-01T19:29:30  <BlueMatt> am I missing something? isnt the feefilter potentially rather deanonymizing? we should probably round/randomize the amount somewhat, no? (or do we, I probably wouldnt know)
504 2016-09-01T19:29:33  <gmaxwell> luke-jr: e.g. later we can add a package fee filter and nodes would signal a package fee filter of X, and a fee filter of 0.
505 2016-09-01T19:29:42  <sipa> i believe it needs rediscussing (low_s)
506 2016-09-01T19:29:46  <jtimon> BlueMatt: good point
507 2016-09-01T19:29:47  <instagibbs> BlueMatt, that's a good point
508 2016-09-01T19:29:48  <sdaftuar> BlueMatt: we do, but worht looking at again
509 2016-09-01T19:29:49  <gmaxwell> BlueMatt: we do.
510 2016-09-01T19:30:08  <BlueMatt> ok, nvm, ignore my ramblings
511 2016-09-01T19:30:43  <jtimon> BlueMatt: please keep rumbling out loud, I hadn't even thought about it, now seems obvious
512 2016-09-01T19:30:46  <gmaxwell> BlueMatt: but also, we really can make no guarentees that a single node with multiple interfaces can't be distinguished as the same node. There are several ways to do this. (obviously I'm happy to reduce them, but it's not a property we currently provide)
513 2016-09-01T19:30:56  <sipa> (can we move on to next topic?)
514 2016-09-01T19:31:01  <gmaxwell> jtimon: it was specfically addressed in the original feefilter PR.
515 2016-09-01T19:31:01  <BlueMatt> gmaxwell: indeed, shame we dont
516 2016-09-01T19:31:04  <jtimon> ack next topic
517 2016-09-01T19:31:04  <BlueMatt> also, what sipa said
518 2016-09-01T19:31:17  <sipa> wumpus: ring topic bell? :)
519 2016-09-01T19:31:25  <gmaxwell> we put wumpus to sleep.
520 2016-09-01T19:31:41  <paveljanik> ;-)
521 2016-09-01T19:31:48  <petertodd> gmaxwell: ring wumpus bell?
522 2016-09-01T19:31:48  * sdaftuar rings the wumpus bell
523 2016-09-01T19:31:51  <sipa> ok, i'll go on anyway
524 2016-09-01T19:32:02  <paveljanik> I think that wumpus never sleeps
525 2016-09-01T19:32:03  <jtimon> go sipa go
526 2016-09-01T19:32:07  <sipa> so, the nulldummy and low_s softfork proposals
527 2016-09-01T19:32:30  <btcdrak> #topic nulldummy and low_s softfork proposals
528 2016-09-01T19:32:36  <wumpus> #topic nulldummy and low_s softfork proposals
529 2016-09-01T19:32:39  <sipa> it was discovered by jl that low_ has a really strange implementation issue leaked into the semantics
530 2016-09-01T19:32:44  <jtimon> I don't remember any objections on low_s last time we discussed it?
531 2016-09-01T19:32:56  <sipa> which is not an issue for standardness, but for consensus i think we prefer clean sema tics
532 2016-09-01T19:33:01  <instagibbs> jtimon, https://github.com/bitcoin/bitcoin/pull/8533#issuecomment-243973512
533 2016-09-01T19:33:17  <gmaxwell> sipa: are clean semantics even possible?
534 2016-09-01T19:33:25  <jtimon> instagibbs: thanks
535 2016-09-01T19:33:38  <sipa> gmaxwell: yes, if we also do the only-empty-signature-in-invalid-checksig sf
536 2016-09-01T19:33:53  <gmaxwell> sipa: oh indeed okay, yes that would be clean
537 2016-09-01T19:33:58  <sipa> which is why i'd propose that we do low_s later, together with that empty sigs rule
538 2016-09-01T19:34:07  <sipa> and only bundle nulldummy with 0.13.1
539 2016-09-01T19:34:19  <sipa> s/0.13.1/segwit/
540 2016-09-01T19:34:23  <gmaxwell> The clenlyness issue is that lowS test fails for some encodings of invalid encodings.
541 2016-09-01T19:34:37  <gmaxwell> er encodings of invalid signatures.
542 2016-09-01T19:34:44  <sipa> yes, some illegal signatures are exempt from low_s
543 2016-09-01T19:34:50  <BlueMatt> would be a shame, but seems like a reasonable approach...has anyone checked for the #/frequency of invalid sigs in the chain?
544 2016-09-01T19:34:59  <BlueMatt> that are non-0-length, at least
545 2016-09-01T19:35:04  <sipa> such signatures are NOT valid
546 2016-09-01T19:35:15  <BlueMatt> but can bt OP_NOT'd, no?
547 2016-09-01T19:35:23  <sipa> yes, but nobody sane does that
548 2016-09-01T19:35:30  <sdaftuar> has NULLDUMMY been discussed on the mailing list yet?  i see one mention of it in passing about the LOW_S BIP.
549 2016-09-01T19:35:32  <BlueMatt> sure, but /has/ anyone ever done so?
550 2016-09-01T19:35:39  <sipa> "yes, this output can be spent UNLESS BlueMatt likes it"
551 2016-09-01T19:35:46  <jtimon> no objections on delaying low_s enforcement
552 2016-09-01T19:35:54  <gmaxwell> BlueMatt: with the exception of intentional insanity, any invalid signature could be malleated to a zero length one, in any case.  I had looked previously and seen no ongoing checksig-not activity, obvious.
553 2016-09-01T19:35:58  <BlueMatt> I might suggest that it is not crazy to propose doing it in 0.13.1 if it has never happened
554 2016-09-01T19:36:29  <BlueMatt> indeed, I'm asking with the assumption that someone might have done intentional insantiy as a test-case or so
555 2016-09-01T19:36:35  <sipa> BlueMatt: the only opractical difference is that the BIP to specify LOW_S would contain a rule that is pointless and complicating
556 2016-09-01T19:36:40  <sipa> i think we should aboid that
557 2016-09-01T19:36:43  <BlueMatt> (wait, it is non-stad to do non-0-length, correct?)
558 2016-09-01T19:36:46  <gmaxwell> BlueMatt: a checksig not has been done at least once in the chain history.
559 2016-09-01T19:36:53  <jtimon> BlueMatt: good question, petertodd has anybody done that? :p
560 2016-09-01T19:36:57  <gmaxwell> By someone triggering a fork off of bitcoin ruby.
561 2016-09-01T19:37:03  <sipa> petertodd: have you done that?
562 2016-09-01T19:37:11  <BlueMatt> gmaxwell: sure, but with 0-length, or with a non-emtpy sig
563 2016-09-01T19:37:20  <gmaxwell> yea, don't recall, we could check.
564 2016-09-01T19:37:35  <petertodd> sipa: me personally, probably not - I'm a fine arts grad :P
565 2016-09-01T19:37:38  <gmaxwell> But I don't think the test here should be none at all. If there was an obvious test someplace in the past, who cares?
566 2016-09-01T19:37:46  <BlueMatt> (this would be immaterial if it is not already nonstd...which I do not recall)
567 2016-09-01T19:37:48  <sipa> jl also pointed out that the benefit of low_s is lower, as it can only be used.for mutating, but not for bloating
568 2016-09-01T19:38:26  <BlueMatt> I was informed that non-0-length invalid sigs is not nonstd
569 2016-09-01T19:38:30  <BlueMatt> I would propose we do so in 0.13.1
570 2016-09-01T19:38:45  <gmaxwell> It is non-standard for segwit. (unless I am on drugs.)
571 2016-09-01T19:38:55  <sipa> gmaxwell: you're on drugs
572 2016-09-01T19:38:57  <gmaxwell> I am on drugs then. Okay. Good to know.
573 2016-09-01T19:38:59  <jtimon> are we still talking low_S ?
574 2016-09-01T19:39:02  <sipa> yes
575 2016-09-01T19:39:03  <BlueMatt> I was assuming it was nonstd, and thus thought it might be reasonable for a softfork, but withdraw my insanity
576 2016-09-01T19:39:08  <gmaxwell> wlel thats insane, we should fix that at least.
577 2016-09-01T19:39:14  <BlueMatt> gmaxwell: ack
578 2016-09-01T19:39:21  <gmaxwell> yes, it needs to be non-standard first. pronto.
579 2016-09-01T19:39:24  <BlueMatt> 0.13.1 should make invalid sigs which are non-0-length nonstd
580 2016-09-01T19:39:25  <sipa> agree
581 2016-09-01T19:39:29  <sdaftuar> agree
582 2016-09-01T19:39:35  <wumpus> yes, absolutely
583 2016-09-01T19:39:42  <CodeShark> +1
584 2016-09-01T19:39:51  <sipa> great
585 2016-09-01T19:40:02  <jtimon> this needs a bip, no?
586 2016-09-01T19:40:12  *** jcorgan has quit IRC
587 2016-09-01T19:40:16  <sipa> jtimon: yes, but we just suggest it as nonstd now
588 2016-09-01T19:40:22  <jtimon> sure
589 2016-09-01T19:40:25  <sipa> (which certainly needs ML discussion too)
590 2016-09-01T19:40:31  <gmaxwell> there is copy for null dummy as part of the old malleability bip, no?
591 2016-09-01T19:40:51  <gmaxwell> nulldummy and fixed invalid?
592 2016-09-01T19:40:54  <sipa> null dummy is about the ignored arg for CMS
593 2016-09-01T19:41:02  <gmaxwell> thus my follow up.
594 2016-09-01T19:41:12  <sipa> empty invalid was not part of bip62
595 2016-09-01T19:41:19  <gmaxwell> okay.
596 2016-09-01T19:41:41  <sipa> because it wasn't needed fir standard txn at the time
597 2016-09-01T19:41:54  <sipa> ok, next topic?
598 2016-09-01T19:42:00  <kanzure> jeremyrubin's stuff see above
599 2016-09-01T19:42:14  <kanzure> 12:04 < jeremyrubin> I'd like to mention that my Checkqueue Lockfree is passing tests, would like to hear what people need to see for it to merge (will be restructuing my commits later today.tomorrow)
600 2016-09-01T19:42:23  <gmaxwell> jeremyrubin is busy making validation great again. I'm super excited about this.
601 2016-09-01T19:42:29  <sdaftuar> sorry before we move topics -- we should repropose NULLDUMMY by itself on the mailing list, yes?
602 2016-09-01T19:42:37  <wumpus> if he's here, at least
603 2016-09-01T19:42:37  <sipa> sdaftuar: ack
604 2016-09-01T19:42:58  <BlueMatt> gmaxwell: ACK
605 2016-09-01T19:42:59  <petertodd> so, one mitigation to this malleability stuff I think we should also consider doing, is having transaction replacement trigger if the tx has a higher fee rate than the old tx (over a certain ratio)
606 2016-09-01T19:43:03  <instagibbs> link to jeremyrubin's stuff?
607 2016-09-01T19:43:25  <sipa> petertodd: that would be a side effect of switching to wtzid based indexing, actually
608 2016-09-01T19:43:30  <sdaftuar> https://github.com/bitcoin/bitcoin/pull/8464
609 2016-09-01T19:43:31  <kanzure> instagibbs: https://github.com/bitcoin/bitcoin/pull/8464
610 2016-09-01T19:44:08  <jonasschnelli> It's a very invasive change...
611 2016-09-01T19:44:18  <jonasschnelli> though, I like the concept
612 2016-09-01T19:44:18  <BlueMatt> jonasschnelli: its worth it, by a lot
613 2016-09-01T19:44:27  <btcdrak> sdaftuar there is a NULLDUMMY only PR as well https://github.com/bitcoin/bitcoin/pull/8636
614 2016-09-01T19:44:28  <petertodd> sipa: not quite - I'm proposing we re-broadcast such replacements to our peers
615 2016-09-01T19:45:06  <BlueMatt> (for those interested, when it was first posted I went and reimplemented it as lockfree but with a single atomic which was contested between threads a decent amount.....my reimplementation might not have been ideal, but was only marginally better than master...jeremy's work is something like 10-20%)
616 2016-09-01T19:45:16  <petertodd> sipa: need to pick a reasonable ratio, geometric series, so something like 75% would be absolute worst case a 4x bandwidth increase, while allowing no more than 25% bloat by a malleability attacker
617 2016-09-01T19:45:31  <sdaftuar> petertodd: you're suggesting different replacement semantics than we have under BIP 125?
618 2016-09-01T19:45:31  <sipa> ah, i see
619 2016-09-01T19:46:07  <petertodd> sdaftuar: yeah, obvious one would be to just do replacements if vout #1 == vout #2 regardless of BIP125, which handles malleability just fine
620 2016-09-01T19:47:07  <petertodd> sdaftuar: mainly proposing this as a belt and suspenders to limit the damage of malleability attacks
621 2016-09-01T19:47:13  <gmaxwell> petertodd: may just be better for mempool reconcillation to handle that.
622 2016-09-01T19:47:27  <petertodd> gmaxwell: sure - when's that coming? :)
623 2016-09-01T19:47:54  <gmaxwell> petertodd: interested in helping define it? :P
624 2016-09-01T19:48:06  *** Cory has quit IRC
625 2016-09-01T19:48:08  <sipa> i believe we're drifting off topic
626 2016-09-01T19:48:17  <gmaxwell> Who was phone?
627 2016-09-01T19:48:25  <petertodd> gmaxwell: heh, seems like I should do a pull-req of this ratio thing for now - that's just a few lines of code
628 2016-09-01T19:48:36  <gmaxwell> fair
629 2016-09-01T19:49:01  <sipa> other topics?
630 2016-09-01T19:49:11  <gmaxwell> petertodd: if you do it right, it will interact well with mempool batching, and the batching will eliminate a lot of the bandwidth overhead.
631 2016-09-01T19:49:27  <wumpus> yes, any other topic proposals?
632 2016-09-01T19:49:32  <gmaxwell> s/mempool batching/relay batching/
633 2016-09-01T19:49:44  <petertodd> gmaxwell: oh, batching? I'm unfamilar with that idea
634 2016-09-01T19:50:02  <BlueMatt> 10 min bell
635 2016-09-01T19:50:04  <gmaxwell> petertodd: relay behavior changed in 0.13, I think you're aware.
636 2016-09-01T19:50:13  <gmaxwell> petertodd: will talk after meeting.
637 2016-09-01T19:50:16  <petertodd> gmaxwell: ack
638 2016-09-01T19:50:42  <sdaftuar> quick travis discussion?
639 2016-09-01T19:50:47  <wumpus> seems that there are no other meeting topics proposals, so we can close
640 2016-09-01T19:51:06  <wumpus> sure
641 2016-09-01T19:51:07  <GitHub133> [bitcoin] jonasschnelli opened pull request #8643: [0.13 backport] Added feeler connections increasing good addrs in the tried table. (0.13...2016/08/feeler_013) https://github.com/bitcoin/bitcoin/pull/8643
642 2016-09-01T19:51:09  <gmaxwell> Non-discussion: 0.13 deployment seems to be trouble free <knock on wood>, congrats everyone.
643 2016-09-01T19:51:10  <wumpus> #topic travis discussion
644 2016-09-01T19:51:14  <sdaftuar> i've been away for the last couple weeks, can anyone summarize the state of our testsuite these days?
645 2016-09-01T19:51:19  <jeremyrubin> Yes
646 2016-09-01T19:51:24  <sdaftuar> i feel like i've seen lots of people complaining
647 2016-09-01T19:51:32  <wumpus> yes, congrats everyone on the 0.13.0 release
648 2016-09-01T19:51:34  <jeremyrubin> Basically theres some failing rpctests
649 2016-09-01T19:51:40  <sdaftuar> and my own local runs are failing a lot too, but i havent figured out why yet
650 2016-09-01T19:51:45  <jeremyrubin> and the make check code is slow
651 2016-09-01T19:51:45  <gmaxwell> what is this backupwallet test thing that keeps failing?
652 2016-09-01T19:51:48  <wumpus> there are randomly failing RPC tests, and also some random timeouts
653 2016-09-01T19:51:51  <cfields> yes, there are a few racy conditions
654 2016-09-01T19:51:56  <sipa> segwit.py also fails sometimes
655 2016-09-01T19:52:09  <jeremyrubin> I've also seen an abandonconflict failure once
656 2016-09-01T19:52:30  <cfields> i believe i tracked down the segwit issue, which may be the root cause of some other issues
657 2016-09-01T19:52:36  <sdaftuar> oh!  good to know
658 2016-09-01T19:52:39  <gmaxwell> I saw some indication before that this was actually misbehavior on the part of the travis infra, that it was occassionally running too slow and timing out.
659 2016-09-01T19:52:41  <sipa> cfields: elobarate?
660 2016-09-01T19:52:43  <cfields> (if that's the same as the one that was worsened by the timing change)
661 2016-09-01T19:53:12  <cfields> sipa: need to check if it's the same thing and gather my notes, take it up after meeting?
662 2016-09-01T19:53:13  <jonasschnelli> can we not just move the segwith test to the end/last item?
663 2016-09-01T19:53:20  <sipa> cfields: ok
664 2016-09-01T19:53:26  <sdaftuar> sounds good
665 2016-09-01T19:53:27  <wumpus> there's an issue open about txn_doublespend and segwit.py, it was worse and made batter by reverting a timeout change, but not solved (as MarcoFalke says)
666 2016-09-01T19:53:29  <jonasschnelli> s/segwith/segwit
667 2016-09-01T19:53:37  <wumpus> the thing is, the tests never fail locally at least here
668 2016-09-01T19:53:52  <wumpus> so yes I also suspect the travis infrastructure for some failiures
669 2016-09-01T19:54:09  <jeremyrubin> There's also an open issue with travis race conditions internally
670 2016-09-01T19:54:10  <wumpus> anyhow the issue is https://github.com/bitcoin/bitcoin/issues/8532
671 2016-09-01T19:54:10  <jtimon> I suspect some tests fail in a non-reproducible way, I don't have local travis, but when the tests doesn't fail locally I just change the last commit id and force push, it works most times
672 2016-09-01T19:54:13  <sipa> sdaftuar says he sometimes sees the failures locally?
673 2016-09-01T19:54:25  <sdaftuar> sipa: yes, with an error condition i don't understand at all, let me find it
674 2016-09-01T19:54:26  <jeremyrubin> e.g. if you push a commit before the last push finished testing
675 2016-09-01T19:54:35  <cfields> ok, same one then. the issue there is that the node heights are in sync, but the wallet hasn't necessarily updated with their txs. So sync_all() followed by a balance check is racy.
676 2016-09-01T19:55:03  <wumpus> so we need a better sync call
677 2016-09-01T19:55:15  <sipa> cfields: so switch to a while loop until balances are an equal/expected value, with a certain timeout?
678 2016-09-01T19:55:17  <wumpus> a kind of fence
679 2016-09-01T19:55:46  <wumpus> sipa: that would imply updating all the balance checks to loops
680 2016-09-01T19:55:53  <gmaxwell> run a ping and check the ping time on all the node.s
681 2016-09-01T19:56:09  <jonasschnelli> gmaxwell: from the RPC API?
682 2016-09-01T19:56:22  <sipa> getpeerinfo, i oresume
683 2016-09-01T19:56:26  <gmaxwell> yes, the ping will act as a barrier in the current p2p protocol, though perhaps cfields is about to kill me
684 2016-09-01T19:56:41  <sipa> i hope cfields isn't changing that barrier effect
685 2016-09-01T19:56:45  <BlueMatt> gmaxwell: iirc breaking that breaks things
686 2016-09-01T19:56:46  <wumpus> yes, ping will work for that, but it's unclear how to use that in RPC tests
687 2016-09-01T19:56:51  <cfields> i was thinking about some rpc call like "wait_for_[height|block]" that would block until reached and finished processing everywhere. then we wouldn't need to loop
688 2016-09-01T19:56:56  <gmaxwell> we had that discussion with cfields before, which is why I mention it. :P
689 2016-09-01T19:56:58  <cfields> i suppose that just introduces its own issues, though
690 2016-09-01T19:57:03  <cfields> heh
691 2016-09-01T19:57:14  <wumpus> no, the barrier effect certainly shouldn't be removed, unless a better mechanism is introduced
692 2016-09-01T19:57:34  <BlueMatt> (I'd actually kinda like a test which relies on pings being barriers, since some software assumes that for the p2p network, and, in fact, for some things you have to)
693 2016-09-01T19:57:39  <gmaxwell> (I actually like ping being head of line blocked for the reason that it lets you measure processing delays of your remote peers)
694 2016-09-01T19:57:40  <wumpus> and that's a huge protocol change, so probably not worth it right now
695 2016-09-01T19:57:55  <sipa> yes, that's out of scope
696 2016-09-01T19:57:58  <gmaxwell> sorry, I started a tangent.
697 2016-09-01T19:58:01  <cfields> well, as a nasty short-term fix, we can just throw some sleeps in after sync. that should at least shut travis up while we work on a fix
698 2016-09-01T19:58:08  <sipa> for a "get the damn unit tests to work again", at least
699 2016-09-01T19:58:10  <gmaxwell> in any case, maybe ping can be used to sync for these tests.
700 2016-09-01T19:58:14  <BlueMatt> 2 min bell
701 2016-09-01T19:58:30  <wumpus> sleeps are pretty terrible, it's easy to get those wrong and travis has a very unpredictable load pattern
702 2016-09-01T19:58:32  <gmaxwell> sleeps for now sound fine to me. We could all use more sleep.
703 2016-09-01T19:58:37  <wumpus> hah
704 2016-09-01T19:58:49  <sdaftuar> i was seeing this a bunch, but i haven't looked at the latest fails yet to confirm if they're the same: https://0bin.net/paste/nvDO+4yPU0w5332j#Y4BWnYpKcTTIW6ePHglWpEwpE4XtfA+I-NP2M3ObMkp
705 2016-09-01T19:58:53  <jonasschnelli> sleeps will just kick the problem a bit further down...
706 2016-09-01T19:58:55  <BlueMatt> cfields: if we commit to reverting it within X days, ACK
707 2016-09-01T19:58:55  <wumpus> but indeed this started when the timeouts were lowered all over the place
708 2016-09-01T19:58:58  <gmaxwell> tests randomly faily though is ... not good.
709 2016-09-01T19:59:07  <jtimon> cfields: go with the sleeps, better solutions later
710 2016-09-01T19:59:08  <gmaxwell> jonasschnelli: I'm not suggesting delting fixing things at all.
711 2016-09-01T19:59:08  <jonasschnelli> and a sleep in sync_all will have a performance impact on the test-duration-tim
712 2016-09-01T19:59:28  <jonasschnelli> though, ack on the sleep for now
713 2016-09-01T19:59:36  <sipa> sgtm
714 2016-09-01T19:59:38  <wumpus> right
715 2016-09-01T19:59:39  <cfields> BlueMatt: +1 for that. Sleeps are ripped out at next meeting if they're still there, and the tests fails again
716 2016-09-01T19:59:48  <gmaxwell> we must not habituate ourselves to test failures being orinary, already that we weren't responding to failures as a potential emergency indicates we're in a bad state.
717 2016-09-01T19:59:49  <BlueMatt> ACK
718 2016-09-01T19:59:55  <sdaftuar> gmaxwell: yep
719 2016-09-01T20:00:03  <BlueMatt> ACK to gmaxwell and cfields
720 2016-09-01T20:00:08  <BlueMatt> also, dingdingding
721 2016-09-01T20:00:09  <sipa> POING
722 2016-09-01T20:00:10  <wumpus> #endmeeting
723 2016-09-01T20:00:10  <lightningbot> Meeting ended Thu Sep  1 20:00:10 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
724 2016-09-01T20:00:10  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-01-19.01.html
725 2016-09-01T20:00:10  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-01-19.01.txt
726 2016-09-01T20:00:10  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-01-19.01.log.html
727 2016-09-01T20:00:25  <wumpus> gmaxwell: yes it's not a good thing that travis failures are a normal thing now
728 2016-09-01T20:00:37  <wumpus> I tend to rely on local tests more and more
729 2016-09-01T20:00:59  <wumpus> if that continues, travis just becomes a distraction
730 2016-09-01T20:01:05  <sipa> ;;tslb
731 2016-09-01T20:01:07  <gribble> Time since last block: 31 minutes and 15 seconds
732 2016-09-01T20:01:18  <cfields> an alternative is to avoid giving up cs_main while the wallet syncs, but i suppose we shouldn't neuter real usage for the sake of tests :p
733 2016-09-01T20:01:44  <wumpus> cfields: yes, and adding a flag to do that for the tests kind of defeats the purpose of tests too
734 2016-09-01T20:01:55  <wumpus> let's try to solve it properly
735 2016-09-01T20:02:11  <petertodd> gmaxwell: I'm aware that we changed relay behavior; forget the exact details there
736 2016-09-01T20:02:41  <cfields> wumpus: sure, that wasn't a real suggestion
737 2016-09-01T20:02:49  <gmaxwell> petertodd: regarding batching, 0.13 changed relay behavior so every peer has a possion timer (5 seconds expected or 2 seconds for outbound),  no relaying happens on a peer until the timer hits again.  when relaying happens, the transactions are checked to see if they're still in mempool and still passing fee filter.. and relayed in topology+feerate sorted order
738 2016-09-01T20:03:07  <jeremyrubin> (a "stopgap" measure till better things are worked out could be to run the rpc tests 3 times and take a best of three; that way we at least get rpc_tests not blocking probably working code)
739 2016-09-01T20:03:14  <gmaxwell> petertodd: so I'm pointing out that if the replacement arrives soon, and the original is removed from the mempool, it will never get offered to most peers.
740 2016-09-01T20:03:33  <wumpus> cfields: adding a wait RPC specific to testing to wait for completion of some ongoing things would be fine, though
741 2016-09-01T20:04:00  <jeremyrubin> (that would at least help us catalouge a definitely non-deterministic failure)
742 2016-09-01T20:04:17  <gmaxwell> jeremyrubin: I don't think thats better than increasing the sync sleeping... it would conceal real issue of kinds that we've encountered before, and it would make travis much slower. :)
743 2016-09-01T20:04:18  <petertodd> gmaxwell: right, so in the malleability case, if we get a 1-byte-less transaction, but haven't sent out the previous one yet to many of our peers, it'd be perfectly reasonable to replace, for instance
744 2016-09-01T20:04:21  <cfields> wumpus: i've often thought that would be very helpful. Not sure how to avoid long timeouts when things really do fail, though
745 2016-09-01T20:04:31  *** xiangfu has quit IRC
746 2016-09-01T20:04:40  <jtimon> agreed, if we get used to "that's probably a travis thing, just push again" then it becomes kind of worthless, when it fails you should be able to get the same error at home
747 2016-09-01T20:05:07  <wumpus> cfields: well we already have plenty of timeouts, can't become that much worse, most important is that everything is logged so that it can be troublehsooted
748 2016-09-01T20:05:10  <gmaxwell> petertodd: right. in general I think the replacement should always happen in the mempool, and if we relay or not is a seperate decision.
749 2016-09-01T20:05:11  <cfields> wumpus: so maybe not wait-for-completion, but wait-for-a-while?
750 2016-09-01T20:05:32  <jeremyrubin> gmaxwell: you can still have it fail; but at least being able to have an estimate of if it is deterministic fail or spurrious would be useful
751 2016-09-01T20:05:33  <gmaxwell> petertodd: and for CB we should have a rejection/eviction cache.
752 2016-09-01T20:05:39  <cfields> wumpus: fair point
753 2016-09-01T20:05:51  <petertodd> gmaxwell: CB? compact blocks?
754 2016-09-01T20:05:53  <sdaftuar> gmaxwell: why do we need an eviction cache, if we're using feefilter?
755 2016-09-01T20:05:54  <gmaxwell> jeremyrubin: okay, potentially useful. Though the time is a concern.
756 2016-09-01T20:05:55  *** xiangfu has joined #bitcoin-core-dev
757 2016-09-01T20:05:59  <sdaftuar> oh
758 2016-09-01T20:06:01  <sdaftuar> i misunderstood
759 2016-09-01T20:06:25  <jeremyrubin> gmaxwell: can have further runs only happen if the last one fails
760 2016-09-01T20:06:28  *** w00t88 has quit IRC
761 2016-09-01T20:06:44  <jeremyrubin> gmaxwell: (up to a bound)
762 2016-09-01T20:06:45  <cfields> wumpus: wait_for_block(height, hash) seems pretty obvious. If either one is hit without matching, it returns failure. That at least eliminates some potential timeouts
763 2016-09-01T20:06:46  <gmaxwell> jeremyrubin: too bad there is probably no way to report the failure right away and keep running. :P
764 2016-09-01T20:06:54  <petertodd> gmaxwell: this could solve this SIGHASH_ANYONECANPAY issue w/o having to put in specific support for SIGHASH_ANYONECANPAY
765 2016-09-01T20:06:57  * jeremyrubin shakes fist at travis
766 2016-09-01T20:07:47  <wumpus> cfields: what about a 'wait for a change in either height or hash'?
767 2016-09-01T20:07:56  <wumpus> cfields: the client can then check the details
768 2016-09-01T20:08:02  <jeremyrubin> gmaxwell: after_failure hook? Not sure when those get run w.r.t. ui updates :)
769 2016-09-01T20:08:05  <cfields> jeremyrubin: seems to me that behavior belongs in the test-script, so that it can be done locally as well
770 2016-09-01T20:08:29  <jeremyrubin> cfields: fair.
771 2016-09-01T20:08:42  <gmaxwell> petertodd: my current mental model for how all this stuff should work is that you should make your mempool the best, and then have a bandwidth limited process that at every timestep uses the available bandwidth in the best way you can to bring your peers closer to your idea of the best. And for the purpose of CB you should keep around recent second bests for a little while.
772 2016-09-01T20:08:53  <cfields> wumpus: makes sense. and in that case, we block until everything is done processing rather than asap
773 2016-09-01T20:08:56  <jeremyrubin> cfields: proposal: failed test gets re-run once after all tests complete?
774 2016-09-01T20:08:57  <cfields> wumpus: i like that.
775 2016-09-01T20:09:00  <wumpus> cfields: doesn't matter to loop a bit in the client, after all
776 2016-09-01T20:09:02  <wumpus> cfields: right
777 2016-09-01T20:09:14  <jtimon> gmaxwell: oh, even with the parallel rpc tests you still wait for all to fail without seeing anything...yuck
778 2016-09-01T20:09:44  <petertodd> gmaxwell: makes sense to me too
779 2016-09-01T20:09:54  <cfields> wumpus: i should think that would speed tests up a pretty good bit as well. avoids tons of msec waits
780 2016-09-01T20:10:13  <petertodd> gmaxwell: also, at some point you want to be transmitting tx replacement deltas, rather than full txs, but that's an advanced topic...
781 2016-09-01T20:10:42  <cfields> wumpus: ok, that sounds simple enough. only complication would be waiting for the wallet
782 2016-09-01T20:10:58  * cfields crosses his fingers that there's some signal/condvar already doing that
783 2016-09-01T20:11:09  <gmaxwell> I don't know that that would be worth the effort. maybe. once you compress the tx format, most of the size comes from high entropy parts in signatures which would change on most modifications.
784 2016-09-01T20:11:18  <petertodd> gmaxwell: a simple first step might be to have a boolean flag in AcceptToMemPool the decides whether or not we'll relay this newly accepted transaction
785 2016-09-01T20:11:55  <petertodd> gmaxwell: in the transaction replacement case, often you'll just be changing small parts of a tx - sigs don't come into it (especially if it's malleability that lead to the replacement)
786 2016-09-01T20:11:56  <wumpus> cfields: yes, it needs to be a wallet call
787 2016-09-01T20:12:10  <sdaftuar> petertodd: for context, are you talking about a replacement policy specifically for when txids match existing ones (ie malleated segwit transactions), or something more general?
788 2016-09-01T20:12:28  <jtimon> gmaxwell: yep, your idea of the ideal mempool/relay management is great and respectful with diverse policies, I was scared when I read the first "the best" and breathed with "your idea of the best"
789 2016-09-01T20:12:30  <gmaxwell> petertodd: I just mean that if the modification changes outputs, it will normally change signatures...
790 2016-09-01T20:12:35  <petertodd> sdaftuar: slightly more general; I'd do it so long as the vout is the same
791 2016-09-01T20:12:58  <petertodd> gmaxwell: normally :) but not always, e.g. SIGHASH_ANYONECANPAY
792 2016-09-01T20:13:17  <sdaftuar> oh, so if someone adds an input, you can remove it
793 2016-09-01T20:13:27  <sdaftuar> i think you guys were discussing that on some PR?
794 2016-09-01T20:14:09  <petertodd> sdaftuar: yup
795 2016-09-01T20:14:14  <petertodd> sdaftuar: https://github.com/bitcoin/bitcoin/pull/8543
796 2016-09-01T20:14:17  <sdaftuar> thanks
797 2016-09-01T20:14:31  <jtimon> note that the "second best" pool may not be "second best" at all, maybe stuff that passes your minimums and your peers seem to repeat for some unkown reason (they should know that's not the best, but at least they agree on being wrong on the same weird way)
798 2016-09-01T20:14:46  <gmaxwell> jtimon: well unlikely luke I don't actually believe that different policies (beyond straight resource limits) are actually virtuious, but in a hetrogenious network, with softforks and whatever, its simply unrealistic to expect equal policy even though I think it would be ideal to have equal policy.
799 2016-09-01T20:15:27  <gmaxwell> jtimon: yea by 'second best' I really meant something more like "data you previously had, prioritized by how shocked you'd be to see it in a block"
800 2016-09-01T20:15:47  <gmaxwell> e.g. you wouldn't keep invalid transactions, but you would keep non-standard ones.
801 2016-09-01T20:16:08  <gmaxwell> s/unlikely/unlike/
802 2016-09-01T20:16:41  <jtimon> I guess it's kind of a philosophically pedantic way of saying "hey, this is not consensus code", but terms...we agree on the overall design
803 2016-09-01T20:17:04  <jtimon> gmaxwell: lol, let's call it "the shockpool"
804 2016-09-01T20:18:09  <jtimon> but I really don't know what criteria would I use there
805 2016-09-01T20:19:51  <cfields> wumpus: looking closer, if we subscribe to a signal rather than just hammering on chainActive.Tip(), the wallet will have already been sync'd. So that's easy. doing it up now.
806 2016-09-01T20:20:32  <sdaftuar> cfields: ah, good idea
807 2016-09-01T20:21:25  <gmaxwell> jtimon: well obviously you just use machine learning to predict what will end up in blocks... :P
808 2016-09-01T20:22:29  <petertodd> gmaxwell: better, yet, use hashing power to make your predictions come true...
809 2016-09-01T20:22:35  <jtimon> gmaxwell: of course, I'm ashamed I hadn't thought of a neural network, the fact that txs are variable size shouldn't stop us...
810 2016-09-01T20:22:59  <gmaxwell> jtimon: hah well actually running a model on the tx data itself is not likely to work well without a very big model.
811 2016-09-01T20:23:06  <gmaxwell> feature vector is [feerate, tx version, vector of failed is standard rules, time in the shockpool] and the model outputs a ranking that tells you how long you should retain it. :P
812 2016-09-01T20:23:21  <gmaxwell> I've suggested similar things for utxo cache management in the past.
813 2016-09-01T20:24:26  <jeremyrubin> Can I ask for some thoughts on the checkqueue stuff?
814 2016-09-01T20:24:56  <jtimon> gmaxwell: model? what's wrong with feeding them binary data?
815 2016-09-01T20:25:13  <jtimon> </sarcasm>
816 2016-09-01T20:25:36  <jeremyrubin> My basic plan for restructuring was to add the benchmarks for the earlier version and then add the new version. I wasn't going to make my tests work for the old code, but could do it if that's neccessary for review
817 2016-09-01T20:25:45  <gmaxwell> jtimon: nothing, except the result will require a large, deep, complex and hard to train network. at it has to learn transaction parsing. The result would be low performance enough that I think it would preclude actually using for anything except a toy. :)
818 2016-09-01T20:25:49  <gmaxwell> oh okay.
819 2016-09-01T20:25:51  <gmaxwell> :P
820 2016-09-01T20:25:59  <jeremyrubin> (also if anyone would care to try testing it out would be great help for me)
821 2016-09-01T20:26:27  <jeremyrubin> (for reference, PR is here https://github.com/bitcoin/bitcoin/pull/8464)
822 2016-09-01T20:29:26  <Chris_Stewart_5> jeremyrubin: Might be worth while to look at #8469 and write some properties for testing
823 2016-09-01T20:30:02  <gmaxwell> jonasschnelli: thanks for that backport.
824 2016-09-01T20:30:48  <jeremyrubin> Chris_Stewart_5: looks cool; I have a pretty good test suite I added already though. When that gets merged I'd be happy to
825 2016-09-01T20:31:26  *** gabridome1 has joined #bitcoin-core-dev
826 2016-09-01T20:32:38  *** cryptapus has quit IRC
827 2016-09-01T20:34:09  *** gabridome has quit IRC
828 2016-09-01T20:34:15  <jtimon> gmaxwell: yep, it would need to learn script parsing, for all I know, random search may be as good as anything else for training in this case
829 2016-09-01T20:36:23  *** HoloIRCUser6 has joined #bitcoin-core-dev
830 2016-09-01T20:36:24  *** gabridome1 has quit IRC
831 2016-09-01T20:36:44  *** gabridome has joined #bitcoin-core-dev
832 2016-09-01T20:37:41  *** gabridome1 has joined #bitcoin-core-dev
833 2016-09-01T20:40:51  *** HoloIRCUser6 has quit IRC
834 2016-09-01T20:41:01  *** gabridome has quit IRC
835 2016-09-01T20:41:17  *** kadoban has joined #bitcoin-core-dev
836 2016-09-01T20:42:26  *** Chris_St1 has joined #bitcoin-core-dev
837 2016-09-01T20:43:13  *** Chris_Stewart_5 has quit IRC
838 2016-09-01T20:49:38  <gmaxwell> PR #8212 needs backport too.
839 2016-09-01T20:49:49  <gmaxwell> er I meant PR #8612.
840 2016-09-01T20:51:46  *** luke-jr has quit IRC
841 2016-09-01T20:51:54  *** luke-jr has joined #bitcoin-core-dev
842 2016-09-01T20:52:44  <instagibbs> what's the New Improved Way(TM) to get uint256 as string
843 2016-09-01T20:53:07  <instagibbs> still working my way around git blaming in reverse, failing me right now
844 2016-09-01T20:54:34  <gmaxwell> instagibbs: do you mean as hex?
845 2016-09-01T20:54:42  <instagibbs> yeah hex string
846 2016-09-01T20:57:31  <instagibbs> oh weight, nevermind me, just in .cpp now, and complaining
847 2016-09-01T20:57:36  <instagibbs> wait even
848 2016-09-01T20:57:47  <instagibbs> probably just fat fingered
849 2016-09-01T20:59:49  *** Eliel_ has quit IRC
850 2016-09-01T21:00:19  *** HoloIRCUser has joined #bitcoin-core-dev
851 2016-09-01T21:00:23  *** Eliel has joined #bitcoin-core-dev
852 2016-09-01T21:06:28  *** Chris_St1 has quit IRC
853 2016-09-01T21:13:47  *** grubles has quit IRC
854 2016-09-01T21:14:37  <gmaxwell> interesting:
855 2016-09-01T21:14:39  <gmaxwell> 2016-09-01 15:35:29.537118 replacing tx 528f6cbebe29fa6bdab3be077a48754c2371df2fbf4cbb8fbc11992fdeb26470 with
856 2016-09-01T21:14:42  <gmaxwell> 922a0895c7246b46533d1d356152bde2477cc9987c96b78e02da4d5869e4b7cc for 0.00008873 BTC additional fees, -194 delta bytes
857 2016-09-01T21:14:45  <gmaxwell> 2016-09-01 15:35:29.537194 replacing tx 308a560e8e90ccaf64af9f5cd3b1dcfe4bccf8d49d73b0460b95b1616bb26c9d with
858 2016-09-01T21:14:48  <gmaxwell> 922a0895c7246b46533d1d356152bde2477cc9987c96b78e02da4d5869e4b7cc for 0.00008873 BTC additional fees, -194 delta bytes
859 2016-09-01T21:14:51  <gmaxwell> 2016-09-01 15:35:50.780139 Successfully reconstructed block 000000000000000002f65cc5054fefb1b8fe75ebb685ac6b51f05dac0b84ee3d with 1 txn
860 2016-09-01T21:14:54  <gmaxwell> prefilled, 2465 txn from mempool and 2 txn requested 2016-09-01 15:35:50.780208 Reconstructed block
861 2016-09-01T21:14:57  <gmaxwell> 000000000000000002f65cc5054fefb1b8fe75ebb685ac6b51f05dac0b84ee3d required tx
862 2016-09-01T21:15:00  <gmaxwell> 528f6cbebe29fa6bdab3be077a48754c2371df2fbf4cbb8fbc11992fdeb26470
863 2016-09-01T21:15:03  <gmaxwell> 2016-09-01 15:35:50.780253 Reconstructed block 000000000000000002f65cc5054fefb1b8fe75ebb685ac6b51f05dac0b84ee3d required tx
864 2016-09-01T21:15:06  <gmaxwell> 308a560e8e90ccaf64af9f5cd3b1dcfe4bccf8d49d73b0460b95b1616bb26c9d
865 2016-09-01T21:18:43  <gmaxwell> other recent CB extra round trips were: a single txn that failed minfee 30 minutes before the block, a pair of transactions that were rejected due to being mempool conflicts ~5-10 minutes before the block, and an orphan that was in my orphan pool at the time.
866 2016-09-01T21:22:01  <luke-jr> gmaxwell: presumably the parent of the orphan was missing in your mempool? was that one of the conflicts?
867 2016-09-01T21:23:04  <gmaxwell> those were three steperate blocks.
868 2016-09-01T21:23:33  *** HoloIRCUser has quit IRC
869 2016-09-01T21:23:42  <luke-jr> so what was the cause of the orphan not being in the mempool (or rejected)?
870 2016-09-01T21:23:53  <gmaxwell> yea, trying to figure that out.
871 2016-09-01T21:24:09  *** HoloIRCUser has joined #bitcoin-core-dev
872 2016-09-01T21:24:24  <gmaxwell> maybe it actually had been evicted by the time the parent came around.
873 2016-09-01T21:24:41  <gmaxwell> 2016-09-01 11:50:23.982337 stored orphan tx aeb9dac61cf2cc7fd535f2b4b685070b0dce2690c9f78d9987335cbadedf5aa3 (mapsz 101 outsz 110)
874 2016-09-01T21:25:13  <gmaxwell> 2016-09-01 11:53:45.913417 Successfully reconstructed block 000000000000000004e70299cd0284b177412b63144fc4b9c6080c65545e875b with 1 txn prefilled, 1868 txn from mempool and 1 txn requested
875 2016-09-01T21:25:27  <gmaxwell> 2016-09-01 11:53:45.913505 Reconstructed block 000000000000000004e70299cd0284b177412b63144fc4b9c6080c65545e875b required tx aeb9dac61cf2cc7fd535f2b4b685070b0dce2690c9f78d9987335cbadedf5aa3
876 2016-09-01T21:26:02  <luke-jr> hmm
877 2016-09-01T21:26:29  <gmaxwell> looking up the parents now.
878 2016-09-01T21:28:22  <luke-jr> FWIW, looking through my logs, most blocks seem to require a round trip. not particularly surprising (spam I assume)
879 2016-09-01T21:28:32  <gmaxwell> luke-jr: wow, no way.
880 2016-09-01T21:28:37  *** HoloIRCUser has quit IRC
881 2016-09-01T21:29:11  *** pmienk has quit IRC
882 2016-09-01T21:29:29  <luke-jr> http://0bin.net/paste/nELoeFqIuT4891qP#P8ugYLrvtlhggdD80jGS5NDOuhJYpJ37JgDgHiGF1CF
883 2016-09-01T21:30:08  <gmaxwell> grep econs ~/.bitcoin/debug.log  | tail -n 100 | awk '{aa+=$16>1} END {print aa/NR}'
884 2016-09-01T21:30:11  <gmaxwell> 0.11
885 2016-09-01T21:30:14  <gmaxwell> 11% here.
886 2016-09-01T21:30:53  *** Chris_St1 has joined #bitcoin-core-dev
887 2016-09-01T21:30:59  <luke-jr> 0.661538
888 2016-09-01T21:31:05  <gmaxwell> how long have you been up?
889 2016-09-01T21:31:49  <gmaxwell> my past expirence is that it takes a good 24 hour uptime before it really behaves normally (and I think I saw measureable improvement for up to three days, though much of that was due to orphans, which should be less bad since the other changes.)
890 2016-09-01T21:32:52  <gmaxwell> also, if you have an atypical mempool policy, thats going to slow you down.. until we get some kind of rejects cache going.
891 2016-09-01T21:33:11  <luke-jr> about 1.5 hours now, but quite a bit longer before that restart
892 2016-09-01T21:33:27  <luke-jr> yes, that's why I said not surprising ;)
893 2016-09-01T21:33:43  <gmaxwell> oh... 'spam I assume'
894 2016-09-01T21:33:46  <gmaxwell> indeed. okay.
895 2016-09-01T21:35:54  <luke-jr> sub-second round-trip for 3 txn, so I assume it's still a gain
896 2016-09-01T21:37:04  <gmaxwell> luke-jr: yes, I found that it was in testing.
897 2016-09-01T21:41:41  *** Guyver2 has quit IRC
898 2016-09-01T21:44:46  *** pmienk has joined #bitcoin-core-dev
899 2016-09-01T21:58:10  *** Chris_St1 has quit IRC
900 2016-09-01T22:01:09  *** spudowiar has joined #bitcoin-core-dev
901 2016-09-01T22:11:46  *** Chris_St1 has joined #bitcoin-core-dev
902 2016-09-01T22:12:51  *** justanotheruser has joined #bitcoin-core-dev
903 2016-09-01T22:18:48  *** Giszmo has quit IRC
904 2016-09-01T22:19:04  *** Chris_St1 has quit IRC
905 2016-09-01T22:24:30  *** Giszmo has joined #bitcoin-core-dev
906 2016-09-01T22:28:40  *** grubles has joined #bitcoin-core-dev
907 2016-09-01T22:28:40  *** aalex has quit IRC
908 2016-09-01T22:31:35  *** aalex has joined #bitcoin-core-dev
909 2016-09-01T22:35:25  *** Chris_St1 has joined #bitcoin-core-dev
910 2016-09-01T23:00:28  *** Chris_St1 has quit IRC
911 2016-09-01T23:32:15  *** TomMc has quit IRC
912 2016-09-01T23:36:07  *** Alopex has quit IRC
913 2016-09-01T23:37:12  *** Alopex has joined #bitcoin-core-dev
914 2016-09-01T23:46:33  *** AaronvanW has quit IRC