... 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.
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:
This is also wrong for several reasons and the fact that diff exceeded the initial 108 and by a huge margings proves that the algo is not solving this issue at all. Also I'll let you answer this on your own, what would be the difference if the initial diff was 50 instead of 108 or even 25 for that matter? What you need to take into consideration and I feel this is one of the model flaws is that profitability pools, don't switch after a SET block they keep mining as long as the coin is profitable so if the 36 average makes the increase of the diff slower (due to the lower average) they'll keep mining longer, intel they'll reach the same point of non profitability and leave and the same story with start over again.
Also 10.7% down did I miss something? and this is even worse, it means that the diff takes longer to go down than to go up.
112/100 = 12% change up, 100/112 = 10.7% change down. This has been noted on previous pages.
The difficulty dropped below 1 because even if 35 blocks were solved INSTANTLY after the fork, the 36 block average time would still have been over 10 minutes -- and so even after 35 drops of 12% the algo "thought" the diff was still too high. Though it wasn't instant, once a couple blocks were found the next 30 or so came very fast. Then, very suddenly, those long blocks were far enough back to be left out of the average, and the average time dropped to below a minute.
The 36SMA12LMT system is intended to react fast to lots of hash entering and leaving the network (which it does well) but a side effect of that is that it overreacted to what it perceived as a lot of hash having "just left" a the time of the fork. If the difficulty had started at 50, block times would have been more reasonable for the 36 before the fork, and this oscillation would never have started.
Also, having the hashrate rise faster than it drops is good in that it prevents hyperinflation. As long as the drop back down is fast enough to keep block times reasonable (at least under an hour), that's more suitable for reaching an equilibrium state.