Bitcoin Core 0.12 Pruning: Wallet Operation and Recovery Limits

This guide explains Bitcoin Core pruning in plain English. It summarises the important changes, who they affect and what should be checked before an upgrade.

What pruning removes

After a node validates blocks, it can delete sufficiently old blk and rev files while retaining chainstate and block-index information needed for current validation. A safety window near the tip remains. The target is approximate because files are removed in chunks and temporary usage can exceed the configured amount.

The 0.12 wallet milestone

Core 0.12 allowed wallet functionality with pruning, removing an earlier incompatibility. The release notes also warned that rescans beyond retained data were not available. The article date therefore marks wallet support in pruned mode, not the invention of pruning, and operational claims must remain scoped to that release.

Rescans and key recovery

Importing an old key, descriptor or wallet birthday may require historical blocks no longer stored. The node cannot reconstruct relevant transactions from chainstate alone. Recovery may require redownloading and revalidating history on a separate unpruned node. Backups must preserve keys and metadata; pruning is not a wallet-backup strategy.

Indexes and services

Transaction indexing and other features have version-specific compatibility with pruning. Historical block serving, explorers and audit tools may require full files. Inventory every consumer before enabling it. A node that validates the tip correctly can still be unsuitable for an application expecting arbitrary historical reads.

Mining and pool design

A pruned validator can follow the chain and support mining under suitable software, but pool operations may need historical data for investigation, payout evidence or customer support. Keep those retention requirements explicit and separate from consensus validation. Failover nodes should not all share the same reduced recovery capability by accident.

Changing mode and capacity

Increasing the prune target does not restore blocks already deleted. Returning to an unpruned state historically required reindexing and obtaining the missing data. Plan peak storage for that transition, including block files, undo data, indexes and chainstate. Treat disablement as a rebuild, not a quick Boolean rollback.

Recovery rehearsal

On an isolated copy, enable pruning, allow deletion, restart and verify chain and wallet operation. Attempt a rescan whose birthday predates retained data and record the failure. Rebuild an unpruned replacement from trusted software and network validation, then prove applications switch without overwriting newer wallet state.

Conclusion

Core 0.12 made wallet use possible on pruned nodes, but it did not remove historical-data dependencies. Enable pruning only with a tested rescan, rebuild and recovery design that preserves keys and application evidence.