< 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
<@wumpus>
#topic perceived validation slowdowns
< sipa>
i noticed very slow chainstate writes (close to a minute, even though the chainstate is only 53 MB)
< 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.
< sipa>
though this may be due to my laptop's disk setup (zfs on encrypted lvm volume)
<@wumpus>
so, some people are noticiing slow validation, I wonder what changed there
< gmaxwell>
(two identical hosts)
< sipa>
from gmaxwell's numbers, it does not look like his time is dominated by database flushes, however
< gmaxwell>
I think I am often guilty of only testing things with a non-default dbcache.
< sipa>
likewise
< gmaxwell>
I previously _expected_ reindex to be slow due to the signature checking.
<@wumpus>
I usually run with default dbcache
< jtimon>
maybe a solution would be to change the default dbcache for something more common among testers?
< 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.
< sipa>
jtimon: we still need to figure out what is behind this... but independently, yes
<@wumpus>
yes, we should definitely crank up the dbcache no matter what
<@wumpus>
but I like to know what happened
< jtimon>
sipa: yeah, of course, I meant independently
<@wumpus>
should at least try to bisec tthis, I know it's frustrating as everything takes so long :)
< sipa>
oh, this is with txindex enabled
< 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?
<@wumpus>
gmaxwell didn't you have some suspicions that CB would affect initial sync? could that also affect reindex?
<@wumpus>
not in my case
< sipa>
wumpus: gmaxwell's test was before cb was merged
< gmaxwell>
my test is without cb merged, also the CB concern was just related to general sync logic, not processing.
< jtimon>
are there recent changes that people suspect may have caused the regression ?
<@wumpus>
wouldbe good to test against #7917, as many people benchmarked that
<@wumpus>
and it was perceived fast at the time
<@wumpus>
jtimon: not really
< 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.
< 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.
< gmaxwell>
(maybe not leveldb itself being slow, e.g. making extranious accesses to it)
<@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
< 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
< gmaxwell>
So actions are. determine if regression, if so where, ... seperately, consider a dbcache increase for the next release.
<@wumpus>
I doubt it is leveldb itself as there haven't been changed to that for ages
< gmaxwell>
sipa: yes this might be txindex related. I can test that too.
<@wumpus>
yes, txindex is *slow*
< CodeShark>
is something slowing down validation that wasn't before?
< sipa>
CodeShark: maybe
<@wumpus>
lots of extra I/O. I also made that mistake once
< gmaxwell>
wumpus: we have changed (reduced) the amount of interaction with leveldb during validation.
<@wumpus>
gmaxwell: sure, it may be the level above leveldb
< sipa>
yes, it may be
<@wumpus>
I just don't suspect the databse itself this time
< 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.
<@wumpus>
unless some compiler flag changed things shockingly, say, the c++11 switch, but I doubt it
< 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.
< sipa>
i briefly suspected the IsInitialBlockDownload change, but apart from using an atomic, its semantics should be unchanged
<@wumpus>
especialy if you see the slowdown in the flush; txindex writes a lot of data to the block index databse
< sipa>
wumpus: but the txindex writes don't happen during the flush
<@wumpus>
so maybe false alarm, the sync is slow, news at 11
< sipa>
wumpus: though they may accumulate somewhere in leveldb until a flush is issued
< CodeShark>
can't we add tracers around calls to narrow it down?
< gmaxwell>
wumpus: well, the "lets increase the dbcache" is still a useful response to this catching attention again.
< sipa>
action points: benchmark in same conditions without txindex, and with larger dbcache?
<@wumpus>
yes we should increate the dbcache, and probably change how it is allocated
<@wumpus>
(e.g. a relatively large part now goes to leveldb caches, that's a waste
< gmaxwell>
(as my laptop is about to be on day three of reindex)
< sipa>
wumpus: the reasoning was that leveldb cache is serialized, so it has a much large impact per byte than the internal cache
<@wumpus>
leveldb's own caches are completely ineffective compared to bitcoind's application level cache
< sipa>
but it has the deserialization overhead
< sipa>
but that's mostly a guess without substansive benchmarking
<@wumpus>
sipa: that makes a lot of sense in theory, but leveldb just sucks at caching :)
< gmaxwell>
I can benchmark a bunch of mixes of cache sizes and see how they pan out.
< 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
<@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
< jtimon>
not sure I'm following but maybe we want separate options for the "internal" and "external" caches?
<@wumpus>
jtimon: for testing that'd be awesome
< sipa>
jtimon: for testing that makes sense, but as a product it should work well with the fewest number of tunable possible
< 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)
< sipa>
jynx
< instagibbs2>
On phone but present
< jtimon>
there's some options that can only be accessed if --debug, right?
<@wumpus>
gmaxwell: you'd be surprised :-)
<@wumpus>
some users are very persistent in trying to find settings that are fastest for them
< CodeShark>
I'd venture to say it's probably not the majority
<@wumpus>
but yes, it should be a hidden option (--help-debug)
< jtimon>
oh, no they may not be showed in the help but they're still accesible I think
<@wumpus>
CodeShark: sure, but don't underestimate peole
< sipa>
wumpus: maybe such options should be marked with ("If you find a setting for this value that improves performance, please let us know")
<@wumpus>
sipa: +1 :D
< gmaxwell>
-funroll-loops -O20
< sipa>
-femit-broken-code
<@wumpus>
-fskip-computing-even-bits
<@wumpus>
ok, any other topics?
< sipa>
relatedly, i think -qt can by default use more ram
< sipa>
also, 100 mb is kinda ridiculous with the mempool already being 300 mb
<@wumpus>
yes, probably, although qt itself also uses more ram
<@wumpus>
yes, agreed
< sipa>
other topic: merge segwit yay or nay
<@wumpus>
let's reduce the mempool to 100mb and increase dbcache to 300mb
< 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.
< petertodd>
sipa: re: segwit, has it been rebased?
<@wumpus>
#topic segwit
< sipa>
petertodd: 12 times by now
< CodeShark>
lol
< sipa>
see 8149
< CodeShark>
poor sipa
< jtimon>
how can we feature freeze without merging segwit?
<@wumpus>
sipa is getting carpal tunnel syndrome from rebasing
< 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.
<@wumpus>
jtimon: softforks / consensus changes don't count as software features
<@wumpus>
jtimon: that's also why they're allowed to be introduced in minor versions
< petertodd>
sipa: I mean, is the current pull-req rebased since compact blocks got merged?
< gmaxwell>
also it's not even activated in any case. it's pure code updates.
< sipa>
petertodd: yes
< jtimon>
wumpus: so it won't be possible to include any feature post segwit merge in 0.13 ?
< CodeShark>
current is #8149, yes?
< 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)
<@wumpus>
jtimon: right, 0.13 is closed feature-wise
< 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.
<@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)
< jtimon>
wumpus: that is a no, that is unconvenient and I wasn't expecting it, but thanks
< CodeShark>
sipa: which PR should we be testing against?
< jtimon>
yeah, should have asked "what about segwit?" back then
< sipa>
CodeShark: 8149 and 7190 are the exact same code
< sipa>
so whatever you like
< gmaxwell>
I had completed review up to the CB rebase, which I have not looked at yet.
< gmaxwell>
(I mean I haven't looked at segwit's rebase for CB)
< 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
< sipa>
git show -w c4e3c755d7e41aaabe74c84af7e4bf00a62c96fb
< sipa>
and then search for cmpctblk and blocktxn
< sipa>
to see the changes related to that
< btcdrak>
oh I'm late
<@wumpus>
jtimon: we all would have preferred other timings, but we have to cope with how things actually are :)
< jtimon>
I planned to rebase/rewrite some of the consensus encapsulation code after segwit, I guess the plan doesn't change anyway
<@wumpus>
well you can still do that, it just won't make 0.13
< jtimon>
wumpus: well, yeah, I could have helped more with reviewing and testing segwit
< gmaxwell>
sipa: thanks, will review once I start up the test panel for the prior topic. :)
< jtimon>
wumpus: understood
< sipa>
jtimon: you can still do that, even after merge :)
< gmaxwell>
yes, post merge review and testing is super important too.
<@wumpus>
yes, absolutely
< 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)
< 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
< gmaxwell>
Obviously there may still need to be some fixes and nits. But thats what we have time for.
< sipa>
(compared to running just cb before)
<@wumpus>
anyone against merging segwit?
<@wumpus>
(I mean right now, not in general)
<@wumpus>
*crickets*
< sipa>
i have no objections :)
<@wumpus>
that's clear then
< btcdrak>
I'd like to see it merged too
<@wumpus>
yes, I understood
< jtimon>
sipa: yeah, it just won't make it to 0.13 as wumpus explained
< CodeShark>
the sooner the better (as long as it doesn't break current behavior)
<@wumpus>
#action Merge segwit
< btcdrak>
o/
< 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.
< instagibbs3>
Good.
< 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?
< petertodd>
gmaxwell: fine by me
< sipa>
i believe jonasschnelli builds nightly binaries
<@wumpus>
sure, why not
<@wumpus>
I prefer doing that outside the 'official' release cycle, but I don't mind running gitian for it
< 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. :)
< gmaxwell>
yes, I don't want something part of the release cycle. Just binaries to give to power users to give it a spin.
<@wumpus>
testnet-only
< CodeShark>
testnet as in not segnet, right?
< gmaxwell>
yea, pre-RC testnet only, we could one line patch to change the default network, so it'll be easier to use.
< sipa>
CodeShark: segnet has been removed a few weeks ago from the patch
< gmaxwell>
Testnet is segwit now. Segnet is dead long live segnet.
< petertodd>
gmaxwell: maybe better to just make it fail unless -testnet is enabled, in case someone does run it in production
<@wumpus>
no, not segnet. Regtest could be allowed. But mainnet disabled and testnet as default
< CodeShark>
is segwit live on testnet?!?!
< gmaxwell>
yea. exactly.
< sipa>
CodeShark: yes, since months
<@wumpus>
petertodd: what is the worst that could happen if you accidentally run testnet?
< petertodd>
wumpus: hard to know!
< 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?
< 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
<@wumpus>
at least the default ports etc will be different, default data dir is different, etc
<@wumpus>
petertodd: apart from GUI users I guess
< 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.
< sipa>
i believe this is a nit not worth minutes of discussion time
< petertodd>
wumpus: yes, but imagine someone has an automated system setup which calls bitcoin-cli...
< gmaxwell>
in any case, can be discussed later or not.
< gmaxwell>
:)
< btcdrak>
any more topics?
< jtimon>
are we merging the bip9 activation parameters for testnet?
< CodeShark>
hmm - I don't see the activation parameters for segwit on testnet
< CodeShark>
how can it be live on testnet?
< jtimon>
CodeShark: people running custom code I assume
< sipa>
CodeShark: in the segwit branch
< jtimon>
oh
< sipa>
not in master
< btcdrak>
CodeShark: it was activated months ago
< CodeShark>
yes, but I'm still confused as to the release here
< CodeShark>
shouldn't testnet only run stuff that's been merged?
< instagibbs3>
bip 9 activation can still be set.
< btcdrak>
no, we set the parameters
< gmaxwell>
CodeShark: we wanted testing in a mixed enviroment with most nodes not upgraded.
< btcdrak>
and that allowed a miner to activate it
< sipa>
CodeShark: it was a very useful testing exercise
< gmaxwell>
CodeShark: since thats realistic.
< gmaxwell>
and segnet couldn't easily provide that.
< CodeShark>
sure, I'm all for the additional testing - I'm just concerned about breaking the master builds for testnet
< gmaxwell>
CodeShark: it's a softfork, hurrah.
< sipa>
(although, there are so few testnet segwit nodes running right now that it really does not work without -addnode)
< CodeShark>
gmaxwell: yes, but it will still break miners. however, if no issues arose as a result I'm fine with it
< sipa>
CodeShark: testnet miners are clearly already running it
< CodeShark>
yes, indeed
< sipa>
so how could merging break anything for them?
< CodeShark>
nvm, all's good
< 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)
< gmaxwell>
er, wouldn't have been
< jtimon>
it is the first time a softfork is activated on testnet before it is in master thought, right?
< 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.
< gmaxwell>
Are the testnet seeds running the code that can give filtered responses?
< sipa>
petertodd: are you sure that's running the filtering code?
< jtimon>
gmaxwell: the "testnet only" builds are just from master after merging segwit, right?
< sipa>
jtimon: yes
< petertodd>
sipa: should be
< 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.
< petertodd>
sipa: I'll recheck
< sipa>
x9.seed.tbtc.petertodd.org gives many results, more than i'd expect
< petertodd>
sipa: note that it is running with extra args to support rbf
< gmaxwell>
jtimon: yes, likely with a trivial patch to change it to default to testnet (or require it). (and maybe a renamed binary)
< petertodd>
sipa: so maybe there's a bug there that you haven't run into yet
< sipa>
petertodd: can i see the code for that?
< jtimon>
gmaxwell: why the changes? aren't this power users?
< sipa>
after the meeting, please
< petertodd>
sipa: it's with the command line arg; which incidentlaly was broken when I tried it (see my pullreq)
< gmaxwell>
any other topics for this meeting?
<@wumpus>
doesn't seem so
<@wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Jun 23 19:49:58 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< jtimon>
oh, I think we forgot to make a joke, that's bad for the summaries :p
< btcdrak>
there is plenty comic relief there
< 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.
< petertodd>
sipa: yeah, I think so
< btcdrak>
wumpus: so is segwit is the last feature PR and now 0.13 is frozen?
< gmaxwell>
segwit is not a feature PR
< gmaxwell>
and 0.13 has been frozen for a bit now.
<@wumpus>
as gmaxwell says ^^
< btcdrak>
fine
< gmaxwell>
(it's especially not a feature PR with it not yet activated in mainnet. :) )
< jtimon>
gmaxwell: whatever, the patch to change the default and/or disable mainnet should be trivial anyway
< sipa>
i'd be perfectly fine with that binary also supporting mainnet
< gmaxwell>
jtimon: yup. if it were hard I wouldn't have suggsted it. I think it's useful but not of great importance.
< jtimon>
I think I disagree with the notion that "the segwit PR is not a feature"
< 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).
< gmaxwell>
jtimon: I feel sorry for you then? It's not even exposed in 0.13 as merged.
<@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
< 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)
< jtimon>
gmaxwell: precisely I thought the "softforks are minor releases" applied to the activation, not to the inactive code
< gmaxwell>
jtimon: sure though inactive code is not a feature either.
< CodeShark>
if it includes the testnet code I'd argue it is a feature
< gmaxwell>
wumpus: that would be fantastic, and would radically increase the use of testnet, I expect.
< gmaxwell>
CodeShark: A feature for testnet. ooohkay.
< gmaxwell>
I don't disagree but I don't think the distinction is important.
< gmaxwell>
Testnet is not very serious, as much as I'd like it to be more serious. It's often pretty broken.
< CodeShark>
going forward, as long as activation parameters for testnet softforks are documented somewhere and we agree on them it seems ok
< gmaxwell>
Not sure how you missed the couple weeks of discussion about segwit in testnet before.
< CodeShark>
I remember the discussion - I just wasn't clear on the release cycle as it pertains to testnet
< jtimon>
yeah, I think that's the source of the discussion
< btcdrak>
there is no release cycle. miners can apply whatever sfs they like at any time
< jtimon>
not saying necessarily the new method is worse, but it has changed
< 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.
<@wumpus>
I don't think the distinction is important either
<@wumpus>
we just need segwit out, and everything that helps the testing and review process is great
< gmaxwell>
(e.g. you didn't see any of us howling about release cycle when jtoomim was using the XT hardfork on it)
<@wumpus>
we're not goingn to block segwit on a procedural detail
< btcdrak>
jtimon: there isnt a release cycle. The consensus rules of the network are not defined by a release cycle of software
< btcdrak>
gmaxwell: exactly
< gmaxwell>
as btcdrak said.
< 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.
< 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
< gmaxwell>
esp when the thing we're trying to test is deployment of a feature in a non-upgraded network. :)
< 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
< sipa>
CodeShark: there have been proposals in the past for having multiple testnetd
< 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.
< 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
< gmaxwell>
and if they were, we could easily move more disruptive things to other testnets.
< jtimon>
btcdrak: ack
< 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)
<@wumpus>
jtimon: sure, I just get crazy from all the time pressure and all the different things that pop up
<@wumpus>
jtimon: I don't have much trust in anything ever being done the 'ideal' way :-)
< 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)
< jtimon>
wumpus: not regreting anything rewarding segwit
< 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
< 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. :)
<@wumpus>
jtimon: well the critical thing is that segwit is reviewed and tested enough, that there are no technical concerns with merging it
< CodeShark>
not sure it's necessary to test on testnet itself
< CodeShark>
at least for an application developer
< CodeShark>
although there is a benefit to us
< gmaxwell>
er after dersig was released.
< jtimon>
wumpus: ack
<@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
< 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.
< sipa>
well, maybe having a windows desktop shortcut for testnet makes it more visible and attractive to test on
< gmaxwell>
E.g. left to their own devices reorg handling may be compeltely untested.
< gmaxwell>
also testnet is useful for interworking tests between multiple implementations.
< sipa>
i would love to see an actually operational test network, where you can try sending from testnet bitgo to testnet bitawesomewallet or something
< jtimon>
wumpus: that's perfect. I'm not criticizing. Just wondering if things can be done EVEN better
< gmaxwell>
I've joked before, but really seriously, that someone should setup a dumb gambling thing on testnet.
< gmaxwell>
I spent much of 2012 begging services to setup testnet instances of themselves with play money, without much luck.
< 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
<@wumpus>
the only services that exist for testnet seem to be some block explorers, also mostly broken
<@wumpus>
I think regtest made it too attractive to set up internal testing networks :-)
<@wumpus>
jtimon: agree, there's always room for improvement
< 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
<@wumpus>
testnet has 'more features', e.g. no standardness
< 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.
< CodeShark>
with regtest you can definitely do more rigorous testing - given you have programs that can simulate network conditions on it
< gmaxwell>
jtimon: softforks have pretty much always activated first on testnet.
< 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. :)
<@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
< 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.
<@wumpus>
gmaxwell: (not that that kind of testing isn't useful, but it just isn't very popular)
<@wumpus>
it requires people actually paying attention on the fly :)
< gmaxwell>
unpredictablity of blocktimes on testnet has not helpped for application testing.
<@wumpus>
also unrealistic reorgs
< 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.
<@wumpus>
whole runs of difficulty-1 blocks that are reorged away suddenly
< btcdrak>
there is no incentive to mine on testnet. that is the main issue
<@wumpus>
btcdrak: right - if there was, then testnet coins would have a value
< 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.
< 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.
< btcdrak>
gmaxwell: i like the idea of testnet block signers.
< 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.
< 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.
< 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
< 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.
< 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
< gmaxwell>
CodeShark: its mostly not used for that. The most use it gets is breaking secondary implementations.
< gmaxwell>
halariously, there is one of these "messaging via the blockchain" spammy things that uses testnet for production.
< 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.
< jtimon>
sorry, was afk
< helo>
god forbid they form their own relay network that actually fits their use case
< btcdrak>
helo: they are too lazy.
< gmaxwell>
It's complicated.
< 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'
< 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)
< gmaxwell>
m certantly not out going to make some custom network for some crazy app dejure (unless they're going to pay...)
< 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
< jtimon>
gmaxwell: well, we could maintain a single-element (ie block signing) chain in elements...
< 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.
< CodeShark>
gmaxwell: even if they're going to pay you probably have better things to do ;)
< gmaxwell>
helo: so I think thats one component of the blockchain hype.
< gmaxwell>
jtimon: yes, and a seperate network that used just that and was otherwise the same as bitcoin testnet
< jtimon>
yes
< 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.
< btcdrak>
permissioned testnet :)
< jtimon>
gmaxwell: interesting thought
< sipa>
yow
< helo>
yeah, that sounds about right...
< 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
< gmaxwell>
have the background/time/interest to go build a regtest test harness.
< gmaxwell>
I can tell you that a lot of bitcoin services have no reorg handling at all. :(
< 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
< CodeShark>
correct?
< gmaxwell>
CodeShark: no.
< btcdrak>
urgh
< btcdrak>
I PMd him
< gmaxwell>
there is nothing weird about it.
< da2ce7_mobile>
I was expecting the CSV flags to drop straight down to zero.
< 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.
< sipa>
da2ce7_mobile: BIP9 suggests that they don't
< 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.
< sipa>
da2ce7_mobile: and that they keep setting the flag during the locked_in phase
< da2ce7_mobile>
:(
< sipa>
why :(
< gmaxwell>
presumably that was to the manual setting of bits.
< da2ce7_mobile>
well it would be better if they followed the protocol.
< 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.
< sipa>
da2ce7_mobile: the difference between theory and practice is that there is none in theory
< da2ce7_mobile>
Ok. It look like that CSV could be a bit of a bumpy ride when activating.
< gmaxwell>
da2ce7_mobile: huh?
< sipa>
set activation threshold to 95%
< gmaxwell>
da2ce7_mobile: not at all.
< btcdrak>
da2ce7_mobile: activation is now certain and we know which block it will occur on
< Lightsword>
is it only eloipool based pools that manually set the version?
< da2ce7_mobile>
well if the bits are not being auto-unset then that suggests that the miners haven't upgraded their nodes.
< btcdrak>
Lightsword: no. we have contacted the pools who do.
< 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).
< btcdrak>
da2ce7_mobile: not at all. it just means they set the bit manually, against our advice.
< da2ce7_mobile>
ok. well in that case I'm less worried.
< 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.
< 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.
< da2ce7_mobile>
ok :) you guys are way ahead of me. Colour me impressed (yet again).
< gmaxwell>
in any case, "we've (hopefully) got this"
< 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
< gmaxwell>
I was irritated to find people were still manually overriding it.
< gmaxwell>
Lightsword: take the version from the template.
< btcdrak>
Lightsword: chat with jl2012, he said he found a solution for one of the pools at least
< 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...
< da2ce7_mobile>
I really like BIP9. It is a really elegant solution and upgrade.
< 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.
< 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. :)
< sipa>
da2ce7_mobile: thanks :)
< sipa>
(and thank everyone who's helping... i didn't even write the majority of the code)