A Bitcoin supply figure can look precise to eight decimal places while leaving its most important assumption unstated. Is it counting the coins permitted by the issuance schedule, the value currently recorded in unspent outputs, or coins whose owners can still access them? Those quantities need not match.
Understanding the distinction helps readers evaluate dashboards and scarcity claims. It also explains what a Bitcoin node can verify directly and where an analyst must introduce assumptions.
Start with the block subsidy
Bitcoin Core calculates a block's permitted subsidy from its height. In the v31.1 implementation, the calculation starts with 50 BTC and repeatedly halves that amount. Mainnet sets the halving interval to 210,000 blocks. These are block-based rules; calendar dates are estimates of when the relevant heights will arrive. Core's subsidy calculation, mainnet's consensus parameters
For example, applying that schedule at height 840,000 produces a subsidy of 3.125 BTC. The familiar 21 million ceiling summarizes the diminishing issuance schedule. Integer arithmetic eventually rounds the permitted subsidy down to zero; it does not keep creating indefinitely smaller fractions of a satoshi. This is a calculation from the documented rule, not a measurement of today's circulating supply. The integer subsidy implementation
Core rejects a block when its coinbase transaction pays more than the allowed subsidy plus transaction fees. That maximum does not require a miner to claim every available satoshi. Consequently, adding the scheduled allowances is not automatically the same as measuring what remains in the ledger. Coinbase reward validation
Separate new coins from fees
The coinbase transaction is the first transaction in a block. Its reward combines newly issued subsidy with fees from included transactions. Ordinary transactions consume earlier outputs, and the difference between input and output value can become a miner's fee. Fees therefore transfer existing value; counting the full miner reward as fresh issuance would double-count that component. Bitcoin's transaction and block rules
Consider a purely illustrative block with a 3.125 BTC subsidy and 0.1 BTC in fees. A miner claiming the full reward receives 3.225 BTC, but only 3.125 BTC comes from the subsidy. The remaining 0.1 BTC already existed in the transactions' inputs. The distinction matters whenever a chart labels miner revenue as supply growth.
Understand what an unspent total includes
Bitcoin Core's gettxoutsetinfo interface reports statistics about the unspent transaction output set, commonly called the UTXO set. Its total_amount field sums the coins in that set; height and bestblock identify the chain position being measured. It also counts outputs separately, so the number of outputs should not be confused with the number of bitcoins. The documented UTXO statistics
With the coin statistics index, the interface can also report amounts permanently excluded from that set. Its categories include the genesis subsidy, provably unspendable scripts and historical duplicate-transaction effects. These are accounting distinctions visible to the software. They do not constitute a census of people who have misplaced their keys. Historical-height queries require that index, and an unindexed calculation may take time. Available fields and index requirements
Lost keys leave a different problem
Bitcoin.org's FAQ explains that losing a wallet's necessary private keys does not erase the associated bitcoins from the blockchain. The record can remain while the ability to authorize a spend is gone. What happens when bitcoins are lost
The practical inference is that an old, unmoved output is not by itself proof of loss. Long-term storage and an inaccessible wallet can both produce years of inactivity. Estimates that subtract dormant coins should therefore disclose their age thresholds and other assumptions. Such an estimate may be useful, but its precision depends on a model rather than a direct observation of every owner's ability to spend.
Make a comparison reproducible
Before comparing node-derived figures, establish which network and chain position were measured. Core's getblockchaininfo reports the network name, validated block height, best block hash, verification progress and an initial-download indicator. A node still catching up cannot supply an up-to-date mainnet total merely because its output contains many decimal places. Blockchain processing information
A useful published figure should identify its definition, software or data source, measurement time and block hash. If it subtracts estimated lost coins or excludes particular holdings, state those adjustments separately. That small amount of context turns a striking number into something another reader can check.
The goal is a supply claim that answers a clear question. The issuance rules describe what may be created, ledger statistics describe recorded outputs, and accessibility estimates add assumptions about control. Keeping those layers visible makes disagreements between dashboards easier to investigate.