The Bitcoin White Paper in Plain English

Abstract: the whole idea in one breath

The paper proposes a way for two people to pay each other online directly, without a bank or payment company in the middle. Digital signatures prove who owns the money, but on their own they can’t stop someone from spending the same money twice. That is the hard part the paper solves.

The fix is a peer-to-peer network that stamps every transaction into a growing chain of proof-of-work. The longest chain is both the record of what happened and proof that it came from the largest pool of computing power. As long as honest computers control most of that power, they will build the longest chain and out-pace attackers. The network needs very little structure: messages are sent on a best-effort basis, and computers can leave and rejoin whenever they like, accepting the longest chain as the record of what happened while they were gone.

1. Introduction: why not just use banks?

Online payments almost always go through trusted third parties, like banks and card processors. That works well enough, but trust has costs. Because a middleman can be asked to step into disputes, payments can be reversed. That raises costs, sets a practical floor on how small a payment can be, and means merchants must ask customers for more personal information than they would otherwise need. Some fraud is simply accepted as unavoidable.

Cash avoids this in person, but there was no way to make a payment over the internet without a trusted party. The paper proposes a system based on cryptographic proof instead of trust. Payments that are computationally impractical to reverse protect sellers from fraud, and routine escrow could protect buyers. The system is secure as long as honest computers, together, control more computing power than any group of attackers working together.

2. Transactions: a coin is a chain of signatures

In the paper, a coin is defined as a chain of digital signatures. To pass a coin on, the owner signs a fingerprint (a hash) of the previous transaction together with the next owner’s public key, and adds that to the end of the coin. Anyone can check the signatures to follow the chain of ownership.

The catch: the person receiving the coin can’t tell whether an earlier owner already spent it somewhere else. The usual answer is a central “mint” that checks every transaction, but then everything depends on that one company. The paper’s goal is to let the receiver know that earlier owners did not sign any earlier transactions. For this, only the first spend counts. The only way to be sure a transaction didn’t happen is to know about every transaction. So transactions must be announced publicly, and the participants need a way to agree on one history of the order they were received.

3. Timestamp Server: proving what came first

The starting point is a timestamp server. It takes a hash of a block of items, timestamps it, and publishes the hash widely. The timestamp proves the data existed at that time. Each timestamp includes the previous timestamp in its hash, forming a chain, and each new one reinforces the ones before it.

4. Proof-of-Work: one CPU, one vote

To run that timestamp server without a central operator, the paper uses proof-of-work, similar to Adam Back’s Hashcash. Computers search for a value (a “nonce”) that makes the block’s hash, using SHA-256, begin with a required number of zero bits. Finding it takes work that grows exponentially with the number of zeros, but anyone can check the answer with a single hash.

Once that work is spent on a block, the block can’t be changed without redoing the work. Later blocks are chained after it, so changing an old block means redoing it and every block after it.

Proof-of-work also settles how decisions are made. If voting were one-IP-address-one-vote, anyone who could grab lots of IP addresses could cheat. Proof-of-work is essentially one-CPU-one-vote. The majority decision is the longest chain, which has the most work put into it. If honest computers control most of the computing power, the honest chain grows fastest. An attacker who wants to change a past block must redo it and all later blocks, then catch up with and pass the honest chain. The chance of a slower attacker catching up shrinks with every new block (see section 11).

Hardware gets faster and interest in running nodes changes, so the difficulty is set by a moving average aimed at an average number of blocks per hour. If blocks come too fast, the difficulty goes up.

5. Network: the six steps

The paper describes how the network runs:

1. New transactions are broadcast to all nodes.
2. Each node collects new transactions into a block.
3. Each node works on finding a difficult proof-of-work for its block.
4. When a node finds a proof-of-work, it broadcasts the block to all nodes.
5. Nodes accept the block only if all the transactions in it are valid and not already spent.
6. Nodes show they accept the block by working on the next block in the chain, using the accepted block’s hash as the previous hash.

Nodes always treat the longest chain as the correct one and keep extending it. If two nodes broadcast different next blocks at the same time, some nodes may see one first and some the other. Each works on the first one it received but saves the other branch in case it becomes longer. The tie breaks when the next proof-of-work is found and one branch pulls ahead; nodes on the other branch then switch to the longer one.

Broadcasts don’t have to reach every node. As long as they reach many nodes, they’ll get into a block before long. Block broadcasts also tolerate dropped messages: a node that missed a block will ask for it when it receives the next one and notices the gap.

6. Incentive: why anyone does the work

By convention, the first transaction in each block is a special one that creates new coins owned by whoever made the block. This gives nodes a reason to support the network, and it is how coins are first put into circulation, since there is no central authority to issue them. The paper compares steadily adding new coins to gold miners spending resources to add gold to circulation; here, the resources are CPU time and electricity.

The incentive can also be funded with transaction fees: if a transaction’s outputs are worth less than its inputs, the difference is a fee added to that block’s reward. Once a set number of coins have entered circulation, the incentive can move entirely to transaction fees and be completely inflation-free.

The incentive may also help keep nodes honest. A greedy attacker with more computing power than all honest nodes would have a choice: use it to defraud people by stealing back payments, or use it to make new coins. The paper argues the attacker should find it more profitable to play by the rules, which earn more new coins than everyone else combined, than to undermine the system and the value of their own wealth.

7. Reclaiming Disk Space: keeping the history small

Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be thrown away to save space. To do that without breaking the block’s hash, transactions are hashed in a Merkle tree, and only the tree’s root goes into the block’s hash. Old blocks can then be compacted by cutting off branches of the tree. The interior hashes don’t need to be stored.

A block header with no transactions is about 80 bytes. At one block every 10 minutes, that’s 80 bytes × 6 × 24 × 365 = 4.2 MB a year. Computers in 2008 typically sold with 2 GB of RAM, and Moore’s Law predicted growth of 1.2 GB a year, so the paper concludes storage shouldn’t be a problem even if the headers are kept in memory.

8. Simplified Payment Verification: checking without a full node

You can verify payments without running a full network node. A user only needs a copy of the block headers of the longest proof-of-work chain (which they can get by asking network nodes until they’re convinced they have the longest chain) and the Merkle branch linking the transaction to the block it’s in. The user can’t check the transaction for themselves, but by linking it to a place in the chain, they can see that a network node accepted it, and blocks added after it confirm the network accepted it too.

This is reliable as long as honest nodes control the network, but more vulnerable if an attacker overpowers it. Full nodes can verify transactions themselves; the simplified method can be fooled by an attacker’s made-up transactions for as long as the attacker keeps overpowering the network. One protection is to accept alerts from network nodes when they detect an invalid block, prompting the user’s software to download the full block and the alerted transactions to confirm the problem. Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.

9. Combining and Splitting Value: inputs and outputs

Handling every cent as a separate coin would be clumsy. So transactions can have multiple inputs and outputs. Normally there is either one input from a larger earlier transaction or several inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender.

A transaction can depend on several earlier transactions, which in turn depend on many more. That “fan-out” isn’t a problem here: there is never a need to pull out a complete standalone copy of a transaction’s history.

10. Privacy: public transactions, anonymous keys

The traditional banking model gets privacy by keeping information to the parties involved and the trusted third party. Because every transaction here must be announced publicly, that isn’t possible. Instead, privacy comes from keeping public keys anonymous. The public can see that someone is sending an amount to someone else, but not who they are, much like a stock exchange that publishes the time and size of each trade without saying who traded.

As an extra firewall, a new key pair should be used for each transaction so they can’t be linked to a common owner. Some linking is still unavoidable with multi-input transactions, which reveal that their inputs were owned by the same owner. The risk is that if the owner of one key is revealed, linking could reveal other transactions that belonged to the same owner.

11. Calculations: how safe is “confirmed”?

The paper looks at an attacker trying to build a secret alternate chain faster than the honest one. Even if it worked, it wouldn’t let them make value out of thin air or take money that was never theirs: nodes won’t accept an invalid transaction as payment, and honest nodes will never accept a block containing one. The attacker can only try to change one of their own transactions to take back money they recently spent.

The race between the honest chain and an attacker’s chain is modeled as a Binomial Random Walk, like the classic Gambler’s Ruin problem. If the honest network has more computing power than the attacker, the chance that the attacker ever catches up drops exponentially with each block they fall behind.

So how long should a receiver wait? The receiver creates a new key pair and gives it to the sender just before signing, so the sender can’t prepare a secret chain in advance. Then the receiver waits until the transaction is added to a block and a number of blocks (z) are linked after it. The paper works out the attacker’s chance of success with a short C program. For example:

• An attacker with 10% of the computing power and 5 blocks to catch up has about a 0.09% chance.
• To push the chance below 0.1%, the paper calculates waiting 5 blocks against a 10% attacker, 11 blocks against 20%, 24 blocks against 30%, and 340 blocks against 45%.

12. Conclusion: electronic cash without trust

The paper proposes a system for electronic transactions without relying on trust. It starts with coins made from digital signatures, which give strong control of ownership but can’t stop double-spending on their own. To solve that, it uses a peer-to-peer network that records a public history of transactions with proof-of-work, which quickly becomes computationally impractical for an attacker to change if honest nodes control most of the computing power.

The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They don’t need to be identified, since messages aren’t routed to any particular place and only need to be delivered on a best-effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their computing power, showing they accept valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism.

FAQ

Keep reading

• Start Here: Bitcoin basics
• Run a Bitcoin node at home
• Hardware wallets explained
• Is My Wallet Safe? (free check)