<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. &quot;Network-adjusted time&quot; 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>
<ul>
<li><a href="http://en.bitcoin.it/wiki/Block_timestamp" rel="nofollow noreferrer">http://en.bitcoin.it/wiki/Block_timestamp</a></li>
</ul>
<p>So, if you want your block accepted by other nodes, you won't mess with anything close to deviating from the current time by two hours.</p>
<p>But the protocol doesn't care how many blocks are being mined, it only will use those durations of the past 2,016 blocks to adjust difficulty when that periodic event occurs.</p>

CC BY-SA 3.0
2014-12-19T12:19:12.070Z
@user5107, downloaded blocks follow the same validation rules, but the greater than the median time stamp of the past 11 blocks is relative. So when validating block 100, you look at time stamps of blocks 89-99 to check the median.
morsecoder
CC BY-SA 3.0
2012-10-17T06:13:51.517Z
2012-10-17T06:13:51.517Z
2020-06-16T11:10:03.350Z
Stephen Gornick
<p>The major factor for pools is that if they do that, their blocks might get rejected by the network and the honest nodes. That would mean not only loss of profits for the pool and the miners, but also a loss of confidence. Both of those factors might result in the pool losing its miners and hashpower.</p>

CC BY-SA 3.0
2012-10-17T07:32:12.747Z
Yep that sounds right. Interestingly, I think non-mining nodes could start accepting blocks with invalid timestamps, and not been penalized while +51% of miners are honest (the longest blockchain will consist of valid blocks). Then when some threshold of non-mining-nodes-accepting-invalid-timestamps is reached, +51% miners could start generating invalid timestamps. Far fetched I know, but interesting to think about. At the end of the day, I guess such an attack would undermine confidence in bitcoin, and thus the benefit of such an attack.
BitPiggy
CC BY-SA 3.0
2012-10-17T09:32:12.020Z
51% or more of miners might collude to change timestamps, but my client still won't accept their blocks.  So no, that isn't something the miners have control over.
Stephen Gornick
CC BY-SA 3.0
2012-10-17T18:15:41.757Z
Miners collectively have a vested interest in keeping Bitcoins worth as much as possible. So the idea that miners would conspire to reduce the value of Bitcoins doesn't seem very likely to me.
David Schwartz
CC BY-SA 3.0
2012-10-17T06:15:59.737Z
2012-10-17T06:15:59.737Z
ThePiachu
<p>From what I understand, the difficulty required by the proof-of-work in bitcoin is a function of block history, specifically the average time between last ~2000 blocks, with the intention that its hovers around the 10 minute mark. </p>

<p>The function relies on the timestamp of when the block was created. It occurs to me that when nodes are calculating blocks, they have an incentive to overstate the timestamp (because the difficulty would then be recalculated to allow for quicker mining of new blocks, which would lead to a higher rate at which that node receives rewarded bitcoins).</p>

<p>The protocol states nodes should reject blocks that have timestamps that look invalid (e.g. too far into the future), but again it relies on nodes being honest. </p>

<p>In short, what is the incentive for miners to not overstate timestamps? Am I right in thinking that if a majority of miners/nodes colluded in overstating + not rejecting invalid timestamps, then the entire bitcoin network would start generating bitcoins faster?</p>

<p>Note: It occurs to me that as the total pool of bitcoins increases + rate of reward halves every 4 years, this 'speeding up' of the bitcoin block generation has less and less impact. </p>

<attack><timestamp><block-interval>
What stops miners/nodes lying about what time a block was mined?
BitPiggy
# What stops miners/nodes lying about what time a block was mined?

(Asked by: username_0 on 2012-10-17)

From what I understand, the difficulty required by the proof-of-work in bitcoin is a function of block history, specifically the average time between last ~2000 blocks, with the intention that its hovers around the 10 minute mark.

The function relies on the timestamp of when the block was created. It occurs to me that when nodes are calculating blocks, they have an incentive to overstate the timestamp (because the difficulty would then be recalculated to allow for quicker mining of new blocks, which would lead to a higher rate at which that node receives rewarded bitcoins).

The protocol states nodes should reject blocks that have timestamps that look invalid (e.g. too far into the future), but again it relies on nodes being honest.

In short, what is the incentive for miners to not overstate timestamps? Am I right in thinking that if a majority of miners/nodes colluded in overstating + not rejecting invalid timestamps, then the entire bitcoin network would start generating bitcoins faster?

Note: It occurs to me that as the total pool of bitcoins increases + rate of reward halves every 4 years, this 'speeding up' of the bitcoin block generation has less and less impact.

**Tags:** attack, timestamp, block-interval


---

## 2 answers

### Answer by username_1 on 2012-10-17. Score: 3

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

* <http://en.bitcoin.it/wiki/Block_timestamp>

So, if you want your block accepted by other nodes, you won't mess with anything close to deviating from the current time by two hours.

But the protocol doesn't care how many blocks are being mined, it only will use those durations of the past 2,016 blocks to adjust difficulty when that periodic event occurs.

> **Comments:**
> **username_2**: @user5107, downloaded blocks follow the same validation rules, but the greater than the median time stamp of the past 11 blocks is relative. So when validating block 100, you look at time stamps of blocks 89-99 to check the median.  

---

### Answer by username_3 on 2012-10-17. Score: 3

The major factor for pools is that if they do that, their blocks might get rejected by the network and the honest nodes. That would mean not only loss of profits for the pool and the miners, but also a loss of confidence. Both of those factors might result in the pool losing its miners and hashpower.

> **Comments:**
> **username_0**: Yep that sounds right. Interestingly, I think non-mining nodes could start accepting blocks with invalid timestamps, and not been penalized while +51% of miners are honest (the longest blockchain will consist of valid blocks). Then when some threshold of non-mining-nodes-accepting-invalid-timestamps is reached, +51% miners could start generating invalid timestamps. Far fetched I know, but interesting to think about. At the end of the day, I guess such an attack would undermine confidence in bitcoin, and thus the benefit of such an attack.  
> **username_1**: 51% or more of miners might collude to change timestamps, but my client still won't accept their blocks.  So no, that isn't something the miners have control over.  
> **username_4**: Miners collectively have a vested interest in keeping Bitcoins worth as much as possible. So the idea that miners would conspire to reduce the value of Bitcoins doesn't seem very likely to me.  

---

