Andrew Karamaoun proposed an idea to discourage selfish mining, which is to allow the block reward get determined by the peak hash rate.

For instance if \(p\) is the peak hash rate for 365 periods or 1 year, made up of 144 blocks, \(h\) the hash rate of the last 144 blocks (1 day period), and \(r\) the base subsidy or reward for mining a block, which is currently 12.5 bitcoin, the maximum block reward can then be calculated using the formula \(0.5r (1 + h/p)\) , the lowest possible block reward being \(0.5r\) . At peak hashrate, the miner gets the full 12.5 BTC reward, otherwise the reward is determined based on the hashrate.

This will discourage miners from mining at lower hashrates since they can only get the full reward at low hashrate for the first 144 blocks after which they will not get the full reward for mining a block at the same rate. This may not sound right since “mining was way easier for early miners” so the difficulty algorithm may have to be modified.

Fees will be the only incentive for miners in the future. At that time, part of the fees can be withheld if the peak rate is not reached, known as the concept of reserve fees.

This concept suggests that in the future when a transaction is made, the user can specify the percentage of the fees they want to be held in the “reserve” and for how long, say 2016 blocks. The “reserve fees” will be paid to miners when their hashrates increase.

Again assuming the current hashrate is \(h\) and the peak hashrate for the previous year is \(p\) , then for each period (1 day), a new hashrate \(h1\) is calculated based on the day’s hashrate. If \(h1>h\) , a portion \((h1 - h)/p\) of the “reserve fees” created in the last 2016 blocks is given to the miners, spread out over the 144 blocks of that period.

More reserve fees will be released based on hashrate until the mining “contract is over” and the user who owns the reserve fees can then only use it for payment of fees on the network subsequently but not as inputs to future transactions.

This will discourage miners from “driving out” competition as the amount of “reserve fees” they get as payment will depend on their hashrate.

A notable feedback from Zawy is that there is a problem with this calculation which is “a positive feedback loop that amplifies oscillations.” If net reward goes up or down with h due to price changes or “random solvetime variation”, miners will make h to go up of course to get higher net reward until they reach a limit. This is a positive feedback loop.

Even worse, miners’ choice of which coin to mine is, which is motivated by profit, is a “non-linear” function: if there is 30% drop in difficulty or 30% increase in the reward for mining an altcoin for instance, it could lead to a 300% rise in hashrate. Typically a selfish mine of 72 blocks out of 144 past blocks only results in 12.5% loss, much worse if the above function is used.

Alternatively, the difficulty should be increased with a similar function instead of a reward since it makes no difference to miners who are only interested in \((price + fees) / difficulty\) ratio.

Zawy concludes:

The problem has been solved to the best of our ability by the Nakamoto consensus. The math is straightforward, so you can’t get around it’s failings unless it’s a profound solution or we shift trust to some place else. Currently we have to choose and trust a small group of coins (or 1) to be the best choice(s), and to trust that the reward plus fees we pay for mining (compared to coin value) is enough to prevent a 51% attack.

Resources:

• Discussion
• Bitcointalk Thread
• Taming large miners with Helper Blocks