[FlyTheElephant1]

Motivation

On current 29.x-knots (with #419), policy already holds coinbase outputs created in the temporary window to 6480-block maturity. The mempool path always passes long_maturity_start_height = 0, so those coins are not relayed or accepted into the mempool until 6480 confirmations.

Consensus does not. In ConnectBlock, the long rule is only applied while the spend height is still inside the temporary window (CoinbaseMaturityLongActiveAt). Once spend height reaches 979920, long_maturity_start_height becomes INT_MAX and every coinbase created in [973440, 979920) drops back to 100-block maturity under consensus.

This change resolves a consensus/policy discrepancy: nodes following policy will not relay or accept into the mempool a spend that consensus still considers valid but will accept a block containing it without this. Without this there is a single-height cliff at 979920 where every historical-window coinbase becomes spendable at once under consensus.

This change attaches the 6480 requirement to the creating height so coins mined in the original window keep the lock under consensus past 979920. Each coin matures individually (973440 at 979920, 973450 at 979930, etc.). Coins created after the window remain at 100 blocks. This makes consensus match the policy already applied to those coins and will not cause a split for any nodes running it or not except for nodes rewriting the code for their node to rip out policy can be split from those running this code or any equivalent or tighter code if they submit a block that contains transactions that violate the policy that we already run.

This does not extend the temporary rule to any coins created after the original window; it only ensures that coins which were already subject to 6480 under both consensus and policy continue to be subject to it under consensus.

Tests

src/test/coinbase_maturity_tests.cpp (historical_window_lock_sticks) covers the new spendability boundaries after the temporary window has closed:

• 973440 is not spendable at 979919 and is spendable at 979920 (973440 + 6480)
• 973450 is not spendable at 979929 and is spendable at 979930
• 979919 (last coin in the window) still requires 6480
• 979920 (first coin after the window) requires only 100

./build/bin/test_bitcoin --run_test=coinbase_maturity_tests reports no errors.

[geobees]

Tested c5de7d0 on top of 58398ba (Ubuntu on WSL2, GCC 15.2).

• build OK, ctest 146/146
• functional: rpc_blockchain (v1+v2), feature_chainstate_revalidation, mempool_long_coinbase_maturity, mempool_spend_coinbase: pass
• With the base src/consensus/tx_verify.cpp swapped in, historical_window_lock_sticks fails 3 checks (973440@979919, 973450@979929, 979919@979919+6479); with this PR's version it passes, so the new test does cover the change.

Notes: the heights 973440/979920 are hard-coded in CheckTxInputs. A trial merge onto #468 (8a4ca1b) conflicts in tx_verify.cpp. I did not test it combined with #468.

[FlyTheElephant1]

Thanks geobees. Yea #477 is this built to be compatible with #468 and do what this does. Every other proposal from everyone except for #468 already solves the problem that this solves, #483 is a fallback option if we think we need to do the simplest possible conclusion to part1. I just made it so it would be here if we need it and simple enough to audit rapidly.

I think in pretty much all cases, #480 makes more sense than this except in the edge case that people cant reach consensus on that but could on this.