Testschains: Many regtests with different genesis and default datadir #17037
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
848ff18 to
90e3696
Compare
|
Rebased |
|
Can you write a more detailed PR description motivating what use cases require this? |
|
Sure, done. Thanks for the suggestion, it is true that the motivation wasn't well explained at all. |
|
Can you explain more why it's worthwile to review this and not just signet? I understand it makes it a bit easier to make a genesis block for signet, but how hard is that? |
|
This would simplify signet. |
|
I'd be interested to hear @kallewoof's thoughts on if this PR is good for signet or not -- it seems like that having the signet stuff merged would make this "nice to have", but not enabling something new (as you can use signets instead of regtests). |
|
Yeah, only one configurable class is necessary. Even making not signet
regtests should be as simple as making is_signet configurable.
Whether that class is called CSignetChainparams or CCustomChainparams
shouldn't be very important IMO.
And if it was the other way around, signet could just be adding those
parameters to the existing class.
I can produce 2 branches with this and signet. One with this first and the
other with signet first.
Although if I do both of them the end result will be the same in both. But
that may be useful to see what I have in mind. And to discuss things that
could be different.
If there's interest, I'm happy to do them.
…On Fri, Dec 20, 2019, 19:27 Jeremy Rubin ***@***.***> wrote:
I'd be interested to hear @kallewoof <https://github.com/kallewoof>'s
thoughts on if this PR is good for signet or not -- it seems like that
having the signet stuff merged would make this "nice to have", but not
enabling something new (as you can use signets instead of regtests).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#17037?email_source=notifications&email_token=AAHWGSVIANX3MEUBC2IWNTTQZUFC3A5CNFSM4I453GF2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHNYXCY#issuecomment-568036235>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHWGSSLVDAHLLSJXQLPG4TQZUFC3ANCNFSM4I453GFQ>
.
|
|
I don't have strong opinions on this PR in particular, as @JeremyRubin stated, we can use multiple signets to get approximately the same effect as multiple custom-named regtests. I don't think this would be detrimental to signet, though. As a sidenote, I would love to remove the grind genesis proof of work part from signet, but unfortunately this was discussed and people didn't like it so it was scratched (hence Anyway, I'm pretty much neutral. |
|
Rebased. Regarding -signet_genesisnonce , as far as I understand the hesitation to remove it is having to touch consensus code. But the changes are minimal, it is just the first commit in this PR. |
1) genesis block hash 2) default datadir 3) chain name (bip70) all directly or indirectly configured with the -chain option ...whose constructor reads params from regular arguments (like regtests)... Qt: Add a default purple and title for unkown chains
|
Rebased |
|
🐙 This pull request conflicts with the target branch and needs rebase. |
|
Closing due to lack of interest. |
And bip70 name.
And on demand (meaning you don't have to mine a genesis block for it to pass minimal pow).
This allows the daemon to create a new regtest-like chains on demand.
The hash of the genesis block is dependent on the "petname" of the chain.
Examples: "regtest2, custom, chain_2, aaa, bbbb"
The hash of the genesis block could depend on more things.
For example, for signet chains, it could depend on the signet_blockscript in the case of BIP325 (signet) #16411
In fact, #16411 could be simplified if this was merged first, for the genesis block wouldn't need to be mined anymore (which requires a special case in grindblock which in turn requires CreateSignetGenesisBlock to be exposed in chainparams). So I guess perhaps signet could be counted as a use case, or perhaps only part of this.
But why would somebody want more than one regtest?
I'm personally using it for doing cross-chain payments in lightning, see https://github.com/jtimon/multi-ln-demo/blob/master/conf/bitcoind.conf
I would like to work on what I call "cross chain trampoline payments" and I plan to keep using it for that too.
I imagine other developers could find this useful for other developments involving bitcoin-like chains.
For example atomic swaps or submarine swaps.
Of course, an alternative for these use cases is to use other regtests from other bitcoin-like networks, for example litecoin regtest or liquid regtest.
Another use case is creating temporal testnets for testing upcoming features.
For example, had this been in place before segwit, when "segwitnet" (was that its name) was created, it could have simply been some shared configuration instead of an additional hardoced chainparams.
Something like:
We're not going to use it for a segwitnet now, obviously, but perhaps for a taprootnet or something.
Perhaps #17032 would be needed too for this use case in particular to be more useful though, or at least make that for some of the fields that are different between testnet3 and regtest.