Continuous & piecewise linear block reward function with 21M limit unchanged

[uminatsu]

It is well known that the bitcoin block reward (as a function of the block number) is not continuous - a discontinuity ("halving") occurs every 210,000 blocks or roughly 4 years, as illustrated in the bitcoin source code:

Code:

CAmount GetBlockValue(int nHeight, const CAmount& nFees)
{
    CAmount nSubsidy = 50 * COIN;
    int halvings = nHeight / Params().SubsidyHalvingInterval();

    // Force block reward to zero when right shift is undefined.
    if (halvings >= 64)
        return nFees;

    // Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
    nSubsidy >>= halvings;

    return nSubsidy + nFees;
}

IMHO the halvings are disruptive events and negatively affects everyone.

It isn't difficult to change the above code to make the block reward function continuous and piecewise linear while keeping the total limit of 21 million BTC unchanged. This would eliminate the discontinuity events in the future.

Proposed function is:

Code:

CAmount GetBlockValue(int nHeight, const CAmount& nFees)
{
    CAmount nSubsidy = 50 * COIN;
    int halvingInterval = Params().SubsidyHalvingInterval();
    int halvings = nHeight / halvingInterval;
    int phase = nHeight % halvingInterval;
    
    // Force block reward to zero when right shift is undefined.
    if (halvings >= 64)
        return nFees;

    // Subsidy is a continuous and piecewise linear function that halves every 210,000 blocks
    // which will occur approximately every 4 years.
    nSubsidy = (nSubsidy * (4 * halvingInterval - 2 * phase)) / (3 * halvingInterval);
    nSubsidy >>= halvings;

    return nSubsidy + nFees;
}

[uminatsu]

Simulation shows that starting from block 6,930,000 both reward functions return 0.

Original sum of block rewards = 20,999,999.97690000 BTC
Proposed sum of block rewards = 21,000,033.29639948 BTC

[cr1776]

It is always nice to have code, but the odds of it happening in are essentially zero. :-)

Something similar is being discussed here:
https://bitcointalk.org/index.php?topic=984958.0

Which may have been what prompted the code - or coincidence.

[uminatsu]

It is always nice to have code, but the odds of it happening in are essentially zero. :-)

Something similar is being discussed here:
https://bitcointalk.org/index.php?topic=984958.0

Which may have been what prompted the code - or coincidence.

I agree it is a hard fork but this transition is something that can be planned to happen many years in the future (for example when the 3rd halving occurs at block 690,000 or around year 2020).

[EcuaMobi]

It is always nice to have code, but the odds of it happening in are essentially zero. :-)

Something similar is being discussed here:
https://bitcointalk.org/index.php?topic=984958.0

Which may have been what prompted the code - or coincidence.

I agree it is a hard fork but this transition is something that can be planned to happen many years in the future (for example when the 3rd halving occurs at block 690,000 or around year 2020).

I don't think implementing this in Bitcoin has any real chance of happening.
Do you know if this or something similar is implemented on any alt-coin? It'd be worth checking the result.

[tacotime]

The linear interpolation of the Bitcoin subsidy function is already used in SpreadCoin (and others).

Code:

int64 GetBlockValue(int nHeight, int64 nFees)
{
    int64_t nSubsidy = 50 * COIN * 4 / 3;
    if (nHeight > (int)getFirstHardforkBlock())
        nSubsidy /= 10;

    // Subsidy is cut in half every g_RewardHalvingPeriod blocks which will occur approximately every 4 years.
    int halvings = nHeight / g_RewardHalvingPeriod;
    nSubsidy = (halvings >= 64)? 0 : (nSubsidy >> halvings);
    nSubsidy -= nSubsidy*(nHeight % g_RewardHalvingPeriod)/(2*g_RewardHalvingPeriod);

    return nSubsidy + nFees;
}

https://github.com/spreadcoin-project/spreadcoin/blob/b05777db815d633a76aba5ef55ecb85390a4df7e/src/main.cpp#L1340-L1352

[TierNolan]

Original sum of block rewards = 20,999,999.97690000 BTC
Proposed sum of block rewards = 21,000,033.29639948 BTC

So, a way to add 0.000159% inflation in a sneaky way ?

A soft fork could accomplish this by reducing the minting fee.  Miners don't have an incentive to support that though.

The effect would be to reduce the total number of coins.

The suggested function always gives a minting fee that is less than or equal to the current rule.  This makes things a soft fork.

Starting when it drops from 12.5 to 6.75, the minting fee drop becomes linear.

This has a deflationary effect and would increase the value of current bitcoin holdings, assuming no loss of security.

Code:

CAmount GetBlockValue(int nHeight, const CAmount& nFees)
{
    CAmount nSubsidy = 50 * COIN;
    int halvingInterval = Params().SubsidyHalvingInterval();
    int halvings = nHeight / halvingInterval;
    
    // Force block reward to zero when right shift is undefined.
    if (halvings >= 64)
        return nFees;

    if (halvings < 3)
    {
        // Use current rule for first 3 halvings (50, 25, 12.5)

        // Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
        nSubsidy >>= halvings;
    }
    else
    {
        // Use new rule for mint (6.75 and after)
  
        int phase = nHeight % halvingInterval;

        // Subsidy is a continuous and piecewise linear function that halves every 210,000 blocks

        // The subsidy is always less than or equal to the old rule
        nSubsidy = (nSubsidy * (2 * halvingInterval - phase)) / (2 * halvingInterval);
        nSubsidy >>= halvings;
    }
    return nSubsidy + nFees;
}

[uminatsu]

Original sum of block rewards = 20,999,999.97690000 BTC
Proposed sum of block rewards = 21,000,033.29639948 BTC

So, a way to add 0.000159% inflation in a sneaky way ?

The 0.000159% is an unfortunate rounding error and is definitely unintended. But it shouldn't be hard to tweak the parameters to get to the exact number (or something within +/- a few thousand satoshis)

[TierNolan]

The 0.000159% is an unfortunate rounding error and is definitely unintended.

Yeah, I realised, was just joking.  Having said that, if it was being implemented, it wouldn't surprise me if someone objected.  You would no longer be able to say that the max number of Bitcoins is less than 21 million.

Handling things as a soft fork has interest incentives.  It benefits those who hold coins already, but means that miners would be accepting lower payouts.  If miners are mainly mining and selling their Bitcoins, then they have little incentive to agree.  Many miners probably have some bitcoins saved, so it might work.

[cr1776]

The 0.000159% is an unfortunate rounding error and is definitely unintended.

Yeah, I realised, was just joking.  Having said that, if it was being implemented, it wouldn't surprise me if someone objected.  You would no longer be able to say that the max number of Bitcoins is less than 27* million.

Handling things as a soft fork has interest incentives.  It benefits those who hold coins already, but means that miners would be accepting lower payouts.  If miners are mainly mining and selling their Bitcoins, then they have little incentive to agree.  Many miners probably have some bitcoins saved, so it might work.

*21    ;-)

As you said, miners can always accept a smaller fee, but (as you said as one alternative) I don't think the incentive to take a smaller fee now to potentially slightly increase the value of their hypothetical holdings sooner is there.  

[DeathAndTaxes]

Well you are never going to convince miners that they should take a voluntarily paycut to avoid 'disruptions' which may or may not happen in the future.  Any attempt to change the subsidy curve will realistically not happen.  Personally I think a lot of the 'end game' uncertainty in Bitcoin fees and security could be mitigated with a low but fixed inflation but that isn't going to happen either.  Just because any change is technically possible it doesn't mean it is realistically possible.

For completeness your code should indicate the starting point (similar to post #7) as I believe it returns a subsidy higher than 25 BTC for blocks in the existing era.  Since this will probably not happen for an existing chain I am curious what would be the simplest subsidy function that returns a 'smooth' curve from block 0.

[TierNolan]

As you said, miners can always accept a smaller fee, but (as you said as one alternative) I don't think the incentive to take a smaller fee now to potentially slightly increase the value of their hypothetical holdings sooner is there.  

A soft fork which changes what the rules will be in 5 years time is more likely to be accepted.  Once it is accepted, then it becomes a network rule.

Miners in 5 years who violate the rule risk getting their blocks rejected.  This is especially true if the reference client rejects them.

[tacotime]

Well you are never going to convince miners that they should take a voluntarily paycut to avoid 'disruptions' which may or may not happen in the future.  Any attempt to change the subsidy curve will realistically not happen.  Personally I think a lot of the 'end game' uncertainty in Bitcoin fees and security could be mitigated with a low but fixed inflation but that isn't going to happen either.  Just because any change is technically possible it doesn't mean it is realistically possible.

For completeness your code should indicate the starting point (similar to post #7) as I believe it returns a subsidy higher than 25 BTC for blocks in the existing era.  Since this will probably not happen for an existing chain I am curious what would be the simplest subsidy function that returns a 'smooth' curve from block 0.

Well, it's always there in Monero (~1% annual starting in year 10) if it's desirable. 

[cr1776]

As you said, miners can always accept a smaller fee, but (as you said as one alternative) I don't think the incentive to take a smaller fee now to potentially slightly increase the value of their hypothetical holdings sooner is there.  

A soft fork which changes what the rules will be in 5 years time is more likely to be accepted.  Once it is accepted, then it becomes a network rule.

Miners in 5 years who violate the rule risk getting their blocks rejected.  This is especially true if the reference client rejects them.

Anything is possible, but I still think unlikely. 

Also 5 years would be roughly after two more halvings, so the block reward (12.5 in ~2016, 6.25 in ~2020) would mean the reward would be down significantly by then, so would not doubt have less push back from people mining then as compared to a 25 BTC reward if the BTC/$/Euro value is similar to now. If the value has skyrocketed in fiat terms, then you might get more pushback against the fork even then, but if 0.01 BTC is worth $2-$3...who knows.

I am just not convinced that changing to a semi-continuous function will matter much in terms of network security since the halving time is widely known and miners have planned for it.

:-)