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

The Bitcoin white paper is Satoshi Nakamoto’s nine-page design for peer-to-peer electronic cash, announced on 31 October 2008. It explains how proof of work and a shared transaction history can resolve conflicting spends without a central mint. Its security argument depends on assumptions about honest and attacking computing power; it does not guarantee that payments can never be reversed.

Evidence: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf); [Bitcoin P2P e-cash paper](https://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html)

Canonical: https://degreesofsatoshi.com/encyclopedia/bitcoin-whitepaper-explained/
Published: 2026-09-23
Substantively modified: 2026-10-02
Independently verified by an automated reviewer: 2026-10-02T18:22:07.965Z

AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied.

## Key facts

- **Title:** “Bitcoin: A Peer-to-Peer Electronic Cash System” ([Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf))
- **Announced:** 31 October 2008, by email to the cryptography mailing list at metzdowd.com ([Bitcoin P2P e-cash paper](https://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html))
- **Length:** Nine pages, twelve numbered sections, eight references ([Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf))
- **First objection:** 2 November 2008, James A. Donald: it “does not seem to scale to the required size” ([Re: Bitcoin P2P e-cash paper (first reply)](https://www.metzdowd.com/pipermail/cryptography/2008-November/014814.html))
- **Hal Finney’s verdict:** 7 November 2008: “Bitcoin seems to be a very promising idea” ([Re: Bitcoin P2P e-cash paper (Hal Finney)](https://www.metzdowd.com/pipermail/cryptography/2008-November/014827.html))
- **On the chain:** The PDF was written into block 230,009 on 6 April 2013 ([Confirmation status of transaction 54e48e…e713](https://blockstream.info/api/tx/54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713/status); [Hidden surprises in the Bitcoin blockchain and how they are stored](https://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html))

## 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.

Evidence: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf)

## 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](/encyclopedia/double-spending/), 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.

Evidence: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf)

## 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](/encyclopedia/proof-of-work-explained/), “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.”

Evidence: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf)

## 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.

Evidence: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf)

## 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.”

Evidence: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf)

## 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](/encyclopedia/cypherpunks-before-bitcoin/) tradition the paper grew out of.

Evidence: [Bitcoin P2P e-cash paper](https://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html); [Re: Bitcoin P2P e-cash paper (first reply)](https://www.metzdowd.com/pipermail/cryptography/2008-November/014814.html); [Re: Bitcoin P2P e-cash paper (Satoshi on scaling)](https://www.metzdowd.com/pipermail/cryptography/2008-November/014815.html); [Re: Bitcoin P2P e-cash paper (Hal Finney)](https://www.metzdowd.com/pipermail/cryptography/2008-November/014827.html)

## 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](/wallet/bitcoin-whitepaper-embedded-on-chain-2013/).

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](/history/bitcoin-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.”

Evidence: [Confirmation status of transaction 54e48e…e713](https://blockstream.info/api/tx/54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713/status); [Hidden surprises in the Bitcoin blockchain and how they are stored](https://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html); [Bitcoin: A Peer-to-Peer Electronic Cash System (translations page)](https://bitcoin.org/en/bitcoin-paper); [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf)

## 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.

Evidence: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf)

## 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.

Evidence: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf)

## Questions

### How long is the Bitcoin white paper?

Nine pages, including the references. It has twelve numbered sections, from the introduction to the conclusion, eight references, a handful of diagrams and one table of probabilities. Most readers can get through it in under an hour.

Evidence: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf)

### Who wrote the Bitcoin white paper and when was it published?

It is credited to Satoshi Nakamoto, a name whose owner has never been identified. It was announced on 31 October 2008 in an email to the cryptography mailing list at metzdowd.com, with a link to the PDF on bitcoin.org, where it is still hosted.

Evidence: [Bitcoin P2P e-cash paper](https://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html); [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf)

### Does the white paper mention 21 million bitcoin or the halving?

No. The paper says only that once “a predetermined number of coins have entered circulation” the incentive can shift to transaction fees. The 21 million cap and the four-year halving schedule are in the software, not the paper. Our dossier on halvings and supply walks through the code.

Evidence: [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf)

### Is the Bitcoin white paper stored on the blockchain?

Yes. A transaction confirmed on 6 April 2013 in block 230,009 contains the PDF, split across hundreds of outputs. Ken Shirriff documented it in 2014, and the file can be reassembled from any full copy of the chain.

Evidence: [Confirmation status of transaction 54e48e…e713](https://blockstream.info/api/tx/54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713/status); [Hidden surprises in the Bitcoin blockchain and how they are stored](https://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html)

## Claims and scope

### bitcoin-whitepaper-explained-quick-answer

The Bitcoin white paper is Satoshi Nakamoto’s nine-page design for peer-to-peer electronic cash, announced on 31 October 2008. It explains how proof of work and a shared transaction history can resolve conflicting spends without a central mint. Its security argument depends on assumptions about honest and attacking computing power; it does not guarantee that payments can never be reversed.

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### bitcoin-whitepaper-explained-fact-title

Title: “Bitcoin: A Peer-to-Peer Electronic Cash System”

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### bitcoin-whitepaper-explained-fact-announced

Announced: 31 October 2008, by email to the cryptography mailing list at metzdowd.com

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### bitcoin-whitepaper-explained-fact-length

Length: Nine pages, twelve numbered sections, eight references

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### bitcoin-whitepaper-explained-fact-first-objection

First objection: 2 November 2008, James A. Donald: it “does not seem to scale to the required size”

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### bitcoin-whitepaper-explained-fact-hal-finney-s-verdict

Hal Finney’s verdict: 7 November 2008: “Bitcoin seems to be a very promising idea”

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

### bitcoin-whitepaper-explained-fact-on-the-chain

On the chain: The PDF was written into block 230,009 on 6 April 2013

Scope: {"collection":"bitcoin","dataAsOf":null,"blockHeight":null}

## Sources

- [Bitcoin: A Peer-to-Peer Electronic Cash System](https://bitcoin.org/bitcoin.pdf) — bitcoin.org. The nine-page paper itself: abstract, twelve sections, the six network steps, the incentive and privacy arguments, the attacker-probability table, and eight references. Locator: The nine-page paper itself: abstract, twelve sections, the six network steps, the incentive and privacy arguments, the attacker-probability table, and eight references.. Retrieved: 2026-10-02T15:04:11.761440+00:00.
- [Bitcoin P2P e-cash paper](https://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html) — Cryptography mailing list archive, metzdowd.com. The 31 October 2008 announcement email with the link to bitcoin.org/bitcoin.pdf and its summary of the design. Locator: The 31 October 2008 announcement email with the link to bitcoin.org/bitcoin.pdf and its summary of the design.. Retrieved: 2026-10-02T14:48:59.965467+00:00.
- [Re: Bitcoin P2P e-cash paper (first reply)](https://www.metzdowd.com/pipermail/cryptography/2008-November/014814.html) — Cryptography mailing list archive, metzdowd.com. The 2 November 2008 reply: “We very, very much need such a system,” followed by the objection that it does not seem to scale. Locator: The 2 November 2008 reply: “We very, very much need such a system,” followed by the objection that it does not seem to scale.. Retrieved: 2026-10-02T14:49:21.155171+00:00.
- [Re: Bitcoin P2P e-cash paper (Satoshi on scaling)](https://www.metzdowd.com/pipermail/cryptography/2008-November/014815.html) — Cryptography mailing list archive, metzdowd.com. Satoshi’s same-day answer: light clients need about 12KB of headers per day, and 100 million transactions a day would cost about 100GB of bandwidth, “12 DVD or 2 HD quality movies.” Locator: Satoshi’s same-day answer: light clients need about 12KB of headers per day, and 100 million transactions a day would cost about 100GB of bandwidth, “12 DVD or 2 HD quality movies.”. Retrieved: 2026-10-02T14:49:21.155746+00:00.
- [Re: Bitcoin P2P e-cash paper (Hal Finney)](https://www.metzdowd.com/pipermail/cryptography/2008-November/014827.html) — Cryptography mailing list archive, metzdowd.com. Finney’s 7 November 2008 message calling Bitcoin “a very promising idea” and endorsing security based on honest CPU power outweighing an attacker. Locator: Finney’s 7 November 2008 message calling Bitcoin “a very promising idea” and endorsing security based on honest CPU power outweighing an attacker.. Retrieved: 2026-10-02T14:49:23.037486+00:00.
- [Confirmation status of transaction 54e48e…e713](https://blockstream.info/api/tx/54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713/status) — Blockstream explorer (API). Confirms the white-paper transaction in block 230,009 with block time 1365280090, which is 6 April 2013 at 20:28:10 UTC. Locator: Confirms the white-paper transaction in block 230,009 with block time 1365280090, which is 6 April 2013 at 20:28:10 UTC.. Retrieved: 2026-10-02T14:49:23.171287+00:00.
- [Hidden surprises in the Bitcoin blockchain and how they are stored](https://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html) — Ken Shirriff’s blog (righto.com). Documents that the Bitcoin paper PDF is stored in transaction 54e48e…e713 using data encoded in place of public keys, alongside other embedded files. Locator: Documents that the Bitcoin paper PDF is stored in transaction 54e48e…e713 using data encoded in place of public keys, alongside other embedded files.. Retrieved: 2026-10-02T14:49:23.377965+00:00.
- [Bitcoin: A Peer-to-Peer Electronic Cash System (translations page)](https://bitcoin.org/en/bitcoin-paper) — bitcoin.org. Hosts the paper in dozens of translations and describes it as still recommended reading for anyone studying how Bitcoin works. Locator: Hosts the paper in dozens of translations and describes it as still recommended reading for anyone studying how Bitcoin works.. Retrieved: 2026-10-02T14:49:23.159255+00:00.

## Revision history

- 2026-09-23: Initial Bitcoin encyclopedia entry at this permanent URL.
- 2026-10-02: Clarified valid-most-work selection and probabilistic finality in historical terminology.
- 2026-10-02: Added reusable claims, explicit source locators, and matching Markdown and JSON. This publishing change does not itself establish factual verification.
- 2026-10-02: Added “Read the design argument before treating it as a rulebook”, clarified the search description, and corrected overbroad section headings. Independent verification is recorded separately.

## Cite this entry

Degrees of Satoshi editorial project. “The Bitcoin white paper, explained: a plain-English walk through all nine pages.” Published 2026-09-23; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/bitcoin-whitepaper-explained/