How Bitcoin Transactions Work: What Happens After You Hit Send

When you send bitcoin, nothing physical moves anywhere. Your wallet selects the digital "bills" you already received, signs a permission slip with your private key, and broadcasts it to thousands of computers around the world. Miners then seal it into a block roughly every ten minutes. The whole journey usually takes somewhere between ten minutes and an hour — and the fee you attach is what decides whether you wait ten minutes or ten hours. Here is exactly what happens at each stage, and what controls the timing.

Step 1: Your wallet picks which "bills" to spend

Bitcoin does not keep accounts with balances the way a bank does. It keeps UTXOs — unspent transaction outputs. Think of them as individual bills in your wallet. If you received 0.2 BTC once and 0.15 BTC another time, your wallet holds two "bills" totaling 0.35 BTC, not a single balance of 0.35.

When you send 0.3 BTC, your wallet must spend whole bills: it uses both UTXOs as inputs and creates two outputs — 0.3 BTC to the recipient's address and 0.0499 BTC back to you as change. The leftover 0.0001 BTC becomes the miner's fee. This is the worked example from Blockstream's transaction guide, and it shows the rule every transaction follows: inputs are consumed entirely, outputs are created fresh, and the fee is simply inputs minus outputs. There is no separate "fee field" in the transaction — the network infers it.

The detail most explainers skip: a UTXO is spent whole or not at all. There is no such thing as spending "part of" a UTXO. That is why change exists — and why your wallet handles it silently in the background.

Step 2: Your private key signs — nothing has left your phone yet

Before anything goes public, your wallet produces a digital signature with the private key tied to each input. The signature proves you control those bills without revealing the key itself. This is the moment people misunderstand most: nothing about the transaction is public, irreversible, or at risk while it sits unsigned on your device.

The point of no return is the broadcast. Before broadcasting, you can abandon or rebuild the transaction freely. After broadcasting, it is visible to the entire network and, in practice, you cannot take it back. Between those two moments, the network has no idea your transaction exists.

Step 3: The mempool queue, where your fee decides your wait

Your signed transaction is broadcast to connected nodes, each of which checks it — are the signatures valid, are the UTXOs really unspent, do the amounts balance — and relays it onward. Within seconds it reaches thousands of nodes, and each one parks it in its own mempool, a waiting area of valid-but-unconfirmed transactions.

Here is the mechanic that surprises newcomers: miners do not process this queue first-come, first-served. They pick transactions by fee rate — satoshis per virtual byte of transaction data. And the fee is priced on data size, not on the amount being moved. A $5 coffee payment and a $5 million transfer built from the same number of inputs and outputs pay exactly the same fee. Your wallet's fee is not a percentage; it is a bid for limited space in the next block.

Some live numbers make this concrete. On October 29, 2026, mempool.space recommended about 3 satoshis per virtual byte for fast confirmation. A typical one-input, two-output SegWit transaction is roughly 140 virtual bytes, so fast confirmation cost about 420 satoshis — roughly a third of a dollar with bitcoin near $79,000–$80,000. At the same moment, 61,488 transactions were waiting in the mempool and the chain stood at block 973,749. Fees move with demand; on congested days the same transaction can cost many times more.

One more gatekeeper lives at this stage: network policy refuses to relay outputs below a few hundred satoshis — the so-called dust limit — because spending them later would cost more in fees than they are worth. That is why your wallet will not let you send an absurdly tiny amount.

Step 4: A miner seals it into a block

Miners compete to bundle pending transactions into a block and solve the proof-of-work puzzle. The network retargets the puzzle's difficulty so that blocks arrive roughly every ten minutes on average — a design target going back to Satoshi Nakamoto's 2008 white paper (bitcoin.pdf). A block holds a few thousand transactions, and the miner keeps the fees of every transaction included.

The moment your transaction appears in a block, it has one confirmation. Every block stacked on top adds another. Here is the part people overstate: "wait for six confirmations" is a convention, not a protocol rule. It traces to the white paper's own analysis of how many blocks make an attack on the payment's history statistically impractical. Exchanges apply it differently — one to three confirmations for small amounts, six for large ones. Each additional block makes rewriting that part of history exponentially harder, which is why confirmations are the closest thing Bitcoin has to finality.

What your wallet quietly does behind your back

Two privacy habits run automatically in most modern wallets. First, your change often goes to a fresh address you control rather than back to the sending address, so your balance history is harder to piece together. Second, wallets generate a new receiving address for every payment you accept. Reusing one address is not dangerous to the transaction itself, but it lets anyone see your entire receiving history at that address — the reason wallets discourage it.

A related distinction worth knowing: in a self-custody wallet, your private keys live on your device. In a custodial wallet (an exchange app, for example), the company holds the keys and your "send" is really a request to them. Same interface, very different trust arrangement.

When a transaction gets stuck — and what you can actually do

A stuck transaction almost always has one cause: the fee was too low for the network's current demand. Your options depend on your wallet:

Wait. Blocks keep coming every ten minutes on average, and fees fall when demand cools. Most low-fee transactions confirm eventually without any action.

Replace it. If your wallet supports replace-by-fee (BIP 125), you can broadcast a replacement of the same transaction with a higher fee. Miners take the better-paying version. This only works if the original transaction was marked replaceable before sending — check your wallet's settings before you need it.

As the recipient, spend it. Child-pays-for-parent (CPFP) means you spend the unconfirmed coins you are about to receive, attaching a generous fee to the child transaction. A miner who wants the child's fat fee must confirm the parent too. It is the workaround when the sender cannot or will not bump the fee.

Let it expire. Default node policy drops unconfirmed transactions after about 336 hours — roughly two weeks (learnmeabitcoin's mempool reference). The coins are never "lost" in this scenario: an unconfirmed transaction never moved them, so after expiry your wallet can spend the UTXOs again. Note the honest caveat: some wallets automatically rebroadcast dropped transactions, which can make "waiting it out" take longer than two weeks.

What you cannot do is cancel. After broadcast there is no cancel button — only replacement, incentive, or patience.

A short checklist before you press send

1. Verify the address. Copy-paste it, then check the first and last characters. Bitcoin transactions have no customer support to reverse a mistyped address, and address-swapping malware is a documented attack.

2. Look at the fee your wallet suggests. Paying the suggested rate buys speed; lowering it saves money but risks the stuck-transaction scenario above. There is no universally right choice — it depends on how urgently the recipient needs the confirmation.

3. Confirm the amount twice. Once a transaction is confirmed, it is effectively irreversible. The ten seconds of re-checking is the cheapest insurance in the system.

4. Use a fresh address when receiving. It costs nothing and keeps your transaction history from being trivially linked together.

Sources and notes

The mechanics above follow Satoshi Nakamoto's white paper, Bitcoin: A Peer-to-Peer Electronic Cash System (bitcoin.org/bitcoin.pdf, October 2008); the UTXO worked example comes from Blockstream's transaction walkthrough; fee, mempool, and block-height figures are from mempool.space on October 29, 2026; mempool policy details (336-hour default expiry, 300 MB default cap) are from learnmeabitcoin's mempool reference. Fee and price figures change constantly — check current conditions before relying on any number above.

Educational content only — not financial advice. Sending cryptocurrency involves irreversible transfers; verify addresses and fees carefully.