[mblowes]

Enforces the existing BIP94 timewarp check on mainnet from EcashHeight. One condition in ContextualCheckBlockHeader; nothing else changes in consensus.

Correction (2026-10-12, after review): miners' templates need a fix before this can activate. The first version of this description said block templates already comply. That is true only of Core's own template. eCash's getblocktemplate refuses callers that do not claim the bip300301 rule and sends miners to bip300301_enforcer (src/rpc/mining.cpp), and the enforcer's template server does not apply the rule: it sets mintime to MTP + 1 and curtime to the wall clock (cusf-enforcer-mempool lib/server.rs, under a // TODO: calculate this correctly; the commented-out alternative there, max(MTP + 1, now), does not include the timewarp floor either). Read from the code; the enforcer was not run against this PR.

• What goes wrong without the fix: the last block of a 2016-block window may be stamped up to 2 hours ahead (MAX_FUTURE_BLOCK_TIME). The next block must then be no earlier than that time minus 600 s. Miners on enforcer templates stamp it with the wall clock, so their retarget blocks are rejected (time-timewarp-attack) for up to about 110 minutes. Anyone who wins that one block can cause this, at every retarget; so can a miner whose clock runs more than 10 minutes fast. No chain split and no lost funds, but wasted work and a possible stall.
• The fix, in the template server: at heights divisible by 2016, mintime = max(MTP + 1, prev.time - 600), otherwise MTP + 1; and curtime = max(now, mintime). It has to ship before this rule activates (block 973,728 if merged before launch). Reported as Block template ignores the BIP94 timewarp limit at retarget heights LayerTwo-Labs/cusf-enforcer-mempool#132.

Why. Bitcoin measures each 2016-block window from its own first block. A miner with majority hash can stamp each window's first block far in the past, make every window look slow, and cut difficulty up to 4× per retarget while mining fast. On Bitcoin that needs most of the world's SHA-256 hash; on eCash a majority can be rented. Mainnet has the check off (enforce_BIP94 = false, as in Core). Before launch it costs nothing to turn on; afterwards it is a coordinated soft fork.

Why not just set enforce_BIP94 = true. The check would then run from genesis, and Bitcoin block 203,616 is stamped 1,127 s before block 203,615, so the node would reject Bitcoin's history at that block. The flag also switches pow.cpp to testnet4's first-block nBits rule, which is not needed here.

Checked on a fully validated Bitcoin Core 29.0 node (read-only RPC): block 203,616 is stamped 1,127 s before its parent; it is the only one of the 481 retarget blocks from 2,016 to 969,696 stamped more than 600 s early (the next worst is 320,544, at −491 s); all 481 are within 7,200 s. On betanet the fork block 967,680 (+116 s) and the retargets 969,696 (+562 s) and 971,712 (+16 s) would all pass.

Scope. Only mainnet sets EcashHeight, so testnet3, testnet4, signet and regtest are unchanged. A network with its own genesis and EcashHeight = 0 gets no check from this path and needs enforce_BIP94; the comment in consensus/params.h now says so (it said 0 means "from genesis"). With ASERT (#2), the check still fires at every 2016th height; it is harmless there but no longer guards the difficulty after the anchor. #2 and #4 merge without conflict.

Limit. 600 s, matching MAX_TIMEWARP and Core's template code. BIP54 (Great Consensus Cleanup) proposes 7,200 s for Bitcoin. Every Bitcoin retarget block passes 7,200 s, so a version with that limit could start at genesis instead.

Tested (2026-10-12, Release build at -j2): pow_tests and validation_tests pass; the full unit suite shows the same three failures as master (bip324_tests, net_peer_connection_tests, script_tests, all from the fork itself); mining_basic.py passes; master + #2 + #4 also passes pow_tests, feature_asert.py and mining_basic.py. This PR has no test of its own: none can reach the new branch, because only mainnet sets EcashHeight. During review we wrote a functional test that gives regtest a fork height (a regtest-only switch like #2's -testasertanchor); it passes on this PR and fails on master and on two mutants (> for >=, and the EcashHeight > 0 guard removed). It needs three test-framework fixes for this fork that every functional test needs anyway (the ecash.conf file name, the bip300301 rule in getblocktemplate requests, eCash's regtest network magic). We can open it as a follow-up PR if you want it.

The second commit changes comments only.