How Bitcoin works
A signature authorizes. A miner proposes. Each full node checks. Follow the distinctions, one step at a time.
One transaction. Seven steps.
Understand / explanatory model
A sequence to read, not a clock to watch. All transactions, blocks and peers below are fictional. No network connection is used by this model.
Manual stepping · automatic playback respects reduced motion.
Paused. Step 1 of 7. Authorize a spend. Keep the key.
Available to spend
Unspent output
Earlier transaction
Stays with the signer
Private key
Not broadcast
Signed transaction
Input → recipient output + change output
Example with change · fee = inputs − outputs
Step 1 / 7
Authorize a spend. Keep the key.
A wallet constructs a transaction spending existing unspent outputs (UTXOs) into new outputs. The required signatures authorize the spend; the private keys are not sent with it. T is our fictional transaction, not an address or a real payment.
Signing is not confirmation. Nothing has been added to a block.
Check the technical source ↓Read a source. Keep the distinction.
Observe / source readings
The model above explains a mechanism. This bench reads mempool.space: reported blocks and aggregate mempool totals. No moving dots stand in for transactions we cannot see.
Opt-in, tab memory only: up to 20 readings for 30 minutes. Reloading or leaving this guide loses them. No wallet or address input. Read the privacy and source limits ↓
Watch off · Manual reads available
No reading requested. Nothing is being recorded.
Replay this session
0 / 20 readings retained
No session history. Request a reading to begin; there is no earlier archive to replay.
A viewpoint, not an all-seeing network
Source & clocks. Observe reads mempool.space’s recent blocks and mempool totals through the Gazette server. These are separate requests, not an atomic snapshot. No source observation time is supplied, so available readings are labelled Partial; after two minutes from retrieval, including supplied HTTP Age, they become Stale. A block’s header timestamp is not when it arrived or was discovered.
Privacy & retention. The feature takes no wallet, address or transaction input and adds no analytics events. The server does not forward reader cookies or headers to the provider. Ordinary hosting logs may exist. The server holds one normalized reading until replaced or its process ends, with a 60-second request cooldown (up to five minutes after a provider retry instruction). The tab retains at most 20 readings for 30 minutes; expired readings disappear when execution resumes. No browser storage, database archive or background recorder is used. Clear, reload or leaving the guide removes session history. External source links visit the provider directly.
What replay cannot prove. The gaps between readings are not filled. A changed tip is not by itself proof of a reorganization. Aggregate mempool changes do not trace transactions, propagation or origins. First seen by one observer would not mean first broadcast—and this bench collects no first-seen times. Blocks shown were reported by the source; they are not independently consensus-validated here.
Inspect the interface. mempool.space API documentation and the Esplora endpoint specification describe these public records. Interface reviewed 25 September 2026; that is not a review of each new reading. The page has no direct Bitcoin peer connection and promises neither consensus verification nor permanent evidence custody.
Read all seven steps
1. Authorize a spend. Keep the key.
A wallet constructs a transaction spending existing unspent outputs (UTXOs) into new outputs. The required signatures authorize the spend; the private keys are not sent with it. T is our fictional transaction, not an address or a real payment.
Signing is not confirmation. Nothing has been added to a block.
Technical source ↓2. A peer checks before relaying.
A receiving full node checks the transaction and applies its own mempool admission and relay policies. In this example, node A admits T. A transaction can meet consensus rules yet fail a node’s local policy.
Relay policy is not a vote that changes consensus rules.
Technical source ↓3. There is no single waiting room.
Peers pass transactions to other peers. Their mempools can differ. Here A holds T while B has not received it yet. These are two illustrative viewpoints, not a map of the entire network or a measurement of propagation.
Seen by one node does not mean seen by everyone—or included in a block.
Technical source ↓4. Choose transactions. Build a candidate.
The block producer selects transactions and constructs a candidate referring to a previous block. Its first transaction, the coinbase, claims a reward limited by the subsidy and included fees. Here the producer includes T. Roles may overlap: miners can also run full nodes.
A candidate is a proposal, not yet an accepted block. Inclusion is not promised.
Technical source ↓5. Search for a qualifying header hash.
Mining varies the candidate header and hashes it, searching for a result at or below the target. For the next step we assume a qualifying result was found. This page does not hash, mine, or estimate when a block will arrive.
Proof-of-work qualifies the header. It does not excuse invalid contents.
Technical source ↓6. Each full node checks for itself.
A full node checks the proposed block against consensus rules, including proof-of-work, transaction validity and the reward limit. Our two full nodes make their own checks. Neither trusts the producer’s assertion that the block is valid.
The checklist is abbreviated. This model assumes all other consensus checks pass.
Technical source ↓7. Work accumulates on a valid history.
Among valid chains, a full node follows the one with the most accumulated proof-of-work. Here T is in block B, and a valid child C follows: two confirmations in this example. Reorganizations remain possible; confirmations are not a wall-clock guarantee or absolute finality.
An invalid block is not made valid by more work or by more nodes accepting it.
Technical source ↓
Counterexample: excessive reward
In this counterexample the proposed block meets the proof-of-work target, but its coinbase claims more than the allowed subsidy plus included fees. Each full node enforcing these rules rejects it. T itself has not been made invalid by the producer’s excessive claim.
The full nodes keep their previous valid tip. T remains unconfirmed in this example; a later valid block could include it. More work on the rejected block would not repair its excessive reward.
What this leaves out
This is a conceptual base-layer walkthrough, not consensus software. It omits script details, transaction replacement, compact-block relay, mining-pool coordination and competing valid tips. The two-node sketch is not a network census; checks shown are not exhaustive. Nothing here connects a wallet, sends a transaction, or mines bitcoin.
From understanding to a question
- What could the transaction cost? →
- What changes a miner’s economics? →
- Who controls the keys and the exit? →
The teaching model is separate from Observe. Replay contains only readings collected in this guide session, not historical network telemetry.
Technical sources & model limits
Model reviewed · not a network observation date
- Bitcoin developer guide · Transactions ↗
Transaction structure; standard and non-standard transactions. The guide’s P2PKH example is not treated as the only signature or output type.
- Bitcoin developer guide · P2P network ↗
Transaction broadcasting and per-peer memory pools. Historical implementation defaults on this page are not used here.
- Bitcoin developer guide · Mining ↗
Candidate construction and header search. Pool protocols, payouts and timing are outside this schematic.
- Bitcoin Core v29.0 · ConnectBlock ↗
Reward check: coinbase output cannot exceed fees plus subsidy; bad-cb-amount. A pinned implementation reference, not a claim about the newest release.
- Bitcoin developer guide · Block chain ↗
Independent validation, proof-of-work, block height and forking. Chain selection is by accumulated work among valid histories, not a headcount.