<p>The explanations on the web are all very vague and mystical, on purpose maybe. Here is my take in simple words, just reading the megacoin source code from the above comment. </p>

<p>The goal is to have a more adaptive way of adjusting the difficulty instead of just averaging the last 2016 blocks like bitcoin. This is needed because of multipools which might switch the coin they are mining, and a sudden change in hashrate  can occur (both increasing or decreasing). Especially when a multipool switches away you get stuck too long with a too high difficulty.</p>

<p>The algo loops backwards through the blocks, starting from the current one. The <code>PastBlocksMass</code> is just the number of blocks, so it starts at one and increases in each loop.</p>

<p>In each loop an adjustment factor is computed, which is the target block time divided by the actual block time, in a cumulative fashion, so at loop 10 we would have the 25 minutes target time divided by the time it actually took to compute the last ten blocks. When the hashrate increases, we get shorter times and an adjustment factor greater than one and vice versa. </p>

<p>The loop ends whenever the average adjustment factor is larger than the <code>kimoto-value</code>, or smaller than <code>1/kimoto-value</code>. To understand this look at this python script and an example plot:</p>

<pre><code>from pylab import *

one_day = 1440 / 2.5   # how many 2.5 min blocks per day

nmin = one_day / 4     # PastBlocksMin
nmax = one_day * 7     # PastBlocksMax
x = arange(nmin, nmax)   # PastBlocksMass

# start with 2.5 minute blocktime + some noise
t0 = 2.5 + randn(nmax) / 4
t1 = 2.5 + randn(nmax) / 4

# t0 has 20% more hashrate, so shorter blocktime in the beginning
t0[:one_day] = 2.5 / 1.2 + randn(one_day) / 4
# t1 has higher blocktime in the beginning
t1[:one_day] = 2.5 / 0.9 + randn(one_day) / 4

s = arange(nmax)

adjust0 = (arange(1, nmax + 1) * 2.5 ) / cumsum(t0)
adjust1 = (arange(1, nmax + 1) * 2.5 ) / cumsum(t1)

# the magic function
def kimoto(x):
    return  1 + (0.7084 * pow((double(x)/double(144)), -1.228));

plot(x/one_day, kimoto(x))
plot(x/one_day, 1/kimoto(x))
plot(s/one_day, adjust0)
plot(s/one_day, adjust1)
legend(["kimoto","1/kimoto", "20% increase in hashrate", "10% drop in hashrate"])
xlabel("days")
ylabel("adjustment factor (target/actual blocktime)")
show()
</code></pre>

<p>The script produces a figure like this <img src="https://i.sstatic.net/I5HHI.png" alt="Kimoto gravity well">.</p>

<p>It shows two constructed examples when the hashrate increases and when it drops for one day. Best is to play with different settings for a while to get a feel for what is going on. </p>

<p>You see that the lines cross through the Kimoto formula at some point. This is when the algo exits and uses this adjustment factor to compute a new target/difficulty. For large adjustment factors this happens earlier than for the ones closer to one. This is to have a quick adaptation if the hashrate changes a lot, and a slower one if not - then we want a longer period to get a better average. The parameters of the Kimoto formula are adjusted in such a way that one roughly adjusts in one day to a 10% change and in seven days to a 1.2% change. A minimum of 144 blocks determine the new difficulty and at most 4032 (0.25 days or 7 days for a 2.5 minute blocktime).</p>

<p>Summary: the Kimoto gravity well algo has a fancy name and determines the number of blocks which contribute to the evaluation of the new difficulty. It gives fewer blocks for high hashrate changes and is therefore more adaptive. </p>

CC BY-SA 3.0
2014-02-16T18:18:25.343Z
Thank you, this is very helpful. One thing I am not sure I understood: What happens when the minimum of 144 blocks isn't reached or the maximum of 4032 blocks is exceeded. Is the KGW then used or is it then not used?
Murch
CC BY-SA 3.0
2014-02-16T20:36:04.813Z
The minimum is 144 blocks. So if the adjustment factor is larger than 1+0.7084, then the factor for 144 blocks is taken. At 4032 the algo stops and the average for 4032 is taken no matter what. KGW gives an answer for both boundary cases.
cronos
CC BY-SA 3.0
2014-02-16T20:59:32.060Z
Okay, thanks, now I get what you meant with that sentence. Excellent answer, thank you very much.
Murch
CC BY-SA 3.0
2014-02-16T17:19:26.367Z
2014-02-16T20:34:53.530Z
2014-02-16T20:34:53.530Z
cronos
<p>Maxcoin will use the <code>Kimoto Gravity Well (KGW)</code> to regulate the difficulty. From what I could find about the KGW, it retargets after every block and adjusts very quickly, e.g. when multipools add and retract mining power to a smaller coin's network. </p>

<p>Apparently, <code>KGW = 1 + (0.7084 * (PastBlocksMass/144)^(-1.228))</code> (<a href="https://bitcointalk.org/index.php?topic=240861.msg3040291#msg3040291" rel="noreferrer">-> Introductory post by Kimoto</a>) describes how to calculate the Kimoto Gravity Well. On another source, it was stated that <em>"KGW is applied if the hash rate is high, and 1/KGW when the hash rate is low"</em> (<a href="https://bitcointalk.org/index.php?topic=441402.msg4907201#msg4907201" rel="noreferrer">-> Post on Catcoin's adoption of KGW</a>).</p>

<p>This leaves me with three questions: </p>

<ol>
<li>What does <code>PastBlocksMass</code> refer to?</li>
<li>Does KGW only rely on the time required to find the previous block?</li>
<li>Why/How does the above formula produce the described fast adaptation of the difficulty?</li>
</ol>

CC BY-SA 3.0
2014-02-06T19:25:03.883Z
Here's where KGW is implemented in Megacoin. https://github.com/megacoin/megacoin/blob/master/src/main.cpp#L1276
John T
CC BY-SA 3.0
2014-02-11T00:27:48.990Z
That did help: PastBlocksMass is apparently a count of blocks up to a maximumParameter or the genesis block. Unfortunately, there are no comments and the function itself takes a number of parameters.
Murch
<difficulty><algorithms><maxcoin>
How does the Kimoto Gravity Well regulate difficulty?
Murch
# How does the Kimoto Gravity Well regulate difficulty?

(Asked by: username_0 on 2014-02-06)

Maxcoin will use the `Kimoto Gravity Well (KGW)` to regulate the difficulty. From what I could find about the KGW, it retargets after every block and adjusts very quickly, e.g. when multipools add and retract mining power to a smaller coin's network.

Apparently, `KGW = 1 + (0.7084 * (PastBlocksMass/144)^(-1.228))` ([-> Introductory post by Kimoto](https://bitcointalk.org/index.php?topic=240861.msg3040291#msg3040291)) describes how to calculate the Kimoto Gravity Well. On another source, it was stated that *"KGW is applied if the hash rate is high, and 1/KGW when the hash rate is low"* ([-> Post on Catcoin's adoption of KGW](https://bitcointalk.org/index.php?topic=441402.msg4907201#msg4907201)).

This leaves me with three questions:

1. What does `PastBlocksMass` refer to?
2. Does KGW only rely on the time required to find the previous block?
3. Why/How does the above formula produce the described fast adaptation of the difficulty?

**Tags:** difficulty, algorithms, maxcoin

> **Comments:**
> **username_1**: Here's where KGW is implemented in Megacoin. https://github.com/megacoin/megacoin/blob/master/src/main.cpp#L1276  
> **username_0**: That did help: PastBlocksMass is apparently a count of blocks up to a maximumParameter or the genesis block. Unfortunately, there are no comments and the function itself takes a number of parameters.  

---

## 1 answers

### Answer by username_2 on 2014-02-16. Score: 22 | Accepted answer

The explanations on the web are all very vague and mystical, on purpose maybe. Here is my take in simple words, just reading the megacoin source code from the above comment.

The goal is to have a more adaptive way of adjusting the difficulty instead of just averaging the last 2016 blocks like bitcoin. This is needed because of multipools which might switch the coin they are mining, and a sudden change in hashrate can occur (both increasing or decreasing). Especially when a multipool switches away you get stuck too long with a too high difficulty.

The algo loops backwards through the blocks, starting from the current one. The `PastBlocksMass` is just the number of blocks, so it starts at one and increases in each loop.

In each loop an adjustment factor is computed, which is the target block time divided by the actual block time, in a cumulative fashion, so at loop 10 we would have the 25 minutes target time divided by the time it actually took to compute the last ten blocks. When the hashrate increases, we get shorter times and an adjustment factor greater than one and vice versa.

The loop ends whenever the average adjustment factor is larger than the `kimoto-value`, or smaller than `1/kimoto-value`. To understand this look at this python script and an example plot:

```
from pylab import *

one_day = 1440 / 2.5   # how many 2.5 min blocks per day

nmin = one_day / 4     # PastBlocksMin
nmax = one_day * 7     # PastBlocksMax
x = arange(nmin, nmax)   # PastBlocksMass

# start with 2.5 minute blocktime + some noise
t0 = 2.5 + randn(nmax) / 4
t1 = 2.5 + randn(nmax) / 4

# t0 has 20% more hashrate, so shorter blocktime in the beginning
t0[:one_day] = 2.5 / 1.2 + randn(one_day) / 4
# t1 has higher blocktime in the beginning
t1[:one_day] = 2.5 / 0.9 + randn(one_day) / 4

s = arange(nmax)

adjust0 = (arange(1, nmax + 1) * 2.5 ) / cumsum(t0)
adjust1 = (arange(1, nmax + 1) * 2.5 ) / cumsum(t1)

# the magic function
def kimoto(x):
    return  1 + (0.7084 * pow((double(x)/double(144)), -1.228));

plot(x/one_day, kimoto(x))
plot(x/one_day, 1/kimoto(x))
plot(s/one_day, adjust0)
plot(s/one_day, adjust1)
legend(["kimoto","1/kimoto", "20% increase in hashrate", "10% drop in hashrate"])
xlabel("days")
ylabel("adjustment factor (target/actual blocktime)")
show()

```

The script produces a figure like this ![Kimoto gravity well](https://i.sstatic.net/I5HHI.png).

It shows two constructed examples when the hashrate increases and when it drops for one day. Best is to play with different settings for a while to get a feel for what is going on.

You see that the lines cross through the Kimoto formula at some point. This is when the algo exits and uses this adjustment factor to compute a new target/difficulty. For large adjustment factors this happens earlier than for the ones closer to one. This is to have a quick adaptation if the hashrate changes a lot, and a slower one if not - then we want a longer period to get a better average. The parameters of the Kimoto formula are adjusted in such a way that one roughly adjusts in one day to a 10% change and in seven days to a 1.2% change. A minimum of 144 blocks determine the new difficulty and at most 4032 (0.25 days or 7 days for a 2.5 minute blocktime).

Summary: the Kimoto gravity well algo has a fancy name and determines the number of blocks which contribute to the evaluation of the new difficulty. It gives fewer blocks for high hashrate changes and is therefore more adaptive.

> **Comments:**
> **username_0**: Thank you, this is very helpful. One thing I am not sure I understood: What happens when the minimum of 144 blocks isn't reached or the maximum of 4032 blocks is exceeded. Is the KGW then used or is it then not used?  
> **username_2**: The minimum is 144 blocks. So if the adjustment factor is larger than 1+0.7084, then the factor for 144 blocks is taken. At 4032 the algo stops and the average for 4032 is taken no matter what. KGW gives an answer for both boundary cases.  
> **username_0**: Okay, thanks, now I get what you meant with that sentence. Excellent answer, thank you very much.  

---

