Include an explicit definition of the acceptable timestamp drift in the protocol specification.
There is a lack of clarity about how accurate timestamps in the block header must be. The yellow paper describes the timestamp as
A scalar value equal to the reasonable output of Unix’s time() at this block’s inception
This causes confusion about the safe use of the
TIMESTAMP opcode (solidity’s
now ) in smart contract development.
Differing interpretations of ‘reasonable’ may create a risk of consenus failures.
The yellow paper should define a timestamp as:
A scalar value equal to the output of Unix’s time() at this block’s inception. For the purpose of block validation, it must be greater than the previous block’s timestamp, and no more than 15 seconds greater than system time.