Lecture 4: Blockchain Basics and Consensus

What this lecture covers

Following the cryptography lecture, this class tackles consensus: how a decentralized network with no central authority agrees on which transactions are valid. Gary Gensler frames this through the Byzantine generals problem — a classic game-theory puzzle about reaching agreement when some participants might be malicious or unreachable — and walks through how Bitcoin's proof-of-work mining, building on Adam Back's 1997 anti-spam scheme, solves it. The class covers mining difficulty, forks and stale blocks, mining hardware evolution, mining pools, and Bitcoin's built-in monetary policy.

After watching, you should be able to explain why proof-of-work puzzles are hard to solve but easy to verify, describe what happens when two miners solve a block at nearly the same time (a fork), and explain how Bitcoin's difficulty adjustment keeps block times near 10 minutes despite huge swings in total mining power.

Key ideas

• Byzantine generals problem: a group of generals surrounding a target must coordinate an attack-or-retreat decision without a trusted central coordinator, and some generals may be malicious or unreliable — the same coordination problem a decentralized blockchain network faces.
• Asymmetric difficulty: proof-of-work puzzles are deliberately hard to solve (requiring many computational attempts) but trivially easy for others to verify, which is essential to making decentralized consensus practical.
• Origins in anti-spam work: Adam Back's 1997 hashcash proposal required a few seconds of computation per email to deter spam; Bitcoin adapted this same hash-based proof-of-work idea, requiring a hash with a target number of leading zeros.
• Difficulty adjustment: Bitcoin recalculates its difficulty target roughly every two weeks (every 2,016 blocks) to keep the average block time near 10 minutes, regardless of how much total computing power is mining.
• Stale blocks and forks: when two miners solve a block at nearly the same time, the network temporarily forks; miners generally converge on the longest chain, and the losing ("stale" or "orphan") block's transactions return to the mempool rather than being lost.
• Hard forks create new currencies: when a fork persists and gains lasting social consensus rather than being abandoned, it can become a permanent, separate currency — as happened when Bitcoin Cash split from Bitcoin.
• Mining hardware evolution: Bitcoin mining progressed from CPUs, to GPUs, to purpose-built ASICs (application-specific integrated circuits), each generation dramatically increasing hashing speed and industrializing the practice.
• Mining pools: because solving a block alone is highly improbable for small miners, pools combine computing power and share rewards, typically charging operators a 1-3% fee, smoothing out the variance in mining income.
• Built-in monetary policy: Bitcoin's block reward halves roughly every 210,000 blocks (initially 50 BTC, then 25, then 12.5 at the time of the lecture), producing a declining, hard-coded inflation rate that approaches zero as supply nears the 21 million cap.
• Alternative consensus mechanisms: beyond proof-of-work, other designs include proof-of-stake, proof-of-activity, proof-of-burn, and proof-of-capacity, generally using randomization or delegation to select who validates the next block.

Walkthrough

The Byzantine generals problem and proof-of-work preview (0:52)

Gensler opens with the study questions: what is the Byzantine generals problem, and how does proof-of-work address it? Students offer early answers describing it as a coordination problem among possibly unreliable or malicious actors, which Gensler will expand on. He previews the day's three focus areas: consensus through proof-of-work and mining, the native currency, and networking.

Review of cryptography and Bitcoin addresses (12:55)

Before moving to new material, the class reviews the prior lecture's concepts — hash functions as commitment schemes (compared to a New York Times crossword puzzle), digital signatures for guarding against tampering and impersonation, and Bitcoin addresses as a hashed, shortened version of a public key.

Adam Back's hashcash and proof-of-work's origins (24:19)

Gensler explains that proof-of-work predates Bitcoin by over a decade: Adam Back's 1997 hashcash scheme required senders to perform a few seconds of hashing work per email, making mass spam computationally expensive while leaving single emails unaffected. Bitcoin adapted this same idea, requiring miners to find a block hash with a target number of leading zeros.

Chains, stale blocks and forks (29:45)

Using a chain diagram with a purple side-branch, the lecture explains how the network typically converges on the longest chain, leaving "stale" or "orphan" blocks whose transactions return to the mempool. A student's question about China isolating part of the network leads Gensler to describe Satoshi Nakamoto's own 2010 explanation: a minority-controlled network segment would eventually stop mining once it realized it wasn't on the majority chain. The Bitcoin Cash hard fork is discussed as a real example of a persistent fork becoming a separate currency.

Difficulty adjustment and mining hardware evolution (42:06)

Gensler details Bitcoin's difficulty target (18 leading zeros in the hash at the time of the lecture, versus 8 required at launch), recalculated roughly every two weeks to maintain 10-minute average block times. He then traces mining hardware from CPUs, to GPUs, to ASICs introduced in 2013, noting that overall mining difficulty had grown roughly seven trillion times harder than in 2009.

Mining pools and electricity economics (52:25)

The lecture covers how mining pools formed around 2010 to smooth out the low probability of any single miner solving a block, with pool operators typically charging 1-3% fees. Electricity cost (roughly 3 cents per kilowatt-hour as a rough break-even) and geographic concentration of mining are discussed, along with the possibility (not yet observed) of mining pools colluding for a 51% attack.

Native currency and monetary policy (58:34)

Gensler walks through Bitcoin's built-in "monetary policy": block rewards halving roughly every 210,000 blocks, a current inflation rate around 4.1% declining toward the 21 million cap near 2040, and a comparison to Ethereum's different issuance schedule. The class debates whether cryptocurrencies fully satisfy money's three classic roles (medium of exchange, store of value, unit of account), citing Bank of England governor Mark Carney's preference for the term "crypto assets."

Network participants and alternative consensus mechanisms (1:06:45)

The lecture closes by distinguishing full nodes, pruning nodes, lightweight (SPV) nodes, miners, wallets, and the mempool, noting that many miners rely on pool operators rather than running full validation themselves. Gensler briefly surveys alternative consensus designs — proof-of-stake, proof-of-activity, proof-of-burn, proof-of-capacity — noting that major permissionless blockchains still predominantly use proof-of-work.

Before you watch

• Watch Lecture 3 first, since this lecture builds directly on hash functions, digital signatures, and Bitcoin addresses covered there.
• Familiarity with the term "mining" in a general sense is helpful, though the lecture explains the mechanics from scratch.
• The Clark paper and NIST reading referenced in the lecture provide useful background on Nakamoto consensus, though they are not required to follow the lecture itself.

Check your understanding

1. What is the Byzantine generals problem, and how does it apply to a decentralized blockchain network with no central authority?
2. Why is it important that proof-of-work puzzles are hard to solve but easy to verify?
3. What happens to the transactions in a "stale" or "orphan" block after a fork resolves, and how did the Bitcoin Cash split differ from an ordinary stale block?
4. How does Bitcoin's difficulty adjustment mechanism keep average block times near 10 minutes as total mining power changes over time?
5. What incentive leads miners to join mining pools, and what tradeoff does a miner accept by not running a full node?