[ZERODAYKEK]

This builds on #467 (thanks @alphaminetech). #467 keeps #419's rolling coinbase maturity in force for as long as
RDTS (BIP110) is. This PR changes two mainnet parameters on top of it:

1. RDTS continues. RdtsExpiryTime becomes INT64_MAX (it was 1819756800, 2027-09-01 00:00 UTC), so
   BIP110's rules stay in force at every height from the BLAKE2b fork.
2. The rolling maturity is 40320 blocks (~280 days) instead of 6480 (~45 days). T.Softfork: Keep the 6480-block (~45-day) rolling coinbase maturity until RDTS expiry #467 ties the rolling rule to
   RDTS, so it continues for as long as RDTS does: every reward mined from height 973440 matures 40320 blocks
   after the block that mined it.

Why 40320

We posit 40320 blocks as a reasonable compromise between the 45 days in force today (#419, #467) and the one
year proposed in #429. It is also closer aligned with the gestation period of a human baby: 40 weeks, 280 days,
which is 40320 blocks at ten minutes each. A reward is conceived when its block is found and can be spent when
it is born.

Because nothing expires, rewards are no longer released early near a cut-off date, an effect #467's release
note describes for rewards mined shortly before RDTS expiry.

What this asks of reviewers

• RDTS becomes permanent. BIP110 was adopted as temporary. Its limits would stay: the 800000-weight block
  limit, 34-byte output scripts, the OP_RETURN data limit, and the input rules it gates.
• Policy is stricter for longer. As in T.Softfork: Long coinbase maturity (part 1 of 3) #419 and T.Softfork: Keep the 6480-block (~45-day) rolling coinbase maturity until RDTS expiry #467, mempool admission asks the configured long depth of
  every coinbase spend, including coinbases from before 973440 whose consensus maturity is 100. At 40320
  blocks, such spends stay out of default mempools for longer; miners can still include them.
• Wallets and explorers that assume 100 or 6480 blocks for covered rewards need to follow.

Soft-fork property

Both changes only keep or deepen existing rules. Against #419 the valid-block set is the same before height
979920, because no covered reward can reach 6480 confirmations sooner; from 979920 this rejects covered spends
younger than 40320 blocks, which #419 accepts at 100. Against #467 the same holds before 979920; after it, this
asks 40320 where #467 asks 6480, and after 2027-09-01 this keeps the rules where #467 lets them lapse. Unit
tests check that this is never looser than either at every height from 973000 to 990000. Testnet4, the other
public networks and default regtest are unchanged.

Testing

• Unit: coinbase_maturity_tests covers the mainnet schedule at parent median-time-pasts before, at and after
  the old expiry, input depths up to 40321, and the soft-fork property against T.Softfork: Long coinbase maturity (part 1 of 3) #419 and T.Softfork: Keep the 6480-block (~45-day) rolling coinbase maturity until RDTS expiry #467.
  rdts_params_tests checks that mainnet RDTS is active at every parent median-time-past from the fork,
  replacing the tripwire that tied the expiry to the fork height. The full test_bitcoin suite passes.
• Functional, all passing: feature_coinbase_maturity_rolling.py (all four modes),
  feature_coinbase_maturity_pruned.py, mempool_long_coinbase_maturity.py, feature_rdts.py,
  feature_reduced_data_temporary_deployment.py, feature_reduced_data_utxo_height.py, rpc_blockchain.py
  and mining_basic.py. feature_coinbase_maturity_upgrade.py was skipped: it needs previous-release
  binaries.
• Built natively on aarch64 Linux.

Diff against #467

Four files: src/kernel/chainparams.cpp (two mainnet lines and their comments),
src/test/coinbase_maturity_tests.cpp, src/test/rdts_params_tests.cpp and
doc/release-notes-coinbase-rolling.md.

Yo yo yo embryo!

🤖 Generated with Claude Code

[ZERODAYKEK]

no consensus reached