Lecture 2: How Bitcoin Achieves Decentralization

What this lecture covers

Lecture 1 ended with ScroogeCoin, a currency that works but depends on a trusted central party, Scrooge. This lecture asks how to remove that central party while keeping the system secure. It answers the question in two parts: a technical mechanism (distributed consensus over a blockchain, built on proof-of-work hash puzzles) and an incentive mechanism (paying miners in the currency itself).

After this lecture you'll understand why Bitcoin nodes don't need identities, how nodes implicitly agree on the next block by extending the longest valid chain, why double spending is the only attack that actually threatens the system, how mining difficulty self-adjusts to keep block time near 10 minutes, and what a 51%-hash-power attacker can and cannot do. It sets up the following lecture, which moves from consensus to the mechanics of Bitcoin transactions and scripting.

Key ideas

• Distributed consensus: a protocol where a fixed set of nodes, some possibly faulty, terminates with all correct nodes agreeing on a value that at least one of them proposed.
• Implicit consensus: instead of voting, a selected node proposes the next block, and other nodes implicitly accept or reject it by extending the chain from it or ignoring it.
• Longest valid chain rule: honest nodes always extend whatever branch is longest among the valid branches they've seen, which is what resolves competing blocks.
• Proof of work / hash puzzles: a node must find a nonce so that hashing the block's contents produces an output below a target threshold — expensive to find, trivial to verify.
• Difficulty adjustment: the network recalculates the target every two weeks so the average time between blocks stays near 10 minutes, regardless of total mining power.
• Block reward and transaction fees: the two incentive mechanisms that pay miners in Bitcoin for extending the chain, only if their block ends up on the consensus branch.
• Confirmations: the probability that a transaction survives on the long-term chain rises exponentially with the number of blocks built on top of it; six is the common heuristic.
• 51% attack limits: even with majority hash power, an attacker cannot forge signatures or steal coins or change protocol rules; they can attempt double spends and censor transactions, and mainly risk destroying confidence in the currency.

Walkthrough

Centralization vs. decentralization (1:12)

The lecture frames decentralization as a spectrum, not all-or-nothing, using email (decentralized SMTP protocol, but centralized webmail providers) as an analogy. It breaks Bitcoin's decentralization into five questions — who maintains the ledger, who decides which transactions are valid, who creates new coins, who changes the rules, and how coins acquire exchange value — and focuses this lecture on the first three. It then rates three components of Bitcoin on the centralization spectrum: the peer-to-peer network (close to fully decentralized, low barrier to running a node), mining (technically open but concentrated due to high capital cost), and software updates (core developers hold outsized influence in practice).

Distributed consensus (4:45)

The lecture defines distributed consensus formally, connects it to traditional applications like keeping replicated databases consistent, and sketches a naive version for Bitcoin: nodes agree block-by-block on a sequence of valid transaction blocks. It explains why the classical theory of distributed consensus (including impossibility results like the Byzantine Generals Problem and FLP) doesn't map cleanly onto Bitcoin: Bitcoin has no global clock, nodes have no persistent identities, and it introduces two things the traditional theory didn't assume — financial incentives and randomness. Because consensus in Bitcoin resolves probabilistically over about an hour rather than deterministically at a fixed point, it sidesteps the classical impossibility results.

Consensus without identity: the block chain (17:46)

Since nodes can't be reliably identified (a central authority would be needed, and pseudonymity is a design goal), the lecture proposes a weaker assumption: some mechanism can approximately select a random node per round. Under this assumption, "implicit consensus" works by having the randomly selected node unilaterally propose the next block; other nodes signal acceptance by extending the chain from it (via a hash pointer to it) or reject it by continuing from the previous block. The lecture then walks through what a malicious node can and can't do: it cannot forge signatures to steal coins, it can only mildly annoy a target by omitting their transactions temporarily, but it can attempt a double-spending attack. It illustrates a double spend against a merchant, Bob, and explains why Bob should wait for confirmations — the more blocks build on top of a transaction, the more exponentially unlikely a competing branch is to overtake it, which is why six confirmations became the common heuristic.

Incentives and proof of work (35:43)

Since Bitcoin can't punish dishonest nodes (they have no identity to penalize), it instead rewards honest block creation using two mechanisms: the block reward, a coin-creation transaction only valid if the block ends up on the consensus chain, and transaction fees, the voluntary difference between a transaction's input and output value. The block reward halves every four years, giving a total eventual supply of 21 million bitcoins, with the reward expected to run out around 2040; transaction fees are expected to take over as the main incentive. The lecture then explains how the "leap of faith" of random node selection is actually implemented: proof of work, where nodes compete to find a nonce making a block's hash fall below a target, approximating random selection weighted by computing power. It covers the three key properties of this puzzle — it's expensive to compute, its difficulty is automatically retargeted every two weeks to hold block time near 10 minutes, and it's trivial for any node to verify. It closes with a simple mining-economics equation (reward vs. hardware and electricity cost) and notes that real mining strategy is a more complex, still partly unresolved game theory problem.

Putting it all together (55:39)

The lecture recaps identities (anonymous key pairs), transactions (signed instructions broadcast peer-to-peer), the blockchain and consensus (security comes from confirmations, not from the peer-to-peer network's reliability), and mining. It highlights a bootstrapping dependency: blockchain security requires honest miners, honest mining requires a valuable currency, and a valuable currency requires trust in the blockchain's security — a chicken-and-egg loop that Bitcoin had to climb out of from nothing. Finally, it works through what a 51%-hash-power attacker can and cannot do: they cannot steal coins (that requires breaking cryptography, not consensus) or unilaterally change protocol rules (other nodes run their own software), but they can attempt double spends and censor specific addresses' transactions (though not hide them from the peer-to-peer network entirely). The most realistic damage from such an attack is destroying public confidence in the currency rather than any specific technical exploit.

Before you watch

• Watch Lecture 1 first — this lecture assumes familiarity with hash pointers, digital signatures, and ScroogeCoin's transaction structure.
• A rough sense of what a peer-to-peer network is will help, though the lecture explains the relevant parts.

Check your understanding

1. Why does Bitcoin's consensus process work "better in practice than in theory," according to the lecture, despite classical impossibility results?
2. Explain how implicit consensus works: what does a node do to signal acceptance or rejection of a proposed block?
3. Why is a double-spend attempt technically indistinguishable from a legitimate payment, and how does the network eventually resolve which one "wins"?
4. What are the two separate incentive mechanisms that reward miners, and why does the block reward alone fail to incentivize honesty without the "only valid on the consensus chain" rule?
5. List two attacks a 51% attacker can carry out and two they cannot, and explain the reasoning behind each.