Author

Topic: Continuous & piecewise linear block reward function with 21M limit unchanged (Read 1282 times)

legendary
Activity: 4228
Merit: 1313
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.

:-)


legendary
Activity: 1484
Merit: 1005
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.  Tongue
legendary
Activity: 1232
Merit: 1094
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.
donator
Activity: 1218
Merit: 1079
Gerald Davis
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.
legendary
Activity: 4228
Merit: 1313
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.  
legendary
Activity: 1232
Merit: 1094
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.
jr. member
Activity: 55
Merit: 2
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 Smiley ?

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)
legendary
Activity: 1232
Merit: 1094
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 Smiley ?

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;
}
legendary
Activity: 1484
Merit: 1005
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
legendary
Activity: 1876
Merit: 1475
It is always nice to have code, but the odds of it happening in are essentially zero. :-)

Something similar is being discussed here:
https://bitcointalksearch.org/topic/re-changing-the-block-reward-reduction-to-happen-per-block-rather-than-one-day-984958

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.
jr. member
Activity: 55
Merit: 2
It is always nice to have code, but the odds of it happening in are essentially zero. :-)

Something similar is being discussed here:
https://bitcointalksearch.org/topic/re-changing-the-block-reward-reduction-to-happen-per-block-rather-than-one-day-984958

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).
legendary
Activity: 4228
Merit: 1313
It is always nice to have code, but the odds of it happening in are essentially zero. :-)

Something similar is being discussed here:
https://bitcointalksearch.org/topic/re-changing-the-block-reward-reduction-to-happen-per-block-rather-than-one-day-984958

Which may have been what prompted the code - or coincidence.
jr. member
Activity: 55
Merit: 2
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
jr. member
Activity: 55
Merit: 2
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;
}
Jump to: