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
2704@@ -2705,6 +2705,12 @@ bool CChainState::ActivateBestChain(CValidationState &state, const CChainParams&
2705 {
2706 LOCK(cs_main);
2707 CBlockIndex* starting_tip = chainActive.Tip();
2708+
2709+ if (nStopAtHeight && starting_tip && starting_tip->nHeight >= nStopAtHeight && ShutdownRequested()) {
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.
0 if (nStopAtHeight && pindexNewTip && pindexNewTip->nHeight >= nStopAtHeight) {
1 LogPrintf("-stopatheight target (%d) reached, shutting down\n", nStopAtHeight);
2 StartShutdown();
3 }
4
5...
6
7 if (ShutdownRequested())
8 break;
9 } while (pindexNewTip != pindexMostWork);
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.
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 -stopatheight in #13490.
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.
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 -stopatheight, or perhaps we can fix -stopatheight in a less disruptive way, e.g. by rolling back after overshooting.
@jonasschnelli this is not good. Here is what I wished I could do:
0bitcoind -stopatheight 500000
1# Wait it reached it
2bitcoin-cli gettxoutsetinfo
3# Note the UTXOSet hash
4bitcoin-cli stop
5tar xcf "bitcoin-chainstate-snapshot-500000.tar" ~/.bitcoin/chainstate
6# Upload the bitcoin-chainstate-snapshot-500000.tar on a public location
7# Sign the snapshot shasum
Then somebody who wants to verify and sign the snapshot as well would repeat
0# On reference machine
1bitcoind -stopatheight 500000
2# Wait it reached it
3bitcoin-cli gettxoutsetinfo
4# Note the UTXOSet hash
Then try to import the UTXO set from the tar
0# On low powered device
1tar xvf bitcoin-chainstate-snapshot-500000.tar -C ~/.bitcoin/chainstate
2bitcoind -stopatheight 500000
3bitcoin-cli gettxoutsetinfo
4# Check that the utxoset hash is the same as on the reference machine
Then he can add his signature to the shasum of bitcoin-chainstate-snapshot-500000.tar so people can trust it more.
If you stop the node once the height is reached, then there is no way to have the hash of the utxoset with gettxoutsetinfo, and no way for somebody else to independently verify a given utxoset inside a tar file.
-stopatheight (e.g. by adding a stop_sync_but_dont_exit param) in a followup PR.
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
Reviewers, 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.
