12

Should make things smoother and result in less oscillation. Is there a reason why retargetting is only every 2016 blocks?

11

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.

  • 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!). – Pacerier Jun 9 '14 at 9:44
  • 2
    How 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. – Pieter Wuille Nov 10 '14 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. – Dave Scotese Mar 3 '16 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. – Pieter Wuille Jul 29 '18 at 20:26
  • 1
    @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. – Pieter Wuille Jul 31 '18 at 0:23
2

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.

  • 7
    It'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). – Pieter Wuille Apr 7 '13 at 19:11
2

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.

1

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
    Why would be more difficult to achieve a consensus? – kermit Apr 8 '13 at 9:50
  • 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? – Borph Apr 8 '13 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 '14 at 22:22
1

Now many coins are retargeting every block using Kimoto Gravity Well Algorithm introduced by Megacoin

see How does the Kimoto Gravity Well regulate difficulty?

0

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.

https://github.com/zack-bitcoin/basiccoin

  • 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. – Nate Eldredge Apr 24 '14 at 19:45
  • 2
    @NateEldredge A 51% attack is just as difficult no matter what the difficulty is. – Nick ODell Sep 20 '14 at 23:35

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.