Auditing Bitcoin Supply

Let's prove out expected Bitcoin issuance with actual balances.

Auditing Bitcoin Supply

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:

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.

Coinstats Index (without UTXO set hash) by fjahr · Pull Request #19521 · bitcoin/bitcoin
This is part of the coinstats index project tracked in #18000While the review of the new UTXO set hash algorithm (MuHash) takes longer recently #19328 was merged which added the possibility to run...

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.

rpc: Add dumpcoinstats by fjahr · Pull Request #19792 · bitcoin/bitcoin
Requires #19521 (this PR only adds the last commit).The rpc dumpcoinstats dumps the content of the coinstats index into a CSV file for auditing purposes.

This 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 HeightExpected IssuanceSum of UTXOsUnspendables and Coinbase LossesDifference

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.