Fighting against pulse mining part 3...

in #mining5 years ago (edited)

It's been a while since I posted my thoughts about how coins can fight against miners that have such high hashing power that they can push the difficulty too high that when they leave, other miners will need a lot more time than the target time to solve the next block.

My third solution is basically two-tiered.

First, the block reward must be as low as possible, but at the same time the hashing algorithm must be as light as possible. This is because powerful mining hardware depend on using all the potential hashing power for most of the time and when the target time is too short, more time is spent on sending the hashes instead of solving them. If they use a mining pool, there is big chance that the solved hashes arrive too late as usually only last 3 block templates are preserved. The mining pool must also support flood protection and have it enabled immediately after miner logs in to combat against miners using either static difficulty or port with too low initial difficulty.

Second, the target time must be variable, instead of static, so people with average hashing power will have chance to solve some shares before pulse miners can collect all the rewards. This is because pool rewards are calculated proportionally to the number of submitted hashes.

Using variable target time will cause average block difficulty to be considerably lower than with static target time as target time depends on number of transactions waiting on transaction pool, as explained in my previous post. With individual mining pools, it is possible to adjust the solve time by adjusting payment interval. Payment interval should be at most the target time when there is constant supply of new transactions, but it should be higher if hashing power of that pool is more than third of the combined hashing power of all mining pools.

In ideal environment, actual solve time will be at most twice the target time, but on low network utilization, it can be up to 10 times the target time without network getting permanently stalled.