I'd like to be able to see the 21,000,000 number.
Where is the bitcoin source code is the 21 million hard cap stated?
Nowhere, because there isn't actually a 21 million cap rule.
The relevant code is this:
CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
int halvings = nHeight / consensusParams.nSubsidyHalvingInterval;
// Force block reward to zero when right shift is undefined.
if (halvings >= 64)
CAmount nSubsidy = 50 * COIN;
// Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
nSubsidy >>= halvings;
// consensusParams.nSubsidyHalvingInterval = 210000.
It computes the maximum subsidy a miner can claim at a given block height, and this function effectively controls Bitcoin's inflation schedule. The often-stated "21 million" limit is just the approximate result of summing all coins this function permits to be brought into circulation, over all time.
The code, in short, implements the following:
- The first 210000 blocks (roughly 4 years) allow up to 50 BTC subsidy each.
- Then 210000 blocks with 25 BTC each
- Then 210000 blocks with 12.5 BTC each
- After 10 halvings, the subsidy becomes 0.04882812 BTC rather than 0.048828125 (which would need half-satoshi precision, and the code uses integer division which rounds down).
- After 33 halvings, the subsidy becomes 0.
If one sums up all the subsidy values over all halvings, the result is 20999999.9769 BTC, not 21000000 BTC. Though, due to various minutiae, that's also not the real limit; this answer goes into more detail.
Now, the code does also contain this constant:
/** No amount larger than this (in satoshi) is valid.
* Note that this constant is *not* the total money supply, which in Bitcoin
* currently happens to be less than 21,000,000 BTC for various reasons, but
* rather a sanity check. As this sanity check is used by consensus-critical
* validation code, the exact value of the MAX_MONEY constant is consensus
* critical; in unusual circumstances like a(nother) overflow bug that allowed
* for the creation of coins out of thin air modification could lead to a fork.
static constexpr CAmount MAX_MONEY = 21000000 * COIN;
which, as the comment explains, does not actually control the total supply (as that's rather the result of summing all the subsidy), but is used as a sanity check in many places.
i wanna add additional info towards what Pieter wrote:
it would not be wise to change into more than that for shown MAX_MONEY value before the year 2100 and only into the next million, if even. for synching into 22nd century (22000000) next. (but synching code had also been written in the past. so maybe its not even a good idea towards that. making changes at all from here on towards that value. Ever! otherwise: "out of synch" problems)
this ensures its not growing larger than what the century it exist inside is capable to offer in limitation capabilities for growth itself.
however you will loose structural integrity towards that build like it is today. meaning: an extension may not be an advantage here! but its too far away to tell for sure yet, so its more a warning!!!
a shorter number is like a triangle vs. a square that would be the next bigger number if the shorter is the triangle.
transfering only 3 lines takes up lesser space in bytes than transfering 4 lines the same size a line. we are more on an advantage with the number 21 here cause 2+1 in crosssum gives us the principle of the 3 lines i mentioned above as well.
sure you can increase further depending on further centuries it develops into.
but you can also work yourself downwards to its beginnings. when 21 wasnt even in place yet towards the millions shown today.
choice is yours! (to point on forking into own chain ideas and values solutions for that)
and regarding: sanity checking, it wasnt named that way without reason. cause it would be insane to meddle with that entry by people in the wrong mind for the burden it takes to keep it the way it is and should be! to make sure things running stable (the most important aspect from a developers perspective i would say anyways). (a static and constexpr for this variable also points strongly on this fact)
but where it will be growing into more. its up to future generations to deal with that problem i guess.
still it cannot hurt to have mentioned that i think still important relationship towards that number. 21st century tech build for 21st century like it is right now! an alone important monetization aspect for the network itself. and maybe most important future anchor as well!
there is also a bit more to it. but from my experience regarding its source code. the century linking does the job best! while anything how it became that way. was how it grew into that.
long enough time to figuring out from now on. if we should make a change for it or not in the future! i would call this a fair deal as well towards the yet unknown future in general understanding!