How is the 21 Million Bitcoin Cap Defined and Enforced?

How is the 21 Million Bitcoin Cap Defined and Enforced?
Bitcoin_Freedom
0
0
    <p>If you've studied Bitcoin for more than a few minutes then you're probably aware that the money supply is predictable and will never exceed 21 million bitcoin. Pedantically, the limit is 2,099,999,997,690,000 satoshis given that all accounting at the protocol level is calculated in the smallest unit.</p>

But how is this limit defined and what prevents it from being broken?

A newbie might try to find this limit mentioned in the whitepaper... but it's not there (nor are many other aspects of the protocol!)

Bitcoin whitepaper purists should take note that the following things are NOT described in the whitepaper:multisigmining pools21M coin capGPU & ASIC mining10 minute block timesHD address generationbest chain = cumulative PoW, not longest chainand much, much more...— Jameson Lopp (@lopp) July 29, 2018

Did you try to find the limit defined in the Bitcoin Core implementation? If you search for "21000000" on the github repository then you'll find this MAX_MONEY constant defined, but that's not it either!

So... where is the cap enforced? It's not as straightforward as you might think.

Implicit Rather than Explicit Limits A common misconception is that Bitcoin must regularly check that the money supply remains under 21 million.In fact, there are 0 such explicit supply checks in Bitcoin Core. Why? It would be onerous to constantly sum 75+ million UTXOs. 21MM cap is implicit rather than explicit.— Jameson Lopp (@lopp) October 12, 2021

Rather than thinking of the total number of bitcoins issued as a "point in time" check, you should view it as a geometric series that sets a moving upper limit. After all, we don't actually care about ~exactly~ how many bitcoins exist - we only care that there are fewer than the expected amount. The series that describes our desired upper bound can be described by the following equation:

Source: https://twitter.com/anilsaidso

This is like saying...

  50 * 210000 + 25  * 210000 + 12.5  * 210000 … + 0.00000002 * 210000 + 0.00000001  * 210000 = 20999999.9769

Bitcoin implementations control new issuance by checking that each new block does not create more than the allowed block subsidy. This line of code is specifically summing up the total output value of the block's coinbase transaction - the first transaction in a block - which is the only transaction allowed to mint new coins.

You may note that this is also taking the transaction fees from the block into account. Why? Because those fees are not newly issued bitcoin - they already existed and were paid to the miner by people who made transactions. It would be similarly correct to check that the coinbase transaction's output value minus the block's transaction fees is less than or equal to the allowed block subsidy.

How is the bitcoin issuance curve defined in the protocol? It's a mere 5 lines of code, 2 of which are to cover an extreme edge case that won't trigger until block height 13,440,000 - some time around the year 2265. You can read all about the logic behind this check on line 1157 in BIP-042.

For any given block height we can easily calculate exactly where in the issuance curve / geometric series this block exists. All we need to know is how many halvings have occurred (line 1155) and then divide the original subsidy amount (50 BTC) in half by that many times, which is what the fancy bit shift operation on line 1162 does.

In addition to checking the block subsidy, we also need to prevent unintended inflation from occurring in non-coinbase transactions.

The first way to do this is to make sure every transaction's inputs actually exist and are spendable. You can find this check in the CheckTxInputs function in Bitcoin Core.

This, of course, is one of the most fundamental checks in the Bitcoin protocol - the prevention of double spending. If it was possible to spend the same money twice, that would be exploitable to arbitrarily inflate the money supply.

We also perform sanity checks on the input values to make sure they aren't negative and don't overflow. Either of these cases would result in the creation of new money; there was an overflow incident in Bitcoin's early days that did just that!

Another important validation for every non-coinbase transaction is to ensure the transaction's total output value is less than or equal to the input value, since a higher output would mean that new value is being created from nothing. The same validation function performs that check here.

Those are the critical checks to prevent arbitrary inflation of Bitcoin's money supply. There are additional mechanisms (difficulty adjustment) to control the issuance rate in terms of human time. If you're interested in learning more about them, check out my deep dives into Bitcoin's Timestamp Security and Bitcoin's Block Time Variance.

Explicit Verification

As noted earlier, actually summing up the total bitcoin supply every time we want to ensure that supply-related rules are being followed would be rather resource intensive. But it is possible to perform a more explicit verification - all you have to do is sum up the values of all of the unspent transaction outputs (UTXOs.)

Bitcoin Core offers a convenient utility function for performing a total money supply audit. This function is called gettxoutsetinfo.

At time of writing there are nearly 80,000,000 UTXOs in existence, so this call can take a minute or two to run depending upon your node's hardware.

My node that powers statoshi.info automatically calls this function after each new block that it processes. The number of coins that it returns is then stored in a database that is used to render this chart.

That's all there is to it! Bitcoin's monetary supply is both trivially predictable and verifiable. The previous thousand words you read were just an explanation of a dozen lines of code.

21 Million FAQs

There are several other questions that folks often have regarding Bitcoin's money supply.

Can the limit be changed?

Technically yes, though this is really a question of governance and incentives. Anyone can change the limits enforced by their own node - the hard part is convincing everyone else to do the same with their nodes. For a deep dive, check out:

Who Controls Bitcoin Core? Understanding how the focal point of Bitcoin development operates. Can Bitcoin’s Hard Cap of 21 Million Be Changed? | River Learn - Bitcoin Basics There will never be more than 21 million bitcoin. This rule, encoded in Bitcoin’s source code, cannot be changed thanks to Bitcoin’s decentralized nature. If it were possible, changing this hard cap would destroy the value proposition of Bitcoin. River Financial Why 21 million and not ______? Q: Why did Satoshi choose an upper limit of 21,000,000 BTC?A: The limiting factor is the max value of a 64 bit integer (18,446,744,073,709,551,615) and 21,000,000 BTC is represented as 2,100,000,000,000,000 satoshis.https://t.co/lUo4fRn0yS pic.twitter.com/KbxSyesiNK— Jameson Lopp (@lopp) January 23, 2021 What happens after all 21 million bitcoin are mined?

Miners don't only mint new coins - they also collect transaction fees. It's called a "block subsidy" for a reason - the issuance of new coins is only meant to help bootstrap the system while the transaction volume is low. As Bitcoin adoption increases, so does demand for (limited) block space and thus so do transaction fees.

What Will Happen to Bitcoin After All 21 Million are Mined? - Decrypt Once the last Bitcoin is mined, miners will have to look elsewhere for the rewards that incentivize their maintenance of the blockchain. How many bitcoins actually exist / are lost?

It's easy enough to count the value of all UTXOs in existence, though deeper investigation shows that some will never be created, some are provably unspendable, and some are probably (but not certainly) unspendable. Coinmetrics has a great post that analyzes the likely circulating supply.

Source: https://coinmetrics.substack.com/p/coin-metrics-state-of-the-network-d2e