-
Notifications
You must be signed in to change notification settings - Fork 35.7k
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
Ignore new blocks when -stopatheight target has been reached #13713
Conversation
@@ -2705,6 +2705,12 @@ bool CChainState::ActivateBestChain(CValidationState &state, const CChainParams& | |||
{ | |||
LOCK(cs_main); | |||
CBlockIndex* starting_tip = chainActive.Tip(); | |||
|
|||
if (nStopAtHeight && starting_tip && starting_tip->nHeight >= nStopAtHeight && ShutdownRequested()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain the && ShutdownRequested()
in the boolean expression?
If it is here to catch the StartShutdown()
below, the do
.. while
loop is already terminated before it can reach this if
statement.
if (nStopAtHeight && pindexNewTip && pindexNewTip->nHeight >= nStopAtHeight) {
LogPrintf("-stopatheight target (%d) reached, shutting down\n", nStopAtHeight);
StartShutdown();
}
...
if (ShutdownRequested())
break;
} while (pindexNewTip != pindexMostWork);
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The upper if statement with the ShutdownRequested()
does make sure that on future calls of ActivateBestChain() and after StartShutdown()
will not process blocks when stopheight is set at a shutdown is triggered.
The lower if statement is there to trigger the shutdown.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I don't understand is that if ShutdownRequested()
is false, then you will end up processing one more block, and this is not what you want. Removing ShutdownRequested()
and just call StartShutdown
at this place?
Note previous discussion about |
I tend to agree with @sdaftuar's reasoning that it is undesirable to burden the validation code further with this. Then again, if we're not going to fix this we should close #13477 (with "wontfix" and this reasoning), otherwise people will wasting time trying to fix it. |
The last travis run for this pull request was 50 days ago and is thus outdated. To trigger a fresh travis build, this pull request should be closed and re-opened. |
This change is already a lot smaller than the previous attempt. Being able to produce a deterministic UTXO set for a given height, as well as block files and indexes, could be quite useful. There may be other approaches than |
Lightly tested on testnet and it seems to indeed fix the issue. |
@jonasschnelli this is not good. bitcoind -stopatheight 500000
# Wait it reached it
bitcoin-cli gettxoutsetinfo
# Note the UTXOSet hash
bitcoin-cli stop
tar xcf "bitcoin-chainstate-snapshot-500000.tar" ~/.bitcoin/chainstate
# Upload the bitcoin-chainstate-snapshot-500000.tar on a public location
# Sign the snapshot shasum Then somebody who wants to verify and sign the snapshot as well would repeat # On reference machine
bitcoind -stopatheight 500000
# Wait it reached it
bitcoin-cli gettxoutsetinfo
# Note the UTXOSet hash Then try to import the UTXO set from the tar # On low powered device
tar xvf bitcoin-chainstate-snapshot-500000.tar -C ~/.bitcoin/chainstate
bitcoind -stopatheight 500000
bitcoin-cli gettxoutsetinfo
# Check that the utxoset hash is the same as on the reference machine Then he can add his signature to the shasum of If you stop the node once the height is reached, then there is no way to have the hash of the utxoset with |
@NicolasDorier I totally agree your workflow is what we should strive for. However this PR only fixes a bug in the existing behaviour. Let's redefine |
Ah got it, this is already the current situation. I misunderstood thinking it was changing the behavior. |
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. |
Needs rebase |
There hasn't been much activity lately and the patch still needs rebase, so I am closing this for now. Please let me know when you want to continue working on this, so the pull request can be re-opened. |
If the
-stopatheight
target has been reached, a shutdown will be triggered, though, already loaded blocks will still be activated, making it impossible to precisely stop at a certain height.This PR will ignore future blocks once the
-stopatheight
target has been reached.Fixes #13477