Bitcoin Forum
December 13, 2017, 01:58:51 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: So, what happens when bitcoins stop being produced?  (Read 3068 times)
matthewh3
Legendary
*
Offline Offline

Activity: 1372



View Profile WWW
October 21, 2012, 01:11:16 AM
 #21

I hear it would take at least 150 years for all the bitcoins to be acquired as the internal software has a limit.

I hear people make up random statistics as their tolerance for actual facts has a limit.


You can make up statistics to prove anything. 83% of people will tell you that!

It's true it will take a very long time to completely stop and if the decimal place kept getting shifted due to rising bitcoin value then mining may happen indefinitely.

1513130331
Hero Member
*
Offline Offline

Posts: 1513130331

View Profile Personal Message (Offline)

Ignore
1513130331
Reply with quote  #2

1513130331
Report to moderator
1513130331
Hero Member
*
Offline Offline

Posts: 1513130331

View Profile Personal Message (Offline)

Ignore
1513130331
Reply with quote  #2

1513130331
Report to moderator
1513130331
Hero Member
*
Offline Offline

Posts: 1513130331

View Profile Personal Message (Offline)

Ignore
1513130331
Reply with quote  #2

1513130331
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513130331
Hero Member
*
Offline Offline

Posts: 1513130331

View Profile Personal Message (Offline)

Ignore
1513130331
Reply with quote  #2

1513130331
Report to moderator
lilphilog
Newbie
*
Offline Offline

Activity: 22


View Profile
October 21, 2012, 12:45:26 PM
 #22

I hope they never stop, i just love the whole concept of "bitcoins"
Ploo
Full Member
***
Offline Offline

Activity: 125


View Profile
October 21, 2012, 04:28:13 PM
 #23

I hope they never stop, i just love the whole concept of "bitcoins"

By design, they will stop being produced. That's what the protocol says.

Or rather they'll be produced indefinitely but because the block reward is halved roughly once every four years, it won't be until far into the future till the reward halves from 1 satoshi (0.00000001) to no reward at all because bitcoin is only divisable to 8 places.

So while technically they'll be produced for a long time to go, in practice the reward will be so small miners will be paid through transaction fees instead.
helloworld
Sr. Member
****
Offline Offline

Activity: 252



View Profile
October 23, 2012, 06:08:59 AM
 #24

Does the calculation lose accuracy each time the reward drops, or is it always based on 50*something?

What will the next list of rewards be after 0.09765625 per block?

I realised this is a dumb question because at some point an actual figure (i.e 50) must have been hardcoded into the software, and that software isn't going to get updated every single time the reward drops.

So obviously the calculation won't lose accuracy as time passes, but will always be based on 50*something.
Foxpup
Legendary
*
Online Online

Activity: 2044



View Profile
October 23, 2012, 07:51:47 AM
 #25

Does the calculation lose accuracy each time the reward drops, or is it always based on 50*something?

What will the next list of rewards be after 0.09765625 per block?

I realised this is a dumb question because at some point an actual figure (i.e 50) must have been hardcoded into the software, and that software isn't going to get updated every single time the reward drops.

So obviously the calculation won't lose accuracy as time passes, but will always be based on 50*something.

Actually, since bitcoins are only divisible down to 8 decimal places, the reward drop will indeed "lose accuracy" on the 10th halving (sometime around the year 2048), when the reward will drop from BTC0.09765625 to BTC0.04882812 (it is always rounded down to the 8th decimal place, so there will be no confusion about it when the time comes).

Will pretend to do unverifiable things (while actually eating an enchilada-style burrito) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4
josephliton
Hero Member
*****
Offline Offline

Activity: 644


View Profile
October 23, 2012, 10:13:46 AM
 #26

I think in the end 1 bitcoin  will be = to 500 dollar. Grin

DannyHamilton
Legendary
*
Offline Offline

Activity: 2002



View Profile
October 23, 2012, 02:29:54 PM
 #27

So obviously the calculation won't lose accuracy as time passes, but will always be based on 50*something.

Actually, since bitcoins are only divisible down to 8 decimal places, the reward drop will indeed "lose accuracy" on the 10th halving (sometime around the year 2048), when the reward will drop from BTC0.09765625 to BTC0.04882812 (it is always rounded down to the 8th decimal place, so there will be no confusion about it when the time comes).

I believe it is technically handled by performing a bitwise right shift on the reward as an integer.

So right now the block reward is 5,000,000,000 which can be represented in binary as:
100101010000001011111001000000000
When we see the reward cut in half in a few weeks, the programming will simply chop a digit off the right-hand side of that binary number giving us
10010101000000101111100100000000
Which is 2,500,000,000 in base 10.

In 2048 the reward will go from 9,765,625 to 4,882,812
100101010000001011111001  (9,765,625)
10010101000000101111100    (4,882,812)

You can see that we will "lose precision" any time we chop off a one, and we will have a nice even halving whenever we chop off a zero.

What will the next list of rewards be . . . ?
For the list of rewards, try this:

http://lmgtfy.com/?q=0b100101010000001011111001000000000+in+decimal

Then you can just remove digits from the right hand side of the binary number to represent the number of "halvings" you are interested in, and you should see the new reward represented in "Satoshi".  If you want to see it represented in BTC, just move the decimal 8 places to the left after the conversion.


odolvlobo
Legendary
*
Offline Offline

Activity: 1974



View Profile
October 24, 2012, 01:28:15 AM
 #28

So obviously the calculation won't lose accuracy as time passes, but will always be based on 50*something.

For the list of rewards, try this:

http://lmgtfy.com/?q=0b100101010000001011111001000000000+in+decimal

Then you can just remove digits from the right hand side of the binary number to represent the number of "halvings" you are interested in, and you should see the new reward represented in "Satoshi".  If you want to see it represented in BTC, just move the decimal 8 places to the left after the conversion.
... or go to https://en.bitcoin.it/wiki/Controlled_Currency_Supply, where all of this is explained and there is a table showing all the block rewards.

Buy bitcoins with cash from somebody near you: LocalBitcoins
Join an anti-signature campaign: DannyHamilton's ignore list
DannyHamilton
Legendary
*
Offline Offline

Activity: 2002



View Profile
October 24, 2012, 02:05:53 AM
 #29

For the list of rewards, try this:

http://lmgtfy.com/?q=0b100101010000001011111001000000000+in+decimal

Then you can just remove digits from the right hand side of the binary number to represent the number of "halvings" you are interested in, and you should see the new reward represented in "Satoshi".  If you want to see it represented in BTC, just move the decimal 8 places to the left after the conversion.

... or go to https://en.bitcoin.it/wiki/Controlled_Currency_Supply, where all of this is explained and there is a table showing all the block rewards.

But which does nothing to explain technically how the reward is modified.  Are the reward amounts coded directly into the software? Is a divide-by-two floating point calculation performed with rounding to 8 decimal places?

ldrgn
Member
**
Offline Offline

Activity: 118


View Profile
October 24, 2012, 02:12:03 AM
 #30

But which does nothing to explain technically how the reward is modified.  Are the reward amounts coded directly into the software? Is a divide-by-two floating point calculation performed with rounding to 8 decimal places?

I'm sorry I can't find you a source, but it's a bit shift of one digit.  Bitcoins are always stored as an integer number of Satoshis.
DannyHamilton
Legendary
*
Offline Offline

Activity: 2002



View Profile
October 24, 2012, 02:19:43 AM
 #31

But which does nothing to explain technically how the reward is modified . . .
I'm sorry I can't find you a source, but it's a bit shift of one digit.  Bitcoins are always stored as an integer number of Satoshis.

I believe you are correct, which is why I already explained it that way here:

I believe it is technically handled by performing a bitwise right shift on the reward as an integer.

DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
October 24, 2012, 03:39:12 AM
 #32

But which does nothing to explain technically how the reward is modified.  Are the reward amounts coded directly into the software? Is a divide-by-two floating point calculation performed with rounding to 8 decimal places?

I'm sorry I can't find you a source, but it's a bit shift of one digit.  Bitcoins are always stored as an integer number of Satoshis.

Correct.

All values at the protocol level are 64bit integers (representing satoshis).  The block reward function uses a right bit shift.

Code:
int64 static GetBlockValue(int nHeight, int64 nFees)
{
    int64 nSubsidy = 50 * COIN;

    // Subsidy is cut in half every 210000 blocks, which will occur approximately every 4 years
    nSubsidy >>= (nHeight / 210000);

    return nSubsidy + nFees;
}
https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp


zebedee
Donator
Hero Member
*
Offline Offline

Activity: 670



View Profile
October 24, 2012, 05:10:42 AM
 #33


Correct.

All values at the protocol level are 64bit integers (representing satoshis).  The block reward function uses a right bit shift.

Code:
int64 static GetBlockValue(int nHeight, int64 nFees)
{
    int64 nSubsidy = 50 * COIN;

    // Subsidy is cut in half every 210000 blocks, which will occur approximately every 4 years
    nSubsidy >>= (nHeight / 210000);

    return nSubsidy + nFees;
}
https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp


That code needs fixing by the devs.  It has undefined behaviour for large nHeight in the right shift operation, and as such is a security hole in the future.

I'd have hoped devs with their experience would know their programming language...
DannyHamilton
Legendary
*
Offline Offline

Activity: 2002



View Profile
October 24, 2012, 06:14:02 AM
 #34


Correct.

All values at the protocol level are 64bit integers (representing satoshis).  The block reward function uses a right bit shift.

Code:
int64 static GetBlockValue(int nHeight, int64 nFees)
{
    int64 nSubsidy = 50 * COIN;

    // Subsidy is cut in half every 210000 blocks, which will occur approximately every 4 years
    nSubsidy >>= (nHeight / 210000);

    return nSubsidy + nFees;
}
https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp


That code needs fixing by the devs.  It has undefined behaviour for large nHeight in the right shift operation, and as such is a security hole in the future.

I'd have hoped devs with their experience would know their programming language...
I don't think we'll have to worry about undefined behavior for at least another 130 years.  I can't think of any computer program that was running 130 years ago that is still running today.  I can't even think of any programming languages that were in use 130 years ago that are still in use today.

I agree that for the sake of well written code it should probably be handled a bit more carefully, but this isn't a bug that will concern me in my lifetime.

Foxpup
Legendary
*
Online Online

Activity: 2044



View Profile
October 24, 2012, 06:55:53 AM
 #35


Correct.

All values at the protocol level are 64bit integers (representing satoshis).  The block reward function uses a right bit shift.

Code:
int64 static GetBlockValue(int nHeight, int64 nFees)
{
    int64 nSubsidy = 50 * COIN;

    // Subsidy is cut in half every 210000 blocks, which will occur approximately every 4 years
    nSubsidy >>= (nHeight / 210000);

    return nSubsidy + nFees;
}
https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp


That code needs fixing by the devs.  It has undefined behaviour for large nHeight in the right shift operation, and as such is a security hole in the future.

I'd have hoped devs with their experience would know their programming language...

Shocked Ouch. Oh well, at least it's an easy fix and we've got over 250 years to implement it...

Will pretend to do unverifiable things (while actually eating an enchilada-style burrito) for bitcoins: 1K6d1EviQKX3SVKjPYmJGyWBb1avbmCFM4
helloworld
Sr. Member
****
Offline Offline

Activity: 252



View Profile
October 28, 2012, 01:53:54 PM
 #36

So obviously the calculation won't lose accuracy as time passes, but will always be based on 50*something.

Actually, since bitcoins are only divisible down to 8 decimal places, the reward drop will indeed "lose accuracy" on the 10th halving (sometime around the year 2048), when the reward will drop from BTC0.09765625 to BTC0.04882812 (it is always rounded down to the 8th decimal place, so there will be no confusion about it when the time comes).

I believe it is technically handled by performing a bitwise right shift on the reward as an integer.

So right now the block reward is 5,000,000,000 which can be represented in binary as:
100101010000001011111001000000000
When we see the reward cut in half in a few weeks, the programming will simply chop a digit off the right-hand side of that binary number giving us
10010101000000101111100100000000
Which is 2,500,000,000 in base 10.

In 2048 the reward will go from 9,765,625 to 4,882,812
100101010000001011111001  (9,765,625)
10010101000000101111100    (4,882,812)

You can see that we will "lose precision" any time we chop off a one, and we will have a nice even halving whenever we chop off a zero.

What will the next list of rewards be . . . ?
For the list of rewards, try this:

http://lmgtfy.com/?q=0b100101010000001011111001000000000+in+decimal

Then you can just remove digits from the right hand side of the binary number to represent the number of "halvings" you are interested in, and you should see the new reward represented in "Satoshi".  If you want to see it represented in BTC, just move the decimal 8 places to the left after the conversion.



However, these truncated values are not hardcoded into the software, but rather the software still only contains the hardcoded 50 (100101010000001011111001000000000) with a run-time algorithm to determine how many times it's shifted.

So this means that it does not lose accuracy each time. i.e. The accuracy loss when a 1 is chopped off does not *compound*.

Example: Let's say we only had 1 decimal place and the reward started at 10, then at some point in the future we decide to use 2 decimal places. If accuracy loss was compounded we'd have the following series.

10.0
5.0
2.5
1.2
"Hey everyone, let's use more decimal places!"
0.60
0.30
0.15
0.07

Whereas if accuracy-loss is not compounded (i.e. only the initial 10.0 is hardcoded into the software) then we end up with a different series

10.0
5.0
2.5
1.2
"Hey everyone, let's use more decimal places!"
0.62
0.31
0.15
0.07

paraipan
Legendary
*
Offline Offline

Activity: 924


Firstbits: 1pirata


View Profile WWW
October 28, 2012, 02:00:13 PM
 #37

^interesting to know, thank you @helloworld for the easy to understand explanation

BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
DannyHamilton
Legendary
*
Offline Offline

Activity: 2002



View Profile
October 28, 2012, 07:14:51 PM
 #38


However, these truncated values are not hardcoded into the software, but rather the software still only contains the hardcoded 50 (100101010000001011111001000000000) with a run-time algorithm to determine how many times it's shifted.

So this means that it does not lose accuracy each time. i.e. The accuracy loss when a 1 is chopped off does not *compound*.

Example: Let's say we only had 1 decimal place and the reward started at 10, then at some point in the future we decide to use 2 decimal places. If accuracy loss was compounded we'd have the following series.

10.0
5.0
2.5
1.2
"Hey everyone, let's use more decimal places!"
0.60
0.30
0.15
0.07

Whereas if accuracy-loss is not compounded (i.e. only the initial 10.0 is hardcoded into the software) then we end up with a different series

10.0
5.0
2.5
1.2
"Hey everyone, let's use more decimal places!"
0.62
0.31
0.15
0.07


Except that right now the code doesn't use decimal places at all.  It works with integers, and then moves the decimal after the calculation is done...

So in your first example (ten plus 1 decimal places) you'd actually be working with 100, then right shift, then move your decimal, to get the extra decimals, you'd have to change your hardcoded starting number fro 100 to 1000 to get the extra precision and still have the starting number be 10 after moving the decimal.  So, you get the extra accuracy, not because the loss wasn't "compounded", but rather because you changed the number that you are starting with to an entirely different number.

helloworld
Sr. Member
****
Offline Offline

Activity: 252



View Profile
October 28, 2012, 11:37:57 PM
 #39

and then moves the decimal after the calculation is done...

This is my entire point (emphasis mine). The reward will always be based on a calculation where '50' (in whatever shape or form) is the only hard-coded amount.
Pages: « 1 [2]  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!