And proof-of-work is how you agree on an order with no one in charge.
You already know how to own a coin without a bank: a coin is a
chain of digital signatures (§2). Each owner
signs hash(previous_tx) + next_owner_pubkey. Anyone can verify the
signature chain. That part needs no trusted third party — public-key crypto does it.
So what's left? One thing. The payee cannot verify that an earlier
owner didn't also sign the very same coin over to someone else. Signatures
prove authorization; they say nothing about which transfer came first.
Reframe
Double-spending isn't a cryptography problem — it's a distributed
ordering / agreement problem. You need everyone to agree on a single
history of which transaction happened first. A mint solves this by being the one
authority that orders things. Nakamoto's whole job is to get that ordering
without the authority.
The naive fix — "announce every transaction publicly, payees accept the
majority's view of first-seen" — fails: in an open network you can't enumerate the
participants, and identities are free to mint (Sybil). Majority-by-headcount is
meaningless. So the paper makes one move:
"The majority decision is represented by the longest chain, which has the
greatest proof-of-work effort invested in it… one CPU one vote." (§4)
Voting weight = computational work, not identities. Sybil attacks
become pointless because spinning up a million fake nodes adds zero hashes.
What proof-of-work actually is
Pick a target. Hash the block header
(prev-block-hash, Merkle root of txns, timestamp, target, nonce). If
SHA-256(header) < target, the block is valid; otherwise bump the
nonce and try again. Because SHA-256 output is effectively uniform random,
the only strategy is brute force. Verification is a single hash. This asymmetry
— expensive to make, trivial to check — is the entire engine.
Why it chains history
The header includes the previous block's hash. So redoing block n
changes its hash, which invalidates block n+1's "prev-hash", which
invalidates n+2… To rewrite one old block you must redo its proof-of-work
and every block after it. History is welded together by work.
The security claim, stated honestly
An attacker who wants to reverse a payment must out-pace the honest chain: build a
secret alternative branch from before their transaction and make it longer. This is a
race between the attacker's hash rate q and the honest network's
p (with p + q = 1). If p > q, every
honest block the attacker has to catch up on makes the gap, on expectation, grow — the
catch-up probability falls roughly exponentially in the number of
confirmations z (§11 — we'll derive the Poisson formula next lesson).
The shape of it
Bitcoin's security is economic and probabilistic, not absolute.
There is no point at which a payment is mathematically final — only a point where
reversing it costs more energy than it's worth. "6 confirmations" is a
risk threshold, not a proof.
1. Signatures alone don't prevent double-spending because they…
2. Proof-of-work resists Sybil attacks because voting weight scales with…
3. Rewriting one old block forces an attacker to redo work for…
Primary source — read this
Nakamoto (2008), Bitcoin: A Peer-to-Peer
Electronic Cash System, §§1–5 (Introduction → Network).
~2 pages. Notice how little text it takes to state the whole idea.
I'm your teacher — ask me anything. e.g. "Why longest chain rather
than most-blocks?", "What stops two valid blocks at the same height?", or "How does
this map to Byzantine agreement / FLP?" Next lesson: deriving the §11 attacker-catch-up
probability and the Poisson approximation.