On 31 October 2008, someone using the name Satoshi Nakamoto posted a nine page paper to a cryptography mailing list. The covering note was two sentences long and opened: "I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party."
The paper itself, Bitcoin: A Peer-to-Peer Electronic Cash System, is short enough to read in an afternoon and narrower than its reputation. It does not describe a new financial system. It solves one problem that had blocked every earlier attempt at digital cash, and everything else follows from that.
The problem: two people, one coin
Digital money is easy to build if you are willing to appoint someone to keep the books. A bank, a card network or a payment company holds the ledger, checks that you have the funds, and moves the number. That model works. The paper's opening section says as much, and then names what it costs: nothing is truly final, because the institution can always reverse it, and the possibility of reversal spreads the need for trust to everyone in the chain.
Take the record keeper away and one problem appears immediately. A double spend is sending the same coin to two people at once. Alice signs a payment to Bob, signs a second payment of the same coin to Carol, and sends each to a different part of the network. Both signatures are perfectly valid. Nothing about the signatures tells you which came first. That is the situation in the illustration at the top of this page.
The paper is blunt that signatures alone are not enough: "Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending." The earlier proposals it cites, Wei Dai's b-money from 1998 and Adam Back's Hashcash from 2002, each supplied a piece and neither closed this gap.
The proposal: agree on an order, and make the order expensive to change
The answer the paper gives is not a rule about which transaction is correct. It is a way for strangers to agree on a sequence.
Transactions are broadcast publicly. Participants gather recent ones into a block, and each block contains the hash of the block before it, so the blocks form a chain in a fixed order. Publishing a block requires finding a number that makes the block's hash start with a certain run of zeros, which can only be done by trying enormous numbers of candidates. That search is the proof of work. Verifying somebody else's answer costs one hash.
Now the ordering is settled by something outside anyone's control. Whichever of Alice's two payments lands in a block first is the one that happened; the other refers to a coin that has already moved and every node rejects it. Nobody adjudicated. The rule is mechanical.
Why the chain becomes hard to rewrite
Rewriting history means redoing the proof of work for the block you want to change and for every block after it, while the rest of the network keeps extending the chain you are racing. The paper's phrase is "one-CPU-one-vote": the chain with the most work behind it is the one nodes treat as real.
Section 11 works the arithmetic out, and the result is the useful part. The probability that an attacker who controls a minority of the network catches up falls off exponentially with each block added on top. The paper's own table gives the numbers: an attacker with 10 per cent of the network needs to wait 5 blocks for the risk to drop below one in a thousand, and an attacker with 45 per cent needs 340. That is where the habit of waiting for a few confirmations comes from, and also why "wait for six" is a convention rather than a guarantee.
The security claim is honest about its own condition. It holds as long as honest participants control the majority of the work. The paper never claims otherwise.
What the paper does not say
This is the part worth carrying away, because most of what people attribute to the white paper is not in it.
It never mentions 21 million. Section 6 says only that "once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees". The actual cap, and the halving schedule that produces it, live in the code that shipped in January 2009, not in the paper.
It never uses the word "blockchain". It describes a chain of blocks and a timestamp server. The word arrived later, along with a decade of projects claiming the structure without the thing that makes it work, which is the cost of extending it.
It does not describe a store of value, or an investment. The word it uses throughout is cash. What the paper is arguing about is settlement.
It does not solve privacy. Section 10 is candid: because every transaction is announced publicly, the traditional banking approach of restricting who can see the ledger is unavailable, and what is left is keeping public keys anonymous and using a fresh one for each transaction.
Reading it yourself
The paper is nine pages including the references, and about half of it is diagrams and one probability calculation. If you have followed this far, you can read it. The sections that repay a slow read are 2 and 5, which set out what a coin is and what a node does, and 11, which is the only place the security argument is stated as a number rather than an assertion.
The mechanisms it names each have their own post here: what a node checks, what miners are actually competing for, and the key pair behind the signatures the paper starts from.