# Last edited on 2015-03-17 17:27:57 by stolfilocal
# For the "wall observer" thread
#  NOT POSTED

[quote author=sAt0sHiFanClub link=topic=178336.msg10749967#msg10749967 date=1426170869]
If there is an axiom that states that 21M is the oncrete limit, then I want to know.
You owe that to me and other bitcoiners. For our future....
[/quote]

No use asking that to the bitcoin "experts".  Most of them are "discrete computing" guys who have a gap in their brain at the spot where the necessary knowledge would be found.

There is a very plausible explanation for that "21 million" number that would make sense to a really experienced computer expert (like Satoshi obviously was), that comes from outside the discrete computing domain.  Specifically, from accounting.

Accounting typically consists in drawing an imaginary circle around some activity - a company, a department, a project, etc - and putting on a spreadsheet everything that went into or out of that circle in some specific time interval.  What was inside at the beginning, and all that went in, goes in one column; what went out, and what is left at the end, goes into another column.  If the two columns add to exactly the same number, people who read that spreadsheet get a warm feeling of security: the match does not really prove that the numbers are correct, of course, but it shows that the accountant did his jobe with a minimum of care.  Whereas, if the numbers don't match, it says that the accountant was sloppy - and therefore who knows what other errors he made.

Since it is a test or accounting precision, the amount of mismatch does not really matter; even a 1 cent error in a billion-dollar report is unacceptable.  To the accountant who is preparing the spreadsheet, in fact, a 10 million dolalr error is no sweat, he has only to look for a missing entry of that size; but a 1 cent error is terrible, because it means that someone, somewhere, made a rounding mistake.

Now, most accounting out there is done on Excel or similar software.  Numbers in excel are represented internally as double-precision floating-point numbers.   The same format is used by many other programs (such as gawk and matlab) that handle 'numbers' in general, integer or fractional, without explicitly requiting users to specify their precision. 

The IEEE double-precision floating-point standard (now used by virtually every computer made today) reserves 52 bits for the actual number (mantissa), apart from sign bits and scaling exponents.  Thus, in Excel one can handle safely, without risk of rounding, any integer up to 2^53=9,007,199,254,740,992.   To be on the safe side (e.g. if one wants to compute 3/4 or 3/5 of any round BTC amount without mysterious rounding) then it is best to leave a couple bits of slack.  Say, make sure that the input integer data does not exceed 2^51-1 = 2,251,799,813,685,247.

And 2'251'799'813'685'247 satoshis is 22'517'998.13685247 BTC.

Next, it was necessary to define a block reward halving schedule that, when complete, would not exceed that maximum limit.  There was no way to predict how the price of bitcoin and the cost of hasing would evolve with time,  so the schedule was arbitrarily set to start with a round number of BTC (50) and be reduced in half every 4 years, rounded to 210'000 blocks.  These two parameters were arbitrary, but linked by the constraint that the final amount of BTC to be generate would be will be a little less than 21 million  (i.e. if the initial reward had been set to 100 BTC/block, then it would have been necessary to set the halving period to ~2 years to get the same amount of coins in the end.)

So, if the limit were to be increased much beyond 21 million BTC, accountants wishing to put the entire bitcoin economy in one Excel spreadsheet would start to get mismatches of a few satoshis due to floating-point rounding. 

Most discrete computer types would never have thought of that, because they generally ignore floating-point as something that only d