<p>Block duration is only controlled by difficulty (although indirectly) and network hashrate, so you'd want to increase difficulty when there are very few transactions in the last X blocks, and vice versa, decrease difficulty when blocks become too full, but also decrease difficulty when there is a low hashrate, and increase difficulty when there is a high hashrate.</p>

<p>At the same time, you'd need to incentivize mining, so you might want to have a reward relative to target time, instead of constant per block, as otherwise miners could spam the network in order to increase revenue.</p>

<h2>A draft</h2>

<p>Let's say, we are aiming to adjust from looking at the last 100 blocks for blocks that are 50% full.  </p>

<pre><code>findNewBlockTime():
  newTimeTarget = (avBlockInterval100)*(0.5/averageFullness); //shorter interval with many transactions, longer with less

setReward():
  newReward = newTimeTarget*totalIntervalReward/rewardInterval; //rewardInterval could be four years like Bitcoin, or some other interval, with four years totalIntervalReward would be 11.5M coins for first interval

calculateDifficulty():
  newDifficulty = sumDiffLast100/last100BlocksTime*newTimeTarget;
</code></pre>

CC BY-SA 3.0
2015-06-25T10:13:44.310Z
2015-06-25T10:13:44.310Z
Murch
<p>You might be interested in what I wrote about the subject <a href="https://bitcointalk.org/index.php?topic=79837.0" rel="nofollow">here</a>. You can make a protocol change where miners are given a choice of their block's "weight", and their decision can then be used to set the global frequency parameters.</p>

CC BY-SA 3.0
2015-08-24T11:09:15.667Z
2015-08-24T11:09:15.667Z
Meni Rosenfeld
<p>I want to implement this, so does anyone have a formula for dynamic block durations instead of a fixed target of 10 minutes?</p>

CC BY-SA 3.0
2015-03-20T10:06:43.593Z
Essentially, you would have to change the difficulty every block, or define the difficulty in terms of passed time. AFAIR The Kimoto Gravity Well does both: [How does the Kimoto Gravity Well regulate difficulty?](http://bitcoin.stackexchange.com/q/21730/5406)
Murch
CC BY-SA 3.0
2015-03-20T12:22:56.073Z
@Murch I already use Kimoto Gravity Well, but it changes the difficulty but not the blockduration?
Maestro
CC BY-SA 3.0
2015-03-20T12:33:25.837Z
Sorry, it's been a year since I read about KGW. If I recall correctly, there was some altcoin that accepted blocks at a receding difficulty the more time had passed, I thought it was KGW that did that, but alas I seem to misremember. Also, now that I think about it, that might come with some unique attack vectors to replace the chain leaf by mining a higher difficulty block redated to an earlier time.
Murch
CC BY-SA 3.0
2015-03-20T16:07:11.173Z
How do you want the block duration to change? That's the hard part. After that, the formula is essentially the same, one of the input parameters (the target block time), just changes.
morsecoder
CC BY-SA 3.0
2015-03-20T20:24:04.493Z
@StephenM347 I want a faster interval when needed, and slower if the network is underutilized.  A good indicator could be the number of transactions in the past X blocks I think? But maybe there are better measures? But for example: if the past 100 blocks are filled by more than 50% of the allowed max, raise the speed. if their are filled less than 50%, decrease the speed. what do u think? What will be a challenge is that I also like to have a floating maximum blocksize, so the previous example would be very complex to implement, since the max blocksize could also grow in the mean time :)
Maestro
CC BY-SA 3.0
2015-03-20T21:08:57.130Z
@Muis, be careful with solutions like that, it sounds easily manipulated, and the problems introduced could be worse than the ones it is trying to solve.
morsecoder
CC BY-SA 3.0
2015-03-20T21:11:34.620Z
@StephenM347 I know, its just for a personal experiment, no noobs will be harmed :)
Maestro
CC BY-SA 3.0
2015-03-24T09:39:19.240Z
It seems like what you really want is a formula to keep block duration static, and block difficulty dynamic.
Nick ODell
CC BY-SA 3.0
2015-03-24T13:00:21.870Z
@NickODell No? Suppose you have a chain that almost receives no transactions for 10 years, but it must be ready for 1 month of high-traffic. If you make the block-duration shorter to be prepared, then you have 10 years of empty blocks to store. If the duration was dynamic, you could have blocks which span 1 month (only 120 for 10 years), and then switch to 1 minute when needed.
Maestro
<protocol><alternatives><altcoin><altcoin-development>
Does anyone have a formula for dynamic block durations?
Maestro
# Does anyone have a formula for dynamic block durations?

(Asked by: username_0 on 2015-03-20)

I want to implement this, so does anyone have a formula for dynamic block durations instead of a fixed target of 10 minutes?

**Tags:** protocol, alternatives, altcoin, altcoin-development

> **Comments:**
> **username_1**: Essentially, you would have to change the difficulty every block, or define the difficulty in terms of passed time. AFAIR The Kimoto Gravity Well does both: [How does the Kimoto Gravity Well regulate difficulty?](http://bitcoin.stackexchange.com/q/21730/5406)  
> **username_0**: @username_1 I already use Kimoto Gravity Well, but it changes the difficulty but not the blockduration?  
> **username_1**: Sorry, it's been a year since I read about KGW. If I recall correctly, there was some altcoin that accepted blocks at a receding difficulty the more time had passed, I thought it was KGW that did that, but alas I seem to misremember. Also, now that I think about it, that might come with some unique attack vectors to replace the chain leaf by mining a higher difficulty block redated to an earlier time.  
> **username_2**: How do you want the block duration to change? That's the hard part. After that, the formula is essentially the same, one of the input parameters (the target block time), just changes.  
> **username_0**: @StephenM347 I want a faster interval when needed, and slower if the network is underutilized.  A good indicator could be the number of transactions in the past X blocks I think? But maybe there are better measures? But for example: if the past 100 blocks are filled by more than 50% of the allowed max, raise the speed. if their are filled less than 50%, decrease the speed. what do u think? What will be a challenge is that I also like to have a floating maximum blocksize, so the previous example would be very complex to implement, since the max blocksize could also grow in the mean time :)  
> **username_2**: @Muis, be careful with solutions like that, it sounds easily manipulated, and the problems introduced could be worse than the ones it is trying to solve.  
> **username_0**: @StephenM347 I know, its just for a personal experiment, no noobs will be harmed :)  
> **username_3**: It seems like what you really want is a formula to keep block duration static, and block difficulty dynamic.  
> **username_0**: @username_3 No? Suppose you have a chain that almost receives no transactions for 10 years, but it must be ready for 1 month of high-traffic. If you make the block-duration shorter to be prepared, then you have 10 years of empty blocks to store. If the duration was dynamic, you could have blocks which span 1 month (only 120 for 10 years), and then switch to 1 minute when needed.  

---

## 2 answers

### Answer by username_1 on 2015-06-25. Score: 2

Block duration is only controlled by difficulty (although indirectly) and network hashrate, so you'd want to increase difficulty when there are very few transactions in the last X blocks, and vice versa, decrease difficulty when blocks become too full, but also decrease difficulty when there is a low hashrate, and increase difficulty when there is a high hashrate.

At the same time, you'd need to incentivize mining, so you might want to have a reward relative to target time, instead of constant per block, as otherwise miners could spam the network in order to increase revenue.

## A draft

Let's say, we are aiming to adjust from looking at the last 100 blocks for blocks that are 50% full.

```
findNewBlockTime():
  newTimeTarget = (avBlockInterval100)*(0.5/averageFullness); //shorter interval with many transactions, longer with less

setReward():
  newReward = newTimeTarget*totalIntervalReward/rewardInterval; //rewardInterval could be four years like Bitcoin, or some other interval, with four years totalIntervalReward would be 11.5M coins for first interval

calculateDifficulty():
  newDifficulty = sumDiffLast100/last100BlocksTime*newTimeTarget;

```


---

### Answer by username_4 on 2015-08-24. Score: 0

You might be interested in what I wrote about the subject [here](https://bitcointalk.org/index.php?topic=79837.0). You can make a protocol change where miners are given a choice of their block's "weight", and their decision can then be used to set the global frequency parameters.


---

