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