The Bitcoin Whitepaper, Section by Section

What the Whitepaper Is — Before You Read It

• The Bitcoin whitepaper is a nine-page document titled "Bitcoin: A Peer-to-Peer Electronic Cash System," released by Satoshi Nakamoto on 31 October 2008. It was posted to the cryptography mailing list at metzdowd.com under the subject line "Bitcoin P2P e-cash paper," timestamped 14:10 US Eastern time.
• Its structure is an abstract, twelve numbered sections, and eight references. Counting the title and the reference list, the whole document runs to roughly 3,500 words, with four displayed equations and seven figures — two of which, in Sections 7 and 10, are two-panel. For a technical paper it is unusually short, sketching the skeleton of a design rather than the details of an implementation.
• This topic walks through those twelve sections in order and sets out what the text actually claims. Both the original and a Japanese translation are published on bitcoin.org. Translations are a genuine aid, but where a point is contested it is worth checking the English original.
• One thing is worth establishing before reading. The whitepaper is not a finished specification. Neither the software that launched in January 2009 nor Bitcoin as it runs today is fully described by it. The final section gathers those differences. All statements about the present state of the network are as of August 2026.

Abstract and Section 1, "Introduction" — Framing the Problem

• The abstract opens with the claim that 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. It then defines the problem: 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.
• What is proposed is a peer-to-peer network that timestamps transactions into an ongoing chain of hash-based proof-of-work. The abstract states that the longest chain serves not only as proof of the sequence of events witnessed, but as proof that it came from the largest pool of CPU power. The security premise is that as long as a majority of CPU power is controlled by nodes not cooperating to attack the network, the honest chain grows fastest.
• Section 1 begins with a diagnosis of the status quo. Commerce on the internet relies almost exclusively on financial institutions serving as trusted third parties to process electronic payments. The system works well enough for most transactions, the paper argues, but it cannot escape the weaknesses inherent in the trust-based model.
• Three weaknesses are named. First, financial institutions cannot avoid mediating disputes, so completely non-reversible transactions are not really possible. Second, the cost of mediation raises transaction costs and cuts off small casual transactions entirely. Third, because reversal remains possible, merchants must be wary of their customers and hassle them for more information than they would otherwise need. A certain percentage of fraud, the paper adds, is accepted as unavoidable.
• On that basis it formulates the requirement: what is needed is an electronic payment system based on cryptographic proof instead of trust. Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers. Section 1 then closes by announcing a solution to the double-spending problem using a peer-to-peer distributed timestamp server, and by stating that the system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes. What irreversibility means in practice is covered in "Why Lost Bitcoin Cannot Be Recovered."

Section 2, "Transactions," and Section 9, "Combining and Splitting Value"

• Section 2 opens by defining an electronic coin as "a chain of digital signatures." Each owner transfers the coin to the next by signing, with their own private key, a hash of the previous transaction and the public key of the next owner, and adding that to the end of the coin.
• A payee can verify the signatures to verify the chain of ownership. That alone, however, does not establish that a previous owner did not spend the coin twice. Here the paper places the double-spending problem at the centre of the argument.
• The conventional solution was a trusted central authority — a mint — that checks every transaction. But then the coin must be returned to the mint after each transaction so a new one can be issued, and the fate of the entire money system comes to depend on the company running the mint. On those grounds the paper rejects it.
• What it requires instead is agreement on ordering, under which the earliest transaction is the one that counts. Because the only way to confirm the absence of a transaction is to be aware of all transactions, the paper concludes that transactions must be publicly announced. What the payee needs is proof that, at the time of each transaction, the majority of nodes agreed it was the first received.
• Section 9, "Combining and Splitting Value," is a short supplement. Making a separate transaction for every cent would be unwieldy, so transactions contain multiple inputs and outputs. Normally there is either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs — one for the payment and one returning the change to the sender. This is the structure known today as the UTXO model, covered in detail in "Transactions Deep Dive."
• Section 9 makes one further point: fan-out, where a transaction depends on several transactions and those depend on many more, is not a problem here. The reason given is that there is never a need to extract a complete standalone copy of a transaction's history.

Section 3, "Timestamp Server," and Section 4, "Proof-of-Work"

• Section 3 introduces a timestamp server as the starting point of the solution. It works by taking a hash of a block of items to be timestamped and widely publishing that hash, as in a newspaper or Usenet post. To get into the hash, the data must have existed at that time — that is what the timestamp proves.
• Each timestamp includes the previous timestamp in its own hash, forming a chain in which each additional timestamp reinforces the ones before it. The structure described here is what later came to be called the blockchain, though that word never appears anywhere in the paper.
• Section 4 argues that implementing this on a peer-to-peer basis requires a proof-of-work system similar to Adam Back's Hashcash. The work involves scanning for a value that, when hashed with something such as SHA-256, begins with a required number of zero bits. The average work required is exponential in the number of zero bits, while verification takes a single hash.
• Here the paper introduces a political analogy. If majority decision were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs, whereas proof-of-work is essentially "one-CPU-one-vote." The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it.
• Difficulty adjustment gets a single sentence. To compensate for increasing hardware speed and varying interest in running nodes, difficulty is determined by a moving average targeting an average number of blocks per hour; if blocks are generated too fast, difficulty increases. Concrete parameters such as a 2,016-block interval appear nowhere in the paper. Mining as practised today is covered in "How Mining Works."

Section 5, "Network" — Six Steps and the Longest-Chain Rule

• Section 5 states that the steps to run the network are as follows, and lists six of them. It is the most compact statement of how Bitcoin operates, and probably the most quoted passage in the entire paper.

• Step 6 deserves attention. There is no dedicated message declaring that a block has been accepted; beginning to build on top of it is itself the vote. Both agreement and rejection are expressed solely through where a node directs its computational resources.
• The handling of splits appears in the same section. Nodes always consider the longest chain to be the correct one and keep extending it. If two nodes broadcast different next blocks simultaneously, each works on the one it received first while saving the other branch. The tie breaks when the next proof-of-work is found and one branch becomes longer; nodes working on the shorter branch switch over.
• The paper makes remarkably relaxed assumptions about network reliability. Transaction broadcasts do not need to reach all nodes — reaching many is enough for a transaction to get into a block before long. Block broadcasts are tolerant of dropped messages, and a node that misses a block will request it once the next block arrives and reveals the gap.
• This best-effort design choice is what backs the abstract's claim that the network itself requires minimal structure. Nodes can leave and rejoin at will, and they reconstruct what happened while they were gone by accepting the longest proof-of-work chain.

Section 6, "Incentive" — Why Mining Beats Attacking

• Section 6 begins by establishing that the first transaction in a block is a special transaction starting a new coin owned by the creator of that block — what is now called the coinbase transaction. This gives nodes an incentive to support the network and, since there is no central authority to issue them, provides a way to distribute coins into circulation in the first place.
• The paper likens this to gold mining. The steady addition of new coins is analogous to gold miners expending resources to add gold to circulation; in this case what is expended is CPU time and electricity. It is worth noting that energy consumption is written into the design as a necessity from the very beginning.
• Fees appear in the same section. If the output value of a transaction is less than its input value, the difference is a transaction fee added to the incentive value of the block containing it. And once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free.
• What matters here is that the paper says only "a predetermined number." Neither the 21 million cap nor the roughly four-yearly halving appears anywhere in it. The issuance schedule was defined in the implementation, and is covered in "Bitcoin's Controlled Supply" and "What is the Halving?"
• The section closes with an economic argument about security. Even if a greedy attacker could assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments and using it to generate new coins. Playing by the rules ought to be more profitable, since such rules favour him with more new coins than everyone else combined, rather than undermining the system and the validity of his own wealth.
• Notice that this argues attack is economically irrational, not that it is technically impossible. The conditions under which the premise breaks — for instance whether a fee market alone can fund the security budget as the block subsidy keeps shrinking — are not examined in the paper and remain unsettled today; they are treated in "Criticisms of Bitcoin." The concrete routes by which an attack could succeed are set out in "Bitcoin's Vulnerabilities."

Section 7, "Reclaiming Disk Space," and Section 8, "Simplified Payment Verification"

• Section 7 states that once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space. To do this without breaking the block's hash, transactions are hashed in a Merkle tree with only the root included in the block's hash. Old blocks can then be compacted by stubbing off branches of the tree, and the interior hashes need not be stored.
• Concrete figures follow. A block header with no transactions would be about 80 bytes. If blocks are generated every ten minutes, 80 bytes × 6 × 24 × 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory.
• That estimate held up rather well. As of August 2026 the block height is roughly 960,000, so headers alone amount to 80 bytes × 960,000 ≈ 77MB — close to the roughly 74MB you get by extending the paper's 4.2MB per year across the roughly seventeen and a half years since the genesis block. What a real full node needs is a different matter: bitcoin.org's full-node guide states that the initial synchronisation requires roughly 740GB of download (as of August 2026). The gap comes from transaction data, not headers.
• Section 8 addresses verifying payments without running a full network node. A user need only keep a copy of the block headers of the longest proof-of-work chain and obtain the Merkle branch linking the transaction to the block it is timestamped in. The user cannot check the transaction independently, but by linking it to a place in the chain can see that a network node accepted it, and blocks added afterwards further confirm that acceptance.
• The paper is explicit about the limits of this method. Verification is reliable as long as honest nodes control the network, but is more vulnerable if an attacker overpowers it: for as long as the attacker can sustain that, simplified verification can be fooled by fabricated transactions. As a countermeasure the paper proposes accepting alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block to confirm the inconsistency. Businesses that receive frequent payments, it adds, will probably still want to run their own nodes.
• Implementation diverged somewhat from this. The alert mechanism never took hold, and Bitcoin Core's storage reduction arrived not as tree pruning but as deletion of validated block files (block pruning, introduced in v0.11.0 in July 2015). On the light-client side, the Bloom filter approach proposed in October 2012 (BIP 37) has been disabled by default since Bitcoin Core v0.19.0 (November 2019) over privacy and denial-of-service concerns, and filters generated block-side (BIP 157/158) are the recommended successor.

Section 10, "Privacy," and Section 11, "Calculations"

• Section 10 frames the traditional banking model as achieving privacy by limiting access to information to the parties involved and the trusted third party. Bitcoin cannot use that method, since all transactions must be publicly announced, but privacy can still be maintained by breaking the flow of information in another place.
• Concretely, public keys are kept anonymous. The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone. The paper likens this to the "tape" released by stock exchanges, where the time and size of individual trades is public but the parties are not.
• As an additional firewall it recommends using a new key pair for each transaction. The limits are stated just as plainly. Multi-input transactions necessarily reveal that their inputs were owned by the same owner, so some linking is unavoidable, and if the owner of a key is revealed, linking could expose that owner's other transactions as well. Traceability in practice is covered in "Privacy & Anonymity."
• Section 11 is the only part of the paper that develops a probability model. It considers an attacker trying to generate an alternate chain faster than the honest chain, but first bounds the scope. Even if that succeeds, it does not let the attacker create value out of thin air or take money that never belonged to him, because nodes will not accept an invalid transaction as payment and honest nodes will never accept a block containing one. All an attacker can do is change one of his own transactions to take back money he recently spent.
• The calculation is framed as a Gambler's Ruin problem. The race between the honest chain and the attacker's chain is treated as a binomial random walk; the attacker's progress while the recipient waits for z blocks is modelled as a Poisson distribution with expected value λ = z × q/p, and that is multiplied by the probability of catching up from each point. The paper presents this as C code, and tabulates, for each attacker hash-power share q, the z required for the success probability P to fall below 0.1%.

• The widely known "six confirmations is safe" convention is not, in fact, written in the paper. The paper never uses the noun "confirmation" at all; it uses only the verb, in Section 8's remark that later blocks "further confirm" the network has accepted a transaction, and otherwise simply presents the table above. The z of 5 to 6 that follows from assuming q = 0.1 is what settled into practice as a rule of thumb. The implication of Section 11 is that the right number of blocks to wait depends on the attacker you assume — the specific attack techniques are covered in "Bitcoin's Vulnerabilities."

Section 12, "Conclusion," and the Eight References

• Section 12 opens by stating that a system for electronic transactions without relying on trust has been proposed. The starting point was the usual framework of coins made from digital signatures, which provides strong control of ownership but is incomplete without a way to prevent double-spending.
• To solve that, the paper proposed a peer-to-peer network using proof-of-work to record a public history of transactions, which quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power.
• The sentences that follow are claims about operation. The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best-effort basis. Nodes can leave and rejoin at will, accepting the proof-of-work chain as proof of what happened while they were gone.
• The final two sentences state the paper's view of governance. Nodes vote with their CPU power, expressing acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives, it concludes, can be enforced with this consensus mechanism.
• The reference list runs to eight items, a small number for a technical paper: Wei Dai's b-money (1998); Adam Back's Hashcash (2002); a series of digital timestamping papers by Haber and Stornetta and colleagues (1991, 1993, 1997) together with the work of Massias and others (1999); Ralph Merkle's paper on public key cryptosystems (1980); and William Feller's textbook on probability theory (1957).
• The shape of that bibliography says something about the paper itself. Every component technology already existed; the novelty lay not in any individual part but in combining them to produce agreement on transaction ordering without a central authority. The proposals that came before are covered in "History of Bitcoin."

The Whitepaper and Seventeen Years Later — The Main Differences from the Implementation

• By August 2026, roughly seventeen years and ten months have passed since the whitepaper appeared. The core of the design — proof-of-work, the longest-chain rule, coinbase reward plus fees, Merkle trees — is unchanged. A great deal that the paper never mentions has also been added. What follows lists the main differences, restricted to what can be verified as fact.
• The quickest route in is to note which words never appear. "Blockchain" (and "block chain"), 21 million, halving, and wallet appear nowhere in the original. "Mining" and "miner" appear only once, in the phrase "gold miners" used as an analogy for gold extraction. Even the word "Bitcoin" appears only in the title and in the URL www.bitcoin.org, never in the body text. Much of the vocabulary now taken for granted in explanations of Bitcoin was produced not by the paper but by the implementation and the community that followed.

• The 1MB block size limit existed neither in the whitepaper nor in the earliest implementation. The constant MAX_BLOCK_SIZE = 1000000 was added to the code in a commit dated 15 July 2010, but that commit's message speaks only of fixing OpenSSL linkage and similar matters, and says nothing whatsoever about the reason for the limit. That single unexplained line went on to become the central point of contention in the scaling debate years later. The history is covered in "Forks & Chain Divergence" and "Layer 2 & Scaling."
• "One-CPU-one-vote" has likewise diverged sharply from reality. The general-purpose CPU mining the paper assumed gave way to GPUs, FPGAs and purpose-built ASICs, and actual hash power is concentrated in a small number of mining pools. The gap between decentralisation by design and concentration in operation is examined head-on in "Bitcoin Paradoxes."
• The shift in use is equally hard to ignore. The paper's title is "A Peer-to-Peer Electronic Cash System," and Section 1 took as its starting point the fact that small casual transactions are not viable. In practice, base-layer fees and confirmation times suit everyday payments poorly, payment use has moved to upper layers such as the Lightning Network, and the base layer's principal use has drifted toward store of value. How to judge that shift divides commentators sharply, so both sides are set out in "Bitcoin Paradoxes" and "Criticisms of Bitcoin."
• A closing word on how to read the paper. A nine-page document does not fully specify a system that has been running for seventeen years, and it does not follow that whatever it says is always right and whatever it omits is always wrong. It is the founding design document; whether the changes made since were sound should be judged on their own technical and economic merits rather than on the paper's authority. We would encourage readers to go to the original first.