A Pruned Node is a Full Node that checks Bitcoin’s rules for itself without keeping every old block permanently. It saves disk space at the cost of more limited access to history. It does not subtract from your bitcoins or replace a wallet backup.
Anna wants to use Bitcoin without relying on someone else’s server to decide whether payments are valid. Her home computer does not have room for a complete archive of blocks, the batches of confirmed transactions. A Pruned Node may suit her. During ordinary Initial Block Download, the node’s first synchronization, it downloads and verifies history in sequence, then removes older processed files. It does not need the whole history on disk at once, but it still has to work through that history during this synchronization. [2] [5]
Pruning is the controlled removal of old data. Bitcoin Core removes eligible block files and their associated undo data, which allow changes made by a block to be reversed. Think of putting away old working papers after incorporating them into an ongoing record. The local supporting documents disappear, but the effects of valid payments remain. Other nodes can still keep those same blocks. [3] [7]
The UTXO set is crucial: it contains transaction outputs that have not yet been spent. Each output records an amount and the conditions for spending it. By updating this set, the node can detect an attempt to spend an output that has already been spent. It also keeps a block index including headers, the short records that link blocks together. The UTXO set is neither a list of accounts nor a record of every past payment. [2] [6]
The network can briefly follow two valid branches and later continue along a different branch with more accumulated work. This change is called a reorganization. Accumulated work measures the difficulty of finding valid blocks, as represented by their Proof of Work, or proof of computational effort. The node must undo the effects of some blocks, so it retains a reserve of recent blocks and undo data. Going back beyond that retained history could require obtaining data again or rebuilding state. A disk setting does not make old payments absolutely irreversible. [5] [7]
Bitcoin Core’s automatic pruning target covers block and undo files, not the node’s entire data directory. Databases, wallets and other files need space too. Removal happens in whole files and must respect the required reserve, so the target is not a hard ceiling. Allow room for this overhead when choosing a disk; the archive limit is not the total size of the node. [1] [4] [7]
Full in Full Node refers to checking the rules yourself, not a duty to store every block forever. Archival and pruned nodes with the same validation settings reject the same invalid blocks. Pruning itself disables no checks. A digital signature provides proof of authorization for a payment using a private key, a secret numerical value, without revealing that key. For example, assumevalid, a setting that can skip some historical signature verification under specific conditions, is separate. It can apply to either type of node and is not a consequence of a smaller disk. [5] [6]
Anna’s node still receives, checks and can relay new transactions and available blocks. It cannot send an old block whose file it has removed. Operators of complete archives therefore also matter to newly started nodes. A Pruned Node is neither disconnected from the network nor merely a lightweight wallet relying on someone else’s validation; its historical data service is more limited. [10]
Anna later restores a wallet she used years ago. A wallet is an application or device for receiving and sending bitcoin. To find her transactions again, the software searches the relevant blocks; this is called a rescan. If those blocks are missing locally, importing a key or a descriptor, a description of how addresses and spending conditions are constructed, does not bring them back. Recovery may then require obtaining history again. A missing old payment in the display does not by itself mean the bitcoins are lost. [8] [9]
The applications connected to your node also matter. A complete history explorer has different needs from a wallet tracking new payments. For example, Bitcoin Core v29.0 does not allow pruning alongside txindex, an auxiliary index for finding transactions in stored blocks. This is not a ban on every index. Check your application’s requirements before choosing a mode; increasing the limit later does not recreate deleted files. [1]
A Pruned Node makes sense if you want to verify Bitcoin yourself without constantly searching the entire archive. It does not eliminate the ordinary initial history download; AssumeUTXO uses a different mechanism to make a node usable sooner. Above all, neither blocks nor the UTXO set back up the private keys that authorize spending. A wallet backup and a tested recovery procedure remain necessary whatever the archive size. [2] [9]
For the clearest picture, read this entry together with Initial Block Download, AssumeUTXO, Block Propagation, vByte, Bitcoin, Bitcoin Core. The reverse links also lead from Initial Block Download, AssumeUTXO, Utreexo, Compact Block Filters.