Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Testchains: Introduce custom chain whose constructor... #8994
...reads from runtime params and simplify the creation of partitioned chains by simply generating different gensis block hashes from a given custom name.
referenced this pull request
Nov 17, 2016
This is related to #9102 (see #9102 (comment) ping @laanwj ) in the sense that we cannot test that the genesis block is not validated unless we can run the system for a chain whose genesis block doesn't comply with the rules.
@gmaxwell, you suggested that something like #9177 would need a lot of coverage testing and review, and I completely agree. Any suggestion to advance in that front in this PR instead of #9177 (which currently doesn't work and has one unittest that is not independent) would be welcomed.
You have recently made improvements in the rpc test framework, @MarcoFalke , and are familiar with it. If you get bored and can help fix one of the 3 tests that aren't passing for custom or just comment about the python changes in general, that would be great.
The longer version of CreateChainParams could indeed take all fields in CChainParams and Consensus::Params as arguments, but that would break the encapsulation. Every time a field is added or removed all calls would need to be adapted. Note that ideally, in the future, all tests would rely on CreateChainParams but none of them on the chainparams globals (accessed to via SelectParams and Params() ).
Another simpler option would be to simply let chainparams.cpp depend on globals mapArgs and mapMultiArgs (it depends on util.o anyway).
Yet another option is to undo some of that changes in #9243 if that gets merged first, which would be my personal preference.
If anyone has more options, I'm all ears.
Added customization for -assumed_blockchain_size and -assumed_chain_state_size introduced in #13216 . I forgot that on rebase.
Also, added basic documentation for all fields as discussed before. Although nits for the documention are of course welcomed, we could perhaps fine tune that and, more importantly, which fields don't even deserve to be exposed, on a different PR, not to add further noise.
In that spirit, I brought back -ndefaultport and -frequirestandard, even though I personally don't think they deserve to be exposed. More generally, I would suggest adding to that list any field containing the word "consider" for its documentation in my initial proposed documentation, sorry for the various redundancies.
They can be discussed individually in different PRs is my main point in bringing them back, I guess. Perhaps we can keep them all as a way to document the existing alternatives people could be using and to remind us that perhaps not all of them even belong in chainparams at all.
Honestly, to me this is mostly about being able to produce many regtest networks with the same binary that are incompatible between them because they don't share the same genesis block hash, which happens to be a consensus rule intrinsically by definition (for any block with height 1 needs to be a child of the genesis block). Perhaps I should add a simple test about that.
To reiterate other motivations, of course it's also for never adding more parameters for each new type of testing chain we want. That scales linearly by the number of chains.
Additionally, we will never need a set method for chainparams ever again (I've seen those come and try to come, and go, and I fought for them to go for a while), so our chainparams singleton could be const forever after initialization, just as everybody reasons about it, and as it should IMO.
Concept ACK and light code re-utACK.
I am not a big fan of adding a ton of new
Well, we can leave some of the options undocumented and we can also not expose some of the chain params at all since there are alternative ways to test that functionality (like the port number or allownonstd).
I meant a new file format for custom chains that is separate from the main argument stuff. People would either provide a JSON object describing all the options or a file that had the options in it.
That said though, isn't it already possible to do e.g.
Concept ACK. There's two things I'm "Approach NACK" on -- all the extra options, and switching to regtest2.
I think the options can be broken out into:
Would it make sense to have that stuff be encoded as a hex blob -- that way it can be cut and paste as a unit, and maybe a checksum can be added? You could make that work by running a script to generate it (along with a genesis block, with sufficient proof of work to not need to add exceptions to the tests), and having the script spit out a hex blob. Then you just paste the hex blob into your bitcoind.conf and share elsewhere? So you end up with a few chain specs in your config:
and can then choose one by saying
I think setting things up that way would make it pretty easy to allow you to have your own newspaper quote, which should in turn make it easy to have regtest use this code path without needing a hardfork.
What is the advantage of the blob? How is copying and pasting from conf files harder than running a script to then copy and paste just the same?
Regarding moving the tests from regtest to regtest2 (or custom, any name except main, test and regtest would do) is the way to test this. I don't see the disadvantage on moving away from regtest there, they're practically the same and some tests could make use of the custom chainparams.
I proposed this in the past, I think I had it implemented at some point. Right, see #8994 (comment)
Now that there are sections for the config file, I don't care so much about it, you can do things like: