However, in the development phase of testnet4, this duration was extended to 7200 seconds. This adjustment aimed to facilitate miners utilizing their system clocks more effectively. Despite this intention, concerns were raised regarding the approach's viability, leading to a reversion to the original 600-second timing, as detailed in the GitHub pull request.

The proposition to revert the timing back to 7200 seconds is now on the table again, albeit for different reasons than those that motivated the initial change during the testnet4 phase. The argument supports the idea that a timeframe shorter than one day should suffice for the intended purposes, sidestepping the specific issues the testnet4 adjustment sought to address. Additionally, this discussion incorporates considerations about potential vulnerabilities, such as those highlighted in the analysis of Zawy's alternating timestamp attack, which can be further explored through the shared discussion link. This perspective underscores an ongoing effort to refine the system's robustness against various forms of manipulation or inefficiency, with timing adjustments being a focal point of these optimization efforts.