Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added fPowNoRetargeting field to Consensus::Params #6853

Merged
merged 1 commit into from Oct 20, 2015

Conversation

@CodeShark
Copy link
Contributor

@CodeShark CodeShark commented Oct 19, 2015

-regtest cannot currently handle chains longer than one retargeting period. This PR allows arbitrary length chains to be created on -regtest by trivially preserving the nBits value of the last block.

@btcdrak
Copy link
Contributor

@btcdrak btcdrak commented Oct 19, 2015

as per @laanwj comment #6162 (comment)

@laanwj
Copy link
Member

@laanwj laanwj commented Oct 19, 2015

Concept ACK

@laanwj laanwj added the Tests label Oct 19, 2015
@jonasschnelli
Copy link
Member

@jonasschnelli jonasschnelli commented Oct 19, 2015

utACK

@davecgh
Copy link
Contributor

@davecgh davecgh commented Oct 19, 2015

I personally think this is a bad idea as it is a slippery slope. One of the main purposes of regtest is to test that the consensus code works as expected. As mentioned in #6162, there is currently no test coverage which exercises the retarget code and is why commit df9eb5e, which introduced the retargetting bug, ended up making it to master. In my opinion, providing a flag to work around a bug that was introduced instead of fixing the bug is a mistake.

What is the point of having a regression test network if you aren't really testing the behavior of the code executed on mainnet due to adding special case branches? With this commit, it will be possible to introduce a subtle consensus breaking change to mainnet for retargets that the tests will not be able to detect.

@CodeShark
Copy link
Contributor Author

@CodeShark CodeShark commented Oct 19, 2015

I agree we need tests for retargeting - but there are a bunch of regtest use cases that test critical things entirely orthogonal to retargeting that cannot really be tested without disabling it (i.e. #6816). I would suggest adding an option to turn this on or off...or to have another regtest chain that does not disable it.

@sipa
Copy link
Member

@sipa sipa commented Oct 19, 2015

@davecgh I fully agree that it's suboptimal that regtest would end up not testing mainnet's retargetting code. But regtest is not the only means through which the consensus rules are tested or exercised, and it's certainly easier to use it to test many other things this way. The alternative you suggest is changing the code that the network is already running on just to be able to test it, which IMHO unnecessarily throws away the trust in that code

@laanwj
Copy link
Member

@laanwj laanwj commented Oct 19, 2015

For me, and quite a few other users that are using regtest, the idea that regtest has retargeting at all was completely unexpected. In my mind, and how it has been always advertised, regtest = easy block generation. And I closed #6162 because I don't find it acceptable to change consensus code just to accommodate regtest.

But absolutely - the retargeting code needs to be tested, but there are other ways.

@gavinandresen
Copy link
Contributor

@gavinandresen gavinandresen commented Oct 19, 2015

@davecgh
Copy link
Contributor

@davecgh davecgh commented Oct 19, 2015

For what it's worth, I'm not only advocating for fixing the bug simply so the regression tests can exercise it although obviously testing the retarget code is certainly an extremely important factor and one it seems everybody agrees should be done, albeit perhaps through a different means.

We have an application (outside of tests) that uses the retarget capabilities of regtest in order to test it works properly across retarget boundaries (not of Bitcoin Core, the application itself). This is what drove the original issue to begin with since Bitcoin Core simply no longer handles retargets properly on regtest. We currently use simnet in btcd for this since it works properly across retargets, however we also wanted to be be able to test it against Bitcoin Core.

So, as you can see, this creates a situation where 3rd-party software can't properly be tested across retarget intervals on the regression test network with Bitcoin Core. Also, with this PR, this would now be a regtest option that when set to default disables all retargeting so it doesn't match mainnet, and when enabled causes a broken retarget because the overflow is still not fixed.

@btcdrak
Copy link
Contributor

@btcdrak btcdrak commented Oct 19, 2015

utACK

@@ -22,6 +22,7 @@ struct Params {
/** Proof of work parameters */
uint256 powLimit;
bool fPowAllowMinDifficultyBlocks;
bool fNoRetargeting;
Copy link
Member

@jtimon jtimon Oct 19, 2015

Nit: can you s/fNoRetargeting/fPowNoRetargeting for naming consistency?

@jtimon
Copy link
Member

@jtimon jtimon commented Oct 19, 2015

ut ACK

Also, with this PR, this would now be a regtest option that when set to default disables all retargeting so it doesn't match mainnet, and when enabled causes a broken retarget because the overflow is still not fixed.

No, read the code again: the new field in Consensus::Params is always true for the regtest testchain (just like nSubsidyHalvingInterval is always 150 for regtest).

@davecgh
Copy link
Contributor

@davecgh davecgh commented Oct 19, 2015

@jtimon: I was referring to:

or to have another regtest chain that does not disable it

@jtimon
Copy link
Member

@jtimon jtimon commented Oct 19, 2015

@davecgh I see. Then I agree that it doesn't make sense to create another testchain (retargetRegtest?), different from regtest that doesn't skip retargeting but it actually doesn't retarget either.
We already have 2 chains to test retargetting anyway (main and testnet3).

@CodeShark CodeShark changed the title Added fNoRetargeting field to Consensus::Params Added fPowNoRetargeting field to Consensus::Params Oct 19, 2015
@dcousens
Copy link
Contributor

@dcousens dcousens commented Oct 20, 2015

utACK

@laanwj laanwj merged commit 7801f43 into bitcoin:master Oct 20, 2015
1 check passed
laanwj added a commit that referenced this issue Oct 20, 2015
7801f43 Added fPowNoRetargeting field to Consensus::Params that disables nBits recalculation. (Eric Lombrozo)
zkbot added a commit to zcash/zcash that referenced this issue Nov 18, 2020
Enable mininodes to construct blocks in RPC tests

Includes changes to disable difficulty adjustment on regtest, cherry-picked from:
- bitcoin/bitcoin#6853
- bitcoin/bitcoin#13046

The ZIP 143/243 logic is ported from https://github.com/zcash-hackworks/zcash-test-vectors
zkbot added a commit to zcash/zcash that referenced this issue Nov 18, 2020
Enable mininodes to construct blocks in RPC tests

Includes changes to disable difficulty adjustment on regtest, cherry-picked from:
- bitcoin/bitcoin#6853
- bitcoin/bitcoin#13046

The ZIP 143/243 logic is ported from https://github.com/zcash-hackworks/zcash-test-vectors
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

9 participants