Include an explicit definition of the acceptable timestamp drift in the protocol specification.
Motivation
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 block.timestamp or now ) in smart contract development.
Differing interpretations of ‘reasonable’ may create a risk of consenus failures.
Specification
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.
Rationale
Both Geth and Parity reject blocks with timestamp more than 15 seconds in the future. This establishes a defacto standard, which should be made explicit in the reference specification.
It should be noted that the “no more than 15 seconds in the future” rule does not apply to ommers. Need to be careful we don’t imply it does when adding this to the YP.
Word on the street is that the Jello Paper is going to be the canonical reference going forward. What does it say?
I’ve got a work-in-progress PR to codify in the EIPs README where canonical representations / specifications live, and how this interacts with EIP expectations.
I think this EIP is useful AND that it might be more of a matter of a PR against the Jello Paper? Not sure!