On May 18, 2010, a programmer named Laszlo Hanyecz posted an offer on the Bitcoin forum: he would pay 10,000 bitcoin for "a couple of pizzas."1 Four days later another forum member took him up on it, and Laszlo pressed send. Later that day he posted again to report that he had "successfully traded 10,000 bitcoins for pizza." The transaction is still on the ledger, in block 57,043, recorded at 18:16 UTC on May 22, 2010.2
Look closely at it and it shows how every Bitcoin payment works, then and now. Laszlo did not send one coin worth 10,000 bitcoin, because there is no such thing. His wallet gathered 131 separate amounts: 111 of them a hundredth of a bitcoin each, and twenty larger ones ranging from 80 bitcoin to more than 3,700. Together they came to 10,000.99 bitcoin. Out came a single payment of exactly 10,000, and the missing 0.99 went to the miner as a fee.2
That is the first of five things that happen every time anyone presses Send.
Building the Transaction
Your bitcoin is not a file on your phone. It is a set of entries on Bitcoin's shared ledger, each one an amount locked so that only your key can spend it. So pressing Send does not move a file anywhere. It starts with your wallet writing a transaction.
The wallet picks one or more of your entries to use up; these are the transaction's inputs. An entry can only be spent whole, the way a bill can only be handed over whole, so the transaction creates new entries called outputs: one for the person you are paying and, usually, one returning the rest to you as change.3 Every entry on the ledger is an output of some earlier transaction, and one that has not been spent yet has a name: an unspent transaction output, or UTXO. The balance your wallet shows is simply your UTXOs added up. Bitcoin itself keeps no balances at all.
There is no line in a transaction for the fee. The wallet just makes the outputs add up to a little less than the inputs, and the gap is the fee, collected by whichever miner puts the transaction in a block. A transaction that tries to pay out more than it takes in is refused outright.4 Laszlo's transaction had no change output; its 0.99-bitcoin gap was all fee.
Signing It
Next, the wallet signs the transaction with your key. The signature proves that whoever holds that key approved this exact transaction, because it is worked out from the transaction's details: which entries it spends, how much goes where, and to whom.3 Change the amount or the destination by even a little and the signature no longer fits. And the key itself never leaves your wallet. Only the signed transaction goes out.
Node to Node
Now the transaction has to reach the network. Your wallet hands it to a node, one of the computers that keep a full copy of the ledger. Many phone wallets send it to a server run by the wallet's maker, which passes it on; some people run a node of their own.
Every node checks a transaction before it does anything with it. Are the signatures real? Are the entries it spends still unspent? Does it pay out no more than it takes in?4 A transaction that fails stops right there. One that passes goes on to the other nodes this node is connected to, and each of them checks it again for itself before passing it further. Node by node it spreads, and within seconds thousands of nodes around the world have a copy.5
This is the moment the person you paid sees the transaction arrive, usually marked "pending." Their wallet has seen it, but it is not in the ledger yet. It is also what people mean when they say Bitcoin payments are instant. Sending is instant. Settling takes longer.
The Waiting Room
So the transaction waits. Each node keeps its own list of transactions that are not in a block yet, called its mempool, short for memory pool. There is no single mempool: every node has its own, with its own size limits, and the lists do not always match.6 On most days tens of thousands of transactions are waiting; over the year to October 2026, the typical count was around 59,000.7
Miners build blocks from these lists, and they usually pick the transactions that pay the highest fee for the space they take, adding them until the block is full.8 A new block arrives about every ten minutes on average and holds a few thousand transactions; in late October 2026 a typical block held around six thousand.7 That is why the fee your wallet chooses affects how long you wait. When the list is long, a higher fee usually means a shorter wait. A transaction paying too little can even wait so long that nodes drop it, and in that case nothing was spent at all.6
Into a Block
Then a miner includes your transaction in a block. The block goes out to every node, and each node checks the whole block for itself, then updates its copy of the ledger and clears those transactions from its waiting list.9 The UTXOs you spent are now gone from every copy of the ledger. The person you paid has a new UTXO that only their key can spend, and your change is a new UTXO of your own. Their wallet changes from "pending" to "confirmed."
One confirmation means the transaction is in one block. Each block added after that counts as one more confirmation, and each makes the transaction harder to undo. Why a block is not quite final, and how many confirmations are enough for what, is the subject of why Bitcoin transactions need confirmations.
So here is what pressing Send does. Your wallet builds a transaction from your UTXOs and signs it with your key. Nodes check it and pass it around the world in seconds. It waits in their mempools until a miner puts it in a block. And every block after that is one more confirmation. Laszlo's pizza payment went through those same steps in 2010, and it has been sitting in block 57,043 ever since, confirmed by every block that has come after it.
Lesson 4 of the course walks through transactions and the network behind them, including why a Bitcoin payment is a signed message rather than a bank transfer. Why it matters that money can move without a bank in the middle is where the free first lesson begins.
Sources
- Laszlo Hanyecz, "Pizza for bitcoins?" Bitcointalk forum, May 18 and May 22, 2010.
- mempool.space, the pizza transaction in block 57,043: 131 inputs totaling 10,000.99 bitcoin, one output of 10,000 bitcoin, and a fee of 0.99 bitcoin.
- Bitcoin developer guide, "Transactions," on inputs, outputs, UTXOs, change and signatures.
- Bitcoin Core 31.0 source, tx_verify.cpp, the checks on a transaction's inputs and its fee.
- Bitcoin Core 31.0 source, net_processing.cpp, how nodes pass transactions to their peers; propagation measurements in Dotan and others, "Survey on Cryptocurrency Networking," 2020.
- Bitcoin Core 31.0 source, mempool_options.h: by default each node's mempool holds up to 300 MB, and transactions expire after two weeks.
- mempool.space, waiting transactions and transactions per block, checked October 28, 2026. Over the previous year the count of waiting transactions ranged from about 7,400 to about 156,000, with a median near 59,000; the 15 blocks up to height 973,547 held a median of 6,061 transactions.
- Bitcoin Core 31.0 source, miner.cpp, how a block is filled highest fee rate first. Miners may choose differently.
- Satoshi Nakamoto, "Bitcoin: A Peer-to-Peer Electronic Cash System," 2008, section 5 (Network).