A Bitcoin node can validate the chain while deleting older raw block files. The trade-off appears when a wallet later needs those files to reconstruct its history.
| What you need to know |
|---|
| Pruning deletes raw block and undo data after validation and database updates. |
| The block index retains metadata about blocks after their raw files are deleted. |
| The pruning target excludes storage needed for the block index and UTXO databases. |
| Bitcoin Core 30.0 refuses a wallet rescan that requires unavailable pruned blocks. |
A restored wallet meets a missing file
Imagine importing an old wallet into a node that is fully synchronized but has already pruned the relevant blocks. The node’s chain state can be current. The raw historical data needed for a wallet rescan can nevertheless be absent. Those conditions are compatible: synchronization and local historical-file availability measure different things.
Pruning is possible because validation builds databases from block data. Once the data has served that purpose, older raw blocks and their undo files can be removed within the pruning rules. The block index retains metadata, and the UTXO database retains the current unspent-output state. Neither is a complete replacement for the raw history a wallet scan may need.
The release notes introducing pruning explain this storage separation. Their wallet restrictions describe that historical release, not a blanket prohibition on using wallets with current pruned nodes. Reading an old release note as a current feature matrix would confuse the origin of the mechanism with today’s implementation.
The current boundary is more specific. The Bitcoin Core 30.0 wallet RPC implementation refuses a rescan range that requires unavailable pruned blocks. Metadata identifying a block does not supply the block contents that the scan must examine.
The target is not the whole data directory
A pruning target governs the block and undo files, not every byte Bitcoin Core stores. The index and UTXO databases need additional space. A small configured target is therefore not a promise that the entire node will fit within that number.
For a wallet recovery, the decisive detail is the historical range that must be scanned and whether the needed blocks are available. The rescanblockchain RPC documentation describes the requested scan range; it does not make deleted files reappear.
Pruning saves historical storage without turning validation into blind trust. What it gives up is immediate local access to some old raw data. A synchronized node can thus be working correctly even when it cannot carry out a particular old wallet rescan from the files it currently holds.
