Should make things smoother and result in less oscillation. Is there a reason why retargetting is only every 2016 blocks?
-
Note: This does not exclude filtering.– kermitApr 8, 2013 at 9:49
-
Also see: en.bitcoin.it/wiki/Adaptive_difficulty– PacerierJun 9, 2014 at 9:42
Add a comment
|
5 Answers
I suppose the only right answer is "because that's how Satoshi implemented it". His reasons for doing may have included easy of implementation, easy to guarantee consistency among nodes, or little worry about instability of correction algorithms.
answered Apr 7, 2013 at 18:56
-
Why not 1 week then? 1 week doesn't seem much more work to implement compared to 2 weeks, but give us considerably more flexible retargetting (twice more!).– PacerierJun 9, 2014 at 9:44
-
2How much work it is to implement isn't relevant. The question is how much work it is to change, and changing this would require pretty much every single piece of Bitcoin software to be rewritten. Unless the alternative is some disaster there is no reason that could justify taking such a risk. Nov 10, 2014 at 10:57
-
Doesn't only half of the hashing power have to get their software rewritten, and then anyone who wanted to be sure about collecting all the transactions that get confirmed? Personally, I expect a valid transaction to be honored because it was published, regardless of whether or not it gets confirmed. The problem is finding out about it if there's no confirmation, and then getting others to see the logic of my position. Mar 3, 2016 at 5:36
-
@DaveScotese No, every fully validating node would reject a block whose difficulty was computed using the new rule. The amount of hashrate isn't relevant here. Jul 29, 2018 at 20:26
-
2@DaveScotese Oh, I see what you're missing. Every block contains the difficulty it is mined at. If that difficulty field is incorrect, the block is invalid. So it is a hardfork in both directions - whether the old or new rules says the difficulty should be higher. Jul 31, 2018 at 0:23
The update frequency results in some trade-offs.
Faster updates increase the exposure to isolation attacks-- where a partitioned part of the network speeds back up to the nominal speed. Faster updates also increase the amount of oscillation possible. On the plus side they make the network respond faster to changes.
Many altcoins have changed to faster rules, but the vast majority have managed to do it in wrong and vulnerable ways. For example: Some apply a sliding window filter but then apply the same change over and over again instead of it's n-th root, causing massive oscillation. Others use the timestamp of the immediately prior block to set the current difficulty-- this lets you set your timestamp slightly lower than you should in order to make the next block have epsilon higher difficulty and thus guarantee it will win in a race due to having more total work. Other schemes have wild non-linearities that make it a lot more profitable for miners to mine in bursts rather than continually.
When I look at all the different ways other rules have been messed up, and how inconsequential the 'slow' updates in Bitcoin have been in practice. I think Bitcoin's creator made a good decision, all considered.
answered Nov 16, 2018 at 1:39
Retargeting on every block would result in ridiculous oscillation in the difficulty level when there's a hot streak and several blocks are found in short succession or a cold streak where a block isn't found for a long period.
As for why it's 2016, at an average rate of 1 block per 10 minutes, it readjusts fortnightly.
Why 10 minutes was picked is unknown, AFAICT.
-
8It's perfectly possible to design an algorithm that retargets continuously and is no less stable that the current one (for example, at every block, multiply the difficulty by the 2016th root of the ratio of the time for the last 2016 blocks over two weeks). Apr 7, 2013 at 19:11
Retargetting every block based on the time from the last found block would result in a ridiculous oscillation - as compro01 writes. But if the target is based on the time for the last 2016 blocks, but evaluated every block, this would be a sliding window and I don't see why it wouldn't work. But most likely it is difficult to have consensus this way which doesn't result in a chain fork, as every node has to have the same opinion.
-
3
-
In fact, I don't know, effectively asking the same as you. When two nodes have a different opinion of the last 2016 blocks (e.g. a chain fork, got to know of a different 'highest' block) together with a bad coincidence (one block was mined just after the previous, the alternative chain didn't find a block in long time) their target would also differ. But: rejecting of blocks happens on same chain where the target is calculated, so what's the problem?– BorphApr 8, 2013 at 18:11
-
There would be no problem. It would be the same situation as it is now: As soon as the chain forks, the two chains have no influence on each other (except that the mining power is reduced for each).– Murch ♦Apr 28, 2014 at 22:22
I built the better scheme. I look at the last 1000 blocks, but I give more importance to the newer blocks. It is a geometric distribution such that the last 50 blocks are 1/2 the total weight.
My scheme recovers from a 90% loss of mining power in 10 blocks.
-
Is it clear that this is desirable? That means if an attacker can mount a denial of service attack that knocks a few big pools offline for a couple hours, they can get a quick drop in difficulty and make it much easier to perform a 51% attack. Apr 24, 2014 at 19:45
-
2@NateEldredge A 51% attack is just as difficult no matter what the difficulty is. Sep 20, 2014 at 23:35
-
2@NickODell Without the rapid difficulty change it takes a long time for a low hashrate attacker to mine 6 blocks (or whatever the target requires) even if the outage has given them >50% of the current hashrate. When difficulty is slow to change that sort of attacker isn't just fighting the current hashrate they're also fightning the recent past's hashrate in a sense. Jan 12, 2020 at 20:30