Quote from: /GeertJohan on October 21, 2014, 07:29:13 PM

Quote from: ny2cafuse on October 21, 2014, 04:52:37 PM

Quote from: thsminer on October 21, 2014, 04:41:59 PM

To ilustrate the behaviour we experience look at the blocks below. At 137136 we had a diff of 412 and because the block preceding this took two hours the diff dropped to 118. But the max drop is 1/3 so it should have dropped to 138 and not 118. The dif lowers and despite blocktimes of tens of seconds it lowers and lowers. Till 137159 then the calculation says hoooo fellas this is too fast and it raises the diff from 29.8 to 162.1 not exactly the max three times that was in the DGW design... So why does is diff adjusted more than the DGW design? And second it can behave much better if it is a weighted average instead of a plain one.

+1 for the detailed info, mate. I'm with you 100%.

I really do believe either looking at less blocks for the average, or creating a weighted average is the way to go. Additionally, there needs to be a limit in the amount of difficulty increase/decrease so we're not throwing the difficulty all over the place.

Again- less extreme changes that happen more often.

-Fuse

I think we're on a good path here!

I've actually started implementing a new algorithm, from scratch. It performs faster re-adjustment, limited to 1.2 or 0.8 difficulty change between individual blocks. But it also limits the difficulty change to 3.0 or 0.33 compared to the last 120 blocks difficulty average. This means that the diff can rise ~3.0 times in 6 blocks, and it can fall to ~0.33 times in 5 blocks. In the linked formula's the impact of the new blocks themselves are not calculated in the 120 blocks average.
The idea behind this is that it will be able to handle large joins and leaves, but won't be tricked into settling on a high difficulty too fast.

Thoughts?

I'll share the code when I'm happy with initial implementation.

Please send me your code by PM to test it for time based attacks... remember that the Achilles Heel of difficulty retargeting algo's that adjust every block is vulnerability to time based attacks... this is why KGW had to be recoded... I would not try to reinvent the wheel with this... a Digishield variant is the best next step in finding a solution... I know this algo has pretty much resolved the multi-pool problem for POT and has proven to be quite resistant to attack.

This is the approach Criptoe is working on at present.