Auditing Bitcoin Supply
Let's prove out expected Bitcoin issuance with actual balances.
The Bitcoin network does not hold any assets, bitcoins are not backed by anything.
What the Bitcoin network does is issue a claim on some quantity of satoshis (1 btc = 100,000,000 satoshis), a liability.
These network liabilities, called outputs, each have a smart contract to cryptographically secure their future transfer.
An output can only be unlocked and transferred if an input is provided that fulfills the spending conditions of the output's smart contract.
The asset owned by the user is generally just a private key that can fulfill the spending conditions of some set of unspent outputs (UTXOs).
The issuance of satoshis is governed by an open p2p network of nodes, run by users, enforcing strict adherence to specific Bitcoin protocol rules.
Miners who propose a valid block to the network can transfer newly issued satoshis to themselves based on a formula with one variable: the block's height.
Every node on the Bitcoin network divides the block height by a fixed issuance halving interval, 210,000 blocks. Rounding to the nearest whole number gives us how many halvings to apply to the 50 BTC initial per-block subsidy.
Halvings are applied by "right shifting" the binary representation of the subsidy, where the last bit is dropped and a zero is prepended in front. Each right shift applied causes a halving of issuance.
Here is the C++ code for this function as implemented in Bitcoin Core:
Here are the results of that function at each of the halving heights, blocks mined at this height and before the next row's height can create at most the calculated subsidy:
| Height | Halvings | Right shifted binary representation of subsidy | Subsidy integer | Total satoshis issued |
|---|---|---|---|---|
| 0 | 0 | 100101010000001011111001000000000 | 5,000,000,000 | 5,000,000,000 |
| 210000 | 1 | 010010101000000101111100100000000 | 2,500,000,000 | 1,050,002,500,000,000 |
| 420000 | 2 | 001001010100000010111110010000000 | 1,250,000,000 | 1,575,001,250,000,000 |
| 630000 | 3 | 000100101010000001011111001000000 | 625,000,000 | 1,837,500,625,000,000 |
| 840000 | 4 | 000010010101000000101111100100000 | 312,500,000 | 1,968,750,312,500,000 |
| 1050000 | 5 | 000001001010100000010111110010000 | 156,250,000 | 2,034,375,156,250,000 |
| 1260000 | 6 | 000000100101010000001011111001000 | 78,125,000 | 2,067,187,578,125,000 |
| 1470000 | 7 | 000000010010101000000101111100100 | 39,062,500 | 2,083,593,789,062,500 |
| 1680000 | 8 | 000000001001010100000010111110010 | 19,531,250 | 2,091,796,894,531,250 |
| 1890000 | 9 | 000000000100101010000001011111001 | 9,765,625 | 2,095,898,447,265,620 |
| 2100000 | 10 | 000000000010010101000000101111100 | 4,882,812 | 2,097,949,223,632,810 |
| 2310000 | 11 | 000000000001001010100000010111110 | 2,441,406 | 2,098,974,611,711,400 |
| 2520000 | 12 | 000000000000100101010000001011111 | 1,220,703 | 2,099,487,305,750,700 |
| 2730000 | 13 | 000000000000010010101000000101111 | 610,351 | 2,099,743,652,770,350 |
| 2940000 | 14 | 000000000000001001010100000010111 | 305,175 | 2,099,871,826,175,170 |
| 3150000 | 15 | 000000000000000100101010000001011 | 152,587 | 2,099,935,912,772,580 |
| 3360000 | 16 | 000000000000000010010101000000101 | 76,293 | 2,099,967,955,966,290 |
| 3570000 | 17 | 000000000000000001001010100000010 | 38,146 | 2,099,983,977,458,140 |
| 3780000 | 18 | 000000000000000000100101010000001 | 19,073 | 2,099,991,988,099,070 |
| 3990000 | 19 | 000000000000000000010010101000000 | 9,536 | 2,099,995,993,419,530 |
| 4200000 | 20 | 000000000000000000001001010100000 | 4,768 | 2,099,997,995,974,760 |
| 4410000 | 21 | 000000000000000000000100101010000 | 2,384 | 2,099,998,997,252,380 |
| 4620000 | 22 | 000000000000000000000010010101000 | 1,192 | 2,099,999,497,891,190 |
| 4830000 | 23 | 000000000000000000000001001010100 | 596 | 2,099,999,748,210,590 |
| 5040000 | 24 | 000000000000000000000000100101010 | 298 | 2,099,999,873,370,290 |
| 5250000 | 25 | 000000000000000000000000010010101 | 149 | 2,099,999,935,950,140 |
| 5460000 | 26 | 000000000000000000000000001001010 | 74 | 2,099,999,967,240,070 |
| 5670000 | 27 | 000000000000000000000000000100101 | 37 | 2,099,999,982,780,030 |
| 5880000 | 28 | 000000000000000000000000000010010 | 18 | 2,099,999,990,550,010 |
| 6090000 | 29 | 000000000000000000000000000001001 | 9 | 2,099,999,994,330,000 |
| 6300000 | 30 | 000000000000000000000000000000100 | 4 | 2,099,999,996,220,000 |
| 6510000 | 31 | 000000000000000000000000000000010 | 2 | 2,099,999,997,060,000 |
| 6720000 | 32 | 000000000000000000000000000000001 | 1 | 2,099,999,997,480,000 |
| 6930000 | 33 | 000000000000000000000000000000000 | 0 | 2,099,999,997,690,000 |
This gives us a precise understanding of Bitcoin's issuance consensus rule.
Note that 21 million bitcoin, 2,100,000,000,000,000 satoshis, was a lie.
It's actually 2,099,999,997,690,000 satoshis.
That's a 2,310,000 satoshi difference.
Thankfully it's deflationary trivia in our favor.
This is why we run the numbers.
Next we want to test if total issuance is equal to or less than the issuance consensus. Why "or less than"? The protocol rules do allow miners to irrationally not issue bitcoin, and this has happened due to bugs in proprietary mining software.
Miners issue bitcoin by creating a coinbase transaction, which is special because it has no inputs, and they put this coinbase transaction inside the block they are going to mine.
The mining process includes this special transaction, so the resulting nonce is uniquely tied to it. Only the miner that did the proof of work, hashed enough to find the winning nonce unique to the miner's block, can benefit from it.
The coinbase transaction does not just include the new bitcoin being issued, called the subsidy. It also includes transaction fees.
To calculate the transaction fees we add all of the outputs that are being spent and subtract all of the new outputs (excluding the coinbase transaction's new outputs).
This is the transaction fee revenue being paid to the miners. We can subtract it from the total coinbase claimed to derive actual new issuance.
If the miner pays themself even less than the transaction fees, then they are actually destroying bitcoin, permanently taking them out of the UTXO set.
The reconciling equation can be thought of this way:
Expected issuance = UTXO set + coinbase losses + unspendable outputs
We want to actually calculate this equation at every block height to potentially uncover a deflation or inflation bug.
What are unspendable outputs? Fabian Jahr has an in-depth description of them here: https://blog.okcoin.com/2020/05/12/btc-developer-asks-where-are-the-coins/
- Genesis block
- BIP30
- OP_RETURN
- MAX_SCRIPT_SIZE
- Other https://bitcointalk.org/index.php?topic=675321.0
We already know expected issuance at every block height from the above recalculation.
Here are the other two equations:
Coinbase losses = subsidy + transaction fees - coinbase outputs
Transaction fees = spent outputs - new outputs ex-coinbase
How can we operationally calculate the sum of the UTXO set, coinbase losses, and unspendable outputs at every block height? The Bitcoin blockchain is hundreds of gigabytes, iterating through it and parsing the relevant data is no small task.
Thankfully the same Fabian Jahr who identified the unspendables has been developing a data index in Bitcoin Core to gather statistics about the UTXO set at every block height.
bitcoin
This index is exactly what we need, by combining it with our own expected issuance calculations we can easily test our equations balance, that debits equal credits.
Our hero Fabian has also written a data exporter for this index.
bitcoinThis allows us to easily dump out a large ~109 MB CSV file.
At every block height, we can subtract total UTXOs and cumulative unspendables from the expected issuance to make sure Bitcoin's actual monetary policy is sound.
| Block Height | Expected Issuance | Sum of UTXOs | Unspendables and Coinbase Losses | Difference | |
|---|---|---|---|---|---|
| 0 | 5000000000 | 0 | 5000000000 | 0 | |
| 1 | 10000000000 | 5000000000 | 5000000000 | 0 | |
| 2 | 15000000000 | 10000000000 | 5000000000 | 0 | |
| 3 | 20000000000 | 15000000000 | 5000000000 | 0 | |
| 4 | 25000000000 | 20000000000 | 5000000000 | 0 | |
| ... | ... | ... | ... | ... | |
| 647664 | 1848540625000000 | 1848522337847248 | 18287152752 | 0 | |
| 647665 | 1848541250000000 | 1848522962847248 | 18287152752 | 0 | |
| 647666 | 1848541875000000 | 1848523587847248 | 18287152752 | 0 | |
| 647667 | 1848542500000000 | 1848524212847248 | 18287152752 | 0 | |
| 647668 | 1848543125000000 | 1848524837847248 | 18287152752 | 0 |
We can and should perform more tests on this data to try to identify exceptions that are not being accounted for, but being able to prove out expected issuance with actual balances is a crucial part of auditing Bitcoin's supply.