12016-12-15T00:02:30  *** TomMc has quit IRC
  22016-12-15T00:03:02  *** Chris_Stewart_5 has quit IRC
  32016-12-15T00:20:49  *** kalle__ has joined #bitcoin-core-dev
  42016-12-15T00:21:58  *** kalle__ is now known as kallle
  52016-12-15T00:29:56  *** alpalp has joined #bitcoin-core-dev
  62016-12-15T00:29:56  *** alpalp has joined #bitcoin-core-dev
  72016-12-15T00:34:25  *** dermoth_ has joined #bitcoin-core-dev
  82016-12-15T00:34:51  *** dermoth has quit IRC
  92016-12-15T00:34:53  *** dermoth_ is now known as dermoth
 102016-12-15T00:50:40  *** _biO_ has quit IRC
 112016-12-15T01:05:18  *** wasi has joined #bitcoin-core-dev
 122016-12-15T01:17:09  *** MarcoFalke has quit IRC
 132016-12-15T01:29:53  *** TomMc has joined #bitcoin-core-dev
 142016-12-15T01:38:06  *** calcyss has joined #bitcoin-core-dev
 152016-12-15T01:54:58  *** abpa has quit IRC
 162016-12-15T01:57:22  *** Ylbam has quit IRC
 172016-12-15T02:00:21  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 182016-12-15T02:03:40  *** calcyss has quit IRC
 192016-12-15T02:14:26  <bitcoin-git> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/b68685a16a81...b83264d9c7a8
 202016-12-15T02:14:27  <bitcoin-git> bitcoin/master c9e69fb Jeremy Rubin: Add CuckooCache implementation and replace the sigcache map_type with it...
 212016-12-15T02:14:27  <bitcoin-git> bitcoin/master 67dac4e Jeremy Rubin: Add unit tests for the CuckooCache...
 222016-12-15T02:14:28  <bitcoin-git> bitcoin/master b83264d Pieter Wuille: Merge #8895: Better SigCache Implementation...
 232016-12-15T02:20:21  *** windsok has quit IRC
 242016-12-15T02:26:10  *** TomMc has quit IRC
 252016-12-15T02:36:55  *** windsok has joined #bitcoin-core-dev
 262016-12-15T02:44:37  *** Chris_Stewart_5 has quit IRC
 272016-12-15T02:55:41  *** alpalp has quit IRC
 282016-12-15T03:01:53  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 292016-12-15T03:03:09  *** abpa has joined #bitcoin-core-dev
 302016-12-15T03:04:08  *** d9b4bef9 has joined #bitcoin-core-dev
 312016-12-15T03:08:01  *** alpalp has joined #bitcoin-core-dev
 322016-12-15T03:08:01  *** alpalp has joined #bitcoin-core-dev
 332016-12-15T03:18:13  *** wvr has quit IRC
 342016-12-15T03:26:50  *** PRab has joined #bitcoin-core-dev
 352016-12-15T03:27:03  *** PRab_ has joined #bitcoin-core-dev
 362016-12-15T03:29:57  *** PRab_ has quit IRC
 372016-12-15T03:29:57  *** PRab has quit IRC
 382016-12-15T03:30:44  *** PRab has joined #bitcoin-core-dev
 392016-12-15T03:31:47  *** PRab has joined #bitcoin-core-dev
 402016-12-15T03:32:18  *** PRab_ has joined #bitcoin-core-dev
 412016-12-15T03:32:51  *** PRab has left #bitcoin-core-dev
 422016-12-15T03:34:03  *** PRab_ is now known as PRab
 432016-12-15T03:37:22  *** PRab has quit IRC
 442016-12-15T03:37:52  *** PRab has joined #bitcoin-core-dev
 452016-12-15T03:38:07  *** PRab_ has joined #bitcoin-core-dev
 462016-12-15T03:39:15  *** Chris_Stewart_5 has quit IRC
 472016-12-15T03:41:38  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 482016-12-15T03:48:56  *** mr_burdell has quit IRC
 492016-12-15T03:49:05  *** mr_burdell has joined #bitcoin-core-dev
 502016-12-15T04:08:22  <bitcoin-git> [bitcoin] rebroad closed pull request #9338: [wip] Stripe downloads to reduce stallers occuring (master...ReduceStalling) https://github.com/bitcoin/bitcoin/pull/9338
 512016-12-15T04:09:04  *** alpalp has quit IRC
 522016-12-15T04:17:22  *** mr_burdell has quit IRC
 532016-12-15T04:19:26  *** mr_burdell has joined #bitcoin-core-dev
 542016-12-15T04:29:50  <luke-jr> BIPs 2 and 123 are now Active
 552016-12-15T04:38:56  *** btcdrak has quit IRC
 562016-12-15T04:41:07  *** Alopex has quit IRC
 572016-12-15T04:42:12  *** Alopex has joined #bitcoin-core-dev
 582016-12-15T04:44:44  *** To7 has quit IRC
 592016-12-15T05:00:25  *** kadoban has quit IRC
 602016-12-15T05:15:06  *** Alopex has quit IRC
 612016-12-15T05:16:12  *** Alopex has joined #bitcoin-core-dev
 622016-12-15T05:22:02  *** Victorsueca has quit IRC
 632016-12-15T05:23:41  *** Victorsueca has joined #bitcoin-core-dev
 642016-12-15T05:28:06  *** Alopex has quit IRC
 652016-12-15T05:29:11  *** Alopex has joined #bitcoin-core-dev
 662016-12-15T05:40:22  *** Alopex has quit IRC
 672016-12-15T05:41:27  *** Alopex has joined #bitcoin-core-dev
 682016-12-15T05:53:07  *** Alopex has quit IRC
 692016-12-15T05:54:12  *** Alopex has joined #bitcoin-core-dev
 702016-12-15T06:16:23  *** Giszmo has quit IRC
 712016-12-15T06:32:21  *** Cory has quit IRC
 722016-12-15T06:37:20  *** windsok has quit IRC
 732016-12-15T06:50:23  *** snowden69 has quit IRC
 742016-12-15T06:52:58  *** btcdrak has joined #bitcoin-core-dev
 752016-12-15T06:54:12  *** snowden69 has joined #bitcoin-core-dev
 762016-12-15T07:00:18  *** dermoth has quit IRC
 772016-12-15T07:01:06  *** dermoth has joined #bitcoin-core-dev
 782016-12-15T07:03:17  *** Alopex has quit IRC
 792016-12-15T07:04:05  *** kallle has quit IRC
 802016-12-15T07:04:22  *** Alopex has joined #bitcoin-core-dev
 812016-12-15T07:05:16  *** kallle has joined #bitcoin-core-dev
 822016-12-15T07:11:17  *** windsok has joined #bitcoin-core-dev
 832016-12-15T07:22:50  *** jtimon has quit IRC
 842016-12-15T07:30:13  *** snowden69 has quit IRC
 852016-12-15T07:53:20  *** snowden69 has joined #bitcoin-core-dev
 862016-12-15T07:59:03  <jonasschnelli> <gmaxwell:#bitcoin-core-dev> jonasschnelli: want to go comment on http://bitcoin.stackexchange.com/questions/50125/failing-to-build-bitcoin-core-v0-13-1-on-debian-stretch and point out its fixed in master
 872016-12-15T07:59:05  <jonasschnelli> ^ done
 882016-12-15T07:59:20  *** BashCo has quit IRC
 892016-12-15T08:11:31  *** Guyver2 has joined #bitcoin-core-dev
 902016-12-15T08:20:08  *** BashCo has joined #bitcoin-core-dev
 912016-12-15T08:27:17  *** Guyver2 has quit IRC
 922016-12-15T08:29:36  *** snowden69 has quit IRC
 932016-12-15T08:29:54  *** snowden69 has joined #bitcoin-core-dev
 942016-12-15T08:34:03  *** wvr has joined #bitcoin-core-dev
 952016-12-15T08:40:46  *** Alina-malina has quit IRC
 962016-12-15T08:45:03  *** LeMiner has joined #bitcoin-core-dev
 972016-12-15T09:12:05  *** Alina-malina has joined #bitcoin-core-dev
 982016-12-15T09:14:19  *** laurentmt has joined #bitcoin-core-dev
 992016-12-15T09:14:49  *** laurentmt has quit IRC
1002016-12-15T09:15:29  *** Alina-malina has quit IRC
1012016-12-15T09:15:29  *** Alina-malina has joined #bitcoin-core-dev
1022016-12-15T09:24:33  *** Lauda has quit IRC
1032016-12-15T09:25:55  *** Ylbam has joined #bitcoin-core-dev
1042016-12-15T09:37:12  *** PaulCapestany has quit IRC
1052016-12-15T09:38:31  *** abpa has quit IRC
1062016-12-15T09:46:47  *** Lauda has joined #bitcoin-core-dev
1072016-12-15T09:51:43  <gmaxwell> I triggered some kind of hang or deadlock today on master by running bitcoin-cli stop shortly after starting bitcoind but before it had come up.  Was in a rush to fix something else so I didn't attach a debugger before killing it.   Mentioning so that if someone else encounteres it, you're not imagining it.
1082016-12-15T09:51:58  <gmaxwell> will try to reproduce tomorrow.
1092016-12-15T09:52:37  *** PaulCapestany has joined #bitcoin-core-dev
1102016-12-15T10:05:31  <gmaxwell> [OT] I was really impressed by the technical accuracy of today's SMBC, then I saw it had a co-author.
1112016-12-15T10:09:08  *** sanada has quit IRC
1122016-12-15T10:17:43  *** Cory has joined #bitcoin-core-dev
1132016-12-15T10:19:38  *** cannon-c has joined #bitcoin-core-dev
1142016-12-15T10:34:22  *** windsok has quit IRC
1152016-12-15T10:41:05  *** Guest80396 has quit IRC
1162016-12-15T10:43:50  *** MarcoFalke has joined #bitcoin-core-dev
1172016-12-15T10:44:49  *** BashCo has quit IRC
1182016-12-15T10:45:34  *** BashCo has joined #bitcoin-core-dev
1192016-12-15T10:53:19  *** laurentmt has joined #bitcoin-core-dev
1202016-12-15T10:53:19  *** laurentmt has quit IRC
1212016-12-15T10:53:29  *** wvr has quit IRC
1222016-12-15T10:53:50  *** wvr has joined #bitcoin-core-dev
1232016-12-15T11:04:10  *** BashCo_ has joined #bitcoin-core-dev
1242016-12-15T11:06:54  *** BashCo has quit IRC
1252016-12-15T11:22:45  *** laurentmt has joined #bitcoin-core-dev
1262016-12-15T11:22:50  *** laurentmt has quit IRC
1272016-12-15T11:30:03  *** windsok has joined #bitcoin-core-dev
1282016-12-15T11:42:28  *** luke-jr has quit IRC
1292016-12-15T11:43:39  *** luke-jr has joined #bitcoin-core-dev
1302016-12-15T12:09:41  *** lightningbot has joined #bitcoin-core-dev
1312016-12-15T12:13:11  *** atroxes has joined #bitcoin-core-dev
1322016-12-15T12:40:24  *** Atomicat_ has joined #bitcoin-core-dev
1332016-12-15T12:42:06  *** Atomicat has quit IRC
1342016-12-15T12:42:14  *** Atomicat_ is now known as Atomicat
1352016-12-15T13:09:39  *** alpalp has joined #bitcoin-core-dev
1362016-12-15T13:09:40  *** alpalp has joined #bitcoin-core-dev
1372016-12-15T13:17:33  *** BashCo_ has quit IRC
1382016-12-15T13:20:00  *** BashCo has joined #bitcoin-core-dev
1392016-12-15T13:25:50  *** BashCo_ has joined #bitcoin-core-dev
1402016-12-15T13:27:45  *** snowden66 has joined #bitcoin-core-dev
1412016-12-15T13:29:22  *** Chris_Stewart_5 has quit IRC
1422016-12-15T13:29:26  *** BashCo has quit IRC
1432016-12-15T13:29:29  *** xiangfu has quit IRC
1442016-12-15T13:30:14  *** snowden69 has quit IRC
1452016-12-15T13:30:15  *** snowden66 has quit IRC
1462016-12-15T13:30:16  *** snowden24 has joined #bitcoin-core-dev
1472016-12-15T13:30:39  *** xiangfu has joined #bitcoin-core-dev
1482016-12-15T13:31:18  *** Sosumi has joined #bitcoin-core-dev
1492016-12-15T13:32:20  *** laurentmt has joined #bitcoin-core-dev
1502016-12-15T13:32:28  *** Giszmo has joined #bitcoin-core-dev
1512016-12-15T13:34:40  *** laurentmt has quit IRC
1522016-12-15T13:36:22  *** cannon-c has quit IRC
1532016-12-15T13:41:07  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1542016-12-15T13:42:35  *** snowden24 has quit IRC
1552016-12-15T13:45:02  *** windsok has quit IRC
1562016-12-15T14:00:05  *** shesek has joined #bitcoin-core-dev
1572016-12-15T14:03:58  *** mturquette has joined #bitcoin-core-dev
1582016-12-15T14:07:45  *** TomMc has joined #bitcoin-core-dev
1592016-12-15T14:10:56  *** Chris_Stewart_5 has quit IRC
1602016-12-15T14:25:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1612016-12-15T14:29:07  *** sanada has joined #bitcoin-core-dev
1622016-12-15T14:37:54  *** MarcoFalke has quit IRC
1632016-12-15T14:38:55  *** gjgkhfg has joined #bitcoin-core-dev
1642016-12-15T14:43:22  *** MykelSIlver has joined #bitcoin-core-dev
1652016-12-15T14:56:55  *** windsok has joined #bitcoin-core-dev
1662016-12-15T15:27:18  *** Chris_Stewart_5 has quit IRC
1672016-12-15T15:29:23  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1682016-12-15T15:58:34  *** abpa has joined #bitcoin-core-dev
1692016-12-15T15:58:58  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/b83264d9c7a8...5bc209c73fb6
1702016-12-15T15:58:59  <bitcoin-git> bitcoin/master a4153e2 Patrick Strateman: Simple fuzzing framework
1712016-12-15T15:59:00  <bitcoin-git> bitcoin/master 8b15434 Wladimir J. van der Laan: doc: Add bare-bones documentation for fuzzing
1722016-12-15T15:59:00  <bitcoin-git> bitcoin/master 5bc209c Wladimir J. van der Laan: Merge #9172: Resurrect pstratem's "Simple fuzzing framework"...
1732016-12-15T15:59:12  *** abpa has quit IRC
1742016-12-15T16:00:13  *** laurentmt has joined #bitcoin-core-dev
1752016-12-15T16:01:22  <btcdrak> wumpus: #7562 is ready for merge.
1762016-12-15T16:01:24  <gribble> https://github.com/bitcoin/bitcoin/issues/7562 | Bump transaction version default to 2 by btcdrak · Pull Request #7562 · bitcoin/bitcoin · GitHub
1772016-12-15T16:01:51  <bitcoin-git> [bitcoin] laanwj closed pull request #9340: [0.13] Update secp256k1 subtree (0.13...Mf1612-013subtree) https://github.com/bitcoin/bitcoin/pull/9340
1782016-12-15T16:01:54  <wumpus> btcdrak: thanks
1792016-12-15T16:03:38  *** xiangfu has quit IRC
1802016-12-15T16:03:51  <bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/5bc209c73fb6...1eef038b1bcf
1812016-12-15T16:03:52  <bitcoin-git> bitcoin/master 1f0ca1a BtcDrak: Bump default transaction version to 2
1822016-12-15T16:03:53  <bitcoin-git> bitcoin/master c5d746a Alex Morcos: tiny test fix for mempool_tests
1832016-12-15T16:03:53  <bitcoin-git> bitcoin/master dab207e BtcDrak: Preserve tx version=1 for certain tests...
1842016-12-15T16:04:56  *** laurentmt has quit IRC
1852016-12-15T16:05:03  *** xiangfu has joined #bitcoin-core-dev
1862016-12-15T16:07:19  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1eef038b1bcf...c6fd923886a3
1872016-12-15T16:07:19  <bitcoin-git> bitcoin/master d8c0b9f Russell Yanofsky: [qa] Add test for rescan feature of wallet key import RPCs...
1882016-12-15T16:07:20  <bitcoin-git> bitcoin/master c6fd923 Wladimir J. van der Laan: Merge #9331: [qa] Add test for rescan feature of wallet key import RPCs...
1892016-12-15T16:07:33  <bitcoin-git> [bitcoin] laanwj closed pull request #9331: [qa] Add test for rescan feature of wallet key import RPCs (master...pr/test-import-rescan) https://github.com/bitcoin/bitcoin/pull/9331
1902016-12-15T16:10:30  *** ryanofsky_ has left #bitcoin-core-dev
1912016-12-15T16:10:44  *** ryanofsky_ has joined #bitcoin-core-dev
1922016-12-15T16:14:07  *** MykelSIlver has quit IRC
1932016-12-15T16:14:35  *** Atomicat has quit IRC
1942016-12-15T16:16:35  *** Atomicat has joined #bitcoin-core-dev
1952016-12-15T16:29:26  *** laurentmt has joined #bitcoin-core-dev
1962016-12-15T16:31:01  *** laurentmt has quit IRC
1972016-12-15T16:37:20  *** LeMiner has quit IRC
1982016-12-15T16:39:01  *** TomMc has quit IRC
1992016-12-15T16:45:06  *** kadoban has joined #bitcoin-core-dev
2002016-12-15T16:47:35  <bitcoin-git> [bitcoin] laanwj opened pull request #9353: Add data() method to CDataStream (master...2016_12_cdatastream_data) https://github.com/bitcoin/bitcoin/pull/9353
2012016-12-15T16:49:24  *** abpa has joined #bitcoin-core-dev
2022016-12-15T16:54:33  *** laurentmt has joined #bitcoin-core-dev
2032016-12-15T16:55:51  *** jtimon has joined #bitcoin-core-dev
2042016-12-15T16:59:47  *** Guyver2 has joined #bitcoin-core-dev
2052016-12-15T17:01:58  *** laurentmt has quit IRC
2062016-12-15T17:03:14  *** windsok has quit IRC
2072016-12-15T17:05:34  *** wasi has quit IRC
2082016-12-15T17:08:23  *** wasi has joined #bitcoin-core-dev
2092016-12-15T17:11:44  *** laurentmt has joined #bitcoin-core-dev
2102016-12-15T17:18:33  *** laurentmt has quit IRC
2112016-12-15T17:19:27  <bitcoin-git> [bitcoin] sipa opened pull request #9354: Make fuzzer actually test CTxOutCompressor (master...fixfuzz) https://github.com/bitcoin/bitcoin/pull/9354
2122016-12-15T17:19:49  *** laurentmt has joined #bitcoin-core-dev
2132016-12-15T17:28:48  *** instagibbs has quit IRC
2142016-12-15T17:32:20  <bitcoin-git> [bitcoin] hoffmabc opened pull request #9355: Add welcome script to Bitcoin Ocho (master...master) https://github.com/bitcoin/bitcoin/pull/9355
2152016-12-15T17:33:00  <bitcoin-git> [bitcoin] hoffmabc closed pull request #9355: Add welcome script to Bitcoin Ocho (master...master) https://github.com/bitcoin/bitcoin/pull/9355
2162016-12-15T17:37:59  *** TomMc has joined #bitcoin-core-dev
2172016-12-15T17:38:26  *** instagibbs has joined #bitcoin-core-dev
2182016-12-15T17:46:02  *** windsok has joined #bitcoin-core-dev
2192016-12-15T17:46:06  *** laurentmt has quit IRC
2202016-12-15T17:50:28  *** windsok has quit IRC
2212016-12-15T17:51:02  <wumpus> and another user banned. Fuck off with the Ocho trolling.
2222016-12-15T17:52:03  *** windsok has joined #bitcoin-core-dev
2232016-12-15T17:53:47  <Lauda> Calm down wumpus :/
2242016-12-15T18:02:04  *** aalex has quit IRC
2252016-12-15T18:02:23  *** aalex has joined #bitcoin-core-dev
2262016-12-15T18:09:33  *** BashCo_ has quit IRC
2272016-12-15T18:19:18  <gmaxwell> wumpus: I believe 9313 may be ready for merge.
2282016-12-15T18:34:40  *** Chris_Stewart_5 has quit IRC
2292016-12-15T18:38:23  *** abpa has quit IRC
2302016-12-15T18:38:53  *** abpa has joined #bitcoin-core-dev
2312016-12-15T18:50:33  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c6fd923886a3...756374c522c4
2322016-12-15T18:50:33  <bitcoin-git> bitcoin/master 01fea7a Alex Morcos: If we don't allow free txs, always send a fee filter
2332016-12-15T18:50:34  <bitcoin-git> bitcoin/master 756374c Wladimir J. van der Laan: Merge #9313: If we don't allow free txs, always send a fee filter...
2342016-12-15T18:50:42  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2352016-12-15T18:50:52  <bitcoin-git> [bitcoin] laanwj closed pull request #9313: If we don't allow free txs, always send a fee filter (master...minminfee) https://github.com/bitcoin/bitcoin/pull/9313
2362016-12-15T18:55:14  * jtimon shamelssly reminds people of https://github.com/bitcoin/bitcoin/pull/8855 (part of https://github.com/bitcoin/bitcoin/pull/8994 which needs rebase again)
2372016-12-15T18:55:29  *** TomMc has quit IRC
2382016-12-15T19:00:25  <achow101> meeting?
2392016-12-15T19:00:42  <wumpus> #startmeeting
2402016-12-15T19:00:42  <lightningbot> Meeting started Thu Dec 15 19:00:42 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
2412016-12-15T19:00:42  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2422016-12-15T19:00:48  <jonasschnelli> here
2432016-12-15T19:00:52  <wumpus> proposed topics?
2442016-12-15T19:01:03  <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
2452016-12-15T19:01:08  <sdaftuar> hi
2462016-12-15T19:01:15  <wumpus> + jl2012
2472016-12-15T19:01:24  <gmaxwell> I was going to talk about some backlog but almost all of it got merged.
2482016-12-15T19:01:28  <instagibbs> oh right
2492016-12-15T19:01:31  * gmaxwell looks
2502016-12-15T19:01:44  <cfields> sick and useless, but here
2512016-12-15T19:02:28  <BlueMatt> cfields: ouch you got it now, too?
2522016-12-15T19:02:44  <cfields> BlueMatt: mine was nice enough to wait until the flight home :\
2532016-12-15T19:02:47  <wumpus> #9322 seems to need discussion
2542016-12-15T19:02:49  <gribble> https://github.com/bitcoin/bitcoin/issues/9322 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
2552016-12-15T19:02:58  <phantomcircuit> hi
2562016-12-15T19:03:01  <instagibbs> interesting issue
2572016-12-15T19:03:04  <wumpus> "Don't set unknown rpcserialversion"
2582016-12-15T19:03:12  <gmaxwell> #9322
2592016-12-15T19:03:14  <gribble> https://github.com/bitcoin/bitcoin/issues/9322 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
2602016-12-15T19:03:16  <BlueMatt> #9352 needs to move forward quickly for fibre/some current network issues
2612016-12-15T19:03:18  <gribble> https://github.com/bitcoin/bitcoin/issues/9352 | Attempt reconstruction from all compact block announcements by sdaftuar · Pull Request #9352 · bitcoin/bitcoin · GitHub
2622016-12-15T19:03:34  <wumpus> looks like there is disagreement about whether it should be done at all
2632016-12-15T19:04:04  <BlueMatt> wumpus: on which?
2642016-12-15T19:04:08  <wumpus> the one I just mentioned
2652016-12-15T19:05:08  *** MarcoFalke has joined #bitcoin-core-dev
2662016-12-15T19:05:11  <gmaxwell> I don't see the disagreement on 9332?
2672016-12-15T19:05:31  <instagibbs> luke-jr seemingly does
2682016-12-15T19:05:34  <wumpus> #9352 is 21 hours old, that could hardly be called backlog
2692016-12-15T19:05:36  <gribble> https://github.com/bitcoin/bitcoin/issues/9352 | Attempt reconstruction from all compact block announcements by sdaftuar · Pull Request #9352 · bitcoin/bitcoin · GitHub
2702016-12-15T19:05:41  <gmaxwell> The purpose of the change is to return an error if you ask for seralization version 9 on software that supports 0/1.
2712016-12-15T19:05:52  <BlueMatt> wumpus: didnt say backlog, said critical to address current ongoing network issues
2722016-12-15T19:05:54  <instagibbs> yes I think that's well understood
2732016-12-15T19:06:01  <gmaxwell> we can talk about that next.
2742016-12-15T19:06:18  <wumpus> would have been useful if luke-jr was here
2752016-12-15T19:06:32  <kanzure> hi. late.
2762016-12-15T19:06:37  <gmaxwell> oh missed his comment.
2772016-12-15T19:06:41  <phantomcircuit> #9332
2782016-12-15T19:06:43  <gribble> https://github.com/bitcoin/bitcoin/issues/9332 | Let wallet importmulti RPC accept labels for standard scriptPubKeys (on top of #9331) by ryanofsky · Pull Request #9332 · bitcoin/bitcoin · GitHub
2792016-12-15T19:07:10  <gmaxwell> I read luke's comment as saying he wanted a "max you support" version.
2802016-12-15T19:07:12  <phantomcircuit> you mean 9322?
2812016-12-15T19:07:42  <gmaxwell> and the response was that this was expected to be the default. Or at least thats my understanding.
2822016-12-15T19:07:46  <jtimon> is luke's comment related to https://github.com/bitcoin/bitcoin/pull/9322/files#r92147938 ?
2832016-12-15T19:07:46  *** To7 has joined #bitcoin-core-dev
2842016-12-15T19:08:19  <gmaxwell> I agree that being able to ask for a max possible is fine. (though 9999 isn't an especially good number for it. :P)
2852016-12-15T19:08:26  <instagibbs> I think #9262 is ready, but some disagreement over default value?
2862016-12-15T19:08:28  <gribble> https://github.com/bitcoin/bitcoin/issues/9262 | Prefer coins that have fewer ancestors, sanity check txn before ATMP by instagibbs · Pull Request #9262 · bitcoin/bitcoin · GitHub
2872016-12-15T19:08:39  <jtimon> do we have a topic?
2882016-12-15T19:08:46  <gmaxwell> jtimon: pr backlog
2892016-12-15T19:09:03  <wumpus> gmaxwell: in any case that doesn't have to be done in that pull, so we can just go ahead and merge it
2902016-12-15T19:09:16  <gmaxwell> ACK
2912016-12-15T19:10:01  <gmaxwell> in 9262 I don't believe this should default to on, for the same reason that spending unconfirmed coins is enabled by default.
2922016-12-15T19:10:27  <gmaxwell> The transactions will be queued in the wallet and periodically rebroadcast (due to other fixes) and go out once they're no longer overlimit.
2932016-12-15T19:10:43  <gmaxwell> the meat of the change was avoiding those cases (sometimes) when it could.
2942016-12-15T19:10:54  <cfields> #9289 is holding up the next round of changes, and I believe the linked issue is unrelated
2952016-12-15T19:10:56  <gribble> https://github.com/bitcoin/bitcoin/issues/9289 | net: drop boost::thread_group by theuni · Pull Request #9289 · bitcoin/bitcoin · GitHub
2962016-12-15T19:10:58  <instagibbs> with other fixes I'm completely comfortable with it off by default.
2972016-12-15T19:10:59  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/756374c522c4...c9e00591cd3f
2982016-12-15T19:11:00  <bitcoin-git> bitcoin/master 80d073c Pieter Wuille: Complain when unknown rpcserialversion is specified
2992016-12-15T19:11:00  <bitcoin-git> bitcoin/master fa615d3 MarcoFalke: [qa] Don't set unknown rpcserialversion
3002016-12-15T19:11:01  <bitcoin-git> bitcoin/master c9e0059 Wladimir J. van der Laan: Merge #9322: [qa] Don't set unknown rpcserialversion...
3012016-12-15T19:11:06  <cfields> (though maybe #9212 deserves a topic of its own)
3022016-12-15T19:11:07  <gribble> https://github.com/bitcoin/bitcoin/issues/9212 | Assertion failed: (nSendVersion != 0), function GetSendVersion, file ./net.h, line 775. · Issue #9212 · bitcoin/bitcoin · GitHub
3032016-12-15T19:11:12  <bitcoin-git> [bitcoin] laanwj closed pull request #9292: Complain when unknown rpcserialversion is specified (master...nofutureserial) https://github.com/bitcoin/bitcoin/pull/9292
3042016-12-15T19:11:53  <wumpus> cfields: agreed
3052016-12-15T19:12:58  <wumpus> ok, so #9262 off by default? should it still be backported then?
3062016-12-15T19:13:01  <gribble> https://github.com/bitcoin/bitcoin/issues/9262 | Prefer coins that have fewer ancestors, sanity check txn before ATMP by instagibbs · Pull Request #9262 · bitcoin/bitcoin · GitHub
3072016-12-15T19:13:14  <BlueMatt> cfields/wumpus: I think there is a fix commit for 9212 on the issue page at the bottom (I havent pr'ed yet because testing, but I think it'd work)
3082016-12-15T19:13:28  <gmaxwell> wumpus: yes, it should, the main thing in the change is that it avoids creating those poorly propagating transactions when it's possible.
3092016-12-15T19:13:42  <gmaxwell> (My opinion)
3102016-12-15T19:13:44  <sipa> wumpus: 9262 does 2 things 1) avoid long chains 2) pre-reject created wallet transactions that would exceed limits
3112016-12-15T19:13:51  <wumpus> gmaxwell: so it still does something even if it's disabled? okay
3122016-12-15T19:13:52  <sipa> wumpus: only 2 is optional
3132016-12-15T19:13:59  <wumpus> okay, right, that wasn't clear to me
3142016-12-15T19:14:19  <wumpus> BlueMatt: ok, will test that too
3152016-12-15T19:14:38  <instagibbs> yes so with default off it will simply try harder to pick coins that have shorter chain length
3162016-12-15T19:14:44  <instagibbs> rather than blindly
3172016-12-15T19:15:06  <sipa> which won't have an effect if you're always sending your full change
3182016-12-15T19:15:10  <sipa> but better is better
3192016-12-15T19:15:32  <cfields> BlueMatt: the reason I didn't do that is that it hides the previous behavior. The current asserts point out issues that need to be backported to 0.13
3202016-12-15T19:15:43  <cfields> (which admittedly should've been loud errors rather than asserts)
3212016-12-15T19:15:46  <gmaxwell> The original suggestion to create that change was (1) based on me actually encountering users that could have avoided the long chains.
3222016-12-15T19:16:02  *** MarcoFalke has quit IRC
3232016-12-15T19:16:11  <btcdrak> here
3242016-12-15T19:16:16  *** MarcoFalke has joined #bitcoin-core-dev
3252016-12-15T19:16:39  <wumpus> cfields: critical issues? or nothing that needs to hold up 0.13.2?
3262016-12-15T19:16:51  <gmaxwell> cfields: I had a node go down with-- we think-- that assert.. but can't tell where it was triggered from.
3272016-12-15T19:16:59  <sipa> cfields: do they really need backporting?
3282016-12-15T19:17:03  <cfields> wumpus: likely nothing critical, just possible data leaks
3292016-12-15T19:17:14  *** MarcoFalke has quit IRC
3302016-12-15T19:17:20  <wumpus> so if I get this right there are now two remaining unmerged pulls that need backport to 0.13.2 https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.13.2
3312016-12-15T19:17:22  *** MarcoFalke has joined #bitcoin-core-dev
3322016-12-15T19:17:26  <BlueMatt> cfields: why are those data leaks? anyway, I think we previously discussed not using nVersion != 0 for this check
3332016-12-15T19:17:26  *** gribble has quit IRC
3342016-12-15T19:17:38  <wumpus> just one I mean, the other *is* a a backport
3352016-12-15T19:17:41  <sipa> cfields: i'd say that such issues are things where we're certainly violating some of our own assumptions about how the p2p implementation works, but unlikely things that cause issues in interaction with other nodes
3362016-12-15T19:18:14  <cfields> any assert represents some case where we should be disconnected, but instead are still sending/responding.
3372016-12-15T19:18:25  <jtimon> #8855 could need rebase if there's new uses of Params(std::string), but if there are, they won't necessarily cause git conflicts
3382016-12-15T19:18:35  <BlueMatt> cfields: no, in this case it means we are sending, but havent yet sent version message
3392016-12-15T19:19:00  <gmaxwell> wumpus: I believe #9352 will be tagged for backport-- but it's too green to comment on it for the moment.
3402016-12-15T19:19:25  <wumpus> gmaxwell: that's too bad, I hoped we could finally get this over with this week
3412016-12-15T19:19:41  <cfields> BlueMatt: right, which specifically here means that we've refused the connection due to missing connection flags, but we're still sending/responding
3422016-12-15T19:19:47  <wumpus> gmaxwell: can't it wait for 0.13.3?
3432016-12-15T19:19:48  <sdaftuar> gmaxwell: should i go ahead and open the backport version of #9352?
3442016-12-15T19:19:58  <BlueMatt> wumpus: its a relatively simple patch, I'm hopeful we still can :)
3452016-12-15T19:20:09  <instagibbs> I will review asap
3462016-12-15T19:20:58  <cfields> BlueMatt: let's take it up after the meeting
3472016-12-15T19:21:03  <BlueMatt> cfields: sure
3482016-12-15T19:23:22  <wumpus> okay, any other topics to discuss?
3492016-12-15T19:23:32  <gmaxwell> sdaftuar: I think that would be useful.
3502016-12-15T19:23:49  <gmaxwell> wumpus: I really want 0.13.2 in RC ASAP. just have some specific conerns about needing that. We'll work through it.
3512016-12-15T19:24:12  <MarcoFalke> Could 9262 delay the rc?
3522016-12-15T19:24:20  <MarcoFalke> Is it well tested?
3532016-12-15T19:24:20  <jtimon> #8498 has been in the backlog for a while too (before that, #6445 was waiting for #6526/#6625/#6557 and friends, which were merged or closed long ago)
3542016-12-15T19:24:35  <gmaxwell> MarcoFalke: I've tested the heck out of it. dunno about others.
3552016-12-15T19:24:35  <MarcoFalke> (Note that it was not yet merged into master)
3562016-12-15T19:24:49  <MarcoFalke> (I haven't really looked at it)
3572016-12-15T19:24:56  <cfields> wumpus: regarding the assertion backports, nothing would be a regression from 0.13, so no need to delay, only a bonus if we get fixes in.
3582016-12-15T19:25:08  <btcdrak> sdaftuar: ack on backport #9352
3592016-12-15T19:25:28  <gmaxwell> MarcoFalke: it's the oldest of thes long-chain wallet fixes, just last to merge. as it had lots of oppturnities for shed painting and resulted in deciding to fix the other issues. :)
3602016-12-15T19:25:39  <wumpus> MarcoFalke: there was at least the discussion to disable the setting by default, but after that change I don't know why it should hold up anything
3612016-12-15T19:25:56  <wumpus> MarcoFalke: I don't think there's any critical concerns with it left
3622016-12-15T19:26:05  <gmaxwell> with the default off it only changes 'non-determinstic' behavior.
3632016-12-15T19:26:19  <gmaxwell> (selectcoins)
3642016-12-15T19:26:27  <sipa> the patch always had the setting off by default - i was the one arguing that it should be on by default instead (and it seems few people agree, fine)
3652016-12-15T19:26:36  <instagibbs> Hm? it was on before
3662016-12-15T19:26:42  <instagibbs> but this is pre other 2 changes
3672016-12-15T19:26:45  <sipa> oh? maybe before i looked at it :)
3682016-12-15T19:27:22  <wumpus> let's just settle on having it disabled by default in the initial merge and the backport, it can always be set to be enabled by default later...
3692016-12-15T19:27:24  <gmaxwell> sipa: you could argue for that in 0.14 later.
3702016-12-15T19:27:31  <gmaxwell> that.
3712016-12-15T19:27:32  <MarcoFalke> Agree wumpus
3722016-12-15T19:28:06  <wumpus> there's no need to fix everything in one pull, or one version for that matter, sometimes things are held up too long on minor discussion points
3732016-12-15T19:28:18  <instagibbs> better is better
3742016-12-15T19:28:22  <wumpus> right.
3752016-12-15T19:28:26  <MarcoFalke> morcos: gmaxwell: Do you have a strong opinion about the fLimitFree flag in the #9290
3762016-12-15T19:28:28  <MarcoFalke>  backport?
3772016-12-15T19:28:33  <gmaxwell> sometimes better is worse, there is totally like an essay on this. :P
3782016-12-15T19:28:47  <jtimon> sipa: just said fine on not having it on by default, didn't he?
3792016-12-15T19:29:15  <wumpus> yes he did, I meant in general
3802016-12-15T19:29:17  <sipa> jtimon: yes, i'm fine with it being off
3812016-12-15T19:29:54  <wumpus> MarcoFalke: ah yes that's an important point
3822016-12-15T19:29:55  <gmaxwell> MarcoFalke: Didn't see your question until now. will evaluate.
3832016-12-15T19:30:13  <wumpus> so this is about this comment: https://github.com/bitcoin/bitcoin/pull/9347#discussion_r92503011
3842016-12-15T19:30:22  <MarcoFalke> Imo it should not matter too much, but I'd rather have a second opinion
3852016-12-15T19:30:25  <bitcoin-git> [bitcoin] sdaftuar opened pull request #9357: [0.13 backport] Attempt reconstruction from all compact block announcements (0.13...backport-optimistic-cb) https://github.com/bitcoin/bitcoin/pull/9357
3862016-12-15T19:32:06  <MarcoFalke> I haven't checked if it caused issues with txes evicted from the pool due to low fee.
3872016-12-15T19:32:49  *** droark has joined #bitcoin-core-dev
3882016-12-15T19:32:53  <gmaxwell> I need to look into it carefully to make a decision on my view, not going to manage it during the meeting.
3892016-12-15T19:33:10  <MarcoFalke> ok, other topics?
3902016-12-15T19:34:02  <morcos> MarcoFalke: I hadn't seen the flimitFree thing before now, I'll take a look and get back to you after...  (same as gmaxwell)
3912016-12-15T19:34:18  <MarcoFalke> great, thx
3922016-12-15T19:34:31  <gmaxwell> We could talk about the compact block announcement stuff not the backports but the change; just so people know what the change is about.
3932016-12-15T19:34:54  <wumpus> #topic compact block announcement stuff
3942016-12-15T19:35:13  <gmaxwell> Right now, if someone sends us a header, we request a block and mark the block in flight. If a compact block (e.g. from a HB mode sender that sends unsolicited ones) shows up while we're waiting.. we just ignore it, instead of trying to reconstruct the block.
3952016-12-15T19:35:55  <gmaxwell> This means that if a peer is broken and slowly transmits or fails to reply, the HB mode will fail to work around it.
3962016-12-15T19:36:44  <gmaxwell> There is a deep rabbit hole we can go down towards optimal behavior, but what is proposed right now is a super minimal change where even if a block is in flight, we'll still see if we can recover the whole block from just the compact block. And if we can, we take it, and mark the block as complete.
3972016-12-15T19:37:16  <wumpus> sounds sensible
3982016-12-15T19:37:42  <gmaxwell> greater than 2/3rs of all blocks can be recovered from just the compact block (varries a lot based on miner/network behavior) so even this small improvement should be a pretty big help.
3992016-12-15T19:37:44  <wumpus> there seems some potential for race conditions though
4002016-12-15T19:37:46  <BlueMatt> this is especially important with prefill, where, if your peer upgrades to prefill txn in the announcement you can recover the block somtimes and recover from stalling without yourself upgrading
4012016-12-15T19:38:25  <wumpus> what if the compact block is reconstructed, and then the inflight block comes in?
4022016-12-15T19:38:39  <gmaxwell> wumpus: yes, though we don't count on the in-flight to protect against that, and if a full block shows up right now we'll accept it.
4032016-12-15T19:38:54  <sdaftuar> wumpus: should not be a problem.  there's generally no downside to receiving a block you already have.
4042016-12-15T19:38:58  <gmaxwell> wumpus: then its just like someone sending us an unsolicited full block, which we'll process if it's not best already.
4052016-12-15T19:38:59  *** Chris_Stewart_5 has quit IRC
4062016-12-15T19:40:02  <wumpus> sdaftuar: in general there's no downside, just thought it'd be a potential edge case, but if that's handled that's ok
4072016-12-15T19:40:06  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4082016-12-15T19:40:44  <gmaxwell> In any case, I think that summarizes where that is, I have several nodes testing live right now.. obviously will need review and testing.. but I just wanted everyone to know what was going on there.
4092016-12-15T19:42:16  *** chris2000 has joined #bitcoin-core-dev
4102016-12-15T19:42:24  *** chris2000 has left #bitcoin-core-dev
4112016-12-15T19:42:31  *** chris2000 has joined #bitcoin-core-dev
4122016-12-15T19:44:01  <jtimon> thanks, I assume more questions about this or other topics?
4132016-12-15T19:46:14  <achow101> when are we planning to start rc'ing for 0.13.2
4142016-12-15T19:47:22  <wumpus> dunno, yesterday if it was up to me :p
4152016-12-15T19:48:04  <wumpus> in any case there's still a few things open and you can help by testing and reviewing: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.13.2
4162016-12-15T19:49:40  <wumpus> bah looks like the build is broken
4172016-12-15T19:50:51  <wumpus> any other topics? if not we'll close the meeting early
4182016-12-15T19:51:14  <sipa> very short report: gmaxwell and i have been experimenting with a per-txout utxo cache approach
4192016-12-15T19:51:15  <gmaxwell> Close meeting early and make 0.13.2 great again ACK.
4202016-12-15T19:51:25  <sipa> so far results don't look too promising
4212016-12-15T19:51:27  <wumpus> heh
4222016-12-15T19:51:42  <morcos> sipa: yeah i haven't looked at that yet
4232016-12-15T19:51:46  <morcos> i'm surprised!
4242016-12-15T19:51:56  <morcos> i was super optimistic
4252016-12-15T19:52:00  <sipa> me too
4262016-12-15T19:52:05  <wumpus> sipa: so grouping the utxos per transaction turns out to have been a good optimization? I'm surprised too
4272016-12-15T19:52:12  <gmaxwell> Well when it's operating totally in memory it's 15% faster even though sipa has not exploited the new structure for better cache intelligence (so its still doing the same dumb flush thing). But when leveldb came into the picture it ate dirt.
4282016-12-15T19:52:21  <morcos> 15% is for babies
4292016-12-15T19:52:34  <instagibbs> what level are you on morcos :)
4302016-12-15T19:52:52  <sdaftuar> i'm going to give a cheers for the sigcache cuckoocache merge now!
4312016-12-15T19:53:05  <jtimon> mhm, haven't looked at the branch, are the utxo's catched per txout but stored per-tx?
4322016-12-15T19:53:23  <sipa> jtimon: both per txout
4332016-12-15T19:53:23  <gmaxwell> Assuming the issue isn't extra debugging sipa added, the downside is perhaps that it is just much harder on leveldb and writes a lot more traffic to the leveldb log.
4342016-12-15T19:53:24  <BlueMatt> gmaxwell: seems like something where you can per-utxo in memory and per-tx on disk?
4352016-12-15T19:53:46  <wumpus> BlueMatt: yes I was about to suggest that too
4362016-12-15T19:53:51  <gmaxwell> The real gains from the change would come from making the cache smarter, so I thought 15% was great news.. since that likely came from reduced malloc traffic.
4372016-12-15T19:53:52  <BlueMatt> i mean might lose all the performance on the boundary, but its worth a shot
4382016-12-15T19:54:01  <jtimon> sipa: thanks. mhmm, yeah, this is surprising then
4392016-12-15T19:54:05  <sipa> BlueMatt: that doesn't solve the O(n^2) issue with large transactions
4402016-12-15T19:54:10  <gmaxwell> BlueMatt: yes, I made that observation too.... but it means that read modify write cycles would be needed.
4412016-12-15T19:54:28  <wumpus> gmaxwell: yeah that would be bad...
4422016-12-15T19:54:48  <wumpus> lookups are slow, if you need read-modify-write cycles it's not going to help performance
4432016-12-15T19:54:55  <sipa> the O(n^2) issue is that a tx with many outputs on every spend needs to write n-i outputs to the database
4442016-12-15T19:55:19  <gmaxwell> wumpus: yes, though it might pay for itself by the cache being much more effective. I guess we won't know until after more testing.
4452016-12-15T19:55:19  <cfields> sdaftuar: +1. Still catching up, didn't see that got merged. Great to see :)
4462016-12-15T19:56:08  <gmaxwell> the other negative is that it looks like this change will require a chainstate reindex. making it compatible with undo files seems really hard.
4472016-12-15T19:56:44  <sipa> basically my reason for wanting per-txout cache is that the current behaviour may be good on average, but it's terrible for big transactions
4482016-12-15T19:56:48  <jtimon> maybe somehow writting txouts in batches could help? (thinking out loud, may be a stupid thought)
4492016-12-15T19:56:59  <wumpus> requiring everyone to do a chainstate reindex would be bad too :/
4502016-12-15T19:57:05  <sipa> jtimon: we're already batching _all_ writes from many blocks
4512016-12-15T19:57:37  <jtimon> sipa: I see, it was a stupid thought
4522016-12-15T19:57:47  <sipa> anyway, just reporting on an experiment - nothing more at this point
4532016-12-15T19:57:50  <morcos> gmaxwell: i'm not sure what you mean about making the cache smarter
4542016-12-15T19:58:02  <gmaxwell> wumpus: right now everyone's chainstate is corrupted... to at some point we'll need to do something about that.  (TXversions)
4552016-12-15T19:58:09  <wumpus> writes are pretty fast with leveldb, it's lookups/reads are slow, especially on slow disks
4562016-12-15T19:58:09  <sipa> morcos: not wiping the cache after a write
4572016-12-15T19:58:13  <morcos> in my view once its only keeping utxos that were actually accessed and not the rest that tagged along with the tx, then thats as smart as it gets
4582016-12-15T19:58:29  <Chris_Stewart_5> Are we thinking txs are going to become larger in terms of inputs/outputs as Bitcoin grows? UTXO size is constantly growing right?
4592016-12-15T19:58:34  <morcos> sipa: sure but you still have to do something when you hit memory limits
4602016-12-15T19:58:43  <sipa> Chris_Stewart_5: i wish it were not growing at all
4612016-12-15T19:59:01  <wumpus> batching writes more is not going to help, and batches are already huge in memory
4622016-12-15T19:59:02  <morcos> you can save the things that are in blocks from the top of your mempool, but thats really small... small enough that it can be done pretty effectively with the existing model
4632016-12-15T19:59:03  <sipa> Chris_Stewart_5: http://bitcoin.sipa.be/utxo_size.png
4642016-12-15T19:59:05  <gmaxwell> morcos: yes the right thing to do is to expire only the oldest entrties at that point. Which is much cleaner when there is no such thing as entry mutation.
4652016-12-15T19:59:12  <Chris_Stewart_5> I guess it is just interesting to hear the tidbit about terrible performance of large txs.
4662016-12-15T19:59:14  <wumpus> gmaxwell: requiring everyone to reindex at the same time is not an acceptable solution though :)
4672016-12-15T19:59:26  <morcos> ah, oldest, yes ok, but that requires extra state
4682016-12-15T19:59:30  <wumpus> gmaxwell: maybe it could support two database versions for a while
4692016-12-15T19:59:42  <sipa> Chris_Stewart_5: in general, we need to optimize worst-case performance, not average performance
4702016-12-15T19:59:44  <wumpus> gmaxwell: new reindexes/syncs would use the new format
4712016-12-15T20:00:01  <wumpus> in any acsae, thanks for trying this experiment
4722016-12-15T20:00:08  <sipa> Chris_Stewart_5: as a large difference between worst-case and average means we could be missing DoS opportunities where an attacker can force us into the worsr
4732016-12-15T20:00:10  <gmaxwell> wumpus: if it made it N fold faster, than reindex on a new version... might be something we could have happen. I think perhaps we'd want to finish your snapshooting work and other things at the same time. ... in any case it's just an expirement now.
4742016-12-15T20:00:11  *** gribble has joined #bitcoin-core-dev
4752016-12-15T20:00:16  <wumpus> even if it turns out it's not better it's good to know this for sure
4762016-12-15T20:00:37  <gmaxwell> it also has resulted in some other optimizations, e.g. the flushing optimization PR that we have right now.
4772016-12-15T20:00:41  <sipa> Chris_Stewart_5: but it's really sad when you need to decrease your average performance in order to improve the worst case... because people don't observe the worst case
4782016-12-15T20:00:51  <wumpus> gmaxwell: if it was possible to convert the old database to the new database without a reindex (e.g. just rewriting) then an upgrade process would be acceptable. But a full reindex? no
4792016-12-15T20:01:02  <gmaxwell> Good, the meeting has run over, so all is well with the world. :)
4802016-12-15T20:01:08  <wumpus> #endmeeting
4812016-12-15T20:01:08  <lightningbot> Meeting ended Thu Dec 15 20:01:08 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
4822016-12-15T20:01:08  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-15-19.00.html
4832016-12-15T20:01:08  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-15-19.00.txt
4842016-12-15T20:01:08  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-15-19.00.log.html
4852016-12-15T20:01:12  <sipa> wumpus: i believe it is convertible, but it's nontrivial
4862016-12-15T20:01:15  <gmaxwell> wumpus: that would be possible, though perhaps a lot of code.
4872016-12-15T20:01:34  <Chris_Stewart_5> sipa: Thanks for the food for thought. I appreciate the extra explanation :-)
4882016-12-15T20:01:51  <wumpus> gmaxwell: ah yes thanks for reminding me of the snapshotting
4892016-12-15T20:02:01  <sipa> the tx height/coinbase is currently only stored in the undo data for the last spend from one tx's outputs, and needs to be stored in all
4902016-12-15T20:02:45  <sipa> but that can be done by walking the undo data backwards (which is always possible, even in pruned mode), and building a temporary database with tx->metadata maps, and using that to rebuild the undo data in the new format
4912016-12-15T20:03:12  <jtimon> wumpus: what snapshotting?
4922016-12-15T20:03:35  <wumpus> jtimon: automatic utxo database backups
4932016-12-15T20:04:08  * jtimon nods
4942016-12-15T20:05:08  <gmaxwell> morcos: my thought was that with the per-utxo model we could simply have a list of keys as they're read into the cache... and then when the cach is full, pop from the beginning of the list and flush those entries... to take it back to 90% or something (whatever is big enough to have a reasonable batch size for leveldb).
4952016-12-15T20:05:13  <wumpus> sipa: btw I still get no results from "host seed.bitcoin.sipa.be"
4962016-12-15T20:05:39  <gmaxwell> Sipa noticed that right now we end up using somewhat less than twice our memory limit; the flush process copies the data being flushed.
4972016-12-15T20:05:59  <morcos> gmaxwell: wow, really... i didn't realize that
4982016-12-15T20:06:47  <morcos> sdaftuar also points out that just deleting spent entries will help
4992016-12-15T20:07:08  <gmaxwell> morcos: well their deletion needs to hit the disk if their creation ever did.
5002016-12-15T20:07:12  <morcos> i had observed that it wasn't THAT helpful, but that was with requiring the whole TX to be spent... should be a much bigger effect
5012016-12-15T20:07:33  <gmaxwell> oh yea, thats one of the benefits of the per txout model.
5022016-12-15T20:07:34  <morcos> yes, so on flush, you can keep everything that isn't spent and your memory usage may reduce non-trivially
5032016-12-15T20:09:08  <gmaxwell> in any case, because of that memory usage we should be limiting our leveldb batch sizes. I'm guessing there probably is no real performance benefit to a batch of 200MB (or 2000mb) over 20MB.
5042016-12-15T20:09:37  <sipa> the size of batches is determined by how much has changed
5052016-12-15T20:09:49  <morcos> yeah, thats what i was thinking a bit annoying to have to track that too
5062016-12-15T20:10:03  <sipa> unless we maintain multiple checkpoints in-memory, to know which entries combined form a consistent state, that's very hard to reduce
5072016-12-15T20:10:30  <sipa> multiple in-memory checkpoints also implies we can't do the fresh optimization until an entry is in no snapshot
5082016-12-15T20:10:32  <wumpus> that sounds overly complicated
5092016-12-15T20:10:35  <sipa> yes.
5102016-12-15T20:11:10  <morcos> gmaxwell: one advnatage of bigger batch sizes is the ability to delete fresh pruned entries...  you lose all your freshness after a flush
5112016-12-15T20:12:37  <gmaxwell> well, the alternative for memory usage is that we start making changes to the leveldb api so that it can do some kind of gather callback or something for the batch.
5122016-12-15T20:13:15  <sipa> yes.
5132016-12-15T20:13:25  <gmaxwell> (I'm not even sure if thats possible, but it looked like it with a quick glance at the leveldb code)
5142016-12-15T20:13:26  <sipa> we discovered that a leveldb write batch is a wrapped std::string
5152016-12-15T20:13:46  <sipa> which just gets writes and erased appended to in a binary format
5162016-12-15T20:14:09  <wumpus> optimizing leveldb's batch representation/scheduling would certainly be possible, yes
5172016-12-15T20:15:47  <wumpus> but in my experience it's reads / lookups that take lots of time, especially on slow disks, not so much writing, writing with leveldb is much faster than comparable databases such as lmdb
5182016-12-15T20:16:25  <sipa> well writing 2GB of modified utxo entries required 90s in gmaxwell's benchmarks
5192016-12-15T20:16:54  <gmaxwell> well it was 40s with master, 90s with the per-utxo.
5202016-12-15T20:17:04  <wumpus> but that's hardly realistic for normal usage
5212016-12-15T20:17:21  <wumpus> if you have a dbcache of gigabytes you hardly really need a database at all
5222016-12-15T20:18:50  <gmaxwell> wumpus: so right now our initial sync performance is really poor with the default cache. it takes 21076 seconds to chainstate reindex even with all signature checking disabled on a fast machine.  We often tell people to crank their dbcache to big numbers to make ibd take more acceptable time.
5232016-12-15T20:19:42  <wumpus> gmaxwell: but is that due to writing? as said, in my experience, it spends almost all the time connecting inputs - e.g. fetching and random lookups
5242016-12-15T20:19:55  <wumpus> it could be I just have very strange hardware of course
5252016-12-15T20:20:39  <gmaxwell> sorry, I thought you were saying that it wasn't realistic for people to run with a big dbcache; and I was just countering that running with a big dbcache is the only way to get ibd to run in a sane-ish amount of time. I guess I was on a tangent from your point.
5262016-12-15T20:24:45  <wumpus> right - maybe the best solution for small memory usage and large memory usage is completely different
5272016-12-15T20:26:47  <wumpus> another thing with writes is that things can be pipelined, as soon as the batch buffers have been filled it could be shipped off to a background thread doing the writing, there's no need to wait for it to continue
5282016-12-15T20:31:19  <gmaxwell> wumpus: yes. Indeed. perhaps a little tricky with consistency between the chainstate and the blockindex.
5292016-12-15T20:31:29  *** abpa has quit IRC
5302016-12-15T20:31:33  *** droark has quit IRC
5312016-12-15T20:40:30  <gmaxwell> ohh sipa's per utxo code had debugging code that was trashing performance, rebenchmarking is looking much more promising!
5322016-12-15T20:43:09  <sdaftuar> yay!
5332016-12-15T20:43:23  <sipa> (with large dbcache)
5342016-12-15T20:43:46  *** BashCo has joined #bitcoin-core-dev
5352016-12-15T20:44:26  <gmaxwell> Man.  Thomas Zander wrote some article attacking segwit today that says up front "Once a user gets a SegWit transaction, she will only be able to move that money forward in a SegWit wallet. So if a person doesn't upgrade they will eventually not be able to accept money from anyone." -- will there be no consequence in this ecosystem for this kind of incompetence or dishonesty?  damn.  It also rep
5362016-12-15T20:44:32  <gmaxwell> eats Jeff Garzik's two buckets lie.
5372016-12-15T20:44:35  <gmaxwell> https://bitcoinclassic.com/devel/FlexTrans-vs-SegWit.html
5382016-12-15T20:46:22  <gmaxwell> Also deceptively claims to make transactions smaller (actually-- it increases the amount of information in a transaction-- because it makes the field ordering non-normative--, making the smallest possible representation larger...)
5392016-12-15T20:51:40  <juscamarena> Just saw that. Was the site hacked? He can't really believe that?
5402016-12-15T20:52:13  <sipa> i'm sure he believes it
5412016-12-15T20:53:41  <gmaxwell> he's previously posted a number of absurd things, e.g. the posts claiming that BIP152 was going to "disrupt the network" and trying to get us to abort the 0.13 release.
5422016-12-15T20:59:56  <btcdrak> gmaxwell: what the heck? that's just ...
5432016-12-15T21:02:06  <juscamarena> Sigh. He might have gotten confused here: "When spending your bitcoins after the upgrade to segwit, you will still be able to pay the original type of Bitcoin addresses that start with a ‘1’ (a P2PKH address) as well as being able to pay other users of P2SH addresses."
5442016-12-15T21:02:27  <juscamarena> Thinking upgrade meant upgrading the wallet.
5452016-12-15T21:03:25  *** grubles_ is now known as grubles
5462016-12-15T21:03:27  <gmaxwell> I'm having a really hard time believing that he is actually this confused.
5472016-12-15T21:06:23  *** abpa has joined #bitcoin-core-dev
5482016-12-15T21:26:30  *** crescendo has joined #bitcoin-core-dev
5492016-12-15T21:28:32  *** Sosumi has quit IRC
5502016-12-15T21:33:52  *** laurentmt has joined #bitcoin-core-dev
5512016-12-15T21:36:14  <morcos> gmaxwell: just skimmed what he wrote.. i don't think hes confused.. (except about the 2 buckets crap, but you know "math is hard")
5522016-12-15T21:37:16  <morcos> i think he was just trying to make a point that i don't think really makes any sense, that people with segwit wallets would prefer to send to other segwit addresses
5532016-12-15T21:37:30  <morcos> well yes i guess maybe thats what you meant by confused, since there is no reason they would prefer that?
5542016-12-15T21:38:14  <gmaxwell> there is no reason they would prefer that.
5552016-12-15T21:38:21  *** laurentmt has quit IRC
5562016-12-15T21:38:22  <gmaxwell> Doesn't cost them any more or less.
5572016-12-15T21:38:33  <gmaxwell> it's indistinguishable to them.
5582016-12-15T21:39:09  <morcos> it seems maybe the text changed if yours was an actual quote
5592016-12-15T21:39:11  <gmaxwell> actually, since the only kind of address type right now used for segwit is p2sh-p2w* it is cryptographically indistinguishable.
5602016-12-15T21:39:22  <gmaxwell> morcos: my test was an actual quote.
5612016-12-15T21:39:24  <gmaxwell> er text.
5622016-12-15T21:39:34  <morcos> it still says this which is at best badly misleading
5632016-12-15T21:39:36  <morcos> "receiving a SegWit transaction requires a SegWit wallet which then will generate SegWit transactions forcing everyone around you to get one too."
5642016-12-15T21:40:06  <gmaxwell> that is absurdly untrue too.
5652016-12-15T21:41:14  <gmaxwell> amusingly one of the big reasons we didn't move foward with a new address type was specifically to avoid this class of misunderstanding.  (the other being that several people wanted time to establish a new base-32 based encoding with proper error detection)
5662016-12-15T21:44:07  <MarcoFalke> morcos: Motivated from the rpc test failure: Should the feefilter rounder not return a fee that is less (or equal to) the target fee?
5672016-12-15T21:44:28  <MarcoFalke> otherwise you might miss some tx if you "round up"
5682016-12-15T21:44:42  <morcos> MarcoFalke: which test failure?
5692016-12-15T21:44:50  <MarcoFalke> fundrawtx
5702016-12-15T21:45:02  <MarcoFalke> Just a sync mempool issue due to feefilter, I guess
5712016-12-15T21:45:12  <morcos> i mean is there a link to what you are talking about
5722016-12-15T21:45:15  <MarcoFalke> #9313
5732016-12-15T21:45:17  <gribble> https://github.com/bitcoin/bitcoin/issues/9313 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
5742016-12-15T21:45:51  <MarcoFalke> If you run fundrawtransaciton on master it will fail randomly
5752016-12-15T21:46:00  <morcos> i'm not following... ok, thats what i was wondering
5762016-12-15T21:46:03  <morcos> really?
5772016-12-15T21:46:13  <MarcoFalke> Likely due to current choice of the feefilter
5782016-12-15T21:46:29  <MarcoFalke> It becomes visible when the transaction pays a fee close to the minrelayfee
5792016-12-15T21:46:50  <MarcoFalke> your feefilter will be maybe minrelaytxfee+x, so you never see the tx
5802016-12-15T21:46:59  <morcos> yeah i guess if you tried to pay exactly the minrelayfee it might not work
5812016-12-15T21:47:52  <MarcoFalke> Would it make sense to always send feefilters that are less than the currentFeeFilter?
5822016-12-15T21:47:57  <morcos> the variance was put in there to slightly obscure the exact state of your mempool..  but ehh, i'm not sure its worth the effort
5832016-12-15T21:48:30  <MarcoFalke> You can keep the variance
5842016-12-15T21:48:35  <morcos> realistically i doubt it would be a problem except in tests..
5852016-12-15T21:48:53  <MarcoFalke> Sure, on current main net
5862016-12-15T21:49:09  <MarcoFalke> with default minrelaytxfee
5872016-12-15T21:49:25  <morcos> i mean its been like that since it came out, the only difference is it happens now before your mempool gets full
5882016-12-15T21:49:34  <MarcoFalke> Right
5892016-12-15T21:50:23  <morcos> i don't feel strongly...
5902016-12-15T21:51:59  <MarcoFalke> As we send a feefilter now by default for all connections, it might not be too much wasted bandwith if we received some minrelaytxfee-dust txs
5912016-12-15T21:52:00  <gmaxwell> I think it's okay to leak that you're at the floor. e.g. apply the max after the variance.
5922016-12-15T21:55:24  <MarcoFalke> In which case your node is identifiable if you set a non-default value for the relay fee, no?
5932016-12-15T21:56:54  <gmaxwell> it's identifyable by behavior in that case, regardless.
5942016-12-15T22:08:52  *** Guyver2 has quit IRC
5952016-12-15T22:13:06  <morcos> MarcoFalke: yeah the floor is a separate issue.  we already send under the floor all the time anyway... i think that could be a special case perhaps.
5962016-12-15T22:13:55  <morcos> i'm just not sure how much any of this is worth it.  to make sure the tests work at exactly minrelaytxfee, need to check all the < vs <='s as well
5972016-12-15T22:14:12  *** Taek has quit IRC
5982016-12-15T22:16:27  *** Chris_Stewart_5 has quit IRC
5992016-12-15T22:19:01  *** Taek has joined #bitcoin-core-dev
6002016-12-15T22:28:03  *** gjgkhfg has quit IRC
6012016-12-15T22:31:28  *** abpa has quit IRC
6022016-12-15T22:32:37  *** Chris_Stewart_5 has joined #bitcoin-core-dev
6032016-12-15T23:02:58  *** Chris_Stewart_5 has quit IRC
6042016-12-15T23:04:10  *** Chris_Stewart_5 has joined #bitcoin-core-dev
6052016-12-15T23:07:06  <luke-jr> instagibbs: more of a suggestion than disagreement re 9322
6062016-12-15T23:28:43  *** wasi has quit IRC
6072016-12-15T23:29:41  *** Chris_Stewart_5 has quit IRC
6082016-12-15T23:34:23  *** JackH has quit IRC
6092016-12-15T23:36:57  *** MarcoFalke has left #bitcoin-core-dev
6102016-12-15T23:48:40  *** Chris_Stewart_5 has joined #bitcoin-core-dev