“Trustless” is relative. Every Bitcoin client chooses a security model: what it verifies locally vs what it assumes about peers, miners, or snapshots.
Complete Step 1 // Required reading in the study plan above, then continue here.
Step 2 — Core idea: what you verify vs what you assume
Product builders who default to third-party APIs without labeling trust boundaries ship wallets that fail silently under eclipse, dishonest servers, or chain forks.
| Model | Verifies locally | Main assumption |
|---|---|---|
| Full node | PoW, scripts, consensus history (with pruning/assumevalid nuances) | Honest majority of work + your software |
| SPV | Headers + merkle proofs for txs of interest | Miners won’t feed invalid high-work forever without detection |
| BIP157/158 filters | Filters + blocks of interest you download | Peers serve honest filters; better privacy than BIP37 blooms |
| Indexer API | Little on-chain verification | The server is honest and available |
| AssumeUTXO | Background validation after snapshot | Snapshot commitment until validation catches up |
Loading diagram…
AssumeUTXO helps nodes sync faster by loading a committed UTXO snapshot, then background-validating. It trades bootstrap time for carefully scoped assumptions until validation completes.
Done when: You can place a wallet design on the table above and name one failure mode it cannot detect.
Step 3 — Trust-boundary map (lab)
Draw a diagram for (a) full node, (b) Neutrino-style filters, (c) Electrum/Esplora. For each: one paragraph on fraud/censorship risk. Recommend a default for a beginner builder and why.
Common mistakes
- Calling any API-backed wallet “non-custodial and trustless”
- Ignoring that light clients can be lied to about absence of transactions
- Skipping background validation after snapshot sync in ops runbooks
Done when: Lab evidence (diagram + three risk paragraphs + recommendation) is complete.
Next lesson
Soft Forks & Activation — how consensus upgrades land without splitting the network.