[chrisguida]

The testnet4 RDTS deployment expired on 2026-10-13 15:00 UTC (block 152963 was the first connected without the rules). This moves the testnet4 expiry to 2027-04-01 00:00 UTC, so testnet4 keeps exercising RDTS ahead of the mainnet expiry (2027-09-01), and it rehearses an extension of the rule before mainnet might need one.

The extension is retroactive: a chainstate revalidation deployment (rdts_testnet4_extension_20270401, from height 152963) makes a node that connected those blocks under the previous parameters rewind and re-check them. All RDTS checks run in ConnectBlock (script flags, the reduced weight limit, the output size limit), which is what the revalidation framework re-runs. Tested on the live chain: a node synced with the previous parameters, restarted on this change, rewound 6 blocks to 152962, reconnected 152963 to 152968 with RDTS active and followed the tip.

With #429 the long coinbase maturity hold on testnet4 ends with the RDTS expiry, so this also keeps that hold a softfork on 29.4.2 (which holds until block 158111) on testnet4, closing the testnet4 finding from the #429 review. Mainnet is unchanged.

One commit on the base #429 uses. For assembly it has to sit after #429 and #425 (#425 inserts the line directly above the testnet4 expiry, and #429 rewrote the test that asserts the revalidation deployments), so an assembly-ready copy rebased onto those two is at chrisguida/rdts-testnet4-extension-k429-29+knots, with the deployment-test lookup adapted to #429's version of the test; in the spec it goes right after k425.

Tests: rdts_params_tests/rdts_testnet4_extension pins the date, the rule being active again at the old boundary, and the deployment entry; coinbase_maturity_tests looks the long-maturity deployment up by name instead of requiring exactly one. Full build, unit and functional suites pass.

Release notes: doc/release-notes-rdts-testnet4.md.

[jasonsopko]

Tested f4d4981 on the live testnet4 chain and read the copy the rc1 spec merges. The code does what it says and the rewind works. Two things the description leaves out: this PR also lengthens the testnet4 coinbase hold, and the coupling in #429 that makes it do so would lengthen the mainnet hold the same way if RDTS is ever extended there.

The hold gets longer. With #429, the coinbase hold ends when RDTS does, on both chains (CoinbaseMaturityLongReleaseTime = consensus.RdtsExpiryTime). So moving the testnet4 RDTS expiry also moves the end of the testnet4 hold, from 2026-10-13 to 2027-04-01. 29.4.2 releases those coinbases at block 158111, which at the last 119 blocks' average of 32.9 minutes comes on 2027-02-08, so the hold here outlasts the one it replaces by about 7 weeks. The release notes should say that. Holding until both the old release height and the old expiry, as suggested on #429, would have kept the softfork without moving the release.

The same lever exists on mainnet. An RDTS extension there extends the one-year hold past 2027-09-01 by itself, since the hold has no date of its own, and the description calls this PR a rehearsal for such an extension. If the mainnet hold is not meant to move with the RDTS expiry, it needs its own release time in #429 before rc1.

Now the checks.

The boundary is right. Block 152961's median-time-past is 1791902645 and block 152962's is 1791904476, so 152963 is the first block whose parent had reached the old expiry of 1791903600.

Upgrade path, on the real chain: a fresh v29.4.2.knots20260508 node synced testnet4 to 153061 with assumevalid at 152962, so it checked 152963 through 153061 in full and with no RDTS rule, which is where a 29.4.2 node stands today. Started on this build with the same datadir, it logged a rewind of 99 blocks to 152962, reconnected them with RDTS active, and ended on the same hash for 153061 as before and as mempool.guide. getdeploymentinfo for block 152962 now reports reduced_data active with expiry_time 1806537600, where 29.4.2 reported it inactive. A second start on this build did not rewind. So no block from 152963 to 153061 breaks an RDTS rule, and for the chain that exists today the extension is a softfork on 29.4.2. Until testnet4 miners run it, a 29.4.2 miner can still produce a block this build rejects.

Your #429 reply says the new expiry is "past block 158111 at any plausible block rate". That holds, with room: the interval would have to average more than 47.6 minutes from here to April 1st for 158111 to land after the new expiry. It averaged 20.6 minutes over the 1,000 blocks before October 10th and 32.9 over the last 119.

The spec copy b7fa3d5 (chrisguida/rdts-testnet4-extension-k429-29+knots, in candidate a7d7d2e) carries the same chainparams, release-note and rdts_params_tests changes as this PR. Its coinbase_maturity_tests change differs in 4 lines, where it expects #429's open-ended deployment instead of the release height minus one.

Build, ctest 131 of 131, functional suite 214 passed, 140 skipped, 1 failed: tool_cli_completion.py, which fails on the base commit this PR shares with #429 and was noted there. Test script, node config and the node's revalidation log lines: https://gist.github.com/jasonsopko/e7b8901d1350c8480e66fab74b221cdb

[kwsantiago]

Tested ACK b7fa3d5 (spec copy, same chainparams as f4d4981) on live testnet4. A 29.4.2-synced node rewinds 128 blocks to 152962 and keeps its tip; a block proposal at 153091 with a 40-byte coinbase output is now rejected with bad-txns-vout-script-toolarge.