Bitcoin Forum
December 02, 2016, 08:31:25 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3]  All
  Print  
Author Topic: BIP: ?? Gradual Changing Block Rewards  (Read 5833 times)
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
April 03, 2012, 04:37:09 AM
 #41

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.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
1480710685
Hero Member
*
Offline Offline

Posts: 1480710685

View Profile Personal Message (Offline)

Ignore
1480710685
Reply with quote  #2

1480710685
Report to moderator
1480710685
Hero Member
*
Offline Offline

Posts: 1480710685

View Profile Personal Message (Offline)

Ignore
1480710685
Reply with quote  #2

1480710685
Report to moderator
1480710685
Hero Member
*
Offline Offline

Posts: 1480710685

View Profile Personal Message (Offline)

Ignore
1480710685
Reply with quote  #2

1480710685
Report to moderator
If you want to be a moderator, report many posts with accuracy. You will be noticed.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
allten
Sr. Member
****
Offline Offline

Activity: 447



View Profile
April 03, 2012, 03:05:22 PM
 #42

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
Legendary
*
Offline Offline

Activity: 1302



View Profile
April 03, 2012, 03:49:41 PM
 #43

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.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
allten
Sr. Member
****
Offline Offline

Activity: 447



View Profile
April 04, 2012, 01:30:12 AM
 #44

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
Sr. Member
****
Offline Offline

Activity: 447



View Profile
April 04, 2012, 02:13:16 AM
 #45

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

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.

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
Legendary
*
Offline Offline

Activity: 775


View Profile
April 04, 2012, 09:23:58 AM
 #46

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
Member
**
Offline Offline

Activity: 97


View Profile
April 04, 2012, 11:19:59 AM
 #47

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. Angry

rjk
Sr. Member
****
Offline Offline

Activity: 420


1ngldh


View Profile
April 04, 2012, 12:21:41 PM
 #48

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.

Mining Rig Extraordinaire - the Trenton BPX6806 18-slot PCIe backplane [PICS] Dead project is dead, all hail the coming of the mighty ASIC!
allten
Sr. Member
****
Offline Offline

Activity: 447



View Profile
April 30, 2012, 08:25:09 PM
 #49

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
Legendary
*
Offline Offline

Activity: 775


View Profile
April 30, 2012, 09:43:07 PM
 #50

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...
Stephen Gornick
Legendary
*
Offline Offline

Activity: 1988



View Profile
November 29, 2012, 01:21:19 AM
 #51

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
Sr. Member
****
Offline Offline

Activity: 447



View Profile
November 29, 2012, 06:03:44 AM
 #52

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
Legendary
*
Offline Offline

Activity: 1092



View Profile WWW
November 29, 2012, 12:56:29 PM
 #53

It wouldn't be as fun without halving day.  Wink

Bitcoin Extra Wallet | Peercoin Android Wallet
BTC: 1D5A1q5d192j5gYuWiP3CSE5fcaaZxe6E9  PPC: PH7fVn1Xs7nkUFmdwCX2ZRYfLPCSwGxAq9
Ichthyo
Hero Member
*****
Offline Offline

Activity: 602


View Profile
November 30, 2012, 04:47:52 AM
 #54

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
Legendary
*
Offline Offline

Activity: 1316



View Profile WWW
November 30, 2012, 04:59:33 AM
 #55

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
Full Member
***
Offline Offline

Activity: 238



View Profile
November 30, 2012, 05:32:28 AM
 #56

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.
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!