I think your ideas would change the coin too drastically to predict how miners or the market would react to it. You're introducing all different kinds of assumptions and reactions to those assumptions, and I have absolutely no way of knowing what kind of effect that would have on the coin.
We don't want the difficulty to explode. That's what happened with the original catcoin. It climbed so high that we couldn't get over the next difficulty level, and as profitability dropped so did the hashrate.
Now, if you wanted to simplify your idea, you could allow the difficulty to increase quickly when the difficulty goes up, but slowly when the difficulty comes down. To do that all you need to do is put a small percentage cap on difficulty decreases, but allow the difficulty to increase without any imposed limit.
You can't both make the coin difficulty stable and also highly reactive. It's a contradiction in terms. You can find a compromise somewhere in the middle, but trying to impose both makes the coin wildly unpredictable.
I agree with you that potentially revolutionary ideas should not be implemented without full vetting. I have proposed that code be written not to implement the idea in a hard fork, but merely passively log what kind of effects it would have if it were to be implemented. Then people can look at the data and debate based on real data rather than just hypothetical data.
However, I think you may not have got the essence of what I was saying about capping. We want the coin to be "highly reactive" and respond to changes in hash rate, because there are legitimate reasons for hash rates to change, and the difficulty should have little constraint to adjusting when those circumstances occur. However, when a fast downward adjustment happens (more than 50% reduction in one difficulty cycle), we know a lot of miners just left, and all those who left, we can safely surmise, were not high on their commitment level to the coin. Therefore, it is also easy to surmise, that while we should continue to pay miners who remained the full amount of reward, any new miners that show up are not likely to be loyal and can therefore have their pay cut without any significant consequence to the coin network. We can also surmise that if we lost a bunch of miners recently due to lack of belief in the coin, there is probably no real need for the difficulty level to go up in terms of meeting demand for people who want to mine the coin. The only real reason there might be for increasing difficulty is purely economic - we don't want too much inflation in the coin. But by cutting the coin award of those who show up during the exceptionally easy period, we have eliminated the inflation factor (they get paid at the same rate per hash contributed as when it at the difficulty level before the crash in difficulty). So we can afford to have an extended period of easy difficulty combined with penny pinching on the rewards. If the demand to mine continues to increase despite that, then difficulty will recover to pre-crash state sooner or later, and at that point, we can go back to normal operating basis.
You mention something about putting caps on difficulty decrease, but not on increases. With all due respect, this makes no sense. It is true that there is no inherent problem when a bunch of new miners show up - It's a happy thing - we notice blocks are being solved every 30 seconds - and we also don't want hyperinflation - so we want to adjust the difficulty up quickly. Maybe the coin suddenly became popular and is trading for lots of money and adjusting the difficulty up quickly is a good thing as lots of new hashing power shows up. High difficulty is never a problem. The problem is, when the miners contributing the hashes are not stable people. We only know that
after they have left. We know they have left, when we notice that block solutions are coming vvvvvveeeeeeeeeeeeeerrrrrrrrrrrrrrry slooooooooooooowly. So we found out that a lot of the hashing power has abandoned us. What do we do now? Put constraints on how quickly we get back to mining a block every 10 minutes???
NO!. We want the blocks to start coming every 10 minutes ASAP. We don't want to hear "20% adjustment constraint" when we are seeing 100 minute block times and increasing. No, we want the block time to return to 10 minutes
immediately. Did we already forget what it was like during the difficulty=172 period?
However, once we have reached this point, (rising difficulty followed by crash in difficulty), we have a special circumstance. It
does make sense to
temporarily (and only temporarily) cap increase in difficulty and simultaneously, impose pay cuts on those who show up to mine, until difficulty has recovered to pre-difficulty-crash number.
If you think there is a scenario which can describe with these rules to cause any of the known evils 1) excessively long block times that go on and on, 2) instability/oscillation in difficulty, 3) instability/oscillation of network hashrates, 4) extended periods of hyperinflation of coins, or 5) there being incentives to do anything other than just sit and mine consistently over a long duration to maximize profit - please describe that scenario. The loyalty credit system is specifically designed with these five factors in mind - but it is possible there are scenarios that it does not cover - I may have overlooked something - if you can think of such a scenario please describe it...
Thank you,
Etblvu1