I am reading the White Paper of Ethereum. And at the Mining Section, I do not understand the this part "less than 2 hours into the future" of the following sentence:
Check that the timestamp of the block is greater than that of the previous block and less than 2 hours into the future.
And also, there is also a note here I do not understand:
2. Technically, the median of the 11 previous blocks.
Just to add to Rob's answer...
I've variously seen this "2 hours" described in different places as different lengths of time, so I'd take it with a pinch of salt. (For example, here it's 900 seconds, which is 15 minutes.)
Note that in the Yellow Paper, this imposed time limit is absent. The only stipulation is that the current timestamp is greater than that of the parent block.
4.4.4. Block Header Validation
(48) Hs > P(H)Hs
Also, from the Geth code, it's not immediately clear that anything near this limit is imposed. (The relevant code is verifyHeader() in consensus.go.)
What appears to be imposed is there only to allow for clock drift between different nodes in the network, and here only a 15-second difference is allowed. (Coincidentally similar to the block time? Not sure.)
If a new block has a timestamp greater than 15 seconds from the current time (not the timestamp of the parent - we're not saying anything about the block time here), then it's temporarily marked as invalid. It will be marked as valid (and allowed to be imported) once the current time is within 15 seconds of this future timestamp.
So if a miner deliberately created a block with a false future timestamp which was further into the future than this, it'd be marked as invalid (though only temporarily). This temporary invalidity would give other miners a chance to mine their own version of the block with a true timestamp, making the cheating miner's block (in effect) permanently invalid.
(Relevant: "#15629 Relax requirements when determining future-blocks".)
- Technically, the median of the 11 previous blocks.
Not sure about this bit.
Miners record a block timeStamp with each discovered block. This value cannot be confirmed or disproved by observers without reference to an accurate external time source, which we do not want.
TimeStamps are checked two ways. First, the clock should not jump too far into the future because that is highly unlikely owing to the predictable pace of block discoveries. See the link below for an interesting discussion about the practical implications and implementation details.
Second, the clock must never run backward, so the timestamp of a new block should always come after the time stamp of the previous block in the chain.
There is an interesting thread about timeStamps in Ethereum over here: Can a contract safely rely on block.timestamp?
Hope it helps.
