--- Day changed Thu Jun 23 2016
00:06 -!- coredump___ [3ba71889@gateway/web/freenode/ip.59.167.24.137] has joined #bitcoin-core-dev
00:10 -!- coredump___ [3ba71889@gateway/web/freenode/ip.59.167.24.137] has quit [Client Quit]
00:11 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Remote host closed the connection]
00:33 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-oyfcoegedqormsyn] has joined #bitcoin-core-dev
00:35 < shangzhou>  means try another channel called #bitcoin this is #bitcoin-core-dev
00:39 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
00:42 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 252 seconds]
01:07 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Remote host closed the connection]
01:32 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
01:33 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev
01:37 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has joined #bitcoin-core-dev
02:08 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
02:14 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
02:15 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Ping timeout: 260 seconds]
02:18 -!- assder [82ebc98a@gateway/web/freenode/ip.130.235.201.138] has joined #bitcoin-core-dev
02:30 -!- assder [82ebc98a@gateway/web/freenode/ip.130.235.201.138] has quit [Quit: Page closed]
02:37 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
02:38 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-oyfcoegedqormsyn] has quit [Quit: Connection closed for inactivity]
03:11 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
03:44 -!- jtimon [~quassel@217.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
03:50 < 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
04:02 < GitHub70> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9f1807af2422...147a7b6726d3
04:02 < GitHub70> bitcoin/master a1c92c2 Wladimir J. van der Laan: trivial: capitalize BIP32 in option help...
04:02 < GitHub70> bitcoin/master 147a7b6 Wladimir J. van der Laan: Merge #8246: trivial: capitalize BIP32 in option help...
04:02 < 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
04:05 < GitHub5> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/147a7b6726d3...08338942b50f
04:05 < GitHub5> bitcoin/master d80efec Peter Todd: Update petertodd's testnet seed...
04:05 < GitHub5> bitcoin/master 0833894 Wladimir J. van der Laan: Merge #8204: Update petertodd's testnet seed...
04:05 < 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
04:12 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
04:15 -!- robs [uid165609@gateway/web/irccloud.com/x-xnishtvlzqpokmdu] has quit [Quit: Connection closed for inactivity]
04:17 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Ping timeout: 276 seconds]
04:20 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has quit [Ping timeout: 240 seconds]
04:28 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
04:32 -!- cryptapus_ is now known as cryptapus
04:46 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
05:08 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:12 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
05:17 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]
05:18 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]
05:35 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection]
05:43 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
05:47 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
06:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
06:13 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
06:18 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Ping timeout: 264 seconds]
06:20 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
06:41 -!- cjcj [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has joined #bitcoin-core-dev
06:43 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
06:45 -!- xiangfu [~xiangfu@58.135.95.134] has joined #bitcoin-core-dev
06:45 < GitHub21> [bitcoin] sipa opened pull request #8247: Mark my dnsseed as supporting filtering (master...newseed) https://github.com/bitcoin/bitcoin/pull/8247
06:48 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
06:56 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]
07:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:14 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
07:18 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Ping timeout: 260 seconds]
07:21 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
07:23 -!- raedah [~x@172.56.42.64] has quit [Remote host closed the connection]
07:24 -!- raedah [~x@172.56.42.64] has joined #bitcoin-core-dev
07:26 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
07:31 -!- TomMc [~tom@unaffiliated/tommc] has quit [Quit: WeeChat 1.3]
07:44 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
07:46 -!- Greybits [~Greybits@unaffiliated/greybits] has joined #bitcoin-core-dev
07:48 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
07:50 -!- MCCCS [b0e8f51a@gateway/web/freenode/ip.176.232.245.26] has joined #bitcoin-core-dev
07:50 -!- MCCCS [b0e8f51a@gateway/web/freenode/ip.176.232.245.26] has quit [Client Quit]
07:57 < 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
08:15 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
08:19 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]
08:29 -!- xiangfu [~xiangfu@58.135.95.134] has quit [Remote host closed the connection]
08:36 -!- xiangfu [~xiangfu@58.135.95.134] has joined #bitcoin-core-dev
08:45 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
08:49 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
08:53 -!- xiangfu [~xiangfu@58.135.95.134] has quit [Remote host closed the connection]
09:06 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has joined #bitcoin-core-dev
09:08 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has quit [Client Quit]
09:15 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
09:20 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Ping timeout: 250 seconds]
09:36 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
09:50 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection]
09:50 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
10:00 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
10:03 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection]
10:04 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
10:07 -!- Greybits [~Greybits@unaffiliated/greybits] has quit [Quit: Leaving]
10:16 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
10:21 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Ping timeout: 252 seconds]
10:26 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
10:43 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []
10:46 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
10:48 -!- jtimon [~quassel@217.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]
10:51 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
11:04 -!- jtimon [~quassel@217.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
11:07 -!- spudowiar1 [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
11:10 -!- spudowiar1 [~spudowiar@unaffiliated/spudowiar] has quit [Client Quit]
11:21 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer]
11:21 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
11:26 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Ping timeout: 276 seconds]
11:26 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Ping timeout: 250 seconds]
11:37 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-nagqtkdyclzltggh] has quit [Excess Flood]
11:37 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-pdhjcdhawubsbeel] has joined #bitcoin-core-dev
11:40 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
11:44 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Ping timeout: 252 seconds]
11:46 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev
12:00 <@wumpus> meeting time?
12:00 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Remote host closed the connection]
12:01 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
12:02 < sipa> present
12:02 < gmaxwell> past?
12:02 <@wumpus> #startmeeting
12:02 < lightningbot> Meeting started Thu Jun 23 19:02:40 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:02 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:03 <@wumpus> any proposed topics?
12:04 <@wumpus> I think https://github.com/bitcoin/bitcoin/issues/8245 needs discussion, whether reindex/verification slowed down
12:04 < gmaxwell> sdaftuar: sipa: phantomcircuit: jonasschnelli: MarcoFalke: jtimon: phantomcircuit: instagibbs: petertodd: morcos:
12:04 < sipa> ack topic
12:04 < gmaxwell> ack.
12:04 < 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
12:04 <@wumpus> #topic perceived validation slowdowns
12:04 < sipa> i noticed very slow chainstate writes (close to a minute, even though the chainstate is only 53 MB)
12:05 < 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.
12:05 < sipa> though this may be due to my laptop's disk setup (zfs on encrypted lvm volume)
12:05 <@wumpus> so, some people are noticiing slow validation, I wonder what changed there
12:05 < gmaxwell> (two identical hosts)
12:05 < sipa> from gmaxwell's numbers, it does not look like his time is dominated by database flushes, however
12:05 < gmaxwell> I think I am often guilty of only testing things with a non-default dbcache.
12:06 < sipa> likewise
12:06 < gmaxwell> I previously _expected_ reindex to be slow due to the signature checking.
12:06 <@wumpus> I usually run with default dbcache
12:06 < jtimon> maybe a solution would be to change the default dbcache for something more common among testers?
12:06 < 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.
12:06 < sipa> jtimon: we still need to figure out what is behind this... but independently, yes
12:06 <@wumpus> yes, we should definitely crank up the dbcache no matter what
12:06 <@wumpus> but I like to know what happened
12:07 < jtimon> sipa: yeah, of course, I meant independently
12:07 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
12:07 <@wumpus> should at least try to bisec tthis, I know it's frustrating as everything takes so long :)
12:08 < sipa> oh, this is with txindex enabled
12:08 < 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?
12:08 <@wumpus> gmaxwell didn't you have some suspicions that CB would affect initial sync? could that also affect reindex?
12:08 <@wumpus> not in my case
12:08 < sipa> wumpus: gmaxwell's test was before cb was merged
12:08 < gmaxwell> my test is without cb merged, also the CB concern was just related to general sync logic, not processing.
12:08 < jtimon> are there recent changes that people suspect may have caused the regression ?
12:09 <@wumpus> wouldbe good to test against #7917, as many people benchmarked that
12:09 <@wumpus> and it was perceived fast at the time
12:09 <@wumpus> jtimon: not really
12:09 < 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.
12:10 < 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.
12:10 < gmaxwell> (maybe not leveldb itself being slow, e.g. making extranious accesses to it)
12:10 <@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
12:10 < 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
12:11 < gmaxwell> So actions are. determine if regression, if so where, ... seperately, consider a dbcache increase for the next release.
12:11 <@wumpus> I doubt it is leveldb itself as there haven't been changed to that for ages
12:11 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
12:11 < gmaxwell> sipa: yes this might be txindex related. I can test that too.
12:11 <@wumpus> yes, txindex is *slow*
12:11 < CodeShark> is something slowing down validation that wasn't before?
12:11 < sipa> CodeShark: maybe
12:11 <@wumpus> lots of extra I/O. I also made that mistake once
12:11 < gmaxwell> wumpus: we have changed (reduced) the amount of interaction with leveldb during validation.
12:11 <@wumpus> gmaxwell: sure, it may be the level above leveldb
12:12 < sipa> yes, it may be
12:12 <@wumpus> I just don't suspect the databse itself this time
12:12 < 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.
12:12 <@wumpus> unless some compiler flag changed things shockingly, say, the c++11 switch, but I doubt it
12:12 < 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.
12:13 < sipa> i briefly suspected the IsInitialBlockDownload change, but apart from using an atomic, its semantics should be unchanged
12:13 <@wumpus> especialy if you see the slowdown in the flush; txindex writes a lot of data to the block index databse
12:13 < sipa> wumpus: but the txindex writes don't happen during the flush
12:13 <@wumpus> so maybe false alarm, the sync is slow, news at 11
12:13 < sipa> wumpus: though they may accumulate somewhere in leveldb until a flush is issued
12:14 < CodeShark> can't we add tracers around calls to narrow it down?
12:14 < gmaxwell> wumpus: well, the "lets increase the dbcache" is still a useful response to this catching attention again.
12:14 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
12:14 < sipa> action points: benchmark in same conditions without txindex, and with larger dbcache?
12:14 <@wumpus> yes we should increate the dbcache, and probably change how it is allocated
12:15 <@wumpus> (e.g. a relatively large part now goes to leveldb caches, that's a waste
12:15 < gmaxwell> (as my laptop is about to be on day three of reindex)
12:15 < sipa> wumpus: the reasoning was that leveldb cache is serialized, so it has a much large impact per byte than the internal cache
12:15 <@wumpus> leveldb's own caches are completely ineffective compared to bitcoind's application level cache
12:15 < sipa> but it has the deserialization overhead
12:16 -!- instagibbs2 [~test@pool-100-15-114-5.washdc.fios.verizon.net] has joined #bitcoin-core-dev
12:16 < sipa> but that's mostly a guess without substansive benchmarking
12:16 <@wumpus> sipa: that makes a lot of sense in theory, but leveldb just sucks at caching :)
12:16 < gmaxwell> I can benchmark a bunch of mixes of cache sizes and see how they pan out.
12:16 < 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
12:17 <@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
12:17 < jtimon> not sure I'm following but maybe we want separate options for the "internal" and "external" caches?
12:17 <@wumpus> jtimon: for testing that'd be awesome
12:17 < sipa> jtimon: for testing that makes sense, but as a product it should work well with the fewest number of tunable possible
12:17 < 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)
12:17 < sipa> jynx
12:17 < instagibbs2> On phone but present
12:18 < jtimon> there's some options that can only be accessed if --debug, right?
12:18 <@wumpus> gmaxwell: you'd be surprised :-)
12:18 <@wumpus> some users are very persistent in trying to find settings that are fastest for them
12:18 < CodeShark> I'd venture to say it's probably not the majority
12:18 <@wumpus> but yes, it should be a hidden option (--help-debug)
12:18 < jtimon> oh, no they may not be showed in the help but they're still accesible I think
12:18 <@wumpus> CodeShark: sure, but don't underestimate peole
12:19 < sipa> wumpus: maybe such options should be marked with ("If you find a setting for this value that improves performance, please let us know")
12:19 <@wumpus> sipa: +1 :D
12:19 < gmaxwell> -funroll-loops -O20 
12:19 < sipa> -femit-broken-code
12:20 <@wumpus> -fskip-computing-even-bits
12:20 <@wumpus> ok, any other topics?
12:20 < sipa> relatedly, i think -qt can by default use more ram
12:20 < sipa> also, 100 mb is kinda ridiculous with the mempool already being 300 mb
12:20 <@wumpus> yes, probably, although qt itself also uses more ram
12:21 <@wumpus> yes, agreed
12:21 < sipa> other topic: merge segwit yay or nay
12:21 <@wumpus> let's reduce the mempool to 100mb and increase dbcache to 300mb 
12:21 < 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.
12:21 < petertodd> sipa: re: segwit, has it been rebased?
12:21 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has joined #bitcoin-core-dev
12:21 <@wumpus> #topic segwit
12:21 < sipa> petertodd: 12 times by now
12:21 < CodeShark> lol
12:21 < sipa> see 8149
12:21 < CodeShark> poor sipa
12:21 < jtimon> how can we feature freeze without merging segwit?
12:22 -!- laurentmt [~Thunderbi@213-245-86-6.rev.numericable.fr] has quit [Client Quit]
12:22 <@wumpus> sipa is getting carpal tunnel syndrome from rebasing
12:22 < 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. 
12:22 <@wumpus> jtimon: softforks / consensus changes don't count as software features
12:22 <@wumpus> jtimon: that's also why they're allowed to be introduced in minor versions
12:22 < petertodd> sipa: I mean, is the current pull-req rebased since compact blocks got merged?
12:22 < gmaxwell> also it's not even activated in any case. it's pure code updates.
12:22 < sipa> petertodd: yes
12:22 < jtimon> wumpus: so it won't be possible to include any feature post segwit merge in 0.13 ?
12:22 < CodeShark> current is #8149, yes?
12:23 < 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)
12:23 <@wumpus> jtimon: right, 0.13 is closed feature-wise
12:23 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Remote host closed the connection]
12:23 < 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.
12:23 <@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)
12:24 < jtimon> wumpus: that is a no, that is unconvenient and I wasn't expecting it, but thanks
12:24 -!- instagibbs3 [~test@2607:fb90:6484:1847:f36:5be3:d294:8977] has joined #bitcoin-core-dev
12:24 <@wumpus> #link see the release schedule here: https://github.com/bitcoin/bitcoin/issues/8250
12:24 < CodeShark> sipa: which PR should we be testing against?
12:24 < jtimon> yeah, should have asked "what about segwit?" back then
12:25 < sipa> CodeShark: 8149 and 7190 are the exact same code
12:25 < sipa> so whatever you like
12:25 < gmaxwell> I had completed review up to the CB rebase, which I have not looked at yet.
12:26 < gmaxwell> (I mean I haven't looked at segwit's rebase for CB)
12:26 < 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
12:26 < sipa> git show -w c4e3c755d7e41aaabe74c84af7e4bf00a62c96fb
12:26 -!- instagibbs2 [~test@pool-100-15-114-5.washdc.fios.verizon.net] has quit [Ping timeout: 258 seconds]
12:26 < sipa> and then search for cmpctblk and blocktxn
12:27 < sipa> to see the changes related to that
12:27 < btcdrak> oh I'm late
12:27 <@wumpus> jtimon: we all would have preferred other timings, but we have to cope with how things actually are :)
12:27 < jtimon> I planned to rebase/rewrite some of the consensus encapsulation code after segwit, I guess the plan doesn't change anyway
12:28 <@wumpus> well you can still do that, it just won't make 0.13
12:28 < jtimon> wumpus: well, yeah, I could have helped more with reviewing and testing segwit
12:28 < gmaxwell> sipa: thanks, will review once I start up the test panel for the prior topic. :)
12:28 < jtimon> wumpus: understood
12:29 < sipa> jtimon: you can still do that, even after merge :)
12:29 < gmaxwell> yes, post merge review and testing is super important too.
12:29 <@wumpus> yes, absolutely
12:29 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds]
12:30 < 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)
12:30 < 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
12:30 < gmaxwell> Obviously there may still need to be some fixes and nits. But thats what we have time for.
12:30 < sipa> (compared to running just cb before)
12:30 <@wumpus> anyone against merging segwit?
12:31 <@wumpus> (I mean right now, not in general)
12:32 <@wumpus> *crickets*
12:32 < sipa> i have no objections :)
12:32 <@wumpus> that's clear then
12:32 < btcdrak> I'd like to see it merged too
12:32 <@wumpus> yes, I understood
12:32 < jtimon> sipa: yeah, it just won't make it to 0.13 as wumpus explained
12:32 < CodeShark> the sooner the better (as long as it doesn't break current behavior)
12:32 <@wumpus> #action Merge segwit
12:32 -!- MarcoFalke [~marco@p57A87852.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
12:32 < btcdrak> o/
12:33 < 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.
12:33 < instagibbs3> Good. 
12:33 < 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?
12:34 < petertodd> gmaxwell: fine by me
12:34 < sipa> i believe jonasschnelli builds nightly binaries
12:34 <@wumpus> sure, why not
12:34 <@wumpus> I prefer doing that outside the 'official' release cycle, but I don't mind running gitian for it
12:34 < 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. :)
12:35 < gmaxwell> yes, I don't want something part of the release cycle. Just binaries to give to power users to give it a spin.
12:35 <@wumpus> testnet-only
12:35 < CodeShark> testnet as in not segnet, right?
12:35 < gmaxwell> yea, pre-RC testnet only, we could one line patch to change the default network, so it'll be easier to use.
12:36 < sipa> CodeShark: segnet has been removed a few weeks ago from the patch
12:36 < gmaxwell> Testnet is segwit now. Segnet is dead long live segnet.
12:36 < petertodd> gmaxwell: maybe better to just make it fail unless -testnet is enabled, in case someone does run it in production
12:36 <@wumpus> no, not segnet. Regtest could be allowed. But mainnet disabled and testnet as default
12:36 < CodeShark> is segwit live on testnet?!?!
12:36 < gmaxwell> yea. exactly.
12:36 < sipa> CodeShark: yes, since months
12:37 <@wumpus> petertodd: what is the worst that could happen if you accidentally run testnet?
12:37 < petertodd> wumpus: hard to know!
12:37 < 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?
12:37 < 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
12:37 <@wumpus> at least the default ports etc will be different, default data dir is different, etc
12:37 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
12:38 <@wumpus> petertodd: apart from GUI users I guess
12:38 < 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.
12:38 < sipa> i believe this is a nit not worth minutes of discussion time
12:38 < petertodd> wumpus: yes, but imagine someone has an automated system setup which calls bitcoin-cli...
12:38 < gmaxwell> in any case, can be discussed later or not.
12:38 < gmaxwell> :)
12:38 < btcdrak> any more topics?
12:39 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
12:40 < jtimon> are we merging the bip9 activation parameters for testnet?
12:40 < CodeShark> hmm - I don't see the activation parameters for segwit on testnet
12:40 < CodeShark> how can it be live on testnet?
12:40 < jtimon> CodeShark: people running custom code I assume
12:40 < sipa> CodeShark: in the segwit branch
12:41 < jtimon> oh
12:41 < sipa> not in master
12:41 < btcdrak> CodeShark: it was activated months ago
12:41 < CodeShark> yes, but I'm still confused as to the release here
12:41 < CodeShark> shouldn't testnet only run stuff that's been merged?
12:42 < instagibbs3> bip 9 activation can still be set. 
12:42 < btcdrak> no, we set the parameters
12:42 < gmaxwell> CodeShark: we wanted testing in a mixed enviroment with most nodes not upgraded.
12:42 < btcdrak> and that allowed a miner to activate it
12:42 < sipa> CodeShark: it was a very useful testing exercise
12:42 < gmaxwell> CodeShark: since thats realistic.
12:42 < gmaxwell> and segnet couldn't easily provide that.
12:43 < CodeShark> sure, I'm all for the additional testing - I'm just concerned about breaking the master builds for testnet
12:43 < gmaxwell> CodeShark: it's a softfork, hurrah.
12:43 < sipa> (although, there are so few testnet segwit nodes running right now that it really does not work without -addnode)
12:43 < jtimon> answer my own question: yes, the testnet activation is part of #7910 : https://github.com/bitcoin/bitcoin/pull/8149/files#diff-64cbe1ad5465e13bc59ee8bb6f3de2e7R191
12:43 < CodeShark> gmaxwell: yes, but it will still break miners. however, if no issues arose as a result I'm fine with it
12:43 < sipa> CodeShark: testnet miners are clearly already running it
12:44 < CodeShark> yes, indeed
12:44 < sipa> so how could merging break anything for them?
12:44 < CodeShark> nvm, all's good
12:44 < 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)
12:44 < gmaxwell> er, wouldn't have been
12:45 < jtimon> it is the first time a softfork is activated on testnet before it is in master thought, right?
12:45 < 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.
12:45 < gmaxwell> Are the testnet seeds running the code that can give filtered responses?
12:45 < sipa> indeed, and we can test the dns filtering
12:45 < sipa> gmaxwell: jonasschnelli's is
12:45 < sipa> not sure about petertodd's
12:45 < sipa> oh, yes
12:45 < sipa> https://github.com/bitcoin/bitcoin/pull/8204
12:46 < sipa> petertodd: are you sure that's running the filtering code?
12:46 < jtimon> gmaxwell: the "testnet only" builds are just from master after merging segwit, right?
12:47 < sipa> jtimon: yes
12:47 < petertodd> sipa: should be
12:47 < 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.
12:47 < petertodd> sipa: I'll recheck
12:47 < sipa> x9.seed.tbtc.petertodd.org gives many results, more than i'd expect
12:47 < petertodd> sipa: note that it is running with extra args to support rbf
12:47 < gmaxwell> jtimon: yes, likely with a trivial patch to change it to default to testnet (or require it). (and maybe a renamed binary)
12:47 < petertodd> sipa: so maybe there's a bug there that you haven't run into yet
12:48 < sipa> petertodd: can i see the code for that?
12:48 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
12:48 < jtimon> gmaxwell: why the changes? aren't this power users?
12:48 < sipa> after the meeting, please
12:48 < petertodd> sipa: it's with the command line arg; which incidentlaly was broken when I tried it (see my pullreq)
12:49 < gmaxwell> any other topics for this meeting?
12:49 <@wumpus> doesn't seem so
12:49 <@wumpus> #endmeeting
12:49 < lightningbot> Meeting ended Thu Jun 23 19:49:58 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:49 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-23-19.02.html
12:49 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-23-19.02.txt
12:49 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-23-19.02.log.html
12:50 < sipa> petertodd: are you including -w 9 ?
12:50 < jtimon> oh, I think we forgot to make a joke, that's bad for the summaries :p
12:51 < btcdrak> there is plenty comic relief there
12:51 < 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. 
12:51 < petertodd> sipa: yeah, I think so
12:51 < btcdrak> wumpus: so is segwit is the last feature PR and now 0.13 is frozen?
12:51 < gmaxwell> segwit is not a feature PR
12:52 < gmaxwell> and 0.13 has been frozen for a bit now.
12:52 <@wumpus> as gmaxwell says ^^
12:52 < btcdrak> fine
12:52 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
12:52 < gmaxwell> (it's especially not a feature PR with it not yet activated in mainnet. :) )
12:52 < jtimon> gmaxwell: whatever, the patch to change the default and/or disable mainnet should be trivial anyway
12:52 < sipa> i'd be perfectly fine with that binary also supporting mainnet
12:52 < gmaxwell> jtimon: yup. if it were hard I wouldn't have suggsted it. I think it's useful but not of great importance.
12:53 < jtimon> I think I disagree with the notion that "the segwit PR is not a feature"
12:53 < 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). 
12:53 < gmaxwell> jtimon: I feel sorry for you then?  It's not even exposed in 0.13 as merged.
12:54 -!- MarcoFalke [~marco@p57A87852.dip0.t-ipconnect.de] has quit [Quit: MarcoFalke]
12:54 <@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
12:54 < 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)
12:55 < jtimon> gmaxwell: precisely I thought the "softforks are minor releases" applied to the activation, not to the inactive code
12:55 < gmaxwell> jtimon: sure though inactive code is not a feature either.
12:55 < CodeShark> if it includes the testnet code I'd argue it is a feature
12:55 < gmaxwell> wumpus: that would be fantastic, and would radically increase the use of testnet, I expect.
12:56 < gmaxwell> CodeShark: A feature for testnet. ooohkay.
12:56 < gmaxwell> I don't disagree but I don't think the distinction is important.
12:56 < gmaxwell> Testnet is not very serious, as much as I'd like it to be more serious. It's often pretty broken.
12:57 < CodeShark> going forward, as long as activation parameters for testnet softforks are documented somewhere and we agree on them it seems ok
12:57 < btcdrak> CodeShark: they are already documented: https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki
12:57 < gmaxwell> Not sure how you missed the couple weeks of discussion about segwit in testnet before.
12:58 < CodeShark> I remember the discussion - I just wasn't clear on the release cycle as it pertains to testnet
12:58 < jtimon> yeah, I think that's the source of the discussion
12:58 < btcdrak> there is no release cycle. miners can apply whatever sfs they like at any time
12:59 < jtimon> not saying necessarily the new method is worse, but it has changed
12:59 < 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.
12:59 < jtimon> well, "release cycle", "modus operandi", whatever
12:59 <@wumpus> I don't think the distinction is important either
12:59 <@wumpus> we just need segwit out, and everything that helps the testing and review process is great
13:00 < gmaxwell> (e.g. you didn't see any of us howling about release cycle when jtoomim was using the XT hardfork on it)
13:00 <@wumpus> we're not goingn to block segwit on a procedural detail
13:00 < btcdrak> jtimon: there isnt a release cycle. The consensus rules of the network are not defined by a release cycle of software
13:00 < btcdrak> gmaxwell: exactly
13:00 < gmaxwell> as btcdrak said.
13:01 < 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.
13:01 < 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
13:01 < gmaxwell> esp when the thing we're trying to test is deployment of a feature in a non-upgraded network. :)
13:02 < 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
13:02 < sipa> CodeShark: there have been proposals in the past for having multiple testnetd
13:02 < 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.
13:02 < 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
13:02 < gmaxwell> and if they were, we could easily move more disruptive things to other testnets.
13:03 < jtimon> btcdrak: ack
13:03 < 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)
13:04 <@wumpus> jtimon: sure, I just get crazy from all the time pressure and all the different things that pop up
13:04 <@wumpus> jtimon: I don't have much trust in anything ever being done the 'ideal' way :-)
13:04 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]
13:04 < 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)
13:04 < jtimon> wumpus: not regreting anything rewarding segwit
13:04 < 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
13:05 < 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. :)
13:05 <@wumpus> jtimon: well the critical thing is that segwit is reviewed and tested enough, that there are no technical concerns with merging it
13:05 < CodeShark> not sure it's necessary to test on testnet itself
13:05 < CodeShark> at least for an application developer
13:05 < CodeShark> although there is a benefit to us
13:05 < gmaxwell> er after dersig was released.
13:05 < jtimon> wumpus: ack
13:05 <@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
13:05 < 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.
13:05 < sipa> well, maybe having a windows desktop shortcut for testnet makes it more visible and attractive to test on
13:06 < gmaxwell> E.g. left to their own devices reorg handling may be compeltely untested.
13:06 < gmaxwell> also testnet is useful for interworking tests between multiple implementations.
13:06 < sipa> i would love to see an actually operational test network, where you can try sending from testnet bitgo to testnet bitawesomewallet or something
13:06 < jtimon> wumpus: that's perfect. I'm not criticizing. Just wondering if things can be done EVEN better
13:06 < gmaxwell> I've joked before, but really seriously, that someone should setup a dumb gambling thing on testnet.
13:07 < gmaxwell> I spent much of 2012 begging services to setup testnet instances of themselves with play money, without much luck.
13:07 < 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
13:07 <@wumpus> the only services that exist for testnet seem to be some block explorers, also mostly broken
13:08 <@wumpus> I think regtest made it too attractive to set up internal testing networks :-)
13:08 <@wumpus> jtimon: agree, there's always room for improvement
13:08 < 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
13:09 <@wumpus> testnet has 'more features', e.g. no standardness
13:09 < 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.
13:09 < CodeShark> with regtest you can definitely do more rigorous testing - given you have programs that can simulate network conditions on it
13:09 < gmaxwell> jtimon: softforks have pretty much always activated first on testnet.
13:09 < 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. :)
13: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
13:10 < 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.
13:10 <@wumpus> gmaxwell: (not that that kind of testing isn't useful, but it just isn't very popular)
13:10 <@wumpus> it requires people actually paying attention on the fly :)
13:11 < gmaxwell> unpredictablity of blocktimes on testnet has not helpped for application testing.
13:11 -!- robs [uid165609@gateway/web/irccloud.com/x-lwzgxdmnhgabhdth] has joined #bitcoin-core-dev
13:11 <@wumpus> also unrealistic reorgs
13:12 < 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. 
13:12 <@wumpus> whole runs of difficulty-1 blocks that are reorged away suddenly
13:13 < btcdrak> there is no incentive to mine on testnet. that is the main issue
13:13 <@wumpus> btcdrak: right - if there was, then testnet coins would have a value
13:13 < 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.
13:15 < 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.
13:15 < btcdrak> gmaxwell: i like the idea of testnet block signers.
13:15 < 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.
13:15 < 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.
13:17 < 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
13:17 < 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.
13:17 < 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
13:17 < gmaxwell> CodeShark: its mostly not used for that. The most use it gets is breaking secondary implementations.
13:18 < gmaxwell> halariously, there is one of these "messaging via the blockchain" spammy things that uses testnet for production.
13:18 < 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.
13:19 < jtimon> sorry, was afk
13:19 < helo> god forbid they form their own relay network that actually fits their use case
13:20 < btcdrak> helo: they are too lazy.
13:20 < gmaxwell> It's complicated.
13:22 < 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'
13:22 < 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)
13:22 < gmaxwell> m certantly not out going to make some custom network for some crazy app dejure (unless they're going to pay...)
13:22 < 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
13:23 < jtimon> gmaxwell: well, we could maintain a single-element (ie block signing) chain in elements...
13:24 < 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.
13:24 < CodeShark> gmaxwell: even if they're going to pay you probably have better things to do ;)
13:24 < gmaxwell> helo: so I think thats one component of the blockchain hype.
13:25 < gmaxwell> jtimon: yes, and a seperate network that used just that and was otherwise the same as bitcoin testnet
13:25 < jtimon> yes
13:26 < 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. 
13:27 < btcdrak>  permissioned testnet :)
13:27 -!- Netsplit *.net <-> *.split quits: cfields_, harding, rubensayshi, hexis, sipa, adamg, musalbas, bustd_soket, Anduck, jron_,  (+1 more, use /NETSPLIT to show all of them)
13:27 -!- Netsplit over, joins: harding
13:27 -!- sipa [~pw@2a02:348:86:3011::1] has joined #bitcoin-core-dev
13:27 -!- Netsplit over, joins: petertodd
13:27 -!- Netsplit over, joins: Anduck
13:27 < jtimon> gmaxwell: interesting thought
13:27 -!- Netsplit over, joins: hexis
13:28 -!- bustd_soket [~weechat@unaffiliated/loteriety] has joined #bitcoin-core-dev
13:28 < sipa> yow
13:28 -!- Netsplit over, joins: adamg
13:28 -!- Netsplit over, joins: rubensayshi
13:28 -!- jron [~okok@54.161.129.226] has joined #bitcoin-core-dev
13:28 < helo> yeah, that sounds about right...
13:29 -!- Netsplit over, joins: musalbas
13:29 -!- cfields [~quassel@unaffiliated/cfields] has joined #bitcoin-core-dev
13:30 < 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
13:30 < gmaxwell>  have the background/time/interest to go build a regtest test harness.
13:30 < gmaxwell> I can tell you that a lot of bitcoin services have no reorg handling at all. :(
13:30 -!- zmanian__ [sid113594@gateway/web/irccloud.com/x-gxpomwonphpiiorn] has quit [Ping timeout: 258 seconds]
13:30 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-dsayumsjmsgievvv] has quit [Ping timeout: 258 seconds]
13:31 -!- limpkin [sid20909@gateway/web/irccloud.com/x-gvcngrgcudbwdmty] has quit [Ping timeout: 258 seconds]
13:32 -!- zmanian__ [sid113594@gateway/web/irccloud.com/x-yfcnsukewvfnwkzx] has joined #bitcoin-core-dev
13:32 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-umprapwslhdrzvbw] has joined #bitcoin-core-dev
13:34 < da2ce7_mobile> has something happened to sipa's node, or the BIP9 chart looking very werid: http://bitcoin.sipa.be/ver9-2k.png
13:34 -!- limpkin [sid20909@gateway/web/irccloud.com/x-yyqdngnvlzgfnwqi] has joined #bitcoin-core-dev
13:34 < 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
13:34 < CodeShark> correct?
13:34 < gmaxwell> CodeShark: no.
13:34 < btcdrak> urgh
13:34 < btcdrak> I PMd him
13:34 < gmaxwell> there is nothing weird about it.
13:35 < da2ce7_mobile> I was expecting the CSV flags to drop straight down to zero.
13:35 < 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.
13:35 < sipa> da2ce7_mobile: BIP9 suggests that they don't
13:36 < 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.
13:36 < sipa> da2ce7_mobile: and that they keep setting the flag during the locked_in phase
13:36 -!- bustd_soket [~weechat@unaffiliated/loteriety] has quit [Ping timeout: 258 seconds]
13:36 < da2ce7_mobile> :(
13:36 -!- instagibbs3 [~test@2607:fb90:6484:1847:f36:5be3:d294:8977] has quit [Ping timeout: 250 seconds]
13:36 < sipa> why :(
13:36 < gmaxwell> presumably that was to the manual setting of bits.
13:37 < da2ce7_mobile> well it would be better if they followed the protocol.
13:37 < 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.
13:37 < sipa> da2ce7_mobile: the difference between theory and practice is that there is none in theory
13:38 < gmaxwell> "Bit 1 activate"  "set hyperdrive to on" "engage flanx warbler" "Bit 1 deactivate"
13:38 < sipa> check sequence verify!
13:38 < da2ce7_mobile> :D :D
13:38 < sipa> median time: set to past
13:39 < gmaxwell> haha   "reorganize! everybody shake!"
13:40 < da2ce7_mobile> Ok. It look like that CSV could be a bit of a bumpy ride when activating.
13:40 < gmaxwell> da2ce7_mobile: huh?
13:40 < sipa> set activation threshold to 95%
13:40 < gmaxwell> da2ce7_mobile: not at all.
13:40 < btcdrak> da2ce7_mobile: activation is now certain and we know which block it will occur on 
13:40 < Lightsword> is it only eloipool based pools that manually set the version?
13:41 < da2ce7_mobile> well if the bits are not being auto-unset then that suggests that the miners haven't upgraded their nodes.
13:41 < btcdrak> Lightsword: no. we have contacted the pools who do.
13:41 < 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). 
13:41 < btcdrak> da2ce7_mobile: not at all. it just means they set the bit manually, against our advice.
13:42 < da2ce7_mobile> ok. well in that case I'm less worried.
13:42 < 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.
13:42 < btcdrak> it's explained here: https://bitcoincore.org/en/2016/06/08/version-bits-miners-faq/
13:42 < btcdrak> and also here: https://bitcoincore.org/en/2016/06/21/csv-softfork-instructions/
13:42 < 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.
13:43 -!- gluytium [~g@c-67-190-234-214.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
13:44 < da2ce7_mobile> ok :)  you guys are way ahead of me.  Colour me impressed (yet again).
13:44 < gmaxwell> in any case, "we've (hopefully) got this"
13:44 < 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
13:45 < gmaxwell> I was irritated to find people were still manually overriding it.
13:45 < gmaxwell> Lightsword: take the version from the template.
13:45 < btcdrak> Lightsword: chat with jl2012, he said he found a solution for one of the pools at least
13:46 < 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...
13:46 < da2ce7_mobile> I really like BIP9. It is a really elegant solution and upgrade.
13:46 < 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.
13:49 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
13:49 < 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. :)
13:49 -!- MarcoFalke [~marco@p57A87852.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
13:50 < sipa> da2ce7_mobile: thanks :)
13:50 < sipa> (and thank everyone who's helping... i didn't even write the majority of the code)
13:52 -!- MarcoFalke [~marco@p57A87852.dip0.t-ipconnect.de] has quit [Client Quit]
13:53 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
13:54 -!- bustd_soket [~weechat@unaffiliated/loteriety] has joined #bitcoin-core-dev
13:57 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]
14:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
14:49 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
14:54 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
14:55 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
15:04 -!- cryptapus_afk is now known as cryptapus
15:05 -!- gluytium [~g@c-67-190-234-214.hsd1.fl.comcast.net] has quit [Max SendQ exceeded]
15:20 -!- gluytium [~g@c-67-190-234-214.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
15:23 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has left #bitcoin-core-dev []
15:44 -!- cryptapus is now known as cryptapus_afk
15:50 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
15:54 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
15:59 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Remote host closed the connection]
16:03 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
16:10 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
16:14 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Ping timeout: 260 seconds]
16:15 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Remote host closed the connection]
16:15 -!- whogoesthere__ [44af4171@gateway/web/freenode/ip.68.175.65.113] has joined #bitcoin-core-dev
16:23 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
16:29 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection]
16:30 -!- neuroses1412 [~neuroses@unaffiliated/neuroses1412] has quit [Ping timeout: 244 seconds]
16:30 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev
16:46 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Remote host closed the connection]
16:51 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
16:55 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
16:55 -!- gluytium [~g@c-67-190-234-214.hsd1.fl.comcast.net] has quit [Max SendQ exceeded]
17:20 -!- whogoesthere__ [44af4171@gateway/web/freenode/ip.68.175.65.113] has quit [Ping timeout: 250 seconds]
17:26 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
17:29 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
17:33 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
17:42 -!- raedah [~x@172.56.42.64] has quit [Remote host closed the connection]
17:45 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit []
17:49 -!- harrymm [~wayne@104.237.91.245] has left #bitcoin-core-dev []
17:54 < phantomcircuit> sipa: is the block/headers synchronziation strategy documented anywhere?
17:55 < phantomcircuit> (mostly im interested in the intended operation)
17:55 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ziijwboxnvlvelpn] has quit [Quit: Connection closed for inactivity]
18:08 -!- gluytium [~g@c-67-190-234-214.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
18:11 -!- raedah [~x@172.56.42.64] has joined #bitcoin-core-dev
18:17 -!- raedah [~x@172.56.42.64] has quit [Remote host closed the connection]
18:33 -!- gluytium [~g@c-67-190-234-214.hsd1.fl.comcast.net] has quit [Ping timeout: 250 seconds]
19:04 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 252 seconds]
19:04 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
19:59 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
20:00 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
20:10 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has joined #bitcoin-core-dev
20:30 -!- xiangfu [~xiangfu@58.135.95.134] has joined #bitcoin-core-dev
21:05 -!- robs [uid165609@gateway/web/irccloud.com/x-lwzgxdmnhgabhdth] has quit [Quit: Connection closed for inactivity]
21:48 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
22:10 < sipa> phantomcircuit: it's complicated...
22:12 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds]
22:16 < phantomcircuit> sipa, that's uh
22:16 < phantomcircuit> sipa, can you explain it to me?
22:16 -!- JackH [~Jack@79-73-186-51.dynamic.dsl.as9105.com] has quit [Ping timeout: 258 seconds]
22:29 < sipa> yes
22:30 < sipa> during initial sync, we send a getheaders to one peer only; outside of it we send it to all
22:30 < sipa> from headers responses we learn what blocks peers have
22:31 < sipa> and then in sendmessages determine which blocks to fetch from whom, subject to various conditions
22:31 < sipa> that's the parallel fetch
22:32 < sipa> there is also the direct fetch, in response to a block 'inv', which (a) sends a getheaders from that inv (b) sends a getdata if we believe we're close to being synced
22:33 < sipa> and then there is bip130, which introduces direct fetch in response to headers
22:34 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev
22:34 < sipa> phantomcircuit: for more detail i need to look at the code
22:36 < phantomcircuit> sipa, ok that's helpful
22:37 < sipa> an invariant is that we never send a second request for a block that is already in flight, but we have timeouts that will disconnect (but not ban) a peer that takes too long
22:41 < gmaxwell> with compact blocks that could potentially be relaxed in the future. fetching a redundant compact block is not going to push you over being able to keep up with the network.
22:41 < gmaxwell> nor would a redundant blocktxn so long as it was less than half the block worth of data.
22:58 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-kpacyjsattfiquxg] has joined #bitcoin-core-dev
23:11 -!- jtimon [~quassel@217.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]