I honestly think the next solution needs to be the solution. Not a series of solutions until we get there.
The more changes we make, the more bloated the code becomes to keep track of the changes on the blockchain, and the bigger chance we have of breaking things. Let the devs and the community come together and figure this out in a rational manner. Hasty decisions kill coins.
-Fuse
The change of block reward depending on block time I would consider a bigger change but easier to implement. It could start hitting if the time falls below a certain level like 60% (1.5min instead the normal 2.5min), this way it allows smaller variations of hashrate before it kicks in.
The other part of changes I am thinking about is the modification of our DGW3, so that it is able to handle major changes in hashrate like we see them now and will have to expect them even more extrem. Let us develop it further, so it can cope with the problems of the Scrypt ASIC age.
I have looked at several diff adaption algorithm during the last days and still think DGW3 was a good choice.
What I had to realize is, they are all pre scrypt ASIC and none of them is able to handle spike like we see them well enough.
Looks like none expected hashpower like we see them today in the hands of only a few switching pools.
And from what I saw, all of them have what I call the "bad block" problem; none of them can handle a sharp drop of hashrate fast enough and steady miners are left with atleast 1 block with extrem long time to solve.
Think of it as a series of smaller patches to tune DGW3 and when it's done you can call it DGW4 if you want.
And for those talking about 1 min block times: The original DGW3 is using a block time of 2.5 min too.
Shortening block times by a factor of 2.5 would only shorten the times for the bad blocks by the same factor. And on the side of the quick blocks we can easily run into much bigger problems.
We need to work on the problem itself, not make them look smaller.
