The Bitcoin white paper, explained: a plain-English walk through all nine pages

Nine pages, one claim: you can pay someone online without a bank in the middle

The paper is titled “Bitcoin: A Peer-to-Peer Electronic Cash System,” is credited to Satoshi Nakamoto, and runs to nine pages including a page of references. Its abstract states the goal in one sentence: “A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.” Everything else in the paper explains how that could be safe.

Section 1, the introduction, says why it matters. Online commerce relies on banks and payment companies as trusted middlemen, with costs: payments can be reversed, so merchants must be wary, and small casual payments are not worth the fees. Cash has no such problem in person, but “no mechanism exists to make payments over a communications channel without a trusted party.” The paper proposes one, “based on cryptographic proof instead of trust,” and states its security assumption up front: the system holds “as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes.” A node is a computer running the software.

A coin is a chain of signatures, and the hard part is stopping a double spend

Section 2 defines the coin: “We define an electronic coin as a chain of digital signatures.” To pay you, I sign a statement handing the coin to your public key, and that signature is added to the coin’s history. Anyone can check the signatures, but nobody can tell from the coin alone whether I also signed it over to someone else. That is the double-spending problem, and the paper says the usual fix is a central mint that sees every transaction, which puts “the fate of the entire money system” in one company’s hands.

The alternative is to make every transaction public and get everyone to agree on the order they arrived in. Section 3 borrows an old idea, the timestamp server: take a batch of items, hash them, and publish the hash somewhere public, “such as in a newspaper or Usenet post.” Each new timestamp includes the previous one, so they form a chain. That chain of hashed batches is what people later started calling a blockchain, though the paper never uses the word.

Proof of work turns the timestamp server into a contest anyone can join

A newspaper is a trusted publisher, so Section 4 replaces it with proof of work, “similar to Adam Back’s Hashcash.” To seal a block, a node must find a number, the nonce, that makes the block’s hash begin with a required run of zeros. Once found, the block cannot be changed without redoing that work, and every later block piles more work on top. To keep the pace steady, the difficulty is set “by a moving average targeting an average number of blocks per hour.”

Proof of work also decides whose version of history counts. Because voting by internet address could be gamed, the paper makes it “essentially one-CPU-one-vote,” and the majority decision “is represented by the longest chain.” Section 5 turns this into six steps: new transactions are broadcast to all nodes, each node gathers them into a block, works on the proof, broadcasts a solved block, other nodes accept it only if every transaction in it is valid, and they show acceptance by building the next block on top. Nodes “always consider the longest chain to be the correct one.”

Section 6 explains why anyone would bother. The first transaction in each block creates new coins for whoever made the block, which both rewards the work and distributes coins “since there is no central authority to issue them.” It compares this to gold mining, notes that transaction fees can also pay for the work, and says that once “a predetermined number of coins have entered circulation” the incentive can shift entirely to fees. It also argues that a would-be attacker with a lot of computing power “ought to find it more profitable to play by the rules.”

Three practical sections: saving disk space, light wallets and making change

Section 7 says old transactions can be discarded once they are buried deep enough, because the transactions inside a block are hashed in a Merkle tree, a structure that lets you throw away branches while keeping the root. A block header alone is about 80 bytes, the paper notes, so a year of headers is about 4.2 megabytes, small even for a 2008 computer with two gigabytes of memory.

Section 8, Simplified Payment Verification, is the design for a light wallet: keep only the block headers, ask a full node for the branch of the tree that links your transaction to a block, and count the blocks built on top. It is weaker, and the paper says businesses receiving many payments “will probably still want to run their own nodes.” Section 9 explains that a transaction can have several inputs and outputs so value can be split and combined, normally with “one for the payment, and one returning the change.” That is the origin of the unspent-output model wallets still use.

Privacy and reversal risk depend on stated assumptions

Section 10 concedes that a public ledger cannot hide transactions the way a bank does, so it hides identities instead: keep public keys anonymous, and use a new key pair for each transaction. The public can see “that someone is sending an amount to someone else,” like the tape of trades a stock exchange publishes, without names attached. The paper is honest that some linking is “still unavoidable” when several inputs are spent together.

Section 11 is the only mathematics. It treats the race between the honest chain and an attacker rewriting a recent payment as a gambler’s-ruin problem, and shows that the attacker’s chance of catching up “drops exponentially” with each block added on top. A table gives the numbers: against an attacker holding a tenth of the network’s power, waiting five blocks brings the odds of a successful rewrite below one in a thousand. Section 12 sums up: “a system for electronic transactions without relying on trust,” in which nodes “vote with their CPU power” and “any needed rules and incentives can be enforced with this consensus mechanism.”

The list pushed back on scaling, Satoshi answered in DVDs, and Hal Finney called it promising

The paper reached the world on 31 October 2008 as an email to the cryptography mailing list hosted at metzdowd.com, with a link to the PDF and a one-paragraph summary. The first substantive reply, from James A. Donald on 2 November, set the tone: “We very, very much need such a system, but the way I understand your proposal, it does not seem to scale to the required size.”

Satoshi replied the same evening. Most users would not need to run full nodes; a light client needs only “the chain of block headers, or about 12KB per day.” A network handling 100 million transactions a day would need about 100 gigabytes of bandwidth, “the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices,” and if the network ever grew that large, “by then, sending 2 HD movies over the Internet would probably not seem like a big deal.” The scaling debate never went away, but the first answer came in week one.

On 7 November, Hal Finney weighed in: “Bitcoin seems to be a very promising idea. I like the idea of basing security on the assumption that the CPU power of honest participants outweighs that of the attacker.” He went on to become the first person to receive bitcoin from Satoshi. The whole exchange, and the people in it, belongs to the cypherpunk tradition the paper grew out of.

The paper now lives inside the ledger it describes

On 6 April 2013, at 20:28 UTC, a transaction confirmed in block 230,009 that carried the entire PDF, split into pieces stored where a transaction normally holds public keys. Ken Shirriff, who cataloged the chain’s hidden data in February 2014, listed it plainly: “In this transaction the Bitcoin blockchain contains the PDF for the original Bitcoin paper.” Nobody has identified who did it. How the encoding works, what it cost, and why every node still stores it are covered in our dossier on the embedded white paper.

The paper is short enough to read in an evening and it has aged well: the network running today still follows its six steps. There is no 21 million figure and no halving schedule; the paper speaks only of “a predetermined number of coins” and an average number of blocks per hour. Those specifics live in the software, and in our dossier on halvings and supply. Bitcoin.org now hosts the paper in dozens of translations and calls it “still recommended reading for anyone studying how Bitcoin works.”

Work selects among valid histories

The white paper often calls the preferred history the longest chain. The relevant measure is accumulated proof of work among chains that satisfy validation rules; a higher block count or extra hashing does not authorize invalid spends.

This selection provides probabilistic finality. A modelled catch-up probability is conditional on its assumptions about attacker hash power and behavior. It does not promise that any fixed confirmation count makes every payment irreversible.

Read the design argument before treating it as a rulebook

For a first reading, follow the problem through sections 2, 4 and 5: conflicting payments require an agreed history, proof of work makes rewriting costly, and participants still check transaction validity. Then read section 11 as a model with assumptions about the attacker, not a universal promise of irreversible payments.

The paper explains the architecture; it is not a complete specification of every rule used by later software. For example, section 6 discusses issuance and fees without giving the familiar 21-million limit or a block-by-block subsidy schedule. Use the paper for the design argument and versioned specifications or code for exact implementation rules.