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.
In the light of the last phrase the solution has to be an answer to the question:
how do you get the blocktime within certain bounds. Satoshi came with the diff. system we all know as a solution to take care of the fact of varying blocktimes and stabilise them. This difficulty was adjusted every 2016 blocks and that worked very well. Nowadays we have large pools that hop in and out so Dr. Kimoto figured out that the diff. had the be adjusted faster. This also opened several expoits because it was a breach in the security.
So to cope with the blocktime the diff system does not function anymore as a sole solution. I suggested a solution to this by rejecting the first N seconds of blocks but that was shot because the word reject triggers negative emotions. But is it so different from what we know? In my opinion not. The system is designed to supply 1 coin every 150 seconds, so as long as thats the case every method works and has the same effect. The network also does not have a discriminator and everybody is able to submit his hash. So lets take it to the extreme and reject submitted blocks for 149.99 seconds. the first miner that submits a block gets the coins. That a very honest and social system were jumppools have the same chance as small miners. Problem with this system is you can't guarantee the blocktime because at low hashpower it can take some time to find a hash. But maybe it's doable. Second problem is the current systems security is build around blockmass (this is the effort put in a range of blocks measured by an addition of the diff). So to keep that in place we need the difficulty to identify how much effort was put in this chain. A combination of the two gives a system where it is not possible to submit blocks for lets say 75 seconds and the diff. adjusts the remainder that way blocks are found in an average of 150 seconds. You can still rape it, but the effect is much less than with a diff only. A large pool can get 90% of the blocks and mine in advance, but thats also possible in the currect system and thus another problem. You can even think of a system where you slowly (this must be because the diff has to follow) increase the blocking time in case of a hopper.
Is this reject system a disadvantage for the miner, no because everybody has an equal chance to find blocks within the possible submit window. The hoppers however have to adjust their method because they can't rape the coin and mine 20 blocks in a minute and dispear leaving the pieces for the community. So that only is probably enough to get the hoppers off our back. But even if they adjust their system they face a coin that has a profitwise disadvange over others so the chance of getting hit is deminishing.
I'm sure there are flaws and exploits, but to solve the problems we are facing and especialy gona face the next six months, it's important to leave the paved roads and think out of the box. In that light I am a huge fan of the BTM solution because it effectively eliminates the short term miners and pools.
