BlockSlop

Persisted Bitcoin block validity is generally not namespaced by software version or by a complete consensus-ruleset identifier, so this shape is not necessarily unique to BIP110. BIP110 makes it concrete because enforcing and explicitly non-enforcing modes share database formats and users may enable enforcement on an existing datadir. This report establishes the BIP110 transition failure; it does not claim that every possible late soft-fork upgrade is promised to recover automatically.

This defect does not create block B or guarantee a persistent split. A sufficiently-worked legacy-valid / BIP110-invalid block must first exist. What the defect does is prevent a normal late upgrade from reliably healing that disagreement.

Both fresh validation and -reindex-chainstate reject the test block correctly. The defect is specifically the ordinary upgrade / startup path — not the BIP110 checks.

The reproducer uses synthetic low-difficulty regtest blocks. It does not target mainnet, contact peers, or provide a mainnet exploitation workflow. It covers mandatory signaling, active output and script rules, default and level-4 startup, chainstate reindex recovery, and pruning.

The pruned audit placed the violation at height 2, extended to height 600 with -fastprune, and pruned away the block containing the violation before enabling enforcement. Because VerifyDB() stops at missing pruned data and VerifyLoadedChainstate() accepts SKIPPED_MISSING_BLOCKS, even a full level-4 scan starts successfully at the unverified tip. Operators must not be told a partial scan proved the history valid.

BLOCK_VALID_SCRIPTS is the highest persisted validity level, but ConnectBlock() can skip script checks for sufficiently buried ancestors of an assumevalid block and still raise the block to that level. The status never records that BIP110 was enabled or which exact rules ran when the block was connected — so any provenance fix must account for assumevalid shortcuts, and must be evaluated after any ReplayBlocks() recovery, since RollforwardBlock() updates coins without running the checks.

Every absence claim and line reference in this report targets the affected commit f41f01e1e6de7025d52a865bef97f2a67277f0f3. Later remediation commits or working-tree changes are outside the reproduced baseline unless separately re-audited.

Both checks are correct — and both live only inside ConnectBlock(). Default level-3 startup never calls ConnectBlock() for inherited blocks, so a block that slipped in under non-enforcing software is never re-tested against either rule.

The general contextual header function carries the same upgrade warning. BIP110's mandatory- signaling check was deliberately split into ContextualCheckBlockHeaderVolatile() and explicitly re-invoked by ConnectBlock(), so it works during a real reconnect. The failure is that ordinary startup never reconnects inherited blocks at all. The code therefore anticipates precisely the upgrade hazard demonstrated here, while only SegWit has a startup guard.

Note the asymmetry: BLOCK_OPT_WITNESS is set when block data is received (see piece 1), not after ConnectBlock() runs — so it proves witness-aware receipt, not that every consensus check executed. BIP110's rules are ConnectBlock()-only and contextual, so its marker must record successful validation under the applicable rules, not mere receipt. AssumeUTXO makes this sharper still: snapshot activation literally fakes BLOCK_OPT_WITNESS for ancestors — src/validation.cpp:6503-6510 — which a BIP110 guard must not blindly imitate.

No mainnet block-content scan was performed — it wasn't necessary, because the header-derived state showed no BIP110 rule was active or mandatory at the audited tip. This observation must be refreshed as mainnet advances toward height 961,632. Ordinary threshold lock-in can move the applicable window earlier.

Consequences can be high for an affected miner, wallet, or service because it may stay on a branch rejected by clean enforcing nodes. Exploitability has strong preconditions: the violating block must obtain enough proof of work to enter the victim's active chain, and that victim must enable enforcement only after persisting it. Without such a block, the defect remains dormant.

If provenance support ships before any BIP110 rule applies on mainnet, no historical block needs it — enforcing nodes mark blocks prospectively and a later transition is detectable without forcing a rebuild. Mainnet was still before that point at the audited height 958,470. This is time-sensitive.

A block can be connected while the deployment is ACTIVE but with mandatory signaling not yet enforced. A single "applicable" bit would let that block's active-rule provenance wrongly satisfy a later signaling check. The updated test test_phase_specific_provenance connects 145 non-signaling blocks under ACTIVE rules, upgrades to a signaling-enforcing config, and confirms startup still refuses — the ACTIVE bit cannot stand in for the SIGNAL bit. I ran this case locally; it passes.

The report flagged the assumevalid interaction, and reading the updated code confirms it survives. In ConnectBlock(), the RDTS script rule runs only when fScriptChecks is true (which assumevalid sets false for sufficiently buried ancestors), but the marker at line 3088 is set with no fScriptChecks condition. So during a reindex that trusts an assumevalid checkpoint, a block can receive BLOCK_OPT_REDUCED_DATA_ACTIVE even though its script rule never executed. The output-size rule is safe — it runs unconditionally — so only the script-rule portion of the ACTIVE phase is exposed. The patch's tests avoid this by always recovering with -assumevalid=0. This remains the sharpest open question before the fix is complete.