Plan ₿ Forum 2026 · Lugano · Oct 23–24
Bitcoin Hub

Bitcoin whitepaper

Updated Reviewed articleRandom article
In plain words

“Bitcoin: A Peer-to-Peer Electronic Cash System” is the 9-page paper by Satoshi Nakamoto, sent to a cryptography mailing list on 31 October 2008. It proposes electronic cash without a trusted third party, using proof-of-work to solve double-spending. The PDF is at bitcoin.org/bitcoin.pdf.

Source: metzdowd.com

Open the PDF: bitcoin.org/bitcoin.pdf Satoshi Nakamoto · 31 Oct 2008 · 9 pages

1. Introduction

Online commerce relies on financial institutions as trusted third parties. That makes fully non-reversible payments impossible, because the institutions must mediate disputes, and mediation adds cost and accepted fraud. The paper proposes a payment system based on cryptographic proof instead of trust, using a peer-to-peer distributed timestamp server to prove the order of transactions. It is secure as long as honest nodes control more CPU power than any cooperating group of attackers.

2. Transactions

An electronic coin is a chain of digital signatures: each owner signs a hash of the previous transaction and the next owner's public key. The payee cannot see whether an earlier owner already spent the coin, and the usual fix, a central mint, makes the whole money system depend on one company. The paper's answer is to announce transactions publicly and let participants agree on a single order in which they were received (UTXO (unspent transaction output)).

3. Timestamp Server

A timestamp server hashes a block of items and widely publishes the hash, for example in a newspaper or a Usenet post. Each timestamp includes the previous timestamp in its hash, so the timestamps form a chain and every new one reinforces the ones before it. Here the paper cites earlier time-stamping research, including Haber and Stornetta (Blockchain).

4. Proof-of-Work

To run the timestamp server peer-to-peer, the paper uses a proof-of-work system like Adam Back's Hashcash: nodes increment a nonce until the block's hash starts with a required number of zero bits. Changing a block would mean redoing its work and the work of every block after it. The longest chain is the majority decision, “one-CPU-one-vote”, and the difficulty follows a moving average that targets a set number of blocks per hour (Proof of work, Difficulty adjustment).

5. Network

Six steps run the network: transactions are broadcast, each node collects them into a block and works on its proof-of-work, and the finder broadcasts the block. Nodes accept it only if every transaction in it is valid and unspent, and show acceptance by building the next block on top of it. Nodes always treat the longest chain as correct; if two versions of a block appear at once, they work on the first they received and switch when one branch grows longer (Mining, Block).

6. Incentive

The first transaction in a block starts a new coin owned by the block's creator. That rewards nodes for supporting the network and distributes coins with no central issuer, much like gold miners adding gold to circulation. Fees (input value minus output value) can fund the incentive once a predetermined number of coins is in circulation, making it inflation-free (21 million supply cap, Halving).

The paper adds that the incentive may keep nodes honest: an attacker with more CPU power than all honest nodes would likely earn more by playing by the rules than by undermining the system.

7. Reclaiming Disk Space

Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded. To keep block hashes intact, transactions are hashed in a Merkle tree (the paper cites Ralph Merkle) and only the root goes into the block's hash. A header without transactions is about 80 bytes, which the paper puts at 4.2 MB per year for one block every 10 minutes (Full node).

8. Simplified Payment Verification

A user can verify payments without running a full node: keep the block headers of the longest chain and get the Merkle branch that links a transaction to its block. He cannot check the transaction himself, but sees that a node accepted it and that later blocks confirm it. This is reliable while honest nodes control the network and more vulnerable if an attacker overpowers it, so businesses with frequent payments will probably still run their own nodes (Confirmation).

9. Combining and Splitting Value

To avoid a separate transaction for every cent, a transaction has multiple inputs and outputs. Normally there is one input from a larger earlier transaction, or several inputs combining smaller amounts, and at most two outputs: the payment and the change back to the sender. The paper notes that a transaction depending on many others is not a problem, because no one needs a standalone copy of its full history (UTXO (unspent transaction output)).

10. Privacy

Because every transaction is announced publicly, the paper keeps privacy by keeping public keys anonymous: the public sees that someone sends an amount to someone else, like the tape of a stock exchange. As an extra firewall it suggests a new key pair for each transaction. Some linking is unavoidable, since multi-input transactions reveal that their inputs had one owner (Address, Private key).

11. Calculations

The paper models an attacker racing the honest chain as a binomial random walk, a Gambler's Ruin problem, and shows the chance of catching up drops exponentially with every block. Even a successful attacker cannot create value from nothing or take money that never belonged to him; he can only try to reverse his own recent payments. The paper includes C code and a table: with an attacker holding 10% of the CPU power, waiting for z=5 blocks pushes the attacker's chance of success below 0.1%.

12. Conclusion

The paper sums up a system for electronic transactions without trust: coins made from digital signatures, plus a peer-to-peer network that uses proof-of-work to record a public history that is quickly impractical for an attacker to change if honest nodes hold most of the CPU power. Nodes need no identity, can leave and rejoin at will, and vote with their CPU power by extending valid blocks and refusing invalid ones. Any needed rules and incentives can be enforced with this consensus mechanism.

Works the paper cites

From the Bitcoin Museum

The whitepaper (31 Oct 2008): Satoshi Nakamoto posts “Bitcoin P2P e-cash paper” to the Cryptography Mailing List: “I've been working on a new electronic cash system that's fully peer-to-peer, with no trusted third party.”

FAQ

Where can I read the Bitcoin whitepaper?
The PDF is at bitcoin.org/bitcoin.pdf. The Satoshi Nakamoto Institute also hosts the paper together with Satoshi's original emails (source: nakamotoinstitute.org).
Who wrote the Bitcoin whitepaper and when?
Satoshi Nakamoto, a pseudonym. The paper was sent to a cryptography mailing list on 31 October 2008 under the subject “Bitcoin P2P e-cash paper” (source: metzdowd.com mailing-list archive).
How many pages and sections does the whitepaper have?
The PDF has 9 pages (page count read from the file itself): an abstract, 12 numbered sections and a list of 8 references (source: bitcoin.org/bitcoin.pdf).
People who built Bitcoin Bitcoin Museum timeline Whitepaper Day

See also

References

  1. Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System (2008) bitcoin.org
  2. Satoshi Nakamoto, “Bitcoin P2P e-cash paper”, cryptography mailing list, 31 Oct 2008 (metzdowd.com) metzdowd.com
  3. Satoshi Nakamoto Institute: whitepaper and emails nakamotoinstitute.org
  4. satoshi.nakamotoinstitute.org satoshi.nakamotoinstitute.org