You tap Send, pick an amount, and your wallet does something that looks suspiciously simple. Under the hood, it’s anything but. To pay you don’t “withdraw” a number — you reach into a pile of coins you already hold, hand whole ones over, get change back, quietly tip a miner, and then broadcast the whole bundle into a global waiting room to be picked up. This lesson follows one bitcoin payment along that entire journey, and finally demystifies the part everyone grumbles about and almost nobody understands: the fee — where it comes from, who gets it, and why it has nothing to do with how much you’re sending.
Your Balance Is a Pile of Coins (UTXOs)
Before you read — take a guess
Guess before reading: when your wallet shows '0.8 BTC', what is actually stored on the Bitcoin blockchain?
You met UTXOs back in crypto-basics; here’s the deepened version, because everything in this lesson hangs off it. UTXO stands for Unspent Transaction Output. Every time someone pays you, the payment shows up as an output of their transaction. Until you spend it, it sits on the chain unspent — like an uncashed cheque made out to your keys. So your “balance” is really a wallet full of discrete coins of various sizes: maybe a 0.5 BTC chunk, a 0.2 BTC chunk, and a 0.1 BTC chunk, adding up to the 0.8 BTC your app shows.
The crucial rule — the one that drives change, fees, and coin selection — is that you spend UTXOs whole. Just as you can’t tear a 20-dollar bill in half, you can’t spend “part of” a UTXO. To pay, you consume one or more whole coins as inputs and create brand-new coins as outputs. The chain’s record of what you own is always just the set of outputs nobody has spent yet.
Watch the difference between this coin-like model and a plain bank balance. Hit “Send a payment” and keep your eye on the left (UTXO) side: a whole coin lifts out toward the recipient, and a smaller change chip floats right back to you.
UTXO model — Bitcoin
Account model — Ethereum
Same payment, two bookkeeping styles: UTXO consumes whole coins and hands back change, while the account model just lowers one running balance.
Your wallet holds three UTXOs: 0.5, 0.2 and 0.1 BTC. Which statement is true?
Inputs, Outputs, and Change
Before you read — take a guess
Guess before reading: you want to send 0.3 BTC but your smallest coin is 0.5 BTC. What does your wallet do?
A bitcoin transaction has two sides:
- Inputs — references to UTXOs you own, each one unlocked by your signature (lesson 5). An input says “I’m spending this specific coin, and here’s the proof I’m allowed to.” The inputs must add up to at least the amount you’re sending plus the fee.
- Outputs — the new coins this transaction creates: one (or more) to the recipient, and usually one back to yourself.
That last one is change. Because you spend whole coins, your inputs almost always exceed what you owe — so the leftover is sent back to you as a new UTXO at a change address your wallet controls. It’s the digital twin of paying a 7-dollar coffee with a 20-dollar bill and getting 13 dollars back. The twist: in Bitcoin you create the change output yourself, as part of the very same transaction. There’s no cashier handing it over; your wallet writes the change output in for you.
Change is your own money — not a cost
Seeing a “change” output is completely normal and means the system is working. It is your leftover money returning to you, not a charge. The only value that actually leaves your control is the fee. If you spend a 0.5 BTC coin to send 0.3 BTC, roughly 0.2 BTC comes straight back to you as change.
Connect every term to its correct meaning.
Pick a term, then click its definition.
Where the Fee Actually Comes From
Before you read — take a guess
Guess before reading: how does a Bitcoin transaction specify its fee?
Here’s the part that surprises everyone. A Bitcoin transaction has no fee field at all. Instead:
Fee = total inputs − total outputs. Whatever value you put into the transaction (your inputs) but don’t assign to any output (recipient + change) is left over — and the miner who includes your transaction simply claims that leftover as the fee. To pay a bigger fee, you make your change output a little smaller. To pay a tiny fee, you make it a little bigger. The “fee” is just the gap you choose to leave.
Let’s make it concrete. Say you spend a single 0.5 BTC coin to send 0.3 BTC, and you set your change output to 0.1999 BTC:
| Part of the transaction | Amount (BTC) |
|---|---|
| Input (one UTXO you own) | 0.5000 |
| Output → recipient | 0.3000 |
| Output → change (back to you) | 0.1999 |
| Fee (inputs − outputs, claimed by the miner) | 0.0001 |
Inputs total 0.5; outputs total 0.4999; the 0.0001 BTC gap is the fee. Nobody wrote “0.0001” into a fee box — it’s just the slice you chose not to send anywhere, and the miner who packs your transaction into a block scoops it up.
Myth: 'The fee goes to Bitcoin / a company / the network treasury'
There is no Bitcoin company, no head office, and no treasury to pay. The fee goes to the miner who includes your transaction in a block — the same proof-of-work miner from lessons 2–3 who spent real electricity to build that block. You’re tipping the person who seats your transaction, alongside the block subsidy they already earn for mining it.
In the worked example above, what would happen if you set your change output to 0.2000 BTC instead of 0.1999 BTC?
Fee Rate: Paying by Size, Not Amount
Before you read — take a guess
Guess before reading: a Bitcoin transaction's fee mostly depends on…
If the fee isn’t a percentage of the amount, what does set it? Size. Miners care about one thing: getting the most fee revenue into a block that has a fixed capacity. So they value a transaction by its fee rate — fee divided by size — measured in satoshis per virtual byte (sat/vByte). (A satoshi is the smallest unit of bitcoin, one hundred-millionth of a BTC. A virtual byte is Bitcoin’s way of measuring how much block space a transaction occupies.)
You don’t really choose a total fee; you choose a fee rate, and the total falls out of rate × size. The size, in turn, depends mostly on how many inputs you bundle. A payment that gathers ten little coins is physically bigger — ten signatures to include — than one that spends a single fat coin, even if the second moves a hundred times more money.
Why a small payment can cost MORE than a huge one
Send 0.001 BTC by sweeping together 20 tiny “dust” UTXOs and your transaction is large — 20 inputs, 20 signatures — so at a given sat/vByte it costs a lot. Send 50 BTC from one clean UTXO and it’s tiny — one input — so it’s cheap. Fees track bytes, not value. That’s why letting your wallet fill up with dust is a quiet way to overpay later.
Miners fill each block highest-fee-rate first, so a higher sat/vByte jumps the queue. We’ll watch that auction in the next section.
Sort each change into whether it tends to raise your total fee or leave it unaffected.
Place each item in the right group.
- Bundling many small UTXOs as inputs (a bigger transaction)
- Sending during heavy mempool congestion
- Doubling the BTC amount you send (same one input)
- Bidding a higher sat/vByte fee rate
- The recipient living on another continent
- Using a longer or shorter wallet password
From Broadcast to Confirmation
Before you read — take a guess
Guess before reading: right after your wallet finishes building and signing a payment, the transaction is…
Every Bitcoin payment runs the same relay. Here’s the whole trip:
| Stage | What happens |
|---|---|
| 1. Build | Your wallet selects which UTXOs to spend and writes the inputs, outputs, and change |
| 2. Sign | You authorize each input with your signature (lesson 5) — the proof you control those coins |
| 3. Broadcast | The signed transaction is sent out to the network’s nodes |
| 4. Mempool | It sits, valid but unconfirmed, in the pool of pending transactions |
| 5. Block inclusion | A miner selects it (highest fee rate first) and packs it into a block |
| 6. Confirmations | The block is mined onto the chain; each later block adds another confirmation |
A confirmation is just a block stacked on top of the block holding your transaction. One confirmation = your transaction is in the latest block. Six confirmations = five more blocks have piled on top. Why count them? Because reversing your payment would mean re-mining your block and every block above it faster than the rest of the network mines new ones — exactly the proof-of-work tug-of-war from lessons 2–3. The deeper your transaction is buried, the more work an attacker must redo. So more confirmations = harder to reverse = safer, and ~6 is the common “very safe” threshold for large amounts.
Myth: 'One confirmation means it's irreversible'
One confirmation is good but not final. A single block can occasionally be displaced by a competing one (a brief “reorg”). Each extra confirmation makes that exponentially less likely, which is why high-value payments wait for several. Deep enough = effectively irreversible; just-included = not quite there yet.
Sort each event into the stage of a transaction's life where it belongs.
Place each item in the right group.
- It competes against other pending transactions on fee rate
- More blocks stack on top, adding confirmations
- Your wallet signs each input with your private key
- Your wallet picks which UTXOs to spend and writes the change output
- The transaction sits unconfirmed, waiting to be picked
- A miner packs it into a block
When the Mempool Gets Crowded
Before you read — take a guess
Guess before reading: your transaction has been stuck pending for hours. The most likely reason is…
Each block holds only so many virtual bytes, and a new one arrives roughly every ten minutes. When more people want to transact than fit in the next few blocks, the mempool fills up and a bidding war breaks out: the going fee rate climbs as everyone tries to outbid everyone else for the limited seats. In quiet times the mempool nearly empties and a few sat/vByte sails through; in a frenzy the clearing rate can spike dramatically. Nothing about your transaction changed — the competition did.
Drag your fee up and down below, hit produce next block, and watch whether your transaction grabs a slot or gets left in the mempool. There’s no magic “correct” fee — it’s whatever beats the others bidding for the same block.
Next block (limited space)
Mempool (waiting to confirm)
A block has limited space, so producers grab the highest-fee transactions first. Bid a higher fee and you confirm sooner; bid too low and higher bidders fill the block ahead of you.
What if you already broadcast a transaction with too low a fee and it’s stuck? It is not lost forever. You have options:
- Replace-by-Fee (RBF): re-broadcast the same transaction with a higher fee rate, replacing the stuck one and jumping the queue. (Your wallet must have flagged it as replaceable.)
- Child-Pays-For-Parent (CPFP): spend the stuck transaction’s change output in a new, high-fee child transaction. A miner who wants the juicy child fee must include the cheap parent too, dragging both into a block.
- Just wait: if congestion eases, even a low-fee transaction can confirm later. And if it never confirms, it eventually drops out of mempools and the coins are simply spendable again — they were never gone.
Myth: 'A stuck transaction is lost money'
A pending transaction hasn’t moved any coins yet — it’s still just an offer sitting in the mempool. It can confirm later when fees drop, be bumped via RBF, be rescued via CPFP, or quietly expire from the mempool, leaving your UTXOs fully spendable. Stuck ≠ gone.
Pick the right word for each blank.
Pick the right option for each blank, then check.
A signed transaction is broadcast to and waits in the . Its fee is the gap between and outputs, claimed by the who includes it. Fees are priced per , and each block stacked on top adds a .
Recall from earlier lessons: what is it about Bitcoin's design that makes deep confirmations expensive to reverse?
The Big Picture
One payment: built from coins you hold, signed, broadcast, parked in the mempool, and bid into a block whose miner pockets the leftover as a fee. Chunk the whole journey into one picture:
Big picture
The life of a bitcoin transaction
- A bitcoin transaction
- Built from coins
- Balance = a pile of UTXOs
- Spend whole coins as inputs
- Create outputs + change back to you
- The fee
- Fee = inputs − outputs (no fee field)
- Goes to the miner, not a company
- Priced by size in sat/vByte, not amount
- The journey
- Sign each input (lesson 5)
- Broadcast to nodes → mempool
- Miner includes it (highest fee rate first)
- Confirmations stack → safer
- Congestion
- Full mempool → fee rates rise
- Stuck? RBF or CPFP to unstick
- Pending ≠ lost
- Built from coins
A mixed recap — it pulls from everything above:
How is a Bitcoin transaction's fee determined?
Check your answer to continue.
Key Takeaways
What to remember
- Your balance is a pile of UTXOs — discrete unspent coins your keys control. To pay, you spend whole coins as inputs and create outputs; the leftover comes back as a change output to an address you control.
- The fee has no field: fee = inputs − outputs. Whatever value you don’t assign to an output, the miner who includes your transaction claims. The fee goes to that miner — not to a Bitcoin company, the recipient, or a treasury.
- Fees are priced by size, not amount. You bid a fee rate in sat/vByte, and miners fill blocks highest-rate-first. A small payment bundling many inputs can cost more than a huge one with a single input.
- The journey: build → sign each input → broadcast to nodes → wait in the mempool → a miner includes it → confirmations stack. More confirmations = harder to reverse = safer (~6 is the common “very safe” mark).
- Congestion drives a fee auction. When the mempool is full, the going rate rises and low-fee transactions stall. A stuck transaction isn’t lost — bump it with RBF, rescue it with CPFP, or just wait.
You’ve now followed a payment from your screen into a block — but who actually checks that your transaction is valid before relaying or mining it? Next: nodes and full verification, the unsung machines that independently enforce every rule of Bitcoin so no one has to be trusted.