<p>Peter Todd has an in-depth answer to this question here:</p>

<p><a href="https://petertodd.org/assets/commitments/52ccc4802bd563076cbd25ec4c1ba88152098cb6aa356ba644c9e79a24182da5.txt" rel="noreferrer">https://petertodd.org/assets/commitments/52ccc4802bd563076cbd25ec4c1ba88152098cb6aa356ba644c9e79a24182da5.txt</a></p>

<h1>What attack does the difficulty drop rate limiter prevent?</h1>

<p>The Bitcoin protocol limits the rate at which the difficulty can decrease to no
less than 1/4th of the prior period's difficulty per adjustment period.
Specifically, in the difficulty calculation the variable containing the actual
time it took to generate 2016 blocks is capped at 4x the expected time.</p>

<pre><code>// Limit adjustment step
int64_t nActualTimespan = pindexLast-&gt;GetBlockTime() - nFirstBlockTime;
if (nActualTimespan &gt; params.nPowTargetTimespan*4)
    nActualTimespan = params.nPowTargetTimespan*4;
</code></pre>

<p>So why did Satoshi do this? What attack does this rate limiter prevent?</p>

<p>Suppose I want to trick you into accepting a chain that I've mined with less
work than the valid chain with the most work in existence. If I can
successfully sybil attack you, I can prevent you from learning about the
most-work chain.</p>

<p>Let's suppose I start the sybil attack when you know of the existance of block
n=(k*2016 - 1), which happens to be one block prior to the end of the difficulty
adjustment period, and has timestamp t.</p>

<p>I now mine block n+1 with the largest timestamp you'll accept (your local clock
plus 2hrs). Without the rate limiter, the amount that the difficulty would drop
is limited only by the difference between time t and now - that may be very
large if your node has been off for awhile, you're in initial sync, or I manage
to get you to reset your chainstate (e.g. by social engineering, or with a
chainstate corruption exploit). For example, if I manage to roll you back a
year, the difficulty would drop to 1/26th of the last block you know about.</p>

<p>With the difficulty dropped, I can then mine blocks quite cheaply to make you
think the transaction you're accepting has a significant number of
confirmations.</p>

<p>By limiting the rate at which difficulty can drop we make this attack
significantly more expensive: my cost-per-block is now only 1/4th of what it
should be, a significant increase compared to the situation without the drop
rate limit.</p>

<h1>Synchrony/Latency</h1>

<p>Of course, all consensus systems have a network synchrony assumption of some
kind - if the participants can't communicate in a sufficiently timely manner
it's impossible to come to consensus; the infinite latency case being an
obvious example. But even if the system isn't functioning properly, we still
want to limit what an attacker can do: in combination with PoW, the difficulty
drop limit ensures that even if latency is infinite, attacks against
participants are <em>still</em> expensive, turning a potentially disastrous
double-spend attack into a much less harmful DoS attack.</p>

<h1>PoW vs PoS</h1>

<p>Finally, note how important PoW was here: PoW guarantees that this attack will
be expensive, by virtue of the fact that the attacker has no way of avoiding
the need to spend funds to destroy energy - or in the case of stolen hash
power, give up the opportunity to mine blocks extending the most-work chain.</p>

<p>Meanwhile in a PoS system this attack can be done for free: even in a "slasher"
style PoS system, since we've sybil attacked the target we can prevent the
slasher mechanism from working. The proof of our fraud will never reach the
outside world, and thus has no impact on the value of our staked coins.</p>

CC BY-SA 3.0
2017-08-22T23:28:25.693Z
2017-08-22T23:43:52.760Z
2017-08-22T23:43:52.760Z
Vijay Boyapati
<p>The BCash fork seems to have correctly anticipated the need to adjust difficulty downwards in the case of very slow blocks. This means it's much less likely for the chain to be orphaned when it was nowhere near as profitable to mine as the BTC chain (the first period was very unprofitable). All you need is one miner to continue mining to produce an adjustment downward fairly rapidly. However, now we're at the point where it may be more profitable to mine BCH and this may strip mining capacity away from BTC - the profitability will see-saw between both chains.</p>

<p>Why does the BTC chain not have faster downward adjustments? I'm guessing there is some important security reason for this. It certainly saved BCH in the beginning so superficially it seems like a good idea. If BTC loses a lot of mining power and has slow adjustments you could have really long periods of slow confirmation times on the legacy chain.</p>

<p>I expect this issue will become even more important with the 2x fork when BTC (presumably) loses much more hashing power. Perhaps there is no easy solution because it would require a hard fork in itself, defeating the purpose of not forking the legacy chain.</p>

<p>So to summarize: </p>

<ul>
<li><p>Why is downward adjustment so slow on the legacy chain? There must be some real benefit to this.</p></li>
<li><p>Will an equilibrium in mining be found, assuming short-term profit seeking miners? How will that equilibrium be arrived at?</p></li>
</ul>

<mining-profitability><mining-theory><difficulty><bitcoin-cash>
Why does Bitcoin not have faster downward difficulty adjustments?
Vijay Boyapati
# Why does Bitcoin not have faster downward difficulty adjustments?

(Asked by: username_0 on 2017-08-22)

The BCash fork seems to have correctly anticipated the need to adjust difficulty downwards in the case of very slow blocks. This means it's much less likely for the chain to be orphaned when it was nowhere near as profitable to mine as the BTC chain (the first period was very unprofitable). All you need is one miner to continue mining to produce an adjustment downward fairly rapidly. However, now we're at the point where it may be more profitable to mine BCH and this may strip mining capacity away from BTC - the profitability will see-saw between both chains.

Why does the BTC chain not have faster downward adjustments? I'm guessing there is some important security reason for this. It certainly saved BCH in the beginning so superficially it seems like a good idea. If BTC loses a lot of mining power and has slow adjustments you could have really long periods of slow confirmation times on the legacy chain.

I expect this issue will become even more important with the 2x fork when BTC (presumably) loses much more hashing power. Perhaps there is no easy solution because it would require a hard fork in itself, defeating the purpose of not forking the legacy chain.

So to summarize:

* Why is downward adjustment so slow on the legacy chain? There must be some real benefit to this.
* Will an equilibrium in mining be found, assuming short-term profit seeking miners? How will that equilibrium be arrived at?

**Tags:** mining-profitability, mining-theory, difficulty, bitcoin-cash


---

## 1 answers

### Answer by username_0 on 2017-08-22. Score: 5

Peter Todd has an in-depth answer to this question here:

<https://petertodd.org/assets/commitments/52ccc4802bd563076cbd25ec4c1ba88152098cb6aa356ba644c9e79a24182da5.txt>

# What attack does the difficulty drop rate limiter prevent?

The Bitcoin protocol limits the rate at which the difficulty can decrease to no
less than 1/4th of the prior period's difficulty per adjustment period.
Specifically, in the difficulty calculation the variable containing the actual
time it took to generate 2016 blocks is capped at 4x the expected time.

```
// Limit adjustment step
int64_t nActualTimespan = pindexLast->GetBlockTime() - nFirstBlockTime;
if (nActualTimespan > params.nPowTargetTimespan*4)
    nActualTimespan = params.nPowTargetTimespan*4;

```

So why did Satoshi do this? What attack does this rate limiter prevent?

Suppose I want to trick you into accepting a chain that I've mined with less
work than the valid chain with the most work in existence. If I can
successfully sybil attack you, I can prevent you from learning about the
most-work chain.

Let's suppose I start the sybil attack when you know of the existance of block
n=(k\*2016 - 1), which happens to be one block prior to the end of the difficulty
adjustment period, and has timestamp t.

I now mine block n+1 with the largest timestamp you'll accept (your local clock
plus 2hrs). Without the rate limiter, the amount that the difficulty would drop
is limited only by the difference between time t and now - that may be very
large if your node has been off for awhile, you're in initial sync, or I manage
to get you to reset your chainstate (e.g. by social engineering, or with a
chainstate corruption exploit). For example, if I manage to roll you back a
year, the difficulty would drop to 1/26th of the last block you know about.

With the difficulty dropped, I can then mine blocks quite cheaply to make you
think the transaction you're accepting has a significant number of
confirmations.

By limiting the rate at which difficulty can drop we make this attack
significantly more expensive: my cost-per-block is now only 1/4th of what it
should be, a significant increase compared to the situation without the drop
rate limit.

# Synchrony/Latency

Of course, all consensus systems have a network synchrony assumption of some
kind - if the participants can't communicate in a sufficiently timely manner
it's impossible to come to consensus; the infinite latency case being an
obvious example. But even if the system isn't functioning properly, we still
want to limit what an attacker can do: in combination with PoW, the difficulty
drop limit ensures that even if latency is infinite, attacks against
participants are *still* expensive, turning a potentially disastrous
double-spend attack into a much less harmful DoS attack.

# PoW vs PoS

Finally, note how important PoW was here: PoW guarantees that this attack will
be expensive, by virtue of the fact that the attacker has no way of avoiding
the need to spend funds to destroy energy - or in the case of stolen hash
power, give up the opportunity to mine blocks extending the most-work chain.

Meanwhile in a PoS system this attack can be done for free: even in a "slasher"
style PoS system, since we've sybil attacked the target we can prevent the
slasher mechanism from working. The proof of our fraud will never reach the
outside world, and thus has no impact on the value of our staked coins.


---

