I get exactly 21.000.000 coins.

[BlackHatCoiner]

I had read somewhere that the number of bitcoins is equal with 20.999.??? but not exactly 21M.

I wrote this on PHP:
https://pastebin.com/raw/xdruWaBJ

and I get exactly 21 million coins when I run the file. Do I do anything wrong?

[1714823030]

1714823030

[ranochigo]

It's important to note that whilst the total theoretical coin cap is 21 million, it will never be 21 million. If it's a graph, the 21 million is an asymptote and the graph will tend towards it.

The reason that it will never be 21 million is because the halving is never exactly accurate; Bitcoin has only 8 decimals and at some point in time, the halving of the rewards will result in a scenario such that the reward extends beyond that 8 decimals, resulting in some coins being lost.

Fun fact, the actual Bitcoin will not go into the full 20.9 million that people estimate.

[BlackHatCoiner]

Oh I know got it. Thanks.

Fun fact, the actual Bitcoin will not go into the full 20.9 million that people estimate

What? why?

[nc50lc]

and I get exactly 21 million coins when I run the file. Do I do anything wrong?

I think 64 halvings is the fault which rounded-up the result or you should find a way to increase the maximum decimal places of the result.
Change:

Code:

$halvings = 64;

Into:

Code:

$halvings = 34;

34 is enough for it to result with 20999999.998778, IDK why 34, even here: https://en.bitcoin.it/wiki/Controlled_supply.
The reward is 0BTC for the 33rd halving (34th reward era), though the maximum should be 64.

BTW, there were and there will be "destroyed coins" that will reduce that amount some more.
I'm not talking about burned coins that're sitting in blackhole addresses, I'm talking about those Tx fees that weren't claimed by the miners.
Read the last sentence of the overview, and its references: https://en.bitcoin.it/wiki/Miner_fees#Overview

[TheArchaeologist]

As mentioned by @nullc the mining reward should become 0 after the 34th halving. At that moment 20999999.997899994 btc should be in circulation:

Code:

 halving |  block  | year |   reward    |coins in circulation
---------|---------|------|-------------|--------------------
      0  |       0 | 2009 | 50.00000000 |         10500000.0
      1  |  210000 | 2012 | 25.00000000 |         15750000.0
      2  |  420000 | 2016 | 12.50000000 |         18375000.0
      3  |  630000 | 2020 |  6.25000000 |         19687500.0
      4  |  840000 | 2024 |  3.12500000 |         20343750.0
      5  | 1050000 | 2028 |  1.56250000 |         20671875.0
      6  | 1260000 | 2032 |  0.78125000 |         20835937.5
      7  | 1470000 | 2036 |  0.39062500 |        20917968.75
      8  | 1680000 | 2040 |  0.19531250 |       20958984.375
      9  | 1890000 | 2044 |  0.09765625 |      20979492.1875
     10  | 2100000 | 2048 |  0.04882812 |      20989746.0927
     11  | 2310000 | 2052 |  0.02441406 |      20994873.0453
     12  | 2520000 | 2056 |  0.01220703 |      20997436.5216
     13  | 2730000 | 2060 |  0.00610352 |      20998718.2608
     14  | 2940000 | 2064 |  0.00305176 | 20999359.130400002
     15  | 3150000 | 2068 |  0.00152588 |      20999679.5652
     16  | 3360000 | 2072 |  0.00076294 |      20999839.7826
     17  | 3570000 | 2076 |  0.00038147 |      20999919.8913
     18  | 3780000 | 2080 |  0.00019073 |      20999959.9446
     19  | 3990000 | 2084 |  0.00009537 |      20999979.9723
     20  | 4200000 | 2088 |  0.00004768 |      20999989.9851
     21  | 4410000 | 2092 |  0.00002384 |      20999994.9915
     22  | 4620000 | 2096 |  0.00001192 |      20999997.4947
     23  | 4830000 | 2100 |  0.00000596 |      20999998.7463
     24  | 5040000 | 2104 |  0.00000298 |      20999999.3721
     25  | 5250000 | 2108 |  0.00000149 |       20999999.685
     26  | 5460000 | 2112 |  0.00000075 | 20999999.842499997
     27  | 5670000 | 2116 |  0.00000037 | 20999999.920199998
     28  | 5880000 | 2120 |  0.00000019 |      20999999.9601
     29  | 6090000 | 2124 |  0.00000009 |       20999999.979
     30  | 6300000 | 2128 |  0.00000005 | 20999999.989499997
     31  | 6510000 | 2132 |  0.00000002 | 20999999.993699998
     32  | 6720000 | 2136 |  0.00000001 | 20999999.995799996
     33  | 6930000 | 2140 |  0.00000001 | 20999999.997899994
     34  | 7140000 | 2144 |  0.00000000 | 20999999.997899994

[pooya87]

it is probably because your "num" is not of type integer, it is instead of type float and at some point when it is divided by 2 it has a leftover 0.5 which should be discarded since it is outside of the valid range but it is not.
you are also using 50 as your start which is technically wrong. it should be 5000000000 as a UInt64 (an unsigned 64-bit number without decimal places) and shift it right on each halving. https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1242-L1253

[BlackHatCoiner]

it is probably because your "num" is not of type integer, it is instead of type float and at some point when it is divided by 2 it has a leftover 0.5 which should be discarded since it is outside of the valid range but it is not.
you are also using 50 as your start which is technically wrong. it should be 5000000000 as a UInt64 (an unsigned 64-bit number without decimal places) and shift it right on each halving. https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L1242-L1253

True, I now write it in satoshis instead of bitcoins: https://pastebin.com/raw/ubfCTNDY
I don't think I've done anything wrong now.

It returns me 2099999999877764 satoshis.

The number_format function solves the 0.5 problem, even if I don't fully understand what is the problem you're saying.

[pooya87]

even if I don't fully understand what is the problem you're saying.

the problem is very simple and is about the variable types. i am not familiar with PHP and am not sure if you can define a fixed variable type that doesn't change. but in programming if you define an "integer" like 7 and divide it by 2 the result will be 3 but if you define a float/decimal like 7 and divide it by 2 the result will be 3.5.

C# example

[BlackHatCoiner]

even if I don't fully understand what is the problem you're saying.

the problem is very simple and is about the variable types. i am not familiar with PHP and am not sure if you can define a fixed variable type that doesn't change. but in programming if you define an "integer" like 7 and divide it by 2 the result will be 3 but if you define a float/decimal like 7 and divide it by 2 the result will be 3.5.

C# example

As far as I know, in C# you define:
int num1;
float num2;

In php, it's not like that. You define just a "var":
var floatName = 7;
var intName = 7;

You can't divide intName / 2 and return 3. It will return you 3,5. Although, there are functions that will return 3 instead.

[HeRetiK]

As far as I know, in C# you define:
int num1;
float num2;

In php, it's not like that. You define just a "var":
var floatName = 7;
var intName = 7;

You can't divide intName / 2 and return 3. It will return you 3,5. Although, there are functions that will return 3 instead.

IIRC PHP dynamically converts between types as it sees fit (like JavaScript), which is for example why you can concatenate numbers like you would concatenate strings (eg. 1 . 2 = 12). For numbers this means that PHP will use integers or (double) floating point numbers depending on the operation.

Thing is though that floating point numbers have limited precision and are stored in a way that work better for some numbers than for others so you can get the weirdest rounding errors.

For example your calculations may return 0.1 + 0.2 = 0.30000000000000004 (which some script interpreters may account for when converting the number to a string). The more complex and longer your calculations the more those rounding errors accumulate so eventually your calculations end up way off.

For reference:
https://floating-point-gui.de/
https://en.wikipedia.org/wiki/Round-off_error

[odolvlobo]

Bitcoin uses integer math here and operates in satoshis and not fractional bitcoins. While the theoretical limit is exactly 21 million, the actual limit is slightly less due to the effects of truncation.

Also, the difference between 33 halvings and 64 halvings is less than 0.01 BTC, though it depends on the implementation (which would be incorrect anyway because the actual difference is 0).

There will be 33 halvings, and not 34 as stated by some. The result of the 33rd halving is a subsidy of 0 satoshis.

Fun fact, the actual Bitcoin will not go into the full 20.9 million that people estimate

What? why?

The subsidy value is the maximum number of bitcoins that can be created in a block. Some blocks have created less than the maximum, so the total will be less than expected. Also the reward from the genesis block cannot be spent.

Code:

 halving |  block  | year |   reward    |coins in circulation
---------|---------|------|-------------|--------------------
...
     32  | 6720000 | 2136 |  0.00000001 | 20999999.995799996
     33  | 6930000 | 2140 |  0.00000001 | 20999999.997899994
...

Your table has precision errors and also the 33rd halving does not halve the subsidy. The actual supply in the end should be 20999999.97690000 BTC.

Edit: Wrote "reward", meant "subsidy".

[zcc]

python:

Code:

reward_interval = 210000
current_reward = 50 * 10**8
total = 0
count = 0
while current_reward > 0:
    total += reward_interval * current_reward
    current_reward /= 2
    count += 1
    print "count is :", count, "; current_reward is :", current_reward
print "Total BTC to ever be created:", total, "Satoshis"

result:

Code:

count is : 1 ; current_reward is : 2500000000
count is : 2 ; current_reward is : 1250000000
count is : 3 ; current_reward is : 625000000
count is : 4 ; current_reward is : 312500000
count is : 5 ; current_reward is : 156250000
count is : 6 ; current_reward is : 78125000
count is : 7 ; current_reward is : 39062500
count is : 8 ; current_reward is : 19531250
count is : 9 ; current_reward is : 9765625
count is : 10 ; current_reward is : 4882812
count is : 11 ; current_reward is : 2441406
count is : 12 ; current_reward is : 1220703
count is : 13 ; current_reward is : 610351
count is : 14 ; current_reward is : 305175
count is : 15 ; current_reward is : 152587
count is : 16 ; current_reward is : 76293
count is : 17 ; current_reward is : 38146
count is : 18 ; current_reward is : 19073
count is : 19 ; current_reward is : 9536
count is : 20 ; current_reward is : 4768
count is : 21 ; current_reward is : 2384
count is : 22 ; current_reward is : 1192
count is : 23 ; current_reward is : 596
count is : 24 ; current_reward is : 298
count is : 25 ; current_reward is : 149
count is : 26 ; current_reward is : 74
count is : 27 ; current_reward is : 37
count is : 28 ; current_reward is : 18
count is : 29 ; current_reward is : 9
count is : 30 ; current_reward is : 4
count is : 31 ; current_reward is : 2
count is : 32 ; current_reward is : 1
count is : 33 ; current_reward is : 0
Total BTC to ever be created: 2099999997690000 Satoshis

[DougM]

FYI Here is Satoshi's own explanation to Mike Hearn (via email) back in April 2009 about why the 21M coin cap.
Doesn't ask your question exactly, but I enjoyed the insight into what Satoshi was thinking at the time:

from Mike Hearn:

How did you decide on the inflation schedule for v1? Where did 24 million coins come from? What denominations are these coins? You mention a way to combine and split value but I'm not clear on how this works. For instance are bitcoins always denominated by an integer or can you have fractional bitcoins?

Satoshi response:

My choice for the number of coins and distribution schedule was an educated guess.  It was a difficult choice, because once the network is going it's locked in and we're stuck with it.  I wanted to pick something that would make prices similar to existing currencies, but without knowing the future, that's very hard.  I ended up picking something in the middle.  If Bitcoin remains a small niche, it'll be worth less per unit than existing currencies.  If you imagine it being used for some fraction of world commerce, then there's only going to be 21 million coins for the whole world, so it would be worth much more per unit.  Values are 64-bit integers with 8 decimal places, so 1 coin is represented internally as 100000000.  There's plenty of granularity if typical prices become small.  For example, if 0.001 is worth 1 Euro, then it might be easier to change where the decimal point is displayed, so if you had 1 Bitcoin it's now displayed as 1000, and 0.001 is displayed as 1.

Later Mike asked Satoshi a follow-on question Dec 27, 2010:

Specifically, BitCoin has a variety of magic numbers and neither the code nor the paper explain where they came from. For example, the fact that inflation ceases when 21 million coins have been issued. This number must have been arrived at somehow, but I can't see how.

Satoshi response and Mike's follow-on question:

>> Educated guess, and the maths work out to round numbers.  I wanted something that would be not too low if it was very popular and not too high if it wasn't.

It'd be interesting to see the working for this. In some sense the number of coins is arbitrary as the nanocoin representation means the issuance is so huge it's practically infinite.

Satoshi's final response on the topic on Jan 10, 2011:

It works out to an even 10 minutes per block:
21000000 / (50 BTC * 24hrs * 365days * 4years * 2) = 5.99 blocks/hour
I fudged it to 364.58333 days/year.  The halving of 50 BTC to 25 BTC is after 210000 blocks or around 3.9954 years, which is approximate anyway based on the retargeting mechanism's best effort.
I thought about 100 BTC and 42 million, but 42 million seemed high.
I wanted typical amounts to be in a familiar range.  If you're tossing around 100000 units, it doesn't feel scarce.  The brain is better able to work with numbers from 0.01 to 1000.
If it gets really big, the decimal can move two places and cents become the new coins.

Pure BTC genius