Re: [ANN] Catcoin - NEW THREAD - FORK INCOMING AT BLOCK 21346 - Scrypt MEOW!
... it will always be the same story, a symetrical solution (diff rise and decrease) won't work it will keep reacting the same way over and over again, 12% 6% 2% 20% won't do anything other than, making the cycle longer (flatter) or shorter / per 36 blocks, in fact and in worst case scenario, due to a lower number the diff will just keep decreasing in a much longer periode of time (if in the 36 blocks we don't reach block target time that is)
I proposed a solution to force the diff to an equilibrium, which is to have whatever limiting function for diff increase SMA36 6% or 12% or whatever, but for diff decrease leave it without any limited, which means that each time profitability pools will leave the coin, on a block the next block diff will drop to the value it should be on this will force those pools to mine the coin again, and over time it will find an equilibrium.
I proposed a solution to force the diff to an equilibrium, which is to have whatever limiting function for diff increase SMA36 6% or 12% or whatever, but for diff decrease leave it without any limited, which means that each time profitability pools will leave the coin, on a block the next block diff will drop to the value it should be on this will force those pools to mine the coin again, and over time it will find an equilibrium.
You are right in stating that having a simple moving average is not a ideal way to reach equilibrium after spike hashrate changes. However, the problem currently is not symmetry -- the current solution is asymmetric at 12% up and 10.7% down. The problem is that the change is ALWAYS pressed to the limit (because of the initial cliff it fell off from 108+ to under 1). The difficulty spends little time in the narrow 24% band around 10 minute blocktime where there is usable feedback, and instead races through until it hits a harder stop near 1 or over 100 difficulty.
An EXTREMELY simple solution to this is to start to back the change away from the limit as blocktime approaches 10. This can be implemented by changing the current diff change factor from:
MIN(MAX(10/),100/112),112/100)
to:
MIN(MAX(1-((1-(10/))*0.02),100/112),112/100)
Where 0.02 is a damping factor that changes the band of usable difficulty feedback. This change has no effect on any other specs of the coin: the max change is still 12% up and down every block based on the simple average of the last 36 blocks, and targets a 10-minute blocktime. I modeled the current system and the proposed system with these results:
As you can see, the prediction for the current mechanism is consistent with what we have seen over the last few days. Also, I simulated a 1500 MH/s spike for 36 blocks (on Feb. 8th in the plot), and the damped system responded with a quick uptick, then drop back to equilibrium.
Edit: The 0.02 damping factor comes from a maximum change of 2% when the difficulty is off by a factor of 2 (e.g. a 5-minute blocktime with yield a 2% per block increase, and a 20-minute blocktime will yield a 2% per block decrease). This changes proportionally to the damping factor, so a factor of 0.01 will yield a 1% increase for 5-minute blocktimes, and 0.03 a 3% increase. Anything over 5% is unstable in my model, while anything under 0.5% is very slow.