If a block takes too long to find, diff. will automatically drop on next drop. If you look at the previous sequences I posted, the 30min. or more case will yield the following :
120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-120-1800 = 2.93 mn block average
Which is way above the 10% limit, triggering a diff. drop on next block.
What I'm gonna do this time is extract actual block times from the NRB chain, and use those as test cases for the new diff. algo, so we'll have concrete data to monitor the suggested change's impact on difficulty.
I agree. Retarget on every block, but use the last 30 to figure out the new value. That adds enough ballast to keep the system running smoothly, and also let's the difficulty go up with every block that's too fast, and go down with every block which is too slow. In the end the protection against hash spikes will be enough hashing power all the time to keep it stable.