2

The Developer Guide on Bitcoin.org says:

If it took fewer than two weeks to generate the 2,016 blocks, the expected difficulty value is increased proportionally (by as much as 300%) so that the next 2,016 blocks should take exactly two weeks to generate if hashes are checked at the same rate.

If it took more than two weeks to generate the blocks, the expected difficulty value is decreased proportionally (by as much as 75%) for the same reason.

Why there is such limit on increase or decrease ratio? Updating difficulty every 2 weeks is not enough to cover abrupt changes?

Community
  • 1
Tail of Godzilla
  • 487
  • 1
  • 4
  • 12
  • Just to be clear this means multiplying or dividing the difficulty target by a maximum of 4. I don't see that happening in the current Bitcoin network anytime soon. In Altcoins this has happened and even attacks where the difficulty rose very fast and then suddenly the miners went to another altcoin, causing the difficulty to stay stuck. Notice that it's 2016 blocks which normally is 2 weeks, but if 75% of the mining power has left, then it's actually 4 * 2 weeks. – Jannes Nov 23 '15 at 09:47
  • Thanks Jannes, could you explain the attack in detail? As I understand the attacker(s) come to an Altcoin network with higher computational power of total Altcoin network causing fast rose on difficulty and then leave the network? The target Altcoin network has not pose limit on the increase ration?? What about decrease ration? It could be useful in similar scenario? – Tail of Godzilla Nov 23 '15 at 10:02
  • Different altcoins might have different increase/decrease limits and different block intervals. So the timings are likely different than for Bitcoin. But if a lot of hashing power joins the altcoin for long enough to let the difficulty rise by the maximum a few times and then leaves again, it will take a long time for the difficulty to go back down. Not so much because of the limits but because blocks are not found very often. In the extreme: if 99% of the hashing power leaves, it will take 100x longer for each block to be mined, so it will take a 100x longer to reach the 2016 blocks. – Jannes Nov 23 '15 at 10:36

1 Answers1

4

Imagine we have a system with no restrictions on the period or rate of decrease. Every block the period is updated looking back 6 blocks and adjusting the difficulty to suit, this is a modification people have made to Bitcoin forks in the past in the belief that there is no harm in doing so.

In this system, to attack a single user all we need to do is partition their node (the exact method is irrelevant, but it is possible) from the rest of the network so they can no longer see new blocks being mined. With the right timing, we might only need to solve a single block on our newly created side of the network and the user/s there will adjust their difficulty dramatically lower to compensate. With no limits, the user will happily accept order of magnitude hashrate decreases without any concern.

We now have to spend next to no effort making very low difficulty blocks on this fork. This allows us to do things like coercing the users into accepting payments with false low-difficulty confirmations, once they re-join the network they will find the confirmations will disappear and they will have been irreparably defrauded. This process would take a very short time and there's no way a user would notice the attack in time to not be stolen from.

Claris
  • 15,408
  • 2
  • 26
  • 43
  • "Six confirmations" is a rule of thumb that works well for Bitcoin. But if you had a system that let the difficulty adjust too quickly, we'd need a different metric -- perhaps some total number of hashes required to generate the blocks after the block with the transaction. And we'd need to adjust that metric regularly. – David Schwartz Nov 25 '15 at 11:46