CS 161, Lesson 34, in 51 slides. It presents Bitcoin as a digital currency that has the properties of physical money but NO trusted bank, in section 16.1, then public keys as identities in sections 16.2 and 16.3, and the signed transaction ledger with balances computed by replay, in sections 16.4 and 16.5. It covers the append-only hash chain and tamper detection in sections 16.6 and 16.7, and consensus by proof of work under the longest-chain rule, in sections 16.8 and 16.9. It is anchored to textbook sections 16.1 to 16.9.
Subject: Computer Security · 83 slides · applied lesson
Open the interactive version of this deck · Homework for this lesson
Title
CS 161 · Lesson 34 of 45
public-key identities · a signed transaction ledger · the append-only hash chain · and consensus by proof of work
Objectives
Warm-up
Discussion prompt
Before we open L34 · Bitcoin: Identities, Transactions, Hash Chains & Proof of Work: without looking back, what was the main idea of L33 · Password Hashing: Salt, Slow Hashes & Key Derivation, and what could you do by the end of it that you could not do before?
Hint: One sentence for the idea, one for the skill. If the second one is blank, that is the part to revisit.
Answer:
CS 161, Lesson 33, in 51 slides. It explains why storing H(w) is not enough, in section 14.7, then covers the offline guessing attack and the amortized precomputation attack, and the two defenses given in section 14.8: a per-user salt, and slow iterated hashing. It closes with what this implies for key derivation, in section 14.9. It is anchored to textbook sections 14.7 to 14.9.
Concept
Every primitive in the crypto unit — collision-resistant hashes (L22) and digital signatures (L30) — now does real work. Bitcoin is the capstone: a currency built ENTIRELY from cryptography, with no bank to trust.
Matching
Match the pairs
From Three questions this lesson answers — match each one to what it actually does. The descriptions have been shuffled.
Why: What problem?, How are identities & money built?, How does everyone agree? are easy to tell apart while they are sitting next to their descriptions and much harder afterwards, which is what this checks.
Section
Part 1 · §16.1 decentralization as the goal
Concept
A usable currency needs a handful of properties we take for granted with cash. List them out — each one is something the system must enforce.
Counterexample
Discussion prompt
A usable currency needs a handful of properties we take for granted with cash. List them out — each one is something the system must enforce.
That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.
Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.
Concept
With normal digital money, a trusted bank is the answer to every property: it holds the accounts, authenticates you, moves the money, and refuses overdrafts. Everyone trusts that one central party.
Bitcoin's goal is radical: provide the same properties with no centralized party at all — using cryptography instead of trust. The bank's four jobs each become a cryptographic mechanism.
Analogy
Discussion prompt
Explain §16.1 Traditionally, a bank enforces all of it by analogy to something with no Computer Security in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.
Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.
Answer:
Bitcoin's goal is radical: provide the same properties with no centralized party at all — using cryptography instead of trust. The bank's four jobs each become a cryptographic mechanism.
Intuition
A central party is a single point of trust AND failure: it can freeze your account, censor a payment, inflate the currency, or simply be hacked. The whole design question of Bitcoin is: can cryptography do the bank's job without anyone being in charge?
This connects all the way back to §1's trust problem: every system has a Trusted Computing Base you must trust. Bitcoin's ambition is a money system with essentially no TCB — no server you have to believe.
Ask yourself: if there's no bank, who stops Alice from spending money she doesn't have? (Nobody single — instead EVERY participant checks the public ledger. That's what the rest of the lesson builds.)
Explain it
Discussion prompt
Explain §16.1 Why remove the bank at all? to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.
Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.
Answer:
Ask yourself: if there's no bank, who stops Alice from spending money she doesn't have? (Nobody single — instead EVERY participant checks the public ledger. That's what the rest of the lesson builds.)
Concept
Map each property the bank used to provide onto the cryptographic mechanism Bitcoin uses instead. The rest of the lesson is this table, expanded.
| Property | Bank's way | Bitcoin's way |
|---|---|---|
| Identity / no impersonation | ID check | Public key + signatures (§16.2–16.3) |
| Accounts / balances | Bank database | Deduced from the ledger (§16.4–16.5) |
| Transactions | Bank moves money | Signed messages on the ledger (§16.4) |
| No double-spend / tamper | Bank is authoritative | Hash chain + proof of work (§16.6–16.9) |
Comparison
Comparison matrix
From §16.1 The four properties → four mechanisms: refill the Bank's way column from what you know. The rest of the table is as it appeared.
| Property | Bank's way | Bitcoin's way |
|---|---|---|
| Identity / no impersonation | ID check | Public key + signatures (§16.2–16.3) |
| Accounts / balances | Bank database | Deduced from the ledger (§16.4–16.5) |
| Transactions | Bank moves money | Signed messages on the ledger (§16.4) |
| No double-spend / tamper | Bank is authoritative | Hash chain + proof of work (§16.6–16.9) |
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'There must be SOME Bitcoin company or server that runs the accounts and approves payments.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: The ENTIRE point of Bitcoin is decentralization — there is no bank, no company, no authoritative server.
A student: who enforces the rules instead?
Why: The ENTIRE point of Bitcoin is decentralization — there is no bank, no company, no authoritative server. If one party were in charge, it would be a single point of trust and failure, exactly what Bitcoin removes.
Trap
A student: 'There must be SOME Bitcoin company or server that runs the accounts and approves payments.'
Assume a central authority enforces the rules
Why: Wrong. The ENTIRE point of Bitcoin is decentralization — there is no bank, no company, no authoritative server. If one party were in charge, it would be a single point of trust and failure, exactly what Bitcoin removes.
A student: who enforces the rules instead?
Every participant enforces the rules using cryptography
Why: §16.1: there is no central party. Public keys, signatures, and a shared append-only ledger let every participant independently verify identities, balances, and transactions. Trust is replaced by math everyone can check.
Intuition
Three of money's properties are about a single moment. The deepest one is about TIME: once Alice spends a unit, she must not be able to spend that same unit again somewhere else.
A bank solves this trivially — it's the one authority that decides the order of events. With no bank, getting everyone to agree on the ORDER of transactions is the central challenge, and it's exactly what proof of work (Part 5) will solve.
Ask yourself: which of the four mechanisms is really about double-spending? (The append-only hash chain plus proof-of-work consensus — they pin down a single agreed order of history.)
Section
Part 2 · §16.2–16.3 primitives & identity
Concept
Bitcoin invents no new cryptography. It assembles two tools you've already studied — both of them public, both of them one-way in the sense that matters.
Collision-resistant hash (L22) — A public function H where it is infeasible to find two inputs with the same output. Used to chain the ledger together and make it tamper-evident.
Digital signature (L30) — A keypair where the private key SK signs a message and the public key PK verifies it. Signatures are unforgeable: nobody without SK can produce a signature that verifies under PK.
Definition probe
Sort into buckets
Every line below is part of the definition of Collision-resistant hash (L22) or of Digital signature (L30) — one or the other, never both. Put each where it belongs.
Concept
There are no usernames or accounts to register. Bob's identity is literally his public key PK_B. Whoever generates a keypair has created a new identity, with no permission from anyone.
\[ \text{identity of Bob} \ :=\ PK_B \]
Identity as a public key — In Bitcoin a participant is identified by a public key PK. They prove they are that participant by signing a message with the matching SK — there is no name, account, or central registrar.
Intuition
To prove 'I am PK_B', Bob signs a message with SK_B. Anyone can verify the signature with the public PK_B. Because signatures are unforgeable, no one without SK_B can produce that signature — so no one can impersonate Bob.
This gives the 'no impersonation' property with no ID check and no bank: holding the private key IS being that identity. Lose the key and you lose the identity; steal the key and you become them.
Ask yourself: what stops Mallory from claiming to be PK_B? (She'd have to sign with SK_B, which she doesn't have. Unforgeable signatures block the impersonation directly.)
Ranking
Put in order
Put the moves of §16.3 Proving you are PK_B into the order they have to happen.
Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. Anyone can refer to 'PK_B' — it's public.
Worked example
Bob publishes PK_B as his identity; he keeps SK_B private
Why: Anyone can refer to 'PK_B' — it's public. Only Bob holds the matching SK_B.
To prove he's PK_B, Bob signs a challenge message m: sigma = Sign(SK_B, m)
Why: Producing a valid signature requires the private key, which only Bob has.
\[ \sigma = \mathrm{Sign}(SK_B,\ m) \]
A verifier checks Verify(PK_B, m, sigma) = true
Why: Anyone with the public PK_B can check the signature; nobody else could have produced it.
Verify: only the holder of SK_B could have signed, so the prover is PK_B
Why: §16.3: unforgeability means a passing signature proves possession of SK_B. Identity is established with no central party — just the keypair.
Notation
Annotate
From §16.3 Proving you are PK_B — read this one piece at a time. What is each part doing?
On: \( \sigma = \mathrm{Sign}(SK_B,\ m) \)
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'My Bitcoin identity is tied to my name, email, or some account I sign up for.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: There are no names, emails, or accounts in Bitcoin.
A student: what actually names a participant?
Why: There are no names, emails, or accounts in Bitcoin. Your identity is a PUBLIC KEY you generated yourself — pseudonymous, not tied to your real-world identity by the protocol.
Trap
A student: 'My Bitcoin identity is tied to my name, email, or some account I sign up for.'
Treat the identity as a real-world name or account
Why: Wrong. There are no names, emails, or accounts in Bitcoin. Your identity is a PUBLIC KEY you generated yourself — pseudonymous, not tied to your real-world identity by the protocol.
A student: what actually names a participant?
The identity is a public key PK, proven by signing with SK
Why: §16.3: identity = PK. You prove you hold it by signing. It is pseudonymous — a key, not a person — though we'll see that does NOT mean anonymous.
Concept
Creating an identity is just running KeyGen to get a fresh (PK, SK). No registration, no approval, no central party — generating the keypair IS creating the account.
\[ \mathrm{KeyGen}() \rightarrow (PK,\ SK)\quad\text{— a brand-new identity} \]
This is why a single person can hold many identities (many keypairs), and why losing SK is catastrophic: there is no 'forgot password' — the identity is unrecoverable without the private key.
Section
Part 3 · §16.4–16.5 the signed ledger
Concept
To pay, Alice broadcasts a signed message saying she sends n units to PK_B. She signs it with her own SK_A so everyone can confirm it really came from PK_A.
\[ T = \big(\text{``}PK_A \text{ sends } n \text{ units to } PK_B\text{''},\ \ \mathrm{Sign}(SK_A, \cdot)\big) \]
Anyone can verify the signature with the public PK_A. Because only Alice holds SK_A, nobody else can spend Alice's money — the signature authorizes the transfer.
Concept
There is no account database holding 'Alice: 6 units'. Instead there is an append-only, immutable ledger that records every transaction and its signature.
The ledger — An append-only, immutable, public list of every transaction ever made, each with its signature. It is the single source of truth — and it stores transactions, NOT balances.
To find anyone's balance, you replay the whole ledger: start from the initial amounts and apply every transaction in order. Balances are a computed view of history, not stored numbers.
Intuition
If balances were just stored numbers, someone would have to be trusted to keep them correct — that's the bank again. By recording only signed transactions, EVERY participant can independently recompute every balance and agree.
The ledger is public and append-only, so the computation is the same for everyone. No authority is needed to tell you a balance; you derive it yourself from history you can verify.
Ask yourself: how does the system know Alice has enough to spend? (Replay the ledger to compute Alice's balance, then check the new transaction doesn't exceed it.)
Sorting
Sort into buckets
These are the pieces of L34 · Bitcoin: Identities, Transactions, Hash Chains & Proof of Work, out of order. Put each one back under the part of the lesson it belongs to.
Step zero
Discussion prompt
§16.5 Replaying the ledger to catch an invalid spend — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Start from initial amounts: Bob has $10, everyone else $0
Answer:
Worked example
Start from initial amounts: Bob has $10, everyone else $0
Why: Replay always begins from the known starting state, then applies transactions in order.
Apply the ledger's first three transactions: Bob→Alice $5, Bob→Mallory $2, Mallory→Alice $1
Why: Each transfer decreases the sender and increases the receiver. We track the running balances after each one.
| transaction | Bob | Alice | Mallory |
|---|---|---|---|
| start | $10 | $0 | $0 |
| Bob → Alice $5 | $5 | $5 | $0 |
| Bob → Mallory $2 | $3 | $5 | $2 |
| Mallory → Alice $1 | $3 | $6 | $1 |
Now check the next transaction, Alice → Eve $9, against Alice's balance
Why: Alice's replayed balance is $6. She is trying to send $9 — more than she has.
\[ \text{Alice balance} = \$6 \ <\ \$9 \ \Rightarrow\ \text{INVALID} \]
Verify: Alice→Eve $9 is REJECTED — she has only $6
Why: §16.5: replaying the ledger gives Alice $6, so the $9 spend exceeds her balance and every participant rejects it. The 'no overspending' property is enforced with no bank.
Discrimination
Sort into buckets
Sort these by Bob, from memory, without looking back at §16.5 Replaying the ledger to catch an invalid…. Telling them apart on the spot is the skill; the table is only where the answer happens to be written down.
Concept
Rather than scanning all of history per balance, each transaction explicitly references where the money came from — the earlier transaction that paid the sender. Money flows in a chain.
| TX | transfer | source of funds |
|---|---|---|
| TX1 | Bob → Alice 5 | Bob's initial coins |
| TX2 | Alice → Eve 5 | TX1 (the 5 Alice received) |
TX2 spends exactly the output of TX1. Following these references, anyone can trace each coin back to where it originated.
Trade off
Comparison matrix
From §16.4 The chaining model: each TX points to its source: every row here is a choice with a cost. Fill the source of funds column, then say which row you would actually pick and what you give up for it.
| TX | transfer | source of funds |
|---|---|---|
| TX1 | Bob → Alice 5 | Bob's initial coins |
| TX2 | Alice → Eve 5 | TX1 (the 5 Alice received) |
Concept
A transaction is valid only if it passes all three checks. Every participant runs them before accepting a transaction.
Check 1 stops impersonation; check 2 stops inventing money; check 3 stops double-spending. Together they replace the bank's authority.
Trap
A student: 'Somewhere there's a table that says Alice = $6, Bob = $3, and a payment just edits those numbers.'
Assume balances are stored and edited directly
Why: Wrong. Nothing stores balances. The ledger stores only signed TRANSACTIONS. A stored-balance table would need a trusted keeper — the very bank Bitcoin removes.
A student: where does a balance come from?
Derive balances by replaying the transaction ledger
Why: §16.5: start from initial amounts, apply every signed transaction in order, and the balance falls out. Balances are a computed view of history, not stored state.
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'Since my identity is just a public key, Bitcoin is completely anonymous — nobody can ever trace my payments.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: The ledger is PUBLIC and permanent.
A student: what does identity-by-public-key actually give?
Why: The ledger is PUBLIC and permanent. Every transaction under your key is visible to all. If your key is ever linked to your real identity (an exchange, a purchase), your whole transaction history is traceable.
Trap
A student: 'Since my identity is just a public key, Bitcoin is completely anonymous — nobody can ever trace my payments.'
Equate 'pseudonymous' with 'anonymous'
Why: Wrong. The ledger is PUBLIC and permanent. Every transaction under your key is visible to all. If your key is ever linked to your real identity (an exchange, a purchase), your whole transaction history is traceable.
A student: what does identity-by-public-key actually give?
Recognize Bitcoin is PSEUDONYMOUS, not anonymous
Why: §16.3–16.5: a public key is a pseudonym, not a hidden identity. Because the ledger is public and replayable, payments are linkable and traceable once the pseudonym is tied to a person.
Ranking
Put in order
Put the moves of §16.4 Tracing money through the chaining model into the order they have to happen.
Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. The transaction names where the money came from — Bob's starting balance — so verifiers know the 5 units exist.
Worked example
TX1: Bob → Alice 5, with funds sourced from Bob's initial coins
Why: The transaction names where the money came from — Bob's starting balance — so verifiers know the 5 units exist.
TX2: Alice → Eve 5, sourced from TX1 (the 5 Alice received)
Why: Alice spends exactly the output of TX1. The reference lets anyone confirm she is spending real, previously-received money.
| TX | transfer | source | valid? |
|---|---|---|---|
| TX1 | Bob → Alice 5 | Bob's initial coins | yes |
| TX2 | Alice → Eve 5 | TX1's output | yes — TX1 unspent |
| TX2b | Alice → Carol 5 | TX1's output again | NO — already spent in TX2 |
Verify: TX2 passes all three checks; a second spend of TX1's output (TX2b) fails check 3
Why: §16.4: signature verifies (check 1), Alice was the receiver in TX1 (check 2), and TX1's output is unspent for TX2 but ALREADY spent for TX2b (check 3). The chaining references make double-spends visible.
Comparison
Comparison matrix
From §16.4 Tracing money through the chaining model: refill the transfer column from what you know. The rest of the table is as it appeared.
| TX | transfer | source | valid? |
|---|---|---|---|
| TX1 | Bob → Alice 5 | Bob's initial coins | yes |
| TX2 | Alice → Eve 5 | TX1's output | yes — TX1 unspent |
| TX2b | Alice → Carol 5 | TX1's output again | NO — already spent in TX2 |
Intuition
Naming the source transaction does two jobs at once: it proves the money EXISTS (it traces back to a real earlier payment), and it makes double-spending detectable (a source can be spent only once).
Without these references you'd have to scan all of history to answer 'does this money exist and is it unspent?'. With them, you follow a chain of pointers — the structure that, generalized, becomes the UTXO model (⊕, beyond this section).
Ask yourself: which validity check does the source reference most directly support? (Check 2 — that the sender was a previous receiver — and check 3, that the referenced output isn't already spent.)
Section
Part 4 · §16.6–16.7 tamper-evidence
Concept
We need the ledger to be append-only and immutable with no authority enforcing it. Build it as a hash chain: each block contains the data PLUS the hash of the previous block.
Hash chain — A sequence of blocks where each block stores a hash of the block before it, so every block's hash depends on all earlier blocks. Tampering with any block changes every hash after it.
\[ \mathrm{Block}_i = \big(m_i,\ H(\mathrm{Block}_{i-1})\big) \]
Concept
Because each block embeds the previous block's hash, expanding the recursion shows that a recent block's hash depends on every block before it. Block 4, fully unfolded:
\[ \mathrm{Block}_4 = \big(m_4,\ H(m_3,\ H(m_2,\ H(m_1)))\big) \]
So a single hash at the top of the chain is a compact digest of the entire history. Change anything in m1, m2, or m3 and this top value changes.
Intuition
Suppose Alice gets the top hash H(Block i) from a trusted source, but downloads the actual blocks 1..i from an untrusted server. Can she trust the blocks? Yes — she can verify them herself.
She recomputes the hashes up the chain from block 1 and checks the result equals her trusted top hash. Because the hash is collision-resistant, any tampering in an early block changes every later hash and shows up as a mismatch at the top.
Ask yourself: what does Alice actually have to trust? (Only ONE value — the top hash — plus collision resistance. The server delivering the blocks can be completely untrusted.)
Step zero
Discussion prompt
§16.7 Tracing a tamper-detection — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.
Hint: It starts with: Alice holds a trusted top hash H(Block 4); she downloads blocks 1..4…
Answer:
Worked example
Alice holds a trusted top hash H(Block 4); she downloads blocks 1..4 from an untrusted server
Why: The top hash is her single anchor of trust; the blocks themselves come from somewhere she does NOT trust.
A malicious server alters m2 (say, to redirect a payment) and re-sends the chain
Why: The attacker hopes Alice won't notice the change buried in an old block.
Alice recomputes hashes up the chain: H(Block 1), then H(Block 2) using the tampered m2, and onward
Why: Changing m2 changes H(Block 2), which changes H(Block 3), which changes H(Block 4) — the change cascades upward.
| block | honest hash | after tampering m2 |
|---|---|---|
| Block 1 | h1 | h1 (unchanged) |
| Block 2 | h2 | h2' ≠ h2 |
| Block 3 | h3 = H(m3,h2) | h3' ≠ h3 |
| Block 4 (top) | h4 (trusted) | h4' ≠ h4 — MISMATCH |
\[ H(\mathrm{Block}_4)_{\text{recomputed}} \ne H(\mathrm{Block}_4)_{\text{trusted}} \ \Rightarrow\ \text{tampering detected} \]
Verify: the recomputed top hash differs from the trusted one, so Alice rejects the chain
Why: §16.7: collision resistance means the attacker cannot alter m2 without changing the top hash. One trusted hash plus recomputation verifies the entire history — no trusted server needed.
Trade off
Comparison matrix
From §16.7 Tracing a tamper-detection: every row here is a choice with a cost. Fill the after tampering m2 column, then say which row you would actually pick and what you give up for it.
| block | honest hash | after tampering m2 |
|---|---|---|
| Block 1 | h1 | h1 (unchanged) |
| Block 2 | h2 | h2' ≠ h2 |
| Block 3 | h3 = H(m3,h2) | h3' ≠ h3 |
| Block 4 (top) | h4 (trusted) | h4' ≠ h4 — MISMATCH |
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'Since I download the whole blockchain from some server, I have to trust that server not to lie to me.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: The server delivering the blocks can be fully malicious.
A student: what's the minimum you must trust?
Why: The server delivering the blocks can be fully malicious. If you have a trusted top hash, you recompute the chain yourself and detect ANY tampering — the data source needs no trust at all.
Trap
A student: 'Since I download the whole blockchain from some server, I have to trust that server not to lie to me.'
Assume the download source must be trusted
Why: Wrong. The server delivering the blocks can be fully malicious. If you have a trusted top hash, you recompute the chain yourself and detect ANY tampering — the data source needs no trust at all.
A student: what's the minimum you must trust?
Trust ONE top hash; verify everything else by recomputing
Why: §16.7: one trusted top hash plus collision resistance lets you verify the entire history from an untrusted source. Tampering changes every later hash and is caught at the top.
Concept
The hash chain makes the ledger append-only: new blocks can be added at the top, but no past block can be changed without breaking the chain above it.
This is exactly the property a ledger of money needs — history must be permanent. An attacker can still TRY to rewrite an old block, but doing so changes every later hash, which the next section (consensus) is what ultimately stops from being accepted.
Section
Part 5 · §16.8–16.9 forks and the longest chain
Concept
There is no central ledger server, so every participant stores the whole blockchain. New transactions are broadcast to the network, and each user independently checks them against the three validity rules.
This is the decentralized version of the ledger: thousands of copies, each verified locally. But it raises a new problem — what happens when malicious participants disagree about which chain is real?
Concept
Mallory pays for something, then tries to undo it. She goes back to a point in the chain BEFORE her payment and re-builds an alternative chain from there in which the payment never happened.
Fork — Two different chains that share a common prefix and then diverge. A malicious fork tries to rewrite history — e.g. to erase a transaction the attacker already benefited from (a double-spend).
The hash chain alone doesn't resolve this: both forks are internally valid hash chains. The network needs a rule to agree on ONE of them. That rule is consensus via proof of work.
Concept
Only miners add blocks, and only by attaching a valid proof of work: a computational puzzle that's expensive to solve but trivial to check.
Proof of work — A miner hashes the block concatenated with a NONCE, incrementing the nonce until the resulting hash starts with N zero bits (N is set by the algorithm, e.g. 33). Finding such a nonce takes many hashes; verifying it takes one.
\[ \text{find a nonce so that } H(\text{block} \,\|\, \text{nonce}) \text{ starts with } N \text{ zero bits} \]
Intuition
Because each block costs real computation to produce, building a chain is a RACE measured in computing power. Honest miners all extend the same chain, so the honest chain grows fastest.
Miners broadcast solved blocks, and honest miners accept the longest correct chain. To fork the chain, Mallory would have to out-compute everyone else and produce a LONGER alternative chain — outrunning the entire honest network.
Ask yourself: why does the longest chain win rather than the 'first' or 'newest'? (Length = total work. The longest correct chain is the one the most computing power agreed on, so it's the hardest to have forged.)
Concept
When Alice makes a payment, she broadcasts it to the whole network. Every participant independently runs the three validity checks (§16.4) before relaying or accepting it.
Miners then gather valid pending transactions into a candidate block and compete to attach a proof of work. Until a transaction is buried under proof-of-work blocks, it isn't yet settled history.
Explain it
Discussion prompt
Explain §16.8 New transactions are broadcast and checked by all to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.
Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.
Answer:
When Alice makes a payment, she broadcasts it to the whole network. Every participant independently runs the three validity checks (§16.4) before relaying or accepting it.
Concept
Bitcoin assumes more than 50% of computing power is honest. Under that assumption, the honest chain outpaces any attacker's chain, so the longest-chain rule converges on the honest history.
51% attack — Mallory can fork the chain — rewriting history and double-spending — only if she controls MORE than 50% of the network's computing power, so she can out-mine everyone else combined. Below 50%, the honest chain always wins the race.
Analogy
Discussion prompt
Explain §16.9 The >50% honest assumption by analogy to something with no Computer Security in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.
Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.
Answer:
Bitcoin assumes more than 50% of computing power is honest. Under that assumption, the honest chain outpaces any attacker's chain, so the longest-chain rule converges on the honest history.
Ranking
Put in order
Put the moves of §16.9 The longest-chain race into the order they have to happen.
Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. A shared prefix everyone has accepted; the next block to mine is b4.
Worked example
All miners agree on the chain b1 → b2 → b3
Why: A shared prefix everyone has accepted; the next block to mine is b4.
Miners M1, M2, M3 race to mine b4 by solving the proof-of-work puzzle
Why: Whoever finds a valid nonce first broadcasts their b4; finding it is proportional to computing power.
Suppose two blocks appear briefly — a short fork b1b2b3b4 and a competing b1b2b3b4'
Why: Network delay can let two miners solve b4 at nearly the same time, creating two candidate chains of equal length.
| chain | length | honest miners do what |
|---|---|---|
| b1 b2 b3 b4 | 4 | extend whichever they saw first |
| b1 b2 b3 b4' | 4 | tie — undecided for now |
| b1 b2 b3 b4 b5 | 5 (longer) | ACCEPT — discard the shorter fork |
\[ \text{accept the LONGEST correct chain; discard the shorter fork} \]
Verify: once b5 extends one branch, every honest miner adopts the length-5 chain and the other branch dies
Why: §16.9: the longest correct chain wins. With >50% honest power, honest miners extend the honest chain fastest, so Mallory cannot keep a competing fork ahead — her rewrite never becomes the longest.
Comparison
Comparison matrix
From §16.9 The longest-chain race: refill the honest miners do what column from what you know. The rest of the table is as it appeared.
| chain | length | honest miners do what |
|---|---|---|
| b1 b2 b3 b4 | 4 | extend whichever they saw first |
| b1 b2 b3 b4' | 4 | tie — undecided for now |
| b1 b2 b3 b4 b5 | 5 (longer) | ACCEPT — discard the shorter fork |
Intuition
Proof of work is asymmetric: finding a nonce that makes H(block‖nonce) start with N zero bits takes (on average) about 2^N hash attempts, but VERIFYING a claimed nonce is a single hash.
That's why the network can demand expensive work from miners while every other participant checks it cheaply. The cost lives entirely on the proposer's side — the same one-way-ness as a hash, weaponized into a race.
Ask yourself: why tie the puzzle to the block's contents via H(block‖nonce)? (So the work commits to THAT specific block — you can't reuse a solved nonce for different transactions.)
Counterexample
Discussion prompt
Proof of work is asymmetric: finding a nonce that makes H(block‖nonce) start with N zero bits takes (on average) about 2^N hash attempts, but VERIFYING a claimed nonce is a single hash.
That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.
Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.
Answer:
Ask yourself: why tie the puzzle to the block's contents via H(block‖nonce)? (So the work commits to THAT specific block — you can't reuse a solved nonce for different transactions.)
Anomaly
Predict first
A student writes this, and it looks reasonable:
A student: 'An attacker with a decent slice of mining power — say 10% — can fork the chain and double-spend.'
It is wrong. Say what breaks — and say it before you turn the page.
Correct: With 10% of the power, the attacker's chain grows far slower than the honest 90%.
A student: what does it actually take to fork the chain?
Why: With 10% of the power, the attacker's chain grows far slower than the honest 90%. By the longest-chain rule, the honest chain stays longer, so the attacker's fork is never adopted. A minority cannot rewrite history.
Trap
A student: 'An attacker with a decent slice of mining power — say 10% — can fork the chain and double-spend.'
Assume a minority of computing power can fork the chain
Why: Wrong. With 10% of the power, the attacker's chain grows far slower than the honest 90%. By the longest-chain rule, the honest chain stays longer, so the attacker's fork is never adopted. A minority cannot rewrite history.
A student: what does it actually take to fork the chain?
Require MORE than 50% of computing power (a 51% attack)
Why: §16.9: only an attacker with >50% of the power can out-mine the honest majority and produce a longer chain. Bitcoin's security rests entirely on the honest-majority assumption.
Two truths and a lie
Sort into buckets
Some of these hold up and some are the exact mistakes this lesson is built to prevent. Sort them.
Constraint
Discussion prompt
Run The Bitcoin playbook with this step confiscated:
Three validity checks: (1) signature verifies, (2) sender was a previous receiver, (3) sender hasn't already spent it — replacing the bank.
Is it still possible? If it is, say what takes its place and what it costs you. If it is not, say exactly what that step was providing that nothing else does.
Hint: A step you can drop for free was never load-bearing. If you cannot drop it, name the thing that goes wrong the moment it is gone.
Answer:
Pattern
Edge cases
Discussion prompt
The Bitcoin playbook works on the cases you have just seen. Push it to the edge: what is the most degenerate input it still handles — empty, zero, one item, everything equal — and what is the first case where it stops being true? Name the case, not just "it breaks".
Hint: Try the smallest legal input, then the largest, then the one where two things collide. Methods are specified at their edges; the middle takes care of itself.
Answer:
Elimination
Eliminate the wrong options
Which statement about this Bitcoin ledger is TRUE?
3 of these 4 are wrong. Strike them one at a time, and say what rules each one out before you strike the next. The survivor is the answer.
Survives elimination: B
Why: §16.4–16.5: balances are not stored — you deduce them by replaying the ledger. From Bob $10: after Bob→Alice $5, Bob→Mallory $2, and Mallory→Alice $1, Alice holds $5 + $1 = $6. The transaction Alice→Eve $9 fails validity check 3 (she cannot spend more than she has), since $6 < $9, so every participant rejects it. There is no stored balance, no bank, and forking the chain to rewrite history requires MORE than 50% of computing power, not 10%.
Check
The ledger starts with Bob holding $10. It records, in order: Bob→Alice $5, Bob→Mallory $2, Mallory→Alice $1. A new transaction Alice→Eve $9 is broadcast. Replay the ledger before choosing.
Check your understanding
Which statement about this Bitcoin ledger is TRUE?
Answer: B
Why: §16.4–16.5: balances are not stored — you deduce them by replaying the ledger. From Bob $10: after Bob→Alice $5, Bob→Mallory $2, and Mallory→Alice $1, Alice holds $5 + $1 = $6. The transaction Alice→Eve $9 fails validity check 3 (she cannot spend more than she has), since $6 < $9, so every participant rejects it. There is no stored balance, no bank, and forking the chain to rewrite history requires MORE than 50% of computing power, not 10%.
Concept
Concept
Concept
Connect it up
Draw it
One page, no notation unless you need it: draw how these connect — The Problem — Money With No Bank · Identity — You Are a Public Key · Transactions & Balances From the Ledger · The Hash Chain — an Immutable Ledger · Consensus & Proof of Work. Put an arrow wherever one of them is what makes another possible, and label the arrow with why.
Recap
You can now state the properties Bitcoin must provide with no bank, explain identity-as-a-public-key, deduce balances by replaying the signed ledger and apply the three validity checks, build the append-only hash chain and verify all history from one trusted top hash, and explain how proof of work and the longest-chain rule give consensus under a >50%-honest majority.
| Idea | § | The one-line version |
|---|---|---|
| The goal | 16.1 | Money's properties with NO trusted central party |
| Identity = public key | 16.3 | You are PK; prove it by signing with SK; pseudonymous |
| Signed transaction | 16.4 | Sign(SK_A): 'PK_A sends n to PK_B', anyone verifies |
| Balances by replay | 16.5 | Replay the ledger; nothing stores balances directly |
| Three validity checks | 16.4 | Signature, prior receiver, not already spent |
| Hash chain | 16.6–16.7 | Block_i=(m_i,H(Block_{i-1})); one top hash verifies all |
| Proof of work | 16.8–16.9 | Nonce → N zero bits; longest chain; >50% honest |
Want this taught 1-on-1? Alexander tutors Computer Security — $55/session, free consultation.