Chapter 4

The Whitepaper

Bitcoin began as a nine-page paper. Before the software, before the first coin, there was a problem stated plainly and a design to solve it. Know where the paper came from and what it claims, and the rest of this book snaps into place.

Where It Came From

On October 31, 2008, someone writing as Satoshi Nakamoto sent a short email to a public mailing list for cryptography researchers. The subject line was plain: “Bitcoin P2P e-cash paper.” It linked to a PDF titled Bitcoin: A Peer-to-Peer Electronic Cash System. Nine pages. An abstract, twelve numbered sections, and a short list of references.

The paper is still at the address it was first published to: bitcoin.org/bitcoin.pdf. Copies are everywhere, and it is short enough to read in an evening.

The software followed. The first entry in the ledger was written on January 3, 2009. The paper names its author and says nothing more about them. The design stands on its own.

The Thesis

The first sentence of the abstract says most of it:

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.

Directly. From one party to another. With no institution in between. Everything else in the paper is in service of making that sentence true.

The problem the paper names is trust. Online payments run through a financial institution that acts as a trusted third party. With that come reversals, fees, a practical minimum size for a payment, and the need to accept the institution’s version of the record. The paper’s answer is one line long: “What is needed is an electronic payment system based on cryptographic proof instead of trust.”

The hard part is double spending. Anything digital can be copied, so what stops someone from spending the same coin twice when there is no referee in the middle? The paper’s solution is the public ledger you met in the last chapter: every transaction recorded, in order, by a network of computers, with the order fixed by real computing work. Once a payment is written deep enough into that record, rewriting it would cost more than it is worth.

Why A Timestamp Server Matters

Double spending is really a question of order. If two payments try to spend the same coin, only one can count, and the only fair rule is that the first one wins. A bank settles that with its own clock and its own database. Take the bank away, and you need another way for everyone to agree on what came first.

That is what a timestamp server does. It takes a batch of records, makes a fingerprint of them, and publishes the fingerprint where everyone can see it. Each new fingerprint includes the one before it. So every stamp proves two things: these records existed by this moment, and they came after the records in the previous stamp. Change anything in the past and every fingerprint after it stops matching.

The paper’s small step was to make the stamping cost real work, so nobody can quietly print a longer history of their own. Put those two ideas together and you have bitcoin’s ledger: a public timestamp server for money, where the longest chain of stamps is the agreed order of events. When your wallet later says a payment is confirmed, this is what it means. The payment has been stamped, and stamps have been laid on top of it.

What The Sections Say

In plain words, one line each:

Introduction. The trust problem, and what reversals and fees cost.
Transactions. A coin is a chain of digital signatures; each owner signs it over to the next.
Timestamp Server. Transactions are fingerprinted into a chain, so their order is public and hard to change (see above).
Proof-of-Work. Writing to the chain costs real computing effort; the chain with the most work behind it is the record.
Network. The steps each computer follows: collect transactions, do the work, share the block, build on it.
Incentive. Whoever writes a block earns new coins and the fees inside it, so honesty pays better than attack.
Reclaiming Disk Space. Old detail can be pruned while the chain stays verifiable.
Simplified Payment Verification. A payment can be checked without holding the whole chain. This is why a wallet fits on a phone.
Combining and Splitting Value. A transaction has many inputs and outputs, usually a payment and change. This is the shape of your first send.
Privacy. Keys are public, names are not; use a fresh key for each payment.
Calculations. The arithmetic of how unlikely a cheater is to catch up with the honest chain.
Conclusion. “We have proposed a system for electronic transactions without relying on trust.”

What You Will Meet Again

Three of those sections show up in your hands within a few chapters. The chain of signatures in Section 2 is what your keys do when you send. The payment and change in Section 9 is what your first transaction will look like on an explorer, with the fee from Section 6 attached. And Section 8 is the reason a lightweight wallet on a phone is enough to start.

Try It: Read The Abstract

open bitcoin.org/bitcoin.pdf
read the abstract, a couple hundred words
notice how often the word trust appears on the first page
read the last sentence of the conclusion

Action Checklist

☐ know the title, the date, and where the paper lives
☐ be able to say the thesis in one sentence
☐ connect three sections to things you will do: keys, change and fee, a light wallet