<p>I consider the &quot;max two hours in the future rule&quot; to be an essential network rule of the Bitcoin network; without it, the system would be woefully insecure. It is not a mere policy rule, but it is also not - and cannot be - a consensus rule as explained in <a href="https://bitcoin.stackexchange.com/a/121249/208">my answer</a> to your other question.</p>
<p>But many other aspects of a Bitcoin node's protocol implementation are not consensus rules. For example, if validating and relaying blocks is so slow that it takes over 10 minutes, the network would fail to converge to a single chain, because miners would never be able to see each other's blocks in time. I think of the max block timestamp rule as something in this category.</p>
<p>The fact that Bitcoin Core software &lt; 27.0 uses network-adjusted time to decide what the &quot;local clock&quot; is that block timestamps are compared against, is as far as a local Bitcoin core policy rule. That policy was changed and all bitcoin core software &gt;= 27.0 now does not use network-adjusted time to validate block timestamps.</p>
<p>So to answer your questions:</p>
<blockquote>
<ol>
<li>Have I correctly understood the way network-adjusted time is calculated? Is the &quot;+2h rule&quot; considered in relation to it rather than the local time (UTC timestamp) of the node?</li>
</ol>
</blockquote>
<p>As of Bitcoin Core 26.0 yes, the network-adjusted time is computed as the local clock plus the median of the peers' clock differences with our clock. That network-adjusted time was what the &quot;max two hours in the future&quot; was comparing against.</p>
<blockquote>
<ol start="2">
<li>Is a deviation of 70 or 90 minutes allowed between network-adjusted time and the local time of the node? I have read different information. Here, they say it's 70, and here, they say it's 90 minutes.</li>
</ol>
</blockquote>
<p>As of Bitcoin core 26.0, yes it's <a href="https://github.com/bitcoin/bitcoin/blob/v26.0/src/timedata.h#L16" rel="nofollow noreferrer">70 minute</a>s (has been for as long as I'm aware the rule has existed). Note that this value can be overridden with the <code>-maxtimeadjustment</code> command-line flag (or the equivalent config file setting).</p>
<blockquote>
<ol start="3">
<li>Does this mean that if I implement my own node, I only need to implement the second rule regarding consensus, and my node is entirely correct, even though it would be good to also implement the +2h rule since most full nodes run Bitcoin Core, so to always be fully synchronized with the majority of the network?</li>
</ol>
</blockquote>
<p>I guess that depends on your definition of &quot;correct&quot;. If your goal is to write software that can decide if a block is valid or invalid according to the consensus rules, then this rule is irrelevant.</p>

CC BY-SA 4.0
2024-01-01T22:39:35.823Z
Thanks, just one question. For this last (3rd question), could there be any problem if I put +1h or +3 in my node implementation instead of +2h? I assume that in reality in most cases no, since miners will always put a timestamp around the current timestamp because they want the block to be "generally" accepted by the entire network, but could a problem arise in some cases? For example, when the timestamp in the block is +2.5h, which I will accept when I am +3h, while the Bitcoin core nodes will not, or when its at +1.5h, which I will not accept for +1h, and the Bitcoin core nodes will?
LeaBit
CC BY-SA 4.0
2024-01-01T22:41:24.250Z
I don't have more to say about that than the last sentence in my answer already says: it likely doesn't matter that it isn't exactly the same rule.
Pieter Wuille
CC BY-SA 4.0
2024-01-01T22:45:56.143Z
Okay, thanks, all clear
LeaBit
CC BY-SA 4.0
2024-01-01T22:25:11.873Z
2024-12-04T18:07:51.610Z
2024-12-04T18:07:51.610Z
Pieter Wuille
<p>In recent times, I have read many articles and questions/answers on bitcoin.stackexchange related to the timestamp, but I still have problems understanding certain things. They are related to the understanding of certain aspects of the &quot;+2h rule&quot; in the context of block acceptance, so I have listed them below.</p>
<p>Firstly, as I understand it, a block will be accepted if its timestamp is up to 2 hours greater than the current network-adjusted time calculated by the given node.</p>
<p>I found some answers related to network-adjusted time, but I'm not sure if I understood it correctly.</p>
<p>As I understand each node calculates its network-adjusted time as follows: Upon initial connection to peers, the node receives UTC timestamps from all peers in the version message. It calculates the difference between its current local (system) UTC timestamp and the received UTC timestamp from the peer. These differences are sorted, and the median is found. <strong>The network-adjusted time is obtained by adding the current local time (UTC timestamp) of the node and the calculated median.</strong> In an ideal world (a completely synchronized network), network-adjusted time and the local time of the node would be equivalent since all differences would be 0 and therefore the median. Also, if the difference between the current system time (UTC timestamp) of the node and the calculated network-adjusted time (UTC timestamp) is more than 70/90 minutes, the network-adjusted time is set to the node's given system time (UTC timestamp). Thus, when a new block arrives, if the block timestamp is within the range of the node local timestamp + previously calculated median (local timestamp + median = network-adjusted time of the node) + 2 hours, the block is accepted by that node (assuming that the other rules are satisfied).</p>
<ol>
<li>Have I correctly understood the way network-adjusted time is calculated? Is the &quot;+2h rule&quot; considered in relation to it rather than the local time (UTC timestamp) of the node?</li>
</ol>
<p><em>Pieter Wuille</em> <a href="https://bitcoin.stackexchange.com/a/119680/145749">here</a> mentioned local clock instead of network-adjusted one. Cite:</p>
<blockquote>
<p>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).</p>
</blockquote>
<ol start="2">
<li>Is a deviation of 70 or 90 minutes allowed between network-adjusted time and the local time of the node? I have read different information. <a href="https://bitcoin.stackexchange.com/a/20490">Here</a>, they say it's 70, and <a href="https://bitcoin.stackexchange.com/a/99333">here</a>, they say it's 90 minutes.</li>
</ol>
<p>From what I understand so far, <strong>the &quot;+2h rule&quot; is NOT part of the consensus but solely represents the acceptance policy of the Bitcoin Core implementation of the Bitcoin full node</strong>. The consensus rule is only that the block timestamp must be greater than the median timestamp of the last 11 blocks.</p>
<ol start="3">
<li>Does this mean that if I implement my own node, I only need to implement the second rule regarding consensus, and my node is entirely correct, even though it would be good to also implement the +2h rule since most full nodes run Bitcoin Core, so to always be fully synchronized with the majority of the network?</li>
</ol>

<timestamp>
How exactly is the timestamp calculated for the +2h acceptance rule and do I have to implement it in my Bitcoin node for the node to still be valid?
LeaBit
# How exactly is the timestamp calculated for the +2h acceptance rule and do I have to implement it in my Bitcoin node for the node to still be valid?

(Asked by: username_0 on 2024-01-01)

In recent times, I have read many articles and questions/answers on bitcoin.stackexchange related to the timestamp, but I still have problems understanding certain things. They are related to the understanding of certain aspects of the "+2h rule" in the context of block acceptance, so I have listed them below.

Firstly, as I understand it, a block will be accepted if its timestamp is up to 2 hours greater than the current network-adjusted time calculated by the given node.

I found some answers related to network-adjusted time, but I'm not sure if I understood it correctly.

As I understand each node calculates its network-adjusted time as follows: Upon initial connection to peers, the node receives UTC timestamps from all peers in the version message. It calculates the difference between its current local (system) UTC timestamp and the received UTC timestamp from the peer. These differences are sorted, and the median is found. **The network-adjusted time is obtained by adding the current local time (UTC timestamp) of the node and the calculated median.** In an ideal world (a completely synchronized network), network-adjusted time and the local time of the node would be equivalent since all differences would be 0 and therefore the median. Also, if the difference between the current system time (UTC timestamp) of the node and the calculated network-adjusted time (UTC timestamp) is more than 70/90 minutes, the network-adjusted time is set to the node's given system time (UTC timestamp). Thus, when a new block arrives, if the block timestamp is within the range of the node local timestamp + previously calculated median (local timestamp + median = network-adjusted time of the node) + 2 hours, the block is accepted by that node (assuming that the other rules are satisfied).

1. Have I correctly understood the way network-adjusted time is calculated? Is the "+2h rule" considered in relation to it rather than the local time (UTC timestamp) of the node?

*username_1 username_1* [here](https://bitcoin.stackexchange.com/a/119680/145749) mentioned local clock instead of network-adjusted one. Cite:

> 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).

2. Is a deviation of 70 or 90 minutes allowed between network-adjusted time and the local time of the node? I have read different information. [Here](https://bitcoin.stackexchange.com/a/20490), they say it's 70, and [here](https://bitcoin.stackexchange.com/a/99333), they say it's 90 minutes.

From what I understand so far, **the "+2h rule" is NOT part of the consensus but solely represents the acceptance policy of the Bitcoin Core implementation of the Bitcoin full node**. The consensus rule is only that the block timestamp must be greater than the median timestamp of the last 11 blocks.

3. Does this mean that if I implement my own node, I only need to implement the second rule regarding consensus, and my node is entirely correct, even though it would be good to also implement the +2h rule since most full nodes run Bitcoin Core, so to always be fully synchronized with the majority of the network?

**Tags:** timestamp


---

## 1 answers

### Answer by username_1 on 2024-01-01. Score: 4 | Accepted answer

I consider the "max two hours in the future rule" to be an essential network rule of the Bitcoin network; without it, the system would be woefully insecure. It is not a mere policy rule, but it is also not - and cannot be - a consensus rule as explained in [my answer](https://bitcoin.stackexchange.com/a/121249/208) to your other question.

But many other aspects of a Bitcoin node's protocol implementation are not consensus rules. For example, if validating and relaying blocks is so slow that it takes over 10 minutes, the network would fail to converge to a single chain, because miners would never be able to see each other's blocks in time. I think of the max block timestamp rule as something in this category.

The fact that Bitcoin Core software < 27.0 uses network-adjusted time to decide what the "local clock" is that block timestamps are compared against, is as far as a local Bitcoin core policy rule. That policy was changed and all bitcoin core software >= 27.0 now does not use network-adjusted time to validate block timestamps.

So to answer your questions:

> 1. Have I correctly understood the way network-adjusted time is calculated? Is the "+2h rule" considered in relation to it rather than the local time (UTC timestamp) of the node?

As of Bitcoin Core 26.0 yes, the network-adjusted time is computed as the local clock plus the median of the peers' clock differences with our clock. That network-adjusted time was what the "max two hours in the future" was comparing against.

> 2. Is a deviation of 70 or 90 minutes allowed between network-adjusted time and the local time of the node? I have read different information. Here, they say it's 70, and here, they say it's 90 minutes.

As of Bitcoin core 26.0, yes it's [70 minute](https://github.com/bitcoin/bitcoin/blob/v26.0/src/timedata.h#L16)s (has been for as long as I'm aware the rule has existed). Note that this value can be overridden with the `-maxtimeadjustment` command-line flag (or the equivalent config file setting).

> 3. Does this mean that if I implement my own node, I only need to implement the second rule regarding consensus, and my node is entirely correct, even though it would be good to also implement the +2h rule since most full nodes run Bitcoin Core, so to always be fully synchronized with the majority of the network?

I guess that depends on your definition of "correct". If your goal is to write software that can decide if a block is valid or invalid according to the consensus rules, then this rule is irrelevant.

> **Comments:**
> **username_0**: Thanks, just one question. For this last (3rd question), could there be any problem if I put +1h or +3 in my node implementation instead of +2h? I assume that in reality in most cases no, since miners will always put a timestamp around the current timestamp because they want the block to be "generally" accepted by the entire network, but could a problem arise in some cases? For example, when the timestamp in the block is +2.5h, which I will accept when I am +3h, while the Bitcoin core nodes will not, or when its at +1.5h, which I will not accept for +1h, and the Bitcoin core nodes will?  
> **username_1**: I don't have more to say about that than the last sentence in my answer already says: it likely doesn't matter that it isn't exactly the same rule.  
> **username_0**: Okay, thanks, all clear  

---

