[bitcoin-dev] Hardfork to fix difficulty drop algorithm

Tier Nolan tier.nolan at gmail.com
Wed Mar 2 15:54:15 UTC 2016


If a hard-fork is being considered, the easiest is to just step the
difficulty down by a factor of 2 when the adjustment happens.

This means that miners still get paid the same minting fee per hash as
before.  There isn't that much risk.  If the hashing power stays constant,
then there will be 5 minute blocks for a while until everything readjusts.

Nearly the same can be accomplished by a soft fork.

Proposal:

If 900 of the last 1000 blocks are block version X or above, then the
smooth change rule applies.

The adjustment is as follows

big_number get_new_target(int height, big_number old_target) {
    if (height < 405000)
        return old_target;
    else if (height < 420000)
        return (old_target * 15000) / (height - 390000);
    else
        return old_target;
}

What this does is ramp up the difficulty slowly from 405,000 to 420,000.
It ends up with a target that is 50% of the value stored in target bits.
These blocks are valid since they have twice as much POW as normally
required.

For block 420000, the difficulty drops by 2 and the reward drops by 2 at
the same time.  This means that miners still get paid the same BTC per
hash.  It would mean 5 minute blocks until the next adjustment though.

If 90% of the network are mining the artificially hard blocks, then a  10%
fork still loses.  The 90% has an effective hash rate of 45% vs the 10%.

It is unlikely that miners would accept the fork, since they lose minting
fees.  It effectively brings the subsidy reduction forward in time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160302/4394958d/attachment-0001.html>


More information about the bitcoin-dev mailing list