Bitcoin: A Peer-to-Peer Electronic Cash System
Nine pages, first shared on a cryptography mailing list, that described for the first time an electronic currency working without a bank or a trusted third party.
Satoshi Nakamoto — satoshin@gmx.com — www.bitcoin.org · October 31, 2008
Abstract
A purely peer-to-peer version of electronic cash would let online payments move directly between two parties, with no financial institution in between. The paper's proposal: timestamp every transaction by hashing it into an ongoing chain of proof-of-work, creating a record that can't be changed without redoing that work. Trust in a bank is replaced by trust in whichever chain represents the greatest amount of computation — and that chain stays honest for as long as cooperating honest nodes control more CPU power than any group of attackers.
1. Introduction
Online commerce today runs almost entirely through financial institutions acting as trusted intermediaries — a model that works well enough for most transactions but carries real structural costs. Mediation raises the price of doing business, rules out small everyday payments, and never allows a truly irreversible transaction, since disputes always need someone able to reverse them. What's needed instead is a payment system built on cryptographic proof rather than trust, letting two willing parties deal directly with each other. This paper proposes solving the double-spending problem with a peer-to-peer distributed timestamp server that computes proof of the chronological order transactions happened in — secure as long as honest nodes collectively control more CPU power than any cooperating group of attackers.
2. Transactions
An electronic coin is defined as a chain of digital signatures. Each owner transfers the coin to the next by signing a hash of the previous transaction and the next owner's public key, then appending that signature to the coin. A payee can verify the chain of ownership by checking the signatures — but on its own, this doesn't stop an earlier owner from having already signed the same coin away to someone else.
The unresolved problem is that a payee can't independently confirm that none of the prior owners double-spent the coin. A common fix is a central mint that checks every transaction for double-spending — but that puts the entire monetary system's fate in the hands of whoever runs the mint, with every transaction still passing through them, just like a bank. What's needed instead is a way for the payee to know the earlier owners never signed any earlier transaction — which requires being aware of every transaction, and a way for the network to agree, publicly, on a single history of the order transactions arrived in.
3. Timestamp Server
The proposed solution starts with a timestamp server: it takes a hash of a block of items to be timestamped and publishes that hash widely, the way a newspaper or a Usenet post would. The timestamp proves the data existed at that moment, since it's what produced the hash. Each new timestamp includes the previous timestamp's hash in its own, forming a chain — every new link reinforcing the ones that came before it.
4. Proof-of-Work
To run this timestamp server in a distributed, peer-to-peer way rather than through a newspaper or forum, the paper adapts a Hashcash-style proof-of-work scheme: search for a value that, hashed together with the rest of the block, produces a hash beginning with a required number of zero bits. Finding that value takes exponentially more average effort the more zero bits are required, yet checking it takes a single hash. For the timestamp network, that search happens by incrementing a nonce in the block until it satisfies the difficulty target — once the CPU effort behind that is spent, changing the block means redoing that work, and redoing every block chained after it too.
Proof-of-work also settles the question of how the majority makes decisions. A one-IP-address-one-vote scheme could be gamed by anyone able to allocate many addresses; proof-of-work is closer to one-CPU-one-vote, with the majority decision represented by whichever chain carries the most accumulated work. As long as honest nodes control most of the CPU power, the honest chain grows fastest and outpaces any competitor — an attacker would need to redo the proof-of-work of the block they want to change and everything after it, then catch up to and overtake the honest nodes' ongoing work, an ever-steeper climb as more blocks are added. Difficulty is retargeted by a moving average so blocks keep arriving at roughly a constant rate even as hardware speed changes over time.
5. Network
Running the network comes down to a simple loop: new transactions are broadcast to all nodes, each node collects them into a block, works on finding a difficult proof-of-work for that block, and broadcasts it once found. Other nodes only accept a block if every transaction in it checks out and hasn't already been spent, and they signal that acceptance by starting work on the next block, using the accepted one's hash as the new "previous hash." Nodes always treat the longest chain as correct and keep extending it; if two blocks arrive around the same time, nodes work on whichever they saw first but keep the other branch on hand in case it ends up winning. Broadcasts don't need to reach every node — reaching enough of them is sufficient for a transaction to land in a block soon, and a node that missed a block simply requests it once it notices a gap.
6. Incentive
By convention, a block's first transaction awards its creator a fixed number of new coins — the mechanism by which currency enters circulation at all, given there's no central issuer, and it doubles as an incentive for nodes to keep supporting the network. It's comparable to gold miners spending resources to bring new gold into circulation, except here the resource spent is CPU time and electricity. Once a predetermined supply of coins has entered circulation, that incentive can shift entirely to transaction fees, with no inflation at all. The incentive structure is also meant to keep nodes honest: an attacker with more computing power than everyone else combined would come out ahead by mining new coins honestly rather than defrauding others, since undermining the system would also undermine the value of their own holdings.
7. Reclaiming Disk Space
Once a coin's most recent transaction is buried under enough blocks, the spent transactions before it can be discarded to save disk space. This works because transactions are hashed into a Merkle tree, with only the root included in the block's own hash — old blocks can then be compacted by pruning branches of that tree, since the interior hashes never need to be kept around.
A block header with no transactions in it runs about 80 bytes — at one block every 10 minutes, that works out to roughly 4.2MB a year. With typical 2008-era desktops shipping 2GB of RAM and hardware capacity growing steadily under Moore's law, keeping every header in memory shouldn't pose a storage problem.
8. Simplified Payment Verification
Verifying a payment doesn't require running a full network node. A user only needs the chain of block headers for the longest proof-of-work chain — obtained by querying network nodes until confident of holding the longest one — plus the Merkle branch linking a transaction to the block it's timestamped in. That branch can't verify the transaction on its own, but it does show a network node accepted it, and that later blocks confirm the rest of the network went along with that acceptance.
This lightweight verification stays reliable as long as honest nodes control the network, but it's more exposed once an attacker dominates it — a network-wide alert system, prompting a full download to double-check anything flagged as invalid, is one way to guard against that. Businesses receiving frequent payments will likely still want to run their own full node for faster, independent confirmation.
9. Combining and Splitting Value
Handling every coin as its own indivisible unit would make a separate transaction for every small amount impractical. Transactions instead carry multiple inputs and outputs so value can be split and combined freely — typically one input from a larger prior transaction, or several smaller ones combined, and at most two outputs: one for the payment, one returning any change to the sender.
10. Privacy
The traditional banking model achieves a degree of privacy by limiting who can see account information to the parties involved and their trusted third party. Because every transaction has to be announced publicly here, privacy instead comes from breaking the link elsewhere: keeping public keys anonymous. The public can see that some amount moved from one key to another, without anything tying that transaction to a specific identity — similar to how a stock exchange publishes the time and size of trades without naming the parties involved.
As extra protection, a new key pair should be used for every transaction to keep them from being linked back to a common owner. Some linkage is still unavoidable with multi-input transactions, since they necessarily reveal that their inputs belonged to the same owner — a risk if that owner's identity is ever revealed, since it could expose other transactions belonging to them too.
11. Calculations
The paper models an attacker trying to generate an alternative chain faster than the honest one. Even if they succeed, that doesn't open the system to arbitrary changes — nodes will never accept an invalid transaction, so an attacker can only try to reclaim money they themselves recently spent. The race between the honest chain and an attacker's chain is modeled as a binomial random walk: a step forward when the honest chain extends, a step back when the attacker's does. This is mathematically the same as a gambler's ruin problem, which lets the probability of an attacker ever catching up be calculated directly:
where p is the probability an honest node finds the next block, q is the probability the attacker finds it, and qz is the probability the attacker ever closes a gap of z blocks. Given the assumption that p is greater than q, that probability drops off exponentially as the number of blocks the attacker needs to make up grows — without an early stroke of luck, their odds shrink fast the further behind they fall.
The remaining question is how long a payee should wait before being confident a sender can no longer reverse a transaction. The concern is a sender who briefly convinces the payee they've been paid, planning to switch to an alternate chain and pay themselves back before the payee notices — with the payee finding out, but hopefully too late for the sender's liking.
12. Conclusion
The paper's proposal is a system for electronic transactions that doesn't depend on trust. It starts from the familiar framework of coins made of digital signatures, which gives strong control over ownership but is incomplete without a way to prevent double-spending — solved here with a peer-to-peer network running proof-of-work to keep a public transaction history that becomes rapidly harder to rewrite, provided honest nodes control a majority of CPU power. The network is robust precisely because it needs so little structure: nodes work with minimal coordination, don't need to be identified, can come and go freely, and simply accept the proof-of-work chain as evidence of what happened while they were away — voting with their CPU power for valid blocks by building on them, and against invalid ones by refusing to.