Bitcoin · Fundamentals
How Bitcoin Transaction Fees Actually Work
Bitcoin fees are priced by how much block space your transaction occupies — not by how much money you move. That single fact explains most of what confuses people.
The most common misconception about Bitcoin fees is that they scale with the amount being sent. They do not. Moving 0.001 BTC and moving 1,000 BTC can cost exactly the same, and frequently do. What you are paying for is space in a block, and the price of that space is set by an ongoing auction.
Block space is the scarce good
Every Bitcoin block has a hard ceiling on how much data it can contain. Blocks arrive roughly every ten minutes on average, and the network has no mechanism to produce them faster when demand rises. When more people want to transact than there is space for, the excess sits in the mempool — each node’s holding area for valid transactions that have not yet been mined.
Miners assemble blocks to maximise their own revenue, which means they select transactions offering the most fee per unit of space. Your transaction is not competing on how much it pays in total; it is competing on how much it pays per byte.
The unit that matters: sat/vB
Fee rates are quoted in satoshis per virtual byte (sat/vB). A satoshi is one hundred-millionth of a bitcoin. A “virtual byte” is a weight-adjusted measure introduced with SegWit: signature data (the witness) is counted at a quarter of its raw size, while the rest of the transaction counts in full.
This is why SegWit and Taproot addresses are cheaper to spend from. It is not a discount granted by goodwill — the signature data genuinely occupies a discounted position in the block weight formula, and address types that put more of their data in the witness benefit accordingly.
When a wallet shows you three options — economy, standard, priority — it is almost always showing you three different sat/vB bids against its estimate of current mempool conditions.
What makes a transaction large
Transaction size is driven overwhelmingly by the number of inputs, not outputs. Each input carries its own signature, and signatures are the bulk of the data.
This has a practical consequence that surprises people: a wallet holding one large unspent output can send cheaply, while a wallet holding the same total balance spread across two hundred small outputs will pay a great deal more to send the same amount. Those small outputs — often the residue of many small deposits — are sometimes called dust, and in a high-fee environment an output can become economically unspendable, where spending it costs more than it is worth.
The countermeasure is consolidation: during a quiet period, deliberately send your own coins to yourself, combining many inputs into one. You pay a fee once, at a cheap moment, to avoid paying repeatedly at expensive ones.
When a transaction gets stuck
A transaction that underbids does not fail. It sits in the mempool, unconfirmed, sometimes for a long time. Nodes eventually evict transactions when their mempool fills, but there is no fixed expiry and no refund — the transaction is simply not yet part of the chain.
Two standard remedies exist.
Replace-by-fee (RBF) lets the sender broadcast a replacement of the same transaction carrying a higher fee. The original must have signalled that it is replaceable, and modern wallets generally do so by default. The replacement supersedes the original; only one of them can ever confirm.
Child-pays-for-parent (CPFP) works from the other side. The recipient — or anyone holding one of the transaction’s outputs — spends that unconfirmed output in a new transaction carrying a fee high enough to cover both. Because a child cannot be mined without its parent, a miner taking the profitable child must also take the unprofitable parent. This is the tool available when you did not send the transaction and therefore cannot replace it.
Why fee estimates go wrong
Fee estimators extrapolate from recent blocks and current mempool contents. They are reading the present and assuming it persists. They cannot see a large batch of transactions that has not been broadcast yet, and they cannot predict whether the next block arrives in two minutes or forty — block intervals are random, clustering around ten minutes but with a long tail.
An estimate of “confirms within one block” is therefore a probability, not a promise. Estimators tend to be least reliable exactly when reliability matters most: during a sharp, fast rise in demand, when the conditions they are extrapolating from are already out of date.
Practical takeaways
- Fees depend on transaction size, not transaction value.
- Inputs dominate size; a fragmented wallet is an expensive wallet.
- Native SegWit and Taproot address types genuinely cost less to spend.
- Consolidate when the network is quiet, not when you urgently need to send.
- If you sent it, RBF. If you are waiting to receive it, CPFP.
- Treat every fee estimate as a bid under uncertainty, not a quoted price.
None of this changes with the market. The auction mechanism is a property of the protocol, and understanding it is what separates paying a sensible fee from paying whatever the default slider suggested.
Educational content only. Nothing here is financial advice.