There is no balance stored anywhere
A wallet shows you a number, so it is natural to assume that number is stored somewhere: a row in a table, a field on an account, a figure nodes debit and credit. It is not. Nothing in Bitcoin's consensus rules holds a balance, and nothing in them holds an identity either.
What the network holds is a set of unspent transaction outputs, usually shortened to UTXOs. Every satoshi in existence sits inside exactly one of them. A wallet produces your balance by scanning for the outputs it can sign for and adding up their amounts. That is why two wallets restored from the same seed can honestly report different balances: they scanned to different derivation depths. The balance was never a fact about the network. It is a fact about what one piece of software found.
This post assumes you already know what a transaction is and how it gets confirmed. It is about the state a transaction changes.
An output is an amount and a condition, and it is indivisible
An output has two parts and no others: a value in satoshis, and a scriptPubKey, the
condition that has to be satisfied to spend it. There is no owner field and no label. A
transaction consumes existing outputs as inputs and creates new ones.
The property everything else hangs on is that an input consumes its output in full. There is no partial spend and no mechanism for one. The Bitcoin developer documentation states it directly: "the full value of the included UTXOs must be spent or given to a miner as a transaction fee" (Bitcoin developer documentation, Transactions).
That is where change comes from. Hold one 0.4 BTC output, pay someone 0.1 BTC, and you cannot slice it. You spend the whole 0.4, create a 0.1 output for the recipient, and create a second output paying the remainder back to a condition you control. The change output is not a convenience feature. It is the only way to avoid handing the remainder to a miner.
The whitepaper's definition of a coin is the same idea from the other side: "a chain of digital signatures", each owner signing it over to the next (Bitcoin: A Peer-to-Peer Electronic Cash System, section 2). A UTXO is one link of that chain, unspent.
The UTXO set is the consensus state
Validating a transaction asks two questions: does every input reference an entry currently in the set, and does the witness satisfy that entry's condition. It never asks whether an account has enough. Connecting a block deletes the entries its transactions consumed and inserts the ones they created, and that is the entire state transition.
The set is therefore not an index maintained for convenience. It is the state, and every
full node you run keeps a copy in its chainstate database. Bitcoin
Core reports it through gettxoutsetinfo, whose txouts field is "the number of unspent
transaction outputs" (Bitcoin Core 31.0.0 RPC
reference). As of
17 August 2026 that count was roughly 167 million
(Blockchain.com, UTXO set size,
which moves daily).
The fee is what you did not claim
There is no fee field in a Bitcoin transaction. Serialise one and you find a version, a list of inputs, a list of outputs, witnesses and a locktime. The fee is a subtraction:
fee = sum(input values) - sum(output values)
Whatever you do not assign to an output, a miner takes. Spend a 1 BTC output, create a single 0.01 BTC output for the recipient, and you have paid a 0.99 BTC fee. The transaction is perfectly valid, and nothing in it marks that apart from a fee you meant to pay, because there is nothing to mark.
The best documented instance has exactly that shape. In block 807,057, mined on 10 September 2023, a transaction spent a single input of 19.89514072 BTC, created five outputs totalling 0.0740544 BTC, and stopped there. The remaining 19.82108632 BTC went to the miner (transaction d5392d47...). Paxos acknowledged that the transfer was its own, and F2Pool, which mined the block, chose to send the fee back on 15 September (Cointelegraph, 15 September 2023). Nothing in the protocol required that refund, and nothing in it would have prevented the loss.
Bitcoin Core treats this as a standing hazard. Its wallet refuses by default to send a
transaction whose absolute fee exceeds 0.1 BTC, the -maxtxfee default
(src/wallet/wallet.h),
and sendrawtransaction rejects a fee rate above 0.10 BTC per kvB unless maxfeerate is
overridden
(src/node/transaction.h).
Those guardrails exist because the fee is implicit and a badly built output list fails
silently.
Cost tracks the number of inputs, not the amount
Miners sell block space, so the fee a transaction needs is its size multiplied by a fee
rate. Size is driven by how many inputs you spend, and an input is far more expensive than
an output. Bitcoin Core's dust calculation writes the numbers down: a spendable P2WPKH
output serialises to 31 bytes and needs an input of at least 67 virtual bytes to spend,
once the witness discount defined in
BIP 141 is applied
(src/policy/policy.cpp).
Amounts do not appear in that calculation at all. Spending a 0.5 BTC output and spending a 20,000 satoshi output cost the same. A transaction sweeping forty small outputs is roughly forty times the size of one spending a single large one, and pays roughly forty times the fee to move the same money.
That is what dust is, stated precisely rather than as a vibe. The same file: "If you'd
pay more in fees than the value of the output to spend something, then we consider it
dust." At the default dustRelayFee of 3,000 satoshis per kvB, a P2WPKH output below 294
satoshis is dust and nodes will not relay a transaction creating one. That threshold is a
policy floor, not the economic line. The economic line moves with the fee market: at 50
sat per virtual byte, spending one input costs about 3,350 satoshis, so anything below that
is worth less than the act of moving it.
Consolidating small outputs while fee rates are low is the usual answer. It is also a trade, and what you are trading away is the next section.
Combining inputs is a claim about who owns them
Section 10 of the whitepaper concedes the problem in one sentence: "Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner."
That sentence is the foundation of most Bitcoin chain analysis. It is known as the common-input-ownership heuristic: when several outputs are spent as inputs to one transaction, assume a single party controlled all of them. It is a heuristic and not a rule, and CoinJoin exists specifically to falsify it, but on ordinary transactions it holds often enough to build a business on. Meiklejohn and colleagues used it in 2013 to collapse millions of addresses into a few thousand clusters (A Fistful of Bitcoins, IMC 2013).
Coin control, choosing which outputs a transaction spends instead of letting the wallet
decide, exists because of that. If one output came from an exchange that holds your
identity documents and another did not, spending them together links the two permanently,
and no later action undoes it: the blockchain is public and it
does not forget. Bitcoin Core ships -avoidpartialspends, which groups outputs by address
and takes all or none, and its own help text names both sides: "Privacy is improved as
addresses are mostly swept with fewer transactions and outputs are aggregated in clean
change addresses. It may result in higher fees"
(src/wallet/init.cpp).
Notice the shape of that. Consolidating is cheap later and links your coins now. Keeping outputs separate stays private and costs more to spend. No setting gives you both, and a wallet that does not expose the choice is making it for you.
What the model does not do
It does not give you an account. There is no object in Bitcoin that accumulates a position, which is why "my balance" is a wallet-side abstraction and not a consensus fact.
It does not track identity. Consensus deals in spending conditions. An address is a human-facing encoding of one of those conditions, produced by wallet software, and the validation code never sees it.
It does not record where a coin came from or whether two coins are yours. The heuristics that guess at the second one work because of how transactions are built, not because the protocol keeps the answer.
The abstraction is a good one, and it hides four things: outputs are spent whole, the leftover is the fee, the count of your outputs is what you pay for, and spending two together says they are related. Each of those arrives eventually, usually on the day the fee is larger than the payment, or the day a firm you have never dealt with knows which coins are yours. The set is the ledger. The balance is a summary someone wrote for your convenience.