BIP: ?? Gradual Changing Block Rewards

[kjj]

I wonder how much thought Satoshi gave this and what his main reason was. I think it was kind of a fairness thing. Whatever it was I think this decision more than most involved his guessing about how (time line etc) Bitcoin would be adopted.

Satoshi's choice of integer representation is obvious enough, but I think that the choice of right shift for the subsidy was deliberate too.  It is exact and unambiguous right down to the final unit.

[1714037503]

1714037503

[1714037503]

1714037503

[1714037503]

1714037503

[allten]

I wonder how much thought Satoshi gave this and what his main reason was. I think it was kind of a fairness thing. Whatever it was I think this decision more than most involved his guessing about how (time line etc) Bitcoin would be adopted.

Satoshi's choice of integer representation is obvious enough, but I think that the choice of right shift for the subsidy was deliberate too.  It is exact and unambiguous right down to the final unit.

Thanks for pointing this out. It may not be obvious to those with no experience in binary numbers.
In fact, I haven't even thought about it that way.
Is there any links available to how that code was "hashed" out among the developers?
It would sure be interesting to see what their discussions were when they finalized it.

There choice definitely makes for a very small piece of slick code to handle block rewards.
A right shift in the binary representation of the number 50 every 210000 blocks. Presto!
That tells me their decision was based almost entirely on getting it coded quick and keeping it simple - there were bigger fish to fry at the time.
And it was just an experiment... I don't think they really envisioned it would be where it is today. Kudos to them for their achievements.

This BIP does call for more complex code (but not impossible) for the rewards to be handled as proposed. I've tried to stay away from the details of code implementation in the BIP because it just opens another can of worms for everyone to argue over which seems pointless until it reaches mass consensus.
However, since you bring it up... do you have an idea how hard it would be for the average developer to come up with an implementation like this? Just curious.

My opinion, is it would only take a few days, but could get take longer if there's a difference of opinion between developers (i.e. BIP16 vs. BIP 17).

[kjj]

I wonder how much thought Satoshi gave this and what his main reason was. I think it was kind of a fairness thing. Whatever it was I think this decision more than most involved his guessing about how (time line etc) Bitcoin would be adopted.

Satoshi's choice of integer representation is obvious enough, but I think that the choice of right shift for the subsidy was deliberate too.  It is exact and unambiguous right down to the final unit.

Thanks for pointing this out. It may not be obvious to those with no experience in binary numbers.
In fact, I haven't even thought about it that way.
Is there any links available to how that code was "hashed" out among the developers?
It would sure be interesting to see what their discussions were when they finalized it.

There choice definitely makes for a very small piece of slick code to handle block rewards.
A right shift in the binary representation of the number 50 every 210000 blocks. Presto!
That tells me their decision was based almost entirely on getting it coded quick and keeping it simple - there were bigger fish to fry at the time.
And it was just an experiment... I don't think they really envisioned it would be where it is today. Kudos to them for their achievements.

Bitcoin uses a scaled integer representation.  The subsidy is 5,000,000,000 satoshis, or 1001010100000010111110010000000000 in binary.  We scale that by 100,000,000 when we show things to the user, and we call 100 million units to be 1 bitcoin.

Pay attention that this is not similar to fixed point.

The pre-scaled value (5 billion) is what gets shifted, not the post-scaled value (50.00000000).  In 33 years, the 9th shift will result in the subsidy being cut by slightly more than half for the first time.  (Or is it the 10th shift in 37 years?  Bah.  Not going to count the zeros again.)

Every binary machine will always get this subsidy calculation right, because right-shift-without-carry is one of the simplest operations in the binary world.  Every other scheme will have to figure out how to deal with inexact operations and rounding one way or another.

This BIP does call for more complex code (but not impossible) for the rewards to be handled as proposed. I've tried to stay away from the details of code implementation in the BIP because it just opens another can of worms for everyone to argue over which seems pointless until it reaches mass consensus.
However, since you bring it up... do you have an idea how hard it would be for the average developer to come up with an implementation like this? Just curious.

My opinion, is it would only take a few days, but could get take longer if there's a difference of opinion between developers (i.e. BIP16 vs. BIP 17).

Well, it can't be implemented at all, as written.  To implement it, someone would have to answer the questions that I asked back in post 38.  If you don't care how the rounding gets handled, then yeah, I should think a couple of days should suffice, if even that long.

Actually, shit.  I just realized something.  If the subsidy drops by 0.000031746 % on every block, before long, you are going to need to calculate something like .999999968254^200000, which is going to be painful.  But, I guess we could cheat by embedding the current subsidy in the block or something, so that each node only has to calculate the next subsidy.

[allten]

Bitcoin uses a scaled integer representation.  The subsidy is 5,000,000,000 satoshis, or 1001010100000010111110010000000000 in binary.  We scale that by 100,000,000 when we show things to the user, and we call 100 million units to be 1 bitcoin.

Thanks for the explanation.
It was quoted earlier what the exact maximum amount would be and I had wondered how they calculated it.

Every binary machine will always get this subsidy calculation right, because right-shift-without-carry is one of the simplest operations in the binary world.  Every other scheme will have to figure out how to deal with inexact operations and rounding one way or another.

You are absolutely right. Whatever "scheme" is chosen will need to be well defined so everyone gets the calculation right every time. This is where computer technology shines and shouldn't be an issue at all.

Well, it can't be implemented at all, as written.  To implement it, someone would have to answer the questions that I asked back in post 38 [I Posted your question below].  If you don't care how the rounding gets handled, then yeah, I should think a couple of days should suffice, if even that long.

By the way, how would this proposal deal with the integer representation?  The first step in the new system would be from 2500000000 to 2499992063.50.  Would this round up, or down?  When it gets down around 0.00315 BTC, the delta will be less than one unit.  How will this be handled?

As I stated earlier, I purposely left the details of implementation out of the BIP. First reason, was it would just give more things to argue over when the main part of the BIP was still under development. Second, the implementation I could devise may not be the "correct" one. I need experts to lend me a hand. If you are willing to entertain a coding implementation, we could start coming up with something. Doesn't mean you have to agree with the BIP, but it would help me with the initial mile stone of having it very well defined.

[allten]

So, Here's what I've dug up so far. Appears relevant to "hashing" out a precise coding implementation for the BIP:

Remember that a floating-point number can only approximate a decimal number, and that the precision of a floating-point number determines how accurately that number approximates a decimal number. By default, a Double value contains 15 decimal digits of precision, although a maximum of 17 digits is maintained internally. The precision of a floating-point number has several consequences:

Two floating-point numbers that appear equal for a particular precision might not compare equal because their least significant digits are different.

A mathematical or comparison operation that uses a floating-point number might not yield the same result if a decimal number is used because the floating-point number might not exactly approximate the decimal number.

A value might not roundtrip if a floating-point number is involved. A value is said to roundtrip if an operation converts an original floating-point number to another form, an inverse operation transforms the converted form back to a floating-point number, and the final floating-point number is equal to the original floating-point number. The roundtrip might fail because one or more least significant digits are lost or changed in a conversion.

In addition, the result of arithmetic and assignment operations with Double values may differ slightly by platform because of the loss of precision of the Double type. For example, the result of assigning a literal Double value may differ in the 32-bit and 64-bit versions of the .NET Framework. The following example illustrates this difference when the literal value -4.42330604244772E-305 and a variable whose value is -4.42330604244772E-305 are assigned to a Double variable. Note that the result of the Parse(String) method in this case does not suffer from a loss of precision.

http://www.gavaghan.org/blog/2007/11/06/c-decimal-and-java-bigdecimal-solve-roundoff-problems
       
I remember a class call "BigFloat" in Java. I believe to make the implementation successful, it will require floating point data types such as "decimal" (in MSDN" or "BigFloat" (in Java). I'm not sure how this is taken care of in other coding languages. This will be critical IMO to make sure everyone gets an exact block rewards every time.

As for rounding, it makes the most sense to round to the nearest satoshi (8 decimal places).

As I see it, there's two paths that we could go.
    1) Each block reward is calculated as a percentage decrease from the previous block.

    2) There could be a function that would return the block reward depending on the block number.

[blablahblah]

This BIP does call for more complex code (but not impossible) for the rewards to be handled as proposed. I've tried to stay away from the details of code implementation in the BIP because it just opens another can of worms for everyone to argue over which seems pointless until it reaches mass consensus.
However, since you bring it up... do you have an idea how hard it would be for the average developer to come up with an implementation like this? Just curious.

My opinion, is it would only take a few days, but could get take longer if there's a difference of opinion between developers (i.e. BIP16 vs. BIP 17).

Even though I'm no programming guru, I know that the terms what and how are generally interchangeable when coding. If you want to figure out how to do something, you need to be very precise about what you want to do. It seems almost dishonest to wait for broad consensus before revealing exactly what you want done. I've seen it happen IRL where a company marketing department wastes incredible amounts of money because they have more say about product development than the engineers do.

[SimonL]

I think it's a non-starter.  It's a solution in search of a problem.

I wouldn't waste your time, or the developers' time with this.  The time would be better spent petitioning US Congress to require all speed limit signs in the US to be readable at 100mph so that the worst speeders will know by just exactly how much they are speeding.

Can't help but agree with Mike, smoothing out the block rewards provides no real incentive for anyone but those with OCD. Long term this solves no problem, over time the reward drops will become less and less anyway. Only in the first and maybe second drop will there be any tangible benefit, and by the time any such proposal is implemented it will be pointless. Miners are not necessarily going to benefit from the steady decrease either. Miners want expected rewards for their efforts, splitting hairs on rewards is not what drew these miners to Bitcoin in the first place, they never signed up for it, so just the notion of steady reward drops could have a huge destabilization effect, and the block reward system is one of the single biggest incentives that drew miners to support Bitcoin in the first place. Whats more, incremental rewards drops that halve every 4 years is childs play to explain to those new to Bitcoin. Seriously how will you explain the system of rewards when it drops steadily as compared to just saying "The Bitcoin reward for each transaction block solved is halved every 4 years". You are introducing complexity and making a straw man.

[rjk]

This BIP does call for more complex code (but not impossible) for the rewards to be handled as proposed. I've tried to stay away from the details of code implementation in the BIP because it just opens another can of worms for everyone to argue over which seems pointless until it reaches mass consensus.
However, since you bring it up... do you have an idea how hard it would be for the average developer to come up with an implementation like this? Just curious.

My opinion, is it would only take a few days, but could get take longer if there's a difference of opinion between developers (i.e. BIP16 vs. BIP 17).

Even though I'm no programming guru, I know that the terms what and how are generally interchangeable when coding. If you want to figure out how to do something, you need to be very precise about what you want to do. It seems almost dishonest to wait for broad consensus before revealing exactly what you want done. I've seen it happen IRL where a company marketing department wastes incredible amounts of money because they have more say about product development than the engineers do.

+1, I wish more people recognized this problem.

[allten]

This BIP does call for more complex code (but not impossible) for the rewards to be handled as proposed. I've tried to stay away from the details of code implementation in the BIP because it just opens another can of worms for everyone to argue over which seems pointless until it reaches mass consensus.
However, since you bring it up... do you have an idea how hard it would be for the average developer to come up with an implementation like this? Just curious.

My opinion, is it would only take a few days, but could get take longer if there's a difference of opinion between developers (i.e. BIP16 vs. BIP 17).

Even though I'm no programming guru, I know that the terms what and how are generally interchangeable when coding. If you want to figure out how to do something, you need to be very precise about what you want to do. It seems almost dishonest to wait for broad consensus before revealing exactly what you want done. I've seen it happen IRL where a company marketing department wastes incredible amounts of money because they have more say about product development than the engineers do.

+1, I wish more people recognized this problem.

"It seems almost dishonest to wait for broad consensus before revealing exactly what you want done"

Didn't mean for it to come across dishonest. I fully support Bitcoin the way it is now and I would also support any scheme that moves to a more frequent block reward decrease assuming they keep the overall injection rate the same over the same time period.
My initial desire was to just write a good "general" BIP without too many details and let the community pick it up and run with it. That would be ideal for me.

[blablahblah]

Didn't mean for it to come across dishonest.

That's OK, I hate revisiting old threads, only to find out that I said something scathing and/or stupid.

My initial desire was to just write a good "general" BIP without too many details and let the community pick it up and run with it. That would be ideal for me.

It sounds like you got a bit of a hard time above (so much for intellectual freedom!), even though intuitively the idea seems like an obvious improvement. The problem with "communities" is that you almost inevitably have to deal with things like groupthink, NIMBYism (not in my back yard), NIHS (not invented here syndrome), idolatry, conservatism... and that's just the civilised programmers...

[Stephen Gornick]

It sounds like you got a bit of a hard time above (so much for intellectual freedom!), even though intuitively the idea seems like an obvious improvement. The problem with "communities" is that you almost inevitably have to deal with things like groupthink, NIMBYism (not in my back yard), NIHS (not invented here syndrome), idolatry, conservatism... and that's just the civilised programmers...

Or that it was a solution to a non-problem, as we now can say from experience.

[allten]

It sounds like you got a bit of a hard time above (so much for intellectual freedom!), even though intuitively the idea seems like an obvious improvement. The problem with "communities" is that you almost inevitably have to deal with things like groupthink, NIMBYism (not in my back yard), NIHS (not invented here syndrome), idolatry, conservatism... and that's just the civilised programmers...

Or that it was a solution to a non-problem, as we now can say from experience.

I guess it all depends on how one would interpret this.

http://bitcoincharts.com/charts/mtgoxUSD#rg180ztgSzm1g10zm2g25zl

The argument was to improve Bitcoin's growth to a very long "gradual" one instead of a sudden jump in either direction (for price and/or mining power). 100% increase in 6 months is not ideal for a currency; however, I do realize there is a ton going on right now with Bitcoin and its future so anything could have caused it. Just don't rule the premise of this BIP out yet even though it most likely will never get implemented.

[MatthewLM]

It wouldn't be as fun without halving day. 

[Ichthyo]

After reading the responses, I fell a very crucial element hasn't been spelled out clearly enough.

The original solution of the reward halving in Bitcoin is beautiful.


This is a distinct and clear property of any mathematical formula or engineering solution which gets to the inner nature of things.
It is simple, it cuts like a sharp knife, it relies on the very basics of binary numbers and it is resilient to interpretation.


There isn't much room for argumentation here. Beautiful things aren't deduced by reasoning, they are recognized in emergence. If you don't immediately get the beauty of a woman, or the beauty of, say, the equation e^(2*i*pi) == 1 for that, then all argumentation will be in vain.


This proposal should be rejected.
One of the core properties of Bitcoin is to replace political adjustments to monetary supply by the pure workings of a mathematical function.
This proposal attempts to replace the purity of this function by an operation just made up to yield some approximate effect.
And this attempt is planned to be forced into the system after-the fact through some kind of majority vote.
Such an attempt, if successful, would threaten the very core of the System.

[Littleshop]

I personally felt the halving of the reward was one of bitcoins weaker (but elegant) parts.  I also felt that a less abrupt change would have been better but I did not want to change to it once things were rolling.  One of the things that makes bitcoin great is the certainty of it.  The reward change was one of those certainties.  Irreversibility is another.  We do not want to change things that. 

The market took care of the reward drop on its own, probably by people knowing about the reward change, buying in advance and now selling.  Long term I would imagine the price to slowly rise as that supply of coins runs down.

[Yuhfhrh]

The original solution of the reward halving in Bitcoin is beautiful.

End of discussion.

OP, you should turn this into a poll so we can see how people here feel about this: Keep it how it is, or try to improve.