<p>I don't ever recall seeing an actual calculation for it, and I strongly suspect the reason is that it is "good enough".</p>

<p>The original, primary use of block timestamps is in difficulty calculations. They now also adjust the time for locktime transactions, but that's a newer addition.</p>

<p>A block's timestamps must:</p>

<ul>
<li>Be greater than the median of the past 11 blocks (11 also seems to be a number chosen because it's good enough)</li>
<li>Within 2 hours of the network adjusted time</li>
</ul>

<p>The network adjusted time is calculated by asking all your peers for their UTC timestamps, and if it's within 70 minutes of your own node, updating a network adjusted time median calculation over all the node times.</p>

<p>This imposes limits on how much a single node or miner can influence the time related parameters. Since difficulty adjustments look at the time between blocks and adjust to bring the mean down or up to 10 minutes, allowing for a very large variance may be counterproductive. 2 hours (to me) seems like a reasonable amount, since even if someone confuses DST time settings <em>and</em> has a bad clock, they would still be off in the range of 1-2 hours, on a reasonable system.</p>

<p>Of course, with ntp and other timekeeping services these days, nodes should be off a lot less. I've never heard of the 2 hour limit being insufficient, or of it being too large and causing issues with difficulty readjustment.</p>

<p>There are several things in the Bitcoin spec that exist because that's the way it was set up in the original implementation, and no pressing reason exists to change it.</p>

CC BY-SA 4.0
2018-07-30T22:24:39.980Z
2018-07-30T22:24:39.980Z
Raghav Sood
<p>Bitcoin wiki says that:</p>
<blockquote>
<p>A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours</p>
</blockquote>
<p>My question is why 2 hours? Why not 1 or 3? Is there any calculation behind it?</p>

CC BY-SA 4.0
2019-09-30T03:20:24.280Z
Possible duplicate of [Why is two hours the maximum acceptable offset for Bitcoin blocks?](https://bitcoin.stackexchange.com/questions/30594/why-is-two-hours-the-maximum-acceptable-offset-for-bitcoin-blocks)
Nate Eldredge
<bitcoin-core><blockchain><block><timestamp><whitepaper>
Where does the 2-hour limit on the timestamp come from?
n0unc3
# Where does the 2-hour limit on the timestamp come from?

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

Bitcoin wiki says that:

> A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours

My question is why 2 hours? Why not 1 or 3? Is there any calculation behind it?

**Tags:** bitcoin-core, blockchain, block, timestamp, whitepaper

> **Comments:**
> **username_1**: Possible duplicate of [Why is two hours the maximum acceptable offset for Bitcoin blocks?](https://bitcoin.stackexchange.com/questions/30594/why-is-two-hours-the-maximum-acceptable-offset-for-bitcoin-blocks)  

---

## 1 answers

### Answer by username_2 on 2018-07-30. Score: 5

I don't ever recall seeing an actual calculation for it, and I strongly suspect the reason is that it is "good enough".

The original, primary use of block timestamps is in difficulty calculations. They now also adjust the time for locktime transactions, but that's a newer addition.

A block's timestamps must:

* Be greater than the median of the past 11 blocks (11 also seems to be a number chosen because it's good enough)
* Within 2 hours of the network adjusted time

The network adjusted time is calculated by asking all your peers for their UTC timestamps, and if it's within 70 minutes of your own node, updating a network adjusted time median calculation over all the node times.

This imposes limits on how much a single node or miner can influence the time related parameters. Since difficulty adjustments look at the time between blocks and adjust to bring the mean down or up to 10 minutes, allowing for a very large variance may be counterproductive. 2 hours (to me) seems like a reasonable amount, since even if someone confuses DST time settings *and* has a bad clock, they would still be off in the range of 1-2 hours, on a reasonable system.

Of course, with ntp and other timekeeping services these days, nodes should be off a lot less. I've never heard of the 2 hour limit being insufficient, or of it being too large and causing issues with difficulty readjustment.

There are several things in the Bitcoin spec that exist because that's the way it was set up in the original implementation, and no pressing reason exists to change it.


---

