Beside all these solutions I still think the problem is the way DGW3 is implemented. It just does not react the way it should and that has nothing to do with being designed for... Because its a counting algo based on the last 24 blocks. One thing that also keeps me busy is the fact that KGW did not work properly either so maybe the solution is at some totally other place in the code. You sometimes see the same strange behaviour when variables are used outside the memory space and overwritten by some other procedure
DGW3 was not modified, except for some code comments and alignment. It looks like DGW3 is calculating correctly, the problem is that it was not created for jump pools at this scale. I have been thinking about increasing the number of blocks into calculation (currently 24). But I'm affraid that it will only result in multipools getting more blocks before the diff spikes. What do you think?
No, what I meant is the fact that two seperate dampening solutions that should work pretty well jump around like crazy. That made me wonder, maybe its not the KGW or DGW code but something that precedes or supercedes it. You maybe could ask Rijk what exactly was done about the KGW problem back in April, because then KGW went haywire. It's just a wild guess, but it's strange that we have more problems with those jump pool than other coins.