RoadmapsProjects
Sign in./start

Learn

RoadmapsProjects

Contribute

DiscoverIssues

Account

Sign in./start-building

Become an Open Source Builder. Learn. Build. Contribute.

Learn

RoadmapsProjectsStart Building

Contribute

DiscoverIssues

Account

Sign inDashboardSettings

Legal

PrivacyTerms

© 2026 Pull // all rights reserved

PrivacyTerms

lesson // bitcoin

Security Models & Light Clients

Full validation vs SPV, Neutrino filters, AssumeUTXO, and what “trustless” really means for builders.

advanced6 days

Public lesson — sign in to track progress on this roadmap.

./sign-in

On this page

Learning objectives

  • Contrast full-node security with SPV / light-client assumptions
  • Explain BIP157/158 compact block filters at a builder level
  • Describe AssumeUTXO’s purpose and remaining trust tradeoffs

study // plan

Lessons are primers. Depth comes from required reading, interactive labs, reflection, and a hands-on check with evidence — the BOSS study pattern.

Research on Bitcoin Search
BIP157BIP158

Required reading

  • bipBIP-157 Compact Block Filters
  • bipBIP-158 Compact Block Filter Encoding
  • docsAssume UTXO FAQs

Reflection prompts

  1. What can an SPV client prove, and what must it assume about miners or peers?
  2. How do compact block filters improve light-client privacy vs BIP37 bloom filters, and what remains leaked?
  3. When would you accept AssumeUTXO for a product bootstrap, and what background validation still matters?

Lab // Trust boundary map

Draw a trust-boundary diagram for a wallet product choosing (a) full node, (b) Neutrino-style filters, or (c) third-party Electrum/Esplora. Label what each design can detect.

evidence required

  • ·Diagram (SVG, Mermaid, or photo of whiteboard)
  • ·One paragraph per option on fraud/censorship risk
  • ·Your recommended default for a beginner builder and why

“Trustless” is relative. Every Bitcoin client chooses a security model: what it verifies locally vs what it assumes about peers, miners, or snapshots.

Why this matters

Product builders who default to third-party APIs without labeling trust boundaries ship wallets that fail silently under eclipse, dishonest servers, or chain forks.

Full nodes

A validating full node checks proof-of-work, scripts, and economic history rules (with pruning/assumevalid nuances). Highest assurance; highest cost.

SPV and filters

Classic SPV verifies proof-of-work headers and merkle proofs for transactions of interest, trusting that miners will not feed an invalid-but-high-work chain forever without fraud proofs.

BIP157/158 compact block filters let light clients request filters and download blocks of interest with better privacy than BIP37 bloom filters — still not full validation.

AssumeUTXO

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.

Label the model in your README

Users deserve to know whether your app verifies scripts, trusts an indexer, or uses filters. Silence is a product bug.

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

further reading

  • articleBitcoin’s Security Model: A Deep Dive

progress // sign in

Reading is public. Sign in to mark lessons complete, sync across devices, and unlock your roadmap.

./sign-in-to-track
prevP2P Adversarial ThinkingnextSoft Forks & Activation

On this page

Press Shift + ? for keyboard shortcuts.

Press R to research on Bitcoin Search.