<p>The root cause of this is that without a central authority, it's impossible to know for sure what the current time is.</p>

<p>The protocol rejects blocks with a timestamp earlier than the median of the timestamps from the previous 11 blocks or later than 2 hours after the current network time.  Any other timestamp is acceptable.  Note that 'network time' may differ from the actual time, since the bitcoin network attempts to correct for incorrect clock settings by taking the median of the time reported by all connected peers as the network time.</p>

<p>You can read about an attack that this makes possible <a href="http://culubas.blogspot.ca/2011/05/timejacking-bitcoin_802.html">here</a>:</p>

<blockquote>
  <p>By announcing inaccurate timestamps when connecting to a node, an
  attacker can alter a node's network time counter and deceive it into
  accepting an alternate block chain. This could significantly increase
  the chances of a successful double-spend, drain a node's computational
  resources, or simply slow down the transaction confirmation rate.</p>
</blockquote>

CC BY-SA 3.0
2017-12-29T10:34:28.067Z
I realize this is a very old post but I would ask if this vulnerability still exists?
Jeff
CC BY-SA 3.0
2017-12-31T01:22:40.033Z
I'm not sure, but I see no reason why it shouldn't. The rules didn't change.
Chris Moore
CC BY-SA 3.0
2017-12-31T02:35:11.677Z
If it is still a vulnerability I am guessing there is a way to protect against it or it is not a serious one -- BTC has survived many assaults since 2012.
Jeff
CC BY-SA 4.0
2020-05-30T16:36:39.617Z
@Jeff Seems like it is still a problem, and not easy enough to fix in a decade. For proposals, see e.g. [\(Short Paper\) Towards More Reliable Bitcoin Timestamps \- IEEE Conference Publication](https://arxiv.org/abs/1803.09028) or  [Achieving reliable timestamp in the bitcoin platform \| SpringerLink](https://link.springer.com/article/10.1007/s12083-020-00905-6)
nealmcb
CC BY-SA 3.0
2012-05-21T01:18:18.407Z
2012-05-21T01:18:18.407Z
Chris Moore
<p>To add a bit to the other answers: Imagine if the protocol required that timestamps increase. Now imagine somebody mines a block with a timestamp a minute in the future as far as you can tell. What do you do? If you try to mine blocks with the timestamp you currently believe is correct, your blocks will get rejected (since they'd have a timestamp earlier than the last accepted block).</p>

<p>Due to the requirement that the network easily agree on whether a block is valid or not, the protocol can't require highly-accurate timestamps as a condition of accepting a block as valid. As a result, requiring monotonic timestamps would likely make things worse rather than better.</p>

CC BY-SA 3.0
2011-09-13T19:49:03.123Z
2011-09-13T19:49:03.123Z
David Schwartz
<p>There is no requirement that blocks have a timestamp after the previous block. The only requirement is that the timestamp is greater than the median timestamp of the last 11 blocks. So this means that a block can have a lower timestamp than its parent, within a certain bound.</p>

<p>This happens because miners do not have perfectly in sync clocks. There can be slight differences in their internal clocks that make them off by a few seconds. If a miner gets really lucky and finds a block soon after another one, because of the clock differences, it is possible that his clock is still behind the timestamp of the parent block. That is probably what happened here.</p>

CC BY-SA 4.0
2020-03-08T18:31:48.297Z
2020-03-08T18:31:48.297Z
Ava Chow
<p>At least one mining pool <a href="https://bitcointalk.org/index.php?topic=23768.msg460150#msg460150">deliberately</a> sets timestamps 6 minutes in the future and <a href="http://blockexplorer.com/b/145045">Block 145045</a> appears to be from Eligius (the generation transaction is split into multiple addresses).</p>

CC BY-SA 3.0
2016-09-22T21:14:58.657Z
why do they do that? do they still do it?
smatthewenglish
CC BY-SA 3.0
2011-09-12T17:49:00.553Z
2011-09-12T17:59:37.713Z
2011-09-12T17:59:37.713Z
jarpiain
<p>I believe the timestamp is based off of the machine hosting the bitcoin client that submitted the block, and variance is allowed as not everyone has their computer time synched properly.</p>

CC BY-SA 3.0
2016-09-22T16:47:45.183Z
Do you know where is the code that performs this function?
smatthewenglish
CC BY-SA 3.0
2011-09-12T17:25:18.097Z
2011-09-12T17:25:18.097Z
tysat
<p>There is a fair amount of leeway in the block timestamp. The timestamp for block N must be greater than the median network time, which is calculated as the median of the past 11 blocks, and also less than the <code>network time + 2 hours</code>, where network time is calculated based on the node's system time, as well as the median time reported by the node's peers.</p>

CC BY-SA 4.0
2020-03-08T18:22:16.003Z
2020-03-08T18:22:16.003Z
Raghav Sood
<p>Block timestamps are not very accurate and are allowed to be up to several hours off. It is difficult for a decentralized network to come to an agreement on an official time.</p>

<p>Reasons that it might be inaccurate are different system times, lag, and also miners often change the time by small amounts once they have tried all possible nonces. This allows them to get new hashes using the old nonces.</p>

<p><a href="https://en.bitcoin.it/wiki/Block_timestamp" rel="nofollow">Here are the rules of what timestamps are allowed.</a></p>

CC BY-SA 3.0
2014-02-02T02:11:03.440Z
2014-02-02T02:11:03.440Z
Buge
<p>A block's timestamp should only be treated as an <strong>approximate</strong> time that the block was mined. There is no way to enforce a miner to include <em>'the actual time'</em>, because it is impossible for the network to ascertain the truth of this. So instead, the network imposes a rule that the timestamp must adhere the following rules in order to be considered valid: </p>

<p>(The info below is copy/pasted from <a href="https://bitcoin.org/en/developer-reference#block-headers" rel="nofollow noreferrer">the Bitcoin.org developer reference</a>)</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>Thus, it is possible for a block at <code>height N</code> to have a timestamp that comes <em>after</em> the the timestamp of the block at <code>height N+1</code>, as long as it follows these rules otherwise. </p>

CC BY-SA 4.0
2019-05-21T18:19:20.523Z
"Full nodes will not accept blocks with headers more than two hours in the future according to their clock." that is not entirely correct AFAIK. It should not be more than two hours from the 'network adjusted time'. When you connect to a node, the node sends a time stamp and you store the difference between the time returned to you by the node and your current local clock. Then after connecting to all nodes you calculate the median deviation between your clock and the network clock. At any point you calculate 'network adjusted time' by adding your local time to the median dev noted earlier
Ugam Kamat
CC BY-SA 4.0
2019-05-21T00:54:43.183Z
2019-05-21T00:54:43.183Z
chytrik
<p>From <a href="https://en.bitcoin.it/wiki/Block_timestamp">the wiki</a>:</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. "Network-adjusted time" is the median of the
  timestamps returned by all nodes connected to you.</p>
  
  <p>Whenever a node connects to another node, it gets a UTC timestamp from
  it, and stores its offset from node-local UTC. The network-adjusted
  time is then the node-local UTC plus the median offset from all
  connected nodes. Network time is never adjusted more than 70 minutes
  from local system time, however.</p>
</blockquote>

<p>It's not obvious that there aren't any problems with this way of timestamping. See the blog post <a href="http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html">Timejacking &amp; Bitcoin</a> and the discussion about it <a href="https://bitcointalk.org/index.php?topic=10241.0">here</a>.</p>

CC BY-SA 3.0
2016-09-14T14:32:45.490Z
so then the blockchain is more about ordering, and timestampedness only in a more abstract sense is it?
smatthewenglish
CC BY-SA 3.0
2017-04-18T12:42:27.813Z
What do you mean by ****greater than the median timestamp of previous 11 blocks**** ?
jean-mickael nounahon
CC BY-SA 3.0
2011-09-12T17:54:29.227Z
So block producers out of sync by up to an hour or 2 cause no real problems so long as they remain in the minority.
Mocky
CC BY-SA 3.0
2011-09-12T19:59:58.617Z
I added some info on potential problems to the answer.
D.H.
CC BY-SA 3.0
2011-09-12T17:34:12.133Z
2011-09-12T19:59:17.540Z
2011-09-12T19:59:17.540Z
D.H.
<p>The timestamps starting at block 145044 are:</p>

<pre><code>145044: 2011-09-12 15:46:39     
145045: 2011-09-12 16:05:07 
145046: 2011-09-12 16:00:05 // ~5 minutes before prior block
145047: 2011-09-12 15:53:36 // ~7 &amp; ~12 minutes before 2 prior blocks
145048: 2011-09-12 16:04:06 // after 2 prior blocks but still before 145045
</code></pre>

<p>How does this occur?</p>

CC BY-SA 3.0
2016-09-22T21:13:59.637Z
is the notion of time in btc still this fuzzy in 2016? has there been any BIP to make this more strictly ordered?
smatthewenglish
CC BY-SA 4.0
2020-11-05T14:41:37.920Z
@smatthewenglish: If you have a new question, please create another topic: [ask]
Murch
<blockchain><protocol><block-header><timestamp>
Why don't the timestamps in the block chain always increase?
Mocky
# Why don't the timestamps in the block chain always increase?

(Asked by: username_0 on 2011-09-12)

The timestamps starting at block 145044 are:

```
145044: 2011-09-12 15:46:39     
145045: 2011-09-12 16:05:07 
145046: 2011-09-12 16:00:05 // ~5 minutes before prior block
145047: 2011-09-12 15:53:36 // ~7 & ~12 minutes before 2 prior blocks
145048: 2011-09-12 16:04:06 // after 2 prior blocks but still before 145045

```

How does this occur?

**Tags:** blockchain, protocol, block-header, timestamp

> **Comments:**
> **username_1**: is the notion of time in btc still this fuzzy in 2016? has there been any BIP to make this more strictly ordered?  
> **username_2**: @username_1: If you have a new question, please create another topic: [ask]  

---

## 9 answers

### Answer by username_14 on 2011-09-12. Score: 26 | Accepted answer

From [the wiki](https://en.bitcoin.it/wiki/Block_timestamp):

> 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. "Network-adjusted time" is the median of the
> timestamps returned by all nodes connected to you.
>
> Whenever a node connects to another node, it gets a UTC timestamp from
> it, and stores its offset from node-local UTC. The network-adjusted
> time is then the node-local UTC plus the median offset from all
> connected nodes. Network time is never adjusted more than 70 minutes
> from local system time, however.

It's not obvious that there aren't any problems with this way of timestamping. See the blog post [Timejacking & Bitcoin](http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html) and the discussion about it [here](https://bitcointalk.org/index.php?topic=10241.0).

> **Comments:**
> **username_0**: So block producers out of sync by up to an hour or 2 cause no real problems so long as they remain in the minority.  
> **username_14**: I added some info on potential problems to the answer.  
> **username_1**: so then the blockchain is more about ordering, and timestampedness only in a more abstract sense is it?  
> **username_15**: What do you mean by ****greater than the median timestamp of previous 11 blocks**** ?  

---

### Answer by username_3 on 2012-05-21. Score: 19

The root cause of this is that without a central authority, it's impossible to know for sure what the current time is.

The protocol rejects blocks with a timestamp earlier than the median of the timestamps from the previous 11 blocks or later than 2 hours after the current network time. Any other timestamp is acceptable. Note that 'network time' may differ from the actual time, since the bitcoin network attempts to correct for incorrect clock settings by taking the median of the time reported by all connected peers as the network time.

You can read about an attack that this makes possible [here](http://culubas.blogspot.ca/2011/05/timejacking-bitcoin_802.html):

> By announcing inaccurate timestamps when connecting to a node, an
> attacker can alter a node's network time counter and deceive it into
> accepting an alternate block chain. This could significantly increase
> the chances of a successful double-spend, drain a node's computational
> resources, or simply slow down the transaction confirmation rate.

> **Comments:**
> **username_4**: I realize this is a very old post but I would ask if this vulnerability still exists?  
> **username_3**: I'm not sure, but I see no reason why it shouldn't. The rules didn't change.  
> **username_4**: If it is still a vulnerability I am guessing there is a way to protect against it or it is not a serious one -- BTC has survived many assaults since 2012.  
> **username_5**: @username_4 Seems like it is still a problem, and not easy enough to fix in a decade. For proposals, see e.g. [\(Short Paper\) Towards More Reliable Bitcoin Timestamps \- IEEE Conference Publication](https://arxiv.org/abs/1803.09028) or  [Achieving reliable timestamp in the bitcoin platform \| SpringerLink](https://link.springer.com/article/10.1007/s12083-020-00905-6)  

---

### Answer by username_6 on 2011-09-13. Score: 15

To add a bit to the other answers: Imagine if the protocol required that timestamps increase. Now imagine somebody mines a block with a timestamp a minute in the future as far as you can tell. What do you do? If you try to mine blocks with the timestamp you currently believe is correct, your blocks will get rejected (since they'd have a timestamp earlier than the last accepted block).

Due to the requirement that the network easily agree on whether a block is valid or not, the protocol can't require highly-accurate timestamps as a condition of accepting a block as valid. As a result, requiring monotonic timestamps would likely make things worse rather than better.


---

### Answer by username_7 on 2020-03-08. Score: 11

There is no requirement that blocks have a timestamp after the previous block. The only requirement is that the timestamp is greater than the median timestamp of the last 11 blocks. So this means that a block can have a lower timestamp than its parent, within a certain bound.

This happens because miners do not have perfectly in sync clocks. There can be slight differences in their internal clocks that make them off by a few seconds. If a miner gets really lucky and finds a block soon after another one, because of the clock differences, it is possible that his clock is still behind the timestamp of the parent block. That is probably what happened here.


---

### Answer by username_8 on 2011-09-12. Score: 7

At least one mining pool [deliberately](https://bitcointalk.org/index.php?topic=23768.msg460150#msg460150) sets timestamps 6 minutes in the future and [Block 145045](http://blockexplorer.com/b/145045) appears to be from Eligius (the generation transaction is split into multiple addresses).

> **Comments:**
> **username_1**: why do they do that? do they still do it?  

---

### Answer by username_9 on 2011-09-12. Score: 7

I believe the timestamp is based off of the machine hosting the bitcoin client that submitted the block, and variance is allowed as not everyone has their computer time synched properly.

> **Comments:**
> **username_1**: Do you know where is the code that performs this function?  

---

### Answer by username_10 on 2020-03-08. Score: 4

There is a fair amount of leeway in the block timestamp. The timestamp for block N must be greater than the median network time, which is calculated as the median of the past 11 blocks, and also less than the `network time + 2 hours`, where network time is calculated based on the node's system time, as well as the median time reported by the node's peers.


---

### Answer by username_11 on 2014-02-02. Score: 4

Block timestamps are not very accurate and are allowed to be up to several hours off. It is difficult for a decentralized network to come to an agreement on an official time.

Reasons that it might be inaccurate are different system times, lag, and also miners often change the time by small amounts once they have tried all possible nonces. This allows them to get new hashes using the old nonces.

[Here are the rules of what timestamps are allowed.](https://en.bitcoin.it/wiki/Block_timestamp)


---

### Answer by username_12 on 2019-05-21. Score: 1

A block's timestamp should only be treated as an **approximate** time that the block was mined. There is no way to enforce a miner to include *'the actual time'*, because it is impossible for the network to ascertain the truth of this. So instead, the network imposes a rule that the timestamp must adhere the following rules in order to be considered valid:

(The info below is copy/pasted from [the Bitcoin.org developer reference](https://bitcoin.org/en/developer-reference#block-headers))

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

Thus, it is possible for a block at `height N` to have a timestamp that comes *after* the the timestamp of the block at `height N+1`, as long as it follows these rules otherwise.

> **Comments:**
> **username_13**: "Full nodes will not accept blocks with headers more than two hours in the future according to their clock." that is not entirely correct AFAIK. It should not be more than two hours from the 'network adjusted time'. When you connect to a node, the node sends a time stamp and you store the difference between the time returned to you by the node and your current local clock. Then after connecting to all nodes you calculate the median deviation between your clock and the network clock. At any point you calculate 'network adjusted time' by adding your local time to the median dev noted earlier  

---

