So, what happens when bitcoins stop being produced?

[matthewh3]

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.

[1713857529]

1713857529

[1713857529]

1713857529

[lilphilog]

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

[Ploo]

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]

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]

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

[josephliton]

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

[DannyHamilton]

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]

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.

[DannyHamilton]

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]

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]

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]

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]

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]

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]

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

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

[helloworld]

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]

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

[DannyHamilton]

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]

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.