<p>The attack allows a group of miners with more than 50% of the network's computational power to change difficulty arbitrarily.</p>

<p>When difficulty is adjusted, only the times of the first and last blocks in a retarget period (i.e., the first and last blocks with a certain difficulty) are considered. This attack works by manipulating the timestamp of one of these two blocks.</p>

<p>Blocks are considered valid if their time is greater than the median of the last 11 blocks and less than currentTime + 2 hours, so it's legal for an attacker to create a new version of an old block with a time far in the future. If this is the first block in a retarget period, then the difficulty will quadruple after that period. If it's the last block, then the difficulty will be divided by four. (Difficulty adjustments are limited to *4 or /4.)</p>

<p>Note that it is not possible to do these major changes with recent blocks because the time would be more than two hours in the future. It needs to be done with historical blocks, and then the attacker needs to re-do all blocks that come after that block. So this attack is only possible when you have a lot more computational power than the legitimate network.</p>

<p>This would not be as big of a problem if there was a block of overlap between the retarget periods. Instead of using the first and last block in a retarget period, use the last block of the old difficulty and the last block of the new difficulty. Then the attacker will still be able to mess with one retarget period, but it will be corrected in the next retarget period.</p>

<p>I think a better solution would be to look at <em>every</em> block in a retarget period plus maybe some blocks before the period. It just seems like a bad idea to give certain blocks "special powers".</p>

<p>A discouraged block is considered valid (it adds confirmations to transactions, blocks after it will also be valid, etc.), but your node refuses to relay it or build future blocks onto it. If most of the network is discouraging a block, then it will almost certainly be replaced. Even a minority discouraging a block will hurt the block's chances. It is very unprofitable for a miner to discourage a block when most of the network is not, though.</p>

<p>(Thanks to gmaxwell for explaining this attack to me.)</p>

CC BY-SA 3.0
2011-10-17T07:38:01.820Z
2011-10-17T07:38:01.820Z
theymos
<p>In this <a href="https://bitcointalk.org/index.php?topic=46498.msg555518#msg555518">forum post</a> from Gavin Andresen he writes: </p>

<blockquote>
  <p>Second: I've written 'discourage blocks' infrastructure:
    <a href="https://github.com/gavinandresen/bitcoin-git/tree/discourageblocks">https://github.com/gavinandresen/bitcoin-git/tree/discourageblocks</a>
    (code reviews welcome)</p>
  
  <p>... which should give us the ability to nudge miners to Do The Right
  Thing.  Discouraging blocks that appear to be gaming the off-by-one
  bug should be enough incentive to prevent 50+% cartels from forming,
  without requiring a blockchain-splitting change.</p>
</blockquote>

<p>I believe the off-by-one bug refers to the difficulty re-target being based on the time taken for the previous 2015 blocks instead of 2016 blocks - please correct me if I'm wrong.</p>

<p>What I want to know is how can this bug be gamed by miners? What can they do and what advantage does it give them?</p>

<security><protocol><timestamp><difficulty-retargetting><time-warp-attack>
Gaming the "off-by-one" bug (difficulty re-target based on 2015 instead of 2016 block time span)?
kirian
# Gaming the "off-by-one" bug (difficulty re-target based on 2015 instead of 2016 block time span)?

(Asked by: username_0 on 2011-10-13)

In this [forum post](https://bitcointalk.org/index.php?topic=46498.msg555518#msg555518) from Gavin Andresen he writes:

> Second: I've written 'discourage blocks' infrastructure:
> <https://github.com/gavinandresen/bitcoin-git/tree/discourageblocks>
> (code reviews welcome)
>
> ... which should give us the ability to nudge miners to Do The Right
> Thing. Discouraging blocks that appear to be gaming the off-by-one
> bug should be enough incentive to prevent 50+% cartels from forming,
> without requiring a blockchain-splitting change.

I believe the off-by-one bug refers to the difficulty re-target being based on the time taken for the previous 2015 blocks instead of 2016 blocks - please correct me if I'm wrong.

What I want to know is how can this bug be gamed by miners? What can they do and what advantage does it give them?

**Tags:** security, protocol, timestamp, difficulty-retargetting, time-warp-attack


---

## 1 answers

### Answer by username_1 on 2011-10-17. Score: 19 | Accepted answer

The attack allows a group of miners with more than 50% of the network's computational power to change difficulty arbitrarily.

When difficulty is adjusted, only the times of the first and last blocks in a retarget period (i.e., the first and last blocks with a certain difficulty) are considered. This attack works by manipulating the timestamp of one of these two blocks.

Blocks are considered valid if their time is greater than the median of the last 11 blocks and less than currentTime + 2 hours, so it's legal for an attacker to create a new version of an old block with a time far in the future. If this is the first block in a retarget period, then the difficulty will quadruple after that period. If it's the last block, then the difficulty will be divided by four. (Difficulty adjustments are limited to \*4 or /4.)

Note that it is not possible to do these major changes with recent blocks because the time would be more than two hours in the future. It needs to be done with historical blocks, and then the attacker needs to re-do all blocks that come after that block. So this attack is only possible when you have a lot more computational power than the legitimate network.

This would not be as big of a problem if there was a block of overlap between the retarget periods. Instead of using the first and last block in a retarget period, use the last block of the old difficulty and the last block of the new difficulty. Then the attacker will still be able to mess with one retarget period, but it will be corrected in the next retarget period.

I think a better solution would be to look at *every* block in a retarget period plus maybe some blocks before the period. It just seems like a bad idea to give certain blocks "special powers".

A discouraged block is considered valid (it adds confirmations to transactions, blocks after it will also be valid, etc.), but your node refuses to relay it or build future blocks onto it. If most of the network is discouraging a block, then it will almost certainly be replaced. Even a minority discouraging a block will hurt the block's chances. It is very unprofitable for a miner to discourage a block when most of the network is not, though.

(Thanks to gmaxwell for explaining this attack to me.)


---

