Unbreaking testnet4

The discussion initiated by Greg Maxwell on the Bitcoin Development Mailing List addresses a specific issue within Testnet4 related to its time window mechanisms. Testnet4 operates with two key time-related rules which interact significantly: firstly, the difficulty exception rule allows for the generation of a minimum-difficulty block if its timestamp is at least 20 minutes past the parent's timestamp. Secondly, the future limit rule inherited from mainnet prevents any block header from being accepted if its timestamp is more than 2 hours ahead of the node’s current time. The interaction between these rules permits miners to exploit these windows, resulting in bursts of five or six blocks before a stop, until real-time catches up.

Maxwell proposes a targeted solution aimed at mitigating this issue without overhauling the system drastically. His recommendation is to reduce the future limit to 20 minutes specifically for Testnet4. This adjustment would effectively collapse the potential for multiple-block bursts to just one block ahead of the clock, streamlining block acceptance and reducing anomalies created by the current settings. The proposal involves making MAX_FUTURE_BLOCK_TIME a chain-specific parameter and setting it to 20 minutes for Testnet4, while maintaining the two-hour limit for mainnet and signet.

This change is viewed as a soft fork tightening, where an upgraded node would accept a subset of the headers that an old node accepts. It depends on the wall-clock, meaning headers rejected for being too far in the future will eventually become valid as real-time catches up. However, there is a failure possibility where an un-upgraded miner might produce headers stamped more than 20 minutes ahead, which would initially be rejected by upgraded nodes but should be resolved as hash rates on compatible branches increase. The proposed modification underscores the balance between maintaining flexibility in test environments and ensuring robustness against exploits.