Is there a benefit to adjusting the difficulty every so often (ie 2 weeks) vs adjusting the difficulty every block?

4 Answers 4


nullc answered this on Reddit.

Adjusting every block (or faster in general) increases user's vulnerability to isolating attacks.

Say I manage to isolate your node so that it's only talking to my node -- not a particularly hard attack. Then using some mining hashpower (perhaps that I've also isolated-- which is harder, or I'm paying for myself) I mine blocks in an isolated fork. At first the blocks come very slowly due to the high difficulty, but if it updates every block the difficulty drops and it speeds up. After a while the fork is producing 6 blocks an hour like the real network (at a lower difficulty).

IIRC the math works out such that keeping all the time constants the same the continuous update costs about half as much to attack as the update-interval = window update.

It's perhaps not the biggest issue, but the change isn't totally free.

Overlapping updates also have some mathematical/implementation complication-- because each block is at a different difficulty so you don't want to 'double apply' the effect of prior slow/fast blocks whos impact you've already partially incorporated (so you need to scale your updates by an N-th root). A bunch of altcoins have gotten this wrong and ended up with an unstable/oscillating difficulty update!

There are also weird fork-incentive attacks against continual updates: Say I game the timestamps on my block so that the successor block will have ever so slightly higher difficulty. That means if there is a competing block with a faithful timestamp at my height the successor of mine will always win in a block race against the successor of the other because my fork has some infinitesimal amount of additional work behind it. This creates an incentive for miners to continually understate their time. In theory this bad incentive also exists in bitcoin, but just at the single final block in the 2016 window-- rare enough that it's probably not worth dorking with. Updating every block makes the problem show up every block.

This can be fixed, e.g. don't use data from the most recent blocks to adjust, but instead use the timestamps from blocks at least N blocks old (setting N high enough to make forks of that depth arbitrarily rare) so that usually all forks have the same difficulty. But now you've got another parameter and tradeoff to consider.

There is also a related exotic attack: Did you know that in bitcoin an attacker which maintains any constant fraction of the networks hashrate, no matter how small (e.g. 0.000001% it just has to scale with the network) will eventually overtake the honest chain if he attacks long enough? He just keeps mining on his fork, and eventually he gets lucky and gets a block faster than he should. He constantly sets the timestamp as low as he can so his difficulty rises the fastest. Why fastest? Variance of poisson variables is equal to the expectation, so his odds of getting lucky and overstating his work go up with higher difficulty. Their difficulty goes up, and they eventually gets lucky again. After some number of lucky blocks he blows away the entire real chain with more "work"! -- but really it was only a handful of lucky blocks with difficulty vastly higher than the real network's.

It turns out that if you plug in numbers from bitcoin this attack isn't a practical concern with the current behavior. E.g. you come up with expected success times of trillions of years-- except for attackers that have significant amounts of hashpower and could attack in other ways. But what increases these attacks time is the slow 2016 updates-- the attacker doesn't need just one lucky block to increase his difficulty, he needs 2016 of them so his low odds of getting them are raised to a 2016 power! He'll then also run into the limit of a 4x difficulty change per window.

The 4x/0.25x difficulty change rule is also another complication. Any non-linearity in the rules opens up strategic behavior: e.g. bump it against the rail and crank out blocks faster, knowing it won't be met by an equal and opposite slowdown. In Bitcoin the 4x/0.25x rule is set far enough out that it's not easy to hit and (IIRC) has never been hit, so the fact that there are maybe some weird incentives there isn't too important. If you want to retain the same limit of 4x every 2016 blocks in the most simple way you'd raise the limit to the 1/2016th power, ... the result is a limit just SLIGHTLY over the current difficulty and it would get constantly hit, which would be clearly bad. There probably is some way to fix this ... or just abandon these limits completely. But it's just more tradeoffs/incentives/risks to consider.

Finally, if the time constant is unchanged-- it will still take a long time to respond to a step-event, so the win is also fairly modest at most.

Difficult is fundamentally a security mechanism and like others there are lots of ways to change it that would improve things in typical cases-- but it's the behavior in malicious and rare cases that really define its performance. Any kind of security measure is going to be worse on average than some less secure alternatives...

In any case, I dunno that I'd argue against a well studied change (-- though I'm not convinced that we even know what we don't know about this subject) including a correctly implemented change to more frequent updating (but maybe not every block), but now you've heard some of the points against it, as you requested.

  • 1
    Thanks! I believe I saw this recently actually. Sounds like a difficult thing to get right, and not as simple as it seems. I'm generally of the feeling that cliffs are bad. Welfare cliffs, vesting cliffs, and 2-week difficulty cliffs. But in the grand scheme of things, getting the difficulty adjustment perfect isn't the highest priority, and doing something that was good enough, and easier to make safe was probably a good decision.
    – B T
    May 14, 2021 at 3:17
  • All these concerns are not practical. Obviously some people hate to criticize any aspect of bitcoin no matter how ancient and dangerous it's. I would say the downward spiral in mining is way more dangerous and important than all these impractical scenarios. May 14, 2021 at 5:50

Yes, there is a risk with adjusting the difficulty every block. It entirely depends on the method of adjusting. With how Bitcoin does it, if you adjusted every block, the difficulty would vary wildly due to the variance in times between blocks. However other algorithms for determining the difficulty may be able to account for that.

Adjusting every 2 weeks allows for the average time between blocks to be close to the actual time between blocks (by the law of large numbers) so that the adjustment can happen without being effected by the variance in times between blocks. The method used by Satoshi is very simple and straightforward with its effects easy to see and model.

Like almost every other "magic number" used in Bitcoin, the 2 week interval appears to simply be an arbitrary number with no real reasoning behind it.

  • I'm talking about the frequency of adjustment, not the window of blocks used to take the average. See The Quantum Physicist's answer about Ethereum and Monero
    – B T
    Mar 22, 2018 at 6:44

In brief with hindsight: It's a mistake.

You have to keep in mind that Bitcoin is the very first Cryptocurrency. It has all the legacy designs and did not anticipate every possible problem. This includes the block-size, which initiated the huge Bitcoin 2x fork debate.

And btw, it's not every 2 weeks. Bitcoin has no means of calculating time accurately other than blocks. It's every 2016 blocks, and if we say every block is 10 minutes on average, 2016*10=20160 minutes, which is 2 weeks.

Newer tech, like Ethereum and Monero adjust the block-time dynamically. For example, Monero decides the difficulty as an average of the last 100 blocks.


2 weeks is a time which is enough long and enough short at the same time, guarantees a fair weighted balance between diff target recalculation and possible diff based attacks to the network.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.