I think that it's better to solve difficulty time warp problem in the most obvious and simple way, that is to change the way required work is computed. Currently it is computed as 1/t, that is 15 sec target time is considdered to be 4x more difficult (takes 4x more time) to find solution than 60 sec and this is probably not the case.
I think Domob already pointed to the fatal flaw in this sort of approach, and DeepCrypto already pointed to the solution.
The problem is that at any time someone could come in with something that massively makes an epic leapfrog in performance, and (at best) just put us back into "block latency race" mode. I'm not talking cpu->gpu->fpga->asic type progression, but a total smashing of the big O computational complexity of a solver.
I think DeepCrypto would agree that any meaningful solution will/must involve calculating difficulty (or difficulties) by some measure of both target time and block acceptance frequency, somehow, and must scale both.
Quote
You (and other bot operators) can do some experiments to determine how required time to find solution depends on target time,
I might try to put together some numbers, but this might ultimately be harder than it sounds to do accurately, from what I've seen so far.
Quote
then we can construct some function that is good approximation of this dependency and use it instead of 1/t.
I think we need to do this from the start. This also relates to why the direct association between control of block frequency and target time is necessary to actually call the attack vector closed.
Quote
Another counter-measure is to add checkpoint, it will prevent whole chain forking.
Agreed!