Bitcoin Whitepaper

Section 2 describes transferring a coin through digital signatures. A recipient can verify authorization, but the sender can also sign a competing payment spending the same funds. A shared public history is the proposed solution. A valid signature and admission of a transaction to that history are separate conditions. [Original Bitcoin whitepaper]

Sections 3–5 link blocks using hashes and Proof of Work. The longest chain here means the history with the most accumulated work, not a vote by IP-address count. Work does not replace transaction validation: nodes reject invalid blocks. The chain establishes order, not a precise independent clock for every payment. [Original Bitcoin whitepaper] [Bitcoin Developer Guide — Block Chain]

Section 6 presents new coins and fees as incentives for block production. It describes a fee as the difference between input and output values and considers a transition to funding entirely through fees. It does not state the numerical limit of 21 million or the 210,000-block halving interval; those parameters require other sources. [Original Bitcoin whitepaper] [Bitcoin Developer Guide — Block Chain]

Section 8 proposes SPV: a client obtains block headers and a Merkle proof of transaction inclusion. Inclusion in a block is not an independent check of every rule and the entire spending history. The paper explicitly acknowledges that this method is more vulnerable to an attacker than a full node. [Original Bitcoin whitepaper]

Section 10 separates public transactions from key holders’ identities and recommends new key pairs. It also warns that linking transactions can expose further payments once one identity is revealed. A fresh address therefore does not by itself guarantee anonymity; public history remains available for analysis. [Original Bitcoin whitepaper]

Section 11 models an attacker catching up with the honest chain. The outcome depends on the attacker’s share of computing power and the chain’s lead; with a weaker attacker, risk falls as the lead grows. The model uses assumptions and a Poisson approximation. It does not set one safe confirmation count for every payment and attack. [Original Bitcoin whitepaper]

Later changes, such as SegWit described in BIP 141, are absent from the whitepaper. Publishing a BIP does not itself mean adoption. Interpreting current behavior requires distinguishing a proposal, implementation, deployed consensus rules and local relay policy; the last of these is not a block-validity rule. [BIP 141 — Segregated Witness] [Bitcoin Developer Guide — Block Chain]

The original October announcement documents publication of the design, while the PDF contains its reasoning. The sections on signatures, networking and calculations should be read together: each addresses a different part of the problem. Quoting one sentence without its assumptions cannot establish the security of a particular wallet or current implementation. [Original announcement — 31 October 2008] [Original Bitcoin whitepaper]