At first there are more than two solutions so there is some preselection done.
Readjustments wont work, there is no clever way, because they always come late. How smart you design the algo when it rises and the hashrate drops dramaticaly your stuck with a high diff. Nothing can be done about that. Thats why Sathoshi took a lot of blocks to calculate the diff anyway... If you want to act fast, rejection is the only way so that would have a chance but probably other problems. Another way more elegant would be lowering the diff midstream but that would be a huge change in protocol.
Blocktime based reward looks promising to me but don't put a limit on either side. The coin is designed for 1000 NLG every 150 secs avg. So putting a limit on hard blocks would decrease the supply and those hard blocks are compensated with fast low reward blocks anyway. It also would be an incentive for miners to stay at high diff because the jackpot is rising.
Readjustments wont work, there is no clever way, because they always come late. How smart you design the algo when it rises and the hashrate drops dramaticaly your stuck with a high diff. Nothing can be done about that. Thats why Sathoshi took a lot of blocks to calculate the diff anyway... If you want to act fast, rejection is the only way so that would have a chance but probably other problems. Another way more elegant would be lowering the diff midstream but that would be a huge change in protocol.
Blocktime based reward looks promising to me but don't put a limit on either side. The coin is designed for 1000 NLG every 150 secs avg. So putting a limit on hard blocks would decrease the supply and those hard blocks are compensated with fast low reward blocks anyway. It also would be an incentive for miners to stay at high diff because the jackpot is rising.
I'm with thsminer on this one. Block limits would be an effective approach. Setting a limit on the number of blocks that can be mined in X amount of time would throw the high hashing multis of the chain.
The BTM solution is probably the easiest change to the code and coin. I'm pretty sure that would literally be one line of code. As far as the drawback mentioned earlier with getting stuck with periods where the hoppers drop, I don't think it would be an issue. You're not changing the difficulty scheme, so the coin should essentially work the way it worked before. It just takes longer for the block to mature. That increase in time may be enough to keep the multis off the chain, and keep the chain running smooth.
As far as the coin reduction per block, I'm not sure I'm all on board with that. What happens when the difficulty drops, and a small pool like mine pegs a block, and then gets lucky with another block almost immediately. Reducing the block reward vs time would essentially take away the benefit of being lucky, wouldn't it? I guess I would need to see the algorithm to make an educated decision, but in my mind I don't think it would be an ideal fix.
Either BTM or block rejection. BTM would be an easier implementation. Block rejection would be a more aggressive/effective fix.
-Fuse
