12016-06-23T00:00:35  *** isis has quit IRC
  22016-06-23T00:03:02  *** isis has joined #bitcoin-core-dev
  32016-06-23T00:25:52  *** raedah has quit IRC
  42016-06-23T00:26:58  *** raedah has joined #bitcoin-core-dev
  52016-06-23T00:35:04  *** Chris_Stewart_5 has quit IRC
  62016-06-23T00:42:38  *** xiangfu has quit IRC
  72016-06-23T00:48:43  *** belcher has quit IRC
  82016-06-23T00:54:16  *** Lauda has quit IRC
  92016-06-23T00:54:31  *** Lauda has joined #bitcoin-core-dev
 102016-06-23T00:55:00  *** Taek has quit IRC
 112016-06-23T00:55:01  *** nsh has quit IRC
 122016-06-23T00:55:44  *** Ylbam has quit IRC
 132016-06-23T00:57:28  *** Taek has joined #bitcoin-core-dev
 142016-06-23T01:10:14  *** nsh has joined #bitcoin-core-dev
 152016-06-23T01:10:44  *** justanotheruser has quit IRC
 162016-06-23T01:17:32  *** fengling has joined #bitcoin-core-dev
 172016-06-23T01:19:31  *** justanotheruser has joined #bitcoin-core-dev
 182016-06-23T01:27:54  *** zooko has quit IRC
 192016-06-23T02:05:09  *** ClockCat has quit IRC
 202016-06-23T02:10:54  *** rallat has joined #bitcoin-core-dev
 212016-06-23T02:11:46  *** rallat has quit IRC
 222016-06-23T02:35:31  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 232016-06-23T02:43:40  *** hsmiths has quit IRC
 242016-06-23T02:45:45  <GitHub58> [bitcoin] dcousens opened pull request #8244: remove unnecessary LOCK(cs_main) (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8244
 252016-06-23T02:46:24  *** dcousens has joined #bitcoin-core-dev
 262016-06-23T02:46:36  <dcousens> uh, I probably meant to ask about https://github.com/bitcoin/bitcoin/pull/8244 here, not #bitcoin-dev
 272016-06-23T02:49:31  *** hsmiths has joined #bitcoin-core-dev
 282016-06-23T02:55:06  *** afk11 has quit IRC
 292016-06-23T02:56:04  *** Chris_Stewart_5 has quit IRC
 302016-06-23T03:02:07  *** raedah has quit IRC
 312016-06-23T03:03:30  *** raedah has joined #bitcoin-core-dev
 322016-06-23T03:28:40  *** TomMc has quit IRC
 332016-06-23T03:32:15  *** TomMc has joined #bitcoin-core-dev
 342016-06-23T03:40:30  *** TomMc has quit IRC
 352016-06-23T03:42:08  *** raedah has quit IRC
 362016-06-23T03:42:53  *** raedah has joined #bitcoin-core-dev
 372016-06-23T03:53:41  *** TomMc has joined #bitcoin-core-dev
 382016-06-23T04:14:33  *** TomMc has quit IRC
 392016-06-23T04:19:46  *** ClockCat has joined #bitcoin-core-dev
 402016-06-23T04:27:43  *** dcousens has quit IRC
 412016-06-23T04:28:01  *** dcousens has joined #bitcoin-core-dev
 422016-06-23T04:48:20  *** dcousens has quit IRC
 432016-06-23T04:54:18  *** zooko has joined #bitcoin-core-dev
 442016-06-23T05:00:06  *** fengling has quit IRC
 452016-06-23T05:01:09  *** kitty_ has joined #bitcoin-core-dev
 462016-06-23T05:01:20  <kitty_> Hi I need help please
 472016-06-23T05:01:35  <kitty_> Does anyone here know how to contact the bitcoin core wallet support team
 482016-06-23T05:03:40  <kitty_> Is there a support team for bitcoin core wallet
 492016-06-23T05:17:52  <kitty_> is anyone here
 502016-06-23T05:29:37  *** btcdrak has quit IRC
 512016-06-23T05:33:02  *** fengling has joined #bitcoin-core-dev
 522016-06-23T05:35:53  *** Ylbam has joined #bitcoin-core-dev
 532016-06-23T05:36:53  *** CubicEarth has joined #bitcoin-core-dev
 542016-06-23T05:43:13  <kitty_> is there anyone here that helps with bitcoin core wallet
 552016-06-23T05:48:04  *** zooko has quit IRC
 562016-06-23T05:49:02  <jl2012> Just ask your question, or try #bitcoin
 572016-06-23T05:50:31  <kitty_> what do you mean #bitcoin
 582016-06-23T05:50:39  <kitty_> #bitcoin
 592016-06-23T06:23:22  *** raedah has quit IRC
 602016-06-23T06:24:17  *** raedah has joined #bitcoin-core-dev
 612016-06-23T06:27:14  *** btcdrak has joined #bitcoin-core-dev
 622016-06-23T06:35:07  *** CubicEarth has quit IRC
 632016-06-23T06:35:31  *** CubicEarth has joined #bitcoin-core-dev
 642016-06-23T06:41:46  *** CubicEarth has quit IRC
 652016-06-23T06:42:02  *** CubicEarth has joined #bitcoin-core-dev
 662016-06-23T06:53:05  *** kitty_ has quit IRC
 672016-06-23T06:55:06  *** [b__b] has quit IRC
 682016-06-23T06:55:33  *** [b__b] has joined #bitcoin-core-dev
 692016-06-23T07:06:48  *** coredump___ has joined #bitcoin-core-dev
 702016-06-23T07:10:09  *** coredump___ has quit IRC
 712016-06-23T07:11:39  *** Giszmo has quit IRC
 722016-06-23T07:33:36  *** shangzhou has joined #bitcoin-core-dev
 732016-06-23T07:35:18  <shangzhou>  means try another channel called #bitcoin this is #bitcoin-core-dev
 742016-06-23T07:39:27  *** PaulCape_ has joined #bitcoin-core-dev
 752016-06-23T07:42:37  *** PaulCapestany has quit IRC
 762016-06-23T08:07:50  *** CubicEarth has quit IRC
 772016-06-23T08:32:57  *** Guyver2 has joined #bitcoin-core-dev
 782016-06-23T08:33:28  *** MarcoFalke has joined #bitcoin-core-dev
 792016-06-23T08:37:37  *** Ginnarr has joined #bitcoin-core-dev
 802016-06-23T09:08:17  *** CubicEarth has joined #bitcoin-core-dev
 812016-06-23T09:14:32  *** Guyver2 has quit IRC
 822016-06-23T09:15:02  *** CubicEarth has quit IRC
 832016-06-23T09:18:41  *** assder has joined #bitcoin-core-dev
 842016-06-23T09:30:26  *** assder has quit IRC
 852016-06-23T09:37:25  *** pedrobranco has joined #bitcoin-core-dev
 862016-06-23T09:38:49  *** shangzhou has quit IRC
 872016-06-23T10:11:09  *** Guyver2 has joined #bitcoin-core-dev
 882016-06-23T10:44:18  *** jtimon has joined #bitcoin-core-dev
 892016-06-23T10:50:56  <GitHub7> [bitcoin] laanwj opened pull request #8246: trivial: capitalize BIP32 in option help (master...2016_06_bip32_uppercase) https://github.com/bitcoin/bitcoin/pull/8246
 902016-06-23T11:02:38  <GitHub70> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9f1807af2422...147a7b6726d3
 912016-06-23T11:02:39  <GitHub70> bitcoin/master a1c92c2 Wladimir J. van der Laan: trivial: capitalize BIP32 in option help...
 922016-06-23T11:02:39  <GitHub70> bitcoin/master 147a7b6 Wladimir J. van der Laan: Merge #8246: trivial: capitalize BIP32 in option help...
 932016-06-23T11:02:48  <GitHub103> [bitcoin] laanwj closed pull request #8246: trivial: capitalize BIP32 in option help (master...2016_06_bip32_uppercase) https://github.com/bitcoin/bitcoin/pull/8246
 942016-06-23T11:05:01  <GitHub5> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/147a7b6726d3...08338942b50f
 952016-06-23T11:05:02  <GitHub5> bitcoin/master d80efec Peter Todd: Update petertodd's testnet seed...
 962016-06-23T11:05:02  <GitHub5> bitcoin/master 0833894 Wladimir J. van der Laan: Merge #8204: Update petertodd's testnet seed...
 972016-06-23T11:05:11  <GitHub150> [bitcoin] laanwj closed pull request #8204: Update petertodd's testnet seed (master...2016-06-15-update-tbtc-seed) https://github.com/bitcoin/bitcoin/pull/8204
 982016-06-23T11:12:06  *** CubicEarth has joined #bitcoin-core-dev
 992016-06-23T11:15:21  *** robs has quit IRC
1002016-06-23T11:17:03  *** CubicEarth has quit IRC
1012016-06-23T11:20:04  *** Ginnarr has quit IRC
1022016-06-23T11:28:47  *** cryptapus_ has joined #bitcoin-core-dev
1032016-06-23T11:32:36  *** cryptapus_ is now known as cryptapus
1042016-06-23T11:46:06  *** fengling has quit IRC
1052016-06-23T12:08:10  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1062016-06-23T12:12:45  *** CubicEarth has joined #bitcoin-core-dev
1072016-06-23T12:17:11  *** CubicEarth has quit IRC
1082016-06-23T12:18:43  *** Chris_Stewart_5 has quit IRC
1092016-06-23T12:35:38  *** pedrobranco has quit IRC
1102016-06-23T12:43:09  *** fengling has joined #bitcoin-core-dev
1112016-06-23T12:47:26  *** fengling has quit IRC
1122016-06-23T13:09:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1132016-06-23T13:13:32  *** CubicEarth has joined #bitcoin-core-dev
1142016-06-23T13:18:28  *** CubicEarth has quit IRC
1152016-06-23T13:20:48  *** pedrobranco has joined #bitcoin-core-dev
1162016-06-23T13:41:36  *** cjcj has joined #bitcoin-core-dev
1172016-06-23T13:43:52  *** fengling has joined #bitcoin-core-dev
1182016-06-23T13:45:09  *** xiangfu has joined #bitcoin-core-dev
1192016-06-23T13:45:16  <GitHub21> [bitcoin] sipa opened pull request #8247: Mark my dnsseed as supporting filtering (master...newseed) https://github.com/bitcoin/bitcoin/pull/8247
1202016-06-23T13:48:06  *** fengling has quit IRC
1212016-06-23T13:56:28  *** Chris_Stewart_5 has quit IRC
1222016-06-23T14:12:24  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1232016-06-23T14:14:14  *** CubicEarth has joined #bitcoin-core-dev
1242016-06-23T14:18:50  *** CubicEarth has quit IRC
1252016-06-23T14:21:46  *** TomMc has joined #bitcoin-core-dev
1262016-06-23T14:23:15  *** raedah has quit IRC
1272016-06-23T14:24:08  *** raedah has joined #bitcoin-core-dev
1282016-06-23T14:26:26  *** Giszmo has joined #bitcoin-core-dev
1292016-06-23T14:31:22  *** TomMc has quit IRC
1302016-06-23T14:44:37  *** fengling has joined #bitcoin-core-dev
1312016-06-23T14:46:09  *** Greybits has joined #bitcoin-core-dev
1322016-06-23T14:48:46  *** fengling has quit IRC
1332016-06-23T14:50:22  *** MCCCS has joined #bitcoin-core-dev
1342016-06-23T14:50:48  *** MCCCS has quit IRC
1352016-06-23T14:57:52  <GitHub49> [bitcoin] laanwj opened pull request #8249: Enable (and check for) 64-bit ASLR on Windows (master...2016_06_windows64_security) https://github.com/bitcoin/bitcoin/pull/8249
1362016-06-23T15:15:00  *** CubicEarth has joined #bitcoin-core-dev
1372016-06-23T15:19:33  *** CubicEarth has quit IRC
1382016-06-23T15:29:55  *** xiangfu has quit IRC
1392016-06-23T15:36:34  *** xiangfu has joined #bitcoin-core-dev
1402016-06-23T15:45:23  *** fengling has joined #bitcoin-core-dev
1412016-06-23T15:49:26  *** fengling has quit IRC
1422016-06-23T15:53:34  *** xiangfu has quit IRC
1432016-06-23T16:06:50  *** laurentmt has joined #bitcoin-core-dev
1442016-06-23T16:08:19  *** laurentmt has quit IRC
1452016-06-23T16:15:42  *** CubicEarth has joined #bitcoin-core-dev
1462016-06-23T16:20:17  *** CubicEarth has quit IRC
1472016-06-23T16:36:38  *** kadoban has joined #bitcoin-core-dev
1482016-06-23T16:50:05  *** pedrobranco has quit IRC
1492016-06-23T16:50:23  *** pedrobranco has joined #bitcoin-core-dev
1502016-06-23T17:00:32  *** Chris_Stewart_5 has quit IRC
1512016-06-23T17:03:50  *** pedrobranco has quit IRC
1522016-06-23T17:04:18  *** pedrobranco has joined #bitcoin-core-dev
1532016-06-23T17:07:43  *** Greybits has quit IRC
1542016-06-23T17:16:30  *** CubicEarth has joined #bitcoin-core-dev
1552016-06-23T17:21:13  *** CubicEarth has quit IRC
1562016-06-23T17:26:36  *** CubicEarth has joined #bitcoin-core-dev
1572016-06-23T17:43:21  *** MarcoFalke has left #bitcoin-core-dev
1582016-06-23T17:46:51  *** fengling has joined #bitcoin-core-dev
1592016-06-23T17:48:15  *** jtimon has quit IRC
1602016-06-23T17:51:06  *** fengling has quit IRC
1612016-06-23T18:04:15  *** jtimon has joined #bitcoin-core-dev
1622016-06-23T18:07:58  *** spudowiar1 has joined #bitcoin-core-dev
1632016-06-23T18:10:01  *** spudowiar1 has quit IRC
1642016-06-23T18:21:40  *** pedrobranco has quit IRC
1652016-06-23T18:21:53  *** pedrobranco has joined #bitcoin-core-dev
1662016-06-23T18:26:42  *** pedrobranco has quit IRC
1672016-06-23T18:26:49  *** kadoban has quit IRC
1682016-06-23T18:37:12  *** jl2012 has quit IRC
1692016-06-23T18:37:34  *** jl2012 has joined #bitcoin-core-dev
1702016-06-23T18:40:19  *** pedrobranco has joined #bitcoin-core-dev
1712016-06-23T18:44:49  *** pedrobranco has quit IRC
1722016-06-23T18:46:00  *** jcorgan has joined #bitcoin-core-dev
1732016-06-23T19:00:37  <wumpus> meeting time?
1742016-06-23T19:00:42  *** CubicEarth has quit IRC
1752016-06-23T19:01:10  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1762016-06-23T19:02:26  <sipa> present
1772016-06-23T19:02:31  <gmaxwell> past?
1782016-06-23T19:02:40  <wumpus> #startmeeting
1792016-06-23T19:02:40  <lightningbot> Meeting started Thu Jun 23 19:02:40 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
1802016-06-23T19:02:40  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
1812016-06-23T19:03:05  <wumpus> any proposed topics?
1822016-06-23T19:04:01  <wumpus> I think https://github.com/bitcoin/bitcoin/issues/8245 needs discussion, whether reindex/verification slowed down
1832016-06-23T19:04:04  <gmaxwell> sdaftuar: sipa: phantomcircuit: jonasschnelli: MarcoFalke: jtimon: phantomcircuit: instagibbs: petertodd: morcos:
1842016-06-23T19:04:08  <sipa> ack topic
1852016-06-23T19:04:11  <gmaxwell> ack.
1862016-06-23T19:04:41  <jtimon> I missed a couple of meetings and I have some questions about merging segwit and 0.13 feature freeze, but maybe that can wait for after the meeting
1872016-06-23T19:04:46  <wumpus> #topic perceived validation slowdowns
1882016-06-23T19:04:58  <sipa> i noticed very slow chainstate writes (close to a minute, even though the chainstate is only 53 MB)
1892016-06-23T19:05:03  <gmaxwell> I was just going to go try reindexes with 0.12.1 and master on two hosts, to see if its a regression.  Even if it is not, it's absurdly slow (and I assume for sync too, but that should be validated) and maybe we should consider cranking dbcache and making a release note for loe memory hosts.
1902016-06-23T19:05:13  <sipa> though this may be due to my laptop's disk setup (zfs on encrypted lvm volume)
1912016-06-23T19:05:27  <wumpus> so, some people are noticiing slow validation, I wonder what changed there
1922016-06-23T19:05:29  <gmaxwell> (two identical hosts)
1932016-06-23T19:05:49  <sipa> from gmaxwell's numbers, it does not look like his time is dominated by database flushes, however
1942016-06-23T19:05:57  <gmaxwell> I think I am often guilty of only testing things with a non-default dbcache.
1952016-06-23T19:06:03  <sipa> likewise
1962016-06-23T19:06:12  <gmaxwell> I previously _expected_ reindex to be slow due to the signature checking.
1972016-06-23T19:06:19  <wumpus> I usually run with default dbcache
1982016-06-23T19:06:30  <jtimon> maybe a solution would be to change the default dbcache for something more common among testers?
1992016-06-23T19:06:46  <gmaxwell> my laptop runs with default dbcache and I have been noticing verification is slow for a while, but I have not reindexed for quite a long time.
2002016-06-23T19:06:48  <sipa> jtimon: we still need to figure out what is behind this... but independently, yes
2012016-06-23T19:06:50  <wumpus> yes, we should definitely crank up the dbcache no matter what
2022016-06-23T19:06:53  <wumpus> but I like to know what happened
2032016-06-23T19:07:08  <jtimon> sipa: yeah, of course, I meant independently
2042016-06-23T19:07:24  *** CubicEarth has joined #bitcoin-core-dev
2052016-06-23T19:07:30  <wumpus> should at least try to bisec tthis, I know it's frustrating as everything takes so long :)
2062016-06-23T19:08:07  <sipa> oh, this is with txindex enabled
2072016-06-23T19:08:14  <gmaxwell> Well I will test against 0.12.1 and see if there is a regression.  oh crap. testing against 0.12.1 will be messed up by signature checking, I guess I will test against patched 0.12.1 that skips signature checking before block 295000? does that sound okay?
2082016-06-23T19:08:18  <wumpus> gmaxwell didn't you have some suspicions that CB would affect initial sync? could that also affect reindex?
2092016-06-23T19:08:24  <wumpus> not in my case
2102016-06-23T19:08:27  <sipa> wumpus: gmaxwell's test was before cb was merged
2112016-06-23T19:08:57  <gmaxwell> my test is without cb merged, also the CB concern was just related to general sync logic, not processing.
2122016-06-23T19:08:58  <jtimon> are there recent changes that people suspect may have caused the regression ?
2132016-06-23T19:09:07  <wumpus> wouldbe good to test against #7917, as many people benchmarked that
2142016-06-23T19:09:18  <wumpus> and it was perceived fast at the time
2152016-06-23T19:09:40  <wumpus> jtimon: not really
2162016-06-23T19:09:42  <gmaxwell> I can refine further if it looks like a regression.  I think it's likely when I tested 7917 it was with a high dbcache and the result was that things got much faster.
2172016-06-23T19:10:13  <gmaxwell> At least the logs I'm seeing suggest that the slow performace is leveldb performance being slow, so it would be completely hidden by a sufficiently large dbcache.
2182016-06-23T19:10:30  <gmaxwell> (maybe not leveldb itself being slow, e.g. making extranious accesses to it)
2192016-06-23T19:10:47  <wumpus> it may be the windows machine I'm testing on is just crappy, I also had a strange issue with ldb files: https://github.com/bitcoin/bitcoin/issues/8250 .. possible that the disk is just very slow due to other processes interfering
2202016-06-23T19:10:56  <sipa> gmaxwell: note that txindex may actually influence this; the txindex entries are written continuously to the db, and not cached inside the application or batched together with the rist
2212016-06-23T19:11:03  <gmaxwell> So actions are. determine if regression, if so where, ... seperately, consider a dbcache increase for the next release.
2222016-06-23T19:11:08  <wumpus> I doubt it is leveldb itself as there haven't been changed to that for ages
2232016-06-23T19:11:13  *** molz has joined #bitcoin-core-dev
2242016-06-23T19:11:17  <gmaxwell> sipa: yes this might be txindex related. I can test that too.
2252016-06-23T19:11:23  <wumpus> yes, txindex is *slow*
2262016-06-23T19:11:24  <CodeShark> is something slowing down validation that wasn't before?
2272016-06-23T19:11:29  <sipa> CodeShark: maybe
2282016-06-23T19:11:32  <wumpus> lots of extra I/O. I also made that mistake once
2292016-06-23T19:11:40  <gmaxwell> wumpus: we have changed (reduced) the amount of interaction with leveldb during validation.
2302016-06-23T19:11:51  <wumpus> gmaxwell: sure, it may be the level above leveldb
2312016-06-23T19:12:00  <sipa> yes, it may be
2322016-06-23T19:12:06  <wumpus> I just don't suspect the databse itself this time
2332016-06-23T19:12:34  <gmaxwell> but yes, the only path I see to leveldb itself would just be that it now has more data in it than ever before, and perhaps it crossed some performance cliff. but otherwise, nah.
2342016-06-23T19:12:36  <wumpus> unless some compiler flag changed things shockingly, say, the c++11 switch, but I doubt it
2352016-06-23T19:12:53  <gmaxwell> I think txindex is a good lead, my laptop is the only host I regularly use with it, and I've been noticing poor validation performance for a while.
2362016-06-23T19:13:07  <sipa> i briefly suspected the IsInitialBlockDownload change, but apart from using an atomic, its semantics should be unchanged
2372016-06-23T19:13:19  <wumpus> especialy if you see the slowdown in the flush; txindex writes a lot of data to the block index databse
2382016-06-23T19:13:42  <sipa> wumpus: but the txindex writes don't happen during the flush
2392016-06-23T19:13:45  <wumpus> so maybe false alarm, the sync is slow, news at 11
2402016-06-23T19:13:59  <sipa> wumpus: though they may accumulate somewhere in leveldb until a flush is issued
2412016-06-23T19:14:01  <CodeShark> can't we add tracers around calls to narrow it down?
2422016-06-23T19:14:08  <gmaxwell> wumpus: well, the "lets increase the dbcache" is still a useful response to this catching attention again.
2432016-06-23T19:14:11  *** moli has quit IRC
2442016-06-23T19:14:31  <sipa> action points: benchmark in same conditions without txindex, and with larger dbcache?
2452016-06-23T19:14:55  <wumpus> yes we should increate the dbcache, and probably change how it is allocated
2462016-06-23T19:15:09  <wumpus> (e.g. a relatively large part now goes to leveldb caches, that's a waste
2472016-06-23T19:15:16  <gmaxwell> (as my laptop is about to be on day three of reindex)
2482016-06-23T19:15:51  <sipa> wumpus: the reasoning was that leveldb cache is serialized, so it has a much large impact per byte than the internal cache
2492016-06-23T19:15:55  <wumpus> leveldb's own caches are completely ineffective compared to bitcoind's application level cache
2502016-06-23T19:15:59  <sipa> but it has the deserialization overhead
2512016-06-23T19:16:04  *** instagibbs2 has joined #bitcoin-core-dev
2522016-06-23T19:16:17  <sipa> but that's mostly a guess without substansive benchmarking
2532016-06-23T19:16:18  <wumpus> sipa: that makes a lot of sense in theory, but leveldb just sucks at caching :)
2542016-06-23T19:16:43  <gmaxwell> I can benchmark a bunch of mixes of cache sizes and see how they pan out.
2552016-06-23T19:16:53  <sipa> wumpus: it may also be due to our access pattern... the things that get written to leveldb haven't been touched for a while; maybe they won't be touched any time soon as a result either
2562016-06-23T19:17:04  <wumpus> the current values are probably ok, I just mean: if we scale dbcache we probably don't want to scale those caches with it
2572016-06-23T19:17:10  <jtimon> not sure I'm following but maybe we want separate options for the "internal" and "external" caches?
2582016-06-23T19:17:27  <wumpus> jtimon: for testing that'd be awesome
2592016-06-23T19:17:42  <sipa> jtimon: for testing that makes sense, but as a product it should work well with the fewest number of tunable possible
2602016-06-23T19:17:46  <gmaxwell> In principle we shouldn't add knobs as a punt for highly technical settings that even we haven't figured out, the users will do no better at it. :P  (as hidden options for testing or whatnot, sure)
2612016-06-23T19:17:58  <sipa> jynx
2622016-06-23T19:17:59  <instagibbs2> On phone but present
2632016-06-23T19:18:21  <jtimon> there's some options that can only be accessed if --debug, right?
2642016-06-23T19:18:25  <wumpus> gmaxwell: you'd be surprised :-)
2652016-06-23T19:18:35  <wumpus> some users are very persistent in trying to find settings that are fastest for them
2662016-06-23T19:18:48  <CodeShark> I'd venture to say it's probably not the majority
2672016-06-23T19:18:51  <wumpus> but yes, it should be a hidden option (--help-debug)
2682016-06-23T19:18:52  <jtimon> oh, no they may not be showed in the help but they're still accesible I think
2692016-06-23T19:19:00  <wumpus> CodeShark: sure, but don't underestimate peole
2702016-06-23T19:19:08  <sipa> wumpus: maybe such options should be marked with ("If you find a setting for this value that improves performance, please let us know")
2712016-06-23T19:19:15  <wumpus> sipa: +1 :D
2722016-06-23T19:19:18  <gmaxwell> -funroll-loops -O20
2732016-06-23T19:19:34  <sipa> -femit-broken-code
2742016-06-23T19:20:05  <wumpus> -fskip-computing-even-bits
2752016-06-23T19:20:13  <wumpus> ok, any other topics?
2762016-06-23T19:20:15  <sipa> relatedly, i think -qt can by default use more ram
2772016-06-23T19:20:37  <sipa> also, 100 mb is kinda ridiculous with the mempool already being 300 mb
2782016-06-23T19:20:42  <wumpus> yes, probably, although qt itself also uses more ram
2792016-06-23T19:21:02  <wumpus> yes, agreed
2802016-06-23T19:21:11  <sipa> other topic: merge segwit yay or nay
2812016-06-23T19:21:16  <wumpus> let's reduce the mempool to 100mb and increase dbcache to 300mb
2822016-06-23T19:21:17  <gmaxwell> okay, I have my action items on this. I will benchmark a bunch of configurations. 0.12.1 vs master;  and master  w/wo txindex, w/wo default dbcache.... and also try different cache splits. I may ask for suggestions on the interesting parameter space when I go to do that. If there is a 0.12.1 vs master regression I'll find out where.
2832016-06-23T19:21:38  <petertodd> sipa: re: segwit, has it been rebased?
2842016-06-23T19:21:42  *** laurentmt has joined #bitcoin-core-dev
2852016-06-23T19:21:45  <wumpus> #topic segwit
2862016-06-23T19:21:46  <sipa> petertodd: 12 times by now
2872016-06-23T19:21:50  <CodeShark> lol
2882016-06-23T19:21:53  <sipa> see 8149
2892016-06-23T19:21:55  <CodeShark> poor sipa
2902016-06-23T19:21:55  <jtimon> how can we feature freeze without merging segwit?
2912016-06-23T19:22:02  *** laurentmt has quit IRC
2922016-06-23T19:22:03  <wumpus> sipa is getting carpal tunnel syndrome from rebasing
2932016-06-23T19:22:05  <gmaxwell> We can do some checking to see what mempool size should be based on current traffic, in principle I'd agree shifting memory from one to the other.
2942016-06-23T19:22:16  <wumpus> jtimon: softforks / consensus changes don't count as software features
2952016-06-23T19:22:28  <wumpus> jtimon: that's also why they're allowed to be introduced in minor versions
2962016-06-23T19:22:29  <petertodd> sipa: I mean, is the current pull-req rebased since compact blocks got merged?
2972016-06-23T19:22:32  <gmaxwell> also it's not even activated in any case. it's pure code updates.
2982016-06-23T19:22:35  <sipa> petertodd: yes
2992016-06-23T19:22:49  <jtimon> wumpus: so it won't be possible to include any feature post segwit merge in 0.13 ?
3002016-06-23T19:22:52  <CodeShark> current is #8149, yes?
3012016-06-23T19:23:00  <sipa> petertodd: and i've been running the rebase on both testnet (where it syncs segwit blocks) and on mainnet (where it uses compact blocks)
3022016-06-23T19:23:05  <wumpus> jtimon: right, 0.13 is closed feature-wise
3032016-06-23T19:23:25  *** CubicEarth has quit IRC
3042016-06-23T19:23:52  <gmaxwell> I haven't done CB+segwit testing yet, but I'm due to bring up a new testnet node, so I can do that.
3052016-06-23T19:23:55  <wumpus> features will be merged again on master after a 0.13 branch is created, which will be around the rc1 release (planned july 6 I think)
3062016-06-23T19:24:02  <jtimon> wumpus: that is a no, that is unconvenient and I wasn't expecting it, but thanks
3072016-06-23T19:24:18  *** instagibbs3 has joined #bitcoin-core-dev
3082016-06-23T19:24:34  <wumpus> #link see the release schedule here: https://github.com/bitcoin/bitcoin/issues/8250
3092016-06-23T19:24:56  <CodeShark> sipa: which PR should we be testing against?
3102016-06-23T19:24:56  <jtimon> yeah, should have asked "what about segwit?" back then
3112016-06-23T19:25:06  <sipa> CodeShark: 8149 and 7190 are the exact same code
3122016-06-23T19:25:10  <sipa> so whatever you like
3132016-06-23T19:25:44  <gmaxwell> I had completed review up to the CB rebase, which I have not looked at yet.
3142016-06-23T19:26:03  <gmaxwell> (I mean I haven't looked at segwit's rebase for CB)
3152016-06-23T19:26:24  <jtimon> I would have preferred that segwit would have been merged before feature freeze to have time to do something post-segwit for 0.13, but mainly I just wanted to undesrtand the situation
3162016-06-23T19:26:45  <sipa> git show -w c4e3c755d7e41aaabe74c84af7e4bf00a62c96fb
3172016-06-23T19:26:54  *** instagibbs2 has quit IRC
3182016-06-23T19:26:54  <sipa> and then search for cmpctblk and blocktxn
3192016-06-23T19:27:01  <sipa> to see the changes related to that
3202016-06-23T19:27:05  <btcdrak> oh I'm late
3212016-06-23T19:27:21  <wumpus> jtimon: we all would have preferred other timings, but we have to cope with how things actually are :)
3222016-06-23T19:27:46  <jtimon> I planned to rebase/rewrite some of the consensus encapsulation code after segwit, I guess the plan doesn't change anyway
3232016-06-23T19:28:02  <wumpus> well you can still do that, it just won't make 0.13
3242016-06-23T19:28:37  <jtimon> wumpus: well, yeah, I could have helped more with reviewing and testing segwit
3252016-06-23T19:28:41  <gmaxwell> sipa: thanks, will review once I start up the test panel for the prior topic. :)
3262016-06-23T19:28:48  <jtimon> wumpus: understood
3272016-06-23T19:29:07  <sipa> jtimon: you can still do that, even after merge :)
3282016-06-23T19:29:22  <gmaxwell> yes, post merge review and testing is super important too.
3292016-06-23T19:29:44  <wumpus> yes, absolutely
3302016-06-23T19:29:52  *** Chris_Stewart_5 has quit IRC
3312016-06-23T19:30:22  <gmaxwell> In any case I am in favor of the merge. (and don't expect my remaining review to turn up any reason not to)
3322016-06-23T19:30:43  <sipa> i'm running the cb+segwit rebase on bitcoin.sipa.be since a few days, to see if there was an impact on memory usage - i see none
3332016-06-23T19:30:48  <gmaxwell> Obviously there may still need to be some fixes and nits. But thats what we have time for.
3342016-06-23T19:30:54  <sipa> (compared to running just cb before)
3352016-06-23T19:30:56  <wumpus> anyone against merging segwit?
3362016-06-23T19:31:03  <wumpus> (I mean right now, not in general)
3372016-06-23T19:32:00  <wumpus> *crickets*
3382016-06-23T19:32:11  <sipa> i have no objections :)
3392016-06-23T19:32:14  <wumpus> that's clear then
3402016-06-23T19:32:17  <btcdrak> I'd like to see it merged too
3412016-06-23T19:32:19  <wumpus> yes, I understood
3422016-06-23T19:32:27  <jtimon> sipa: yeah, it just won't make it to 0.13 as wumpus explained
3432016-06-23T19:32:30  <CodeShark> the sooner the better (as long as it doesn't break current behavior)
3442016-06-23T19:32:39  <wumpus> #action Merge segwit
3452016-06-23T19:32:44  *** MarcoFalke has joined #bitcoin-core-dev
3462016-06-23T19:32:45  <btcdrak> o/
3472016-06-23T19:33:10  <gmaxwell> at this point it will amplify testing, since we've done a much of the specialized testing. Testing for incidental effects by a broader audience would be good.
3482016-06-23T19:33:26  <instagibbs3> Good.
3492016-06-23T19:34:00  <gmaxwell> Would it be awful to suggest that we put out 'testnet binaries' right away off master to also get more people testing with that code in use?
3502016-06-23T19:34:19  <petertodd> gmaxwell: fine by me
3512016-06-23T19:34:21  <sipa> i believe jonasschnelli builds nightly binaries
3522016-06-23T19:34:22  <wumpus> sure, why not
3532016-06-23T19:34:47  <wumpus> I prefer doing that outside the 'official' release cycle, but I don't mind running gitian for it
3542016-06-23T19:34:51  <gmaxwell> I think that the prior segnet testing didn't include anyone that was likely to be confused by status changes in the UI or whatnot-- too technical an audience since you had to build it. :)
3552016-06-23T19:35:15  <gmaxwell> yes, I don't want something part of the release cycle. Just binaries to give to power users to give it a spin.
3562016-06-23T19:35:27  <wumpus> testnet-only
3572016-06-23T19:35:51  <CodeShark> testnet as in not segnet, right?
3582016-06-23T19:35:52  <gmaxwell> yea, pre-RC testnet only, we could one line patch to change the default network, so it'll be easier to use.
3592016-06-23T19:36:07  <sipa> CodeShark: segnet has been removed a few weeks ago from the patch
3602016-06-23T19:36:17  <gmaxwell> Testnet is segwit now. Segnet is dead long live segnet.
3612016-06-23T19:36:21  <petertodd> gmaxwell: maybe better to just make it fail unless -testnet is enabled, in case someone does run it in production
3622016-06-23T19:36:26  <wumpus> no, not segnet. Regtest could be allowed. But mainnet disabled and testnet as default
3632016-06-23T19:36:32  <CodeShark> is segwit live on testnet?!?!
3642016-06-23T19:36:36  <gmaxwell> yea. exactly.
3652016-06-23T19:36:38  <sipa> CodeShark: yes, since months
3662016-06-23T19:37:01  <wumpus> petertodd: what is the worst that could happen if you accidentally run testnet?
3672016-06-23T19:37:14  <petertodd> wumpus: hard to know!
3682016-06-23T19:37:39  <gmaxwell> it's just pre-RC master, lots of people do run that in production. I wouldn't worry too much, discretion of whomever makes the testnet-as-default patch?
3692016-06-23T19:37:44  <petertodd> wumpus: having to add a -testnet flag isn't a big deal; and failing hard if you don't shouldn't have any consequences
3702016-06-23T19:37:46  <wumpus> at least the default ports etc will be different, default data dir is different, etc
3712016-06-23T19:37:55  *** CubicEarth has joined #bitcoin-core-dev
3722016-06-23T19:38:13  <wumpus> petertodd: apart from GUI users I guess
3732016-06-23T19:38:19  <gmaxwell> petertodd: I hope the user doesn't have to set any flags, if they have to set flags far fewer people will try it.
3742016-06-23T19:38:25  <sipa> i believe this is a nit not worth minutes of discussion time
3752016-06-23T19:38:25  <petertodd> wumpus: yes, but imagine someone has an automated system setup which calls bitcoin-cli...
3762016-06-23T19:38:41  <gmaxwell> in any case, can be discussed later or not.
3772016-06-23T19:38:42  <gmaxwell> :)
3782016-06-23T19:38:46  <btcdrak> any more topics?
3792016-06-23T19:39:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3802016-06-23T19:40:06  <jtimon> are we merging the bip9 activation parameters for testnet?
3812016-06-23T19:40:27  <CodeShark> hmm - I don't see the activation parameters for segwit on testnet
3822016-06-23T19:40:39  <CodeShark> how can it be live on testnet?
3832016-06-23T19:40:54  <jtimon> CodeShark: people running custom code I assume
3842016-06-23T19:40:57  <sipa> CodeShark: in the segwit branch
3852016-06-23T19:41:02  <jtimon> oh
3862016-06-23T19:41:03  <sipa> not in master
3872016-06-23T19:41:20  <btcdrak> CodeShark: it was activated months ago
3882016-06-23T19:41:44  <CodeShark> yes, but I'm still confused as to the release here
3892016-06-23T19:41:59  <CodeShark> shouldn't testnet only run stuff that's been merged?
3902016-06-23T19:42:11  <instagibbs3> bip 9 activation can still be set.
3912016-06-23T19:42:13  <btcdrak> no, we set the parameters
3922016-06-23T19:42:26  <gmaxwell> CodeShark: we wanted testing in a mixed enviroment with most nodes not upgraded.
3932016-06-23T19:42:26  <btcdrak> and that allowed a miner to activate it
3942016-06-23T19:42:29  <sipa> CodeShark: it was a very useful testing exercise
3952016-06-23T19:42:32  <gmaxwell> CodeShark: since thats realistic.
3962016-06-23T19:42:48  <gmaxwell> and segnet couldn't easily provide that.
3972016-06-23T19:43:00  <CodeShark> sure, I'm all for the additional testing - I'm just concerned about breaking the master builds for testnet
3982016-06-23T19:43:10  <gmaxwell> CodeShark: it's a softfork, hurrah.
3992016-06-23T19:43:18  <sipa> (although, there are so few testnet segwit nodes running right now that it really does not work without -addnode)
4002016-06-23T19:43:19  <jtimon> answer my own question: yes, the testnet activation is part of #7910 : https://github.com/bitcoin/bitcoin/pull/8149/files#diff-64cbe1ad5465e13bc59ee8bb6f3de2e7R191
4012016-06-23T19:43:39  <CodeShark> gmaxwell: yes, but it will still break miners. however, if no issues arose as a result I'm fine with it
4022016-06-23T19:43:58  <sipa> CodeShark: testnet miners are clearly already running it
4032016-06-23T19:44:05  <CodeShark> yes, indeed
4042016-06-23T19:44:09  <sipa> so how could merging break anything for them?
4052016-06-23T19:44:19  <CodeShark> nvm, all's good
4062016-06-23T19:44:24  <gmaxwell> CodeShark: no issues appear to have arisen.  (also testnet reorgs a lot in any case, so a little instability would have been an issue)
4072016-06-23T19:44:37  <gmaxwell> er, wouldn't have been
4082016-06-23T19:45:02  <jtimon> it is the first time a softfork is activated on testnet before it is in master thought, right?
4092016-06-23T19:45:02  <gmaxwell> in any case, so that would be an action to go with the testnet only builds: get more testnet nodes running upgraded so that it works without addnode.
4102016-06-23T19:45:14  <gmaxwell> Are the testnet seeds running the code that can give filtered responses?
4112016-06-23T19:45:16  <sipa> indeed, and we can test the dns filtering
4122016-06-23T19:45:23  <sipa> gmaxwell: jonasschnelli's is
4132016-06-23T19:45:27  <sipa> not sure about petertodd's
4142016-06-23T19:45:37  <sipa> oh, yes
4152016-06-23T19:45:49  <sipa> https://github.com/bitcoin/bitcoin/pull/8204
4162016-06-23T19:46:49  <sipa> petertodd: are you sure that's running the filtering code?
4172016-06-23T19:46:57  <jtimon> gmaxwell: the "testnet only" builds are just from master after merging segwit, right?
4182016-06-23T19:47:02  <sipa> jtimon: yes
4192016-06-23T19:47:02  <petertodd> sipa: should be
4202016-06-23T19:47:03  <gmaxwell> good okay, so an action right after merge will be to get some more testnet nodes running it spun up, and cooridnate a pre-rc testnet-default/only binary.
4212016-06-23T19:47:10  <petertodd> sipa: I'll recheck
4222016-06-23T19:47:14  <sipa> x9.seed.tbtc.petertodd.org gives many results, more than i'd expect
4232016-06-23T19:47:32  <petertodd> sipa: note that it is running with extra args to support rbf
4242016-06-23T19:47:40  <gmaxwell> jtimon: yes, likely with a trivial patch to change it to default to testnet (or require it). (and maybe a renamed binary)
4252016-06-23T19:47:42  <petertodd> sipa: so maybe there's a bug there that you haven't run into yet
4262016-06-23T19:48:16  <sipa> petertodd: can i see the code for that?
4272016-06-23T19:48:20  *** fengling has joined #bitcoin-core-dev
4282016-06-23T19:48:24  <jtimon> gmaxwell: why the changes? aren't this power users?
4292016-06-23T19:48:33  <sipa> after the meeting, please
4302016-06-23T19:48:44  <petertodd> sipa: it's with the command line arg; which incidentlaly was broken when I tried it (see my pullreq)
4312016-06-23T19:49:02  <gmaxwell> any other topics for this meeting?
4322016-06-23T19:49:31  <wumpus> doesn't seem so
4332016-06-23T19:49:58  <wumpus> #endmeeting
4342016-06-23T19:49:58  <lightningbot> Meeting ended Thu Jun 23 19:49:58 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
4352016-06-23T19:49:58  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-23-19.02.html
4362016-06-23T19:49:58  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-23-19.02.txt
4372016-06-23T19:49:58  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-23-19.02.log.html
4382016-06-23T19:50:23  <sipa> petertodd: are you including -w 9 ?
4392016-06-23T19:50:35  <jtimon> oh, I think we forgot to make a joke, that's bad for the summaries :p
4402016-06-23T19:51:03  <btcdrak> there is plenty comic relief there
4412016-06-23T19:51:06  <gmaxwell> jtimon: the network changing expirence is not a great UI; I know of many people that are running a half dozen altcoins and got lost when asked to use testnet.  Especially since it's not a release that we want anyone messing up and running in production on mainnet, it makes sense to switch the default, both to make it easy to use, and harder to screw up.
4422016-06-23T19:51:15  <petertodd> sipa: yeah, I think so
4432016-06-23T19:51:46  <btcdrak> wumpus: so is segwit is the last feature PR and now 0.13 is frozen?
4442016-06-23T19:51:55  <gmaxwell> segwit is not a feature PR
4452016-06-23T19:52:03  <gmaxwell> and 0.13 has been frozen for a bit now.
4462016-06-23T19:52:12  <wumpus> as gmaxwell says ^^
4472016-06-23T19:52:16  <btcdrak> fine
4482016-06-23T19:52:26  *** fengling has quit IRC
4492016-06-23T19:52:27  <gmaxwell> (it's especially not a feature PR with it not yet activated in mainnet. :) )
4502016-06-23T19:52:30  <jtimon> gmaxwell: whatever, the patch to change the default and/or disable mainnet should be trivial anyway
4512016-06-23T19:52:52  <sipa> i'd be perfectly fine with that binary also supporting mainnet
4522016-06-23T19:52:58  <gmaxwell> jtimon: yup. if it were hard I wouldn't have suggsted it. I think it's useful but not of great importance.
4532016-06-23T19:53:34  <jtimon> I think I disagree with the notion that "the segwit PR is not a feature"
4542016-06-23T19:53:38  <gmaxwell> I'd suggest just change testnet default to 1 in it. lots of people run git master in production (sadly, and sometimes without realizing it).
4552016-06-23T19:53:55  <gmaxwell> jtimon: I feel sorry for you then?  It's not even exposed in 0.13 as merged.
4562016-06-23T19:54:22  *** MarcoFalke has quit IRC
4572016-06-23T19:54:35  <wumpus> re: launching testnet it would be useful if the windows installer created a Bitcoin Core (Testnet) link in the menu too, which does nothing but launch bitcoin-qt with -testnet flag. I have no idea how to do that though
4582016-06-23T19:54:53  <gmaxwell> And the release cycle distinction we make for bitcoin is that consensus consistency changes are base, mandatory, functionality-- not software features (though sometimes some features must ride along with them)
4592016-06-23T19:55:05  <jtimon> gmaxwell: precisely I thought the "softforks are minor releases" applied to the activation, not to the inactive code
4602016-06-23T19:55:31  <gmaxwell> jtimon: sure though inactive code is not a feature either.
4612016-06-23T19:55:50  <CodeShark> if it includes the testnet code I'd argue it is a feature
4622016-06-23T19:55:53  <gmaxwell> wumpus: that would be fantastic, and would radically increase the use of testnet, I expect.
4632016-06-23T19:56:08  <gmaxwell> CodeShark: A feature for testnet. ooohkay.
4642016-06-23T19:56:25  <gmaxwell> I don't disagree but I don't think the distinction is important.
4652016-06-23T19:56:49  <gmaxwell> Testnet is not very serious, as much as I'd like it to be more serious. It's often pretty broken.
4662016-06-23T19:57:28  <CodeShark> going forward, as long as activation parameters for testnet softforks are documented somewhere and we agree on them it seems ok
4672016-06-23T19:57:59  <btcdrak> CodeShark: they are already documented: https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki
4682016-06-23T19:57:59  <gmaxwell> Not sure how you missed the couple weeks of discussion about segwit in testnet before.
4692016-06-23T19:58:21  <CodeShark> I remember the discussion - I just wasn't clear on the release cycle as it pertains to testnet
4702016-06-23T19:58:55  <jtimon> yeah, I think that's the source of the discussion
4712016-06-23T19:58:57  <btcdrak> there is no release cycle. miners can apply whatever sfs they like at any time
4722016-06-23T19:59:14  <jtimon> not saying necessarily the new method is worse, but it has changed
4732016-06-23T19:59:34  <gmaxwell> In the future it might be useful to try to get softfork changes in earlier, and have them make it a whole cycle inactive on mainnet.  But testnet is testnet, whatever happens there is what people using it think is best for testing.
4742016-06-23T19:59:42  <jtimon> well, "release cycle", "modus operandi", whatever
4752016-06-23T19:59:48  <wumpus> I don't think the distinction is important either
4762016-06-23T19:59:59  <wumpus> we just need segwit out, and everything that helps the testing and review process is great
4772016-06-23T20:00:04  <gmaxwell> (e.g. you didn't see any of us howling about release cycle when jtoomim was using the XT hardfork on it)
4782016-06-23T20:00:18  <wumpus> we're not goingn to block segwit on a procedural detail
4792016-06-23T20:00:18  <btcdrak> jtimon: there isnt a release cycle. The consensus rules of the network are not defined by a release cycle of software
4802016-06-23T20:00:39  <btcdrak> gmaxwell: exactly
4812016-06-23T20:00:42  <gmaxwell> as btcdrak said.
4822016-06-23T20:01:23  <gmaxwell> And sure, on _mainnet_ having consensus rules change without released software would be _insane_, thats why BIP9 got a starting date... but for testnet, that can make sense.
4832016-06-23T20:01:45  <CodeShark> ok, fair enough - in the past I've been a bit confused as to testnet's purpose as it seems to be used for very different things. it seems like it should be the place where we try to break the protocol, first and foremost - and not so much the place where application developers can try out new stuff
4842016-06-23T20:01:47  <gmaxwell> esp when the thing we're trying to test is deployment of a feature in a non-upgraded network. :)
4852016-06-23T20:02:04  <jtimon> wumpus: completely agree re segwit, but if we can improve things for the future, it may be worth the discussion (ie like gmaxwell's suggestion on making a whole unactivaded release cycle). There's no harm on trying to think what would be "ideal" for next time
4862016-06-23T20:02:18  <sipa> CodeShark: there have been proposals in the past for having multiple testnetd
4872016-06-23T20:02:30  <gmaxwell> I'd love it to be where application developers can try new stuff, but virtually none have been interested in using it in the past, even with begging.
4882016-06-23T20:02:48  <sipa> CodeShark: it is not ideal that network feature deployments are being tested in the same place as where we hope applications test before mainnet exposure
4892016-06-23T20:02:52  <gmaxwell> and if they were, we could easily move more disruptive things to other testnets.
4902016-06-23T20:03:08  <jtimon> btcdrak: ack
4912016-06-23T20:03:38  <gmaxwell> but so far, people largely aren't, and there are barely enough running nodes to keep even one functional.  (and to be clear, segwit hasn't been disruptive of testnet)
4922016-06-23T20:04:03  <wumpus> jtimon: sure, I just get crazy from all the time pressure and all the different things that pop up
4932016-06-23T20:04:23  <wumpus> jtimon: I don't have much trust in anything ever being done the 'ideal' way :-)
4942016-06-23T20:04:25  *** cryptapus has quit IRC
4952016-06-23T20:04:27  <gmaxwell> Though its often disrupted by random stuff, and by ordinary releases too. (The alpha sidechain uses testnet and we've had a couple firedrills with it when the ordinary release cycle caused forks because of absentee miners on testnet)
4962016-06-23T20:04:36  <jtimon> wumpus: not regreting anything rewarding segwit
4972016-06-23T20:04:38  <CodeShark> if you're interested in testing applications and are comfortable assuming that the protocol itself isn't broken it seems preferable to spawn up a new testnet or just use regtest
4982016-06-23T20:05:01  <gmaxwell> e.g. for a while after dersig would merge, testnet would fork as soon as the miner in my office got turned off because I was on a phone call and wanted less noise. :)
4992016-06-23T20:05:05  <wumpus> jtimon: well the critical thing is that segwit is reviewed and tested enough, that there are no technical concerns with merging it
5002016-06-23T20:05:08  <CodeShark> not sure it's necessary to test on testnet itself
5012016-06-23T20:05:12  <CodeShark> at least for an application developer
5022016-06-23T20:05:19  <CodeShark> although there is a benefit to us
5032016-06-23T20:05:20  <gmaxwell> er after dersig was released.
5042016-06-23T20:05:20  <jtimon> wumpus: ack
5052016-06-23T20:05:23  <wumpus> jtimon: that's the kind of thing I lay awake about at night, not whether we do the release phases in the right order
5062016-06-23T20:05:52  <gmaxwell> CodeShark: it's useful because most developers don't have the time and interest to simulate the volitility of a real network in their testing.
5072016-06-23T20:05:57  <sipa> well, maybe having a windows desktop shortcut for testnet makes it more visible and attractive to test on
5082016-06-23T20:06:05  <gmaxwell> E.g. left to their own devices reorg handling may be compeltely untested.
5092016-06-23T20:06:21  <gmaxwell> also testnet is useful for interworking tests between multiple implementations.
5102016-06-23T20:06:39  <sipa> i would love to see an actually operational test network, where you can try sending from testnet bitgo to testnet bitawesomewallet or something
5112016-06-23T20:06:43  <jtimon> wumpus: that's perfect. I'm not criticizing. Just wondering if things can be done EVEN better
5122016-06-23T20:06:48  <gmaxwell> I've joked before, but really seriously, that someone should setup a dumb gambling thing on testnet.
5132016-06-23T20:07:12  <gmaxwell> I spent much of 2012 begging services to setup testnet instances of themselves with play money, without much luck.
5142016-06-23T20:07:32  <gmaxwell> I think I got one exchange to do it for a bit. And they ended up stealing 10000 tnbtc from me and going unresponsive. :P
5152016-06-23T20:07:48  <wumpus> the only services that exist for testnet seem to be some block explorers, also mostly broken
5162016-06-23T20:08:26  <wumpus> I think regtest made it too attractive to set up internal testing networks :-)
5172016-06-23T20:08:40  <wumpus> jtimon: agree, there's always room for improvement
5182016-06-23T20:08:43  <jtimon> well, people used segtest, right? maybe if testnet usually had more features it would be more used (following gmaxwell's suggestion to have softforks activated in testnet but not activated in master for longer). Please, I'm just speculating
5192016-06-23T20:09:00  <wumpus> testnet has 'more features', e.g. no standardness
5202016-06-23T20:09:05  <gmaxwell> wumpus: most parties just seem to 'test' with mainnet, which is fine too, but you can't really test reorg and doublespend handling that way.
5212016-06-23T20:09:20  <CodeShark> with regtest you can definitely do more rigorous testing - given you have programs that can simulate network conditions on it
5222016-06-23T20:09:27  <gmaxwell> jtimon: softforks have pretty much always activated first on testnet.
5232016-06-23T20:09:48  <gmaxwell> CodeShark: yes, you can but with a lot of work. What you can't test is what happens when crazy things that you didn't even know where possible happen. :)
5242016-06-23T20:10:10  <wumpus> gmaxwell: well people like predictability for testing, as most testing is automated and internal anyway. On regtest you can trigger a reorg when you want to test it, instead of randomly happening at a point you're doing something else
5252016-06-23T20:10:24  <gmaxwell> I think prudent parties will do both: rigorous tests with regtest and a harness, and a toy instance on testnet to see what catches fire.
5262016-06-23T20:10:29  <wumpus> gmaxwell: (not that that kind of testing isn't useful, but it just isn't very popular)
5272016-06-23T20:10:56  <wumpus> it requires people actually paying attention on the fly :)
5282016-06-23T20:11:25  <gmaxwell> unpredictablity of blocktimes on testnet has not helpped for application testing.
5292016-06-23T20:11:49  *** robs has joined #bitcoin-core-dev
5302016-06-23T20:11:50  <wumpus> also unrealistic reorgs
5312016-06-23T20:12:56  <gmaxwell> I've wondered if it might not be interesting to have a testnet with the rather small code for signed blocks from alpha and have a testnet where blocks happen once a minute constantly, and every N hours there is a reorg which includes every conflict the signer has learned about.
5322016-06-23T20:12:58  <wumpus> whole runs of difficulty-1 blocks that are reorged away suddenly
5332016-06-23T20:13:12  <btcdrak> there is no incentive to mine on testnet. that is the main issue
5342016-06-23T20:13:31  <wumpus> btcdrak: right - if there was, then testnet coins would have a value
5352016-06-23T20:13:45  <gmaxwell> btcdrak: I don't think thats an issue, I have 2TH that are basically always on testnet except when someone moves them off to test something else and forgets to move them back.
5362016-06-23T20:15:00  <gmaxwell> I don't consider it important and don't actively monitor them, though I could have that setup... often it's the only mining of testnet though.
5372016-06-23T20:15:23  <btcdrak> gmaxwell: i like the idea of testnet block signers.
5382016-06-23T20:15:27  <gmaxwell> wumpus: it's tricky, for that kind of testing there should be substantive reorgs (that mainnet has only very rarely); but not absurd ones.
5392016-06-23T20:15:55  <gmaxwell> the diff-1 stuff in testnet feels like its mostly been a failure, ... okay, it's an improvement over being stuck for days, but it's lame in a lot of other ways.
5402016-06-23T20:17:02  <CodeShark> the way I always looked at it, testnet is ideal for people who want to try to break the protocol itself and try their exploits
5412016-06-23T20:17:16  <gmaxwell> btcdrak: I'd say that someone who wanted that could just use alpha, but alpha has a lot of radical depatures, it's not that compatible.
5422016-06-23T20:17:45  <CodeShark> for any sort of testing where you know the edge cases, regtest is better  - but testnet can help with the cases we didn't think of
5432016-06-23T20:17:47  <gmaxwell> CodeShark: its mostly not used for that. The most use it gets is breaking secondary implementations.
5442016-06-23T20:18:27  <gmaxwell> halariously, there is one of these "messaging via the blockchain" spammy things that uses testnet for production.
5452016-06-23T20:18:58  <gmaxwell> Bitcoin tx fees were too high for them, so they only use bitcoin for periodic commitments and they use testnet as a messaging flooding network.
5462016-06-23T20:19:28  <jtimon> sorry, was afk
5472016-06-23T20:19:51  <helo> god forbid they form their own relay network that actually fits their use case
5482016-06-23T20:20:10  <btcdrak> helo: they are too lazy.
5492016-06-23T20:20:19  <gmaxwell> It's complicated.
5502016-06-23T20:22:14  <gmaxwell> I think a lot of 'programming' has split into layers, there are systems people like me that generally don't touch UIs. And 'applications' people that wont touch a protocol. ... and in the later case a very strong culture of using hosted services. (I've seen webapps calling third party rest APIs to do things like sort a list) ... so using some found network seems sensible to some people... and I'
5512016-06-23T20:22:21  <NicolasDorier> wumpus: you were whinning about testing 0.13 on windows on twitter? I can help if needed (btw, all my compact blocks tests were done on windows)
5522016-06-23T20:22:21  <gmaxwell> m certantly not out going to make some custom network for some crazy app dejure (unless they're going to pay...)
5532016-06-23T20:22:34  <CodeShark> helo: if you haven't noticed, it seems the opposite is more prevalent these days...people trying to fit their use cases to use blockchains somehow
5542016-06-23T20:23:28  <jtimon> gmaxwell: well, we could maintain a single-element (ie block signing) chain in elements...
5552016-06-23T20:24:10  <gmaxwell> helo: so I think part of it is a software norm that has arisen where you build software by using third party APIs that you find.. BUT you reconize that these centeralized APIs are a problem... sooooo a "found" distributed network is the obvious solution.
5562016-06-23T20:24:14  <CodeShark> gmaxwell: even if they're going to pay you probably have better things to do ;)
5572016-06-23T20:24:19  <gmaxwell> helo: so I think thats one component of the blockchain hype.
5582016-06-23T20:25:04  <gmaxwell> jtimon: yes, and a seperate network that used just that and was otherwise the same as bitcoin testnet
5592016-06-23T20:25:40  <jtimon> yes
5602016-06-23T20:26:48  <gmaxwell> jtimon: I dunno if anyone would use it.  it could even do a clever thing where blocks that would be reorged out are signed by seperate keys, so that users could decide if they want to see reorgs or not.
5612016-06-23T20:27:12  <btcdrak>  permissioned testnet :)
5622016-06-23T20:27:37  *** Anduck has quit IRC
5632016-06-23T20:27:38  *** bustd_soket has quit IRC
5642016-06-23T20:27:38  *** rubensayshi has quit IRC
5652016-06-23T20:27:38  *** adamg has quit IRC
5662016-06-23T20:27:38  *** musalbas has quit IRC
5672016-06-23T20:27:43  *** sipa has quit IRC
5682016-06-23T20:27:43  *** jron_ has quit IRC
5692016-06-23T20:27:43  *** hexis has quit IRC
5702016-06-23T20:27:44  *** harding has quit IRC
5712016-06-23T20:27:45  *** cfields_ has quit IRC
5722016-06-23T20:27:45  *** petertodd has quit IRC
5732016-06-23T20:27:47  *** harding has joined #bitcoin-core-dev
5742016-06-23T20:27:47  *** sipa has joined #bitcoin-core-dev
5752016-06-23T20:27:48  *** petertodd has joined #bitcoin-core-dev
5762016-06-23T20:27:53  *** Anduck has joined #bitcoin-core-dev
5772016-06-23T20:27:53  <jtimon> gmaxwell: interesting thought
5782016-06-23T20:27:56  *** hexis has joined #bitcoin-core-dev
5792016-06-23T20:28:01  *** bustd_soket has joined #bitcoin-core-dev
5802016-06-23T20:28:02  <sipa> yow
5812016-06-23T20:28:04  *** adamg has joined #bitcoin-core-dev
5822016-06-23T20:28:05  *** rubensayshi has joined #bitcoin-core-dev
5832016-06-23T20:28:15  *** jron has joined #bitcoin-core-dev
5842016-06-23T20:28:41  <helo> yeah, that sounds about right...
5852016-06-23T20:29:19  *** musalbas has joined #bitcoin-core-dev
5862016-06-23T20:29:43  *** cfields has joined #bitcoin-core-dev
5872016-06-23T20:30:12  <gmaxwell> e.g. produce a block every 5 minutes that it promses to not reorg, and otherwise produces faster blocks which it _tries_ to reorg with doublespends whenever they happen.  If you want to test something and not see reorgs, just ignore the non-guarenteed blocks.  Would be a fair amount of coding though to do the try-to-reorg behavior. But I think it would be quite valuable for some people who don't
5882016-06-23T20:30:18  <gmaxwell>  have the background/time/interest to go build a regtest test harness.
5892016-06-23T20:30:22  <gmaxwell> I can tell you that a lot of bitcoin services have no reorg handling at all. :(
5902016-06-23T20:30:32  *** zmanian__ has quit IRC
5912016-06-23T20:30:55  *** wallet42 has quit IRC
5922016-06-23T20:31:41  *** limpkin has quit IRC
5932016-06-23T20:32:14  *** zmanian__ has joined #bitcoin-core-dev
5942016-06-23T20:32:52  *** wallet42 has joined #bitcoin-core-dev
5952016-06-23T20:34:09  <da2ce7_mobile> has something happened to sipa's node, or the BIP9 chart looking very werid: http://bitcoin.sipa.be/ver9-2k.png
5962016-06-23T20:34:11  *** limpkin has joined #bitcoin-core-dev
5972016-06-23T20:34:18  <CodeShark> just to be 100% clear, the plan is no more minor releases on 0.12, merge segwit into master now but without activation parameters
5982016-06-23T20:34:24  <CodeShark> correct?
5992016-06-23T20:34:31  <gmaxwell> CodeShark: no.
6002016-06-23T20:34:35  <btcdrak> urgh
6012016-06-23T20:34:39  <btcdrak> I PMd him
6022016-06-23T20:34:56  <gmaxwell> there is nothing weird about it.
6032016-06-23T20:35:29  <da2ce7_mobile> I was expecting the CSV flags to drop straight down to zero.
6042016-06-23T20:35:37  <gmaxwell> Miners are turning off their BIP9 signaling manually (which is what I was fussing about a few days ago). It's no longer required as it locked in.
6052016-06-23T20:35:56  <sipa> da2ce7_mobile: BIP9 suggests that they don't
6062016-06-23T20:36:07  <gmaxwell> the fact that miners are manually twiddling their versions is a big long term concern and risk, but checking directly with them suggests things are fine.
6072016-06-23T20:36:08  <sipa> da2ce7_mobile: and that they keep setting the flag during the locked_in phase
6082016-06-23T20:36:17  *** bustd_soket has quit IRC
6092016-06-23T20:36:23  <da2ce7_mobile> :(
6102016-06-23T20:36:23  *** instagibbs3 has quit IRC
6112016-06-23T20:36:40  <sipa> why :(
6122016-06-23T20:36:58  <gmaxwell> presumably that was to the manual setting of bits.
6132016-06-23T20:37:02  <da2ce7_mobile> well it would be better if they followed the protocol.
6142016-06-23T20:37:40  <gmaxwell> There is a cellphone game called spaceteam where you have to call out instructions for other people to punch in to jointly fly a fictional spacecraft.  Manually setting consensus normative flags in bitcoin makes me think of spaceteam.
6152016-06-23T20:37:59  <sipa> da2ce7_mobile: the difference between theory and practice is that there is none in theory
6162016-06-23T20:38:11  <gmaxwell> "Bit 1 activate"  "set hyperdrive to on" "engage flanx warbler" "Bit 1 deactivate"
6172016-06-23T20:38:31  <sipa> check sequence verify!
6182016-06-23T20:38:38  <da2ce7_mobile> :D :D
6192016-06-23T20:38:42  <sipa> median time: set to past
6202016-06-23T20:39:23  <gmaxwell> haha   "reorganize! everybody shake!"
6212016-06-23T20:40:20  <da2ce7_mobile> Ok. It look like that CSV could be a bit of a bumpy ride when activating.
6222016-06-23T20:40:26  <gmaxwell> da2ce7_mobile: huh?
6232016-06-23T20:40:27  <sipa> set activation threshold to 95%
6242016-06-23T20:40:32  <gmaxwell> da2ce7_mobile: not at all.
6252016-06-23T20:40:54  <btcdrak> da2ce7_mobile: activation is now certain and we know which block it will occur on
6262016-06-23T20:40:57  <Lightsword> is it only eloipool based pools that manually set the version?
6272016-06-23T20:41:19  <da2ce7_mobile> well if the bits are not being auto-unset then that suggests that the miners haven't upgraded their nodes.
6282016-06-23T20:41:23  <btcdrak> Lightsword: no. we have contacted the pools who do.
6292016-06-23T20:41:31  <gmaxwell> it's locked in, the bit doesn't technically matter, we've checked with the miners who aren't setting it anymore and confirmed that they're all upgraded.. they're only not setting it now because they manually set the version (danger! danger!, but not at the moment).
6302016-06-23T20:41:50  <btcdrak> da2ce7_mobile: not at all. it just means they set the bit manually, against our advice.
6312016-06-23T20:42:11  <gmaxwell> da2ce7_mobile: they have, (well they have or they're lying) the explination is that due to how past softforks worked their infrastructure is setup to 'fake' all versions.
6322016-06-23T20:42:12  <da2ce7_mobile> ok. well in that case I'm less worried.
6332016-06-23T20:42:16  <btcdrak> it's explained here: https://bitcoincore.org/en/2016/06/08/version-bits-miners-faq/
6342016-06-23T20:42:36  <btcdrak> and also here: https://bitcoincore.org/en/2016/06/21/csv-softfork-instructions/
6352016-06-23T20:42:52  <gmaxwell> Because past softforks would orphan your blocks if you had the wrong version.   We specifically got rid of that behavior in BIP9 in part to discourage faking the versions, but this improvement is not yet well understood and the software is already written.
6362016-06-23T20:43:51  *** gluytium has joined #bitcoin-core-dev
6372016-06-23T20:44:32  <da2ce7_mobile> ok :)  you guys are way ahead of me.  Colour me impressed (yet again).
6382016-06-23T20:44:46  <gmaxwell> in any case, "we've (hopefully) got this"
6392016-06-23T20:44:48  <Lightsword> yeah, I can see why some have to set it manually, especially since some build blocks from stratum templates…not sure what the proper way to handle it with those situations would be
6402016-06-23T20:45:00  <gmaxwell> I was irritated to find people were still manually overriding it.
6412016-06-23T20:45:04  <gmaxwell> Lightsword: take the version from the template.
6422016-06-23T20:45:18  <btcdrak> Lightsword: chat with jl2012, he said he found a solution for one of the pools at least
6432016-06-23T20:46:10  <gmaxwell> We could also in GBT return a "next block version" to allowed delayed computation there. Thoug we can't do a "next block bits" which would be more useful...
6442016-06-23T20:46:38  <da2ce7_mobile> I really like BIP9. It is a really elegant solution and upgrade.
6452016-06-23T20:46:39  <gmaxwell> and part of the reason why BIP9 flag changes happen at retargets is to make the header unpredictable at the same time the bits change makes it unpredictable.
6462016-06-23T20:49:07  *** fengling has joined #bitcoin-core-dev
6472016-06-23T20:49:22  <da2ce7_mobile> sipa: while I have been following your segwit pull request(s); the code goes over my head. however it is easy to see your professionalism and dedication is really exceptional. :)
6482016-06-23T20:49:52  *** MarcoFalke has joined #bitcoin-core-dev
6492016-06-23T20:50:00  <sipa> da2ce7_mobile: thanks :)
6502016-06-23T20:50:37  <sipa> (and thank everyone who's helping... i didn't even write the majority of the code)
6512016-06-23T20:52:23  *** MarcoFalke has quit IRC
6522016-06-23T20:53:26  *** fengling has quit IRC
6532016-06-23T20:54:56  *** bustd_soket has joined #bitcoin-core-dev
6542016-06-23T20:57:22  *** Chris_Stewart_5 has quit IRC
6552016-06-23T21:12:32  *** Chris_Stewart_5 has joined #bitcoin-core-dev
6562016-06-23T21:49:54  *** fengling has joined #bitcoin-core-dev
6572016-06-23T21:54:06  *** fengling has quit IRC
6582016-06-23T21:55:14  *** Guyver2 has quit IRC
6592016-06-23T22:04:08  *** cryptapus_afk is now known as cryptapus
6602016-06-23T22:05:19  *** gluytium has quit IRC
6612016-06-23T22:20:21  *** gluytium has joined #bitcoin-core-dev
6622016-06-23T22:23:57  *** jcorgan has left #bitcoin-core-dev
6632016-06-23T22:44:02  *** cryptapus is now known as cryptapus_afk
6642016-06-23T22:50:38  *** fengling has joined #bitcoin-core-dev
6652016-06-23T22:54:46  *** fengling has quit IRC
6662016-06-23T22:59:02  *** CubicEarth has quit IRC
6672016-06-23T23:03:36  *** CubicEarth has joined #bitcoin-core-dev
6682016-06-23T23:10:33  *** pedrobranco has joined #bitcoin-core-dev
6692016-06-23T23:14:49  *** pedrobranco has quit IRC
6702016-06-23T23:15:17  *** CubicEarth has quit IRC
6712016-06-23T23:15:45  *** whogoesthere__ has joined #bitcoin-core-dev
6722016-06-23T23:23:16  *** CubicEarth has joined #bitcoin-core-dev
6732016-06-23T23:29:42  *** d9b4bef9 has quit IRC
6742016-06-23T23:30:03  *** neuroses1412 has quit IRC
6752016-06-23T23:30:15  *** d9b4bef9 has joined #bitcoin-core-dev
6762016-06-23T23:46:54  *** CubicEarth has quit IRC
6772016-06-23T23:51:20  *** fengling has joined #bitcoin-core-dev
6782016-06-23T23:55:26  *** fengling has quit IRC
6792016-06-23T23:55:55  *** gluytium has quit IRC