Pruned Node

Pruned node is a Bitcoin full node that fully validates every block in the chain's history but then deletes old raw block files once they are no longer needed, keeping only the most recent blocks plus the complete UTXO set. The result gives you the same trust-minimized validation as an archival full node in a fraction of the disk space — often under 10 GB against the 600+ GB a full archive now demands. It is the configuration that keeps running your own validation practical on a Raspberry Pi, an old laptop, or a modest home server.

Same security, smaller footprint

The persistent misconception is that pruning weakens validation. It does not — not by one signature. During the initial block download, a pruned node fetches every block from genesis, verifies every signature, executes every script, and enforces every consensus rule, exactly as an archival node does. Only after a block has been fully validated and its outputs folded into the UTXO set does the node discard the raw block data. What remains — the UTXO set plus all block headers — is everything required to validate each new block as it arrives and to enforce the rules against miners and peers alike. Your node still independently confirms the chain is valid and watches your own coins without trusting anyone. Validation is about what you check, not what you keep.

The trade-offs, honestly

Pruning has real costs, and they are about serving history, not verifying it. A pruned node cannot serve old blocks to peers bootstrapping their own nodes, so it takes from the network's archive capacity without contributing to it — fine at the margin, a problem if everyone did it. It cannot rescan deep history for a newly imported wallet without re-downloading the chain, so import old keys before pruning or plan for a slow re-sync. Some software that needs arbitrary historical blocks — certain indexers and explorers — will not run against a pruned backend. And pruning offers zero speedup on the initial block download: every block is still fetched and verified before being discarded, so the first sync costs the same bandwidth and CPU as ever.

Configuration in practice

Pruning is enabled in Bitcoin Core with the prune setting, which takes a target size in mebibytes for the retained block files — the minimum is prune=550, and a comfortably larger value keeps more recent history around for reorg handling and wallet rescans over recent weeks. Everything else about node operation is unchanged: the node relays transactions, maintains a mempool, and serves your wallet exactly as before. One pairing worth knowing: a pruned node still supports compact block filters for light clients you control, but cannot retroactively build indexes that require the full chain, so decide your indexing needs before you prune, not after. On modest hardware the retained-block setting also bounds disk I/O nicely, and pairing a pruned configuration with a small SSD for the chainstate remains the classic budget node build.

Why it matters

Every barrier to running a node is a subsidy for trusted third parties, and disk space has historically been the barrier cited most. Pruning removes it almost entirely: the sovereignty of a full node — your rules, verified by your hardware — at a footprint any spare machine can afford. For most home operators the honest advice is simple: an archival node if you have the terabyte to spare and want to serve the network's history; a pruned node if you do not. Both validate everything. See our self-hosting resources for choosing and sizing the right setup.