<p>Block headers contain timestamps. Those timestamps cannot be changed without redoing the work on those blocks. If we have consensus about which chain has the most work, we also have consensus about what the next difficulty should be. Those timestamps might not be correct: you rightly note that a miner might lie about what timestamp a block was mined at. </p>

<p>What mitigations does Bitcoin have against miners lying? If a block timestamp is before the median of the last 11 blocks, the block will be rejected. If a block timestamp is more than 2 hours later than the clock of the node validating the block, the block will be temporarily rejected.</p>

CC BY-SA 3.0
2017-06-23T10:53:16.560Z
OK so the solutions are not ideal, but heuristic/practical.
user8162717
CC BY-SA 3.0
2017-06-22T20:46:56.050Z
2017-06-22T20:51:59.700Z
2017-06-22T20:51:59.700Z
Nick ODell
<p>While re-calculating the difficulty every 2016 blocks, how do nodes agree on the new difficulty? There is no unique timestamp on the p2p  network, because nodes can lie about their time stamps. Let us say I calculated the new difficulty and found N, another person found N+3. How is the consensus about the new difficulty arises? The formula depends on the time elapsed for the last 2016 blocks, so without a consensus about time stamps, how do we arrive at a consensus about the new difficulty?</p>

<bitcoind><timestamp>
How do nodes agree on timestamps?
user8162717
# How do nodes agree on timestamps?

(Asked by: username_0 on 2017-06-22)

While re-calculating the difficulty every 2016 blocks, how do nodes agree on the new difficulty? There is no unique timestamp on the p2p network, because nodes can lie about their time stamps. Let us say I calculated the new difficulty and found N, another person found N+3. How is the consensus about the new difficulty arises? The formula depends on the time elapsed for the last 2016 blocks, so without a consensus about time stamps, how do we arrive at a consensus about the new difficulty?

**Tags:** bitcoind, timestamp


---

## 1 answers

### Answer by username_1 on 2017-06-22. Score: 2 | Accepted answer

Block headers contain timestamps. Those timestamps cannot be changed without redoing the work on those blocks. If we have consensus about which chain has the most work, we also have consensus about what the next difficulty should be. Those timestamps might not be correct: you rightly note that a miner might lie about what timestamp a block was mined at.

What mitigations does Bitcoin have against miners lying? If a block timestamp is before the median of the last 11 blocks, the block will be rejected. If a block timestamp is more than 2 hours later than the clock of the node validating the block, the block will be temporarily rejected.

> **Comments:**
> **username_0**: OK so the solutions are not ideal, but heuristic/practical.  

---

