<p>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.</p>

<p>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.</p>

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

<p>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.</p>

CC BY-SA 4.0
2018-07-24T20:02:41.520Z
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
CC BY-SA 4.0
2018-07-25T09:31:04.630Z
Alright, I accept that detail had slipped my memory. I will re-evaluate the writing of the first paragraph.
Willtech
CC BY-SA 4.0
2018-07-25T09:34:01.967Z
@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
CC BY-SA 4.0
2018-07-26T12:38:21.387Z
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
CC BY-SA 4.0
2018-07-23T21:11:33.443Z
2018-07-23T21:11:33.443Z
Willtech
<p>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.</p>

<p>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. </p>

CC BY-SA 4.0
2018-07-23T20:39:19.113Z
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
CC BY-SA 4.0
2018-07-23T20:22:10.880Z
2018-07-23T20:22:10.880Z
0xb10c
<p>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.</p>

<p>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.</p>

<p>No intervention is required.</p>

CC BY-SA 4.0
2018-07-24T23:42:57.817Z
2018-07-24T23:42:57.817Z
G. Maxwell
<p>Upon receiving a newly mined block, the block timestamp validation is performed here:</p>

<p><a href="https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3263-L3270" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L3263-L3270</a></p>

<p>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? </p>

<p>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?</p>

<attack><timestamp>
What prevents DoS based on near-valid block timestamps?
bgd223
# What prevents DoS based on near-valid block timestamps?

(Asked by: username_0 on 2018-07-23)

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?

**Tags:** attack, timestamp


---

## 3 answers

### Answer by username_1 on 2018-07-23. Score: 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.

> **Comments:**
> **username_0**: 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  
> **username_1**: Alright, I accept that detail had slipped my memory. I will re-evaluate the writing of the first paragraph.  
> **username_1**: @username_0 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 username_3's explanation.  
> **username_0**: 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.  

---

### Answer by username_2 on 2018-07-23. Score: 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.

> **Comments:**
> **username_0**: 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.  

---

### Answer by username_3 on 2018-07-24. Score: 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.


---

