The Whitepaper

Bitcoin: A Peer-to-Peer Electronic Cash System

Author

Satoshi Nakamoto — a pseudonym; the identity behind it has never been established

Published

31 October 2008, to a cryptography mailing list

Length

Nine pages, including references

Sections

Twelve, from “Introduction” to “Conclusion”

This opens the paper at bitcoin.org, where its author published it. BitcoinTrench keeps no copy of the file — a copy on a third-party site is one a reader cannot be sure has not been altered, and this document's whole value is being the original. The guide below is written to be read alongside it.

1 · Introduction — the cost of needing a referee

The paper opens not with cryptography but with commerce. Online payment depends on financial institutions acting as trusted third parties, and that dependence has prices: transactions can be reversed, so merchants must distrust customers and collect more information about them than they need; small payments become uneconomic because the fee floor makes them uneconomic. The stated goal is not to defeat banks but to make a payment as final as handing over cash.

2 · Transactions — the double-spending hole

A coin is defined as a chain of digital signatures: each owner signs a hash of the previous transaction and the next owner's public key, so anyone can verify the chain of custody. The paper then immediately admits the flaw in its own construction — this proves who signed, but not when, so nothing stops an owner signing the same coin over to two different people. Solving that without a central authority is the rest of the paper.

3 · Timestamp server — publishing the order

To know which spend came first you need agreed time. The proposal is a chain of timestamps where each one includes the hash of the previous, so each publication reinforces everything before it. This is the structure later called a blockchain, though the paper never uses that word.

4 · Proof of work — making history expensive to rewrite

The heart of the paper. To add a block you must find a number that makes the block's hash start with a required number of zero bits — findable only by guessing, and instantly checkable by everyone else. Because each block builds on the last, changing an old one means redoing its work and every block after it, while the honest network keeps extending. The difficulty is adjusted automatically to hold a steady pace as participation grows.

This section is also the answer to “one vote per IP address”, which is trivially forged. The paper's phrase is one vote per unit of computing power — a thing you cannot fake because it must be spent.

See the difficulty adjustment happening

5 · Network — the six rules that run everything

The whole protocol, compressed into a short list: broadcast transactions to all nodes; each node collects them into a block; each works on the proof of work for its block; on finding one, broadcasts it; nodes accept it only if every transaction in it is valid and unspent; and they express acceptance by building the next block on top of it. Nodes always treat the longest chain as correct, so agreement needs no messages about agreement.

6 · Incentive — why anyone bothers

The first transaction in a block creates new coins for whoever mined it. This does two jobs at once: it distributes the currency without any authority handing it out, and it pays for the security the network needs. The paper notes that issuance is finite and that once it stops, transaction fees take over entirely. It also makes an economic argument rather than a moral one — an attacker with enough hardware to rewrite history would earn more by mining honestly than by devaluing the thing they hold.

Issuance against the 21 million cap

7 · Reclaiming disk space — how it stays runnable

Old transactions are collapsed into a Merkle tree so spent data can be discarded while the block header still proves what it contained. A short engineering section, but it is what keeps a node something an ordinary person can run — and node count is what decentralisation actually consists of.

8 · Simplified payment verification — checking without the whole chain

A user can verify a payment holding only block headers, by checking that a transaction sits in a tree whose root is in a block the network has built on. Weaker than running a full node — it trusts that the majority is honest — but it is what makes wallets on a phone possible.

9 · Combining and splitting value — no accounts, no balances

Transactions take multiple inputs and usually produce two outputs: the payment, and change back to the sender. This is why Bitcoin has no account balances — only unspent outputs — and why a wallet holding many small pieces pays a larger fee to spend them.

Why this makes fees depend on size, not amount

10 · Privacy — a different place to draw the line

Banks get privacy by keeping records secret. Here the records are public, and privacy comes from the keys not being linked to identities. The paper recommends a new key pair for every transaction and warns plainly that inputs spent together reveal common ownership. It never claims anonymity — a distinction much of the later coverage lost.

11 · Calculations — the arithmetic of an attack

The paper closes its argument with probability, modelling an attacker racing to catch up with the honest chain as a random walk. The result is that the chance of success falls exponentially with each additional confirmation. This is the origin of waiting for a number of confirmations, and of the phrase “six blocks”.

12 · Conclusion — what was actually claimed

The closing claim is modest and worth measuring the last seventeen years against: a system for electronic transactions that does not rely on trust, in which nodes work with little coordination, need not be identified, and can leave and rejoin at will, accepting the longest chain as proof of what happened while they were gone.