Follow one payment.

Spend old outputs. Create new ones.

Bitcoin does not begin with a single balance under Maya’s name. It tracks amounts left by earlier transactions that have not yet been spent. Each comes with conditions that a later payment must satisfy.

These are unspent transaction outputs, usually shortened to UTXOs. Maya’s wallet adds up the ones it can spend and shows her a balance.

In this hypothetical example, it chooses one output worth 80,000 sats. The payment creates 50,000 sats for her friend and 29,000 sats of change for Maya. The remaining 1,000 sats is the transaction fee.

80,000 in equals 50,000 to her friend, 29,000 back to her and 1,000 in fees. The old output is spent whole. New outputs replace it; the change is not a refund sent by the friend.

A signature is the beginning of the checks.

The wallet constructs a transaction and uses the relevant key to sign it. In an ordinary payment, the signature commits to the important payment details, including the destination and amount. Bitcoin also supports special signing arrangements; the wallet must use the intended one.

The signed message is broadcast to connected computers called nodes. A fully validating node checks whether the inputs exist and are unspent, whether the spending conditions are satisfied, whether the amounts are allowed, and whether the transaction follows the other rules.

A valid signature alone is not enough. You cannot spend the same output twice in one accepted history, or create extra value merely by writing a larger number.

Nodes may relay an acceptable transaction and keep it in a local waiting area called a mempool. Different nodes can have different waiting lists and relay policies. There is no single global queue promising Maya a particular place.

A miner proposes a page of history.

A miner selects transactions for a candidate block and tries to find the proof of work required to publish it. Fees help pay miners for including transactions. Demand for limited block space can affect the fee needed for timely inclusion.

When a miner finds suitable work, other full nodes still check the whole block. A winning hash does not excuse a double spend, an invalid signature or an excessive reward.

If Maya’s payment is included in a block on the node’s accepted chain, it has one confirmation. When another block is built after it, it has two. The count measures how much accepted history has accumulated after inclusion.

A confirmation is evidence, not a promise about time.

Bitcoin targets an average of about ten minutes between blocks. A particular block may arrive quickly or take much longer. A transaction may also wait through several blocks if it is not selected.

Sometimes two valid blocks appear close together and different nodes temporarily follow different tips. As more work arrives, nodes converge on the valid chain with the most accumulated work. A short replacement of recent blocks is called a reorganization.

More confirmations generally make replacement harder under the network’s security assumptions. No fixed number turns probability into a mathematical guarantee. The recipient’s acceptance policy should reflect the value and risk of the payment.

A block explorer can help you inspect a transaction, but it is someone else’s view. Running your own validating node lets you check the rules for yourself. Neither tool can reverse a mistaken payment simply because you ask.

The idea to keep

A wallet spends previous outputs, creates new ones and signs the instruction. Nodes validate, miners propose blocks, and later work increases confidence in the accepted history.

Next, we will open one of those blocks and see what physically links it to the one before.