< promag>
sipa: > involve downgrading/upgrading between versions
< sipa>
yes?
< promag>
could have those wallets as fixtures'
< promag>
?
< sipa>
?
< promag>
you mean that to test you have to use different versions of the wallet or the binary?
< sipa>
yes
< sipa>
any automated testing that downgrading/upgrading is supported under the intended scenarios would involve having tests with access to different versions of binaries
< sipa>
which is just hard logistically
< promag>
why? could make use of docker for instance
< sipa>
i fail to understand what kind of universe you live in where that doesn't qualify as "logistically hard" :)
< promag>
but yes, a pain
< sipa>
i'm not saying it's impossible - but it requires very nontrivial changes to our setup
< sipa>
so i'm looking for opinions
< sipa>
is it enough to do manual testing for downgrade/upgrade scenarios, for example?
< promag>
how about having some wallets created offline with different versions commited to the source code, to use in the the tests?
< sipa>
that would be a good idea!
< sipa>
it can't test downgrade scenarios, though - only upgrade
< promag>
why? the downgrade should produce an expected wallet (also commited)
< sipa>
we don't have old binaries available
< meshcollider>
promag: what about testing a wallet generated by the new version, against old software
< sipa>
oh, by downgrade i mean opening a new file in an old version of the software
< meshcollider>
e.g. generate wallet with 0.16.0, test against 0.15.1
< meshcollider>
downgrading the software not the wallet :)
< promag>
no need to test agains 0.15.1
< meshcollider>
I mean any previous versin
< promag>
you just happen to know downgrade result, so just check the downgrade result, offline you know it works in that version
< sipa>
promag: practically the entire discussion about segwit wallet support is about downgrading and restoring backups across versions
< sipa>
so no, we absolutely do care about how 0.15.1 deals with 0.16 files
< promag>
I'm not saying otherwise
< meshcollider>
old binaries are all stored on bitcoincore.org so just write another testing framework to use those ;)
< sipa>
promag: then i don't understand what you're saying
< meshcollider>
oh actually there is nothing pre-0.9.5 there
< promag>
so offline with create and downgrade the wallet, test with older versions, if it's ok then commit a test that does the same and at the end verifies the downgraded wallet
< sipa>
what does 'verifies the downgraded wallet' mean?
< sipa>
there is no such thing as a downgraded wallet - it's just a wallet file that was modified by master, and we care about how old software deals with it
< promag>
for instance, the sha(downgraded wallet file) must be ....
< sipa>
bdb files aren't deterministic
< meshcollider>
in reality it'd require a whole new testing framework to ensure things like signrawtransaction, listunspent, etc. all work on the old versions aye
< sipa>
and testing exact equivalence would be painful to maintain, as it would need updating after pretty much any change
< promag>
2 downgrades of the same can be different?
< sipa>
promag: BDB files aren't deterministic, so you can't predict at all what the wallet file will look like after _any_ change
< sipa>
you could dump the key/values in it, and compare those
< sipa>
but my point is that you don't want to do that
< sipa>
we don't care about the exact contents - we care about whether it works in old versions :)
< promag>
my point is that those "exact contents" work in previous versions
< sipa>
yes, but we can't predict what exact contents will be in master
< sipa>
unless you want to modify that pre-committed exact contents after any change in master that affects the wallet file
< promag>
that should not change often?
< sipa>
maybe not
< sipa>
it'd still be a pain
< promag>
I mean, until a better testing framework exists it's better than nothing
< sipa>
maybe
< meshcollider>
just checking the hash of the wallet file is not sufficient though?
< sipa>
meshcollider: no, the hash of the wallet file is completely unpredictable
< meshcollider>
yeah, isn't that what promag is suggestion though
< promag>
hash, key/values, whatever
< sipa>
i generally dislike tests that test for exact equivalence
< meshcollider>
key/values dumped by a newer version won't necessarily match those of an older version also, because changes to e.g. dumpscript would change the output
< promag>
the test should just expect something. if master changes that then it might mean an old version can't use a downgraded wallet
< sipa>
especially if its unclear how those expected values should change
< promag>
but yes, if a wallet decides to add a new key/value for soemthing else then its' a pain
< sipa>
or a timestamp
< sipa>
or a version number
< sipa>
or a txid that's hard to make constant during the test
< promag>
and pick the relevant key/values?
< promag>
nothing better than actually use the old binaries
< meshcollider>
yeah
< promag>
what versions you think it should tests?
< meshcollider>
well even 0.11 is now EOL isn't it, so I think it would be sufficient to just test on 12+ ?
< meshcollider>
(automatically, of course we shouldn't deliberately break compatibility with earlier versions too just not test against them all automatically)?
< promag>
only final releases right?
< meshcollider>
you mean like, not rc? or just 0.14.2 not 0.14.1?
< sipa>
it's a good question what versions should be supportedd for downgrading
< sipa>
the use case is generally that someone upgrades, notices that the new version does something else/unexpected that is incompatible with their business, and downgrades until the issue is resolved
< sipa>
and obvious for the specific case of segwit wallet support - downgrading below 0.13 is impossible of course
< promag>
I guess you should add this testing as a follow up in #11403
< promag>
a checklist for manual testing downgrade would be great also
< sipa>
good point
< promag>
bed time o/
< meshcollider>
IMO its safe enough to support downgrading to versions which havent reached EOL and not bother testing the others too
< Varunram>
Is it possible to change the difficulty on a regtest chain?
< kallewoof>
Trying to get gitian working, and am having issues with LXC. I am getting "sudo: unable to resolve host gitian / cannot set terminal process group (1): Inappropriate ioctl for device / no job control in this shell" for the line "sudo $LXC_EXECUTE -n gitian -f var/lxc.config -- sudo -u $TUSER $ENV -i -- $*" in libexec/on-target, called from make-clean-vm (the bootstrap-fixup part). Any ideas?
< midnightmagic>
kallewoof: I solved that by modifying the gitian tqrget config to add the hostname to the internal /etc/hosts file; originally I solved it by manually modifying the base image.
< kallewoof>
midnightmagic: Nice, that got rid of the first line, but the other two lines remain (and I get thrown into a shell as root on the LXC side)..
< kallewoof>
If I ^D, I get a bunch of "unknown user: ubuntu" errors when it tries to continue doing stuff.
< midnightmagic>
does yout bootstrap-fixup not do an adduser for you?
< kallewoof>
It's not being executed, because of the above errors, I suspect.
< kallewoof>
I tried copying it into the base VM and then running it as a script from inside. That sorta worked, but "initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused" (not sure if that is bad news or can be ignored), then stuff, and then it fails again on the "Preparing build environment" part (basically, it fails whenever a "<" is used to feed a script
< kallewoof>
into it).
< kallewoof>
In this case, the "system! "on-target setarch #{@arches[arch]} bash < target-bin/init-build.sh"" part in gbuild
< kallewoof>
I think an easy fix for me is to just copy target-bin into the image after copying it. Not sure why <'ing doesn't work tho. :/
< kallewoof>
I got to the copy-to-target part, which hangs indefinitely on "tar -C `dirname "$1"` -cf - `basename "$1"` | sudo $LXC_EXECUTE -n gitian -f var/lxc.config -- sudo -i -u $TUSER tar -C "$2" -xf -". I suspect the pipe is not functional just like the <, but I could be wrong.
< bitcoin-git>
bitcoin/master bf20a7d Tim Shimmin: [docs] Fixed outdated link with archive.is...
< bitcoin-git>
bitcoin/master 00d25e9 Wladimir J. van der Laan: Merge #11804: [docs] Fixed outdated link with archive.is...
< Provoostenator>
Tangentally related to testing the segwit branch. It looks like miners are no longer mining SegWit transactions on testnet. See my example in #bitcoin.
< Provoostenator>
(well, much less, they do get mined eventually)
< wumpus>
testnet mining seems a continuing issue
< Provoostenator>
I can't go in there with my laptop CPU and mine it myself I presume?
< instagibbs>
people point ASICs at it, so no
< Provoostenator>
Ethereum created a consortium testnet out of desperation, which seems like a pretty bad solution.
< Provoostenator>
Would it be hard to spin up smaller testnets amongst "friends"?
< instagibbs>
for segwit itself something like 4 new testnets were created(segnet)
< Provoostenator>
instagibbs: thanks
< Provoostenator>
The Github issues and pull requests form an infinitely deep and complex rabbit hole; fascinating :-)
< Provoostenator>
"There's a PR for that" might make a good meme.
< instagibbs>
The best one is where there is a PR that's been revived by 2+ people.... thar be dragons
< Provoostenator>
Would it make sense to tweak the PoW algorithm on testnet so it can't (easily) be ASIC mined? Maybe that would keep the difficulty at somewhat manageable levels, where more people can step in and mine SegWit and (experimental) non-standard transactions.
< Provoostenator>
Maybe now is a bad time with heated emotions and such, it could be taken the wrong way. DIY testnets like in the above PR is safer.
< wumpus>
there was some talk of a testnet with signed blocks instead of mining at some point, as mining is always a problem with regard to incentives, but it's pretty annoying to implement and touches consensus code
< Provoostenator>
And I suppose any code supporting such PoW change on testnet would cause maintenance headaches.
< wumpus>
there's no need for PoW at all on testnet, unless for testing miners I guess
< wumpus>
and in that case using a different one is useless
< Provoostenator>
Hardcode the difficulty at 0 and add a consensus rule for now more than 1 block per minute?
< Provoostenator>
I suppose that would be a DDOS vector.
< wumpus>
but yes I think DIY/private testnets are the best solution usually, most testing scenarios don't really want all the noise around
< Provoostenator>
The noise helps you catch unexpected stuff though.
< Provoostenator>
And having frequent reorgs on testnet would be nice too for testing robustness.
< wumpus>
that's what we have already, most requests are for a more reliable testnet
< Provoostenator>
Right, maybe we need a seperate calmnet and wildnet.
< Provoostenator>
I used to just test everything on mainnet when fees were a bit lower (still works if you use the minimum relay fee and spend unconfirmed txs).
< mlz>
devs, current testnet blockheight: 1251999, could we reset testnet or redesign it all together that LN testers don't have to wait for a segwit miner to come along?
< wumpus>
indeed, testing on mainnet is possible, though that's bad practice to recommend to anyone, much foot-shooting potential
< wumpus>
mlz: yes, testnet seems broken at the moment, and no one seems to be able to spare miners to point at it :/
< mlz>
wumpus, is it possible to make it CPU mining? i can help and so can many others
< wumpus>
one idea that has been proposed is to do a testnet with signed blocks, e.g. wumpus signs a block every 10 minutes. Mining, of whatever kind, will always introduce these kind of issues.
< wumpus>
it's not that sha256 is not CPU minable, just that someone is mining and pushing up difficulty w/ inconvenient settings or version
< wumpus>
just two year ago I CPU-mined quite a few blocks on testnet, while no one else was pointing miners at it
< wumpus>
anyhow for a reliable testnet it's probably best to have a fixed set of rules, distributed mining competition doesn't really help
< wumpus>
as mentioned before it'd be good to try to move #8994 forward
< Provoostenator>
(feel free to answer in #bitcoin instead)
< Varunram>
(yeah)
< Provoostenator>
Is there a way to get `make cov` to produce an lcov file rather than HTML?
< Provoostenator>
(happy to tweak Makefile.am, but no idea how)
< phantomcircuit>
wumpus, ye but lots of miners use testnet to test
< phantomcircuit>
about the only people who do really
< BlueMatt>
nah, the ln folks are consistently pissed that testnet sucks
< BlueMatt>
so they use it
< phantomcircuit>
BlueMatt, heh
< Provoostenator>
I'm getting a second hand Block Erupter USB on Sunday, we'll see if that helps.
< BlueMatt>
lol
< Varunram>
for mining segwit txs on testnet?
< Provoostenator>
Yes, as the guy in Armageddon said: this is how we fix things in Russian space station :-)
< Varunram>
lol
< adiabat>
BlueMatt: I use testnet3 all the time, it's a little weird but oh well
< adiabat>
maybe the biggest issue is that you'll have miners show up who don't run segwit and mine for days where no segwit txs can be confirmed
< gmaxwell>
need some hashpower there that mines segwit invalid blocks.
< adiabat>
the messiness of testnet3 is something of a feature though; found some reorg bug in my code the other day
< adiabat>
though it's specific to the testnet difficulty reduction, so maybe actually not that great a feature :)
< Varunram>
adaibat: further adding to BlueMatt's assertion that ln folks use testnet grudgingly
< Varunram>
adiabat*
< adiabat>
I mean, it's a mess, but at the same time it allows to test weird edge cases
< adiabat>
for example, I have code to checkpoint SPV headers, which is only there because testnet has over 100MB of headers
< Varunram>
nice e.g. lol
< BlueMatt>
heh, there's been persistent discussion of resetting testnet to bump min diff to limit the insane header volume issue
< adiabat>
if anything, making testnet3 more congested may help, as it would allow fee pressure and testing different fees, RBF, etc
< BlueMatt>
heh, well someone can write a bot to do that.....
< BlueMatt>
spam testnet!
< adiabat>
yeah the min diff thing is weird, could definitely do without that
< adiabat>
I don't know the etiquette on that
< adiabat>
I spammed it a bit last year, and made those 3.7MB blocks
< adiabat>
wouldn't be hard to spam more, but figured people might get annoyed at a 200GB testnet
< Varunram>
people would quit it altogether
< phantomcircuit>
BlueMatt, ye testnet probbaly needs a reset
< phantomcircuit>
i mean
< phantomcircuit>
pretty sure im still 90% of testnet by bytes
< adiabat>
I may be a couple %
< Provoostenator>
Rather than spamming, why not drastically decrease the block size? I kind of like that I do an IDB in less than an hour for a change.
< jimpo>
In a local branch I'm getting linking errors along the lines of "multiple definition of `StartShutdown()'". Can someone explain why the definitions in test_bitcoin_main.cpp don't conflict with the ones in init.cpp?