12016-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
  22016-09-01T00:29:56  *** murch has quit IRC
  32016-09-01T00:33:14  *** isis is now known as isis_
  42016-09-01T00:45:54  *** Ylbam has quit IRC
  52016-09-01T00:47:45  *** fengling has joined #bitcoin-core-dev
  62016-09-01T00:51:56  *** belcher has joined #bitcoin-core-dev
  72016-09-01T00:52:46  *** fengling has quit IRC
  82016-09-01T01:02:01  *** Alopex has quit IRC
  92016-09-01T01:02:42  *** isis_ is now known as isis
 102016-09-01T01:03:06  *** Alopex has joined #bitcoin-core-dev
 112016-09-01T01:03:16  *** Samdney has left #bitcoin-core-dev
 122016-09-01T01:19:19  *** randy-waterhouse has joined #bitcoin-core-dev
 132016-09-01T01:31:27  *** Chris_Stewart_5 has quit IRC
 142016-09-01T01:32:27  *** pmienk has quit IRC
 152016-09-01T01:32:57  *** pmienk has joined #bitcoin-core-dev
 162016-09-01T01:33:40  *** grubles has quit IRC
 172016-09-01T01:35:06  *** Alopex has quit IRC
 182016-09-01T01:36:11  *** Alopex has joined #bitcoin-core-dev
 192016-09-01T01:49:15  *** fengling has joined #bitcoin-core-dev
 202016-09-01T01:51:47  *** jtimon has quit IRC
 212016-09-01T01:52:46  <instagibbs> am I the only one who never types in those types of commands in chat windows? :)
 222016-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
 232016-09-01T01:55:06  *** fengling has quit IRC
 242016-09-01T01:55:37  <achow101> not me! :D Changed all those passwords
 252016-09-01T01:56:28  <instagibbs> hypothetically speaking of course >_>
 262016-09-01T01:58:59  <kanzure> we should probably tell achow101 that he should use better passwords :)
 272016-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.
 282016-09-01T02:00:31  <warren> That's the combination on my luggage!
 292016-09-01T02:05:34  *** achow101 has quit IRC
 302016-09-01T02:05:53  *** achow101 has joined #bitcoin-core-dev
 312016-09-01T02:06:09  *** fengling has joined #bitcoin-core-dev
 322016-09-01T02:21:06  *** fengling has quit IRC
 332016-09-01T02:31:22  *** Alopex has quit IRC
 342016-09-01T02:32:27  *** Alopex has joined #bitcoin-core-dev
 352016-09-01T02:53:09  *** fengling has joined #bitcoin-core-dev
 362016-09-01T02:54:22  *** Alopex has quit IRC
 372016-09-01T02:55:27  *** Alopex has joined #bitcoin-core-dev
 382016-09-01T03:21:08  *** dcousens has quit IRC
 392016-09-01T03:22:28  <luke-jr> are we actively trying to remove boost in non-consensus code, or is it okay to use?
 402016-09-01T03:23:10  *** dcousens has joined #bitcoin-core-dev
 412016-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.
 422016-09-01T03:33:39  *** TomMc has joined #bitcoin-core-dev
 432016-09-01T03:34:56  *** naco has joined #bitcoin-core-dev
 442016-09-01T03:39:21  *** spudowiar has quit IRC
 452016-09-01T03:43:21  *** TomMc has quit IRC
 462016-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
 472016-09-01T03:52:26  <gmaxwell> ugh, do you really want boost::any? we like static typing..
 482016-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
 492016-09-01T03:54:29  <luke-jr> but perhaps there's a way to workaround this
 502016-09-01T03:55:14  <luke-jr> (eg, move the parse internal to the setter, and set by string)
 512016-09-01T04:14:33  *** justan0theruser has joined #bitcoin-core-dev
 522016-09-01T04:16:31  *** justanotheruser has quit IRC
 532016-09-01T04:34:17  *** slackircbridge1 has joined #bitcoin-core-dev
 542016-09-01T04:35:01  *** pavel_ has joined #bitcoin-core-dev
 552016-09-01T04:36:56  *** paveljanik has quit IRC
 562016-09-01T04:37:58  *** NicolasDorier has quit IRC
 572016-09-01T04:37:58  *** slackircbridge has quit IRC
 582016-09-01T04:38:14  *** CodeShark has quit IRC
 592016-09-01T04:39:28  *** NicolasDorier has joined #bitcoin-core-dev
 602016-09-01T04:39:49  *** CodeShark has joined #bitcoin-core-dev
 612016-09-01T04:48:46  *** cfields has quit IRC
 622016-09-01T04:48:53  *** cfields has joined #bitcoin-core-dev
 632016-09-01T04:48:58  *** Giszmo has quit IRC
 642016-09-01T04:50:00  *** Giszmo has joined #bitcoin-core-dev
 652016-09-01T04:50:18  *** pavel_ has quit IRC
 662016-09-01T04:51:39  *** Giszmo has quit IRC
 672016-09-01T04:54:38  *** justanotheruser has joined #bitcoin-core-dev
 682016-09-01T04:58:16  *** justan0theruser has quit IRC
 692016-09-01T05:03:08  *** zmanian__ has quit IRC
 702016-09-01T05:03:08  *** ibrightly has quit IRC
 712016-09-01T05:05:21  *** ibrightly has joined #bitcoin-core-dev
 722016-09-01T05:06:17  *** zmanian__ has joined #bitcoin-core-dev
 732016-09-01T05:13:06  *** michagogo has quit IRC
 742016-09-01T05:14:52  *** michagogo has joined #bitcoin-core-dev
 752016-09-01T05:27:33  *** paveljanik has joined #bitcoin-core-dev
 762016-09-01T05:46:53  *** AtashiCon has quit IRC
 772016-09-01T06:04:12  *** AtashiCon has joined #bitcoin-core-dev
 782016-09-01T06:07:01  *** Alopex has quit IRC
 792016-09-01T06:08:07  *** Alopex has joined #bitcoin-core-dev
 802016-09-01T06:19:24  *** PaulCape_ has joined #bitcoin-core-dev
 812016-09-01T06:21:32  *** PaulCapestany has quit IRC
 822016-09-01T06:21:33  *** instagibbs has quit IRC
 832016-09-01T06:21:33  *** limpkin has quit IRC
 842016-09-01T06:21:45  *** instagibbs has joined #bitcoin-core-dev
 852016-09-01T06:22:00  *** mn3monic has quit IRC
 862016-09-01T06:22:31  *** limpkin has joined #bitcoin-core-dev
 872016-09-01T06:22:51  *** justanotheruser has quit IRC
 882016-09-01T06:26:41  *** kadoban has quit IRC
 892016-09-01T06:50:52  *** aalex has quit IRC
 902016-09-01T06:52:45  *** aalex has joined #bitcoin-core-dev
 912016-09-01T06:59:38  *** BashCo has quit IRC
 922016-09-01T07:02:39  *** laurentmt has joined #bitcoin-core-dev
 932016-09-01T07:04:23  *** kyletorpey has quit IRC
 942016-09-01T07:06:21  *** laurentmt has quit IRC
 952016-09-01T07:08:09  *** assder has joined #bitcoin-core-dev
 962016-09-01T07:08:18  *** randy-waterhouse has quit IRC
 972016-09-01T07:11:54  <GitHub15> [bitcoin] rebroad reopened pull request #8622: [WIP] Clarify variable names (master...ClarifyVariableNames) https://github.com/bitcoin/bitcoin/pull/8622
 982016-09-01T07:12:05  *** dcousens has quit IRC
 992016-09-01T07:18:49  *** BashCo has joined #bitcoin-core-dev
1002016-09-01T07:20:55  *** adiabat has quit IRC
1012016-09-01T07:23:06  *** warren has quit IRC
1022016-09-01T07:24:21  *** warren has joined #bitcoin-core-dev
1032016-09-01T07:24:47  *** jtimon has joined #bitcoin-core-dev
1042016-09-01T07:32:14  *** FNinTak has joined #bitcoin-core-dev
1052016-09-01T08:01:27  *** Evel-Knievel has quit IRC
1062016-09-01T08:01:42  *** Evel-Knievel has joined #bitcoin-core-dev
1072016-09-01T08:02:12  *** jtimon has quit IRC
1082016-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
1092016-09-01T08:05:35  <GitHub45> [bitcoin] sipa closed pull request #8622: [WIP] Clarify variable names (master...ClarifyVariableNames) https://github.com/bitcoin/bitcoin/pull/8622
1102016-09-01T08:05:42  *** jonasschnelli has quit IRC
1112016-09-01T08:06:47  *** jonasschnelli has joined #bitcoin-core-dev
1122016-09-01T08:07:05  *** laurentmt has joined #bitcoin-core-dev
1132016-09-01T08:07:06  *** laurentmt has quit IRC
1142016-09-01T08:15:46  *** laurentmt has joined #bitcoin-core-dev
1152016-09-01T08:17:37  *** mn3monic has joined #bitcoin-core-dev
1162016-09-01T08:19:14  *** Guyver2 has joined #bitcoin-core-dev
1172016-09-01T08:24:45  *** laurentmt has quit IRC
1182016-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
1192016-09-01T08:25:20  <luke-jr> sigh
1202016-09-01T08:28:26  <gmaxwell> I dunno whats going on there.
1212016-09-01T08:28:38  <gmaxwell> I feel like I am being fuzz tested.
1222016-09-01T08:28:42  <luke-jr> lol
1232016-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.
1242016-09-01T08:31:02  <gmaxwell> those changes will throughly break communications with at least some versions.
1252016-09-01T08:32:47  <sipa> gmaxwell: it seems intentional
1262016-09-01T08:33:30  <gmaxwell> it's completely wildly handled though, sending garbage messages to peers that will tell who knows what malfunction.
1272016-09-01T08:35:24  <sipa> one of the commits mentions that a protocol change introduced in 2010 should be supported by everyone
1282016-09-01T08:35:37  <sipa> but he kills pre-bip31 nodes as well, which dates from 2012
1292016-09-01T08:38:48  <gmaxwell> yea, I was looking at the BIP31 changes and scratching my head.
1302016-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
1312016-09-01T08:39:30  <luke-jr> (if vRecv has nonce data, read and use it; otherwise, don't)
1322016-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.
1332016-09-01T08:48:36  *** slackircbridge has joined #bitcoin-core-dev
1342016-09-01T08:50:14  *** lukedashjr has joined #bitcoin-core-dev
1352016-09-01T08:50:47  *** Arnavion has quit IRC
1362016-09-01T08:50:52  *** Arnavion has joined #bitcoin-core-dev
1372016-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.
1382016-09-01T08:52:34  <sipa> can someone else other than me comment there?
1392016-09-01T08:53:55  *** ybit_ has joined #bitcoin-core-dev
1402016-09-01T08:54:02  *** ybit_ has quit IRC
1412016-09-01T08:54:02  *** ybit_ has joined #bitcoin-core-dev
1422016-09-01T08:54:27  <gmaxwell> last comment from his is you're right.
1432016-09-01T08:56:13  *** lukedashjr has quit IRC
1442016-09-01T08:56:23  *** lukedashjr has joined #bitcoin-core-dev
1452016-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.
1462016-09-01T08:58:49  *** mn3monic has quit IRC
1472016-09-01T08:58:49  *** aalex has quit IRC
1482016-09-01T08:58:49  *** slackircbridge1 has quit IRC
1492016-09-01T08:58:50  *** sanada` has quit IRC
1502016-09-01T08:58:51  *** Bootvis has quit IRC
1512016-09-01T08:58:51  *** jyap has quit IRC
1522016-09-01T08:58:51  *** go1111111 has quit IRC
1532016-09-01T08:58:52  *** morcos has quit IRC
1542016-09-01T08:58:53  *** ybit has quit IRC
1552016-09-01T08:58:53  *** crudel has quit IRC
1562016-09-01T08:58:53  *** luke-jr has quit IRC
1572016-09-01T08:58:54  *** harding has quit IRC
1582016-09-01T08:58:54  *** gijensen3 has quit IRC
1592016-09-01T08:58:55  *** Taek has quit IRC
1602016-09-01T08:59:09  *** jyap has joined #bitcoin-core-dev
1612016-09-01T08:59:09  *** jyap has joined #bitcoin-core-dev
1622016-09-01T08:59:11  *** gijensen has joined #bitcoin-core-dev
1632016-09-01T09:00:17  *** cdecker has joined #bitcoin-core-dev
1642016-09-01T09:00:28  *** go1111111 has joined #bitcoin-core-dev
1652016-09-01T09:00:38  *** lukedashjr is now known as luke-jr
1662016-09-01T09:01:11  *** JackH has joined #bitcoin-core-dev
1672016-09-01T09:02:31  *** morcos has joined #bitcoin-core-dev
1682016-09-01T09:02:43  *** aalex has joined #bitcoin-core-dev
1692016-09-01T09:03:03  *** mn3monic has joined #bitcoin-core-dev
1702016-09-01T09:03:04  *** sanada` has joined #bitcoin-core-dev
1712016-09-01T09:03:04  *** Bootvis has joined #bitcoin-core-dev
1722016-09-01T09:03:04  *** crudel has joined #bitcoin-core-dev
1732016-09-01T09:03:04  *** harding has joined #bitcoin-core-dev
1742016-09-01T09:03:04  *** Taek has joined #bitcoin-core-dev
1752016-09-01T09:20:51  *** laurentmt has joined #bitcoin-core-dev
1762016-09-01T09:34:11  *** dcousens has joined #bitcoin-core-dev
1772016-09-01T09:50:48  *** laurentmt has quit IRC
1782016-09-01T09:59:37  *** isis is now known as isis_
1792016-09-01T10:04:18  *** isis_ is now known as isis
1802016-09-01T10:11:27  *** AaronvanW has joined #bitcoin-core-dev
1812016-09-01T10:11:28  *** AaronvanW has quit IRC
1822016-09-01T10:11:28  *** AaronvanW has joined #bitcoin-core-dev
1832016-09-01T10:15:18  *** Ginnarr has joined #bitcoin-core-dev
1842016-09-01T10:21:06  <GitHub97> [bitcoin] sipa pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/84decb54f259...19b0f33de0ef
1852016-09-01T10:21:07  <GitHub97> bitcoin/master d2c5d04 Pieter Wuille: Precompute sighashes...
1862016-09-01T10:21:07  <GitHub97> bitcoin/master ab48c5e Nicolas DORIER: Unit test for sighash caching
1872016-09-01T10:21:08  <GitHub97> bitcoin/master 35fe039 Pieter Wuille: Rename to PrecomputedTransactionData
1882016-09-01T10:21:12  <GitHub100> [bitcoin] sipa closed pull request #8524: Precompute sighashes (master...noprecomputecachedhashes) https://github.com/bitcoin/bitcoin/pull/8524
1892016-09-01T10:25:39  <gmaxwell> \O/
1902016-09-01T10:25:41  *** FNinTak has quit IRC
1912016-09-01T10:26:02  *** FNinTak has joined #bitcoin-core-dev
1922016-09-01T10:33:48  *** FNinTak has quit IRC
1932016-09-01T10:34:13  *** FNinTak has joined #bitcoin-core-dev
1942016-09-01T10:37:08  <jl2012> great, one big step closer to 0.13.1
1952016-09-01T10:37:36  *** FNinTak has quit IRC
1962016-09-01T10:39:20  *** cdecker has quit IRC
1972016-09-01T10:39:37  *** Ylbam has joined #bitcoin-core-dev
1982016-09-01T10:39:53  *** cdecker has joined #bitcoin-core-dev
1992016-09-01T10:53:07  *** cdecker has quit IRC
2002016-09-01T11:04:53  *** cdecker has joined #bitcoin-core-dev
2012016-09-01T11:36:27  *** Ginnarr has quit IRC
2022016-09-01T11:42:22  *** Ylbam has quit IRC
2032016-09-01T11:42:22  *** jl2012 has quit IRC
2042016-09-01T11:56:41  <GitHub89> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/2663e5149dc06dedb8c29672abe4b1c645768e52
2052016-09-01T11:56:41  <GitHub89> bitcoin/master 2663e51 Wladimir J. van der Laan: Merge #8640: [depends] Remove Qt46 package...
2062016-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
2072016-09-01T11:56:59  *** Ylbam has joined #bitcoin-core-dev
2082016-09-01T12:00:51  *** jl2012 has joined #bitcoin-core-dev
2092016-09-01T12:02:36  *** pmienk has quit IRC
2102016-09-01T12:17:33  *** jtimon has joined #bitcoin-core-dev
2112016-09-01T12:17:57  *** pmienk has joined #bitcoin-core-dev
2122016-09-01T12:19:09  *** dermoth_ has joined #bitcoin-core-dev
2132016-09-01T12:19:33  *** dermoth has quit IRC
2142016-09-01T12:19:35  *** dermoth_ is now known as dermoth
2152016-09-01T12:32:32  *** cryptapus has joined #bitcoin-core-dev
2162016-09-01T12:37:48  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2172016-09-01T12:42:26  <GitHub162> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2663e5149dc0...0e563d89c075
2182016-09-01T12:42:27  <GitHub162> bitcoin/master 33d15a3 Pavel Janík: Do not shadow LOCK's criticalblock variable for LOCK inside LOCK
2192016-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...
2202016-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
2212016-09-01T12:51:23  *** aalex_ has joined #bitcoin-core-dev
2222016-09-01T12:52:06  *** gijensen is now known as gijensen3
2232016-09-01T12:52:21  *** aalex has quit IRC
2242016-09-01T13:05:20  *** Chris_Stewart_5 has quit IRC
2252016-09-01T13:11:35  *** grubles has joined #bitcoin-core-dev
2262016-09-01T13:13:11  *** slackircbridge has quit IRC
2272016-09-01T13:14:27  *** slackircbridge has joined #bitcoin-core-dev
2282016-09-01T13:20:32  *** slackircbridge has quit IRC
2292016-09-01T13:20:44  *** slackircbridge has joined #bitcoin-core-dev
2302016-09-01T13:20:58  *** laurentmt has joined #bitcoin-core-dev
2312016-09-01T13:25:06  *** TomMc has joined #bitcoin-core-dev
2322016-09-01T13:26:02  *** slackircbridge has quit IRC
2332016-09-01T13:26:15  *** slackircbridge has joined #bitcoin-core-dev
2342016-09-01T13:34:20  *** aalex_ has quit IRC
2352016-09-01T13:36:24  *** laurentmt has quit IRC
2362016-09-01T13:36:29  *** aalex has joined #bitcoin-core-dev
2372016-09-01T13:36:45  *** laurentmt has joined #bitcoin-core-dev
2382016-09-01T13:37:01  *** aalex has quit IRC
2392016-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
2402016-09-01T13:44:52  *** aalex has joined #bitcoin-core-dev
2412016-09-01T13:45:34  *** aalex has quit IRC
2422016-09-01T13:47:37  *** aalex has joined #bitcoin-core-dev
2432016-09-01T13:57:29  <GitHub140> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/0e563d89c075...44691f3c51c9
2442016-09-01T13:57:30  <GitHub140> bitcoin/master fab1f92 MarcoFalke: [contrib] verifybinaries: Adjust parsing to new rc path
2452016-09-01T13:57:30  <GitHub140> bitcoin/master fa917f6 MarcoFalke: [contrib] verifybinaries: Keep downloads by default
2462016-09-01T13:57:31  <GitHub140> bitcoin/master faaed88 MarcoFalke: [contrib] verifybinaries: Mention mandatory preparation step
2472016-09-01T13:57:42  <GitHub143> [bitcoin] laanwj closed pull request #8557: [contrib] Rework verifybinaries (master...Mf1608-verifyBins) https://github.com/bitcoin/bitcoin/pull/8557
2482016-09-01T13:58:09  *** timothy has quit IRC
2492016-09-01T13:58:12  *** drizztbsd has joined #bitcoin-core-dev
2502016-09-01T13:58:38  *** drizztbsd is now known as timothy
2512016-09-01T13:59:03  <GitHub10> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/44691f3c51c9...f061415d12ce
2522016-09-01T13:59:03  <GitHub10> bitcoin/master f012a85 djpnewton: rest.cpp: change HTTP_INTERNAL_SERVER_ERROR to HTTP_BAD_REQUEST
2532016-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...
2542016-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
2552016-09-01T14:03:53  *** LeMiner2 has joined #bitcoin-core-dev
2562016-09-01T14:05:01  *** LeMiner has quit IRC
2572016-09-01T14:05:01  *** LeMiner2 is now known as LeMiner
2582016-09-01T14:14:46  *** fengling has quit IRC
2592016-09-01T14:18:54  *** aalex has quit IRC
2602016-09-01T14:19:27  *** aalex has joined #bitcoin-core-dev
2612016-09-01T14:20:42  *** Giszmo has joined #bitcoin-core-dev
2622016-09-01T14:22:29  *** aalex has quit IRC
2632016-09-01T14:23:00  *** aalex has joined #bitcoin-core-dev
2642016-09-01T14:25:57  <GitHub130> [bitcoin] laanwj pushed 5 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/15502d7b2543...ec0afbd52b78
2652016-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
2662016-09-01T14:25:58  <GitHub130> bitcoin/0.12 ddd8c01 Luke Dashjr: Implement BIP 9 GBT changes...
2672016-09-01T14:25:58  <GitHub130> bitcoin/0.12 40e81f5 Luke Dashjr: qa/rpc-tests: bip9-softforks: Add tests for getblocktemplate versionbits updates
2682016-09-01T14:25:59  <GitHub130> bitcoin/0.12 65ee332 Luke Dashjr: getblocktemplate: Explicitly handle the distinction between GBT-affecting softforks vs not
2692016-09-01T14:28:27  <paveljanik> sipa, PrecomputedTransactionData is defined as struct, but: src/main.h:class PrecomputedTransactionData;
2702016-09-01T14:29:29  <sipa> will fix
2712016-09-01T14:29:37  <paveljanik> ok, thanks.
2722016-09-01T14:32:04  *** slackircbridge has quit IRC
2732016-09-01T14:39:50  *** [b__b] has quit IRC
2742016-09-01T14:40:13  *** Samdney has joined #bitcoin-core-dev
2752016-09-01T14:41:07  *** [b__b] has joined #bitcoin-core-dev
2762016-09-01T14:47:35  *** laurentmt has quit IRC
2772016-09-01T14:47:59  *** laurentmt has joined #bitcoin-core-dev
2782016-09-01T15:05:15  *** dcousens has quit IRC
2792016-09-01T15:06:50  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2802016-09-01T15:11:49  *** BashCo has quit IRC
2812016-09-01T15:16:52  *** slackircbridge has joined #bitcoin-core-dev
2822016-09-01T15:17:16  *** Cheeseo has quit IRC
2832016-09-01T15:17:38  *** Cheeseo has joined #bitcoin-core-dev
2842016-09-01T15:17:38  *** Cheeseo has joined #bitcoin-core-dev
2852016-09-01T15:53:19  *** BashCo has joined #bitcoin-core-dev
2862016-09-01T16:01:49  *** goregrin1 has quit IRC
2872016-09-01T16:07:47  *** goregrind has joined #bitcoin-core-dev
2882016-09-01T16:17:50  *** achow101 has quit IRC
2892016-09-01T16:21:56  *** achow101 has joined #bitcoin-core-dev
2902016-09-01T16:22:16  *** laurentmt has quit IRC
2912016-09-01T16:34:18  *** Cheeseo has quit IRC
2922016-09-01T16:38:21  *** HoloIRCUser13 has joined #bitcoin-core-dev
2932016-09-01T16:40:17  *** HoloIRCUser13 is now known as yep555
2942016-09-01T16:43:02  *** Cheeseo has joined #bitcoin-core-dev
2952016-09-01T16:43:02  *** Cheeseo has joined #bitcoin-core-dev
2962016-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
2972016-09-01T17:01:18  *** gabridome has joined #bitcoin-core-dev
2982016-09-01T17:02:38  <jtimon> mhmm, no, just randomly it seems, nothing to see here, sorry
2992016-09-01T17:04:48  *** gabridome has quit IRC
3002016-09-01T17:07:55  *** Yv7trNY has joined #bitcoin-core-dev
3012016-09-01T17:13:11  <wumpus> jtimon: travis is a tad flakey at the moment
3022016-09-01T17:15:04  <jtimon> I see
3032016-09-01T17:16:39  *** kyletorpey has joined #bitcoin-core-dev
3042016-09-01T17:18:36  *** Yv7trNY has quit IRC
3052016-09-01T17:26:26  *** niska has quit IRC
3062016-09-01T17:37:02  *** assder has quit IRC
3072016-09-01T17:47:12  *** spudowiar has joined #bitcoin-core-dev
3082016-09-01T17:48:48  <jeremyrubin> Yeah my lockfree checkqueue work should be passing all tests now; but has failures due to flaky pulltester :/
3092016-09-01T17:51:26  <jeremyrubin> Ah
3102016-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
3112016-09-01T17:58:35  *** niska has joined #bitcoin-core-dev
3122016-09-01T17:58:43  *** BashCo has quit IRC
3132016-09-01T17:58:59  *** pmienk has quit IRC
3142016-09-01T18:03:24  *** BashCo has joined #bitcoin-core-dev
3152016-09-01T18:06:00  *** laurentmt has joined #bitcoin-core-dev
3162016-09-01T18:12:34  *** pmienk has joined #bitcoin-core-dev
3172016-09-01T18:25:10  *** spudowiar has quit IRC
3182016-09-01T18:44:57  *** yep555 has quit IRC
3192016-09-01T18:50:44  *** jcorgan has joined #bitcoin-core-dev
3202016-09-01T18:53:34  *** w00t88 has joined #bitcoin-core-dev
3212016-09-01T18:54:03  *** ybit_ has quit IRC
3222016-09-01T18:54:15  *** ybit has joined #bitcoin-core-dev
3232016-09-01T18:55:21  *** laurentmt has quit IRC
3242016-09-01T18:59:21  <wumpus> meeting time?
3252016-09-01T18:59:29  <helo> <3
3262016-09-01T18:59:35  <jonasschnelli> yes
3272016-09-01T18:59:37  <luke-jr> big storm here, I may lose power
3282016-09-01T19:00:09  <paveljanik> Hi
3292016-09-01T19:00:13  <sipa> ohai
3302016-09-01T19:00:21  <achow101> hi
3312016-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
3322016-09-01T19:00:30  <kanzure> greetz.
3332016-09-01T19:00:30  *** grubles_ has joined #bitcoin-core-dev
3342016-09-01T19:00:33  <sdaftuar> hi
3352016-09-01T19:00:39  <cfields> here
3362016-09-01T19:00:42  <gmaxwell> luke-jr: I miss thunderstorms.
3372016-09-01T19:00:43  *** gabridome has joined #bitcoin-core-dev
3382016-09-01T19:01:02  <btcdrak> here
3392016-09-01T19:01:41  <sipa>  there
3402016-09-01T19:01:57  <wumpus> #startmeeting
3412016-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.
3422016-09-01T19:01:57  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3432016-09-01T19:02:21  <wumpus> proposed topics?
3442016-09-01T19:02:47  <sipa> remaining 0.13.1 issues
3452016-09-01T19:02:48  <jtimon> hi
3462016-09-01T19:03:00  <instagibbs> present
3472016-09-01T19:03:03  <wumpus> there are lots of 0.13.1-tagged pull requests open, any that should be prioritized for review?
3482016-09-01T19:03:04  <jeremyrubin> present
3492016-09-01T19:03:16  <sipa> wumpus: in fact, some conflict
3502016-09-01T19:03:19  <wumpus> (e.g. what should go in first)
3512016-09-01T19:03:24  <wumpus> yes, I thought so
3522016-09-01T19:03:26  <jonasschnelli> https://github.com/bitcoin/bitcoin/milestones/0.13.1
3532016-09-01T19:03:56  <wumpus> #link https://github.com/bitcoin/bitcoin/milestones/0.13.1
3542016-09-01T19:04:04  *** grubles has quit IRC
3552016-09-01T19:04:04  <sipa> 8393 (segwit + compact blocks) is a big blocker
3562016-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)
3572016-09-01T19:04:09  <wumpus> #topic remaining 0.13.1 issues
3582016-09-01T19:04:32  <jeremyrubin> (also can't stick around meeting past 12:15 FYI)
3592016-09-01T19:04:38  <sipa> beyond that, we still need to choose a solution to the mempool dos issue around segwit
3602016-09-01T19:04:51  <instagibbs> yes cb and then dos issues are probably 2 biggest?
3612016-09-01T19:04:58  <sipa> this has been brought uo several times the past few meetings
3622016-09-01T19:05:10  *** grubles_ is now known as grubles
3632016-09-01T19:05:10  <wumpus> #action #8393 (segwit + compact blocks) is a blocker, needs review testing and be merged
3642016-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
3652016-09-01T19:05:35  <sipa> sdaftuar: matt had more comments on the bip, but just on wording, not on semantics
3662016-09-01T19:05:40  <jtimon> sorry what was cb ?
3672016-09-01T19:05:45  <instagibbs> compact blocks
3682016-09-01T19:05:46  <sipa> compact blocks
3692016-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
3702016-09-01T19:05:50  <jtimon> compact blocks
3712016-09-01T19:05:54  <jtimon> sorry
3722016-09-01T19:05:56  <sdaftuar> sipa: ok, i intend to review/test 8393 soon
3732016-09-01T19:06:00  <sipa> thank you
3742016-09-01T19:06:05  <sipa> beyond that, the dos issue
3752016-09-01T19:06:24  <sipa> i'm not confortable with the previous suggestion of fully validating everything
3762016-09-01T19:06:35  <sipa> as a change for a minor point release
3772016-09-01T19:06:45  <jeremyrubin> wumpus: I'll try to swing back in the last few minutes of the meeting if possible?
3782016-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
3792016-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?
3802016-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
3812016-09-01T19:07:54  <jonasschnelli> shouldn't we tag https://github.com/bitcoin/bitcoin/issues/8279 for 0.13.1?
3822016-09-01T19:08:14  <sipa> sdaftuar: yes, there have been other suggestions in other talks to
3832016-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?
3842016-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
3852016-09-01T19:10:03  <sdaftuar> (and i don't think anyone has started work on it)
3862016-09-01T19:10:07  <sipa> yes, that's a bigger change, and there are complications
3872016-09-01T19:10:13  <sipa> like duplicating several indexes
3882016-09-01T19:10:30  <sipa> and always risking downloading twice, because old nodes may announce using the txid
3892016-09-01T19:10:50  <sipa> twice is better than $CONNECTIONS times, but still
3902016-09-01T19:11:04  <luke-jr> old nodes won't relay witness transactions at all.. (or if they do, they'll be incomplete)
3912016-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.
3922016-09-01T19:11:42  <sipa> i very much like the idea of mandatory feefilter
3932016-09-01T19:11:47  <CodeShark> me too
3942016-09-01T19:11:57  <sipa> moving the responsibiloty of resource cost to the sender
3952016-09-01T19:12:19  <jtimon> can someone summarize the idea?
3962016-09-01T19:12:19  <CodeShark> it's the least hackish approach
3972016-09-01T19:12:20  <sdaftuar> would we get rid of free tx relay at the same time, or not necessarily?
3982016-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.
3992016-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
4002016-09-01T19:12:50  <BlueMatt> sdaftuar: would be nice to get rid of that code
4012016-09-01T19:13:01  <sdaftuar> BlueMatt: i don't object in theory, but it's a sudden change for a point release
4022016-09-01T19:13:03  <gmaxwell> s/thing/think/
4032016-09-01T19:13:08  <CodeShark> what sort of heuristics?
4042016-09-01T19:13:09  <sipa> sdaftuar: agree
4052016-09-01T19:13:10  <BlueMatt> sdaftuar: sure, i wouldnt recommend it for that
4062016-09-01T19:13:16  <jtimon> just stop allowing free transactions?
4072016-09-01T19:13:24  <gmaxwell> sdaftuar: in practice it's not enabled in any case.
4082016-09-01T19:13:28  <jtimon> s/allowing/relaying/
4092016-09-01T19:13:30  <BlueMatt> jtimon: we effectively already do...
4102016-09-01T19:13:35  <instagibbs> jtimon, it's about particular feerate, not just free
4112016-09-01T19:13:37  <sipa> CodeShark: check whether the witness program's embedded scriot hash matches the hash of the witness script, for example
4122016-09-01T19:13:39  <gmaxwell> jtimon: they're already not relayed on nodes that are up for more than a few hours.
4132016-09-01T19:13:48  <sdaftuar> jtimon: because mempools are full
4142016-09-01T19:13:55  <jtimon> so what's the mandatory feefilter changing?
4152016-09-01T19:13:57  <instagibbs> sipa, yes that would be an easy fix, early on
4162016-09-01T19:14:07  <sipa> instagibbs: there is a PR for this
4172016-09-01T19:14:19  <gmaxwell>   "mempoolminfee": 0.00001812
4182016-09-01T19:14:19  <instagibbs> is that jls? I can't remember
4192016-09-01T19:14:24  <jtimon> if it's too long to summarize that's fine
4202016-09-01T19:14:40  <sipa> instagibbs: yes, on a phonr, i can't seatch the pr number
4212016-09-01T19:14:49  <instagibbs> #8593
4222016-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
4232016-09-01T19:15:02  <sdaftuar> so mandatory fee filter would only apply to witness transactions?
4242016-09-01T19:15:11  <sdaftuar> er, NODE_WITNESS peers?
4252016-09-01T19:15:18  <sipa> sdaftuar: that's a possibility
4262016-09-01T19:15:23  <instagibbs> he moves full input validation up front in #8539
4272016-09-01T19:15:30  <sdaftuar> it doesn't make sense otherwise, we can't stop relaying transactions from older clients right
4282016-09-01T19:15:33  <sipa> instagibbs: oh, no, not that one
4292016-09-01T19:15:43  <instagibbs> would be abusive to disconnect older nodes imo
4302016-09-01T19:15:52  <gmaxwell> sdaftuar: It has to be negoiated somehow, node witness would be one way.. though a bit disruptive on testnet.
4312016-09-01T19:16:03  <gmaxwell> instagibbs: no one is going to do that.
4322016-09-01T19:16:04  <sipa> instagibbs: full validation has some kinks to work out; something for 0.14 imho
4332016-09-01T19:16:11  <luke-jr> mandatory feefilter seems liable to cause issues with 1) diverging fee policies; 2) ancestor feerate (CPFP) relay stuff
4342016-09-01T19:16:14  <jtimon> sipa: I see, thanks, like an additional filter per peer
4352016-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
4362016-09-01T19:16:30  *** thestringpuller has joined #bitcoin-core-dev
4372016-09-01T19:16:31  <instagibbs> sipa, I don't see the PR you are talking about then
4382016-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?
4392016-09-01T19:17:24  <jonasschnelli> instagibbs: i think there is no PR right now for that proposal
4402016-09-01T19:17:30  <gmaxwell> sdaftuar: that would be fine too.
4412016-09-01T19:17:37  <petertodd> sdaftuar: yes
4422016-09-01T19:17:38  <sipa> instagibbs: 8499
4432016-09-01T19:17:47  <sipa> yes there is
4442016-09-01T19:17:49  <instagibbs> oh that one
4452016-09-01T19:18:02  <jonasschnelli> Indeed: https://github.com/bitcoin/bitcoin/pull/8499/files
4462016-09-01T19:18:20  <sipa> so, i would like to request review on 8499 and 8525
4472016-09-01T19:18:34  <sipa> neither of those is a policy change
4482016-09-01T19:18:35  <instagibbs> wumpus, can you tag that PR please #8499
4492016-09-01T19:18:47  <sdaftuar> sipa: will do
4502016-09-01T19:19:07  <wumpus> sure
4512016-09-01T19:19:15  <instagibbs> I will review 8499
4522016-09-01T19:19:38  <sipa> and untag 8593
4532016-09-01T19:20:15  <wumpus> done
4542016-09-01T19:20:38  <sipa> so the only remaining thing is enforcing feefilter stronger as sdaftuar suggests only for witness peers
4552016-09-01T19:20:53  <BlueMatt> I'd ACK that
4562016-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.
4572016-09-01T19:20:57  <sipa> does that sound reasonable for 0.13.1?
4582016-09-01T19:21:07  <gmaxwell> FWIW, mandatory fee filter would couple well with 8525, rejection cache mostly exists due to a lack of feefilter.
4592016-09-01T19:21:22  <sipa> besides fixing known bugs, obviously
4602016-09-01T19:21:24  <petertodd> gmaxwell: yup
4612016-09-01T19:21:29  <sdaftuar> sipa: yes
4622016-09-01T19:21:36  <petertodd> sipa: sure
4632016-09-01T19:21:45  <sipa> great
4642016-09-01T19:21:55  <sdaftuar> you started a PR that did that, yes?
4652016-09-01T19:22:05  <sipa> sdaftuar: not yet, i will
4662016-09-01T19:22:12  <sdaftuar> ok
4672016-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.
4682016-09-01T19:22:29  <instagibbs> gmaxwell, ack
4692016-09-01T19:22:34  <sdaftuar> sounds reasonable
4702016-09-01T19:22:51  <sipa> ack on backporting feelers
4712016-09-01T19:22:59  <sdaftuar> curious to know if anyone has experimented with that on testnet and has any results?
4722016-09-01T19:23:17  <sipa> i think it will take a while for network wide effects of feelers to become visible
4732016-09-01T19:23:41  <sdaftuar> oh maybe i misunderstood, i thought your own node would benefit from that by itself?
4742016-09-01T19:23:43  <sipa> and testnet is not particularly in a sane p2p state
4752016-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?
4762016-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.
4772016-09-01T19:24:01  <sipa> right, but indirectly the results of addr messages will get better too from feelers
4782016-09-01T19:24:12  <sipa> if the overall quality of addrmans improves
4792016-09-01T19:24:13  <sdaftuar> sipa: ah, yes
4802016-09-01T19:24:14  <gmaxwell> CodeShark: the filters are one way.  "Here is what you can send me"
4812016-09-01T19:24:21  <instagibbs> https://github.com/bitcoin/bitcoin/pull/8282
4822016-09-01T19:25:00  <CodeShark> gmaxwell: sure...but your peers would filter stuff you wanted to see
4832016-09-01T19:25:10  <sipa> next topic?
4842016-09-01T19:25:12  <gmaxwell> CodeShark: has nothing to do with fee filter.
4852016-09-01T19:25:14  <sipa> i'm in a mildly unconfortable position here (irl meetup in milan, where BlueMatt spoke)
4862016-09-01T19:25:21  <gmaxwell> CodeShark: peers already filter anything they won't relay.
4872016-09-01T19:26:04  <BlueMatt> sipa: you can irc from my laptop if you prefer
4882016-09-01T19:26:06  <jtimon> its kind of "please, don't bother sending me things below X or I'll disconnect from you"
4892016-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)
4902016-09-01T19:27:39  *** cdecker has quit IRC
4912016-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
4922016-09-01T19:27:58  <petertodd> luke-jr: how?
4932016-09-01T19:28:08  <jtimon> luke-jr: I'm not following, how does the peer know your rate X
4942016-09-01T19:28:10  <jtimon> ?
4952016-09-01T19:28:43  <luke-jr> petertodd: if you change your fee policy code, you could be partitioned off from the other peers, no?
4962016-09-01T19:28:46  *** cdecker has joined #bitcoin-core-dev
4972016-09-01T19:28:48  <sdaftuar> luke-jr: no
4982016-09-01T19:28:49  <instagibbs> suggested topic: "Extra" softforks low_s and nulldummy
4992016-09-01T19:28:59  <luke-jr> what am I missing?
5002016-09-01T19:29:06  <sdaftuar> only if you lie about it to your peers
5012016-09-01T19:29:14  <sipa> instagibbs: ack topic
5022016-09-01T19:29:26  <jtimon> I believe low_s was discussed already?
5032016-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)
5042016-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.
5052016-09-01T19:29:42  <sipa> i believe it needs rediscussing (low_s)
5062016-09-01T19:29:46  <jtimon> BlueMatt: good point
5072016-09-01T19:29:47  <instagibbs> BlueMatt, that's a good point
5082016-09-01T19:29:48  <sdaftuar> BlueMatt: we do, but worht looking at again
5092016-09-01T19:29:49  <gmaxwell> BlueMatt: we do.
5102016-09-01T19:30:08  <BlueMatt> ok, nvm, ignore my ramblings
5112016-09-01T19:30:43  <jtimon> BlueMatt: please keep rumbling out loud, I hadn't even thought about it, now seems obvious
5122016-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)
5132016-09-01T19:30:56  <sipa> (can we move on to next topic?)
5142016-09-01T19:31:01  <gmaxwell> jtimon: it was specfically addressed in the original feefilter PR.
5152016-09-01T19:31:01  <BlueMatt> gmaxwell: indeed, shame we dont
5162016-09-01T19:31:04  <jtimon> ack next topic
5172016-09-01T19:31:04  <BlueMatt> also, what sipa said
5182016-09-01T19:31:17  <sipa> wumpus: ring topic bell? :)
5192016-09-01T19:31:25  <gmaxwell> we put wumpus to sleep.
5202016-09-01T19:31:41  <paveljanik> ;-)
5212016-09-01T19:31:48  <petertodd> gmaxwell: ring wumpus bell?
5222016-09-01T19:31:48  * sdaftuar rings the wumpus bell
5232016-09-01T19:31:51  <sipa> ok, i'll go on anyway
5242016-09-01T19:32:02  <paveljanik> I think that wumpus never sleeps
5252016-09-01T19:32:03  <jtimon> go sipa go
5262016-09-01T19:32:07  <sipa> so, the nulldummy and low_s softfork proposals
5272016-09-01T19:32:30  <btcdrak> #topic nulldummy and low_s softfork proposals
5282016-09-01T19:32:36  <wumpus> #topic nulldummy and low_s softfork proposals
5292016-09-01T19:32:39  <sipa> it was discovered by jl that low_ has a really strange implementation issue leaked into the semantics
5302016-09-01T19:32:44  <jtimon> I don't remember any objections on low_s last time we discussed it?
5312016-09-01T19:32:56  <sipa> which is not an issue for standardness, but for consensus i think we prefer clean sema tics
5322016-09-01T19:33:01  <instagibbs> jtimon, https://github.com/bitcoin/bitcoin/pull/8533#issuecomment-243973512
5332016-09-01T19:33:17  <gmaxwell> sipa: are clean semantics even possible?
5342016-09-01T19:33:25  <jtimon> instagibbs: thanks
5352016-09-01T19:33:38  <sipa> gmaxwell: yes, if we also do the only-empty-signature-in-invalid-checksig sf
5362016-09-01T19:33:53  <gmaxwell> sipa: oh indeed okay, yes that would be clean
5372016-09-01T19:33:58  <sipa> which is why i'd propose that we do low_s later, together with that empty sigs rule
5382016-09-01T19:34:07  <sipa> and only bundle nulldummy with 0.13.1
5392016-09-01T19:34:19  <sipa> s/0.13.1/segwit/
5402016-09-01T19:34:23  <gmaxwell> The clenlyness issue is that lowS test fails for some encodings of invalid encodings.
5412016-09-01T19:34:37  <gmaxwell> er encodings of invalid signatures.
5422016-09-01T19:34:44  <sipa> yes, some illegal signatures are exempt from low_s
5432016-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?
5442016-09-01T19:34:59  <BlueMatt> that are non-0-length, at least
5452016-09-01T19:35:04  <sipa> such signatures are NOT valid
5462016-09-01T19:35:15  <BlueMatt> but can bt OP_NOT'd, no?
5472016-09-01T19:35:23  <sipa> yes, but nobody sane does that
5482016-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.
5492016-09-01T19:35:32  <BlueMatt> sure, but /has/ anyone ever done so?
5502016-09-01T19:35:39  <sipa> "yes, this output can be spent UNLESS BlueMatt likes it"
5512016-09-01T19:35:46  <jtimon> no objections on delaying low_s enforcement
5522016-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.
5532016-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
5542016-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
5552016-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
5562016-09-01T19:36:40  <sipa> i think we should aboid that
5572016-09-01T19:36:43  <BlueMatt> (wait, it is non-stad to do non-0-length, correct?)
5582016-09-01T19:36:46  <gmaxwell> BlueMatt: a checksig not has been done at least once in the chain history.
5592016-09-01T19:36:53  <jtimon> BlueMatt: good question, petertodd has anybody done that? :p
5602016-09-01T19:36:57  <gmaxwell> By someone triggering a fork off of bitcoin ruby.
5612016-09-01T19:37:03  <sipa> petertodd: have you done that?
5622016-09-01T19:37:11  <BlueMatt> gmaxwell: sure, but with 0-length, or with a non-emtpy sig
5632016-09-01T19:37:20  <gmaxwell> yea, don't recall, we could check.
5642016-09-01T19:37:35  <petertodd> sipa: me personally, probably not - I'm a fine arts grad :P
5652016-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?
5662016-09-01T19:37:46  <BlueMatt> (this would be immaterial if it is not already nonstd...which I do not recall)
5672016-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
5682016-09-01T19:38:26  <BlueMatt> I was informed that non-0-length invalid sigs is not nonstd
5692016-09-01T19:38:30  <BlueMatt> I would propose we do so in 0.13.1
5702016-09-01T19:38:45  <gmaxwell> It is non-standard for segwit. (unless I am on drugs.)
5712016-09-01T19:38:55  <sipa> gmaxwell: you're on drugs
5722016-09-01T19:38:57  <gmaxwell> I am on drugs then. Okay. Good to know.
5732016-09-01T19:38:59  <jtimon> are we still talking low_S ?
5742016-09-01T19:39:02  <sipa> yes
5752016-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
5762016-09-01T19:39:08  <gmaxwell> wlel thats insane, we should fix that at least.
5772016-09-01T19:39:14  <BlueMatt> gmaxwell: ack
5782016-09-01T19:39:21  <gmaxwell> yes, it needs to be non-standard first. pronto.
5792016-09-01T19:39:24  <BlueMatt> 0.13.1 should make invalid sigs which are non-0-length nonstd
5802016-09-01T19:39:25  <sipa> agree
5812016-09-01T19:39:29  <sdaftuar> agree
5822016-09-01T19:39:35  <wumpus> yes, absolutely
5832016-09-01T19:39:42  <CodeShark> +1
5842016-09-01T19:39:51  <sipa> great
5852016-09-01T19:40:02  <jtimon> this needs a bip, no?
5862016-09-01T19:40:12  *** jcorgan has quit IRC
5872016-09-01T19:40:16  <sipa> jtimon: yes, but we just suggest it as nonstd now
5882016-09-01T19:40:22  <jtimon> sure
5892016-09-01T19:40:25  <sipa> (which certainly needs ML discussion too)
5902016-09-01T19:40:31  <gmaxwell> there is copy for null dummy as part of the old malleability bip, no?
5912016-09-01T19:40:51  <gmaxwell> nulldummy and fixed invalid?
5922016-09-01T19:40:54  <sipa> null dummy is about the ignored arg for CMS
5932016-09-01T19:41:02  <gmaxwell> thus my follow up.
5942016-09-01T19:41:12  <sipa> empty invalid was not part of bip62
5952016-09-01T19:41:19  <gmaxwell> okay.
5962016-09-01T19:41:41  <sipa> because it wasn't needed fir standard txn at the time
5972016-09-01T19:41:54  <sipa> ok, next topic?
5982016-09-01T19:42:00  <kanzure> jeremyrubin's stuff see above
5992016-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)
6002016-09-01T19:42:23  <gmaxwell> jeremyrubin is busy making validation great again. I'm super excited about this.
6012016-09-01T19:42:29  <sdaftuar> sorry before we move topics -- we should repropose NULLDUMMY by itself on the mailing list, yes?
6022016-09-01T19:42:37  <wumpus> if he's here, at least
6032016-09-01T19:42:37  <sipa> sdaftuar: ack
6042016-09-01T19:42:58  <BlueMatt> gmaxwell: ACK
6052016-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)
6062016-09-01T19:43:03  <instagibbs> link to jeremyrubin's stuff?
6072016-09-01T19:43:25  <sipa> petertodd: that would be a side effect of switching to wtzid based indexing, actually
6082016-09-01T19:43:30  <sdaftuar> https://github.com/bitcoin/bitcoin/pull/8464
6092016-09-01T19:43:31  <kanzure> instagibbs: https://github.com/bitcoin/bitcoin/pull/8464
6102016-09-01T19:44:08  <jonasschnelli> It's a very invasive change...
6112016-09-01T19:44:18  <jonasschnelli> though, I like the concept
6122016-09-01T19:44:18  <BlueMatt> jonasschnelli: its worth it, by a lot
6132016-09-01T19:44:27  <btcdrak> sdaftuar there is a NULLDUMMY only PR as well https://github.com/bitcoin/bitcoin/pull/8636
6142016-09-01T19:44:28  <petertodd> sipa: not quite - I'm proposing we re-broadcast such replacements to our peers
6152016-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%)
6162016-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
6172016-09-01T19:45:31  <sdaftuar> petertodd: you're suggesting different replacement semantics than we have under BIP 125?
6182016-09-01T19:45:31  <sipa> ah, i see
6192016-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
6202016-09-01T19:47:07  <petertodd> sdaftuar: mainly proposing this as a belt and suspenders to limit the damage of malleability attacks
6212016-09-01T19:47:13  <gmaxwell> petertodd: may just be better for mempool reconcillation to handle that.
6222016-09-01T19:47:27  <petertodd> gmaxwell: sure - when's that coming? :)
6232016-09-01T19:47:54  <gmaxwell> petertodd: interested in helping define it? :P
6242016-09-01T19:48:06  *** Cory has quit IRC
6252016-09-01T19:48:08  <sipa> i believe we're drifting off topic
6262016-09-01T19:48:17  <gmaxwell> Who was phone?
6272016-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
6282016-09-01T19:48:36  <gmaxwell> fair
6292016-09-01T19:49:01  <sipa> other topics?
6302016-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.
6312016-09-01T19:49:27  <wumpus> yes, any other topic proposals?
6322016-09-01T19:49:32  <gmaxwell> s/mempool batching/relay batching/
6332016-09-01T19:49:44  <petertodd> gmaxwell: oh, batching? I'm unfamilar with that idea
6342016-09-01T19:50:02  <BlueMatt> 10 min bell
6352016-09-01T19:50:04  <gmaxwell> petertodd: relay behavior changed in 0.13, I think you're aware.
6362016-09-01T19:50:13  <gmaxwell> petertodd: will talk after meeting.
6372016-09-01T19:50:16  <petertodd> gmaxwell: ack
6382016-09-01T19:50:42  <sdaftuar> quick travis discussion?
6392016-09-01T19:50:47  <wumpus> seems that there are no other meeting topics proposals, so we can close
6402016-09-01T19:51:06  <wumpus> sure
6412016-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
6422016-09-01T19:51:09  <gmaxwell> Non-discussion: 0.13 deployment seems to be trouble free <knock on wood>, congrats everyone.
6432016-09-01T19:51:10  <wumpus> #topic travis discussion
6442016-09-01T19:51:14  <sdaftuar> i've been away for the last couple weeks, can anyone summarize the state of our testsuite these days?
6452016-09-01T19:51:19  <jeremyrubin> Yes
6462016-09-01T19:51:24  <sdaftuar> i feel like i've seen lots of people complaining
6472016-09-01T19:51:32  <wumpus> yes, congrats everyone on the 0.13.0 release
6482016-09-01T19:51:34  <jeremyrubin> Basically theres some failing rpctests
6492016-09-01T19:51:40  <sdaftuar> and my own local runs are failing a lot too, but i havent figured out why yet
6502016-09-01T19:51:45  <jeremyrubin> and the make check code is slow
6512016-09-01T19:51:45  <gmaxwell> what is this backupwallet test thing that keeps failing?
6522016-09-01T19:51:48  <wumpus> there are randomly failing RPC tests, and also some random timeouts
6532016-09-01T19:51:51  <cfields> yes, there are a few racy conditions
6542016-09-01T19:51:56  <sipa> segwit.py also fails sometimes
6552016-09-01T19:52:09  <jeremyrubin> I've also seen an abandonconflict failure once
6562016-09-01T19:52:30  <cfields> i believe i tracked down the segwit issue, which may be the root cause of some other issues
6572016-09-01T19:52:36  <sdaftuar> oh!  good to know
6582016-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.
6592016-09-01T19:52:41  <sipa> cfields: elobarate?
6602016-09-01T19:52:43  <cfields> (if that's the same as the one that was worsened by the timing change)
6612016-09-01T19:53:12  <cfields> sipa: need to check if it's the same thing and gather my notes, take it up after meeting?
6622016-09-01T19:53:13  <jonasschnelli> can we not just move the segwith test to the end/last item?
6632016-09-01T19:53:20  <sipa> cfields: ok
6642016-09-01T19:53:26  <sdaftuar> sounds good
6652016-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)
6662016-09-01T19:53:29  <jonasschnelli> s/segwith/segwit
6672016-09-01T19:53:37  <wumpus> the thing is, the tests never fail locally at least here
6682016-09-01T19:53:52  <wumpus> so yes I also suspect the travis infrastructure for some failiures
6692016-09-01T19:54:09  <jeremyrubin> There's also an open issue with travis race conditions internally
6702016-09-01T19:54:10  <wumpus> anyhow the issue is https://github.com/bitcoin/bitcoin/issues/8532
6712016-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
6722016-09-01T19:54:13  <sipa> sdaftuar says he sometimes sees the failures locally?
6732016-09-01T19:54:25  <sdaftuar> sipa: yes, with an error condition i don't understand at all, let me find it
6742016-09-01T19:54:26  <jeremyrubin> e.g. if you push a commit before the last push finished testing
6752016-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.
6762016-09-01T19:55:03  <wumpus> so we need a better sync call
6772016-09-01T19:55:15  <sipa> cfields: so switch to a while loop until balances are an equal/expected value, with a certain timeout?
6782016-09-01T19:55:17  <wumpus> a kind of fence
6792016-09-01T19:55:46  <wumpus> sipa: that would imply updating all the balance checks to loops
6802016-09-01T19:55:53  <gmaxwell> run a ping and check the ping time on all the node.s
6812016-09-01T19:56:09  <jonasschnelli> gmaxwell: from the RPC API?
6822016-09-01T19:56:22  <sipa> getpeerinfo, i oresume
6832016-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
6842016-09-01T19:56:41  <sipa> i hope cfields isn't changing that barrier effect
6852016-09-01T19:56:45  <BlueMatt> gmaxwell: iirc breaking that breaks things
6862016-09-01T19:56:46  <wumpus> yes, ping will work for that, but it's unclear how to use that in RPC tests
6872016-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
6882016-09-01T19:56:56  <gmaxwell> we had that discussion with cfields before, which is why I mention it. :P
6892016-09-01T19:56:58  <cfields> i suppose that just introduces its own issues, though
6902016-09-01T19:57:03  <cfields> heh
6912016-09-01T19:57:14  <wumpus> no, the barrier effect certainly shouldn't be removed, unless a better mechanism is introduced
6922016-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)
6932016-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)
6942016-09-01T19:57:40  <wumpus> and that's a huge protocol change, so probably not worth it right now
6952016-09-01T19:57:55  <sipa> yes, that's out of scope
6962016-09-01T19:57:58  <gmaxwell> sorry, I started a tangent.
6972016-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
6982016-09-01T19:58:08  <sipa> for a "get the damn unit tests to work again", at least
6992016-09-01T19:58:10  <gmaxwell> in any case, maybe ping can be used to sync for these tests.
7002016-09-01T19:58:14  <BlueMatt> 2 min bell
7012016-09-01T19:58:30  <wumpus> sleeps are pretty terrible, it's easy to get those wrong and travis has a very unpredictable load pattern
7022016-09-01T19:58:32  <gmaxwell> sleeps for now sound fine to me. We could all use more sleep.
7032016-09-01T19:58:37  <wumpus> hah
7042016-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
7052016-09-01T19:58:53  <jonasschnelli> sleeps will just kick the problem a bit further down...
7062016-09-01T19:58:55  <BlueMatt> cfields: if we commit to reverting it within X days, ACK
7072016-09-01T19:58:55  <wumpus> but indeed this started when the timeouts were lowered all over the place
7082016-09-01T19:58:58  <gmaxwell> tests randomly faily though is ... not good.
7092016-09-01T19:59:07  <jtimon> cfields: go with the sleeps, better solutions later
7102016-09-01T19:59:08  <gmaxwell> jonasschnelli: I'm not suggesting delting fixing things at all.
7112016-09-01T19:59:08  <jonasschnelli> and a sleep in sync_all will have a performance impact on the test-duration-tim
7122016-09-01T19:59:28  <jonasschnelli> though, ack on the sleep for now
7132016-09-01T19:59:36  <sipa> sgtm
7142016-09-01T19:59:38  <wumpus> right
7152016-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
7162016-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.
7172016-09-01T19:59:49  <BlueMatt> ACK
7182016-09-01T19:59:55  <sdaftuar> gmaxwell: yep
7192016-09-01T20:00:03  <BlueMatt> ACK to gmaxwell and cfields
7202016-09-01T20:00:08  <BlueMatt> also, dingdingding
7212016-09-01T20:00:09  <sipa> POING
7222016-09-01T20:00:10  <wumpus> #endmeeting
7232016-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)
7242016-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
7252016-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
7262016-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
7272016-09-01T20:00:25  <wumpus> gmaxwell: yes it's not a good thing that travis failures are a normal thing now
7282016-09-01T20:00:37  <wumpus> I tend to rely on local tests more and more
7292016-09-01T20:00:59  <wumpus> if that continues, travis just becomes a distraction
7302016-09-01T20:01:05  <sipa> ;;tslb
7312016-09-01T20:01:07  <gribble> Time since last block: 31 minutes and 15 seconds
7322016-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
7332016-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
7342016-09-01T20:01:55  <wumpus> let's try to solve it properly
7352016-09-01T20:02:11  <petertodd> gmaxwell: I'm aware that we changed relay behavior; forget the exact details there
7362016-09-01T20:02:41  <cfields> wumpus: sure, that wasn't a real suggestion
7372016-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
7382016-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)
7392016-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.
7402016-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
7412016-09-01T20:04:00  <jeremyrubin> (that would at least help us catalouge a definitely non-deterministic failure)
7422016-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. :)
7432016-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
7442016-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
7452016-09-01T20:04:31  *** xiangfu has quit IRC
7462016-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
7472016-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
7482016-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.
7492016-09-01T20:05:11  <cfields> wumpus: so maybe not wait-for-completion, but wait-for-a-while?
7502016-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
7512016-09-01T20:05:33  <gmaxwell> petertodd: and for CB we should have a rejection/eviction cache.
7522016-09-01T20:05:39  <cfields> wumpus: fair point
7532016-09-01T20:05:51  <petertodd> gmaxwell: CB? compact blocks?
7542016-09-01T20:05:53  <sdaftuar> gmaxwell: why do we need an eviction cache, if we're using feefilter?
7552016-09-01T20:05:54  <gmaxwell> jeremyrubin: okay, potentially useful. Though the time is a concern.
7562016-09-01T20:05:55  *** xiangfu has joined #bitcoin-core-dev
7572016-09-01T20:05:59  <sdaftuar> oh
7582016-09-01T20:06:01  <sdaftuar> i misunderstood
7592016-09-01T20:06:25  <jeremyrubin> gmaxwell: can have further runs only happen if the last one fails
7602016-09-01T20:06:28  *** w00t88 has quit IRC
7612016-09-01T20:06:44  <jeremyrubin> gmaxwell: (up to a bound)
7622016-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
7632016-09-01T20:06:46  <gmaxwell> jeremyrubin: too bad there is probably no way to report the failure right away and keep running. :P
7642016-09-01T20:06:54  <petertodd> gmaxwell: this could solve this SIGHASH_ANYONECANPAY issue w/o having to put in specific support for SIGHASH_ANYONECANPAY
7652016-09-01T20:06:57  * jeremyrubin shakes fist at travis
7662016-09-01T20:07:47  <wumpus> cfields: what about a 'wait for a change in either height or hash'?
7672016-09-01T20:07:56  <wumpus> cfields: the client can then check the details
7682016-09-01T20:08:02  <jeremyrubin> gmaxwell: after_failure hook? Not sure when those get run w.r.t. ui updates :)
7692016-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
7702016-09-01T20:08:29  <jeremyrubin> cfields: fair.
7712016-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.
7722016-09-01T20:08:53  <cfields> wumpus: makes sense. and in that case, we block until everything is done processing rather than asap
7732016-09-01T20:08:56  <jeremyrubin> cfields: proposal: failed test gets re-run once after all tests complete?
7742016-09-01T20:08:57  <cfields> wumpus: i like that.
7752016-09-01T20:09:00  <wumpus> cfields: doesn't matter to loop a bit in the client, after all
7762016-09-01T20:09:02  <wumpus> cfields: right
7772016-09-01T20:09:14  <jtimon> gmaxwell: oh, even with the parallel rpc tests you still wait for all to fail without seeing anything...yuck
7782016-09-01T20:09:44  <petertodd> gmaxwell: makes sense to me too
7792016-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
7802016-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...
7812016-09-01T20:10:42  <cfields> wumpus: ok, that sounds simple enough. only complication would be waiting for the wallet
7822016-09-01T20:10:58  * cfields crosses his fingers that there's some signal/condvar already doing that
7832016-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.
7842016-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
7852016-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)
7862016-09-01T20:11:56  <wumpus> cfields: yes, it needs to be a wallet call
7872016-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?
7882016-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"
7892016-09-01T20:12:30  <gmaxwell> petertodd: I just mean that if the modification changes outputs, it will normally change signatures...
7902016-09-01T20:12:35  <petertodd> sdaftuar: slightly more general; I'd do it so long as the vout is the same
7912016-09-01T20:12:58  <petertodd> gmaxwell: normally :) but not always, e.g. SIGHASH_ANYONECANPAY
7922016-09-01T20:13:17  <sdaftuar> oh, so if someone adds an input, you can remove it
7932016-09-01T20:13:27  <sdaftuar> i think you guys were discussing that on some PR?
7942016-09-01T20:14:09  <petertodd> sdaftuar: yup
7952016-09-01T20:14:14  <petertodd> sdaftuar: https://github.com/bitcoin/bitcoin/pull/8543
7962016-09-01T20:14:17  <sdaftuar> thanks
7972016-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)
7982016-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.
7992016-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"
8002016-09-01T20:15:47  <gmaxwell> e.g. you wouldn't keep invalid transactions, but you would keep non-standard ones.
8012016-09-01T20:16:08  <gmaxwell> s/unlikely/unlike/
8022016-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
8032016-09-01T20:17:04  <jtimon> gmaxwell: lol, let's call it "the shockpool"
8042016-09-01T20:18:09  <jtimon> but I really don't know what criteria would I use there
8052016-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.
8062016-09-01T20:20:32  <sdaftuar> cfields: ah, good idea
8072016-09-01T20:21:25  <gmaxwell> jtimon: well obviously you just use machine learning to predict what will end up in blocks... :P
8082016-09-01T20:22:29  <petertodd> gmaxwell: better, yet, use hashing power to make your predictions come true...
8092016-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...
8102016-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.
8112016-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
8122016-09-01T20:23:21  <gmaxwell> I've suggested similar things for utxo cache management in the past.
8132016-09-01T20:24:26  <jeremyrubin> Can I ask for some thoughts on the checkqueue stuff?
8142016-09-01T20:24:56  <jtimon> gmaxwell: model? what's wrong with feeding them binary data?
8152016-09-01T20:25:13  <jtimon> </sarcasm>
8162016-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
8172016-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. :)
8182016-09-01T20:25:49  <gmaxwell> oh okay.
8192016-09-01T20:25:51  <gmaxwell> :P
8202016-09-01T20:25:59  <jeremyrubin> (also if anyone would care to try testing it out would be great help for me)
8212016-09-01T20:26:27  <jeremyrubin> (for reference, PR is here https://github.com/bitcoin/bitcoin/pull/8464)
8222016-09-01T20:29:26  <Chris_Stewart_5> jeremyrubin: Might be worth while to look at #8469 and write some properties for testing
8232016-09-01T20:30:02  <gmaxwell> jonasschnelli: thanks for that backport.
8242016-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
8252016-09-01T20:31:26  *** gabridome1 has joined #bitcoin-core-dev
8262016-09-01T20:32:38  *** cryptapus has quit IRC
8272016-09-01T20:34:09  *** gabridome has quit IRC
8282016-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
8292016-09-01T20:36:23  *** HoloIRCUser6 has joined #bitcoin-core-dev
8302016-09-01T20:36:24  *** gabridome1 has quit IRC
8312016-09-01T20:36:44  *** gabridome has joined #bitcoin-core-dev
8322016-09-01T20:37:41  *** gabridome1 has joined #bitcoin-core-dev
8332016-09-01T20:40:51  *** HoloIRCUser6 has quit IRC
8342016-09-01T20:41:01  *** gabridome has quit IRC
8352016-09-01T20:41:17  *** kadoban has joined #bitcoin-core-dev
8362016-09-01T20:42:26  *** Chris_St1 has joined #bitcoin-core-dev
8372016-09-01T20:43:13  *** Chris_Stewart_5 has quit IRC
8382016-09-01T20:49:38  <gmaxwell> PR #8212 needs backport too.
8392016-09-01T20:49:49  <gmaxwell> er I meant PR #8612.
8402016-09-01T20:51:46  *** luke-jr has quit IRC
8412016-09-01T20:51:54  *** luke-jr has joined #bitcoin-core-dev
8422016-09-01T20:52:44  <instagibbs> what's the New Improved Way(TM) to get uint256 as string
8432016-09-01T20:53:07  <instagibbs> still working my way around git blaming in reverse, failing me right now
8442016-09-01T20:54:34  <gmaxwell> instagibbs: do you mean as hex?
8452016-09-01T20:54:42  <instagibbs> yeah hex string
8462016-09-01T20:57:31  <instagibbs> oh weight, nevermind me, just in .cpp now, and complaining
8472016-09-01T20:57:36  <instagibbs> wait even
8482016-09-01T20:57:47  <instagibbs> probably just fat fingered
8492016-09-01T20:59:49  *** Eliel_ has quit IRC
8502016-09-01T21:00:19  *** HoloIRCUser has joined #bitcoin-core-dev
8512016-09-01T21:00:23  *** Eliel has joined #bitcoin-core-dev
8522016-09-01T21:06:28  *** Chris_St1 has quit IRC
8532016-09-01T21:13:47  *** grubles has quit IRC
8542016-09-01T21:14:37  <gmaxwell> interesting:
8552016-09-01T21:14:39  <gmaxwell> 2016-09-01 15:35:29.537118 replacing tx 528f6cbebe29fa6bdab3be077a48754c2371df2fbf4cbb8fbc11992fdeb26470 with
8562016-09-01T21:14:42  <gmaxwell> 922a0895c7246b46533d1d356152bde2477cc9987c96b78e02da4d5869e4b7cc for 0.00008873 BTC additional fees, -194 delta bytes
8572016-09-01T21:14:45  <gmaxwell> 2016-09-01 15:35:29.537194 replacing tx 308a560e8e90ccaf64af9f5cd3b1dcfe4bccf8d49d73b0460b95b1616bb26c9d with
8582016-09-01T21:14:48  <gmaxwell> 922a0895c7246b46533d1d356152bde2477cc9987c96b78e02da4d5869e4b7cc for 0.00008873 BTC additional fees, -194 delta bytes
8592016-09-01T21:14:51  <gmaxwell> 2016-09-01 15:35:50.780139 Successfully reconstructed block 000000000000000002f65cc5054fefb1b8fe75ebb685ac6b51f05dac0b84ee3d with 1 txn
8602016-09-01T21:14:54  <gmaxwell> prefilled, 2465 txn from mempool and 2 txn requested 2016-09-01 15:35:50.780208 Reconstructed block
8612016-09-01T21:14:57  <gmaxwell> 000000000000000002f65cc5054fefb1b8fe75ebb685ac6b51f05dac0b84ee3d required tx
8622016-09-01T21:15:00  <gmaxwell> 528f6cbebe29fa6bdab3be077a48754c2371df2fbf4cbb8fbc11992fdeb26470
8632016-09-01T21:15:03  <gmaxwell> 2016-09-01 15:35:50.780253 Reconstructed block 000000000000000002f65cc5054fefb1b8fe75ebb685ac6b51f05dac0b84ee3d required tx
8642016-09-01T21:15:06  <gmaxwell> 308a560e8e90ccaf64af9f5cd3b1dcfe4bccf8d49d73b0460b95b1616bb26c9d
8652016-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.
8662016-09-01T21:22:01  <luke-jr> gmaxwell: presumably the parent of the orphan was missing in your mempool? was that one of the conflicts?
8672016-09-01T21:23:04  <gmaxwell> those were three steperate blocks.
8682016-09-01T21:23:33  *** HoloIRCUser has quit IRC
8692016-09-01T21:23:42  <luke-jr> so what was the cause of the orphan not being in the mempool (or rejected)?
8702016-09-01T21:23:53  <gmaxwell> yea, trying to figure that out.
8712016-09-01T21:24:09  *** HoloIRCUser has joined #bitcoin-core-dev
8722016-09-01T21:24:24  <gmaxwell> maybe it actually had been evicted by the time the parent came around.
8732016-09-01T21:24:41  <gmaxwell> 2016-09-01 11:50:23.982337 stored orphan tx aeb9dac61cf2cc7fd535f2b4b685070b0dce2690c9f78d9987335cbadedf5aa3 (mapsz 101 outsz 110)
8742016-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
8752016-09-01T21:25:27  <gmaxwell> 2016-09-01 11:53:45.913505 Reconstructed block 000000000000000004e70299cd0284b177412b63144fc4b9c6080c65545e875b required tx aeb9dac61cf2cc7fd535f2b4b685070b0dce2690c9f78d9987335cbadedf5aa3
8762016-09-01T21:26:02  <luke-jr> hmm
8772016-09-01T21:26:29  <gmaxwell> looking up the parents now.
8782016-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)
8792016-09-01T21:28:32  <gmaxwell> luke-jr: wow, no way.
8802016-09-01T21:28:37  *** HoloIRCUser has quit IRC
8812016-09-01T21:29:11  *** pmienk has quit IRC
8822016-09-01T21:29:29  <luke-jr> http://0bin.net/paste/nELoeFqIuT4891qP#P8ugYLrvtlhggdD80jGS5NDOuhJYpJ37JgDgHiGF1CF
8832016-09-01T21:30:08  <gmaxwell> grep econs ~/.bitcoin/debug.log  | tail -n 100 | awk '{aa+=$16>1} END {print aa/NR}'
8842016-09-01T21:30:11  <gmaxwell> 0.11
8852016-09-01T21:30:14  <gmaxwell> 11% here.
8862016-09-01T21:30:53  *** Chris_St1 has joined #bitcoin-core-dev
8872016-09-01T21:30:59  <luke-jr> 0.661538
8882016-09-01T21:31:05  <gmaxwell> how long have you been up?
8892016-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.)
8902016-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.
8912016-09-01T21:33:11  <luke-jr> about 1.5 hours now, but quite a bit longer before that restart
8922016-09-01T21:33:27  <luke-jr> yes, that's why I said not surprising ;)
8932016-09-01T21:33:43  <gmaxwell> oh... 'spam I assume'
8942016-09-01T21:33:46  <gmaxwell> indeed. okay.
8952016-09-01T21:35:54  <luke-jr> sub-second round-trip for 3 txn, so I assume it's still a gain
8962016-09-01T21:37:04  <gmaxwell> luke-jr: yes, I found that it was in testing.
8972016-09-01T21:41:41  *** Guyver2 has quit IRC
8982016-09-01T21:44:46  *** pmienk has joined #bitcoin-core-dev
8992016-09-01T21:58:10  *** Chris_St1 has quit IRC
9002016-09-01T22:01:09  *** spudowiar has joined #bitcoin-core-dev
9012016-09-01T22:11:46  *** Chris_St1 has joined #bitcoin-core-dev
9022016-09-01T22:12:51  *** justanotheruser has joined #bitcoin-core-dev
9032016-09-01T22:18:48  *** Giszmo has quit IRC
9042016-09-01T22:19:04  *** Chris_St1 has quit IRC
9052016-09-01T22:24:30  *** Giszmo has joined #bitcoin-core-dev
9062016-09-01T22:28:40  *** grubles has joined #bitcoin-core-dev
9072016-09-01T22:28:40  *** aalex has quit IRC
9082016-09-01T22:31:35  *** aalex has joined #bitcoin-core-dev
9092016-09-01T22:35:25  *** Chris_St1 has joined #bitcoin-core-dev
9102016-09-01T23:00:28  *** Chris_St1 has quit IRC
9112016-09-01T23:32:15  *** TomMc has quit IRC
9122016-09-01T23:36:07  *** Alopex has quit IRC
9132016-09-01T23:37:12  *** Alopex has joined #bitcoin-core-dev
9142016-09-01T23:46:33  *** AaronvanW has quit IRC