This limitation is intended to manage the efficiency and capabilities of high-throughput mining equipment, specifically those exceeding 280 TH/s. To accommodate these powerful machines, StratumV2 allows for the option of utilizing multiple "channels" to request additional jobs from the mining pool, or alternatively, constructing their own work by requesting a merkle path to the coinbase. This enables them to adjust the extranonce instead of relying solely on nTime modifications. The practice of rolling nTime more frequently than the permitted rate appears to be uncommon among existing miners. This is inferred from the implementation of pool software that outright rejects attempts to roll nTime past a 600-second threshold, suggesting such behavior was not anticipated or accounted for during the drafting of the specification.

Furthermore, the decision to enforce a 600-second limit on nTime adjustments within testnet4 serves as a precautionary measure. By establishing this boundary, the goal is to create an environment conducive to thorough testing. This ensures that mining operations remain unaffected by the constraint, thereby validating the safety and practicality of the 600-second limit for practical use. The imposition of this limit is based on the belief that it will not detrimentally impact miners, supported by current data and practices observed within the mining community.

The argument against designing protocols with compromises to cater to hypothetical future mining technologies that might circumvent existing limitations is emphasized. Specifically, it is argued that protocol designs should not be compromised by the potential development of mining devices that may choose to ignore established restrictions on nTime rolling, as outlined in both the StratumV2 and Bitcoin protocols. The focus should remain on creating robust and effective protocols that adhere to current technological standards and limitations, ensuring their integrity and functionality without yielding to speculative future scenarios.