1

Upon receiving a newly mined block, the block timestamp validation is performed here:

https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3263-L3270

Q1: As for the second check (block timestamp too far in the future), what prevents a miner broadcasting a block that's near the limit in the future and having some of the nodes accept the block, while some other nodes reject the block?

Q2: If a part of the network accepts a block and the other part of the network rejects a block (i.e., not record the block it in its blocktree due to invalid time stamp), can the network recover from this in any way?

Improve this question

3 Answers 3

Reset to default
2

I'm answering both questions at once. It's not uncommon for the network to split i.e. different nodes accepting different blocks as chain tip. In fact this happens from time to time as two or more blocks are found at the same time by different miners. This gets resolved when the next block is found on top one of the previous blocks. The longest chain is valid.

And a miner can't simply set the timestamp when broadcasting. The timestamp needs to be set before finding a valid nonce. Thus a miner is incentivised to mine with a valid timestamp. If the block doesn't get accepted by the network, the hashrate (and electricity) used isn't compensated.

Improve this answer
1
  • Thanks for tackling this, but it doesn't really address the questions, here's why: in the case of a "usual" fork you are referring to, the block trees of differing nodes contain both blocks, whereas in this case, the block trees are essentially different and as such they can't sync/switch to a branch with more proof of work. As for miner's incentive when it comes to timestamp manipulation, sure, the miner is not incentivized, but the question is whether this is theoretically possible or not.
    – bgd223
    Jul 23, 2018 at 20:39
2

It is true that this edge case seems to present an issue, however, the block timestamp will either be valid or not since it is the time since the time embedded in the last valid block with most PoW and not the local time in question.

In the case described, which is not the case but, if may somehow or another be the case otherwise, then some nodes may continue to build upon the block that the other nodes reject. How this would resolve will depend on the percentage of the network split. If 51% or greater of mining power rejects the speculative block then the issue will self-resolve in time as the valid chain is extended further than and having the most PoW. If, on the other hand, 51% or greater of mining power accept the speculative block to build upon then an intervention would be required to pick up the nodes still rejecting or, to discard the invalid chain.

Essentially, if a block complies with the consensus rules (the rules of the reference client) then it is valid.

Others have already stated that it is not wise economically to push the time envelope when mining as it must be decided in advance, so there is an economic disincentive.

Improve this answer
4
  • Thanks for the 2nd paragraph, however the 1st paragraph is wrong: in this case, the upper bound for timestamp validity is determined as local node's time + network time offset (basically estimate on the local time error based on node's peers). As such it's imaginable that a miner mines a block with a timestamp close to the upper bound, and the block gets rejected by some nodes and accepted by other nodes. ref: GetAdjustedTime() in github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3398
    – bgd223
    Jul 24, 2018 at 20:02
  • Alright, I accept that detail had slipped my memory. I will re-evaluate the writing of the first paragraph.
    – Willtech
    Jul 25, 2018 at 9:31
  • @bgd223 Would it not be the case then that in a few minutes the block timestamp would, in fact, be valid? At worst it requires reconsideration of the block or even less, nothing as per G Maxwell's explanation.
    – Willtech
    Jul 25, 2018 at 9:34
  • Agreed, assuming there's no mechanism that re-rejects already rejected blocks in any scenario. and DoS based on the lower bound in this case does not seem to apply.
    – bgd223
    Jul 26, 2018 at 12:38
2

It's normal and not a problem for some of the network to be on one tip block while the rest is on another. When there is a split like this it will eventually be decided by subsequent blocks.

If a block isn't accepted by a node because its timestamp is too far in the future the situation isn't much different: After the timestamp becomes permissible a future block on that fork that would make that fork the longest chain will cause a reorg onto it. So the only difference between this and a split caused by an ordinary block race is that the nodes that rejected the block will take longer to accept it-- not until both the time is valid and a new block appears on that fork.

No intervention is required.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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