What prevents DoS based on near-valid block timestamps?

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?

bgd223

Posted 2018-07-23T19:42:25.253

Reputation: 141

Answers

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.

0xb10c

Posted 2018-07-23T19:42:25.253

Reputation: 953

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 – 2018-07-23T20:39:19.113

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.

Willtech

Posted 2018-07-23T19:42:25.253

Reputation: 2 657

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 https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3398

– bgd223 – 2018-07-24T20:02:41.520

Alright, I accept that detail had slipped my memory. I will re-evaluate the writing of the first paragraph. – Willtech – 2018-07-25T09:31:04.630

@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 – 2018-07-25T09:34:01.967

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 – 2018-07-26T12:38:21.387

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.

G. Maxwell

Posted 2018-07-23T19:42:25.253

Reputation: 6 039