Crypto Gloss

Bitcoin: A Peer-to-Peer Electronic Cash System

Authors Satoshi Nakamoto
Year 2008
Project Bitcoin
License Not stated in the paper
Official source Read the nine-page PDF on Bitcoin.org

This page summarizes and analyzes the original paper for reference; it does not reproduce the paper in full or claim authorship of it. Rights in the original document remain with its author or rights holders.

In brief: Satoshi Nakamoto’s 2008 paper describes a peer-to-peer electronic cash system meant to let people send payments online without asking a bank or another trusted intermediary to prevent the same digital funds from being spent twice. Its proposed answer combines public transaction announcements, proof-of-work, and a shared history ordered by accumulated work. The design depends on an explicit security assumption: honest participants control more computing power than a cooperating attacker.

What problem was the paper trying to solve?

A digital payment can be copied. If a digital coin were only a signed file, its owner could try to send it to two recipients. A bank or payment processor can prevent that by keeping the authoritative record, but then users must trust that organization to order transactions and resolve disputes. Nakamoto’s paper asks whether a network can maintain a common transaction history without a central operator.

The paper starts from digital signatures, which let a recipient verify a chain of ownership, but notes that signatures alone do not show whether the same funds were already spent elsewhere. Its contribution is a proposed way for a distributed network to agree on transaction order, making a conflicting spend increasingly difficult to replace as more proof-of-work is added.

How the proposed system works

  1. Transactions are announced publicly. Nodes relay transactions so participants can learn about possible spends.
  2. Miners gather transactions into blocks. Each block commits to its transaction data and to the previous block’s hash.
  3. Proof-of-work makes a block costly to produce. A miner searches for a nonce that makes the block hash meet a target. Checking a proposed result is much cheaper than finding it.
  4. Nodes validate before accepting. The paper’s network steps say nodes accept a block only when its transactions are valid and not already spent.
  5. Participants extend the chain with the most accumulated work. If competing blocks appear, later work helps resolve the temporary fork. “Longest chain” is shorthand in the paper; the relevant measure is proof-of-work, not simply the count of blocks.
  6. Block rewards and fees provide an incentive. The paper describes newly issued coins and transaction fees as ways to reward the work that supports the system.

This is not a vote by account, IP address, or person. The paper ties its proposed majority decision to computational work, so creating many identities by itself does not create more influence. That mechanism still has costs and concentration risks; it does not make the network independent of mining power, software rules, connectivity, or users’ choices about which software to run.

The security assumption matters

The paper does not claim that an attacker can never reorganize transactions. Its abstract says the system is secure while honest nodes collectively control more CPU power than an attacker group. Section 11 models the chance of an attacker catching up as depending on the attacker’s share of computing power and the number of later blocks. More confirmations reduce the modeled risk under those assumptions; they do not create mathematical or legal finality.

That distinction matters for merchants and wallet users. A transaction broadcast to the network is not yet included in a block. Inclusion gives it one confirmation, and each later block adds work on top. How much protection is enough depends on the value, timing, and threat model of the payment.

What the paper says—and what later software added

Question What the 2008 paper says What it does not specify
Block timing It discusses an average target of about six blocks per hour, or roughly ten minutes per block, and an adjustment based on a moving average. It does not give today’s exact retarget interval of 2,016 blocks.
Issuance It proposes a block incentive that issues coins, with transaction fees able to support miners and a possible transition after a “predetermined number” of coins. It does not state a 21 million figure or a 210,000-block halving schedule.
Payment confidence It calculates how the modeled probability of a successful catch-up attack changes with confirmations and attacker hash power. It does not declare six confirmations a universal rule or promise that a payment is irreversible.

Those omitted numbers belong to Bitcoin’s later implementation and consensus rules. Bitcoin Core’s mainnet parameters set a 210,000-block subsidy-halving interval and target two weeks for each difficulty period, which corresponds to 2,016 blocks at the ten-minute target. The commonly cited approximately 21 million supply follows from the implemented subsidy schedule; it is not a number printed in the 2008 paper. The distinctions are visible in the Bitcoin Core mainnet chain parameters and block-subsidy validation code.

Six confirmations are also a practice recommendation, not a promise embedded as a fixed threshold in the paper. The Bitcoin Developer Guide says confirmation risk varies and describes six as a somewhat arbitrary threshold that software handling high-value or fraud-sensitive payments may choose. An average ten-minute interval does not mean every block arrives on a timer.

SPV proofs are useful but limited

The paper’s simplified payment verification (SPV) design lets a lightweight client keep block headers and request a Merkle branch showing that a transaction appears in a block. This is less data than downloading and validating every block. It gives evidence of inclusion and of the work built on that block, but it does not independently validate every transaction in the block. A full node performs that broader validation. The security and privacy trade-offs depend on how an SPV wallet connects to other nodes and what information it reveals.

Bitcoin’s privacy model is pseudonymous, not private by default

The paper recognizes that transactions must be public for the network to check for double spending. It proposes keeping public keys from being directly linked to real-world names and recommends new key pairs to reduce simple transaction linkage. It also notes that transactions with multiple inputs can reveal common ownership. In practice, a public ledger can expose patterns, and external information may connect activity to people. A Bitcoin address should not be treated as an anonymous account.

What came before it—and what came later

The paper cites earlier work, including Haber and Stornetta’s cryptographic timestamping research, Adam Back’s Hashcash proof-of-work, and Wei Dai’s b-money proposal. Bitcoin’s design combines and adapts ideas in a specific payment system; it did not invent every component or the broad idea of linking data with hashes.

Many familiar parts of today’s Bitcoin ecosystem—wallet interfaces, address formats, mining pools, later script and protocol upgrades, and payment channels such as Lightning—were developed outside the nine-page paper. The paper is a starting design document, not a complete description of every current wallet, service, or consensus implementation.

Social Media Sentiment

A small, illustrative sample of recent r/Bitcoin discussions shows two recurring ways people interpret the paper. In one thread, a reader asks what problem it solves; many replies emphasize direct payments without a bank and the double-spend problem, while some add broader claims about banks that go beyond the paper’s stated design. In another thread, commenters debate whether Bitcoin confirmations should be compared with card authorization or final settlement. They disagree about merchant risk, reversibility, and whether waiting is practical. These selected posts are not a representative survey of Bitcoin users, and neither discussion changes what the paper itself says.

Last updated: 2026-10

Related Terms

See Also

Sources and Further Reading