Lecture 19: Bitcoin

What this lecture covers

The lecture explains how Bitcoin solves a problem closely related to certificate transparency from the previous lecture: getting a large, open set of mutually distrusting participants to agree on a single public ledger of transactions, so that a coin can't be spent twice. It first rules out a trusted-central-party solution and a naive voting scheme (neither works when anyone can join anonymously and IP addresses can be forged), then builds up the blockchain, proof-of-work mining, and the longest-chain rule as Bitcoin's actual answer.

You'll come away understanding why blocks are chained by cryptographic hash, why mining requires real CPU work rather than votes, how temporary forks arise and get resolved, why merchants wait for multiple confirming blocks before treating a payment as final, and what it would take for an attacker to rewrite history. The lecture also covers practical limits: transaction throughput, the ten-minute block interval, storage growth, and the limits of Bitcoin's anonymity.

Key ideas

• Public ledger (blockchain): a single agreed-on sequence of transactions that lets everyone check whether a coin has already been spent, preventing double-spending.
• Why no trusted central party: in a worldwide, open system there's no single entity everyone trusts, so Bitcoin is designed to tolerate malicious participants rather than rely on one.
• Why simple voting fails: without knowing how many peers exist or being able to limit one vote per participant, an attacker can cheaply forge IP addresses or compromise machines to control a majority of votes.
• Proof-of-work mining: a peer must find a nonce that makes the block's hash have enough leading zeros, which costs real CPU time and can't be faked, making block creation a random, hard-to-manipulate process instead of a vote.
• Chained hashes: each block includes the hash of the previous block, so altering an earlier block changes its hash and breaks every later block that refers to it.
• Forks and the longest-chain rule: when two valid blocks are mined around the same time, peers temporarily split into two chains, but all peers switch to whichever chain becomes longer first, and mining effort concentrates there until the shorter fork is abandoned.
• Confirmations: because a recently added block could still end up on an abandoned fork, recipients of high-value payments wait for several subsequent blocks before treating a transaction as final.
• 51% attack: an attacker with more mining power than the rest of the network combined could out-mine the honest chain and force a longer, alternate fork that reverses transactions, though this is expensive and would undermine trust in Bitcoin.

Walkthrough

Why a trusted party or simple voting doesn't work (0:00 to 7:03)

The lecture opens by stating the goal: a global published record of transactions, ordered so that if someone tries to double-spend a coin, only the first transaction counts. A single trusted party could maintain this log, but no entity is trusted globally. A voting scheme among open peers also fails, because Bitcoin doesn't know how many participants exist and can't stop an attacker from forging IP addresses or compromising machines to accumulate a fake majority, which would let the attacker show different peers conflicting versions of the ledger.

Blocks, transactions, and mining (8:06)

Bitcoin's blockchain is a chain of blocks, each containing the hash of the previous block, a batch of transactions (each with a hash of the prior transaction for that coin, the new owner's public key, and a signature from the previous owner's private key), a nonce, and a timestamp. Producing a valid new block, called mining, requires finding a nonce that makes the block's cryptographic hash start with enough leading zeros, a search that costs real, unfakeable CPU time. The difficulty adjusts so that, across the whole network, a new block is found roughly every ten minutes.

Forks and the longest-chain rule (22:15)

Because many peers mine simultaneously on slightly different sets of pending transactions, two different valid successor blocks can appear around the same time, creating a fork. Peers initially split between the two, but as soon as one fork produces a longer chain, all peers switch to extending it, and the shorter fork's transactions (except any also present in the winning fork) are simply dropped. The lecture uses a coffee-shop example to show why a recipient who accepts payment as soon as it appears in the latest block can be left unpaid if that block ends up on the losing fork, which is why high-value transactions should wait for several confirming blocks.

Attacking the chain (33:25)

Modifying a transaction buried in an old block doesn't work quietly, since it changes that block's hash and breaks the hash links in every subsequent block. A more serious attack is possible if a party controls more mining power than the rest of the network combined: it could mine an alternate, longer chain that omits a transaction, and honest peers would switch to it under the longest-chain rule, enabling a double spend. The lecture notes this is what makes waiting for confirmations meaningful, and that while a few large mining operations control sizable shares of Bitcoin's mining power, actually mounting such an attack would be expensive and would likely destroy confidence in, and the value of, the system the attacker has invested in.

Practical limits: throughput, storage, and anonymity (43:40)

The ten-minute block interval exists because shorter intervals would leave too little time for new blocks to propagate across thousands of peers before the next one is found, wasting miners' effort on superseded blocks. Peers must track all unspent transactions indefinitely to check for double-spends, and block-size and interval limits cap Bitcoin's throughput well below what's needed to handle large-scale commerce. The lecture also addresses anonymity: using a fresh public key per transaction helps, but real-world clues, like a shipping address tied to a purchase, mean Bitcoin resists casual observers but is not truly anonymous against a determined investigator.

Before you watch

• Watch the previous lecture on Certificate Transparency, since this lecture explicitly builds on its handling of public logs, forks, and the problem of agreement without a trusted party.
• Basic familiarity with public-key cryptography and cryptographic hashing (from earlier in the course) is assumed, since transactions and blocks rely on signatures and hash chaining.

Check your understanding

1. Why can't Bitcoin rely on a simple majority vote among peers to decide which transaction happened first?
2. What does proof-of-work mining actually prove, and why does it prevent an attacker from cheaply controlling block creation?
3. How does the longest-chain rule resolve a fork, and why might a payment that appears in the very latest block still not be safe to treat as final?
4. What would an attacker need in order to reverse an already-confirmed transaction, and why is this considered impractical against a large, established network?
5. Why is Bitcoin's anonymity weaker in practice than it might first appear, even when a new public key is used for every transaction?