<p>The update frequency results in some trade-offs.</p>

<p>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.</p>

<p>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.</p>

<p>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.</p>

CC BY-SA 4.0
2018-11-16T01:39:26.573Z
2018-11-16T01:39:26.573Z
G. Maxwell
<p>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.</p>

<p>As for why it's 2016, at an average rate of 1 block per 10 minutes, it readjusts fortnightly.</p>

<p>Why 10 minutes was picked is unknown, AFAICT.</p>

CC BY-SA 3.0
2013-04-07T19:11:18.293Z
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
CC BY-SA 3.0
2013-04-07T19:02:14.237Z
2013-04-07T19:02:14.237Z
Compro01
<p>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.  </p>

CC BY-SA 3.0
2013-04-08T09:50:32.190Z
Why would be more difficult to achieve a consensus?
kermit
CC BY-SA 3.0
2013-04-08T18:11:16.903Z
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
CC BY-SA 3.0
2014-04-28T22:22:52.720Z
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
CC BY-SA 3.0
2013-04-07T19:17:56.813Z
2013-04-07T19:17:56.813Z
Borph
<p>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.</p>

<p>My scheme recovers from a 90% loss of mining power in 10 blocks.</p>

<p><a href="https://github.com/zack-bitcoin/basiccoin" rel="nofollow">https://github.com/zack-bitcoin/basiccoin</a> </p>

CC BY-SA 3.0
2014-04-24T19:45:20.883Z
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
CC BY-SA 3.0
2014-09-20T23:35:03.013Z
@NateEldredge A 51% attack is just as difficult no matter what the difficulty is.
Nick ODell
CC BY-SA 4.0
2020-01-12T20:30:17.567Z
@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.
G. Maxwell
CC BY-SA 3.0
2014-04-24T15:28:54.357Z
2014-04-24T15:28:54.357Z
user9415
<p>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.</p>

CC BY-SA 3.0
2014-06-09T09:44:56.563Z
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
CC BY-SA 3.0
2014-11-10T10:57:18.163Z
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
CC BY-SA 3.0
2016-03-03T05:36:50.990Z
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
CC BY-SA 4.0
2018-07-29T20:26:01.480Z
@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
CC BY-SA 4.0
2018-07-31T00:17:45.607Z
@PieterWuille  Is there an inaccuracy in the following?  Every fully validating OLD node would reject new blocks that don't meet the _old_ difficulty.  It would be a hardfork as soon as a NEW node found a block whose hash is between the two difficulties (and OLD nodes have a higher difficulty).  At that point, NEW nodes would see one branch and OLD ones would see the other.  Thanks for helping me understand bitcoin a little better!  Then NEW nodes would get cut off from the OLD ones for violations.
Dave Scotese
CC BY-SA 4.0
2018-07-31T00:20:38.850Z
@DaveScotese Yes, as soon as the two difficulty rules give a different result, the first block that follows it will split the network into just old nodes and just new nodes. Thus in order to not fork, you need 100% completely every node to switch to a the new code. If any old node remains, they'll be cut off from the network. Hashrate does not have anything to do with it, and a majority of anything isn't enough.
Pieter Wuille
CC BY-SA 4.0
2018-07-31T00:23:57.630Z
@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
CC BY-SA 3.0
2013-04-07T18:56:17.050Z
2013-04-07T18:56:17.050Z
Pieter Wuille
<p>Should make things smoother and result in less oscillation. Is there a reason why retargetting is only every 2016 blocks?</p>

CC BY-SA 3.0
2013-04-08T09:49:16.183Z
Note: This does not exclude filtering.
kermit
CC BY-SA 3.0
2014-06-09T09:42:55.227Z
Also see: https://en.bitcoin.it/wiki/Adaptive_difficulty
Pacerier
<difficulty-retargetting>
Why not retarget on every block?
kermit
# Why not retarget on every block?

(Asked by: username_0 on 2013-04-07)

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

**Tags:** difficulty-retargetting

> **Comments:**
> **username_0**: Note: This does not exclude filtering.  
> **username_1**: Also see: https://en.bitcoin.it/wiki/Adaptive_difficulty  

---

## 5 answers

### Answer by username_4 on 2013-04-07. Score: 12 | Accepted answer

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.

> **Comments:**
> **username_1**: 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!).  
> **username_4**: 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.  
> **username_10**: 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.  
> **username_4**: @username_10 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.  
> **username_10**: @username_4  Is there an inaccuracy in the following?  Every fully validating OLD node would reject new blocks that don't meet the _old_ difficulty.  It would be a hardfork as soon as a NEW node found a block whose hash is between the two difficulties (and OLD nodes have a higher difficulty).  At that point, NEW nodes would see one branch and OLD ones would see the other.  Thanks for helping me understand bitcoin a little better!  Then NEW nodes would get cut off from the OLD ones for violations.  
> **username_4**: @username_10 Yes, as soon as the two difficulty rules give a different result, the first block that follows it will split the network into just old nodes and just new nodes. Thus in order to not fork, you need 100% completely every node to switch to a the new code. If any old node remains, they'll be cut off from the network. Hashrate does not have anything to do with it, and a majority of anything isn't enough.  
> **username_4**: @username_10 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.  

---

### Answer by username_2 on 2018-11-16. Score: 7

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.


---

### Answer by username_3 on 2013-04-07. Score: 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.

> **Comments:**
> **username_4**: 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).  

---

### Answer by username_5 on 2013-04-07. Score: 1

Retargetting every block based on the time from the last found block would result in a ridiculous oscillation - as username_3 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.

> **Comments:**
> **username_0**: Why would be more difficult to achieve a consensus?  
> **username_5**: 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?  
> **username_6**: 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).  

---

### Answer by username_7 on 2014-04-24. Score: 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>

> **Comments:**
> **username_8**: 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.  
> **username_9**: @username_8 A 51% attack is just as difficult no matter what the difficulty is.  
> **username_2**: @username_9 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.  

---

