Pruning is a storage optimization where a full node deletes old block data after validating it, keeping only the current state (account balances, UTXOs) and enough recent history to handle reorganizations. A pruned Bitcoin node needs only ~5-10 GB instead of ~550 GB, while still independently validating every transaction. The tradeoff: it cannot serve historical block data to other nodes.
What Is Pruning (Node Storage Mechanics)?
3 min read
The short version
Pruning is like reading and verifying a 500-page ledger cover to cover, then keeping only the final balance sheet and shredding the old pages. You still personally verified everything (so you trust the result), but you no longer have the old pages to show someone else. If they need the full history, they have to get it from a node that kept everything (an archival node).
How It Works
How it works on Bitcoin Core: (1) During initial sync, the node downloads and validates every block since 2009. (2) After validation, blocks older than the pruning threshold (configurable, minimum 550 MB of recent blocks) are deleted from disk. (3) The UTXO set (all current unspent outputs, ~5-8 GB) is always kept in full. (4) The node can still validate new blocks normally because it holds the current UTXO set. It just cannot go back and serve block #100,000 to a peer requesting it. On Ethereum: "pruning" is more complex because Ethereum has a full state tree. Geth's default mode (snap sync) does not store full historical state. An "archive node" keeps every historical state version (>15 TB) but most nodes only keep recent state plus enough to revert recent blocks. Pruned nodes are first-class participants: they validate, relay, and enforce consensus rules. They simply cannot help others sync from scratch or provide historical queries.
Running a pruned Bitcoin node on a $35 microSD card
You have a Raspberry Pi 4 with a 64GB microSD card. Full Bitcoin blockchain: 550+ GB (does not fit). With pruning set to 1,000 MB (prune=1000 in bitcoin.conf): (1) Initial sync still downloads and validates all 550 GB of blocks (this takes several days on a Pi). (2) Once validated, only the most recent 1,000 MB of blocks are kept on disk. Old blocks are deleted as new ones arrive. (3) Total storage used: ~8 GB (UTXO set + recent blocks + chainstate). Fits comfortably on your 64 GB card. (4) Your node fully validates every new block. You have the same security guarantees as a full archival node for your own transactions. (5) What you lose: you cannot help new nodes sync (cannot provide old blocks) and you cannot look up historical transactions from 2015. For personal use (verifying your own wallet), this tradeoff is often acceptable.
What People Get Wrong
Pruned nodes do not validate
They validate everything. Pruning is about storage after validation, not about skipping validation. A pruned node that synced from genesis has verified every transaction in Bitcoin history. It just does not keep the receipts afterward.
Pruned nodes are less secure
For the operator: identical security. You verified everything. For the network: pruned nodes cannot help bootstrap new peers (a slight reduction in network service capacity). But your personal security and ability to enforce consensus rules is unaffected.
You cannot run a wallet with a pruned node
You can. Bitcoin Core and other node software support wallet functionality on pruned nodes. The only limitation: you cannot rescan the full blockchain for old transactions already pruned. If you import old keys, you would need a full node (or re-download the relevant range) to find their history.
Keep Reading
Sources & Further Reading
- Bitcoin Core Reduce Storage
Official documentation on running Bitcoin Core in pruned mode
Questions People Also Ask
- How do I enable pruning on Bitcoin Core?
- Add prune=550 (minimum, in MB) to your bitcoin.conf file, or start with -prune=550 flag. Values represent how much block data to keep. Higher values keep more history but use more disk. 550 MB is the minimum allowed. You can set it during initial setup or switch to pruning mode later (requires re-download if upgrading from a full node that already stored everything).
- Can I switch from pruned to full later?
- Not without re-downloading the pruned blocks. If you delete old blocks, they are gone from your disk. To become a full archival node again, you would need to re-sync from scratch (or at least re-download the missing block range from peers).
- What is an archive node vs. a pruned node?
- Archive node: keeps everything (all blocks, all historical state). Needed for: block explorers, historical queries, serving the network. Pruned node: keeps only current state + recent blocks. Sufficient for: personal transaction verification, wallet operation, consensus participation. Most users need pruned at most; only service providers need archive.