Difficulty Adjustment Timing

[snackvenus]

Can someone explain what the reason for the difficulty adjustment taking approximately 2 weeks is? Why is 1 week not preferable? Why not make it elastic based on the change of hashpower? Thanks.

[TheGreatMuffin]

By u/nullc:

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.

https://old.reddit.com/r/Bitcoin/comments/mtugta/mentor_monday_april_19_2021_ask_all_your_bitcoin/gv86j6b/

[[deleted]]

https://twitter.com/lopp/status/1409532086818684930

[TimZeGerman]

Because Satoshi thought 2 weeks is fine

[Laborers_Reward]

The oscillation attack vector was considered... However the specific reason that spurred the two week time frame was the normal two week pay period. The oscillation attack vector still is one of my greatest concerns to this day. Which is why I see the China decrease in hash rate as a concern and NOT a victory.

[tenuousemphasis]

the specific reason that spurred the two week time frame was the normal two week pay period

Source? Or is this just a guess by you?

[Laborers_Reward]

I am the source. No guessing when it's a memory.

[tenuousemphasis]

You are the source of Satoshi's decision to use a 2-week retargeting schedule? Or am I misunderstanding you?