Reading the Bitcoin Whitepaper, Section by Section

The Bitcoin whitepaper is one of the most discussed technical documents of recent decades, and one of the least read. It is signed with a pseudonym, Satoshi Nakamoto, whose real identity has never been established; we do not speculate about it here. What we can do is read what the paper actually says. It has an abstract, twelve numbered sections and eight references, and it fits on nine pages.

The abstract and the problem

The abstract opens with a sentence that states the whole ambition of the project.

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

Bitcoin whitepaper, abstract, 2008

It immediately names the obstacle. Digital signatures can prove who authorised a payment, but if a trusted third party is still needed to prevent double-spending, the main benefit is lost. The paper proposes a solution using a peer-to-peer network that timestamps transactions into an ongoing chain of proof of work.

Section 1, the introduction, frames the problem in terms anyone who has read our earlier essays will recognise. Online commerce relies on financial institutions acting as trusted third parties. Because those institutions can reverse transactions to settle disputes, merchants must guard against fraud and ask customers for more information than they would otherwise need. What is needed, the paper says, is an electronic payment system based on cryptographic proof instead of trust.

Sections 2 and 3: coins and timestamps

Section 2, “Transactions”, contains the paper’s definition of its central object: “We define an electronic coin as a chain of digital signatures.” Each owner transfers the coin by digitally signing a hash of the previous transaction together with the public key of the next owner. Anyone can check the chain of signatures to verify the chain of ownership.

The section then states the problem plainly. Signatures cannot show that an earlier owner did not also sign the same coin over to someone else. The usual solution is a central mint that checks every transaction, which is exactly what the paper wants to avoid. The only way to confirm that a transaction has not happened, it reasons, is to be aware of all transactions. So transactions must be announced publicly, and participants need a way to agree on a single history of the order in which they were received.

Section 3, “Timestamp Server”, introduces the tool for ordering. A timestamp server takes the hash of a block of items and publishes it widely, like a notice in a newspaper. Each timestamp includes the previous one in its hash, forming a chain in which every new timestamp reinforces the ones before it. This is the idea of Haber and Stornetta, whose work the section cites.

Section 4: proof of work

A timestamp chain needs someone to run it, and the paper does not want that someone to be a trusted party. Section 4 replaces the trusted timestamp server with proof of work, in the style of Adam Back’s Hashcash. To add a block, a participant must find a value, now usually called a nonce, which makes the hash of the block begin with a required number of zero bits. Finding it takes a great deal of trial and error; checking it takes one hash.

The section then makes its most important move. Proof of work also decides which history counts. The paper describes it as one-CPU-one-vote, in contrast to one-IP-address-one-vote, which anyone able to create many addresses could subvert. The majority decision is represented by the longest chain, meaning the chain with the greatest proof-of-work effort behind it. To change a past block, an attacker would have to redo its work and the work of every block after it, and then overtake the honest chain. The difficulty of the work adjusts over time to keep the average rate of new blocks roughly steady.

Section 5: the network

Section 5 describes how the network runs in six short steps. New transactions are broadcast to all nodes. Each node collects new transactions into a block. Each node works on finding a proof of work for its block. When a node finds one, it broadcasts the block to all nodes. Nodes accept the block only if all transactions in it are valid and not already spent. Nodes express their acceptance by working on the next block, using the hash of the accepted block as the previous hash. Nodes always consider the longest chain to be the correct one, and the section explains how temporary ties are resolved when the next block is found.

Section 6: incentive

Why would anyone spend computing effort on this? Section 6 answers that, by convention, the first transaction in each block is a special one that starts a new coin owned by the creator of the block. This gives nodes a reason to support the network and also provides a way to put coins into circulation initially, since there is no central authority to issue them. The paper compares this to gold miners spending resources to add gold to circulation. Transaction fees provide a further incentive, and once a predetermined number of coins have entered circulation, the incentive can move entirely to fees.

The section ends with an argument about honesty. An attacker who managed to gather more computing power than all honest nodes would, the paper suggests, find it more advantageous to play by the rules and receive new coins than to undermine the system on which the value of those coins depends.

Sections 7 to 10: practical matters

Section 7, “Reclaiming Disk Space”, uses Merkle trees so that old, spent transactions can be discarded without breaking the chain. A block header without transactions would be about 80 bytes; the paper calculates that headers alone would grow by about 4.2 megabytes a year, which it considered unproblematic given the memory of contemporary computers.

Section 8, “Simplified Payment Verification”, explains that a user does not need to run a full node to check a payment. It is enough to keep the block headers of the longest chain and obtain the Merkle branch linking a transaction to a block. The paper notes honestly that this method is weaker if the network is overpowered by an attacker.

Section 9, “Combining and Splitting Value”, deals with the fact that coins come in arbitrary amounts. Transactions can have several inputs, combining smaller amounts, and normally at most two outputs: one for the payment, and one for any change going back to the sender.

Section 10, “Privacy”, contrasts the system with traditional banking. Banks achieve privacy by restricting access to information. Here every transaction is public, so privacy must come from keeping public keys anonymous: observers can see that someone sent an amount to someone else, but not who they were. As an additional precaution, the paper recommends a new key pair for each transaction, while admitting that some linking is unavoidable.

Section 11: the calculations

Section 11 is the most mathematical part. It considers an attacker trying to build an alternative chain faster than the honest one, in order to undo a payment the attacker has made. It models the race between honest and attacker chains as a random walk and shows that the probability of the attacker catching up falls off exponentially with the number of blocks the attacker is behind. The paper includes a short program and a table. With an attacker controlling a tenth of the total computing power, for example, the chance of success drops below one in a thousand once the payment is five blocks deep.

Section 12 and what came after

The conclusion restates the design in a few lines: a system for electronic transactions without relying on trust, in which nodes work all at once with little coordination, need not be identified, and vote with their computing power on which blocks to accept.

On 3 January 2009 the first block of the chain was created. Its first transaction contains the text “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks”, a headline from that day’s London newspaper, which also served to prove the block could not have been made earlier. The software was released on 9 January, and on 12 January the first transaction between two people sent coins to Hal Finney.

What the paper left open

Reading the whitepaper today, what stands out is how much it leaves unsaid. It says almost nothing about governance, about how the rules themselves would change, or about the energy that proof of work would consume at scale. It assumes that most computing power will be honest. And it describes a payment system, not the wider industry that later grew up around it. Those questions, and the responses of regulators to them, are the subject of the essays that follow.