01
Introduction
Frames the central problem: making direct electronic payments without depending on a financial institution to prevent double-spending.
Can digital scarcity exist without a trusted central ledger?
Resources
The paper that introduced Bitcoin
Bitcoin: A Peer-to-Peer Electronic Cash System
Satoshi Nakamoto · 31 October 2008
A compact proposal for digital payments that do not require a trusted financial intermediary to maintain one authoritative ledger.
The problem
Digital money without a central bookkeeper
Digital signatures can prove who authorised a payment, but they do not by themselves stop the same digital value being promised to two recipients.
The paper combines a peer-to-peer network, public transaction history, proof of work and economic incentives. Participants can independently evaluate one shared ordering of transactions without appointing a bank or central server to decide which spend happened first.
Signed transaction
A spender authorises new outputs.
Peer-to-peer relay
Nodes share the transaction.
Proof-of-work block
A miner commits transactions to a block.
Node verification
Nodes enforce their consensus rules.
Confirmations
Later work makes reversal increasingly costly.
Guided reading
The paper, section by section
Use these summaries as a map, then read Satoshi’s wording directly. The guide explains the purpose of each section without replacing the original.
02
Transactions
Describes ownership as a chain of digital signatures and explains why signatures alone cannot reveal which conflicting spend came first.
How can ownership be transferred and independently checked?
03
Timestamp Server
Introduces a public sequence of hashed records. Each timestamp includes the previous one, making later records reinforce earlier history.
How can participants agree on the order of events?
04
Proof-of-Work
Uses computational work to make the history expensive to rewrite and gives the network an objective way to compare competing histories.
How does rewriting the ledger become economically costly?
05
Network
Outlines the transaction and block relay process: broadcast, collect, find proof of work, publish and build on the accepted chain.
How do independent nodes converge without a central coordinator?
06
Incentive
Explains the block subsidy and transaction fees as incentives for honest participation while introducing coins into circulation.
Why should participants spend resources securing the network?
07
Reclaiming Disk Space
Shows how Merkle trees allow spent transaction data to be pruned while retaining the block header needed to commit to the history.
How can storage requirements be reduced without discarding every proof?
08
Simplified Payment Verification
Proposes checking block headers and Merkle proofs without operating a fully validating node, with a different security model.
What can a lightweight client verify for itself?
09
Combining and Splitting Value
Explains transactions with multiple inputs and outputs, including the familiar pattern of sending value and returning change.
How can transactions represent practical payment amounts?
10
Privacy
Separates public transaction history from real-world identity and recommends using fresh key pairs to reduce linkability.
What privacy is possible on a transparent public ledger?
11
Calculations
Models the probability of an attacker catching up as honest proof of work continues to extend the accepted chain.
Why do additional confirmations reduce double-spend risk?
12
Conclusion
Brings the components together into a peer-to-peer system where nodes independently verify and converge on a proof-of-work history.
How do signatures, networking and proof of work form one system?
Read with context
What the paper does not tell you
Bitcoin has continued to develop since 2008. These distinctions prevent a foundational document from being treated as a complete description of the network today.
The paper is a design document
It introduces the system’s core idea, but it is not a complete specification of today’s Bitcoin consensus rules, peer-to-peer protocol or wallet behaviour.
“Longest” means most cumulative work
The accepted chain is selected by cumulative proof of work, not simply by counting which branch contains the greatest number of blocks.
Coins are implemented as UTXOs
The paper’s chain-of-signatures explanation is useful conceptually. Modern Bitcoin software tracks unspent transaction outputs that new inputs consume.
Privacy is not anonymity
Bitcoin does not require real-world names at protocol level, but public transaction history can still reveal links and patterns when addresses are reused or combined.
Mining hardware evolved
The paper refers to CPU power because it predates specialised Bitcoin mining hardware. Proof of work is now overwhelmingly performed by ASICs.
Full validation remains the standard
Simplified verification has useful trade-offs, but a full node independently checks every block and transaction against its consensus rules.
Key language
White paper glossary
- Double-spending
- An attempt to spend the same transaction output more than once.
- Hash
- A fixed-size cryptographic fingerprint of data. Changing the input changes the resulting hash.
- Proof of work
- Evidence that computational work was performed to produce a block hash below the current target.
- Node
- Software that participates in the network. A full node independently validates blocks and transactions.
- Merkle tree
- A hash structure that efficiently commits a block header to all transactions in that block.
- Confirmation
- A transaction receives one confirmation when included in a block, then another for each block built after it.
Continue learning
Turn the paper into practical understanding
The white paper is a starting point. Follow the concepts into focused lessons on Bitcoin, transactions, mining, nodes and consensus.
Original English PDF
Read the nine-page document hosted at bitcoin.org.
Open source31 October announcement
See the message used to introduce the paper to the cryptography mailing list.
View archiveModern developer guide
Continue with current documentation covering blocks, proof of work and consensus rules.
Read documentation