1

Will other nodes refuse the mined block if the timestamp is too far apart from local or UTC timestamp or will they blindely accept the block if the PoW is correct?

earizon
  • 606
  • 4
  • 15

1 Answers1

0

It depends on the client, but currently Geth and Parity reject blocks that are more than 15 minutes later than local clock time. That is, if my node sees that it's 12:00pm, and you mine a block with a timestamp of 12:20pm, then my node will not process that block.

The white paper https://github.com/ethereum/wiki/wiki/White-Paper clearly indicates for block validation: """...Check that the timestamp of the block is greater than that of the referenced previous block and less than 15 minutes into the future """

earizon
  • 606
  • 4
  • 15
natewelch_
  • 12,021
  • 1
  • 29
  • 43
  • Your comment guided me to https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1482.md

    I'm not sure what's the current status. It's just an informal protection in geth and parity implementation. It's defined by some other formal spec?

    I've seen some ¿audited code? in OpenZeppelin using the timestamp (https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/token/ERC20/TokenTimelock.sol).

    With no spec-protection for block timestamp shifts, I think the only safe measure is to use external oracles to input the "physical time" outside the Ethereum network.

     – earizon Dec 18 '18 at 14:58
  • You're correct that it's not defined in the yellow paper. I think that EIP is greatly needed just to make sure the official specification follows implementation, but all major clients implement this same or a stricter future timestamp check. – natewelch_ Dec 18 '18 at 15:57