[RFC] Continuous block reward decrease

[Pieter Wuille]

One question that often arises is what will happen when the block reward goes from 50 BTC to 25 BTC. I assume that after some temporary disturbances, a new mining equilibrium will be reached. I'm not sure what those disturbances will be though, or whether they are beneficial to bitcoin as a whole.

Here is a wild proposal: after block 209999, we replace the block reward function with an approximated exponential, such that the reward in 210000 is still close to 50 BTC, and sum of all rewards ever still tends to (and doesn't reach) 21M BTC.

Since we keep a higher reward (near 50 BTC) for longer, this will need to be compensated later. This results in a somewhat faster convergence towards 21M, with a halving of the reward every 145561 blocks (instead of 210000).

Here is a C function that computes rewards whose sum reaches 20999999.99999336 at block 4899870 (the current system reaches 20999999.9769 at block 6929999). It only uses 64-bit integer arithmetic and is quite fast.

Code:

static const int64_t coef[11]=
    { 419991,  630002,  840000, 1050003,
     1260003, 1470003, 1680004, 1890005,
     2100005, 2310005, 2520006};

uint64_t reward(int blocknum) {
    int64_t ret = 5000000000ULL;
    if (blocknum<210000) return ret;
    blocknum -= 210000;
    int shift = blocknum/145561;
    blocknum %= 145561;
    int64_t m = (blocknum*2380982516ULL)/100000;
    ret -= m;
    for (int i=0; i<11; i++) {
        m = (-m*blocknum)/coef[i];
        if (!m) break;
        ret -= m;
    }
    return (ret>>shift);
}

The resulting reward is shown here:


The resulting distance from the target amount in circulation (21M BTC) is shown here:

With some tuning I'm sure it's possible to have it go to its final value somewhat smoother.

So, questions:
* Do you think a continuous decrease of the block reward is better?
* Is it worth breaking backward compatibility for?
* Does anyone know a nicer function than A*exp(B*x) that could be fitted to better match the existing reward?

[xf2_org]

So, questions:
* Do you think a continuous decrease of the block reward is better?
* Is it worth breaking backward compatibility for?
* Does anyone know a nicer function than A*exp(B*x) that could be fitted to better match the existing reward?

It's an interesting question, but I think you answered your own proposal IMO:  it does not seem to be worth breaking compatibility, without some strong, concrete drivers of such a fundamental change (covered in satoshi's bitcoin.pdf, etc.)

[stillfire]

This strikes me as elegant. Good idea. Pity it wasn't part of the original protocol - not sure if it seems worth it to try to change something like this late in the game without clear indication that the coming disruption will really be, ehr, disruptive.

[ByteCoin]

Great post! Research done, code posted, graphs comparing two schemes. [ + ]

It seems clear to me that your scheme is vastly superior to the current scheme. Just imagine if your scheme was the one implemented from the start. Anyone proposing a change to the current situation would be ridiculed.

Your scheme is superior as it doesn't subject the bitcoin economy to a sudden shock. I believe the collective anxiety in advance of the change (to 25BTC) will be the cause of much more wasted effort than any adverse effects of the change. Your scheme avoids both the anxiety and any adverse effects.

I doubt that a nicer function than the one you chose can be found. What qualities would it have to enjoy for it to be superior?

I think it's a very good candidate for being included in any future breaking-change releases.

If it was implemented as you have shown, could you print out how the block values would decay for a few of the immediately following blocks please?

ByteCoin

PS. I predict that people will complain that the areas under the graphs for the current scheme and the new scheme do not look equal.

[Gavin Andresen]

So, questions:
* Do you think a continuous decrease of the block reward is better?
* Is it worth breaking backward compatibility for?

No and no, in my opinion.

I think being able to explain the block reward as "starts at 50 every 10 minutes and is cut in half every 4 years" is a big advantage.  I like simple-- "the simplest possible solution that will work" is a good engineering rule of thumb.

[theymos]

Does your algorithm easily handle increases in precision like the current system does?

I don't like that the end state would be changed. People signed up for particular rules. The end total BTC is very similar, but 132 years -> 93 years is significant.

[gigabytecoin]

So, questions:
* Do you think a continuous decrease of the block reward is better?
* Is it worth breaking backward compatibility for?

No and no, in my opinion.

I think being able to explain the block reward as "starts at 50 every 10 minutes and is cut in half every 4 years" is a big advantage.  I like simple-- "the simplest possible solution that will work" is a good engineering rule of thumb.

Although I do agree that simple is best for giving speeches and talking to the general public, you could just as easily have said "starts at 50 every 10 minutes and decreases gradually until all 21 million are distributed".

I had just mentioned this in another similar thread as well so I will re-post it here too:

What if the bitcoin reward drop turns out to be a horrible thing for the markets? People could potentially be scared off of bitcoin every few years and it could kill the project.

[Mike Hearn]

Yeah, I don't think it's so much harder to explain.

The concern over the transition is that there will be a sudden fall in network security as miners drop out, which would shake confidence in the system. But I'm not sure a slow steady decline can ever be achieved. The 50->25 transition is going to feel a bit like a bubble bursting, and that's OK. There will be sudden drops in hash power due to exchange rate bubbles over time even if the general trend is positive. So we'll have to handle wild fluctuations in difficulty anyway as BTC/USD moves in response to external events.

We also want to avoid a situation in which people feel any drop in difficulty is The End of Bitcoin. Ever since the 'tx equilibrium' thread I've been more convinced that the eventual network difficulty post-inflation will be not so far different to what it is now. It might even be lower. The current cost of reversing a tx is very high, much higher than most peoples threat model would require. By 2012 it's likely to be astronomical, given current growth trends.

Transaction reversal is not the end of the world as the current credit-card based system shows. I suspect many Bitcoin transactions in future will be free and could stay in the memory pool for weeks or months, until a high-fee tx that depends on it shows up. For many people "voting by IP address" will be enough. For others they may not even broadcast at all, and rely purely on interpersonal trust to avoid double spends.

[marcus_of_augustus]

Kind of nice mathematically how it is .... being a special case of Jakob Bernoulli's summation of infinite geometric series formula

a + ar + ar² + ar³ + ... + ar^k + ... = a/(1-r)

where a = 10.5 million btc and r = 1/2

The first jump from 50 to 25 is going to be the most disruptive, relatively speaking.

Could see as it the final system test, survive that and you can survive anything.

(Gonna be one hell of party on 1/3/13 if its still rocking on up this growth curve.)

[Cdecker]

Great proposal, I wish many would be so elaborate

While I too don't like the sudden halving of the reward it is a pretty nice and simple algorithm. What is especially nice about it is that the reward from the coinbase (generated coins) never really reaches 0, so miners will not have to rely completely on fees.

[ribuck]

"The perfect is the enemy of the good".

There are some parts of Bitcoin that are not everyone's idea of perfect. And yet, those things are part of what Bitcoin is. The cost of fiddling around with those things is very high, and the benefit is low (even if you think the current design is suboptimal) to zero (if you don't think there's a problem).

At the same time, there are real, substantial problems that are far more deserving of people's energy. Such as: how can non-technical Bitcoin users keep their wallet safe?

[Pieter Wuille]

PS. I predict that people will complain that the areas under the graphs for the current scheme and the new scheme do not look equal.

The areas will be equal on a graph with a linear scale.

Does your algorithm easily handle increases in precision like the current system does?

It is quite specifically tuned for 64-bit integer arithmetic to reach 21M. Nothing of course prevents one from introducing a new algorithm at the time a precision increase is introduced as well, along the lines of "if (blocknum < 3000000) { ...; ret *= 100000000; } else { ... }". The construction of the algorithm can be more or less automated once the function to match is known.

I don't like that the end state would be changed. People signed up for particular rules. The end total BTC is very similar, but 132 years -> 93 years is significant.

Good point. I've tried finding a different function that mimicks the end behaviour better, but it's quite hard, and probably not worth it anyway.

The concern over the transition is that there will be a sudden fall in network security as miners drop out, which would shake confidence in the system. But I'm not sure a slow steady decline can ever be achieved. The 50->25 transition is going to feel a bit like a bubble bursting, and that's OK. There will be sudden drops in hash power due to exchange rate bubbles over time even if the general trend is positive. So we'll have to handle wild fluctuations in difficulty anyway as BTC/USD moves in response to external events.

You're probably right. I wanted to show that it is quite possible to implement a nice exponential decrease, and somehow show my regret it wasn't in the original system.

While I too don't like the sudden halving of the reward it is a pretty nice and simple algorithm. What is especially nice about it is that the reward from the coinbase (generated coins) never really reaches 0, so miners will not have to rely completely on fees.

Given the limited divisibility of bitcoin, this is not entirely true. In the current scheme, the reward becomes 0 after block 6929999. In my proposed scheme, it becomes 0 after block 4899870.

"The perfect is the enemy of the good".

Indeed, but sometimes it's hard to see in advance whether it's good enough or not.

[marcus_of_augustus]

Great proposal, I wish many would be so elaborate

While I too don't like the sudden halving of the reward it is a pretty nice and simple algorithm. What is especially nice about it is that the reward from the coinbase (generated coins) never really reaches 0, so miners will not have to rely completely on fees.

Not entirely correct. At some point, block reward will drop below 1e-9 btc ... i.e. below current resolution of the currency. At around k = 36 , in the formula above, i.e. in 144 years.

[Mike Hearn]

You're probably right. I wanted to show that it is quite possible to implement a nice exponential decrease, and somehow show my regret it wasn't in the original system.

Yes, I agree it'd have been nice to have. Along with a different serialization format etc :-)

It's worth exploring these ideas. It's possible that BitCoin will not become the worlds next super-currency and fail, but if so, it will certainly pave the way for future efforts. So coming up with ways to improve upon it are worth doing even if they aren't incorporated.

[ByteCoin]

Under this scheme the block reward drops from       50 by 0.01 every 7 hours.
After about half a year the block reward drops from 44 by 0.01 every 8 hours.
Half a year after that the block reward drops from   39 by 0.01 every 9 hours.
About 5 months after that the reward  drops from   35 by 0.01 every 10 hours.
Four months after that the block reward drops from 32 by 0.01 every 11 hours.

ByteCoin

[sunray]

Thanks for this proposal.  I was the one who started the recent similar thread asking why Satoshi didn't use a continuous reward decline in the first place.

So, questions:
* Do you think a continuous decrease of the block reward is better?

Probably it would be if we were starting over.  I personally think the Bitcoin economy will be robust enough to survive the reward decrease, but it will be an interesting and perhaps slightly scary moment.  In general I think that Bitcoin will be volatile enough already without shocks to the system like this one.

On the other hand, one advantage to the current scheme is that everything stays constant for 4 years at a time.  Once the reward transition happens, miners will know that the reward (relative to difficulty) won't change for 4 years, which may help their long-term planning and bring in 4 more years of stability.

* Is it worth breaking backward compatibility for?

No.  In the absence of any devastating flaws, I think we should remain true to the model that Satoshi proposed.  Everyone has been aware of that model all along, after all, and has planned their investments based on it.  As long as at least one block chain remanis true to that model, it will have a legitimacy above all others which will encourage the community to stay unified.  If you don't like this model, you're free to start again with your own block chain. 

[Pieter Wuille]

If you don't like this model, you're free to start again with your own block chain. 

Don't worry, I have no such intention

[Hal]

I don't like that the end state would be changed. People signed up for particular rules. The end total BTC is very similar, but 132 years -> 93 years is significant.

I agree, we should be very conservative about this part of Bitcoin. It is the foundation of value for the whole system.

[FreeMoney]

I think gradual decay would have been better, but not anywhere near enough for a change now. The only benefit the current system has is a slight easy of explaining to a noob, but if you are explaining the technical details of Bitcoin to someone who can't handle a little decay then you are doing it wrong.

[genjix]

Instead of having the reward half every 210k blocks,

I wouldn't have it drop by 1/4 every 105k blocks.
Nor would I have it drop by 1/8 every 52k blocks.
Nor drop by 1/16 every 26k blocks.
But drop by 1/32 every 13k blocks.

Seems much easier/closer to the current scheme than an approximated exponential.