Bitcoin nodes come in three principal flavors with different trust assumptions and resource requirements. A full node downloads, validates, and stores the entire blockchain (~750 GB as of 2026); it independently verifies every consensus rule and is the maximal-sovereignty option. A pruned node performs the same validation but discards block data after validation, retaining only the UTXO set and recent blocks (~10-15 GB); it has the same trust model as a full node but lower disk requirements. A Simplified Payment Verification (SPV) light client downloads only block headers (~70 MB total for the entire chain history) plus Merkle proofs for transactions of interest; it relies on the longest-chain rule but cannot independently verify all consensus rules — it has to trust that miners enforce them, which most do. Compact block filters (BIP-157/158) are the modern light-client architecture, providing better privacy than the older BIP-37-based SPV. The choice between these affects sovereignty, privacy, resource cost, and the operational threat model — running a full node is the "don't trust, verify" standard for self-custodied Bitcoin holders.
Why this note matters
The decision to run your own node — and which kind — is one of the load-bearing self-custody decisions. A holder using only an SPV wallet is trusting the longest chain (a reasonable trust) plus their specific SPV server (less reasonable when the server is a third party). A holder running their own full node verifies everything personally; this is the structural expression of “don’t trust, verify.”
The trade-off is real: full nodes require substantial storage (~750 GB) and ongoing bandwidth (~5-15 GB/month); SPV clients run on phones. For most retail holders, this trade-off is non-trivial. Understanding what each model offers (and what it doesn’t) is essential for making the right operational choice.
What each type does
Full node (Initial Block Download + ongoing operation):
- Downloads all blocks from the network (~750 GB raw; 800+ GB with indexes)
- Validates every block against all consensus rules (Consensus rules)
- Maintains the full UTXO set (~10-15 GB in memory or on disk)
- Stores all historical blocks
- Can serve any historical query (recover a transaction from 2011 by TXID; check what was in any block)
- Propagates blocks and transactions to other nodes (participates in The peer-to-peer network)
Pruned node (full validation, partial storage):
- Same initial download and full validation as a full node
- Discards block data after validation, keeping only recent blocks (~550 blocks by default = ~1 GB of recent block data)
- Maintains the full UTXO set
- Cannot serve historical queries beyond the pruned window
- Cannot fully serve other peers (can’t relay historical blocks)
- Disk footprint: ~10-15 GB total
SPV light client (header-only):
- Downloads only block headers (~70 MB for the entire chain through 2026)
- For each transaction of interest, requests a Merkle proof from a server (full node or specialized SPV server)
- Verifies the Merkle proof and the chain of headers
- Relies on the longest-chain rule for finality
- Does NOT validate consensus rules — relies on miners and full nodes enforcing them
- Cannot detect: invalid transactions miners might include (e.g., over-issuance); witness-data-related failures; consensus violations not reflected in the headers
Compact block filter clients (BIP-157/158):
- Downloads block headers + compact filters (each filter is a ~100 KB Bloom-filter-like structure summarizing which addresses appear in a block)
- For each address of interest, the client checks the filter locally to determine if that address appears in a block
- If the filter indicates a match, requests the full block (or specific transactions) for verification
- Better privacy than BIP-37 SPV: the server doesn’t see which addresses the client is interested in
The trust models
Full node trust model:
- Trusts the cryptographic primitives (SHA-256, secp256k1) — see Public key cryptography and SHA-256
- Trusts the soundness of its own Bitcoin Core implementation
- Does NOT trust any other node — fully verifies everything
- Does NOT trust the longest chain claim — verifies it has the most cumulative work itself
This is the maximal-sovereignty trust model. A full-node operator’s reality is constructed from cryptographic verification, not from social or organizational trust.
Pruned node trust model:
- Same as full node, with the additional assumption that recent blocks (post-prune-point) are sufficient for ongoing operation
- Trades disk for nothing — both have identical validation guarantees
SPV light client trust model:
- Trusts the cryptographic primitives
- Trusts the longest chain (a chain with most cumulative work is canonical)
- Trusts that miners enforce consensus rules — does not independently verify
- Trusts the specific SPV server it queries (for inclusion proofs); attacks on SPV servers can deceive the client
- May trust the wallet vendor for software integrity
This is a substantially weaker model. An attacker controlling enough hashrate (51%+) could in principle produce a chain that violates consensus (e.g., over-issues BTC) and SPV clients would accept it. Real-world attack feasibility depends on the cost of compromising the relevant hashrate (see Consensus-layer attack theories in Criticisms).
The historical concern: at the start of the Block Size Wars - History, some argued that SPV clients (and light wallets generally) inadequately enforce Bitcoin’s economic policy — that a soft-fork-style consensus change could be ignored by SPV clients because they don’t see the relevant validation rules. The substantive engagement on this is in Block Size Wars - History (History section).
Resource requirements
Approximate values as of 2026:
| Resource | Full node | Pruned node | SPV |
|---|---|---|---|
| Initial download | ~750 GB | ~750 GB (then prune) | ~70 MB |
| Steady-state storage | 750-850 GB | 10-15 GB | < 1 GB |
| Bandwidth (month) | 50-200 GB | 50-200 GB | 1-5 GB |
| CPU (validation) | Substantial during IBD; modest thereafter | Same | Minimal |
| Memory | 4-8 GB recommended | 2-4 GB | < 100 MB |
The initial-block-download (IBD) phase is the heaviest — downloading and validating the full chain since 2009 takes 1-3 days on consumer hardware. Ongoing operation after IBD is much lighter.
Trust + assumed-UTXO snapshots. The assumeUTXO feature — shipped in Bitcoin Core 28.0 (2024) — lets a new node bootstrap from a recent UTXO snapshot rather than performing full IBD, becoming usable within minutes while it validates the historical chain in the background. This trades some trust (in the snapshot’s correctness, cross-checked as background validation completes) for faster setup. It is available but not the default; sovereignty-maximizing operators still do full IBD from genesis.
Bandwidth on consumer connections. A relaying full node uses substantial bandwidth — most of it is uploading blocks and transactions to peers. Block-relay-only nodes (BIP-152 with relay-only flag) substantially reduce upload bandwidth while preserving validation.
Privacy implications
Full node privacy: Best of the three. The node fetches all blocks from the network and validates them locally; it doesn’t reveal which transactions it cares about to any third party. Wallet queries against the local node leak nothing externally.
Pruned node privacy: Same as full node for ongoing queries; the pruning is invisible externally.
SPV privacy (BIP-37 historical): Poor. The client tells servers which addresses to check via Bloom filters; the servers can infer the address set with reasonable accuracy. This is a long-known privacy weakness — Bloom filters provide weak deniability at best.
Compact block filter privacy (BIP-157/158): Much better. The server doesn’t know which addresses the client cares about; the client downloads filters and computes matches locally. The client only requests full blocks when filters indicate a match, which leaks block-level (not address-level) information.
Tor and onion-routing. Both full nodes and SPV clients can route p2p connections through Tor for network-level privacy. Onion-service-only full nodes provide maximal network privacy at the cost of bandwidth and connection reliability.
For substantive operational privacy treatment, see KYC leakage and Address reuse and chain analysis (Privacy practice).
When to use which
Use a full node when:
- You hold substantial Bitcoin and want to enforce consensus yourself
- You want maximum privacy
- You can afford the storage, bandwidth, and operational complexity
- You’re running services for others (mining pool, Lightning routing, exchange)
Use a pruned node when:
- You want full validation but have storage constraints
- You don’t need historical query capability beyond recent blocks
- You’re running on a Raspberry Pi or low-disk environment (e.g., Umbrel, Start9, Raspiblitz hardware)
Use a compact-block-filter light client when:
- You’re on a mobile device (phone, tablet)
- You want better-than-BIP-37 privacy
- You’re willing to trust the longest chain plus miners’ rule enforcement
- Examples: BlueWallet, Phoenix Wallet, Sparrow with filters mode
Use a custodial wallet only when:
- The amounts are small and the convenience matters more than self-sovereignty
- You’re a beginner taking the first step into Bitcoin (and plan to migrate to self-custody soon)
- The service provides additional capabilities you specifically need (yield, swaps) — accepting the custodial trade-off knowingly
For substantive operational guidance, see Self-custody configuration ladder and Threat modeling for self-custody.
Tradeoffs and design choices
Why SPV works at all. Satoshi designed SPV from the start (section 8 of the whitepaper). The structural argument: light clients can verify Proof of Work (cumulative-work chain selection) without full validation, which is “good enough” if you assume miners are honest. The trade-off is real; the SPV trust model is weaker than full validation.
The pruning trade-off. Pruning was added in 2015 (Bitcoin Core 0.11) to address growing chain size. Pruned nodes preserve full validation guarantees while shedding storage. The cost is the inability to serve historical queries — pruned nodes can’t be the canonical archive for the network. The general assumption is that a sufficient number of full nodes will continue to exist to serve historical queries; pruned nodes coexist as the more lightweight option.
The “majority of nodes should be archival” question. Bitcoin’s network resilience depends on having sufficient archival nodes that historical data is recoverable. If everyone pruned, the chain history could be lost. Empirically, archive nodes are abundant (operated by exchanges, block explorers, large operators); pruning is safe to choose for individual operators.
BIP-37 vs BIP-157/158 trade-off. BIP-37 (2012) was the original SPV mechanism. BIP-157/158 (2018) is the modern replacement with better privacy and better matching efficiency. The Bitcoin Core BIP-37 server has been deprecated; only specialized infrastructure serves it now. Most modern wallets use BIP-157/158 or alternative private-query mechanisms.
UTXO snapshots and assumed-state. Several proposals (UTREEXO, assumeUTXO) allow new nodes to start from a recent state without full IBD. This shifts the trust model slightly — the operator trusts the snapshot rather than independently verifying from genesis. The general assumption is that this trust is acceptable for casual users; sovereignty-maximizing operators continue to do full IBD.
For substantive engagement with the consensus-enforcement and economic-node concerns that motivate running a full node, see Protocol-evolution constraints (Criticisms) and Block Size Wars - History (History).
Open questions for further development
- How will the long-run chain-size growth affect full-node operability? At 750+ GB in 2026 with continuing growth, the trend is sustainable on consumer SSDs but not indefinitely. UTREEXO and similar accumulators may become operationally necessary.
- Should the BIP-37 SPV mechanism be formally deprecated network-wide? Most modern wallets have moved off it; remaining usage is small.
- What’s the right operational practice for verifying that an SPV server isn’t lying? Cross-checking against multiple servers is a partial mitigation; running your own full node is the complete solution.
- How does Lightning Network operation interact with node choice? Lightning nodes need certain on-chain visibility; SPV is generally not sufficient.
Canonical sources for this note
Bitcoin engineering references
- Mastering Bitcoin, Andreas Antonopoulos (chapter 8: “The Bitcoin Network”, chapter 12: “Mining and Consensus”) — canonical engineering treatment. See Mastering Bitcoin - Andreas Antonopoulos.
- Programming Bitcoin, Jimmy Song (chapter 10: “Networking”, chapter 11: “Simplified Payment Verification”) — working-programmer treatment.
Bitcoin Improvement Proposals
- BIP-37 — original SPV with bloom filters (Mike Hearn et al.). Deprecated.
- BIP-152 — Compact block relay (used by full nodes).
- BIP-157 / BIP-158 — Compact block filters (modern light-client architecture).
Foundational sources
- The Bitcoin whitepaper, section 8 (“Simplified Payment Verification”) — Nakamoto’s original SPV specification. See The Bitcoin whitepaper - Explainer.
Related notes
- The peer-to-peer network — How nodes connect; full and pruned nodes are network peers; SPV clients are usually clients of full nodes.
- Blocks and the blockchain — Block structure that nodes validate.
- Consensus rules — Rules full nodes enforce.
- Merkle trees — SPV’s inclusion-proof mechanism uses Merkle trees.
- UTXO model and Bitcoin transactions — UTXO set is what full nodes maintain.
- Self-custody configuration ladder — Operational treatment of node choice. Self-custody.
- Running a full node — Practical guidance on operating a full node. Self-custody.
- Node hardware options — Hardware platforms for running nodes (Umbrel, Start9, etc.). Self-custody.
- Connecting wallets to your own node — Operational practice of pointing your wallet at your own node. Self-custody.
- Threat modeling for self-custody — Includes the trust-model considerations for SPV vs full nodes. Self-custody.
- Consensus-layer attack theories — Attack scenarios that distinguish trust models. Criticisms section.
- Block Size Wars - History — Historical example of where node-level consensus enforcement mattered. History section.