The Bitcoin whitepaper.
One argument, made visible.
Bitcoin begins with a simple problem: a digital signature can prove who authorized a payment, but it cannot prove that the same money was not promised twice.
Satoshi Nakamoto's nine-page paper builds one answer step by step. Public transactions let participants see candidate histories. Proof of work makes changing an old history costly. Independent nodes validate the rules and treat the valid history with the greatest accumulated work as their record.
What is the paper trying to achieve?
Electronic cash without a payment company in the middle
The paper does not start by proposing an investment or a general-purpose database. It asks how two willing parties can make an online payment without depending on a financial institution to approve it and reverse it later.
Physical cash solves a version of this problem in person. Once you hand over a banknote, you cannot also hand that same note to someone else. Digital information is different because it can be copied. If Alice sends Bob a file that represents ten units, nothing about ordinary copying stops her from sending the same file to Carol.
A bank solves this by maintaining the authoritative ledger. Bitcoin removes that single operator, so the network must answer two questions: who was authorized to spend, and which of two conflicting spends came first? The first answer comes from signatures. The second needs a shared ordering of events.
If a signature is valid, why is that not enough?
Ownership is not the same as history
The paper describes an electronic coin as a chain of digital signatures. Each owner signs a reference to the previous transaction and the next owner's public key. Bob can check that the signature authorizing his payment is valid.
But Alice can create two individually valid signatures that spend the same earlier output. One pays Bob. The other pays Carol, or sends the value back to Alice. Cryptography can show that Alice authorized both messages. It cannot tell Bob which message the rest of the economy should accept.
This is why the paper requires transactions to be publicly announced and ordered. A recipient needs evidence that the network accepted one spend before its rival. The whitepaper's wording about a majority of nodes can mislead modern readers. The mechanism gives weight to proof of work, not to a count of computers or IP addresses.
Interactive model: Alice signs a payment to Bob. A conflicting payment spends the same earlier output. Miners extend candidate histories, and full nodes select the valid chain with greater cumulative proof of work. More confirmations make a rewrite harder under the paper's attacker assumptions.
How does the network put events in order?
A timestamp becomes expensive to rewrite
A block commits to a group of transactions. Its header contains the previous block's hash, so every new block points back to an earlier one. Change a transaction in an old block and its commitment changes. That changes the block hash, which breaks the pointer stored by the next block.
Proof of work adds a cost. A miner repeatedly changes a nonce and hashes the block header until the result is below a target. Finding such a hash takes many attempts on average. Checking it takes one hash. Once more blocks are built on top, rewriting the old transaction requires rebuilding the proof for that block and catching the continuing honest chain.
The paper often says “longest chain,” then defines it as the chain representing the greatest proof-of-work effort. Those are close when blocks have similar difficulty. The precise rule is work, not visual length. Bitcoin's current blockchain information interface calls the active history the most-work fully validated chain and reports its total chainwork.
What proof of work does not do: it does not make an invalid transaction valid. A chain can contain enormous work and still be rejected if it creates coins outside the rules, spends missing outputs, or contains an invalid signature.
Who runs the process?
The network is a loop, not a central meeting
The paper gives a six-step process. New transactions spread to nodes. Miners gather valid transactions into candidate blocks and search for proof of work. A successful miner broadcasts the block. Each full node checks the block and its transactions. Nodes express acceptance by working on, or relaying, the valid chain they consider best.
If two valid blocks arrive at nearly the same time, different nodes can temporarily build on different tips. That is not a failure. Both branches remain candidates until later proof of work makes one branch stronger. Nodes on the weaker branch switch to the stronger valid branch.
Messages only need best-effort delivery. A node that misses a block can discover the gap when it receives a later header and request what it lacks. Today's Bitcoin Core uses more developed relay and synchronization techniques than the paper sketches. For example, the headers-first synchronization guide describes downloading and partially checking the best header chain before fetching full blocks from multiple peers.
Why would anyone spend electricity on this?
The block reward pays for ordering and security
The first transaction in a block creates the block subsidy under the protocol's issuance schedule. A miner can also claim the difference between a transaction's inputs and outputs as fees. These payments reward the miner who found acceptable proof of work.
The incentive is part of the security argument. Hash power used to extend valid blocks can earn new coins and fees. Hash power used on a private rewrite may earn nothing if the attack fails, and a successful attack could damage confidence in the value being attacked.
This is economic reasoning, not a mathematical guarantee that every miner will be honest. The attacker calculation assumes honest participants control more work and keep extending the public history. Real security also depends on software rules, market conditions, network connectivity, miner concentration, and what an attacker is trying to gain.
Must every wallet store and verify everything?
Merkle proofs answer inclusion, not full validity
Transactions in a block are summarized by a Merkle tree. A short branch of hashes can prove that one transaction contributed to the Merkle root in a particular block header. You do not need every other transaction to check that inclusion proof.
The paper calls the lighter method Simplified Payment Verification, or SPV. An SPV client keeps block headers and requests a Merkle branch for its payment. It can see that a transaction was included in a chain carrying proof of work and that later headers were added after it.
The tradeoff is independence. An inclusion proof does not make the client a full validator. The paper itself says the simplified method is more vulnerable if an attacker overpowers the network and suggests businesses receiving frequent payments may prefer their own nodes. A full node downloads the relevant data and checks consensus rules for itself.
Pruning is different from SPV. A full node may discard older block data after validation while retaining what it needs to enforce current state. It was still a validator when it accepted the history.
Does the paper promise anonymous money?
Bitcoin's ledger is public, and links accumulate
The paper's privacy section proposes keeping public keys separate from real-world identities and using a fresh key pair for each transaction. Observers can see amounts and transaction relationships without being handed a name directly.
It also states the weakness: transactions with multiple inputs reveal that those inputs were controlled together. If one public key becomes linked to a person, other activity can become linkable. The modern UTXO model keeps value in unspent transaction outputs, and transactions often combine several outputs or send change back to a new output.
The developer guide warns against key reuse for the same reason. Fresh addresses help, but public graph analysis, exchange records, network observation, and payment context can still connect activity. Bitcoin's design is pseudonymous, not private by default.
When is a payment final?
Confirmations reduce risk; they do not create a magic boundary
The paper models a race between an honest chain and a slower attacker. Let q be the attacker's share of block-finding power and let z be the honest chain's lead. If the attacker has less than half, the chance of eventually catching up falls as the lead grows.
The calculation uses a Poisson distribution to estimate how much private progress the attacker may have made while the recipient waited. The interactive model above evaluates the paper's formula. It should be read with its assumptions attached: independent block discoveries, stable relative hash share, an attacker trying to reverse the attacker's own recent payment, and honest nodes rejecting invalid transactions.
An attacker cannot use a rewrite to spend somebody else's output without their signature or create arbitrary value. The modeled attack replaces one of the attacker's own payments with a conflicting spend. More confirmations change the economics and probability of that specific history race.
Is the whitepaper the complete Bitcoin specification?
The paper explains the design; running code defines far more detail
The whitepaper gives the core argument and enough machinery to understand why the parts fit together. It is not a complete description of Bitcoin as used today. It does not specify every script rule, relay policy, wallet behavior, address format, synchronization strategy, or later protocol change.
Modern Bitcoin is an implemented consensus system with years of engineering around the original idea. Current transactions spend UTXOs rather than passing indivisible “coins” from owner to owner. Nodes distinguish consensus validity from local relay policy. Header synchronization, compact block relay, fee estimation, pruning, Segregated Witness, and newer output types belong to the implementation history after the paper.
That distinction makes the paper more useful, not less. Read it as a compact explanation of the problem and the proposed mechanism. Then use current documentation and source code for exact behavior. Continue with Bitcoin's codebase, explained through source, or compare the different privacy and trust goals in the Bitcoin and Monero whitepapers.
The shortest accurate reading: signatures say who may spend. Full nodes say whether a transaction follows the rules. Proof of work orders valid candidate histories. Confirmations make a recent history progressively harder to replace.