[Ded7xSEoPKYNsDd]

In my toy blockchain implementation, I just went with two constraints: 1) every timestamp must be strictly larger than the one of the previous block (this makes difficulty calculation easier) 2) timestamps may not be in the future (except for a little wiggle room for unsynchronized clocks)

My reasoning was roughly as follows:

Miners are incentivized to pick very large timestamps, because the longer it takes to mine X blocks, the easier becomes the proof of work they need to solve, giving them more block rewards and transaction fees in the long run. But if they want the network to accept their blocks, they can't pick timestamps in the future, so the best they can do is pick the current time as their timestamp.

[Taek]

Your method is easily exploited by a malicious miner. Clocks across the network are going to have some inherent amount of skew. By forcing blocks to have incrementing timestamps and also by refusing to accept blocks in the future, you have made it easy for me as a miner to commit abuse. Instead of picking the exact current time, I will pick a time that is as far in the future as the network allows (taking full advantage of the wiggle room).

Because other miners are required to use a higher timestamp for their block to be valid, they have no ability to correct my outlier time. You have essentially allowed me to put the blocktime permanently forward by the allotted wiggle room, and also you have allowed me to consume all that space you allocated for miners who have clock skew.

It's overall a small attack, but highlights that even tiny decisions can have consequences that impact security. Bitcoin accounts for this by requiring that timestamps be greater than the median of the past 11 blocks, and that's enough to prevent one evil miner from forcing the block times forward for all blocks.

[Ded7xSEoPKYNsDd]

Yes, if the next block by an honest miner is very quick it will pick a timestamp of (wrong_timestamp + 1) instead of the actual time, but after a few blocks they will certainly able to use the correct time again.

But even if all miners decide to do as you say and always pick a date slightly in the future but inside the wiggle room, all that they achieve is a one-time very slight difficulty decrease, but by the next difficulty adjustment that's already lost because by then both the start date and end date of the period are offset by the same amount into the future.

[Taek]

It significantly increases the risk of network forks for people who don't have completely correct clocks. If a merchant has a clock that is off by 1 hour (they didn't adjust properly for daylight savings perhaps, or maybe they just have a really crappy clock), then it's possible they will not even be seeing the most recent 6 blocks, as all of them are 2 hours in the future (3 hours as seen by the merchant).

There are consequences to having blocks that are permanently set forwards beyond a one-time difficulty decrease of 0.6%.

[PaulBGD_]

Okay, this makes sense! I keep thinking too strictly with my constraints.