The life of a transaction

From the outside, sending bitcoin looks like sending an email. You enter an address, enter an amount, press a button, and some minutes later it has arrived. Underneath, almost none of that is what happens — nothing is sent to the recipient, nothing is submitted anywhere in particular, and the thing that finally makes the payment real is a decision made independently by thousands of computers that have never heard of you.

This page follows one payment from a private key to a confirmed block. Not as instructions — there is nothing here to do — but because knowing the shape of it explains most of the advice on the rest of this site.

1It starts with a key that never moves

Your wallet holds a private key: an enormous random number. From it, a public key is derived by one-way maths, and from that, an address. The chain runs in one direction only — an address tells the world nothing useful about the key behind it, which is why publishing addresses is safe and why guessing backwards is not a viable attack.

The important property for what follows: the private key is never transmitted anywhere, at any stage. Not to the recipient, not to the network, not to a miner. It stays where it was generated. If you take one structural fact from this page, that is the one — and it is why a hardware wallet can safely be plugged into a compromised computer.

Keys, addresses, and UTXOs covers this layer properly. Here it is just the starting point.

2Building the transaction

The first surprise is that you do not spend a balance. There is no account holding a number. What you own is a set of discrete previous outputs — UTXOs — each one a specific chunk of bitcoin from a specific earlier transaction, each one spendable only in full.

So a transaction is a short document that says: these particular previous outputs are being consumed, and here is where their value goes instead. Inputs point backwards at outputs of earlier transactions. Outputs create new chunks, one to the recipient and usually one back to yourself as change.

Everything so far is just arithmetic on public data. Anyone could compose this document about your coins. What they could not do is the next step.

3Signing, and the number that must never repeat

Signing produces a proof that the holder of the private key authorised this exact transaction — not a password, not an unlock, but a piece of mathematics that anyone can verify against your public key and nobody can produce without your private one.

What gets signed matters. By default a signature commits to the whole transaction: every input, every output, every amount. Change a single character of the destination address afterwards and the signature stops verifying. This is precisely why checking the address on the signing device's own screen is worth doing — the device shows you what it is about to commit to, and once committed, the details cannot be edited by malware on the computer.

A hardware wallet held in one hand mid-confirmation, thumb resting on the button, its small screen sharp and readable while the laptop behind it falls completely out of focus.

Image to come

The nonce

Each signature also consumes a fresh secret number, used once and discarded, called a nonce. It never leaves the device and never appears in the transaction — but it is arguably the most dangerous number in the whole process.

If a wallet ever signs two different transactions using the same nonce with the same key, anyone who sees both signatures can recover the private key outright. Not brute-force it — solve for it, with school algebra, in a fraction of a second. This is not theoretical: it is how the PlayStation 3's signing key was extracted in 2010, and a 2013 flaw in Android's random number generator drained real bitcoin wallets by exactly this route.

• The danger is not a weak nonce, it is a repeated one. Two signatures are enough.
• Modern wallets avoid the problem by deriving the nonce deterministically from the private key and the transaction itself, so it cannot repeat unless the transaction does.
• A malicious signing device could go the other way — subtly biasing nonces so that its signatures leak your key a few bits at a time, in public, with nothing looking wrong. Some devices support anti-exfil protocols where your computer contributes randomness to each nonce and can verify it was used, which closes that door. It is worth knowing the attack exists when you choose hardware.

The same principle applies to the newer Schnorr signatures used by Taproot addresses. Different mathematics, identical rule: the nonce is used once, or not at all.

4Broadcast, which is not a submission

The signed transaction now needs to reach miners, and here is the second surprise: there is nowhere to send it. No server, no submission endpoint, no queue with an operator.

Your wallet hands the transaction to the handful of peers it is connected to. Each of those checks it, and if it is valid, passes it to their peers, who do the same. Within a couple of seconds it has reached most of the network by nothing more organised than gossip. Nobody accepted it and nobody could have refused it on the network's behalf — each node simply decided independently whether to keep passing it along.

Note what did not happen: the recipient was not contacted. They find out they have been paid the same way everyone else does, by watching the chain. A bitcoin payment is not delivered to anyone; it is announced to everyone.

5The mempool: a waiting room nobody owns

Until a miner includes it, your transaction sits in the mempool — the pool of valid, unconfirmed transactions each node keeps in memory.

And there is no such thing as the mempool. Every node keeps its own, they differ from each other, and none is authoritative. When a block explorer shows you "the mempool", it is showing you one particular node's view of the queue.

A large split-flap departure board in a station, most rows reading as waiting rather than departing, photographed from below so the board fills the frame.

Image to come

Miners are not obliged to take transactions in order, and they do not. They assemble the most profitable block they can, which in practice means selecting by fee rate — satoshis per unit of transaction size, not total fee. A physically small transaction paying a modest fee can easily outrank a large one paying more in absolute terms.

• A transaction in the mempool has not happened. It is a proposal that most of the network currently considers valid and plausible.
• It can be replaced. Fee too low? Sign a replacement paying more and the network will generally prefer it — useful when you underpaid, and the reason zero-confirmation payments cannot be treated as settled.
• It can simply expire. Nodes evict transactions when their mempool fills, and drop them entirely after about two weeks by default. Nothing is refunded because nothing was ever taken — the coins never left your control.
• Congestion is a market, not an outage. When blocks are full, the fee needed to be selected rises. Nothing is broken; you are bidding for space.

6Mining, and the other nonce

A miner gathers transactions into a candidate block, summarises them all into a single fingerprint called a merkle root, and builds an 80-byte header containing that root, the previous block's hash, a timestamp, and the current difficulty target.

Then the work: hash the header, and check whether the result falls below the target. It almost certainly does not. So change one field and hash again. That field is the header's nonce — a number with no meaning whatsoever, existing purely to be changed so the header hashes differently.

The header nonce is only 32 bits, so modern hardware exhausts all four billion possibilities in well under a second. Miners therefore also vary a spare field inside the block's first transaction, which changes the merkle root and hands them a fresh nonce range to grind through — and repeat, quadrillions of times per second across the network, until someone's header comes out below the target.

Whoever finds one broadcasts the block immediately. Everyone else verifies it in milliseconds, abandons the candidate they were working on, and starts again on top of the new tip. The difficulty target adjusts every 2,016 blocks so that this contest keeps resolving roughly every ten minutes no matter how much hardware joins or leaves.

7Your node has the final say

The block arrives at your own node, and this is the part people skip. Your node does not accept it because a miner spent money producing it. It re-verifies everything, from scratch, for itself:

• That the block's own proof of work genuinely meets the current target.
• That every input in every transaction refers to an output that exists and has not already been spent, checked against the node's own UTXO set.
• That every signature is valid for the key it claims to come from.
• That the block claims no more subsidy than the schedule permits, and breaks no other consensus rule.
• That the whole thing fits the size and weight limits.

Fail any of these and the block is discarded, regardless of how much work is behind it. This is the practical meaning of the point made in the problem bitcoin solved: mining decides the order of valid transactions, and has no authority over what counts as valid. That authority is distributed across every node independently enforcing the same rules — and if you run one, you are one of them.

Only after those checks pass does your wallet show one confirmation. Everything before that moment was, from your node's point of view, a rumour it had not yet finished checking.

8Confirmations are depth, not status

One confirmation means one block. Six means five more were built on top. Nothing changes state along the way; what changes is how much work an attacker would have to redo to remove your transaction, and that grows with every block.

Occasionally two miners find a block at nearly the same moment and the network briefly follows two tips. Within a block or so, one side gains work, the other is abandoned, and its transactions return to the mempool to be mined again. This is ordinary and self-correcting — and it is the concrete reason a single confirmation is good rather than final.

The short version

A key that never moves signs a document that consumes specific earlier outputs. That document is gossiped to strangers, none of whom can accept or reject it on anyone else's behalf. It waits in a queue that has no owner, gets selected by a miner competing to guess a meaningless number, and is finally made real by your own computer independently checking every claim in the block that contains it.

There is no step in that sequence where an institution grants permission. That is the entire design, and it is why the responsibility for your keys, your verification, and your backups cannot be handed to anyone else — there is nobody in the system to hand it to.