reducing timestamp manipulation attack surface

[l0k18]

zawy12/difficulty-algorithms#30

Further reading of this article to identify changes that will improve post-hardfork timing security. Disallowing non-progressing block timestamps will be one measure, already the difficulty adjustment scheme does not have a hard limiter but instead an accelerating limiter.

There may be other considerations to look into as well, as the article mentions also not using MTP, but also requiring a unique timestamp on every block so time must transit at least 1 second by timestamps between sequential blocks.

[l0k18]

as well as enforcing monotonic timestamps, the furthest forward a block can go has to be much smaller than the averaging window, longer block time intervals are thus more secure compared to the scope for distorting time, and miners generally defaulting to sticking to one second ahead of the previous one or their local time ensures that when the time is stretched forwards, it is forced that it be reversed, and quickly, towards what miners actually see.

[l0k18]

for post hard fork, the value has been set to 19 minutes ahead. This is not a consensus value but were it too difficult could cause a fork. Having never personally seen an in-use clock more than 10 minutes unintentionally wrong, this allows about this much in both directions relative to each node's time, which likely is nearly the same within a minute. It does not allow very much time to stretch the chain's clock.

[l0k18]

it is now monotonic timestamps enforced for hard fork, always at least 1 second ahead for every block, and 90 seconds is the node's future timestamp reject threshold