
**Describe the issue**
Core can not check past blocks correctly

**What behavior did you expect?**
Expected setting checkblocks=0, checklevel=6, and assumevalid=0 to result in verification that the chain is valid. And that it would take nigh upon forever. It doesn’t. It poops out in about 12 hours. 

**What was the actual behavior** 
Debug.log highlights:
(Note: Block height at time of message was 693086)
init message: Verifying blocks…
Verifying last 693086 blocks at level 4
[0%]… [10%]… [20%]… [30%]… [40%]…ERROR: VerifyDB(): *** coin database inconsistencies found (last 601365 blocks, 142571 good transactions before that)

Corrupted block database detected.

**How reliably can you reproduce the issue, what are the steps to do so?**
100% reproducible. To reproduce, just try rechecking the chain. I don’t know the fastest way to do this, in fact, I’m not even entirely sure how many checklevels there even are but I read 6 on stack exchange…anyhow, just add this to bitcoin.conf and restart node:

assumevalid=0
checkblocks=0
checklevel=6

**What version of Bitcoin Core are you using, where did you get it (website, self-compiled, etc)?**
0.21.1.0; self compiled. I got the code two different t ways: over Internet using git at the command line and from the friendly lizards working for blockstream in space via satellite using blocksat-cli.

**What type of machine are you observing the error on (OS/CPU and disk type)?**
I’ve checked two intel architecture nodes I have running. Both are little intel NUCs.
Ubuntu 20.04 Lts/2.6 ghz intel i7 underclocked at 2.4 GHz max just in case/16 and 32 GB RAM at conservative BIOS settings/NVME SSD (tried it on one node with a single Samsung 970 evo plus formatted ext4 filesystem and another with 2 Samsung 980 NVME in raid 1 configuration…also ext4)

**What is your operating system and its version? If Linux, what is your desktop environment and graphical shell?**
Whatever is default for Ubuntu 

**Any extra information that might be useful in the debugging process.**
Someone far smarter than me can reproduce this too (dflate)

Somehow relates to this…see explorers disagreeing (via dflate)

https://blockstream.info/tx/d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599?expand

https://explorer.bitcoin.com/btc/tx/d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599


Otherwise, not yet. I keep my node off the internet, because, you know, satellite and stuff…but I’ve typed out by hand what seems relevant above. 
<!--- This is normally the contents of a `debug.log` or `config.log` file. Raw text or a link to a pastebin type site are preferred. -->

AsserLocHeld(cs_main);
    piexNew->nTx = bloc.vx.size();
    piexNew->nChainTx = 0;
    piexNew->nFile = pos.nFile;
    piexNew->nDaaPos = pos.nPos;
    piexNew->nUoPos = 0;
    piexNew->nSaus |= BLOCK_HAVE_DATA;
    if (DeploymenAciveA(*piexNew, m_chainman, Consensus::DEPLOYMENT_SEGWIT)) {
        piexNew->nSaus |= BLOCK_OPT_WITNESS;
    }
    piexNew->RaiseValidiy(BLOCK_VALID_TRANSACTIONS);
    m_blocman.m_diry_blociex.inser(piexNew);
    if (piexNew->pprev == nullpr || piexNew->pprev->HaveTxsDownloaded()) {
         
        sd::deque<CBlocIex*> queue;
        queue.push_bac(piexNew);
         
        while (!queue.empy()) {
            CBlocIex *piex = queue.fron();
            queue.pop_fron();
            piex->nChainTx = (piex->pprev ? piex->pprev->nChainTx : 0) + piex->nTx;
            piex->nSequenceId = nBlocSequenceId++;
            if (m_chain.Tip() == nullpr || !seBlocIexCaida.value_comp()(piex, m_chain.Tip())) {
                seBlocIexCaida.inser(piex);
            }
            sd::pair<sd::mulimap<CBlocIex*, CBlocIex*>::ieraor, sd::mulimap<CBlocIex*, CBlocIex*>::ieraor> range = m_blocman.m_blocs_unlined.equal_range(piex);
            while (range.firs != range.seco) {
                sd::mulimap<CBlocIex*, CBlocIex*>::ieraor i = range.firs;
                queue.push_bac(i->seco);
                range.firs++;