BenGimli (OP)
Newbie
Offline
Activity: 2
Merit: 0


June 15, 2015, 03:31:29 PM Last edit: June 15, 2015, 09:42:07 PM by BenGimli 

Ok, Forgive my ignorance, but I'm new to bitcoin (love it!) and doing a lot of research. How did Satoshi Nakamoto come up with 21 million, for his (their?) limit to bitcoin? Because we use base 10, it seems to me that 50 million, 100, million, or 25 million would be a 'better' number to have ended up with. Or, if you wanted to derive a mathematical number, why not double a number, to get to 16.7 million (16,777,216) or 33.5 million (33,554,432) bitcoin? 21 million bitcoin just seems like a random number. Or is it?






The Bitcoin network protocol was designed to be extremely flexible. It can be used to create timed transactions, escrow transactions, multisignature transactions, etc. The current features of the client only hint at what will be possible in the future.



Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.




DannyHamilton
Legendary
Offline
Activity: 3108
Merit: 3895

Ok, Forgive my ignorance, but I'm new to bitcoin (love it!) and doing a lot of research. How did Satoshi Nakamura come up with 21 million, for his (their?) limit to bitcoin? Because we use base 10, it seems to me that 50 million, 100, million, or 25 million would be a 'better' number to have ended up with. Or, if you wanted to derive a mathematical number, why not double a number, to get to 16.7 million (16,777,216) or 33.5 million (33,554,432) bitcoin? 21 million bitcoin just seems like a random number. Or is it? The actual number isn't 21 million. People just round up to 21 million (and then say "the total amount will never be more than 21 million") when talking about it. The actual limit on number of bitcoins that can be created is 20999999.9769 The number is calculated as follows: Start with a block reward of a nice simple number of 50 BTC per block. Then every 210000 block (approximately every 4 years if blocks are generated on average every 10 minutes), cut the block reward in half and throw away any decimals after the 8th decimal place. So after 210000 blocks you will have generated 50 * 210000 = 10500000 BTC Then after another 210000 blocks you will have generated another 25 * 210000 = 5250000 BTC for a total of 10500000 + 5250000 = 15750000 BTC Then after another 210000 blocks you will have generated another 12.5 * 210000 = 2625000 BTC for a total of 10500000 + 5250000 + 2625000 = 18375000 BTC If you continue this process, you'll find that by the time you reach block number 6930000 you will be cutting the block reward in half from 0.00000001 which, upon throwing away any decimals after the 8th decimal place, will be 0.00000000 BTC. By then you will have generated a total of exactly 20999999.9769 BTC. Since the block reward is then 0, cutting it in half leaves it at zero forever meaning that no new bitcoins will ever be generated. You can see all the related numbers here if your curious: https://en.bitcoin.it/wiki/Controlled_supply#Projected_Bitcoins_Long_Term




teukon
Legendary
Offline
Activity: 1246
Merit: 1002


June 15, 2015, 04:37:52 PM 

How did Satoshi Nakamura come up with 21 million, for his (their?) limit to bitcoin?
Satoshi Naka moto settled on a target time of 10 minutes per block with an initial subsidy of 50 BTC set to halve once every 4 years. 4 years / 10 minutes ≈ 210 000 50 + 25 + 12.5 + 6.25 + ... = 100 210 000 * 100 = 21 million




tspacepilot
Legendary
Offline
Activity: 1456
Merit: 1073
I may write code in exchange for bitcoins.


June 15, 2015, 04:55:54 PM 

I think BIP42 is also relevant here. In fact, after having read through that BIP, I can't tell if it's been implemented or not. I also can't tell if the author is merely pointing out a quirk in the C++ code which formed the reference standard or if he's referring to Satoshi's intentions that the supply not be finite. In any case, I'm sure DannyHamilton can enlighten us on it. Thanks in advance!




DannyHamilton
Legendary
Offline
Activity: 3108
Merit: 3895


June 15, 2015, 05:12:17 PM 

...after having read through that BIP, I can't tell if it's been implemented or not...
It was implemented with these three lines of code: https://github.com/bitcoin/bitcoin/blob/c1fb0e1075f626ea23d832b07b2070e0638f4215/src/main.cpp#L1198L1200I also can't tell if the author is merely pointing out a quirk in the C++ code which formed the reference standard or if he's referring to Satoshi's intentions that the supply not be finite.
The author is using humor, pretending that Satoshi is incapable of having bugs in his code and therefore the bug MUST have been a hidden intended behavior of the protocol. The effect of the bug is that in some implementations of the protocol (specifically those that use C++ and calculate the block reward the same way as the reference client used to) the block reward is reset back to 50 BTC per block every 256 years. In any case, I'm sure DannyHamilton can enlighten us on it.
Thanks in advance!
I've done what I can.




TierNolan
Legendary
Offline
Activity: 1232
Merit: 1014

I think BIP42 is also relevant here. In fact, after having read through that BIP, I can't tell if it's been implemented or not. I also can't tell if the author is merely pointing out a quirk in the C++ code which formed the reference standard or if he's referring to Satoshi's intentions that the supply not be finite. Yeah, it's implemented. They just check the number of doublings against 64 and set it to zero after that. [edit] To slow by me.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF



tspacepilot
Legendary
Offline
Activity: 1456
Merit: 1073
I may write code in exchange for bitcoins.


June 15, 2015, 10:35:14 PM 

...after having read through that BIP, I can't tell if it's been implemented or not...
It was implemented with these three lines of code: https://github.com/bitcoin/bitcoin/blob/c1fb0e1075f626ea23d832b07b2070e0638f4215/src/main.cpp#L1198L1200I also can't tell if the author is merely pointing out a quirk in the C++ code which formed the reference standard or if he's referring to Satoshi's intentions that the supply not be finite.
The author is using humor, pretending that Satoshi is incapable of having bugs in his code and therefore the bug MUST have been a hidden intended behavior of the protocol. The effect of the bug is that in some implementations of the protocol (specifically those that use C++ and calculate the block reward the same way as the reference client used to) the block reward is reset back to 50 BTC per block every 256 years. In any case, I'm sure DannyHamilton can enlighten us on it.
Thanks in advance!
I've done what I can. It was enough. I understand now. For the record, I also thought there was a tongueincheek to the author's suggestion that Satoshi wanted to keep bitcoin expanding, but then he made that reference to gold mines being discovered and I just couldn't tell. Anyway, thanks for clearing it up.




Vaccomondus


June 16, 2015, 08:28:47 AM 

still none of you guys have said WHY, he asked why he choose those numbers not how it work




s2


June 16, 2015, 08:57:36 AM 

I've written my thoughts on this once before, wish I could find it but it was in reddit's /r/bitcoin of /r/bitcointechnology... anyhow I expect it's mainly due to floating point issues. Satoshi seems very comfortable using many different numbering systems in the code so was well aware of floating point precision issues. Whilst the bitcoind is written using integer math for satoshis the magical 21 million * 100,000,000 fits perfectly should someone use floats to store the satoshi value of the transaction. For languages like Javascript you have to use double precision floating point so there was method to this madness.
A double precision floating point has 52 significant bits so is capable of describing every number between 0  4503599627370496 exactly.
Or converting that number of satoshi's in Bitcoins this gives 45,035,996. 27370496
So whilst he could have use 45 million my guess is that the maths of starting with 50BTC and halving came to ~21 million which is high enough to use the full range while giving some room for error such as someone doing ( coins in circulation + satoshi's stash ) / 2 and not worrying about overflow errors.




tspacepilot
Legendary
Offline
Activity: 1456
Merit: 1073
I may write code in exchange for bitcoins.


June 16, 2015, 02:03:08 PM 

still none of you guys have said WHY, he asked why he choose those numbers not how it work
Well *why* may very much be a matter of speculation. Who can really say "why" except Satoshi himself? And if he hasn't said *why* then how can we infer it? Seems like the next best thing to why is to look at what. Anyway, in this case, I understood DannyHamilton's answer to be suggesting that the why was that the 21M was merely an artifact of the how. Ie, there was no intentionality in the why 21M, that the intentionality was to have the supply diminish on a curve and 21M just happened to be the value for the particular parameters he choseperhaps suggesting that if there were numbers chosen intentionally it was the 50BTC block reward and the 10 minute block time, and the halving rate.




Cryddit
Legendary
Offline
Activity: 924
Merit: 1100


June 17, 2015, 03:52:38 AM 

Satoshi cared that people using Javascript (?) or other languages which encode all numbers as 'double' (64bit floats) would not have to jump through hoops to avoid stupid accounting mistakes.
Your 64bit float has 52 bits of mantissa, so, in order to avoid rounding errors ever going the wrong way, the number of units involved in bitcoinrelated math must never be more than 2^{51}, which is 2251799813685248 units. 21 million coins times 10^{8} divisions (Satoshis as they are now called) is 2100000000000000 units  comfortably just below the limit allowing "simple" accounting implementations in such languages to be accurate.
And as Hal Finney pointed out in 2008, even if the entire M1 money supply of the world as of that time were expressed in Bitcoins, the smallest division would still be worth less than 1 USAmerican penny, so there is no need for more than that many units.




Cryddit
Legendary
Offline
Activity: 924
Merit: 1100


June 17, 2015, 03:58:45 AM 

A double precision floating point has 52 significant bits so is capable of describing every number between 0  4503599627370496 exactly.
Or converting that number of satoshi's in Bitcoins this gives 45,035,996. 27370496
So whilst he could have use 45 million my guess is that the maths of starting with 50BTC and halving came to ~21 million which is high enough to use the full range while giving some room for error such as someone doing ( coins in circulation + satoshi's stash ) / 2 and not worrying about overflow errors.
Actually yes, Satoshi was very much aware of numeric representation issues. And the fact is that you can't actually get 100% accurate rounding on basic4 operations (addition/subtraction/multiplication/division) if you use more than *HALF* of the number of distinct values available. So the actual limit on the number of divisions for accounting without "gotcha" rounding errors is 2^51, not 2^52.




tspacepilot
Legendary
Offline
Activity: 1456
Merit: 1073
I may write code in exchange for bitcoins.


June 17, 2015, 06:28:50 AM 

Satoshi cared that people using Javascript (?) or other languages which encode all numbers as 'double' (64bit floats) would not have to jump through hoops to avoid stupid accounting mistakes.
Your 64bit float has 52 bits of mantissa, so, in order to avoid rounding errors ever going the wrong way, the number of units involved in bitcoinrelated math must never be more than 2^{51}, which is 2251799813685248 units. 21 million coins times 10^{8} divisions (Satoshis as they are now called) is 2100000000000000 units  comfortably just below the limit allowing "simple" accounting implementations in such languages to be accurate.
And as Hal Finney pointed out in 2008, even if the entire M1 money supply of the world as of that time were expressed in Bitcoins, the smallest division would still be worth less than 1 USAmerican penny, so there is no need for more than that many units.
Cryddit, of course it's fun to look at the facts posthoc and try to guess about their motivation, and I have to point out the fallacy of that (in the general case). But your speculation is the best one yet! That's a very cool observation.




teukon
Legendary
Offline
Activity: 1246
Merit: 1002

A double precision floating point has 52 significant bits so is capable of describing every number between 0  4503599627370496 exactly.
Or converting that number of satoshi's in Bitcoins this gives 45,035,996. 27370496
So whilst he could have use 45 million my guess is that the maths of starting with 50BTC and halving came to ~21 million which is high enough to use the full range while giving some room for error such as someone doing ( coins in circulation + satoshi's stash ) / 2 and not worrying about overflow errors.
Actually yes, Satoshi was very much aware of numeric representation issues. And the fact is that you can't actually get 100% accurate rounding on basic4 operations (addition/subtraction/multiplication/division) if you use more than *HALF* of the number of distinct values available. So the actual limit on the number of divisions for accounting without "gotcha" rounding errors is 2^51, not 2^52. Am I missing something here? It appears to me that binary64 (IEEE 754) can precisely represent any integer from 2 ^{53} to 2 ^{53}. Even after allowing one bit to avoid rounding oddities we have a second bit unaccounted for.




Cryddit
Legendary
Offline
Activity: 924
Merit: 1100


June 17, 2015, 04:53:04 PM 

Yeah, the issue requiring an extra bit for rounding accuracy happens when you multiply or divide by by an imprecisely represented decimal fraction, or add or subtract an imprecisely represented decimal fraction, and want to be sure that the answer comes out to the closest value.
And it's 52 bits of mantissa, not 53. The last one is a sign bit, and while there's no such thing as negative bitcoins you can't use it for positive amounts because of partial results and subtractions having negative values you must represent.




StephenMorse
Member
Offline
Activity: 88
Merit: 12

Ok, Forgive my ignorance, but I'm new to bitcoin (love it!) and doing a lot of research. How did Satoshi Nakamoto come up with 21 million, for his (their?) limit to bitcoin? Because we use base 10, it seems to me that 50 million, 100, million, or 25 million would be a 'better' number to have ended up with. Or, if you wanted to derive a mathematical number, why not double a number, to get to 16.7 million (16,777,216) or 33.5 million (33,554,432) bitcoin? 21 million bitcoin just seems like a random number. Or is it? The bitcoin.SE is a good reference on this: http://bitcoin.stackexchange.com/questions/8439/whywas21millionpickedasthenumberofbitcoinstobecreatedIt's a good thing Satoshi didn't go much higher, because 21 * 10^14 is breaching on what a signed 64 bit integer can hold.




teukon
Legendary
Offline
Activity: 1246
Merit: 1002


June 17, 2015, 10:31:55 PM Last edit: June 18, 2015, 11:44:02 PM by teukon 

Yeah, the issue requiring an extra bit for rounding accuracy happens when you multiply or divide by by an imprecisely represented decimal fraction, or add or subtract an imprecisely represented decimal fraction, and want to be sure that the answer comes out to the closest value.
Yes, this is a subtle point I'd not considered before. Good to know. And it's 52 bits of mantissa, not 53. The last one is a sign bit, and while there's no such thing as negative bitcoins you can't use it for positive amounts because of partial results and subtractions having negative values you must represent.
Yes, the mantissa is 52 bits. However, the leading '1' of the binary representation of a nonzero integer is not stored in the mantissa. The least positive integer that cannot be precisely expressed in this format is 2 ^{53} + 1.




teukon
Legendary
Offline
Activity: 1246
Merit: 1002


June 17, 2015, 10:50:45 PM 

It's a good thing Satoshi didn't go much higher, because 21 * 10^14 is breaching on what a signed 64 bit integer can hold.
A signed 64bit integer will go up to about 9.2 * 10 ^{18}, much larger than the 2.1 * 10 ^{15} bound.




