<p>I think you have a misconception about what this clause means:</p>
<blockquote>
<p>Full nodes will not accept blocks with headers more than two hours in the future according to their clock.</p>
</blockquote>
<p>You appear to be interpreting this as, if a new block is more than two hours later than the previous block, then do not accept it. That is incorrect. This clause is not about gaps in time between blocks.</p>
<p>The actual meaning of this clause is that, if a new block says it's literally from the future, from a time that the universe has not yet reached, then do not accept it. This clause is about preventing manipulation of the blockchain via falsified timestamps.</p>
<p>This comparison is between the new block's timestamp and your clock, not the new block's timestamp and the previous block's timestamp.</p>

CC BY-SA 4.0
2021-07-23T22:10:15.857Z
2021-07-23T22:16:44.827Z
2021-07-23T22:16:44.827Z
Douglas
<blockquote>
<p>How strict are the time validation rules?</p>
</blockquote>
<p>Very.</p>
<blockquote>
<p>If the next block is mined more than 2 hours after the current block, would this not stall the blockchain?</p>
</blockquote>
<p>No.</p>
<p>It doesn't break the rule <em>&quot;Full nodes will not accept blocks with headers more than two hours in the future <strong>according to their clock</strong>.&quot;</em></p>
<p>Nor does it break the rule <em>&quot;Must be strictly <strong>greater than</strong> the median time of the previous 11 blocks.&quot;</em></p>
<hr />
<p>The above should be clear I hope, but in case it isn't, lets make an example:</p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th>Event</th>
<th>Time</th>
</tr>
</thead>
<tbody>
<tr>
<td>Last block mined</td>
<td>08:00</td>
</tr>
<tr>
<td>Median time of last 11 blocks</td>
<td>07:00</td>
</tr>
<tr>
<td>Current time on my clock</td>
<td>11:00</td>
</tr>
<tr>
<td>Time on block arriving now</td>
<td>12:59</td>
</tr>
</tbody>
</table>
</div><div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th>Rule</th>
<th>Result</th>
</tr>
</thead>
<tbody>
<tr>
<td>(12:59 - 11:00) &lt; 2</td>
<td>OK</td>
</tr>
<tr>
<td>12:59 &gt; 07:00</td>
<td>OK</td>
</tr>
</tbody>
</table>
</div>
<p>So no problem even though there's been a three hour gap instead of 10 minutes and even though the block has a timestamp that I think is nearly two hours in the future!</p>
<p>Note that these particular rules are not broken if there is a huge (e.g. 50 year) gap between blocks. In theory everything would continue (though it seems likely there would be other issues preventing this)</p>

CC BY-SA 4.0
2021-07-23T11:12:04.097Z
Fair enough, miners aren't restricted to putting in a certain time
arshbot
CC BY-SA 4.0
2021-07-23T14:12:31.460Z
@arshbot That's true, but not relevant I think. Even if the timestamps in blocks are always exactly equal to the time the block is produced, there is no problem.
Pieter Wuille
CC BY-SA 4.0
2021-07-23T11:06:07.310Z
2021-07-23T11:34:08.990Z
2021-07-23T11:34:08.990Z
RedGrittyBrick
<p><a href="https://developer.bitcoin.org/reference/block_chain.html" rel="nofollow noreferrer">According to bitcoin.org</a>, full nodes have a strict requirement on the deviation of time within certain boundaries.</p>
<blockquote>
<p>The block time is a Unix epoch time when the miner started hashing the header (according to the miner). Must be strictly greater than the median time of the previous 11 blocks. Full nodes will not accept blocks with headers more than two hours in the future according to their clock.</p>
</blockquote>
<p>However, if given a certain circumstance, it appears the blockchain is at risk of rejecting all blocks due to conflicting validation parameters.</p>
<p>For example, in the instance of a severe difficulty drop. Difficulty in bitcoin is revaluated every
<a href="https://en.bitcoin.it/wiki/Difficulty" rel="nofollow noreferrer">2016 blocks</a>. If the difficulty drops drastically enough, it could be hours or days until the next valid block is found since the network is operating with reduced mining capacity at a difficulty level intended for much greater. If the next block is mined more than two hours after the current block, would this not stall the blockchain? What would happen in this given scenario?</p>
<p>How strict are the time validation rules?</p>

<validation><block-header><timestamp><difficulty-retargetting><time>
How strict are the Unix Epoch time validation rules?
arshbot
# How strict are the Unix Epoch time validation rules?

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

[According to bitcoin.org](https://developer.bitcoin.org/reference/block_chain.html), full nodes have a strict requirement on the deviation of time within certain boundaries.

> The block time is a Unix epoch time when the miner started hashing the header (according to the miner). Must be strictly greater than the median time of the previous 11 blocks. Full nodes will not accept blocks with headers more than two hours in the future according to their clock.

However, if given a certain circumstance, it appears the blockchain is at risk of rejecting all blocks due to conflicting validation parameters.

For example, in the instance of a severe difficulty drop. Difficulty in bitcoin is revaluated every
[2016 blocks](https://en.bitcoin.it/wiki/Difficulty). If the difficulty drops drastically enough, it could be hours or days until the next valid block is found since the network is operating with reduced mining capacity at a difficulty level intended for much greater. If the next block is mined more than two hours after the current block, would this not stall the blockchain? What would happen in this given scenario?

How strict are the time validation rules?

**Tags:** validation, block-header, timestamp, difficulty-retargetting, time


---

## 2 answers

### Answer by username_2 on 2021-07-23. Score: 8 | Accepted answer

> How strict are the time validation rules?

Very.

> If the next block is mined more than 2 hours after the current block, would this not stall the blockchain?

No.

It doesn't break the rule *"Full nodes will not accept blocks with headers more than two hours in the future **according to their clock**."*

Nor does it break the rule *"Must be strictly **greater than** the median time of the previous 11 blocks."*

---

The above should be clear I hope, but in case it isn't, lets make an example:

| Event | Time |
| --- | --- |
| Last block mined | 08:00 |
| Median time of last 11 blocks | 07:00 |
| Current time on my clock | 11:00 |
| Time on block arriving now | 12:59 |

| Rule | Result |
| --- | --- |
| (12:59 - 11:00) < 2 | OK |
| 12:59 > 07:00 | OK |

So no problem even though there's been a three hour gap instead of 10 minutes and even though the block has a timestamp that I think is nearly two hours in the future!

Note that these particular rules are not broken if there is a huge (e.g. 50 year) gap between blocks. In theory everything would continue (though it seems likely there would be other issues preventing this)

> **Comments:**
> **username_0**: Fair enough, miners aren't restricted to putting in a certain time  
> **username_3**: @username_0 That's true, but not relevant I think. Even if the timestamps in blocks are always exactly equal to the time the block is produced, there is no problem.  

---

### Answer by username_1 on 2021-07-23. Score: 7

I think you have a misconception about what this clause means:

> Full nodes will not accept blocks with headers more than two hours in the future according to their clock.

You appear to be interpreting this as, if a new block is more than two hours later than the previous block, then do not accept it. That is incorrect. This clause is not about gaps in time between blocks.

The actual meaning of this clause is that, if a new block says it's literally from the future, from a time that the universe has not yet reached, then do not accept it. This clause is about preventing manipulation of the blockchain via falsified timestamps.

This comparison is between the new block's timestamp and your clock, not the new block's timestamp and the previous block's timestamp.


---

