12016-06-30T00:01:46  *** fengling has quit IRC
  22016-06-30T00:17:33  *** zooko has joined #bitcoin-core-dev
  32016-06-30T00:45:46  *** Ylbam has quit IRC
  42016-06-30T00:49:17  *** Chris_Stewart_5 has quit IRC
  52016-06-30T00:52:36  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  62016-06-30T00:52:47  *** fengling has joined #bitcoin-core-dev
  72016-06-30T00:57:33  *** gabridome has quit IRC
  82016-06-30T00:59:04  *** gabridome has joined #bitcoin-core-dev
  92016-06-30T01:04:26  *** molz has joined #bitcoin-core-dev
 102016-06-30T01:07:11  *** moli has quit IRC
 112016-06-30T01:20:41  *** zooko has quit IRC
 122016-06-30T01:52:30  <GitHub64> [bitcoin] luke-jr opened pull request #8293: Bugfix: Allow building libbitcoinconsensus without any univalue (master...sys_univalue_opt) https://github.com/bitcoin/bitcoin/pull/8293
 132016-06-30T01:55:30  *** xiangfu has joined #bitcoin-core-dev
 142016-06-30T01:59:33  *** Chris_Stewart_5 has quit IRC
 152016-06-30T02:17:49  *** justanotheruser has quit IRC
 162016-06-30T02:18:22  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 172016-06-30T02:23:12  *** justanotheruser has joined #bitcoin-core-dev
 182016-06-30T02:24:49  *** Chris_Stewart_5 has quit IRC
 192016-06-30T02:27:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 202016-06-30T02:28:18  *** dingus has joined #bitcoin-core-dev
 212016-06-30T02:33:07  *** Chris_Stewart_5 has quit IRC
 222016-06-30T02:37:55  *** Samdney has left #bitcoin-core-dev
 232016-06-30T03:44:52  *** justanotheruser is now known as justanother|NYY
 242016-06-30T03:49:46  *** fengling has quit IRC
 252016-06-30T04:17:01  *** Alopex has quit IRC
 262016-06-30T04:18:06  *** Alopex has joined #bitcoin-core-dev
 272016-06-30T04:24:33  *** fengling has joined #bitcoin-core-dev
 282016-06-30T04:29:26  *** fengling has quit IRC
 292016-06-30T04:31:12  *** moli has joined #bitcoin-core-dev
 302016-06-30T04:33:34  *** molz has quit IRC
 312016-06-30T05:25:55  *** fengling has joined #bitcoin-core-dev
 322016-06-30T05:30:06  *** fengling has quit IRC
 332016-06-30T06:09:09  *** kadoban has quit IRC
 342016-06-30T06:10:30  *** Ylbam has joined #bitcoin-core-dev
 352016-06-30T06:13:02  *** fengling has joined #bitcoin-core-dev
 362016-06-30T06:28:39  *** harrymm has quit IRC
 372016-06-30T06:36:27  *** davec_ has quit IRC
 382016-06-30T06:39:52  *** xiangfu has quit IRC
 392016-06-30T06:42:18  *** murch has joined #bitcoin-core-dev
 402016-06-30T06:44:01  *** davec_ has joined #bitcoin-core-dev
 412016-06-30T06:45:46  *** fengling has quit IRC
 422016-06-30T06:47:22  *** harrymm has joined #bitcoin-core-dev
 432016-06-30T06:47:51  *** fengling has joined #bitcoin-core-dev
 442016-06-30T06:53:39  *** davec_ has quit IRC
 452016-06-30T06:55:41  *** xiangfu has joined #bitcoin-core-dev
 462016-06-30T06:59:48  *** jannes has joined #bitcoin-core-dev
 472016-06-30T07:04:09  *** harrymm has quit IRC
 482016-06-30T07:25:43  *** harrymm has joined #bitcoin-core-dev
 492016-06-30T07:40:33  *** harrymm has quit IRC
 502016-06-30T07:41:26  *** paveljanik has quit IRC
 512016-06-30T07:55:12  *** harrymm has joined #bitcoin-core-dev
 522016-06-30T07:55:32  *** murch has quit IRC
 532016-06-30T08:15:39  *** murch has joined #bitcoin-core-dev
 542016-06-30T08:18:36  *** Giszmo has quit IRC
 552016-06-30T08:33:30  *** [b__b] has quit IRC
 562016-06-30T08:33:50  *** [b__b] has joined #bitcoin-core-dev
 572016-06-30T08:40:07  *** MarcoFalke has joined #bitcoin-core-dev
 582016-06-30T08:54:13  *** Guyver2 has joined #bitcoin-core-dev
 592016-06-30T08:58:26  *** slackircbridge1 has joined #bitcoin-core-dev
 602016-06-30T09:01:06  *** fengling has quit IRC
 612016-06-30T09:01:27  *** Michail1_ has joined #bitcoin-core-dev
 622016-06-30T09:01:54  *** hybridsole_ has joined #bitcoin-core-dev
 632016-06-30T09:03:31  *** pmienk_ has joined #bitcoin-core-dev
 642016-06-30T09:03:57  *** Amnez777- has joined #bitcoin-core-dev
 652016-06-30T09:04:54  *** roasbeef_ has joined #bitcoin-core-dev
 662016-06-30T09:05:42  *** aj_ has joined #bitcoin-core-dev
 672016-06-30T09:06:36  *** xiangfu has quit IRC
 682016-06-30T09:08:16  *** whphhg has quit IRC
 692016-06-30T09:08:16  *** pmienk has quit IRC
 702016-06-30T09:08:16  *** Amnez777 has quit IRC
 712016-06-30T09:08:17  *** sturles has quit IRC
 722016-06-30T09:08:17  *** slackircbridge has quit IRC
 732016-06-30T09:08:17  *** roasbeef has quit IRC
 742016-06-30T09:08:18  *** Michail1 has quit IRC
 752016-06-30T09:08:18  *** aj has quit IRC
 762016-06-30T09:08:18  *** luke-jr has quit IRC
 772016-06-30T09:08:18  *** wangchun has quit IRC
 782016-06-30T09:08:18  *** hybridsole has quit IRC
 792016-06-30T09:08:18  *** Michail1_ is now known as Michail1
 802016-06-30T09:08:21  *** hybridsole_ is now known as hybridsole
 812016-06-30T09:08:25  *** wangchun has joined #bitcoin-core-dev
 822016-06-30T09:08:38  *** luke-jr has joined #bitcoin-core-dev
 832016-06-30T09:08:46  *** paveljanik has joined #bitcoin-core-dev
 842016-06-30T09:08:55  *** paveljanik has quit IRC
 852016-06-30T09:08:55  *** paveljanik has joined #bitcoin-core-dev
 862016-06-30T09:10:37  *** whphhg has joined #bitcoin-core-dev
 872016-06-30T09:11:55  *** sturles has joined #bitcoin-core-dev
 882016-06-30T09:11:55  *** sturles has joined #bitcoin-core-dev
 892016-06-30T09:15:27  *** fengling has joined #bitcoin-core-dev
 902016-06-30T09:24:17  *** pedrobranco has joined #bitcoin-core-dev
 912016-06-30T09:28:06  *** fengling has quit IRC
 922016-06-30T09:32:54  *** afk11 has quit IRC
 932016-06-30T09:36:47  *** fengling has joined #bitcoin-core-dev
 942016-06-30T09:37:52  *** afk11 has joined #bitcoin-core-dev
 952016-06-30T09:37:52  *** afk11 has quit IRC
 962016-06-30T09:37:52  *** afk11 has joined #bitcoin-core-dev
 972016-06-30T09:42:22  *** xiangfu has joined #bitcoin-core-dev
 982016-06-30T09:56:58  *** xiangfu has quit IRC
 992016-06-30T10:21:46  *** fengling has quit IRC
1002016-06-30T10:23:54  *** fengling has joined #bitcoin-core-dev
1012016-06-30T10:25:35  *** davec_ has joined #bitcoin-core-dev
1022016-06-30T10:29:48  *** afk11 has quit IRC
1032016-06-30T10:31:45  *** paveljanik has quit IRC
1042016-06-30T10:37:42  *** afk11 has joined #bitcoin-core-dev
1052016-06-30T10:37:42  *** afk11 has quit IRC
1062016-06-30T10:37:42  *** afk11 has joined #bitcoin-core-dev
1072016-06-30T10:41:31  *** ratoder has quit IRC
1082016-06-30T10:41:46  *** Alopex has quit IRC
1092016-06-30T10:41:51  *** jonasschnelli has quit IRC
1102016-06-30T10:49:22  *** jonasschnelli has joined #bitcoin-core-dev
1112016-06-30T10:53:07  *** Alopex has joined #bitcoin-core-dev
1122016-06-30T10:55:26  *** fengling has quit IRC
1132016-06-30T11:01:33  *** cryptapus has joined #bitcoin-core-dev
1142016-06-30T11:20:49  *** jonasschnelli has quit IRC
1152016-06-30T11:20:49  *** jonasschnelli has joined #bitcoin-core-dev
1162016-06-30T11:36:11  *** pmienk_ has quit IRC
1172016-06-30T11:36:35  *** pmienk_ has joined #bitcoin-core-dev
1182016-06-30T11:50:57  *** belcher has joined #bitcoin-core-dev
1192016-06-30T12:15:51  *** paveljanik has joined #bitcoin-core-dev
1202016-06-30T12:34:16  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1212016-06-30T12:48:54  *** Chris_Stewart_5 has quit IRC
1222016-06-30T12:52:57  *** cryptapus_ has joined #bitcoin-core-dev
1232016-06-30T12:56:21  *** cryptapus has quit IRC
1242016-06-30T13:04:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1252016-06-30T13:49:02  *** murch has quit IRC
1262016-06-30T13:49:28  *** murch has joined #bitcoin-core-dev
1272016-06-30T14:00:18  *** murch1 has joined #bitcoin-core-dev
1282016-06-30T14:01:12  *** murch has quit IRC
1292016-06-30T14:13:02  *** harrymm has quit IRC
1302016-06-30T14:20:19  <GitHub96> [bitcoin] jmcorgan closed pull request #8284: Backport remaining commits for out-of-tree builds from master to 0.12 branch (0.12...build-oot-0.12) https://github.com/bitcoin/bitcoin/pull/8284
1312016-06-30T14:32:04  *** Giszmo has joined #bitcoin-core-dev
1322016-06-30T14:34:52  *** harrymm has joined #bitcoin-core-dev
1332016-06-30T14:38:32  *** rubensayshi has quit IRC
1342016-06-30T14:40:13  *** rubensayshi has joined #bitcoin-core-dev
1352016-06-30T14:56:15  *** bsm1175321 has joined #bitcoin-core-dev
1362016-06-30T14:58:00  *** pmienk_ has quit IRC
1372016-06-30T14:58:48  *** harrymm has quit IRC
1382016-06-30T14:59:53  *** cryptapus_ is now known as cryptapus
1392016-06-30T15:01:44  <sdaftuar> proposed topic for the meeting today: wrapping up the mining-related changes to 0.13.0 (please see #8294)
1402016-06-30T15:04:26  *** [Author] has quit IRC
1412016-06-30T15:06:49  *** cryptapus has quit IRC
1422016-06-30T15:07:02  *** cryptapus has joined #bitcoin-core-dev
1432016-06-30T15:09:37  *** [Author] has joined #bitcoin-core-dev
1442016-06-30T15:25:41  *** zooko has joined #bitcoin-core-dev
1452016-06-30T15:30:34  *** Chris_Stewart_5 has quit IRC
1462016-06-30T15:40:17  *** frankenmint has joined #bitcoin-core-dev
1472016-06-30T15:41:26  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1482016-06-30T15:59:36  *** spudowiar has joined #bitcoin-core-dev
1492016-06-30T16:00:27  *** Chris_Stewart_5 has quit IRC
1502016-06-30T16:09:14  *** jtimon has joined #bitcoin-core-dev
1512016-06-30T16:10:57  <jtimon> since then does AcceptToMemoryPoolWorker take a bool* pfMissingInputs parameter instead of just logging a validation error and returning false?
1522016-06-30T16:11:30  <jtimon> that's a consensus check, do we plan to pass bool* pfMissingInputs to libconsensus' veryfyTx too?
1532016-06-30T16:12:31  <sipa> since 0.1.0
1542016-06-30T16:12:43  <sipa> it's literally been there in every release ever
1552016-06-30T16:13:01  *** davec_ has quit IRC
1562016-06-30T16:13:56  *** davec_ has joined #bitcoin-core-dev
1572016-06-30T16:15:00  <jtimon> mhmm, somehow I remember return state.DoS(missing inputs) in https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1236
1582016-06-30T16:15:33  <jtimon> may have been in one of my consensus branches...
1592016-06-30T16:17:02  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1602016-06-30T16:17:53  <jtimon> never mind, I must have dreamed it or something
1612016-06-30T16:18:21  <sipa> Sounds like a nice dream.
1622016-06-30T16:20:35  *** jtimon has quit IRC
1632016-06-30T16:22:55  <GitHub6> [bitcoin] sdaftuar opened pull request #8295: Mining-related fixups for 0.13.0 (master...cnb-segwit) https://github.com/bitcoin/bitcoin/pull/8295
1642016-06-30T16:27:46  *** Frederic94500 has joined #bitcoin-core-dev
1652016-06-30T16:33:50  *** Sosumi has quit IRC
1662016-06-30T16:36:05  *** Lysanders has joined #bitcoin-core-dev
1672016-06-30T16:38:19  *** murch1 has quit IRC
1682016-06-30T16:39:58  *** Chris_Stewart_5 has quit IRC
1692016-06-30T16:40:27  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1702016-06-30T16:45:28  *** Chris_Stewart_5 has quit IRC
1712016-06-30T16:46:19  *** kadoban has joined #bitcoin-core-dev
1722016-06-30T16:48:44  *** [b__b] has quit IRC
1732016-06-30T16:50:10  *** harrymm has joined #bitcoin-core-dev
1742016-06-30T16:50:56  *** [b__b] has joined #bitcoin-core-dev
1752016-06-30T16:52:51  *** MarcoFalke has left #bitcoin-core-dev
1762016-06-30T16:54:40  *** harrymm has quit IRC
1772016-06-30T16:55:57  *** bsm1175321 has quit IRC
1782016-06-30T16:58:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1792016-06-30T17:01:29  *** dingus is now known as grubles
1802016-06-30T17:02:03  *** bsm1175321 has joined #bitcoin-core-dev
1812016-06-30T17:11:31  *** pmienk has joined #bitcoin-core-dev
1822016-06-30T17:17:21  *** Chris_Stewart_5 has quit IRC
1832016-06-30T17:20:52  *** pmienk has quit IRC
1842016-06-30T17:25:06  *** frankenmint has quit IRC
1852016-06-30T17:32:55  *** pmienk has joined #bitcoin-core-dev
1862016-06-30T17:33:17  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1872016-06-30T17:39:24  *** [b__b] has quit IRC
1882016-06-30T17:44:27  *** [b__b] has joined #bitcoin-core-dev
1892016-06-30T17:55:45  <GitHub138> [bitcoin] MarcoFalke opened pull request #8296: [qa] Make setup_chain private (master...Mf1607-qaSetupChain) https://github.com/bitcoin/bitcoin/pull/8296
1902016-06-30T17:57:30  *** roasbeef_ is now known as roasbeef
1912016-06-30T18:00:12  *** spudowiar has quit IRC
1922016-06-30T18:00:56  *** Sosumi has joined #bitcoin-core-dev
1932016-06-30T18:04:08  *** rubensayshi has quit IRC
1942016-06-30T18:09:33  *** Arnavion has quit IRC
1952016-06-30T18:11:57  *** Arnavion has joined #bitcoin-core-dev
1962016-06-30T18:18:49  *** pedrobranco has quit IRC
1972016-06-30T18:19:22  *** pedrobranco has joined #bitcoin-core-dev
1982016-06-30T18:20:46  *** pedrobra_ has joined #bitcoin-core-dev
1992016-06-30T18:20:48  *** pedrobranco has quit IRC
2002016-06-30T18:21:12  *** MarcoFalke has joined #bitcoin-core-dev
2012016-06-30T18:25:25  *** pedrobra_ has quit IRC
2022016-06-30T18:25:53  *** frankenmint has joined #bitcoin-core-dev
2032016-06-30T18:30:44  *** frankenmint has quit IRC
2042016-06-30T18:33:18  *** cjcj has quit IRC
2052016-06-30T18:38:16  *** pedrobranco has joined #bitcoin-core-dev
2062016-06-30T18:43:09  *** pedrobranco has quit IRC
2072016-06-30T18:45:57  *** Prattler has joined #bitcoin-core-dev
2082016-06-30T18:47:26  *** Prattler has left #bitcoin-core-dev
2092016-06-30T18:49:55  *** spudowiar has joined #bitcoin-core-dev
2102016-06-30T18:56:30  *** jtimon has joined #bitcoin-core-dev
2112016-06-30T19:00:25  <MarcoFalke> no meeting?
2122016-06-30T19:00:36  <sdaftuar> i'm here!
2132016-06-30T19:00:36  <gmaxwell> Yes meeting.
2142016-06-30T19:01:02  <sipa> i ' m   h e r e
2152016-06-30T19:01:10  <gmaxwell> #startmeeting
2162016-06-30T19:01:10  <lightningbot> Meeting started Thu Jun 30 19:01:10 2016 UTC.  The chair is gmaxwell. Information about MeetBot at http://wiki.debian.org/MeetBot.
2172016-06-30T19:01:10  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2182016-06-30T19:01:13  <btcdrak> ping
2192016-06-30T19:01:17  <wumpus> pong
2202016-06-30T19:01:20  *** TheFactory7 has joined #bitcoin-core-dev
2212016-06-30T19:01:20  <sipa> pang
2222016-06-30T19:01:26  <gmaxwell> Welcome to the meeting. Hard start today, sorry to not get pings out earlier.
2232016-06-30T19:01:35  <jonasschnelli> pong
2242016-06-30T19:01:47  <wumpus> <sdaftuar> proposed topic for the meeting today: wrapping up the mining-related changes to 0.13.0 (please see #8294)
2252016-06-30T19:02:01  <gmaxwell> wumpus: jtimon: jonasschnelli: petertodd: morcos: MarcoFalke: NicolasDorier: paveljanik:
2262016-06-30T19:02:06  <jtimon> pong
2272016-06-30T19:02:27  <gmaxwell> #topic wrapping up the mining-related changes to 0.13.0 (please see #8294)
2282016-06-30T19:02:32  <wumpus> also segwit 0.12 backport status, maybe
2292016-06-30T19:02:39  <sipa> unstarted.
2302016-06-30T19:03:21  <sdaftuar> so i mentioned a few things in that issue that i think we need to address for 0.13.0
2312016-06-30T19:03:22  <petertodd> hi
2322016-06-30T19:03:30  <sdaftuar> a couple should be non-controversial bugfixes
2332016-06-30T19:03:41  <kanzure> hi
2342016-06-30T19:03:48  <gmaxwell> sdaftuar: blockminsize  should just go
2352016-06-30T19:03:57  <sdaftuar> two things i wanted feedback on were (a) removing the old mining algorithm ("addScoreTxs") and (b) -blockminsize
2362016-06-30T19:04:01  <sdaftuar> ok great, that's what i think too
2372016-06-30T19:04:02  <sipa> in favor of just dropping -blockminsize
2382016-06-30T19:04:21  <gmaxwell> sdaftuar: "Should we remove the old transaction selection algorithm"   I'm indifferent to favoring removing code.
2392016-06-30T19:04:30  <gmaxwell> luke-jr: your thoughts?
2402016-06-30T19:04:52  <wumpus> if the code is not used, it should be removed
2412016-06-30T19:04:56  <gmaxwell> (like to sdaftuar's issue: https://github.com/bitcoin/bitcoin/issues/8294 )
2422016-06-30T19:04:56  <sipa> i think we shouldn't keep the old algorithm just because we're not sure if the new one works
2432016-06-30T19:05:02  <sipa> we can always revert code if needed
2442016-06-30T19:05:35  <sipa> the current reason for keeping is because when -blockminsiz or -blockmaxsize are -blockprioritysize are given, the new algorithm does not work (due to missing accounting)
2452016-06-30T19:05:49  <sipa> if we fix the accounting, and make the new algorithm support those parameters, the old algorithm can go
2462016-06-30T19:05:55  <sdaftuar> sipa: right, and that is addressed in the first commit of #8295
2472016-06-30T19:05:59  <gmaxwell> the only gain I see is if there is some stupidity in the new one the old one is a switch away... but the new one has a reasonable amount of testing and if it has some issue it seems unlikely that its so major that just fixing it wouldn't be the prefered solution.
2482016-06-30T19:06:02  <sipa> ok, grea;t i haven't looked
2492016-06-30T19:06:08  <jtimon> I don't remember addScoreTx, but ack on removing blockminsize
2502016-06-30T19:06:43  <wumpus> it's a bit late in the release to be removing arguments, on the other hand it was already not working so let's do it...
2512016-06-30T19:07:01  <wumpus> as long as it's documented in the release notes
2522016-06-30T19:07:13  <gmaxwell> it should be removed but not cause the daemon to fail to start if specified.
2532016-06-30T19:07:15  <sdaftuar> wumpus: agree, the release notes need a bunch of writeup for all the mining changes
2542016-06-30T19:07:16  <wumpus> or e.g. emit a warning/error if it is provided
2552016-06-30T19:07:31  <sipa> i am perfectly fine with just making -blockminsize work for 0.13 with CPFP, and removing it in 0.14
2562016-06-30T19:07:52  <sipa> sdaftuar: unless you think that would be much more work (i think it would be deleting 2 lines to stop supporting it)
2572016-06-30T19:08:08  <wumpus> sounds like that would be a waste of work, if it is going to be removed anyway, but I don't know how much work it is
2582016-06-30T19:08:15  <sdaftuar> sipa: it'd be adding code to support it.  i think it's probably easy, but i haven't thought carefully about it.  probably a one line change.
2592016-06-30T19:08:32  <sipa> i expect it to be trivial to make it work, and also trivial to remove
2602016-06-30T19:08:48  <wumpus> if it's trivial to make it work, let's go for that
2612016-06-30T19:08:50  <sipa> also, i think it's utterly pointless in the current mining encironment
2622016-06-30T19:08:53  <sdaftuar> sipa: agreed.
2632016-06-30T19:09:03  <jtimon> emit warning seems a good option
2642016-06-30T19:09:19  <gmaxwell> I think it's a goofy option.
2652016-06-30T19:09:20  <wumpus> if it's not trivial, or annoying to test, let's get rid of it
2662016-06-30T19:09:26  <gmaxwell> less options good.
2672016-06-30T19:09:28  <sipa> ack, we could just test for its value, and fail at startup if a nonzero value is passed
2682016-06-30T19:09:31  <sdaftuar> we have no tests for it now, i believe.
2692016-06-30T19:09:36  <sipa> it has no tests
2702016-06-30T19:09:38  <sipa> pretty sure
2712016-06-30T19:09:47  *** Chris_Stewart_5 has quit IRC
2722016-06-30T19:09:54  <sdaftuar> my preference would be to get rid of it, rather than add a test to make sure it works.
2732016-06-30T19:10:07  <sipa> sdaftuar: will review your patch
2742016-06-30T19:10:08  <wumpus> right, that's fine
2752016-06-30T19:10:26  *** Bootvis has joined #bitcoin-core-dev
2762016-06-30T19:10:32  <jtimon> gmaxwell: why you don't want it to fail if the argument is provided ?
2772016-06-30T19:11:04  <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon luke-jr cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
2782016-06-30T19:11:14  <gmaxwell> (sorry, just creating a ping macro for future use)
2792016-06-30T19:11:37  <michagogo> Oh
2802016-06-30T19:11:38  <michagogo> Hi
2812016-06-30T19:11:43  <sdaftuar> jtimon: my preference for not causing failure is that that would be extra code to write/test/review.  silent failure seems easier, and harmless in this situation.
2822016-06-30T19:11:49  <gmaxwell> jtimon: because it's a mostly meaningless setting that some people are going to have by virtue of copy and pasting things.
2832016-06-30T19:11:56  <sipa> meh, ok
2842016-06-30T19:11:57  <kanzure> i nominate jtimon for double inclusion in the ping, but otherwise ACK
2852016-06-30T19:12:02  <wumpus> I don't really like ignoring options, that can be really frustrating
2862016-06-30T19:12:25  <wumpus> 'wtf doesn't this work', oh, then after an hour of debugging you notice that the functionality has been removed
2872016-06-30T19:12:31  <sipa> agree
2882016-06-30T19:12:36  <sdaftuar> wumpus: in this case though, you wouldn't have been noticing the old behavior "working"
2892016-06-30T19:12:38  <wumpus> at least add a warning, I don't care about failing
2902016-06-30T19:12:39  <jtimon> I'm fine with either failing or giving a warning
2912016-06-30T19:12:46  <sdaftuar> i can add a warning, sure.
2922016-06-30T19:12:54  <sipa> let's discuss this when the actual PR is created
2932016-06-30T19:13:01  <jtimon> fair enough
2942016-06-30T19:13:03  <sdaftuar> i included removal of -blockminsize in 8295
2952016-06-30T19:13:14  <sdaftuar> i can fix to warn if the argument is given
2962016-06-30T19:13:20  <wumpus> great
2972016-06-30T19:13:23  <gmaxwell> okay warning fine.
2982016-06-30T19:14:08  <sdaftuar> one thing i wanted to mention, if we do decide to remove addScoreTxs(), we could also remove the mining_score from the mempool multiindex
2992016-06-30T19:14:15  <gmaxwell> wumpus: I agree in principle except for the fact that a LOT of people have copied the "example config" from the bitcoin wiki and are setting all kinds of crazy things. :)
3002016-06-30T19:14:23  <sdaftuar> i didn't incldue that in 8295, but wanted to mention it in case we want to remove for 0.13
3012016-06-30T19:14:39  <sdaftuar> it would give us a small memory savings in the mempool, but not sure if that's a change that we'd rather wait for 0.14 tomake
3022016-06-30T19:14:43  <sdaftuar> i don't have a preference
3032016-06-30T19:14:50  <sipa> ENOCARE
3042016-06-30T19:15:00  <jtimon> sdaftuar: can't https://github.com/bitcoin/bitcoin/pull/8295/commits/27362dda4d583a43ebf687ae097d2f45ba1c4c32 be a trivial to review separate PR ?
3052016-06-30T19:15:03  <wumpus> gmaxwell: yes, indeed, it's an option that's bound to be misinterpreted/misused anyway
3062016-06-30T19:15:16  <gmaxwell> <meme text="Delete all the code."/>
3072016-06-30T19:15:42  <sdaftuar> jtimon: it builds on removing addScoreTxs i think?
3082016-06-30T19:15:51  <jtimon> sdaftuar: oh, I see
3092016-06-30T19:15:59  <sdaftuar> jtimon: but yes i could have split those two commits out
3102016-06-30T19:16:00  <jtimon> mhmm
3112016-06-30T19:16:52  <gmaxwell> Okay, anything more on this that needs to happen in the meeting?
3122016-06-30T19:16:54  <jtimon> whatever, minor point, I just don't think I can ack the pr like that because I haven't been following some of the refactors in miner much
3132016-06-30T19:17:33  <sdaftuar> i think we can move on, thanks
3142016-06-30T19:17:35  <jtimon> well, refactors and changes
3152016-06-30T19:17:40  <wumpus> sdaftuar: I'd say if they are after your changes remove the mempool fields, it's not much of a risk, if everything is alright the compiler checks that nothing is referring to it
3162016-06-30T19:17:54  <sdaftuar> wumpus: ok great, thanks
3172016-06-30T19:18:00  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3182016-06-30T19:18:03  <sdaftuar> i'll defer that until after 8295 is merged anyway
3192016-06-30T19:18:10  <wumpus> right, it's not a priority
3202016-06-30T19:18:12  <sdaftuar> yep
3212016-06-30T19:18:25  <wumpus> any other topics for today?
3222016-06-30T19:18:53  <CodeShark> hmm
3232016-06-30T19:19:05  <petertodd> anyone get a chnace to look at https://github.com/bitcoin/bitcoin/issues/8279 ? at a conf right now
3242016-06-30T19:19:27  <sipa> petertodd: yes, i think it is a good point
3252016-06-30T19:19:42  <petertodd> sipa: cool, thanks
3262016-06-30T19:19:48  <sdaftuar> sipa: you noticed a related issue as well, right?
3272016-06-30T19:19:56  <petertodd> sipa: (mainly wanted to know if I needed to post a retraction!)
3282016-06-30T19:20:37  <sipa> sdaftuar: the sigops counting? i believe that is not vulnerable to mauling (the verb related to 'malleability', apparently)
3292016-06-30T19:20:42  <sipa> (also not found by me)
3302016-06-30T19:20:43  <gmaxwell> #topic segwit
3312016-06-30T19:21:02  <sdaftuar> sipa: it is, because we don't verify that the witness script matches the commitment in the pubkey output
3322016-06-30T19:21:08  <sdaftuar> right?
3332016-06-30T19:21:28  <petertodd> sdaftuar: no, I think we do that prior to sigops checking
3342016-06-30T19:21:48  <sdaftuar> i'll take another look.  pretty sure sipa and i discussed and concluded that we didn't.
3352016-06-30T19:21:52  <sipa> sdaftuar: something to look into
3362016-06-30T19:22:13  <petertodd> sdaftuar: yeah, wouldn't hurt to take another look - that review was a bunch of owrk and I may have been a bit faded by the end :)
3372016-06-30T19:22:35  <sipa> i don't think these are serious problems (it allows preventing a node from getting a transaction, but there are other means for that, like announcing it and not responding)
3382016-06-30T19:22:39  <sdaftuar> petertodd: i'm specifically referring to the sigopcount checks in accepttomemorypool, not consensus level checking
3392016-06-30T19:22:43  <sipa> but they should be understood
3402016-06-30T19:23:04  *** Chris_Stewart_5 has quit IRC
3412016-06-30T19:23:16  <petertodd> sdaftuar: yeah, I _thought_ I looked at that, but may have missed it - mempool was the last thing I looked at
3422016-06-30T19:23:51  <sipa> petertodd: i'm really glad you did that review, by the way - the writeup makes a lot of things more communicatable
3432016-06-30T19:24:08  <petertodd> sipa: thanks! yeah, mainly wanted to demystify the process of doing review
3442016-06-30T19:24:47  <gmaxwell> I don't think its of major importance, but "Bitcoin XT" recently started making only outbound connections to other XT nodes.  In combination with segwit, I believe this will partition them.  Because they are such a small number of nodes I don't think it warrents much attention, but something to be aware of.
3452016-06-30T19:24:47  *** laurentmt has joined #bitcoin-core-dev
3462016-06-30T19:25:28  <gmaxwell> petertodd: yea, nice work.
3472016-06-30T19:25:30  <sdaftuar> gmaxwell: we have a little time before that will happen, as we haven't yet activated the preferential peering yet
3482016-06-30T19:25:40  <gmaxwell> sdaftuar: indeed.
3492016-06-30T19:26:22  <petertodd> gmaxwell: ...
3502016-06-30T19:26:52  <sipa> segwit by the way does not _only_ make outbound connections to segwit
3512016-06-30T19:26:58  <sipa> but it strongly prefers them
3522016-06-30T19:27:12  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3532016-06-30T19:27:14  <petertodd> sipa: yeah, I noticed that - after 40 tries you connect to non-segwit outgoing
3542016-06-30T19:27:22  <gmaxwell> sipa: right, I think that would be sufficient to partition there.
3552016-06-30T19:27:26  <sipa> petertodd: yes, totally arbitrary number
3562016-06-30T19:28:06  <jl2012> gmaxwell: they should fix that. We just need to let them know
3572016-06-30T19:28:07  <petertodd> wouln't be a crazy idea to have a mode that disabled the DoS banning for incoming nodes btw...
3582016-06-30T19:28:31  <sipa> petertodd: DoS banning, or also DoS disconnection?
3592016-06-30T19:28:48  <gmaxwell> petertodd: one can set that threshold arbritarily high at least.
3602016-06-30T19:28:56  <petertodd> sipa: both, to be able to (at least temproarily) work around bugs related to DoS banning
3612016-06-30T19:29:24  <petertodd> sipa: equally, have a small subset of nodes that can be set to ignore the DoS banning
3622016-06-30T19:29:38  <gmaxwell> Patch accepted to make low-dos-score a ranking criteria in eviction protection logic, which would also make running with a very high dos threshold more reasonable.
3632016-06-30T19:29:56  <petertodd> gmaxwell: good idea
3642016-06-30T19:30:50  <gmaxwell> jl2012: I was just made aware of it, but sure.
3652016-06-30T19:31:02  <gmaxwell> my past expirence with that project has not been very good.
3662016-06-30T19:31:14  <wumpus> so a different ban thrshold for incoming versus outgoing connections?
3672016-06-30T19:31:25  <petertodd> jl2012: there's a issue open in the XT repo for it already
3682016-06-30T19:31:37  <btcdrak> jl2012: there is a ticket open already
3692016-06-30T19:31:54  <gmaxwell> petertodd: we should probably just brainstorm some about connection management stuff, there are a number of neat improvements we can make.
3702016-06-30T19:32:11  <sipa> if we're thinking about such refactors, the DoS score should probably also attenuate over time
3712016-06-30T19:32:14  <petertodd> wumpus: I think the main thing, is just to have different thresholds period for some nodes, so that while you won't wast bandwidth on everyone, keep a few peers connected regardless in case you're dealing with a DoS-related bug and should be distributing the data anyway
3722016-06-30T19:32:31  <sipa> otherwise longer-lived connections will accumulate a score they don't deserve
3732016-06-30T19:32:35  <wumpus> petertodd: so a sort of halfway-whitelisting
3742016-06-30T19:32:39  <petertodd> wumpus: also, along those lines, distributing invalid blocks with valid PoW isn't a crazy idea
3752016-06-30T19:32:42  <petertodd> wumpus: yup
3762016-06-30T19:32:45  <gmaxwell> petertodd: such a thing could also turn those peers into blocksonly.
3772016-06-30T19:32:51  <gmaxwell> since thats all we care about for anti-partitioning.
3782016-06-30T19:32:52  <petertodd> gmaxwell: yeah, that's a good idea
3792016-06-30T19:33:02  <gmaxwell> and yet it almost completely eliminates dos concerns.
3802016-06-30T19:33:36  *** laurentmt has quit IRC
3812016-06-30T19:34:42  <petertodd> blocksonly on-DoS + relaying of invalid blocks w/ valid PoW in a separate "may be invalid" message would satisfy everything I think
3822016-06-30T19:34:53  <wumpus> sipa: attentuating theDoS score over time makes sense, a very slow DoS attack isn't really a DoS attack (apart from keeping a connection slot open, but that's not what the score is to protect against)
3832016-06-30T19:35:27  <sipa> theDos? sister of GLaDoS?
3842016-06-30T19:35:34  <petertodd> sipa: lol
3852016-06-30T19:35:37  <btcdrak> omg
3862016-06-30T19:36:03  <wumpus> then again it's not really a anti-DoS score is it, it won't get triggered on accidental over-use of resources, more a misbehavior score
3872016-06-30T19:36:23  <wumpus> hehe
3882016-06-30T19:36:37  <sipa> yes, i think there may be reasons to introduce something like a "resource usage score" which is distinct from "misbehaviour"
3892016-06-30T19:36:40  <wumpus> the cake is a lie
3902016-06-30T19:36:51  <sipa> and which gets used to decide which peers to disconnect in favor of others
3912016-06-30T19:36:57  <sipa> but never causes a ban
3922016-06-30T19:37:03  <wumpus> yes, indeed
3932016-06-30T19:37:15  <sipa> not a disconnection, unless there is a pressing reason to disconnect someone anyway
3942016-06-30T19:37:23  <petertodd> wumpus: might not be a bad idea to go through the DoS stuff and remove bans in cases where the misbehavior doesn't take much cpu time to detect (and then use it in the anti-partitioning score instead)
3952016-06-30T19:37:46  <gmaxwell> yea, I think there is a lot we can do here.
3962016-06-30T19:38:21  <gmaxwell> So-- the issue of dbcache that I brought up last week can we talk about that for a bit?
3972016-06-30T19:38:27  <sipa> ack topic
3982016-06-30T19:38:30  <wumpus> sure
3992016-06-30T19:38:31  <gmaxwell> #topic dbcache
4002016-06-30T19:38:50  <wumpus> petertodd: agreed
4012016-06-30T19:38:56  <gmaxwell> Last week I brought up that reindex with defaults was SUPER slow on my laptop, been a while since I'd reindexed with default dbcache.
4022016-06-30T19:39:29  <gmaxwell> This resulted in more benchmarking, and wumpus has a PR to increase the default dbcache to 300mb and also clamp the leveldb cache usage (so that it doesn't go gigantic as dbcache increases)
4032016-06-30T19:39:30  <wumpus> the pull request to bump default dbcache to 300MiB is ready: https://github.com/bitcoin/bitcoin/pull/8273
4042016-06-30T19:39:44  <gmaxwell> I did testing to confirm that the leveldb cache sizes don't have much effect.
4052016-06-30T19:39:58  <gmaxwell> they seem like they have more effect with txindex enabled, however.
4062016-06-30T19:40:03  * jonasschnelli will test 8273
4072016-06-30T19:40:31  <wumpus> which makes sense, txindex has a completely different access pattern than the utxo set
4082016-06-30T19:40:34  <wumpus> it's almost write-only
4092016-06-30T19:40:43  <sipa> morcos: no more work on #6936?
4102016-06-30T19:40:52  <gmaxwell> As a related aside txindex performance is fairly slow, makes an 'infinite' dbcache reindex by about 25%.
4112016-06-30T19:40:56  <wumpus> so we could cap that at a different value
4122016-06-30T19:41:20  <sipa> txindex adds many many more writes
4132016-06-30T19:41:29  <gmaxwell> wumpus: yes, ran a test with 32mb which has finished but I didn't have time before the meeting to collect the results, will shortly after.
4142016-06-30T19:41:31  <sipa> though they should be configured to bypass all caches
4152016-06-30T19:41:33  <wumpus> yes txindex is very slow, just a lot of data
4162016-06-30T19:41:47  <gmaxwell> my testing is on a fast spinning disk system, which I think is probaby the right thing to test for on this.
4172016-06-30T19:42:00  <sdaftuar> sipa: oh, morcos and i were just talking about whether there were things we were working on that used the mining score index, but i think we had both forgotten about #6936.
4182016-06-30T19:42:16  <wumpus> even the idea of indexing every transaction on the block chain is crazy
4192016-06-30T19:42:32  <jonasschnelli> My last tests showd me that a reindex (master) was twice as long as a a normal IDB (from rnd peers) from the scratch...
4202016-06-30T19:42:44  <wumpus> there's much slower implementations possible though, like stashing everything into mysql :-)
4212016-06-30T19:42:55  <sipa> jonasschnelli: wut?!
4222016-06-30T19:42:55  <gmaxwell> One result of my testing is showing that even the 300MB dbcache is really not big enough to give good reindex performance.  We should consider something for 0.14 to give mempool memory to dbcache during ibd/reindex or something.
4232016-06-30T19:43:17  <gmaxwell> jonasschnelli: that last test was before the signature checking fix?
4242016-06-30T19:43:19  <jonasschnelli> sipa: 5.5h reindex against ~3h IBD
4252016-06-30T19:43:20  <wumpus> jonasschnelli: whoa
4262016-06-30T19:43:28  <jonasschnelli> I'm redoing it now...
4272016-06-30T19:43:32  <gmaxwell> jonasschnelli: when was it?
4282016-06-30T19:43:36  <sipa> jonasschnelli: what part of that was real reindex, and what was chainstate rebuilding?
4292016-06-30T19:43:39  <wumpus> I thought we solved that recently
4302016-06-30T19:43:40  <jonasschnelli> a couple of weeks ago after sipas work
4312016-06-30T19:43:51  <jonasschnelli> sipa: just a plain -reindex
4322016-06-30T19:43:57  <jonasschnelli> wth dbcache=8000
4332016-06-30T19:44:10  <sipa> that's painful
4342016-06-30T19:44:15  <gmaxwell> Reindex now has that header scan, it adds about 20 minutes on my test hosts that a sync wouldn't have.
4352016-06-30T19:44:32  <sipa> jonasschnelli: can you benchmark -reindex-chainstate vs IBD?
4362016-06-30T19:44:35  <wumpus> that can't make the difference between 3h and 5.5h though
4372016-06-30T19:44:44  <gmaxwell> but I tested with and without signature checking, and in both cases reindex in master is faster than 0.12.1.
4382016-06-30T19:44:45  <jonasschnelli> sipa: okay. Will do.
4392016-06-30T19:44:51  <wumpus> 20 minutes difference would be ok
4402016-06-30T19:45:10  <sipa> it may depend on your disk
4412016-06-30T19:45:29  <gmaxwell> I didn't test an IBD but I can easily do that. We do probably lose some time due to out of order blocks.
4422016-06-30T19:45:34  <jonasschnelli> Also there is the potential_deadlock_detected that stops my node (-debug) every couple of minutes..
4432016-06-30T19:45:35  <sipa> if it's a VM with a file-backed storage which is on a network filesystem stored on an encrypted ZFS container...
4442016-06-30T19:46:05  <sipa> jonasschnelli: i hope your normal benchmarks are not with -debug builds
4452016-06-30T19:46:06  <wumpus> lock debugging slows down the sync too
4462016-06-30T19:46:29  <sipa> additionally, we need to fix that bug
4472016-06-30T19:46:39  <sipa> i'll look into that lockorder
4482016-06-30T19:46:44  <wumpus> but yes, the deadlock detected in the network code seems to be a real deadlock
4492016-06-30T19:46:58  <jonasschnelli> wumpus: yes. Agree. But i have compare -debug IBD against -debug reindex
4502016-06-30T19:47:07  <sipa> jonasschnelli: meh, don't do that
4512016-06-30T19:47:17  <sipa> debug is not ever going to give you a realistic benchmark
4522016-06-30T19:47:32  <jonasschnelli> developer are supposed to run --enable-debug software! :)
4532016-06-30T19:47:36  <wumpus> do we have an issue open for that deadlock issue btw?
4542016-06-30T19:47:42  <sipa> jonasschnelli: yes, but not for benchmarking
4552016-06-30T19:47:49  <gmaxwell> #topic net deadlock
4562016-06-30T19:47:50  <jonasschnelli> wumpus: no. Let me open one.
4572016-06-30T19:47:56  <sipa> jonasschnelli: thanks
4582016-06-30T19:48:07  <jonasschnelli> sipa: Yes. Agree... will benchmark again without -debug
4592016-06-30T19:48:14  <sipa> jonasschnelli: please list your exact commit (so we can identify the line numbers)
4602016-06-30T19:48:27  <jonasschnelli> okay. Good point.
4612016-06-30T19:49:13  <gmaxwell> #action jonasschnelli to open issue on lockorder deadlock report that he's seeing
4622016-06-30T19:49:17  <gmaxwell> Any other topics?
4632016-06-30T19:50:25  <gmaxwell> okay Seems quiet, perhaps we can end a bit early.
4642016-06-30T19:50:29  <sdaftuar> maybe bip152?
4652016-06-30T19:50:31  <wumpus> seemingly not :)
4662016-06-30T19:50:34  <gmaxwell> ah okay!
4672016-06-30T19:50:37  <sdaftuar> not sure if that's worht bringing up here
4682016-06-30T19:50:39  <gmaxwell> #topic BIP152
4692016-06-30T19:50:53  <gmaxwell> So sipa has SW BIP 152 working on testnet and a number of people testing it.
4702016-06-30T19:51:11  <wumpus> good to hear
4712016-06-30T19:51:31  <petertodd> gmaxwell: as in, segwit bip152 right? +1
4722016-06-30T19:51:39  <btcdrak> I dont recall seeing a PR for that yet?
4732016-06-30T19:51:42  <gmaxwell> petertodd: yes.
4742016-06-30T19:51:50  <wumpus> there's no PR for that
4752016-06-30T19:51:50  <sipa> btcdrak: intentionally not
4762016-06-30T19:52:11  <sipa> 1) this allows us to test interaction between non-SW-BIP152 testnet and changed
4772016-06-30T19:52:24  <sipa> 2) needs some BIP changes (in BIP144, BIP152, or a separate bip entirely)
4782016-06-30T19:52:41  <sipa> 3) not necessary before the segwit softfork
4792016-06-30T19:52:41  <petertodd> sipa: +1
4802016-06-30T19:53:34  <sipa> branch: github.com/sipa/bitcoin/commits/segwitcb
4812016-06-30T19:53:41  <wumpus> not necessary, but would be good to have it before the activation, otherwise CB will suddenly disable
4822016-06-30T19:53:59  <sipa> indeed; it is necessary imho before activation in mastdr
4832016-06-30T19:54:29  <gmaxwell> Thats my view.
4842016-06-30T19:54:54  <wumpus> right, for 0.12 it makes no different, there's no cb there anyhow
4852016-06-30T19:54:59  <gmaxwell> jinx
4862016-06-30T19:55:01  <sipa> agree
4872016-06-30T19:55:12  *** zooko has quit IRC
4882016-06-30T19:55:22  <gmaxwell> In any case, it's working, didn't require anything too complicated. (says the guy who didn't write it)
4892016-06-30T19:56:01  <sdaftuar> sipa, gmaxwell: i still think it'd be better if the information in a blocktxn message could be understood without any state. did i make any progress trying to convince you?
4902016-06-30T19:56:23  <wumpus> there's no need to hurry it anyhow, CB and segwit separately are already huge changes, better to test them in isolation for now
4912016-06-30T19:56:45  <gmaxwell> sdaftuar: only a very small amount.
4922016-06-30T19:57:12  <sipa> sdaftuar: no strong opinion yet
4932016-06-30T19:57:19  <gmaxwell> sdaftuar: we can talk more post meeting.
4942016-06-30T19:57:30  <sdaftuar> sure
4952016-06-30T19:58:32  <gmaxwell> okay, Anything else, we're almost out of time? :)
4962016-06-30T19:58:48  <petertodd> ack endmeeting
4972016-06-30T19:58:51  <gmaxwell> #endmeeting
4982016-06-30T19:58:51  <lightningbot> Meeting ended Thu Jun 30 19:58:51 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
4992016-06-30T19:58:51  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-30-19.01.html
5002016-06-30T19:58:51  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-30-19.01.txt
5012016-06-30T19:58:51  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-30-19.01.log.html
5022016-06-30T19:58:55  <gmaxwell> Hurrah we ended early.
5032016-06-30T19:59:05  <gmaxwell> :P
5042016-06-30T19:59:11  <jonasschnelli> 1min! :)
5052016-06-30T19:59:19  <gmaxwell> May your usage of the remaining minute be productive.
5062016-06-30T19:59:21  <petertodd> heh, my clock must be off... :)
5072016-06-30T19:59:31  <petertodd> brb, gonna fix ntp :)
5082016-06-30T20:00:04  <sipa> doh, too late
5092016-06-30T20:01:55  <gmaxwell> sdaftuar: So; I'm still trying to come up with a case where the offsets would be useful where were are not already keeping an equiivlent amount of state.  There are DOS reasons why we can't, say,  loadbalance getblocktxn fragments to all peers that have inved. But even if we have, keeping a list of indexes per peer is negligible additional state.
5102016-06-30T20:02:05  <sdaftuar> sipa: btw morcos was away from his desk, but says he can look at the coins cache stuff again after 0.13 is branched off
5112016-06-30T20:02:17  <sipa> sdaftuar: sounds good
5122016-06-30T20:02:59  <sdaftuar> gmaxwell: basically you'd be tracking your last getblocktxn request to each peer
5132016-06-30T20:03:48  *** Frederic94500 has quit IRC
5142016-06-30T20:03:49  <sdaftuar> i agree you could do something like that, but this is also complicated, as you'd have to ensure you don't have more than one in-flight
5152016-06-30T20:04:10  <gmaxwell> right, effectively the same information the peer would send back over the wire, you'd keep in memory.  You can have more than one in-flight per peer but not more than one for a given block.
5162016-06-30T20:04:42  <sdaftuar> i guess my point is that it's a trivial amount of bandwidth use in order to do less bookkeeping in code
5172016-06-30T20:04:51  <gmaxwell> But at the same time we could probably even DOS a peer that getblocktxned the same block multiple times. (and we should perhaps consider doing that)
5182016-06-30T20:05:27  <sdaftuar> i think that's a bit too aggressive -- there are legitimate reasons you could do that i think
5192016-06-30T20:05:35  <sdaftuar> ie if block reconstruction failed in an unexpected place
5202016-06-30T20:05:43  <gmaxwell> it's maybe 0.4% overhead
5212016-06-30T20:05:44  <sdaftuar> but you got insight from another peer
5222016-06-30T20:06:41  <sdaftuar> i just don't want to overly limit what we can do with the p2p messages we're adding
5232016-06-30T20:07:24  <sdaftuar> .4% is probably an upperbound on the overhead
5242016-06-30T20:07:31  <gmaxwell> yes.
5252016-06-30T20:08:29  <gmaxwell> sdaftuar: I agree on not limiting the usefulness but I really am just trying to get a case where I agree that it's actually helpful beyond reducing the state size slightly in an already stateful exchange.
5262016-06-30T20:09:08  <gmaxwell> Because there is a cost-- the admitably trivial overhead, and the extra error conditions to test for.
5272016-06-30T20:09:15  <sdaftuar> yeah, it'd be more useful if i had an implementation of something that used it that i could point to, which i sadly don't
5282016-06-30T20:09:24  *** spudowiar has quit IRC
5292016-06-30T20:09:51  <gmaxwell> I had a couple ideas, but then found that they didn't actually work. :)
5302016-06-30T20:10:04  <sdaftuar> my intuition is that messages which can be interpreted on their own is more helpful for writing code.  this isn't super relevant for bitcoind, but imagine how much better it would be to look at historical data that can stand on its own, versus require state
5312016-06-30T20:10:21  <sdaftuar> or writing tests that do strange things
5322016-06-30T20:11:02  <gmaxwell> hah but thats part of my point: it adds more corner cases that need to be tested. E.g. what happens when the indexes weren't what you asked for but were correct, what happens if the txn are what you asked for but the indexes are correct?
5332016-06-30T20:11:13  * gmaxwell steps out for lunch and to ruminate.
5342016-06-30T20:11:32  * sdaftuar has to leave to catch a train anyway, will think about it some more
5352016-06-30T20:16:24  <midnightmagic> hrm.. I like meetbot.
5362016-06-30T20:17:32  *** MarcoFalke has left #bitcoin-core-dev
5372016-06-30T20:17:47  <morcos> sipa: yes i'm happy to take another pass at keeping the cache warm.  but whats your current state of thinking with keeping the utxos by txid instead of by individual utxo?  we had discussed at one point changing that?
5382016-06-30T20:18:14  <sipa> i think we should switch to individual utxo
5392016-06-30T20:18:22  <sipa> but it's a pretty nontrivial change
5402016-06-30T20:18:27  <morcos> yeah...
5412016-06-30T20:18:35  <morcos> i wonder what the current overhead is
5422016-06-30T20:18:57  <sipa> the one pain point is storage of per-tx information (height and coinbaseness)
5432016-06-30T20:19:01  <sipa> and nversion
5442016-06-30T20:19:12  <sipa> copied into each utxo, or still have some per txid state
5452016-06-30T20:21:28  <morcos>  yeah maybe there is some hybrid that makes the most sense..   anyway, ok, just food for thought
5462016-06-30T20:22:59  <sipa> in the storage format that means refcounting per txid, though
5472016-06-30T20:23:04  <sipa> yuckness
5482016-06-30T20:23:31  <sipa> or a read after write to see if any entries remain, and if not, delete the txid data
5492016-06-30T20:24:16  <morcos> yeah, i was thinking more the latter, we kind of already do that right?
5502016-06-30T20:24:28  <morcos> at the disk level for pruning
5512016-06-30T20:24:43  <morcos> ugh sorry, bad choice of words, but think its called that in the code
5522016-06-30T20:26:53  <morcos> maybe you could keep a bit field of the spentness of various vout#s in the txid level state, so when its in memory, you know whether any uncached vout#s are still unspent.
5532016-06-30T20:44:09  *** spudowiar has joined #bitcoin-core-dev
5542016-06-30T20:53:34  *** spudowiar has quit IRC
5552016-06-30T20:55:43  *** droark has joined #bitcoin-core-dev
5562016-06-30T21:18:54  *** zooko has joined #bitcoin-core-dev
5572016-06-30T21:20:41  *** jannes has quit IRC
5582016-06-30T21:28:04  *** Prattler has joined #bitcoin-core-dev
5592016-06-30T21:29:06  *** Prattler has quit IRC
5602016-06-30T21:30:05  <gmaxwell> own't the key overhead make the dataset much larger? whats the average outputs per key in the database today?
5612016-06-30T21:32:59  *** Amnez777 has joined #bitcoin-core-dev
5622016-06-30T21:33:44  *** Amnez777- has quit IRC
5632016-06-30T21:36:14  *** jtimon has quit IRC
5642016-06-30T21:37:14  <luke-jr> I don't see why the new algorithm can't work with blockmaxsize etc?
5652016-06-30T21:37:48  <gmaxwell> because it will produce wrong results if blockmaxsize is the limited commodity.
5662016-06-30T21:38:15  <gmaxwell> wrong in the sense of not picking the optimal block subject to that constraint.
5672016-06-30T21:41:46  *** Prattler has joined #bitcoin-core-dev
5682016-06-30T21:45:37  *** bsm1175321 has quit IRC
5692016-06-30T21:45:38  *** face has quit IRC
5702016-06-30T21:45:38  *** Taek has quit IRC
5712016-06-30T21:47:13  <zooko> Hey Bitcoin core devs. Over in the Zcash project we occasionally do things which might be independently useful to Bitcoin core.
5722016-06-30T21:47:24  *** Chris_Stewart_5 has quit IRC
5732016-06-30T21:48:06  <zooko> One of those is a performance measurement of a transaction with the maximal number of inputs.
5742016-06-30T21:48:30  <zooko> We're currently talking about that test/measurement over in #zcash and Nathan mentioned that it might be of use to core.
5752016-06-30T21:56:41  *** frankenmint has joined #bitcoin-core-dev
5762016-06-30T21:59:22  *** instagibbs has quit IRC
5772016-06-30T22:01:03  *** instagibbs has joined #bitcoin-core-dev
5782016-06-30T22:02:02  <luke-jr> gmaxwell: if we're hoping to see that constraint unnecessary in the next year, I don't think we need it to be "ideal"; but if sdaftuar wants to support it better, that's fine with me too
5792016-06-30T22:02:42  *** frankenmint has quit IRC
5802016-06-30T22:03:23  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5812016-06-30T22:05:53  <gmaxwell> I think its fine if its not ideal. given the current climate we can expect people to just turn it as high as possible in any case.
5822016-06-30T22:06:00  <gmaxwell> just as they're doing with the current target.
5832016-06-30T22:08:22  *** BCBot has joined #bitcoin-core-dev
5842016-06-30T22:09:01  *** BCBot has quit IRC
5852016-06-30T22:09:18  *** BCBot has joined #bitcoin-core-dev
5862016-06-30T22:12:12  *** afk11 has quit IRC
5872016-06-30T22:12:27  *** belcher has quit IRC
5882016-06-30T22:13:36  <dgenr8> regarding gmaxwell statement on XT above https://github.com/bitcoinxt/bitcoinxt/issues/153#issuecomment-229793755
5892016-06-30T22:19:26  *** cryptapus has quit IRC
5902016-06-30T22:20:12  *** afk11 has joined #bitcoin-core-dev
5912016-06-30T22:20:12  *** afk11 has quit IRC
5922016-06-30T22:20:12  *** afk11 has joined #bitcoin-core-dev
5932016-06-30T22:22:03  *** belcher has joined #bitcoin-core-dev
5942016-06-30T22:22:12  *** pmienk has quit IRC
5952016-06-30T22:30:13  *** Guyver2 has quit IRC
5962016-06-30T22:31:41  *** BCBot_ has joined #bitcoin-core-dev
5972016-06-30T22:33:26  <gmaxwell> dgenr8: your intended behavior will partition the network and leave XT isolated.
5982016-06-30T22:34:34  *** BCBot_ has joined #bitcoin-core-dev
5992016-06-30T22:35:02  <gmaxwell> as your only connections from core nodes will be inbound and after segwit activates core will avoid making outbound connections to non-segwit enabled hosts; already that behavior is dangerous because there are relatively few hosts that it is willing to outbound connect to, making chance partitioning and vulnerability to sybil attacks worse.
6002016-06-30T22:36:57  *** BCBot_ has quit IRC
6012016-06-30T22:37:06  *** BCBot_ has joined #bitcoin-core-dev
6022016-06-30T22:37:17  *** pmienk has joined #bitcoin-core-dev
6032016-06-30T22:37:58  *** BCBot_ has quit IRC
6042016-06-30T22:41:15  *** paveljanik has quit IRC
6052016-06-30T22:41:28  *** BCBot_ has joined #bitcoin-core-dev
6062016-06-30T22:43:43  *** BCBot_ has quit IRC
6072016-06-30T22:43:53  *** BCBot_ has joined #bitcoin-core-dev
6082016-06-30T22:45:43  *** BCBot_ has joined #bitcoin-core-dev
6092016-06-30T22:46:32  *** Prattler has quit IRC
6102016-06-30T22:46:45  *** Prattler has joined #bitcoin-core-dev
6112016-06-30T22:46:47  *** BCBot_ has quit IRC
6122016-06-30T22:48:53  *** Amnez777 has quit IRC
6132016-06-30T22:48:58  *** BCBot has quit IRC
6142016-06-30T22:50:09  *** justanother|NYY is now known as justanotheruser
6152016-06-30T22:50:24  <sipa> gmaxwell: that's not the reason. the algorithm needs per-package byte sizes, which are not counted currently
6162016-06-30T22:50:33  <sipa> gmaxwell: it's not just that it's suboptinal
6172016-06-30T22:50:51  <sipa> without adding package-accounted sizes, it just cannot work
6182016-06-30T22:51:21  *** Amnez777 has joined #bitcoin-core-dev
6192016-06-30T22:51:27  <gmaxwell> sipa: hm why doesn't it just construct assuming that there is no size limit then truncate when the block is full.
6202016-06-30T22:51:49  <gmaxwell> [pp.getblock(pp.getblockhash(x))['size'] for x in range(353213,417725)]  ... man rpc from python is slow, thats running at 9 blocks per second and is going to take two hours to finish.
6212016-06-30T22:57:32  *** ybit has quit IRC
6222016-06-30T22:57:44  *** ybit has joined #bitcoin-core-dev
6232016-06-30T23:00:28  *** kanzure has quit IRC
6242016-06-30T23:03:37  *** justanotheruser is now known as justanotherusr
6252016-06-30T23:04:48  *** justanotherusr is now known as justanotheruser
6262016-06-30T23:05:34  *** Chris_Stewart_5 has quit IRC
6272016-06-30T23:09:00  *** Chris_Stewart_5 has joined #bitcoin-core-dev
6282016-06-30T23:09:33  *** ybit has quit IRC
6292016-06-30T23:09:43  *** ybit has joined #bitcoin-core-dev
6302016-06-30T23:14:47  *** spudowiar has joined #bitcoin-core-dev
6312016-06-30T23:19:03  *** ybit has quit IRC
6322016-06-30T23:28:40  *** Chris_Stewart_5 has quit IRC
6332016-06-30T23:29:29  *** ybit has joined #bitcoin-core-dev
6342016-06-30T23:31:37  *** kanzure has joined #bitcoin-core-dev
6352016-06-30T23:34:28  *** ybit has quit IRC
6362016-06-30T23:39:48  *** ybit has joined #bitcoin-core-dev
6372016-06-30T23:41:51  *** kanzure has quit IRC
6382016-06-30T23:42:30  *** kanzure has joined #bitcoin-core-dev
6392016-06-30T23:42:32  <sdaftuar> sipa: gmaxwell: i think the fix is straightforward, please see https://github.com/bitcoin/bitcoin/pull/8295/commits/f15c2cde455174c7c899833fd5792460ed49a472
6402016-06-30T23:42:55  <sdaftuar> i guess i didn't test it very well though!
6412016-06-30T23:43:15  <sdaftuar> oops, i should go back and do that more carefully
6422016-06-30T23:43:50  <sdaftuar> also, that silly function name gets improved in the next commit of the PR, which adds witness checking as well.
6432016-06-30T23:43:54  <sdaftuar> #8295
6442016-06-30T23:44:15  *** spudowiar has quit IRC
6452016-06-30T23:44:24  *** Chris_Stewart_5 has joined #bitcoin-core-dev
6462016-06-30T23:44:45  *** ybit has quit IRC
6472016-06-30T23:45:07  *** ybit has joined #bitcoin-core-dev
6482016-06-30T23:49:51  *** kanzure has quit IRC
6492016-06-30T23:50:24  *** ybit has quit IRC
6502016-06-30T23:51:26  *** kanzure has joined #bitcoin-core-dev
6512016-06-30T23:51:29  *** randy-waterhouse has joined #bitcoin-core-dev
6522016-06-30T23:51:31  *** ybit has joined #bitcoin-core-dev
6532016-06-30T23:53:58  *** zooko has quit IRC