Geth and Parity nodes differ in a fundamental way when they validate block headers.


According to the yellow paper

4.3 timestamp: A scalar value equal to the reasonable output of Unix's time() at this block's inception; formally Hs
4.4 Hs is the timestamp of block H and must fulfil the relation: Hs > P(H)

Both implementations require that the machine running the node to resolve it's NTP protocol to pool.ntp.org for no more than 10 seconds


But, they differ when it comes time to validate the block. Geth and parity will check if that timestamp is greater than the parent's timestamp, but geth will outright reject any block that has its current time set in the future


Given the fact that parity allows for a looser interpretation of timestamp validity, how do these protocols resolve on different blocks being proposed, does the stricter protocol win in the end? Additionally, is there a way to quantify this variation of timestamps?


I doubt there has ever been an actual case of this happening (don't quote me on that unless you also quote that I said not to quote me on it). In order for a block to be valid by Parity and not valid for Geth, a miner would have to knowingly create a block with a time sufficiently in the future, and this is against their best interest since nodes will converge on Geth-valid blocks (because Geth is by far the largest by node count) and the miners would lose their rewards from the orphaned blocks. A problematic scenario would be if Parity nodes became the majority. If that happened, a miner could create one of these Geth-invalid but Parity-valid blocks and the majority of the network would be Parity, but the Geth nodes would be on a fork.


Just brainstorming here but I guess the reason block times are accurate is for the same reason the miners agree on all of the other parameters a block must have.

Eg they agree that they pay 3 Eth, at time of writing, for each new block. If a miner tries to award themselves more than the block reward their block is rejected. Similarly if a miner submits a block with a time that is different from the real time, their block is rejected. It isn't in the interest of the network as a whole to have inaccurate block times.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.