Pruned and full Bitcoin nodes differ in the amount of blockchain data they store. A full node stores the entire blockchain, which includes every transaction that has ever occurred on the Bitcoin network. In contrast, a pruned node only stores a subset of the blockchain, which is beneficial for users with limited storage capacity who don't need to retain the full chain history after validation.
TL;DR: Run a pruned node when storage is the constraint, run an archival node when serving historical blocks, rescanning a wallet from before today, or running an indexer is part of the plan. Consensus validation is identical either way; the difference is what gets kept on disk after a block is verified.
What "Full" and "Pruned" Mean
An archival node keeps the entire blockchain on disk: every block from the genesis block forward, plus the Unspent Transaction Output (UTXO) set and any local indexes. An archival node can answer any historical query, serve any block to peers, and rescan a wallet for transactions at any point in chain history.
A pruned node runs the same validation on every block, then deletes the raw block and undo data once those blocks are no longer needed to keep up with the tip. The Bitcoin Core configuration setting -prune=N tells the node how many megabytes of raw block and undo data to keep before deletion begins. The minimum allowed value is 550, which is enough to retain the last 288 blocks, roughly two days at the protocol's 600-second block target. (Bitcoin Core 0.11 release notes)
Pruning controls disk storage, not which validation checks run. A pruned node still downloads every block during Initial Block Download (IBD), checks every signature, executes every script, and updates the UTXO set. The block data is discarded after validation; the consensus state derived from it remains.
Storage and Disk Math
Archival nodes store ~742 GB of chain data as of May 2026, with growth on the order of tens of gigabytes per year. That excludes the chainstate database, mempool data, and optional indexes such as -txindex or -coinstatsindex, which add tens of gigabytes on a fully-indexed node.
A pruned node configured at prune=550 typically uses roughly 9 to 11 GB total on disk in 2026: the 550 MB block floor, the chainstate database (currently around 8 to 10 GB and growing), and a small amount for the mempool, peer information, and logs. The exact footprint depends on the chainstate size at the time of sync.
Setting prune higher retains more history. prune=10000 keeps roughly 10 GB of recent blocks, enough to answer peer requests during short reorgs and support most light-client connections without refetching.
What a Pruned Node Loses
Once raw block data is deleted, three categories of functionality become unavailable on the local node.
Serving historical blocks beyond the pruned floor. Peers requesting old blocks the node no longer stores fetch them from an archival peer instead. BIP 159 defines the NODE_NETWORK_LIMITED service bit (0x400) that pruned nodes use to advertise this limitation: a node setting this bit guarantees at least the last 288 blocks but does not claim to serve the full chain. (BIP 159)
Wallet rescan from before the pruned floor. Adding a watch-only address or importing a private key with historical transactions requires walking the chain back to find them. A pruned node only rescans within its retained window; wallets that need to scan further require an archival node or an external indexer.
Transaction indexing. The -txindex option, which builds a database mapping every transaction ID to its position on disk, is incompatible with pruning; Bitcoin Core will refuse to start if both -prune and -txindex are set, so the operator must choose one. Block explorers and the getrawtransaction Remote Procedure Call (RPC) on arbitrary transactions need an archival node with -txindex=1.
Indexers such as Electrum servers and Esplora depend on archival storage and typically -txindex; a pruned node cannot back them. A public node-backed reference such as Blockstream Explorer covers the occasional historical-transaction lookup without running an archival node locally.
What a Pruned Node Keeps
A pruned node performs every function the Bitcoin protocol requires of a node.
Full consensus validation. Every block is checked against every consensus rule: proof of work, transaction signatures (Elliptic Curve Digital Signature Algorithm and Schnorr), script execution, double-spend prevention, fee rules, witness data, soft-fork activation. Validation depends on having the UTXO set, which a pruned node keeps, not on retaining block history.
UTXO state. The UTXO set is the working memory of the Bitcoin network. A pruned node maintains it in full, which is what lets the node validate the next block.
Mempool participation. Incoming unconfirmed transactions enter the local mempool the same way they do on an archival node. Fee estimation, replace-by-fee handling, and relay policy work identically.
Block and transaction relay. A pruned node relays new transactions and new blocks to its peers. The NODE_NETWORK_LIMITED service bit lets peers know this node can serve at least the last 288 recent blocks but not the deep historical chain. A pruned node listening on port 8333 contributes to the network's block-relay topology for any block within its retained window. (BIP 159)
Independent verification. The reason to run a node at all is to verify the rules of the Bitcoin network without trusting anyone else's word for them. Pruned nodes provide that verification with the same authority as archival nodes.
AssumeUTXO: A Fast Bootstrap Option
AssumeUTXO is a separate feature that pairs naturally with pruning for operators who want to come online quickly. Bitcoin Core 28.0 added mainnet parameters for the loadtxoutset RPC at block height 840,000, which lets a new node load a UTXO snapshot at that height and begin tracking the tip immediately, while the background validation of all earlier blocks continues in parallel. (Bitcoin Core 28.0 release notes)
The node does not skip validation. It validates in two passes: a forward pass from the snapshot to the tip, and a background pass from the snapshot back to genesis. Until both complete, certain operations (full chainstate queries, some RPCs) are limited. Once the background sync finishes, the node has a fully validated chain, the same as an IBD-from-genesis node.
AssumeUTXO helps most on slow connections or older hardware where a fresh IBD would take days. Paired with pruning, the node reaches the network within hours on hardware that would otherwise be a non-starter.
Bitcoin Node Requirements: Hardware Floors for Each Setup
Archival node. A modern Solid-State Drive (SSD) is strongly recommended. IBD on a hard disk drive hits write-pattern bottlenecks that stretch the sync from hours to weeks. Memory: 4 GB minimum, 8 GB comfortable, 16 GB recommended for nodes running indexes or wallet services. Bandwidth: archival nodes serving historical blocks see steady upload to peers, so an unmetered or generous-cap connection is the baseline. Plan at least 1 TB of storage for chain growth and optional indexes.
Pruned node. Pruning lowers hardware floors sharply. A Raspberry Pi 4 or 5 with an SSD over USB 3 runs a pruned node comfortably, and single-board computers and low-cost cloud instances become viable. Storage drops to single-digit gigabytes for the chain data plus the chainstate (currently around 8 GB and growing). Memory: 2 GB minimum, 4 GB comfortable.
For both: an SSD remains the right choice even when storage size is small. UTXO updates and chainstate flushes are random-access workloads that punish HDDs and reward SSDs.
When to Pick Which
Pick pruned when:
- Storage budget is the binding constraint.
- The goal is independent validation, mempool participation, and relay.
- The node will run on a Raspberry Pi, a small VPS, or other low-disk hardware.
- No plan exists to run an indexer, Electrum server, or block explorer locally.
- No plan exists to rescan wallets from arbitrary historical heights.
Pick archival when:
- Disk is not the constraint and ~1 TB is available.
- The node will back an Electrum server, Esplora, a block explorer, or another service that needs full block history.
- Wallet rescans for arbitrary heights are part of the workflow.
- The operator wants to contribute archival capacity to peers performing IBD.
- A future option to enable -txindex matters.
For most users running a node to verify their own transactions and support decentralization, pruned is the practical default. Archival is the right choice when serving the chain to others or running adjacent services is the goal.
Wallet Implications
The Bitcoin Core built-in wallet runs on a pruned node, with one constraint: rescans only reach back as far as the pruned floor. Creating a new wallet from a fresh recovery phrase that has never received bitcoin works fine. Importing a hierarchical deterministic seed with transactions older than the pruned window does not, because the block data needed to find them has been deleted.
Wallets that talk to the node over RPC (Sparrow, Specter) work over either pruned or archival, with the same rescan caveat. For wallets that need broad rescans, point them at an archival node or an indexer such as Esplora. For signing, a hardware signer such as Blockstream Jade pairs with the node so keys stay offline while the node supplies the chain data. The Blockstream app works as a self-custodial companion wallet on mobile and desktop.
For most self-custodial setups where the wallet was created on the node and has only seen transactions since it came online, the pruned-rescan limitation does not bite.
Operational Notes for Operators
Changing the prune setting after IBD. Raising the prune value (keeping more history) takes effect on the next start; the node will retain newly downloaded blocks up to the new ceiling. Lowering the prune value triggers additional deletion on the next flush. Switching between two pruned settings does not require resync.
Switching from pruned to archival. This requires a full re-download. Pruning is one-way locally: deleted blocks are gone from the local store, and the node must refetch them from peers to rebuild the archive. Plan a fresh IBD if archival mode is needed later.
Enabling -txindex on an existing archival node. This triggers a one-time index build at startup, which walks the existing block files. It is not a re-IBD, but it can take several hours.
Listening port. Pruned nodes should listen on port 8333 (listen=1 in bitcoin.conf) to relay blocks and transactions to peers. Pruning does not change listening behavior; the NODE_NETWORK_LIMITED service bit announces the storage limitation and peers handle the rest.
Reindex. If chain data becomes corrupted, -reindex rebuilds the chainstate from existing block files on an archival node. On a pruned node, -reindex-chainstate is not available at all: Bitcoin Core refuses the combination and tells you to use a full -reindex instead, which means re-downloading the blocks that were pruned away.
Caveats and Tunable Settings
The 550 MB floor is the minimum, not a recommendation. Setting prune=10000 (10 GB) or higher gives the node more retained history without coming close to archival storage.
The chainstate database grows as the UTXO set grows. A pruned node that fit in 5 GB total in 2024 may need 8 to 10 GB in 2026 for the chainstate alone, so plan storage with margin.
Pruning is independent of network privacy. Running a pruned node over Tor (onlynet=onion in bitcoin.conf) works the same as running an archival node over Tor.
A pruned node cannot validate a chain reorg deeper than its retained window. Mainnet reorgs longer than a handful of blocks are vanishingly rare, so this is a theoretical edge case.
Frequently Asked Questions
Does a pruned node validate the same rules as a full node?
Yes. A pruned Bitcoin Core node runs the same consensus checks (proof of work, signature verification, script execution, UTXO updates, soft-fork activation) as an archival node and reaches the same accept-or-reject decision on every block. Pruning controls disk storage only; validation is identical.
Can a pruned node serve blocks to other nodes?
Yes, within its retained window. BIP 159 defines the NODE_NETWORK_LIMITED service bit (0x400). A pruned node serves at least the last 288 blocks and advertises this capability to peers, so peers asking for older blocks can route to archival nodes instead. BIP 159 also recommends that a connecting peer account for a 144-block safety buffer for chain reorganizations, treating only roughly the most recent 144 of those blocks as reliably available. (BIP 159)
How do I switch from pruned back to archival?
Stop the node, remove the prune setting from bitcoin.conf, and restart with a fresh data directory or after clearing the existing chain. The node will perform a full IBD from genesis. There is no in-place upgrade from pruned to archival; the deleted blocks must be re-fetched.
Can I run a wallet on a pruned node?
Yes, with one limitation. The Bitcoin Core built-in wallet, and external wallets that talk to the node over RPC, operate normally on a pruned node for transactions seen after the node came online. Rescanning for transactions older than the pruned window is not possible without an archival node or an external indexer.
What is the smallest practical prune setting?
prune=550 is the minimum allowed value. It allots 550 MB to raw block and undo data, which retains the last 288 blocks (~2 days at the 600-second block target). Most operators set higher values (1024 to 10000) for additional reorg headroom and peer relay coverage. (Bitcoin Core 0.11 release notes)
Does AssumeUTXO replace pruning?
No. AssumeUTXO is a fast-bootstrap mechanism: it loads a UTXO snapshot at a known height so the node can track the tip while background-validating earlier blocks. Pruning is a storage policy that discards old block data after validation. The two pair naturally, especially on low-disk hardware that wants to come online quickly. (Bitcoin Core 28.0 release notes)
Next Steps
Ready to set up a node? Walk through hardware and configuration choices in how do I set up and run a Bitcoin node. For background on what a node actually does, see what is a Bitcoin node and the broader types of Bitcoin nodes. For the reference implementation specifics, see what is Bitcoin Core.