Blockchain Pruning

What Is Blockchain Pruning?

Blockchain pruning is a storage optimization in Bitcoin Core that allows a fully validating node to delete old block and undo data from disk after that data has been processed. The node still downloads and validates every block since the genesis block, enforcing all consensus rules, but it discards the raw data once it has updated the UTXO set and block index.

The Bitcoin blockchain exceeds 700 GB as of 2026 and grows by roughly 1 GB every few days. For users running nodes on consumer hardware, laptops, or low-storage devices, storing the full chain is increasingly impractical. Pruning was introduced in Bitcoin Core 0.11.0 (July 2015) specifically to address this barrier, making it possible to run a fully validating node with minimal disk space.

A common misconception is that pruning weakens security. It does not. A pruned node performs the same validation as an archival node during initial block download: verifying proof-of-work, checking every transaction against consensus rules, and building the complete UTXO set. The only difference is what happens after validation: the raw block files are deleted.

How It Works

Pruning operates on the raw block storage files that Bitcoin Core writes to disk. Understanding the process requires knowing what data a node stores:

• Block files (blk*.dat): serialized block data as received from the network
• Undo files (rev*.dat): data needed to reverse blocks during chain reorganizations
• Block index (LevelDB): metadata about every block including headers, chain work, and file positions
• Chainstate (LevelDB): the complete UTXO set, tracking every unspent output

When pruning is enabled, the node follows this sequence during sync and normal operation:

1. Download a block from peers
2. Validate the block fully: check block header, verify proof-of-work, validate every transaction, enforce all consensus rules
3. Update the UTXO set by applying the block's transactions
4. Write the block and undo data to disk
5. Once disk usage exceeds the prune target, delete the oldest block and undo files while keeping at least the most recent 288 blocks (roughly two days of blocks)

The 288-block minimum is defined by BIP 159, which also introduces the NODE_NETWORK_LIMITED service bit. Pruned nodes signal this bit to peers, indicating they can serve only recent blocks rather than the full chain history.

What Is Retained

After pruning, the node still holds:

• The complete UTXO set: every unspent transaction output, identical to an archival node
• All block headers and the full block index
• The most recent 288 blocks of raw data, available for serving to peers and handling chain reorganizations

What Is Discarded

Pruning removes:

• Old block files (blk*.dat): the raw serialized block data
• Old undo files (rev*.dat): reversal data for disconnecting blocks

Configuration

Pruning is controlled by the prune parameter in bitcoin.conf or via the command line:

# bitcoin.conf

# Disable pruning (default): store the full blockchain
prune=0

# Automatic pruning: set target in MiB (minimum 550)
prune=550

# Manual pruning: prune on demand via RPC
prune=1

The minimum value of 550 MiB was chosen to ensure the node always retains at least 288 blocks on disk. In practice, actual disk usage may briefly exceed the target to maintain this minimum.

Manual pruning mode (prune=1), introduced in Bitcoin Core 0.14.0, allows operators to prune blocks on demand using the pruneblockchain RPC:

# Prune all blocks up to height 800000
bitcoin-cli pruneblockchain 800000

This gives operators fine-grained control over which blocks to keep, useful for archiving specific historical ranges while pruning the rest.

Pruning and Initial Block Download

During initial block download (IBD), a pruned node downloads and validates the entire blockchain from genesis, just like an unpruned node. The IBD process is identical in terms of validation: every block is checked, every transaction is verified, and the UTXO set is built incrementally.

The difference is that old block files are deleted as the sync progresses. Bitcoin Core aggressively prunes all eligible files at once rather than deleting one at a time, because each pruning event triggers a flush of the in-memory UTXO cache (-dbcache) to disk. Fewer flushes mean faster sync times.

A pruned node may temporarily use more disk space during IBD than the final pruned size, since blocks accumulate between pruning events and the UTXO cache consumes memory that gets flushed to disk periodically.

Use Cases

Running a Node on Limited Hardware

The most common use case for pruning is running a fully validating Bitcoin node on hardware with limited storage. A Raspberry Pi with a 32 GB SD card, an old laptop, or a cloud VPS with minimal disk allocation can all run a pruned node. Without pruning, these setups would require 700+ GB of storage.

Desktop Wallets with Full Validation

Users who want self-custodial wallets with full validation (rather than trusting a third-party server) can run a pruned node alongside their wallet software. Bitcoin Core's built-in wallet has supported pruned mode since version 0.12.0, giving users the security of full validation without dedicating a terabyte of disk space.

Network Decentralization

By lowering the hardware requirements to run a full node, pruning contributes to Bitcoin's decentralization. More users validating their own transactions means fewer users trusting third-party nodes, strengthening the network's censorship resistance and trustless verification properties.

Why It Matters

Bitcoin's security model depends on users running their own full nodes to verify transactions independently. As the blockchain grows, the cost of running a full node increases. Pruning directly addresses this by keeping the disk requirement manageable regardless of how large the total chain becomes.

For layer-2 solutions like the Spark protocol and the Lightning Network, the ability to run lightweight full nodes matters. Users interacting with off-chain protocols still benefit from verifying on-chain state independently. A pruned node provides that verification without the storage overhead.

The distinction between a pruned node and a light client (SPV) is important: SPV clients trust miners to produce valid blocks, while pruned nodes verify everything themselves. Pruning achieves most of the storage savings of SPV without any of the trust assumptions.

Risks and Considerations

Cannot Serve Historical Blocks

A pruned node cannot relay old blocks to peers syncing the chain. The Bitcoin network depends on archival nodes to serve historical data. If too many nodes prune, new nodes joining the network may struggle to find peers with the blocks they need during IBD. In practice, enough archival nodes exist today, but this is a collective action concern.

No Wallet Rescan for Imported Keys

Importing a private key or watch-only address into a pruned node will not discover historical transactions. The RPCs importwallet, importaddress, and importprivkey are disabled in pruned mode because the historical blocks needed to find past transactions have been deleted.

Bitcoin Core developers are working on solutions to re-fetch pruned blocks from peers on demand, but this remains a limitation for most users.

Incompatible with Transaction Index

The -txindex flag, which builds an index of all transactions for fast lookup via getrawtransaction, requires full block data. Pruning and transaction indexing are mutually exclusive. Applications that need to query arbitrary historical transactions (block explorers, analytics tools) must run unpruned nodes.

Irreversible Without Re-download

Once blocks are pruned, the only way to recover them is to re-download the entire blockchain from the network using the -reindex flag. This means switching from pruned to unpruned mode requires a full resync, which can take hours or days depending on hardware and network conditions.

UTXO Set Growth

Pruning does not reduce the size of the UTXO set, which is stored separately and continues to grow over time. As of 2025, the UTXO set exceeds 11 GB. Even with pruning, nodes must store the full UTXO set to validate new transactions. This represents the true minimum storage requirement that pruning cannot reduce.

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.