MASTERING-BITCOIN
| Concept | Meaning |
|---|---|
| Root of Trust | The one component everything else depends on; the whole system inherits its weakness. |
| Bitcoin's Root of Trust | The validated blockchain, anchored at the genesis block and verified block-by-block by your own node. |
| Two Pillars | (1) Decentralized key control — users hold their own keys. (2) Independent validation — every node checks the rules itself. |
| Single Point of Failure | A component whose compromise alone takes down the whole system. |
| Compromise Thought Experiment | Imagine each component fully controlled by an attacker — is the app still secure? Trust only what survives the worst case. |
Traditional architects shrink the root of trust down to the simplest component they can. The reason: more complexity means more bugs, and more bugs mean more vulnerability.
Drag the slider to change how much code lives inside the trusted core, and watch how the estimated number of latent bugs (the attack surface) grows.
⚙ interactive visualization — coming to this page format soon
Reflect: A tiny, simple core has the least surface area for an attacker, so it is the thing least likely to fail — exactly what you want to trust most. Bitcoin takes this idea further: instead of a small core you control, the trusted core is the validated blockchain, replicated across thousands of nodes.
Take each component of an app, one at a time, and imagine it is fully controlled by an attacker. Then ask: is my app still secure?
If a single component's compromise breaks the whole app, you've found a single point of failure — a place where trust was misplaced. Select a component below to "stamp it COMPROMISED" and see the verdict.
⚙ interactive visualization — coming to this page format soon
Notice: Every component outside the blockchain — hot wallet, database, server, encryption key — breaks the app the moment it is compromised on its own. Only the blockchain survives the test: a well-built Bitcoin app should be vulnerable only to a compromise of Bitcoin consensus itself. Trust only what survives the worst case.
A centralized app has one server to seize, bribe, or hack. Bitcoin's history is replicated across thousands of independent nodes that reach consensus together — there is no central server to attack.
Suppose an attacker can compromise any single node with probability p. For a decentralized system, the attacker must compromise a majority of nodes to break consensus. See how adding nodes changes the chance the whole system fails.
⚙ interactive visualization — coming to this page format soon
Reflect: With a single server (n = 1), the system fails as easily as that one component (probability p). As long as each node is more likely honest than not (p < 0.5), adding independent validators drives the failure probability toward zero. That is the power of decentralized consensus — there is no single point to seize, bribe, or hack.
Question 1
According to the video, what is Bitcoin's root of trust — the foundation that everything else depends on?
✅ Correct! Your own node verifies the chain from genesis, block by block.
❌ Not quite. A chip, a hot wallet, or a vault are all things you control on your hardware — Bitcoin's trust lives in the decentralized, validated chain.
Solution:
Bitcoin's root of trust is the validated blockchain itself. It is anchored at the genesis block (the very first block, hardcoded into the software), and every following block is independently validated — building an unbroken chain of trust up to the current block.
Crucially, this chain is replicated across thousands of decentralized nodes that reach consensus together. There is no central server to seize, bribe, or hack.
Question 2
True or False: Holding users' private keys for them is just a harmless convenience feature that keeps users safely inside Bitcoin's security model.
✅ Correct! Custodial key-holding creates a honeypot and steps outside Bitcoin's pillars.
❌ Not quite. Holding user keys is exactly what moves users outside Bitcoin's security model and recreates the fragile bank honeypot.
Solution: False.
Taking custody of users' keys moves them outside Bitcoin's security model. It breaks the first pillar — decentralized key control — and builds a honeypot: one tempting target holding everyone's funds.
The early exchange hacks happened precisely because a single hot wallet held every customer's coins. Encryption layers don't change where the root of trust lives; the keys are still a single point of failure.
Question 3
You run the compromise thought experiment on your app. For a truly secure Bitcoin application, the app should fail only when which component is compromised?
✅ Correct! That is the goal state — trust only what survives the worst case.
❌ Not quite. If compromising the hot wallet, database, or key alone breaks the app, those are single points of failure — not the goal.
Solution: Bitcoin consensus itself.
In the thought experiment you imagine each component fully controlled by an attacker:
The goal state is an app that is vulnerable only to a compromise of Bitcoin consensus — everything else has been removed as a single point of failure.
Question 4
The video says choosing a centralized architecture for a Bitcoin app leaves you two options, both bad. Which statement best captures this dilemma?
✅ Correct! Both centralized paths either rebuild the honeypot or just break even.
❌ Not quite. Encryption layers and more developers don't change where the root of trust lives — centralization keeps a single point of failure.
Solution:
A centralized choice leaves two bad options:
Building centralized security "well enough" only recreates the traditional model with all its weaknesses, while forfeiting Bitcoin's unique strengths. The lasting principle: make the blockchain your only explicit point of trust.
Solved: 0 / 4