TL;DR: The Bitcoin network has different types of nodes, each with varying tradeoffs. Full nodes store the entire blockchain and verify all transactions, and come with greater security and privacy for users by eliminating the need for third-party reliance. Pruned nodes, on the other hand, retain only a portion of the blockchain to save space, which limits their historical data access. Lightweight or Simplified Payment Verification (SPV) nodes, commonly found on mobile devices, fetch transaction data from other nodes and may pose potential trust issues. Mining nodes, paired with specialized mining hardware (ASICs), facilitate block creation and transaction ordering. While Bitcoin full nodes were originally primarily mining nodes, the rise in hashrate has made mining nodes a minority.
The Bitcoin network is a mesh of independent computers that exchange blocks and transactions over a peer-to-peer protocol. Each computer in that mesh runs node software, and the choice of software, configuration, and resources determines what kind of Bitcoin node it is. Before comparing the variants, it helps to be clear on what a Bitcoin node is and the role of a Bitcoin node on the network.
How Bitcoin Nodes Are Classified
Three independent axes describe any Bitcoin node. Most node types are combinations of choices along these three axes rather than entirely separate categories.
By What They Store
A node can keep the entire validated block history of the blockchain, prune old blocks after validating them, or skip block bodies entirely and rely on headers. Storage choice drives the most visible cost difference: a full archival node holds roughly 742 GB of block data as of mid-2026 (per blockchainsize.org), while a pruned node configured at the Bitcoin Core minimum holds only the unspent transaction output (UTXO) set, the chainstate indexes, and the most recent ~550 MB of blocks.
By What They Serve
A node can accept inbound peer connections and serve blocks, transactions, and filters to other nodes, or it can run in non-listening mode and only fetch data for its own wallet. The split matters for network health: every new node performing Initial Block Download (IBD) depends on listening archival nodes that hold the full historical chain.
By Who Runs Them
Node operators range from individual users running Bitcoin Core on a home server, to wallets embedding light-client logic in a phone app, to mining operations that assemble blocks for application-specific integrated circuit (ASIC) fleets. The same Bitcoin Core binary can play any of these roles depending on configuration.
Full Nodes
Full nodes are nodes that run a compatible version of the Bitcoin client software and store a full copy of the Bitcoin blockchain history. A full node handles all protocol aspects and can independently verify the entire blockchain and any transaction. By running a full node, Bitcoin users can protect their interests by validating consensus rules, ensuring miners follow suit. A full node also strengthens security by eliminating dependency on a third party and offers better privacy, since those users can connect to the network anonymously.
A full node independently verifies every consensus rule of the Bitcoin protocol without trusting any other party: that signatures are valid, that no bitcoin is spent twice, that block subsidies follow the halving schedule, that scripts evaluate correctly, and that proof-of-work meets the current difficulty target. The reference implementation is Bitcoin Core, maintained by an open-source contributor community. Compatible implementations include Bitcoin Knots, btcd, and libbitcoin.
Practical requirements as of mid-2026: a solid-state drive sized for the chain plus growth (roughly 1 TB for several years of headroom), 8 GB of RAM at a minimum (16 GB is more comfortable), and an internet connection capable of sustained downloads during initial sync. IBD on modern SSDs typically completes in hours to a day depending on bandwidth; older spinning disks can extend that to weeks because random-read latency dominates UTXO updates.
Pruned Nodes
Pruned nodes are nodes that hold only a truncated version of the blockchain in order to save storage space. How much a pruned node keeps is controlled by a parameter in the bitcoin.conf configuration file that defines the maximum number of bytes to use for blockchain data. Pruned nodes have some drawbacks, as they discard some historical data. For instance, they cannot be indexed for faster lookups, and they cannot fully recover wallets that received bitcoin during the time period that is now discarded, as those transactions simply are not there anymore.
The Bitcoin Core configuration option prune=N sets the target storage budget in megabytes, with prune=550 as the protocol minimum. After IBD, a pruned node retains the UTXO set, the chainstate indexes, and roughly the last 550 MB of recent blocks, while still validating every new block against the full ruleset. The validation guarantees are identical to a full archival node; only the historical-serving capability is reduced.
Pruned nodes that still relay at least the most recent 288 blocks (roughly two days) can signal the NODE_NETWORK_LIMITED service bit defined in BIP 159, letting other peers selectively request recent data without expecting the full archive. Pruned mode is the right configuration for node operators running on small SSDs or low-power hardware such as a Raspberry Pi. For the full set of trade-offs, see choosing between a full and a pruned node.
Archival Nodes
An archival node is a full node that keeps the complete block history forever and offers it to other peers. Every node that has not pruned its block data and is reachable on the public network qualifies as archival. The service bit advertised in the node's version handshake is NODE_NETWORK (bit 0), signalling to other peers that the node can serve any block at any height.
Archival nodes are load-bearing infrastructure for the network. They are what new full nodes connect to during IBD, and they are what wallets and explorers depend on for historical lookups. Blockstream Explorer and the open-source Esplora that powers it both run on full archival Bitcoin Core nodes for exactly this reason. The economic incentive to run one is intrinsic: operators who care about the long-term integrity of the chain run them so that future participants can independently verify history without trusting a centralized API.
Listening vs Non-Listening Nodes
The listening/non-listening distinction cuts across every other classification. A listening node accepts inbound peer connections on TCP port 8333 (the default Bitcoin P2P port) and actively serves blocks and transactions. A non-listening node still validates the chain for its own wallet but does not accept inbound peers, typically because it sits behind a network address translation (NAT) layer or a firewall that blocks unsolicited connections.
The distinction shows up in node counts: the roughly 23,000 reachable nodes that bitnodes.io reports include only listening nodes that bitnodes can reach via probing. The total population of non-listening clients (mobile wallets, desktop wallets, headless validators behind NATs) is much larger and not directly measurable. Both populations contribute to consensus by validating blocks; only listening nodes contribute to the network's serving capacity. Operators who want their node to count toward the public network can open port 8333 on their router or run the node over Tor as a hidden service.
Lightweight or SPV Nodes
Lightweight or SPV nodes are nodes that do not have a copy of the blockchain but instead rely on some other node to serve them data about their transactions via a protocol called "Simplified Payment Verification." This may be problematic because the SPV node has to trust the node that delivers the data. This node could hide transactions, serve fake transactions, and potentially misuse or sell data and metadata pertaining to the SPV node. SPV nodes are often used on mobile devices, where battery life, storage space, and data plans may prohibit running a full node.
An SPV node downloads only the block headers (80 bytes each, currently about 70 MB total) and uses Merkle proofs to confirm that wallet transactions are included in the chain. SPV clients do not validate signatures, scripts, or the consensus rules; they verify proof-of-work on the header chain and trust that the heaviest chain represents the network's consensus.
Two protocol-level mechanisms let SPV clients request only the transactions relevant to their wallet:
- BIP 37 defines Bloom filters that an SPV client sends to a full node so the full node returns only matching transactions. BIP 37 has known privacy weaknesses: the filter pattern leaks information about which addresses belong to the client.
- BIP 157 and BIP 158 define compact block filters that full nodes compute once per block and serve to clients. The client downloads the filter, checks locally whether any of its addresses match, and only requests the full block on a match. This pushes the privacy boundary back to the client side and has become the modern default for new light-wallet implementations.
An SPV client trusts that the majority of hashing power follows the rules, while a full node trusts only the rules themselves. For users moving large amounts of bitcoin or relying on validation as a sovereignty guarantee, a full node is the safer choice. For users running a phone wallet on limited storage, SPV is the practical choice.
Mining Nodes
Mining nodes are nodes that participate in transaction ordering and block creation in conjunction with running specialized mining hardware called ASICs. This is made possible via the Stratum protocol, which acts as a bridge between the ASIC and Bitcoin network. Upon Bitcoin's inception, most nodes were also mining, but as mining evolved with greater computational demands, they made up a smaller subset of Bitcoin full nodes.
Every mining node runs full validation, which keeps miners from accidentally building on an invalid chain. The terminology often gets conflated; a mining node, a mining pool, and a mining ASIC are three separate things:
- The mining node is software (typically Bitcoin Core, sometimes a specialised template-builder like the Stratum V2 reference job constructor) running on a general-purpose computer. It validates blocks and assembles templates from the mempool.
- A mining pool is a coordination service that aggregates work from many ASICs across many operators, shares rewards proportionally, and runs its own mining nodes on behalf of the pool.
- A mining ASIC is the dedicated hardware that performs the SHA-256 proof-of-work hashing.
Compact Block Relay (BIP 152) reduces the bandwidth cost of propagating newly mined blocks across the network, which is why every modern mining node supports it. For a deeper treatment of how mining nodes coordinate with pools and ASIC fleets, see the role of a node in mining.
Master Nodes
Bitcoin has no master nodes. Master nodes are specific to some altcoins, where they organize governance on-chain or perform some other function not carried out by regular nodes. That hierarchy runs counter to Bitcoin's non-hierarchical design, in which all nodes are equal and must follow the same protocol rules.
AssumeUTXO and the Bootstrap Variant
IBD is the largest barrier to running a full node: validating every block from the genesis block on modern consumer hardware takes from several hours on a fast SSD to weeks on older spinning disks. AssumeUTXO is a feature merged into Bitcoin Core that lets a new node bootstrap from a UTXO set snapshot instead of replaying every block from genesis.
The mechanism: the node downloads a UTXO snapshot at a recent block height, verifies the snapshot's hash against a value compiled into the binary, and immediately begins validating new blocks from that height forward. In the background, the node still downloads and validates the historical chain from genesis up to the snapshot height, which converges the node to a fully validated state without keeping the user waiting.
Bitcoin Core 28.0 added mainnet AssumeUTXO parameters at block height 840,000, making the loadtxoutset RPC usable on mainnet. The result is a node that can be useful within minutes while still arriving at the same fully validated state as a node that synced from genesis.
Comparison Table
| Type | Stores full chain | Validates every block | Serves old blocks | Service bit | Typical storage |
|---|---|---|---|---|---|
| Full archival node | Yes | Yes | Yes | NODE_NETWORK | ~742 GB |
| Pruned node | No (recent only) | Yes | No (or limited) | NODE_NETWORK_LIMITED (BIP 159) | ~5–10 GB practical |
| SPV / light client | No | No (headers only) | No | n/a (does not relay) | ~70 MB headers + wallet |
| Mining node | Yes (typically) | Yes | Yes | NODE_NETWORK | ~742 GB |
| AssumeUTXO bootstrap | Eventually | Yes (after background sync) | Eventually | NODE_NETWORK (after sync) | ~742 GB after convergence |
Hardware Implications
Storage dominates the hardware question. An SSD is strongly recommended for any node that validates blocks: spinning disks struggle with the random-read pattern that UTXO updates impose, which is why HDD-based initial syncs can stretch from days to weeks. A 1 TB SSD is a comfortable choice for a full archival node and gives several years of headroom for chain growth at the current rate of roughly 50–100 GB per year.
RAM, CPU, and network still matter, though less than storage. 8 GB of RAM is the practical floor, and 16 GB is more comfortable for nodes that also run wallet software, an electrum server, or Lightning. Modest CPUs are sufficient for steady-state validation; only initial sync benefits meaningfully from faster cores. A residential broadband connection is enough for both serving and being served, with the caveat that an always-on listening node uses several hundred gigabytes of upload per month under normal load.
Why the Taxonomy Matters
The node type a Bitcoin user runs determines the trust model their wallet relies on. Full and pruned nodes validate the chain themselves and answer only to the consensus rules; SPV clients delegate validation to whichever full nodes they connect to. For users moving large amounts of bitcoin, holding self-custodial savings, or participating in the network as anything more than a casual consumer, the difference is meaningful.
The taxonomy also explains why Bitcoin's decentralisation is durable. No single category of participant carries the network alone. Mining centralisation leaves the validating mesh intact, since that mesh is composed of full and pruned nodes run by ordinary users, and a surge in mobile wallet usage leaves history availability intact, since archival nodes hold the chain regardless. The architecture distributes responsibility across variants that can each be operated by different actors with different resources.
Frequently Asked Questions
What are the main types of Bitcoin nodes?
The main types are full nodes, pruned nodes, archival nodes, SPV (light) clients, and mining nodes. Full, pruned, and archival nodes validate every consensus rule; SPV clients verify only block headers; mining nodes assemble candidate blocks and submit them through ASIC hardware.
What is the difference between a full node and a pruned node?
A full node stores the entire validated block history. A pruned node validates every block during initial sync but then discards old block data, keeping only the UTXO set, indexes, and the most recent blocks. Both validate identically; only the historical-serving capability differs.
What is an SPV node?
An SPV (Simplified Payment Verification) node downloads only block headers and uses Merkle proofs to confirm wallet transactions are included in the chain. SPV clients trust the heaviest header chain rather than re-validating every consensus rule.
Are there master nodes in Bitcoin?
No. Bitcoin has no privileged node tier, no staking node, and no master node. Every full node validates the same rules and has the same authority. The term "master node" comes from other cryptocurrency projects and does not apply to Bitcoin.
Do mining nodes earn the block reward?
The block reward is paid to whichever address the mining node specifies in the coinbase transaction of a solved block. In pooled mining, that address belongs to the pool, which then distributes a share of the reward to contributing operators.
Can a node be both pruned and listening?
Yes. A pruned node that opens port 8333 to inbound peers signals NODE_NETWORK_LIMITED (BIP 159) and serves recent blocks to other peers without holding the full archive.
Run a Bitcoin Node With Blockstream
Validating Bitcoin independently means a node runner no longer relies on others to enforce the network's rules. For node runners who want a hardware wallet that connects to their own node, Blockstream Jade Plus signs transactions offline while the Blockstream app handles broadcasting through the user's preferred validation source. The combination keeps signing keys air-gapped and consensus decisions local.
