The text that started Bitcoin runs to nine pages and about 3,500 words, and the word “blockchain” appears nowhere in it. The paper speaks of a “chain” and of the longest “proof-of-work chain”. Its author, writing as Satoshi Nakamoto, announced it on a cryptography mailing list on 31 October 2008. As of 23 October 2026, the network it describes had produced more than 972,000 blocks and ran at about 1,055 exahashes per second, according to the estimate of mempool.space that morning.
This is the Bitcoin whitepaper explained section by section, for readers who already know what Bitcoin is and want to know what its founding document actually argues. The short version: the paper proposes to replace a trusted third party, the bank or the mint, by a public order of transactions that is expensive to rewrite. Everything else in it is the engineering needed to make that order hold.
The easiest way in is to read it as a chain of objections. A coin can be a series of signatures, but then it can be spent twice. Stopping that needs a public order of events. That order needs timestamps. Timestamps need a cost that makes rewriting them hard. Each section answers the problem left open by the one before, and the eleventh does the maths on an attacker. Below, the sections are retold in our own words, with only a handful of short quotes, and set against the network as it runs in 2026.
What the paper is, and what it is not
The full title is “Bitcoin: A Peer-to-Peer Electronic Cash System”. The PDF hosted at bitcoin.org/bitcoin.pdf has nine pages: an abstract, twelve numbered sections, two pages of formulas with a short program and its results, and eight references. The copy we downloaded on 23 October 2026 carries file metadata from March 2009, so it is a later export rather than the very file linked in the October 2008 post. The Satoshi Nakamoto Institute, which keeps an archive of Satoshi’s writings, dates the paper 31 October 2008.
The text was also touched up after the announcement. The abstract Satoshi pasted into his email of 31 October differs in a few places from the one in the PDF: the email version talks of honest nodes controlling “the most CPU power”, where the PDF talks of a majority of CPU power held by nodes that are not cooperating to attack. The argument is the same; the wording was tightened.
It is a technical proposal, close in style to an academic preprint. The name Bitcoin appears only in the title and in the web address under the author’s name. The body talks about an “electronic coin” and about nodes spending CPU power. Several things that readers associate with Bitcoin are absent from it, including the 21 million cap, halvings, wallets and dedicated mining chips. We list them in a later section.
It is also not a “white paper” in the sense used by financial regulators today. Under the EU’s MiCA rules, a crypto-asset white paper is a disclosure document that the seller of a token must notify to a supervisor. Satoshi sold nothing and asked for nothing. The difference matters, and we come back to it at the end.
A careful reading takes about 15 to 20 minutes for the text, more if you work through section 11 (our estimate). The maths is optional: you can skip the formulas and still follow the argument, because the paper prints its results in plain tables.
Where to read the Bitcoin whitepaper in English, French and Italian
The original English text is at bitcoin.org/bitcoin.pdf, with a copy on the Satoshi Nakamoto Institute’s servers. The English paper page on bitcoin.org lists translations in dozens of languages, each as a PDF credited to a named translator. None of these translations comes from Satoshi, and none has any official status.
For French readers, there is no French paper page on bitcoin.org: the address bitcoin.org/fr/bitcoin-paper returned an error when we tested it on 23 October 2026. The French PDF is linked from the English page, at bitcoin.org/files/bitcoin-paper/bitcoin_fr.pdf. It runs to 11 pages, carries the title “Bitcoin : un système de paiement électronique pair-à-pair” and is credited to Arnaud-François Fausse. In a closing note, the translator warns that the translation cannot fully replace the English original and that any derived work should go back to the original documents. French searches usually call the paper the “livre blanc”, a term the translation itself does not use.
Italian has its own page, bitcoin.org/it/documento-bitcoin, which credits the Italian translation to Terzim. The older address bitcoin.org/it/bitcoin-paper now only shows a notice that the page has moved. The Italian PDF, also 11 pages, is at bitcoin.org/files/bitcoin-paper/bitcoin_it.pdf, under the title “Bitcoin: un sistema di moneta elettronica peer-to-peer”, while the web page calls it a “sistema di pagamento elettronico”. The Satoshi Nakamoto Institute hosts both translations too.
To cite the paper in an essay or a report, the usual form is: Satoshi Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System”, 31 October 2008, https://bitcoin.org/bitcoin.pdf. When you quote a translation, cite the English original as well, in line with the French translator’s note.
The Bitcoin whitepaper explained in twelve sections
The sections fall into three groups. Sections 1 and 2 state the problem: online payments depend on trust, and a purely digital coin can be copied. Sections 3 to 6 build the machine: timestamps, proof of work, the network’s routine and the reward that keeps people running it. Sections 7 to 11 handle the engineering and the proof, from storage and light clients to the shape of a transaction, privacy and the odds of an attack. Section 12 sums up in one paragraph.
| Section | Question it answers | What it became (as of October 2026) |
|---|---|---|
| 1 Introduction | Why remove the trusted third party? | The stated motive of the whole project |
| 2 Transactions | What is a coin? | Signed transactions between key pairs |
| 3 Timestamp Server | How do we fix an order of events? | Each block points to the hash of the previous one |
| 4 Proof-of-Work | Why is that order hard to rewrite? | Mining, about 1,055 EH/s on 23 October 2026 |
| 5 Network | What does each node do? | The block relay and validation routine |
| 6 Incentive | Why would anyone run a node? | Block subsidy plus fees |
| 7 Reclaiming Disk Space | Will storage blow up? | Merkle roots in 80-byte headers |
| 8 Simplified Payment Verification | Can a user check without a full node? | Light wallets |
| 9 Combining and Splitting Value | How do amounts add up and split? | Inputs, outputs and change |
| 10 Privacy | Who can see what? | Public ledger, pseudonymous addresses |
| 11 Calculations | How safe is a payment after z blocks? | The habit of waiting for confirmations |
| 12 Conclusion | What has been shown? | Consensus by computing power |
Abstract and introduction: trust treated as a cost
The abstract states the goal in a single sentence: cash for the internet that moves between two people with no financial institution in the middle. It then names the obstacle, double spending, and the remedy, a peer-to-peer network that stamps transactions into a chain of proof of work. The security condition comes at once. The scheme holds for as long as most of the computing power belongs to nodes that are not working together to attack it.
The introduction is the only part that reads like an economic critique, and its target is narrow: not money, not banks as such, but the cost of mediation. A payment that can be reversed is a payment someone has to police. Settling disputes costs money, that cost puts a floor under the size of a worthwhile payment, and merchants protect themselves by asking customers for extra personal details. Some fraud becomes a cost that everyone simply budgets for.
Face to face, cash avoids all of this. In 2008 nothing did the same online. Satoshi’s answer is “an electronic payment system based on cryptographic proof instead of trust”. The detail most summaries skip is that the paper keeps a place for buyer protection: payments that cannot practically be reversed protect the seller, and escrow arrangements could be layered on top for the buyer. Dispute resolution moves out of the payment itself; it is not abolished.
A short note for 2026 readers: many people now hold bitcoin through a trading platform, which brings the trusted third party back in. Our lesson on how centralized exchanges work explains what you trust when you do that. The paper itself only describes people holding their own keys.
Section 2: a coin is a chain of signatures
Section 2 opens with the most compact line in the paper: “We define an electronic coin as a chain of digital signatures.” There is no coin object at all, only a record of hand-overs. To pay someone, you sign two things together: a fingerprint (a hash) of the transaction that gave you the coin, and the public key of the person you are paying. Each hand-over goes at the end of the record, so anyone holding it can walk ownership back step by step, much as a bank clerk reads the endorsements on the back of a cheque.
The signature is made with the owner’s private key, which never has to leave their hands; the next owner is named by a public key, and today’s Bitcoin addresses are usually derived from public keys. How a key pair is generated and why it cannot be guessed is the subject of a later lesson. Here it is enough to know that a valid signature proves the right key was used.
What signatures cannot show is that the owner did not give the same coin to someone else a minute earlier. That is the double-spending problem. The standard fix of the time was a mint: a central issuer that sees every payment, retires each coin after use and issues a fresh one. The paper’s objection is blunt. A mint simply rebuilds a bank, with one company in the path of every payment and the whole money system at its mercy.
So the paper sets out to replace what the mint knew. The mint saw every transaction and decided which came first. Without it, every transaction has to be broadcast in public, an idea the paper credits to Wei Dai’s b-money proposal of 1998, and participants need some way to settle on one shared ordering. For a payee, the question becomes simple: did most of the network see my payment before any rival spend of the same coin? Our guide to how crypto transactions work follows the same steps as a wallet performs them today.
Sections 3 and 4: a timestamp chain that is costly to rewrite
Satoshi did not invent the pieces used in these two sections, and the paper says so in its references. Timestamping documents with chained hashes goes back to work by Stuart Haber and W. Scott Stornetta published from 1991, and charging a computing cost to send a message comes from Adam Back’s Hashcash. Our lesson on digital money before Bitcoin tells the story of those earlier attempts; here we stay with how the paper combines them.
The timestamp server
The starting point is an old notarial trick. Gather a batch of items, compute one hash for the whole batch, and print that value somewhere public that is hard to alter later; the paper’s examples are a newspaper and a Usenet post. Nobody could have computed the hash without having the items, so the printed value proves they existed by that date. Now chain the batches, each new hash covering the previous one, and tampering with an old batch breaks every value printed after it. The word blockchain grew out of this idea later; our guide to what a blockchain is covers the general concept.
Proof of work: one CPU, one vote
A newspaper is a central party, so section 4 swaps it for proof of work. Nodes keep trying values until the block’s hash (SHA-256 in the paper’s example) begins with a required number of zero bits. The value they vary is a counter inside the block, the nonce. Each extra zero bit doubles the expected number of tries, while anyone can check a winning answer with a single hash. The cost runs one way: to alter a block that already has others on top of it, an attacker must redo its work and then the work of every later block.
The same device answers a second question: who gets to decide? Counting one vote per internet address would hand the vote to anyone able to rent many addresses. “Proof-of-work is essentially one-CPU-one-vote,” the paper says, and the majority’s verdict is simply the chain with the most work behind it, usually called the longest chain. The section ends with a rule for difficulty, which follows a moving average aimed at a steady number of blocks per hour and rises when blocks arrive too quickly.
Two things changed in practice. The network now recalculates difficulty every 2,016 blocks, aiming for two weeks per period, as the bitcoin.org developer guide explains; the paper gave no such number. And the “one CPU” image has aged. Mining is done on specialised chips, and the network’s hash rate stood at about 1,055 exahashes per second on 23 October 2026, by mempool.space’s estimate. The vote is still counted in computing work, just not on ordinary processors.
Sections 5 and 6: how the network runs, and why anyone runs it
Section 5 sets out the routine as six numbered steps. In our words:
- A new payment is sent out to every node the sender can reach.
- Each node collects the payments it hears about into a candidate block.
- Each node spends computing power looking for a valid proof of work for that block.
- The first node to find one sends the finished block to the others.
- The others check every payment in it and reject the block if any payment is invalid or spends coins already spent.
- A node shows that it accepts the block by starting work on the next one, which carries the accepted block’s hash as its link to the past.
No node ever says “yes” in a message: agreement shows in where it spends its work. Nodes regard the chain with the most work as the valid one. Now and then two competing blocks appear within seconds of each other, and for a while the network is split, each node building on whichever version reached it first while keeping the other in reserve. The next block settles it, because one branch is now longer and everyone moves there. Lost messages do little harm. A payment only needs to reach enough nodes to get into a block soon, and a node that missed a block notices the gap when the next one arrives, then asks for it.
Section 6 deals with the obvious objection: why would anyone pay for the electricity? The answer is that the first transaction of every block is special and creates new coins for whoever made the block; developers now call it the coinbase transaction. It is also the only way coins enter circulation, since there is no issuer. Satoshi likens it to gold miners spending resources to bring new gold to market, an image that stuck, since the people who make blocks are now called miners. Fees come on top: whatever a transaction’s inputs hold beyond its outputs is left for the block’s creator.
Next comes a promise. Once “a predetermined number of coins” are in circulation, the reward can rely on fees alone, with no further inflation. The paper gives no number. The figure arrived with the software: in the announcement of the first release on 8 January 2009, Satoshi wrote that the total would be 21 million coins, handed to block makers with the amount cut in half every four years. That schedule, the Bitcoin halving, is enforced by the software. The paper never describes it.
The section ends on a bet about motives rather than a proof. Take a greedy attacker who controls more computing power than every honest node put together. He could spend it reversing his own payments, or spend it minting coins under rules that already pay him more than anyone else. Satoshi argues that the second choice pays better, since cheating would damage the value of the coins he holds. It is an argument about incentives, not a guarantee, and later research tested its limits.
Sections 7 to 9: pruning, light verification and the shape of a transaction
Reclaiming disk space
Section 7 worries about storage. Once a coin’s latest transaction is buried under enough blocks, the older spent transactions are dead weight. The fix is to hash a block’s transactions in pairs, then pairs of pairs, up to a single value: a Merkle tree, named after Ralph Merkle, whose 1980 paper is among the references. Only that top value, the root, enters the block’s hash, so branches holding spent transactions can be cut away without breaking the chain.
A header stripped of its transactions weighs about 80 bytes. Assume one block every 10 minutes and the headers come to 4.2 MB a year, which the paper sets against the 2 GB of memory that computers typically shipped with in 2008. This is the only place the paper mentions ten minutes, and only as an assumption for the arithmetic.
The forecast held. With 972,744 blocks on 23 October 2026 (heights 0 to 972,743), the headers alone add up to about 78 MB, by our calculation. Full blocks are another matter: they hold the transactions, and the complete history weighs far more than the headers, which is why the pruning and light-client ideas of sections 7 and 8 still matter.
Simplified payment verification
Section 8 shows how a user can check a payment without running a full node. The user keeps only the chain of headers, choosing the one with the most work after asking several nodes, and requests the Merkle branch: the handful of hashes that connect the payment to the root in one header. That does not prove the payment is valid. It proves that a node put it in a block and that more blocks have been built on top since.
Satoshi is frank about the weak point. A light user sees whatever the majority of computing power shows, so an attacker who controlled the network could feed them invented transactions for as long as that control lasted. The paper floats the idea of warnings sent by full nodes, and expects businesses that are paid often to run their own. Phone wallets are built on this idea today. The distinction the paper draws still holds: a light wallet trusts that the chain it is shown is the honest one, while a full node checks every rule itself.
Combining and splitting value
Section 9 deals with amounts. Say you received 0.3 and 0.5 bitcoin in two earlier payments and now owe someone 0.7. Instead of tracking coins one by one, a transaction takes both earlier payments as inputs and creates new outputs: 0.7 to the payee and a little under 0.1 back to you as change, the difference being the fee. The paper describes the usual pattern as one or several inputs and no more than two outputs. Real transactions can have many more outputs, so read that as the common case, not a limit.
Nor does it matter that each input depends on older transactions, which depend on older ones still. Checking a payment never requires rebuilding a coin’s full history.
Section 10: privacy by keeping keys anonymous
Banks protect privacy by keeping records closed: only the parties and the bank see a payment. A ledger that everyone can read rules that out, so Satoshi cuts the flow of information at a different point. Amounts and timing are public; who stands behind each key is not. The comparison is with a stock exchange tape, which prints the time and size of every trade without naming buyer or seller.
Two cautions follow. The paper advises a fresh key pair for every transaction, so that payments do not pile up under one identity. And it admits that a transaction spending several inputs at once tells the world those inputs share an owner, so a single key traced to a person can expose others. This is pseudonymity, not anonymity: anyone studying the public ledger can follow exactly the links section 10 describes.
Section 11: the maths of an attacker racing the honest chain
Section 11 first narrows the threat. Even an attacker who builds a faster chain cannot conjure coins or spend someone else’s, because honest nodes refuse blocks with invalid transactions. The one thing within his reach is undoing his own recent payment: pay a merchant, collect the goods, then replace history with a version in which the money never left.
Satoshi treats this as a race between two chains. Call p the share of new blocks found by honest nodes and q the share found by the attacker. Every honest block widens the gap by one and every attacker block narrows it by one, which is the classic Gambler’s Ruin problem of probability theory; the reference is William Feller’s 1957 textbook. An attacker with as much power as the honest side, or more, catches up sooner or later. With less, his chance of ever closing a gap of z blocks shrinks exponentially as z grows.
Then the practical question: how long should a merchant wait? In the paper, the merchant hands over a brand-new public key only just before the payment, so the attacker cannot have been preparing a rival chain for that exact transaction in advance. The merchant waits until the payment is in a block with z further blocks on top, estimates how far a secret attacker could have got in that time (a Poisson distribution, in the paper), and adds up the chances. The calculation is given as a short program in C, followed by its results.
Here are the paper’s own figures for an attacker holding 10% of the computing power (q = 0.1) and one holding 30% (q = 0.3). We re-ran the paper’s formula for several rows and got the same values.
| Blocks after the payment (z) | Attacker with 10% (q = 0.1) | Attacker with 30% (q = 0.3) |
|---|---|---|
| 0 | 100% | 100% |
| 1 | 20.46% | not given |
| 5 | 0.0914% | 17.74% |
| 6 | 0.0243% | not given |
| 10 | 0.00012% | 4.17% |
| 20 | not given | 0.248% |
| 50 | not given | 0.00006% |
A second table in the paper gives the number of blocks needed to push the attacker’s chance below 0.1%: 5 blocks at 10% of the power, 11 at 20%, 24 at 30%, 89 at 40% and 340 at 45%. The closer the attacker gets to half the network, the longer the wait.
The popular rule of waiting for six confirmations matches the 10% row, where six blocks bring the odds to about 0.02%. The paper never writes “six confirmations”: that is a later convention among wallets and exchanges, and platforms set their own numbers.
The model has limits. It assumes an attacker who builds a rival chain in secret and tries to overtake. In November 2013, Ittay Eyal and Emin Gün Sirer described “selfish mining”, a strategy in which a pool withholds the blocks it finds to earn more than its share, and argued that the usual one-half threshold is too optimistic. Their paper proposes a change meant to protect against pools holding less than a quarter of the resources. Section 11 does not cover that kind of behaviour.
Section 12 and the references: eight sources, none of them a bank
The conclusion fits in one paragraph and restates the argument rather than adding to it. Signatures settle who owns a coin. The proof-of-work network settles the order of payments, and after a few blocks that order costs an attacker more than he can hope to gain, provided honest nodes hold most of the computing power. Nodes need no names and almost no coordination. “They vote with their CPU power,” the paper says: building on a block counts as a yes, refusing to build on it as a no.
The reference list is short and telling. It holds Wei Dai’s b-money (1998), three papers on timestamping by Haber, Stornetta and Bayer (1991 to 1997), a timestamping service design by Massias, Avila and Quisquater (1999), Adam Back’s Hashcash (2002), Ralph Merkle’s paper on public-key protocols (1980) and Feller’s probability textbook (1957). Apart from b-money, itself a proposal for digital money from the cypherpunk mailing lists, they are about cryptography, timestamping or probability. None is an economics paper, a central bank document or a legal text.
That says something about the paper’s method. It is a synthesis: most of its parts existed, and the new step was to tie timestamping and Hashcash-style work to a reward, so that the cost of rewriting history falls on anyone who wants to cheat and pays anyone who plays fair. Satoshi gave the motive more bluntly a few months later, writing on the P2P Foundation forum on 11 February 2009 that “The root problem with conventional currency is all the trust that’s required to make it work” (Satoshi Nakamoto Institute archive).
What the paper does not say, and what the network added
A search through the PDF turns up no occurrence of the following words or ideas, all of which are now part of how people describe Bitcoin:
- the word “blockchain”, a later coinage from the paper’s blocks and chain;
- a total of 21 million coins or a halving every four years, both first stated in the software release announcement of January 2009;
- a block size limit of 1 MB or any other figure;
- miners as a profession, wallets, the mempool, graphics cards or specialised mining chips;
- the Lightning Network or any plan for scaling payments, a subject for a later lesson.
Some ideas in the paper proved accurate. Header storage grew at roughly the rate it predicted, about 78 MB after nearly 18 years against a forecast of 4.2 MB a year. The race between an attacker and the honest chain still frames how people think about reversals. Others were overtaken. Computing power moved from home processors to industrial chips and pools, and privacy proved weaker than the stock-tape comparison suggests, because the links between inputs can be followed by anyone.
Some questions are a matter of debate rather than fact, such as whether Bitcoin is used mainly as the cash the title promises or mainly as a store of value. The paper does not settle that, and our page on Bitcoin shows the network’s figures rather than an opinion on it.
One curiosity we could check ourselves: the PDF is stored inside the blockchain, cut into pieces across the outputs of an ordinary transaction confirmed in block 230,009 on 6 April 2013 (the transaction on mempool.space). We put those pieces back together on 23 October 2026 and got a file identical, byte for byte, to the one bitcoin.org serves today: both have the same SHA-256 fingerprint.
The anniversary of 31 October is celebrated by enthusiasts as “Whitepaper Day”. No official body sets it; it is a community date. The story of the person behind the pseudonym, and of the first blocks mined in January 2009, belongs to later lessons in this path.
The whitepaper and the law: why a 2008 paper is not a MiCA white paper
Since the EU’s Il MiCA (Markets in Crypto-Assets) è il regolamento europeo 2023/1114 che fissa regole comuni per gli emittenti di cripto-attività, le stablecoin e i prestatori di servizi per le cripto-attività (CASP) in tutta l’UE. Si applica pienamente dal 30 dicembre 2024.">markets in crypto-assets regulation took effect, “white paper” has a legal meaning in Europe. Whoever offers most kinds of crypto-asset to the public, or asks for one to be admitted to trading, must write a crypto-asset white paper with prescribed contents and notify it to the national supervisor, such as the AMF in France or Consob in Italy, at least 20 working days before publishing it. Article 8 of MiCA forbids supervisors to demand that they approve it beforehand. Our guide to the MiCA regulation explains the regime.
Bitcoin does not fit that pattern, because it has no issuer. Recital 22 of MiCA keeps crypto-assets with “no identifiable issuer” outside these rules, and in an answer published by ESMA (Q&A 2552, answered on 18 February 2026), the European Commission confirmed that no white paper is required for such assets, not even from a trading platform that lists them. Platforms that trade them remain covered by MiCA’s other rules. Separately, Article 4(3), as shown in ESMA’s interactive single rulebook, exempts crypto-assets created automatically as a reward for maintaining the ledger or validating transactions, which is how new bitcoin appears under section 6 of the paper. The Commission’s answer is guidance: only the EU Court of Justice can give a binding reading of the law.
For readers in the United States and the United Kingdom the point is the same. A token’s white paper is written by whoever issues or sells the token, and no regulator vets it. It is not a registration statement: the SEC’s investor.gov alert on crypto asset securities recalls that an offering of securities must be registered with the SEC or fall under an exemption, and that registration is what forces an issuer to disclose key information. In the UK, firms promoting cryptoassets must, since 8 October 2023, be authorised or registered by the FCA or have their marketing approved by an authorised firm, and the FCA still describes cryptoassets as “high-risk and largely unregulated”. Before trusting a project because it has a white paper, check who wrote it and who is selling.
The Bitcoin paper is a different genre: a technical proposal by a pseudonymous author, with no sale attached. Its authority comes from the fact that anyone can test its claims against the running network, which is what the sections above have done.
