<p>No. The 2-hours rule is checking if the timestamp of a block is not more than 2 hours <em>in the future</em>. A valid timestamp for a given tip cannot become invalid as time passes.</p>
<p>I think you are confusing the 2-hours rule with the MTP rule.</p>
<p>From the example you added in your edit, block 104 is still valid according to the MTP rule since it's based on the timestamps of the previous blocks. And it is still valid according to the 2-hours rule since it's compared to the node's clock <em>at the time of reception</em>.</p>

CC BY-SA 4.0
2023-09-16T12:20:29.837Z
My question is about blocks being mined now -- but such that they would be invalid according to the chain. I'll improve the question.
fiatjaf
CC BY-SA 4.0
2023-09-16T12:26:19.257Z
@fiatjaf I think you're still confusing the two rules, see my answer. The 2-hour rule is w.r.t. the verifier's local clock, not w.r.t. to other blocks' timestamps.
Pieter Wuille
CC BY-SA 4.0
2023-09-16T12:26:30.183Z
Reading your edit, i still think you are confusing the MTP and 2-hours rule. I'll edit my answer to use your example.
Antoine Poinsot
CC BY-SA 4.0
2023-09-16T12:27:32.120Z
Yes, that was it. I didn't realize the 2-hours rule was according to the current time of the validator.
fiatjaf
CC BY-SA 4.0
2023-09-16T12:17:50.867Z
2023-09-16T12:28:57.363Z
2023-09-16T12:28:57.363Z
Antoine Poinsot
<p>My understanding of the 2-hour rule was incorrect. I thought the 2 hours was in relation to the timestamp of the previous block, but it <strong>is in relation to the timestamp of the local clock of whoever is verying the block at any time</strong>, so miners don't have to fake timestamps at all, they can just use their current local time and it should be correct if their clocks are correct.</p>

CC BY-SA 4.0
2023-09-16T12:46:58.637Z
If we answered your question, could you mark one of the answers as accepted? (Probably Pieter's, since it's more detailed.)
Antoine Poinsot
CC BY-SA 4.0
2023-09-16T12:30:19.187Z
2023-09-16T12:30:19.187Z
fiatjaf
<p>No.</p>
<p>There are two restrictions on the timestamp of blocks:</p>
<ul>
<li>A consensus rule that the timestamp of a block must be strictly larger than the median timestamp of its 11 predecessors (parent, grandparent, great-grandparent, ...). This is a property of just the block itself - it's either valid or not, independent of when validation happens.</li>
<li>An acceptance rule that the timestamp cannot be more than 2 hours in future (compared to the verifier's local clock). Since this depends on the local clock, this property can change over time (and once enough time passes, a block formerly found to be invalid by this rule may become acceptable).</li>
</ul>
<p>Neither of these rules tightens when a reorg happens. The first rule widens (as the reorged out blocks disappear from the median timestamp calculation), and the second rule is unaffected (it continues to allow more and more as time passes).</p>

CC BY-SA 4.0
2023-09-16T12:26:36.017Z
Either my question was unclear or I don't understand this answer.

EDIT: I now understand the answer.
fiatjaf
CC BY-SA 4.0
2023-09-16T12:20:27.117Z
2023-09-16T12:20:27.117Z
Pieter Wuille
<p>Imagine there are a series of reorgs happening because of maybe some fee sniping event or something else, doesn't matter.</p>
<p>If that happens for over than 2 hours, then new blocks will not be able to mined with their current timestamp anymore, otherwise they wouldn't be accepted? In such a case will the chain have to proceed with invalid block times forever after the reorgs end?</p>
<h3>Example:</h3>
<pre><code>block 100: 00h00
block 101: 00h10
block 102: 00h20
block 103: 00h30
  :: reorgs happen for 3 hours, many blocks discarded ::
block 104: 03h30 # invalid because of the timestamp.
</code></pre>
<p>I think the question is if whoever is mining the block 104 at the end will have to <em>fake</em> a timestamp in the past (like <code>01h30</code>) even though  its actual current time is <code>03h30</code>.</p>

CC BY-SA 4.0
2023-09-28T15:33:26.843Z
By the way, if this issue existed, we would have encountered it on block 1: https://bitcoin.stackexchange.com/a/77964/5406 ;)
Murch
<timestamp><chain-reorganization>
Would a series of reorgs cause Bitcoin to break because of the 2-hour block time difference restriction?
fiatjaf
# Would a series of reorgs cause Bitcoin to break because of the 2-hour block time difference restriction?

(Asked by: username_0 on 2023-09-16)

Imagine there are a series of reorgs happening because of maybe some fee sniping event or something else, doesn't matter.

If that happens for over than 2 hours, then new blocks will not be able to mined with their current timestamp anymore, otherwise they wouldn't be accepted? In such a case will the chain have to proceed with invalid block times forever after the reorgs end?

### Example:

```
block 100: 00h00
block 101: 00h10
block 102: 00h20
block 103: 00h30
  :: reorgs happen for 3 hours, many blocks discarded ::
block 104: 03h30 # invalid because of the timestamp.

```

I think the question is if whoever is mining the block 104 at the end will have to *fake* a timestamp in the past (like `01h30`) even though its actual current time is `03h30`.

**Tags:** timestamp, chain-reorganization

> **Comments:**
> **username_1**: By the way, if this issue existed, we would have encountered it on block 1: https://bitcoin.stackexchange.com/a/77964/5406 ;)  

---

## 3 answers

### Answer by username_3 on 2023-09-16. Score: 8 | Accepted answer

No.

There are two restrictions on the timestamp of blocks:

* A consensus rule that the timestamp of a block must be strictly larger than the median timestamp of its 11 predecessors (parent, grandparent, great-grandparent, ...). This is a property of just the block itself - it's either valid or not, independent of when validation happens.
* An acceptance rule that the timestamp cannot be more than 2 hours in future (compared to the verifier's local clock). Since this depends on the local clock, this property can change over time (and once enough time passes, a block formerly found to be invalid by this rule may become acceptable).

Neither of these rules tightens when a reorg happens. The first rule widens (as the reorged out blocks disappear from the median timestamp calculation), and the second rule is unaffected (it continues to allow more and more as time passes).

> **Comments:**
> **username_0**: Either my question was unclear or I don't understand this answer.  EDIT: I now understand the answer.  

---

### Answer by username_2 on 2023-09-16. Score: 4

No. The 2-hours rule is checking if the timestamp of a block is not more than 2 hours *in the future*. A valid timestamp for a given tip cannot become invalid as time passes.

I think you are confusing the 2-hours rule with the MTP rule.

From the example you added in your edit, block 104 is still valid according to the MTP rule since it's based on the timestamps of the previous blocks. And it is still valid according to the 2-hours rule since it's compared to the node's clock *at the time of reception*.

> **Comments:**
> **username_0**: My question is about blocks being mined now -- but such that they would be invalid according to the chain. I'll improve the question.  
> **username_3**: @username_0 I think you're still confusing the two rules, see my answer. The 2-hour rule is w.r.t. the verifier's local clock, not w.r.t. to other blocks' timestamps.  
> **username_2**: Reading your edit, i still think you are confusing the MTP and 2-hours rule. I'll edit my answer to use your example.  
> **username_0**: Yes, that was it. I didn't realize the 2-hours rule was according to the current time of the validator.  

---

### Answer by username_0 on 2023-09-16. Score: 2

My understanding of the 2-hour rule was incorrect. I thought the 2 hours was in relation to the timestamp of the previous block, but it **is in relation to the timestamp of the local clock of whoever is verying the block at any time**, so miners don't have to fake timestamps at all, they can just use their current local time and it should be correct if their clocks are correct.

> **Comments:**
> **username_2**: If we answered your question, could you mark one of the answers as accepted? (Probably username_3's, since it's more detailed.)  

---

