<p>One obvious countermeasure is that nodes reject any block with a timestamp that is more than two hours ahead of the average time reported by network peers.</p>
<p>Related:</p>
<ul>
<li><a href="https://bitcoin.stackexchange.com/q/119908/13866">Miners setting timestamps up to 2h into the Future</a></li>
</ul>

CC BY-SA 4.0
2024-01-01T14:35:24.393Z
But that's not a consensus rule...
LeaBit
CC BY-SA 4.0
2024-01-01T12:38:01.110Z
2024-01-01T12:38:01.110Z
RedGrittyBrick
<p>What you describe is a (variant of a) majority attack: if an attacker can construct a block every 3 minutes while the rest of the network can only construct a block every 10 minutes, that means the attacker has 10/13 = 77% of the total hashrate.</p>
<p>In such a situation, there is no hope. The attacker can also choose to ignore honest miners' blocks entirely. This situation will persist as long as the attacker has a majority of the hashrate, but it is not permanent. If other hashrate comes online, the situation is resolved.</p>
<p>Note that even though the attacker in your scenario can outcompete the honest network, they cannot(*) actually print money substantially faster than the subsidy allows, because the network (=honest nodes, including non-miners) will not accept blocks with a timestamp more than 2 hours in the future. As you point out in another answer, that is not technically a consensus rule, but it is sufficient for the attacker to not be able to spend their minted coins immediately. They need to wait to broadcast their (quickly) mined blocks until the blocks' timestamp is within 2 hours of the current time, and at that point it degrades into a simple collision attack - equivalent to the attacker simply never building on top of honest miners' blocks.</p>
<p>(*) There does exist a separate <a href="https://bitcoin.stackexchange.com/q/75831">timewarp attack</a> (which is more sophisticated), where a majority hashrate attacker <em>can</em> speed up block production beyond the intended 10 min/block. It exploits a bug in how difficulty adjustment is calculated, and needs a soft fork to fix it.</p>

CC BY-SA 4.0
2024-01-01T15:33:54.683Z
According to some "rough" math, it turns out that then he can use his majority of hashrate to actually send just 12 blocks "prematurely". He generates those blocks in `3min*12=36 min`. All these 12 blocks will be immediately accepted upon sending to the network. For all other blocks after that he will actually have to wait 10 minutes otherwise blocks won't enter the 2 hour range? So actually the network wouldn't have that much of a problem?
LeaBit
CC BY-SA 4.0
2024-01-01T15:13:16.823Z
2024-01-01T15:13:16.823Z
Pieter Wuille
<p>Assume some very &quot;strong&quot; miner that can produce a new block (find a correct nonce) on average every 3 minutes. Everything is fine as long as he sets the right timestamp (the one corresponding to 3 minutes on average), because that way the difficulty will increase (the target will decrease) and the average time to find a new block will return back to about 10 minutes.</p>
<p><strong>However, what happens if he lies and sets the timestamp values as 10 minutes even thought they are actually 3?</strong></p>
<p>In that case the block timestamps correspond to 10 minutes, but the blocks were actually created every 3 minutes and propagated to the network. By that, the difficulty remains the same (since the timestamp in the blocks is set for 10 and not 3 minutes), which enables the dominant miner to further have a monopoly over the network. Also, it additionally means that we will actually reach 2016 blocks (when retargeting is done) in 14/3 (say ~5) days instead of 14 days.</p>
<p>So one miner controls the entire network because he produces a block every 3 minutes while the difficulty remains as if it were 10.</p>
<p>How does the network protect itself from this kind of attack?</p>

CC BY-SA 4.0
2024-01-02T15:50:43.187Z
I removed the [tag:time-warp-attack] tag, since that is a very specific attack that relies on exploiting the off-by-one error in how the difficulty adjustment assesses the time that has passed in the most recent difficulty period.
Murch
<mining-pools><mining-theory><majority-attack><difficulty-retargetting>
How does the network protect itself against attacks where one miner with a lot of hashing power lies that it takes 10 minutes to create a block?
LeaBit
# How does the network protect itself against attacks where one miner with a lot of hashing power lies that it takes 10 minutes to create a block?

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

Assume some very "strong" miner that can produce a new block (find a correct nonce) on average every 3 minutes. Everything is fine as long as he sets the right timestamp (the one corresponding to 3 minutes on average), because that way the difficulty will increase (the target will decrease) and the average time to find a new block will return back to about 10 minutes.

**However, what happens if he lies and sets the timestamp values as 10 minutes even thought they are actually 3?**

In that case the block timestamps correspond to 10 minutes, but the blocks were actually created every 3 minutes and propagated to the network. By that, the difficulty remains the same (since the timestamp in the blocks is set for 10 and not 3 minutes), which enables the dominant miner to further have a monopoly over the network. Also, it additionally means that we will actually reach 2016 blocks (when retargeting is done) in 14/3 (say ~5) days instead of 14 days.

So one miner controls the entire network because he produces a block every 3 minutes while the difficulty remains as if it were 10.

How does the network protect itself from this kind of attack?

**Tags:** mining-pools, mining-theory, majority-attack, difficulty-retargetting

> **Comments:**
> **username_1**: I removed the [tag:time-warp-attack] tag, since that is a very specific attack that relies on exploiting the off-by-one error in how the difficulty adjustment assesses the time that has passed in the most recent difficulty period.  

---

## 2 answers

### Answer by username_3 on 2024-01-01. Score: 9 | Accepted answer

What you describe is a (variant of a) majority attack: if an attacker can construct a block every 3 minutes while the rest of the network can only construct a block every 10 minutes, that means the attacker has 10/13 = 77% of the total hashrate.

In such a situation, there is no hope. The attacker can also choose to ignore honest miners' blocks entirely. This situation will persist as long as the attacker has a majority of the hashrate, but it is not permanent. If other hashrate comes online, the situation is resolved.

Note that even though the attacker in your scenario can outcompete the honest network, they cannot(\*) actually print money substantially faster than the subsidy allows, because the network (=honest nodes, including non-miners) will not accept blocks with a timestamp more than 2 hours in the future. As you point out in another answer, that is not technically a consensus rule, but it is sufficient for the attacker to not be able to spend their minted coins immediately. They need to wait to broadcast their (quickly) mined blocks until the blocks' timestamp is within 2 hours of the current time, and at that point it degrades into a simple collision attack - equivalent to the attacker simply never building on top of honest miners' blocks.

(\*) There does exist a separate [timewarp attack](https://bitcoin.stackexchange.com/q/75831) (which is more sophisticated), where a majority hashrate attacker *can* speed up block production beyond the intended 10 min/block. It exploits a bug in how difficulty adjustment is calculated, and needs a soft fork to fix it.

> **Comments:**
> **username_0**: According to some "rough" math, it turns out that then he can use his majority of hashrate to actually send just 12 blocks "prematurely". He generates those blocks in `3min*12=36 min`. All these 12 blocks will be immediately accepted upon sending to the network. For all other blocks after that he will actually have to wait 10 minutes otherwise blocks won't enter the 2 hour range? So actually the network wouldn't have that much of a problem?  

---

### Answer by username_2 on 2024-01-01. Score: 2

One obvious countermeasure is that nodes reject any block with a timestamp that is more than two hours ahead of the average time reported by network peers.

Related:

* [Miners setting timestamps up to 2h into the Future](https://bitcoin.stackexchange.com/q/119908/13866)

> **Comments:**
> **username_0**: But that's not a consensus rule...  

---

