db: verify the tail of the chain on startup and back out of a bad tip

[Bitflash-sh]

A node that accepted blocks its current rules would reject — because it was running an older build, or because the tip it landed on was never valid — had no way to notice. It kept the branch, kept building on it, and kept mining coins the rest of the network throws away. The only cure was deleting blk*.dat by hand, which requires knowing something is wrong in the first place.

A node here once mined a 323-block fork for five days exactly like that.

Satoshi added this upstream after the block 74638 incident, for the same reason: so nobody would have to delete files.

What it does

On load, walk back from the tip running CheckBlock on each block. If one fails, move the best chain back to its parent, disconnect what came after, and let the node re-download from peers.

Only the last 288 blocks are checked by default — about ten hours at a two-minute target — because every check costs a RandomX hash. /checkblocks=N changes it, 0 does the whole chain.

Two things worth reviewing

The repair runs in LoadBlockIndex() in main.cpp, not in CTxDB::LoadBlockIndex where the detection happens. CTxDB::LoadBlockIndex walks the index with a cursor it never closes, so it is still holding read locks when it returns, and a write transaction opened alongside it waits on them forever. That is measured, not guessed: the first version came up, printed the diagnosis, and hung there with nothing in any log. Closing that cursor is its own fix — it is one of the things Satoshi fixed in c5c7911da that this fork never got — and is deliberately not bundled here.

A failed rollback reports and starts anyway. Refusing to start would leave the operator with no node to read the message from.

What it does not catch

What CheckBlock checks: proof of work, merkle root, duplicate transactions, sigops, timestamps. It does not re-verify signatures or spends — that would mean rebuilding the transaction index. So a tip that is invalid only under the script rules from #15 is not caught by this.

Testing

Forcing a block at tip-5 to fail verification:

LoadBlockIndex(): hashBestChain=55b9f6a291a9fe  height=3922
LoadBlockIndex() : *** bad block at height 3917, hash=3767c2cb9dc601
LoadBlockIndex(): verified 288 block(s)
LoadBlockIndex() : *** moving best chain back to height 3916, discarding 6 block(s)
LoadBlockIndex() : now at height 3916, will re-download from peers

The node stayed up and re-synced past its old tip, to 3928. Without the forced failure it verifies 288 and says so. Every error in the log during the run was a dead .btf descriptor or the down Nostr relay — none from this path.