Pruned Node
A Bitcoin full node that discards old block data after validation, significantly reducing storage requirements while maintaining full validation.
Key Takeaways
- A pruned node is a full Bitcoin node that validates every block from genesis, then discards old block data to save disk space. It enforces the same consensus rules as an archival node.
- Pruning reduces storage from over 700 GB to as little as 12 to 20 GB by retaining only the UTXO set, block headers, and the most recent 288 blocks.
- The tradeoff: pruned nodes cannot serve historical blocks to peers, cannot run a transaction index, and have limited wallet rescan capability. AssumeUTXO complements pruning by enabling near-instant startup.
What Is a Pruned Node?
A pruned node is a Bitcoin full node that downloads, validates, and then discards old block data to conserve disk space. Unlike a light client that skips validation, a pruned node processes every single block in Bitcoin's history: checking every signature, enforcing every consensus rule, and building the complete UTXO set. Once a block has been validated and its effects applied to the UTXO set, the raw block data is deleted from disk.
Pruning was introduced in Bitcoin Core v0.11.0 in July 2015. As the blockchain has grown beyond 700 GB, pruning has become increasingly important for users who want full validation without dedicating a terabyte of storage. A pruned node provides the same security guarantees as an archival node: it has independently verified every transaction in Bitcoin's history. The only difference is that it no longer holds the raw proof on disk.
How It Works
During initial block download (IBD), a pruned node behaves identically to an archival node. It downloads every block from the genesis block forward, validates each one against all consensus rules (script validation, signature verification, inflation schedule, difficulty adjustment), and updates the UTXO set accordingly.
The difference happens after validation. Once blocks are processed and the node accumulates more raw block data than the configured pruning target, the oldest block files (blk?????.dat) and their corresponding undo files (rev?????.dat) are automatically deleted. The node continues validating new blocks normally, always keeping the most recent data while trimming the oldest.
What Data Is Retained
A pruned node keeps everything it needs to validate future blocks and transactions:
- UTXO set (chainstate): the complete set of all unspent transaction outputs, approximately 11 GB as of 2026 containing roughly 173 million UTXOs
- Block index and headers: metadata for every block from genesis to the tip, allowing the node to understand the full chain structure without the raw block data
- Recent blocks: at minimum the most recent 288 blocks (roughly two days of blocks), ensuring the node can handle chain reorganizations
- Operational data: the mempool, peer database, and ban list
Storage Comparison
| Configuration | Approximate Size |
|---|---|
| Full archival node | 740+ GB (growing 60 to 80 GB per year) |
| Archival node with txindex | 800+ GB |
| Pruned node (prune=550, minimum) | 12 to 13 GB |
| Pruned node (prune=5000, typical) | 16 to 20 GB |
Configuration
Pruning is configured via the prune parameter in bitcoin.conf or as a command-line flag. The value specifies the target size in MiB (mebibytes) for raw block and undo data:
# bitcoin.conf
# Disable pruning (default): full archival node
prune=0
# Automatic pruning: keep ~5 GB of recent blocks
prune=5000
# Minimum automatic pruning: ~550 MiB of recent blocks
prune=550
# Manual pruning: blocks kept until explicitly pruned via RPC
prune=1The minimum value for automatic pruning is 550 MiB, chosen to guarantee at least 288 blocks remain on disk. Setting a value between 2 and 549 produces an error. Manual pruning mode (prune=1) retains all blocks until you explicitly call the pruneblockchain RPC:
# Prune all blocks up to height 850000
bitcoin-cli pruneblockchain 850000BIP 159 and Network Signaling
Since Bitcoin Core v0.16.0, pruned nodes signal NODE_NETWORK_LIMITED (defined in BIP 159) to the network. This tells peers the node can serve the last 288 blocks but not historical data. Pruned nodes deliberately do not reveal their exact prune depth to prevent fingerprinting. They still relay new transactions and blocks, contributing to network health even without serving the full chain history.
Pruned Node vs. SPV Client
Pruning is often confused with SPV (simplified payment verification) or light clients, but the security models are fundamentally different:
| Aspect | Pruned Node | SPV / Light Client |
|---|---|---|
| Validation | Full validation of every block and transaction | Validates block headers only; relies on Merkle proofs from full nodes |
| Trust model | Trustless: self-validates everything | Must trust that full nodes are honest |
| Data downloaded during sync | Entire blockchain (700+ GB), then discarded | Block headers only (~60 MB) |
| Disk usage | 12 to 20 GB typical | 50 to 100 MB |
| Security | Equivalent to a full archival node | Reduced: cannot independently detect invalid transactions |
The critical distinction: a pruned node has verified every single block in Bitcoin's history. It is a full node in every security-relevant sense. An SPV client has never validated full blocks and depends on honest full nodes for transaction verification. For a deeper comparison of node types, see the Bitcoin node implementation comparison.
Use Cases
Personal Verification on Limited Hardware
Pruning makes full validation accessible on devices with limited storage: older laptops, single-board computers like Raspberry Pi, or VPS instances with small disks. Users gain self-custodial verification without needing a dedicated server or external hard drive.
Wallet Backends
A pruned node works well as a personal wallet backend. It validates incoming transactions and blocks independently, providing the same security as an archival node for day-to-day wallet operations. The main limitation is wallet import: importing an extended public key with historical transactions requires the node to rescan blocks it may have already pruned.
Development and Testing
Developers running mainnet nodes for testing or monitoring benefit from pruning since it avoids dedicating hundreds of gigabytes to data they rarely query. For applications that only need to validate current state and recent transactions, pruning is sufficient.
AssumeUTXO: Complementary Optimization
AssumeUTXO is a complementary feature that addresses pruning's biggest friction point: the initial sync. Even with pruning enabled, a node must download and validate the entire 700+ GB blockchain before becoming usable, a process that can take days or weeks on modest hardware.
AssumeUTXO allows a node to load a serialized UTXO snapshot (roughly 3 to 4 GB) and immediately begin validating new blocks from that snapshot's height. The node becomes usable within minutes. In the background, it downloads and validates the full historical chain to independently verify the snapshot was correct.
When combined with pruning, assumeUTXO creates a powerful setup: near-instant startup with full validation and minimal storage. During the background validation phase, the prune budget is split between two chainstates, so a minimum of 1,100 MiB is recommended for the prune target. Bitcoin Core v28.0 shipped mainnet assumeUTXO parameters for block height 840,000.
Risks and Considerations
Cannot Serve Historical Blocks
Pruned nodes cannot provide old blocks to new nodes performing IBD. As of late 2025, approximately 8% of reachable Bitcoin nodes signal as pruned. If this percentage grows significantly, new nodes would have fewer peers to download historical data from, potentially slowing network bootstrapping. The current ratio is not considered problematic, but it is a long-term consideration as the blockchain continues to grow.
Limited Wallet Rescan
A pruned node can only rescan blocks it still has on disk. Importing an old wallet or recovering from a seed phrase with historical transactions may fail to find transactions in blocks that have been pruned. The Bitcoin Core community is actively working on a pruned node rescan project that would use compact block filters (BIP 158) to identify and re-download only the specific blocks containing relevant transactions.
No Transaction Index
The -txindex flag, which creates an index mapping every transaction ID to its block location, requires full block data and is incompatible with pruning. Applications that depend on looking up arbitrary historical transactions (block explorers, analytics tools) need archival nodes.
Reindexing Requires Re-download
If a pruned node's database becomes corrupted, running -reindex requires re-downloading the entire blockchain from the network since the original block data no longer exists on disk. This makes disaster recovery slower than for archival nodes, which can rebuild from their local copy.
Network Health Tradeoffs
Every pruned node is one fewer source of historical block data for the network. While pruned nodes still relay new transactions and blocks and serve recent blocks via NODE_NETWORK_LIMITED, the network depends on archival nodes for bootstrapping new participants. Running an archival node is a greater contribution to Bitcoin's decentralization, but running a pruned node is far better than running no node at all. Layer 2 protocols like Spark benefit from a healthy base layer with many validating nodes, whether archival or pruned.
This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.