Open the complete story and reading map
The previous chapter left us with two conflicting, correctly signed payments. Bitcoin's first chapter turns that thought experiment into a network: people run software that checks rules, miners propose an ordering, and recipients decide when they have enough evidence to treat a payment as received. Those are different jobs.
From proposal to running software
On October 31, 2008, Satoshi Nakamoto announced a peer-to-peer electronic cash paper to the Cryptography mailing list. On January 8, 2009, in the mailing-list archive's displayed time, Nakamoto announced Bitcoin v0.1 and described it as experimental alpha software. A paper states a design; a release lets people test a shared implementation. Paper announcement · First-release announcement.
It is tempting to compress this into a single origin slogan. The contemporary documents are more useful: they show the payment problem, the proposed mechanism and the early software's limitations. They do not justify treating one economic event as the sole cause of the project, or treating today's wallet experience as something that existed at launch.
Follow one payment from three viewpoints
Imagine Imani paying a fictional merchant 6 units from an available 10-unit output. Ignore fees for this teaching example. The transaction creates a 6-unit payment output and a 4-unit change output. The wallet's display is a view of these records; the coins are not little files stored inside the phone.
| Role | What it does | What it cannot promise |
|---|---|---|
| Wallet | Constructs the request and obtains the required authorization. | That a broadcast request has been included in the accepted history. |
| Validating node | Checks transactions and blocks against its rules and the relevant prior state. | That every participant receives messages immediately. |
| Miner | Builds a candidate block and performs proof of work. | That other nodes will accept an invalid spend merely because work was performed. |
One machine can perform more than one role. The distinction is conceptual, not a requirement for three separate devices. The Bitcoin developer guide explains the relationship between validation, unspent outputs and selection of the valid chain with the most accumulated work. “Most work” must not be shortened to “any chain with the most blocks wins.”
Why waiting matters—and what waiting cannot fix
Suppose two miners produce competing valid blocks close together. Different nodes may initially see different tips. Subsequent work helps select a history; a transaction in a displaced block may need inclusion again. A merchant accepting a high-value payment therefore faces a different decision from someone watching an unconfirmed wallet notification.
Waiting does not repair an incorrect destination address, make a seller honest or remove exposure to a custodian. It addresses uncertainty about the accepted history under the network's security assumptions. Settlement confidence is one dimension of a transaction, not a universal safety score.
2013: shared rules also depend on software
The March 2013 chain-fork post-mortem, BIP 50, records an unexpected split: some older nodes rejected a block that version 0.8 could process. A database-lock limitation had affected practical block acceptance. Mining pools downgraded to help restore a common chain, and services temporarily suspended deposits or payments.
The lesson is not that every disagreement is resolved by a central administrator. It is that a protocol's practical behavior includes implementations, coordination and operational responses. A network can publish rules yet still encounter incompatible software behavior. That is why release engineering and incident documentation belong in a history of blockchains.
The trade-offs that remained
- Independent verification has a cost: data, computation and maintenance are somebody's responsibility.
- Convenience can restore intermediaries: a hosted account can simplify use while introducing an institution that controls withdrawals.
- Public verification is not private by default: a public transaction record and a person's identity are separate questions.
- Payments are only one kind of shared rule: developers also wanted applications whose state and interactions could be expressed more generally.
For the technical version, continue to Bitcoin architecture: wallets, nodes, miners and UTXOs. For the historical sequence, ask how a network could execute a shared program.
Check your reasoning: a miner includes an unauthorized spend. Does enough work make it valid?
No. A validating node applies its validity rules before choosing among acceptable histories. Work helps select between valid candidates; it does not supply a missing authorization. Also distinguish this from two authorized spends that conflict with each other.