A Reader’s Guide to the Bitcoin Whitepaper

An email few people answered

It was Friday, October 31, 2008, 18:10 UTC.

The financial crisis was at its most frightening. Lehman Brothers had collapsed only six weeks earlier, and governments were rushing out enormous sums to rescue their banks. In the middle of all this, the Cryptography Mailing List, hosted at metzdowd.com, received an email with the subject line "Bitcoin P2P e-cash paper," signed Satoshi Nakamoto.

It opened with a single sentence: "I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party." It linked to a paper nine pages long.

Replies were few, many of them skeptical, though some pressed for technical detail. The people on that list had already seen plenty of digital cash proposals, and most had never left the page. Few could have guessed that this email began a history that is still unfolding.

Eighteen years on, we read the paper again. What struck us most was the way it reasons. Each section tackles exactly one problem, and each answer leads naturally to the next question. Reading all twelve sections feels like following the author through a hard problem from start to finish.

This guide is written for readers with no technical background. We start by explaining a few words you cannot avoid, then go through the paper one section at a time. For each section we cover three things: the problem it addresses, how it solves it, and the new problem it leaves behind. The original text, in English and Chinese, hangs on the Whitepaper Wall in the Origins hall. Read this first, and the original will be much easier going.

Six words to know before you start

The whitepaper is short, but it uses quite a few technical terms. Get these six straight and the rest becomes much easier.

Hash: think of it as a fingerprint for data. Any piece of content, from a single word to an entire book, can be run through a hash function to produce a short string of fixed length. Change even one comma and the fingerprint changes completely, yet nobody can work backwards from the fingerprint to the original content. Bitcoin uses hashes everywhere to check whether anything has been altered.

Private key and public key: a matched pair of digital keys. You keep the private key secret and can share the public key with anyone. Picture a locked mailbox: the public key is the mailbox's address, which anyone may know, and the private key is the key that opens it, which only you hold.

Digital signature: you use your private key to "sign" a piece of content. Anyone can use the matching public key to check that you signed it, but no one can forge the signature without your private key. It works like a handwritten signature that cannot be copied.

Block and blockchain: Bitcoin's ledger is written one page at a time. Each page is called a block and holds a batch of transactions. Every page carries the fingerprint of the page before it, so all the pages are linked in order, and together they form the blockchain.

Node: a computer that takes part in the Bitcoin network by keeping and checking a copy of the ledger. Anyone can run one.

Proof-of-work: a math puzzle that can only be solved by guessing again and again. Finding the answer takes a great deal of computation, but checking it takes others an instant. Bitcoin uses it to decide who gets to add the next page to the ledger.

With these six words in hand, we can begin.

Section 1 · Introduction: it starts with cost

What it says: almost every online payment today depends on a "trusted third party" such as a bank or a payment company to sit in the middle. Nakamoto points out that this dependence has a price.

Here is an example. When you buy something online, you can usually ask for a refund after paying. That protects the buyer, but it is a risk for the seller: someone could receive the goods and then falsely claim they never arrived. To protect themselves, merchants ask customers for more information and absorb some losses to fraud. Those costs end up in the price of everything, and they make small payments uneconomical.

Cash does not have this problem. You hand over the money, you get the goods, and the payment is done. Online, until then, there was no way to do the same.

The question it leaves: could there be an online payment that is final like cash, without any third party? And without a third party, who decides who owns an electronic coin?

The tone of the introduction is strikingly calm. It reads like an engineer setting out a technical problem to be solved, starting from cost and reasoning forward one step at a time.

Section 2 · Transactions: a coin is a chain of signatures

What it solves: with no bank keeping the books, how do you prove a coin is yours?

Nakamoto's answer is surprisingly simple. He defines "an electronic coin as a chain of digital signatures."

Imagine a transfer slip that keeps changing hands. At the start it says "this coin belongs to A." When A gives the coin to B, A writes "to B" at the bottom and signs it. When B passes it to C, B does the same. Anyone can read the slip from top to bottom and confirm that every handover was signed by the previous owner.

Technically, the "signature" here is the digital signature described above: the current owner uses their private key to sign a hash of the previous transaction and the next owner's public key.

This also answers a question many people have asked: where is a bitcoin, actually? It is recorded on the blockchain, as this chain of signatures that can be traced from one transfer to the next. To "own bitcoin" really means to hold the private key that can sign the next transfer.

The problem it leaves: a signature proves a handover, but it cannot stop someone from cheating. A could sign one slip saying "to B" and another saying "to C," selling the same coin twice. B and C would each check their slip and find a genuine signature. This is the double-spending problem, and most of the rest of the paper is spent dealing with it.

Section 3 · Timestamp server: putting transactions in order

What it solves: to catch A out, all you need to know is which transaction came first. The earlier one counts and the later one is void. But with no central authority, who decides the order?

Nakamoto starts from an existing idea, the timestamp server. Picture a notary who regularly gathers the latest batch of transactions, stamps them with the time, and publishes the stamp for everyone to see. The key is that each new stamp includes the fingerprint of the previous one, just as each page of the ledger begins by copying out the fingerprint of the page before.

The stamps are therefore linked in a chain. If someone secretly changes a page in the middle, that page's fingerprint changes, the copies on every later page stop matching, and the tampering is exposed at once.

Easy to spot is not the same as hard to do, however. Someone able to recopy every later page could still get away with it. What makes tampering extremely difficult in practice is the proof-of-work introduced in the next section.

The problem it leaves: a real notary is a central authority, and Bitcoin wants no center at all. On a network where everyone is equal, who gets to apply the stamp?

Section 4 · Proof-of-work: making votes cost something

What it solves: without a notary, the whole network has to decide together who stamps the next page. The obvious idea is a vote, with the majority deciding.

Online, though, voting has a fatal flaw: creating an identity costs almost nothing. The paper notes that if the majority were based on "one-IP-address-one-vote," it could be subverted by anyone able to allocate many IPs. It is like an online poll where someone who registers ten thousand fake accounts gets ten thousand votes.

Voting power therefore has to be tied to something that cannot be created for free. Nakamoto chose computing power.

Here is how it works. Anyone who wants to stamp the next page must first solve a math puzzle. There is no trick to it; the only way is to keep guessing, like rolling dice over and over until you get a small enough number. Whoever finds an answer first wins the right to add the page and publishes the answer, and everyone else can check it in an instant.

Because guessing costs real electricity and real hardware, the computing power you control is, in effect, your number of votes. Fake accounts are useless, because fake accounts do not solve puzzles.

On top of this, Bitcoin sets a rule: everyone accepts the "longest" chain, or more precisely, the chain with the most accumulated work behind it. That is the majority decision. And to keep pace with faster hardware and a changing number of participants, the puzzle's difficulty adjusts automatically so that blocks keep arriving at a steady average rate, about one every ten minutes.

Now go back to the worry left by Section 3. Anyone who wants to alter a page would have to recopy every later page, re-solve the puzzle for each one, and do it faster than all the honest participants put together. In practice that is almost impossible.

The first common misreading: the paper says that "proof-of-work is essentially one-CPU-one-vote." The line is often taken to mean that everyone can take part equally. Read in context, though, its point is that voting must carry a real cost, rather than depending on how many identities you have.

Mining today is dominated by specialized chips and large industrial sites, far from the picture in the paper, and the Mining Rig Wall in The Trust Machine hall records how that happened. The paper argues that voting power must be tied to computing power. It makes no prediction about how that computing power will end up distributed.

Section 5 · Network: less than a page

What it solves: all the parts are in place, so how does the network actually run?

Nakamoto needs only six steps:

1. Someone makes a new transaction and broadcasts it to all nodes.
2. Each node collects the new transactions it receives into a candidate block.
3. Each node starts working on the proof-of-work puzzle for its block.
4. Whoever solves it first broadcasts the block to all nodes.
5. The other nodes check the block and accept it only if every transaction in it is valid and not already spent.
6. Nodes show that they accept the block by starting work on the next block on top of it.

If two nodes solve the puzzle at almost the same moment, the network briefly has two chains of equal length. Each node keeps working on the one it heard about first. When the next block arrives, whichever chain becomes longer wins, and the other is simply dropped. Nodes always treat the longest chain as the correct one and keep extending it.

A global system that is still running today is described in less than a page.

The question it leaves: solving puzzles costs money for electricity and hardware, so why would anyone do it?

Section 6 · Incentive: making honesty the best deal

What it solves: giving people a reason to take part.

The answer is a reward. The first transaction in each block creates a set amount of new coins and gives them to whoever solved the puzzle. It compensates them for their electricity and equipment, and it is the only way new bitcoin enters circulation. Because it resembles digging gold out of the ground, spending resources to bring new coins into being, the work later came to be called mining and the participants miners. Once new issuance comes to an end, transaction fees take over.

The best part of this section comes in the second half. Nakamoto imagines an attacker with more computing power than all the honest nodes combined and calmly reasons through his choices. He could use that power to cheat, quietly reversing his own payments, or he could mine honestly and earn new coins. Nakamoto concludes that playing by the rules pays better, because he would earn more new coins than he could gain by cheating. And any attack would shake confidence in Bitcoin and drag down the value of the coins he already holds.

Bitcoin's security, in other words, does not depend on everyone being good. The rules are designed so that following them is the most profitable thing to do. The earlier sections show that the system is technically possible. This one explains why anyone would choose to run it, which on an open network is often the harder question.

Whether fees alone can support enough computing power over the long run, once new issuance ends, is a question that came up later, and it is still being debated.

Section 7 · Reclaiming disk space: what to do as the ledger grows

What it solves: every transaction stays on the ledger forever, so the ledger keeps growing, and sooner or later an ordinary computer could not hold it.

Nakamoto's solution uses a structure called a Merkle tree. Think of it like this: take all the transactions in a block, pair them up, and compute a fingerprint for each pair. Then pair up those fingerprints and compute new ones. Keep merging upward, layer by layer, until a single fingerprint remains, called the Merkle root. The block's own fingerprint only needs to include this one root.

The benefit is that once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be deleted. Only a few necessary fingerprints in the tree are kept, and the chain can still be fully checked. Nakamoto even worked out that keeping only each block's "header" would take just a few megabytes a year.

Section 8 · Simplified payment verification: no need for the whole ledger

What it solves: even compressed, ordinary users may not want to store and check the whole ledger. Can they simply confirm that a payment to them has been recorded?

They can. A user keeps only the block headers and, when needed, asks the network for a short proof that their transaction sits inside a particular block's Merkle tree. It is a bit like tracking a parcel: you do not need access to the courier's whole system, just the tracking number, to confirm your package is on its way. Many of today's lightweight wallets trace their design back to this idea.

The paper is just as clear about the cost: this approach relies on honest nodes making up the majority of the network, and it is less secure than running a full node yourself. That is why the paper suggests that businesses receiving frequent payments should still run their own full nodes.

Section 9 · Combining and splitting value: Bitcoin's "change"

What it solves: if every coin had to be sent separately, a single payment might need hundreds of transactions, which would be impractical.

Nakamoto's design allows one transaction to have several inputs and several outputs. Imagine you have a $50 bill and a $20 bill and need to pay $60. You hand over both (two inputs), and you get $60 paid to the seller plus $10 back (two outputs, one of them change to yourself).

This explains something about Bitcoin wallets: your balance is not a single number. It is made up of several pieces of unspent "change" of different sizes.

Section 10 · Privacy: pseudonymous, not anonymous

What it solves: if the ledger is open to everyone, is every transaction exposed?

Traditional banks protect privacy by keeping their books hidden from outsiders. Bitcoin cannot do that, because the ledger has to be public for everyone to check it. Nakamoto takes another route: the ledger is public, but it records public keys rather than names. Outsiders can see money moving from one address to another, but not who is behind either address. It is like a stock exchange publishing every trade without naming the buyer and seller.

As an additional safeguard, the paper recommends using a new key pair for every transaction so that payments cannot be linked to a common owner.

The second common misreading: many people believe Bitcoin is anonymous. Yet the paper itself warns that a transaction with several inputs reveals that those inputs belong to the same owner, and addresses can be linked, analyzed and eventually matched to real people. The paper uses the word "anonymous," but the mechanism it describes is closer to what we now call pseudonymous: your name is not on the chain, but every transaction you have made is.

Section 11 · Calculations: security you can compute

What it solves: after all this, how secure is the system? Nakamoto does not leave it at a description. He works it out.

He treats an attack as a race. Suppose you have received a payment, the transaction has been written into a block, and several more blocks have been added after it. To reverse it, an attacker must secretly start a separate chain from before that transaction and then catch up with and overtake the chain that honest nodes keep extending.

As long as the attacker has less computing power than the honest nodes, the further behind he starts, the slimmer his chances, and they shrink exponentially. The paper gives concrete figures: an attacker with 10% of the network's computing power, starting six blocks behind, has a chance of catching up of only about 0.024%, or roughly 2.4 in 10,000.

The third common misreading: the paper gives a probability, not a guarantee. The more blocks pile up, the closer the chance of reversal comes to zero, but strictly speaking it never reaches it. That is different from the idea of settlement finality in traditional finance. The familiar advice to "wait for six confirmations" rests on exactly this kind of calculation: once six blocks have been added after a transaction, about an hour later, the chance of reversal is small enough to ignore.

In The Ledger Heist, in The Trust Machine hall, you can adjust the attacker's share of computing power and watch how the odds of catching up from one and from six blocks behind change.

Section 12 · Conclusion: a condition in plain sight

The conclusion is brief. Nakamoto retraces the argument: digital signatures to establish who owns a coin, then proof-of-work and the longest chain to stop double spending. His conclusion is that the system is secure as long as honest nodes control a majority of the computing power.

That conclusion comes with a condition, and the paper states it plainly. Over the eighteen years since, much of the debate around Bitcoin has, in the end, been about how far that condition holds in the real world.

The twelve sections in one paragraph

If you wanted to sum up the whole whitepaper in one paragraph, it might go like this:

We want to pay online the way we pay with cash, without a bank (Section 1). So a coin is defined as a chain of signatures (Section 2), but that cannot stop the same coin being spent twice, so transactions need an order everyone accepts (Section 3). The right to set that order is earned by solving puzzles, votes are weighted by computing power, and everyone follows the chain with the most accumulated work (Section 4). The network keeps the books together in six steps (Section 5), attracts participants with new coins and fees, and makes honesty the most profitable choice (Section 6). Three engineering designs deal with storage, lightweight checking and change (Sections 7 to 9), a public ledger without names balances openness with privacy (Section 10), the odds of a successful attack are calculated (Section 11), and the conditions for all of it to hold are stated plainly (Section 12).

Closing the nine pages

What moves us most on rereading is its restraint. It makes no grand promises. It poses a problem, offers a solution, and states honestly the conditions under which that solution holds.

This is the paper that a little-noticed email pointed to eighteen years ago.

If you have never read the original, stop by the Whitepaper Wall and give it half an hour, from the first page to the ninth. With this guide behind you, it is easier going than you might expect.

The section summaries above are the editors' own readings of the original, not translations, and the original always takes precedence. If you find a discrepancy, please let us know at editorialoffice@btc.com.