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.
Topic: BIP: ?? Gradual Changing Block Rewards (Read 6400 times)
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.
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.
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.
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.
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.
It wouldn't be as fun without halving day. 
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.
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.
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.
Quote
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...
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).
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.
"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.
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).
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.
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.
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.
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).
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.
So, Here's what I've dug up so far. Appears relevant to "hashing" out a precise coding implementation for the BIP:
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.
Quote
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.
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.
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.
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).
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.
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).
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.
If you divided by the 4th root of 2 every 52500 wouldn't you be producing at the same rate as the old way for one block every 210,000 and producing fewer all other times leading to way fewer blocks? What is the right number?
To restate everyone, this isn't happening. Fantasy is fine.
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.
To restate everyone, this isn't happening. Fantasy is fine.
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.
Appreciate everyone's comments even if they totally disagree. I would like to continue to push to get this published in the WIKI BIP. Doesn't mean it will be adopted. I just want to make it an official record of what is possible and not possible with Bitcoin.
Before doing so, I would like to kindly request that you humor me and this BIP "as if" it was going to be adopted and help me nail down all 3 variables and hold off from commenting on its feasibility.
Please comment on the following:
1)Frequency
2)Block # of implementation
3)Percent decrease.
Also, what if we rounded the block reward after each decrease to four significant digits? Any thoughts.
Points disputing the rationale:Before doing so, I would like to kindly request that you humor me and this BIP "as if" it was going to be adopted and help me nail down all 3 variables and hold off from commenting on its feasibility.
Please comment on the following:
1)Frequency
2)Block # of implementation
3)Percent decrease.
Also, what if we rounded the block reward after each decrease to four significant digits? Any thoughts.
- It's too complicated. Instead of having nice round numbers to work with for various calculations or estimates, one would need to spend a lot of time with spreadsheets (or custom software) making sure that they get the decay curve right. Even with a simpler hypothetical situation, such as adjusting the reward every year, instead of dividing by 2, you're looking at dividing by the 4th root of 2 (if my mental math is right). Very user-unfriendly.
- The rationale assumes that the 4-year steps will be a problem. A bit of a straw man argument? Won't it get priced-in?
- What about possible benefits to having periodic jolts in the block rate?
1) One that comes to mind could be a sustained step in the price that helps Bitcoin achieve mainstream acceptance.
2) Compared to the fiat world, Bitcoin banking is boring - it could give an outlet for investors looking to make money on cyclic changes. (I'm not sure if that was such a great argument, but I thought I'd better mention it anyway).
3) Having these periodic jolts could help to keep the system robust. Without such a mechanism to help maintain robustness, alternative currencies -- with unknown inflation rates -- could cause problems for miners.
There is a reference to the coin maximum (MAX_MONEY) in the code. I don't think it gets used much, mostly just a sanity check. It would be trivial to change.
The client has no idea of how many coins have been created. There is no running total anywhere.
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?
The client has no idea of how many coins have been created. There is no running total anywhere.
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?
And precisely because there is no hard limit on the total money supply, just a side effect of the subsidy function, changing this particular aspect of the algorithm is sacrilegious for the cult of Bitcoin. Sure, we could use this curve, we could use Pieter Wuille's curve, or any other heretic curve with fix supply equal to 21m.
But what guarantees do the faithful have that it will stop here ? If miners are free to disobey the laws of the great Satoshi as they see fit, what stops them from using the same consensus mechanism and set a fixed 50 BTC block reward ? It's certainly in their interest. Or maybe, gasp ! an increasing reward ! Blasphemy ! Cursed demon of Hiperinflation, you dare show your face HERE ? Begone with your heathen BIP !
But what guarantees do the faithful have that it will stop here ? If miners are free to disobey the laws of the great Satoshi as they see fit, what stops them from using the same consensus mechanism and set a fixed 50 BTC block reward ? It's certainly in their interest. Or maybe, gasp ! an increasing reward ! Blasphemy ! Cursed demon of Hiperinflation, you dare show your face HERE ? Begone with your heathen BIP !
Jump to: