A Bitcoin node is a computer running Bitcoin software, most commonly Bitcoin Core, that connects to other nodes over a peer-to-peer network, validates every transaction and block against the consensus rules, and keeps a copy of the blockchain. Nodes are the machines that actually enforce the rules of Bitcoin. Miners produce blocks, but nodes decide whether to accept them.
TL;DR: A Bitcoin node is software running on a computer that maintains a copy of the Bitcoin blockchain and applies the consensus rules to every block and transaction it sees. If a block breaks the rules, the node rejects it, regardless of how much hash power produced it. This is the property that makes Bitcoin trust-minimized: the rules are enforced by the people running nodes, not by any central authority.
The original description appears in Satoshi Nakamoto's Bitcoin whitepaper, which calls nodes the entities that "vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them." Today, validation and mining are separate functions, but the principle is the same: a node's job is to verify.
What a Bitcoin Node Actually Does
A Bitcoin node performs three jobs at the same time: validation, relay, and storage.
Validation and Consensus
When a node receives a new transaction or block, it checks every rule before accepting it. The checks include signature validity (Bitcoin uses both ECDSA and Schnorr signatures since the Taproot soft fork activated at block 709632 in November 2021), correct proof-of-work, no double spends, valid script execution, correct block size and weight, and a chain that connects back to the genesis block. If any check fails, the node rejects the item.
This is what people mean by "running a node to enforce your own rules," the central role of a Bitcoin node. Two operators running the same Bitcoin Core release will reach the same conclusion about every block, because the consensus rules are deterministic. If a miner produced a block that paid itself extra coins or spent someone else's unspent transaction output (UTXO), every node on the network would reject it.
Relay and Propagation
After a node validates a transaction or block, it relays that item to its peers. Bitcoin's peer-to-peer protocol uses a gossip model: each node maintains a handful of outbound connections (eight full-relay by default in Bitcoin Core) and accepts incoming connections from other listening peers. Compact block relay (BIP 152) reduces the bandwidth needed to forward a freshly mined block by sending short transaction identifiers instead of full transactions, since most nodes already have the underlying transactions in their mempool.
Storage of the Blockchain
A node stores some or all of the blockchain. An archival node keeps every block since genesis, currently about 742 GB as of 2026-05-22 per blockchainsize.org. A pruned node deletes old block data after verifying it, keeping the on-disk block footprint as low as 550 MB (Bitcoin Core's `prune=550` minimum). Both types validate identically; the difference is only how much historical data is retained.
Mempool Admission and Policy Filtering
A node maintains a mempool of unconfirmed transactions waiting to be included in a block. Mempool admission is governed by policy rules, which sit above the consensus rules and are configured per node. Defaults in Bitcoin Core include:
- A minimum relay fee (default 1 sat/vB) below which transactions are not relayed.
- A dust limit that rejects outputs whose value is too small to be economically spent.
- Ancestor and descendant package limits that cap how large a chain of unconfirmed transactions can grow in any single node's mempool.
- Standardness checks on script templates, transaction size, and signature operations.
By default, a node saves its mempool to disk on shutdown and reloads it on startup, so unconfirmed transactions survive a restart. Operators can disable this behavior to start with an empty mempool instead.
Policy Rules vs. Consensus Rules
Consensus rules are network-wide and define what counts as a valid transaction or block. Every node must enforce them, or the node falls off the network's view of the chain. Policy rules are local and define what a node chooses to relay or accept into its own mempool, and differences in policy do not split the network. A miner can include a transaction that violates a local policy rule as long as the transaction satisfies consensus, and other nodes will still accept the resulting block.
Rule Enforcement and Reorg Defense
Validation alone is passive. Enforcement is the active half: a node refuses to extend its chain with any block that fails verification, even if that block sits on a longer competing chain. Because a node follows the heaviest valid proof-of-work chain, an invalid block cannot become canonical no matter how much hash power backs it.
This property prevents a small, well-resourced group from rewriting the rules. The whitepaper describes the same defense: an attacker who wants to extend the chain finds it more profitable to play by the rules, and any attempt to claim more than the allowed subsidy or spend an output that does not exist is rejected by every honest node (Nakamoto, 2008, §6).
Defense against a reorg, where a competing chain replaces blocks a node already accepted, follows the same principle. When two valid blocks compete at the same height, a node initially accepts the first one it sees and switches to the other if more proof-of-work accumulates on it. The protocol limits how far back a reorg can rewrite through economic friction rather than a hard cap, which is why most software and exchanges wait six confirmations before treating a transaction as final.
Soft-Fork Signaling and Consensus Participation
When the network considers adopting a backwards-compatible rule change, mining nodes signal readiness using version bits (BIP 9 or its successor BIP 8). BIP 9 sets a designated bit in the block version field during a signaling period and activates the new rule once 1916 of 2016 blocks in a retarget period (about 95%) include the bit on mainnet.
Non-mining nodes participate in consensus differently. A non-mining node does not signal, but it enforces an activated soft fork once the activation period completes, rejecting blocks that violate the new rule. Nodes also warn loudly when an unknown soft fork reaches the locked-in state, prompting operators to upgrade so their node enforces the rule rather than splitting from the network.
Decentralized Validation and Eclipse-Attack Mitigation
Every node performing the same validation independently is what makes the network decentralized in practice rather than only in theory. If one node fails or lies, every other node continues to enforce the rules. There is no central authority a node consults to learn what is valid.
A node operator can reduce a class of attack called eclipse, in which an adversary monopolizes all of a node's peer connections to feed it a false view of the chain. Mitigations supported by Bitcoin Core include:
- Anchor connections that persist across restarts, so a peer set is not fully rebuilt from scratch every time.
- Outbound connections to peers in diverse network groups (different ASNs and geographies).
- Connections over Tor and I2P in addition to clearnet, so a single network-layer adversary cannot intercept every connection.
The combination of independent validation and a diverse peer topology is what keeps a node's view of the chain consistent with the rest of the network.
Types of Bitcoin Nodes
The Bitcoin network has several node varieties, and the types of Bitcoin nodes article goes deeper into each one.
Full Archival Nodes
A full archival node stores the entire blockchain and validates every block since genesis. It can serve historical blocks to other nodes during their Initial Block Download, which makes the network more resilient. Block explorers, indexers, and many merchants run archival nodes for this reason.
Pruned Full Nodes
A pruned node performs the same validation as an archival node but deletes older block data after it has been processed. The chainstate (the current UTXO set) and the recent blocks needed for reorg handling are kept. A pruned node still enforces every consensus rule on every new block; it just cannot serve old blocks to other peers. This makes pruned nodes ideal for low-storage hardware. The trade-offs are covered in whether to run a full node or a pruned node.
SPV (Lightweight) Clients
Simplified Payment Verification (SPV), described by Satoshi in section 8 of the whitepaper, is a mode where a client downloads only block headers and the transactions relevant to its addresses. Two different filtering protocols later supported this light-client model: BIP 37 added server-side bloom filters, and BIP 157 with BIP 158 added client-side compact block filters that avoid the privacy leaks of the bloom-filter approach. SPV clients trust that the longest valid header chain is the correct one without validating every transaction. Most mobile Bitcoin wallets use some form of SPV or a server-assisted variant. SPV reduces resource needs sharply but provides weaker guarantees than a full node.
Mining Nodes
A mining node is a full node that also produces candidate blocks, either from work assigned by a pool or on its own. Mining requires a full node because the miner has to know which transactions are valid before assembling them into a block template, which is the role of a node in mining.
Hardware and Bandwidth Requirements
The current floor for a Bitcoin Core full archival node:
- About 1 TB of disk space, ideally on an SSD. The blockchain is 742 GB as of 2026-05-22 per blockchainsize.org and grows by roughly 50-60 GB per year.
- A pruned node can run with as little as 550 MB of block storage plus the chainstate (about 9 GB and growing).
- 8 GB of RAM. Bitcoin Core can run on 2 GB but is comfortable at 8.
- A modest CPU. Any modern x86 or ARM processor is sufficient; a Raspberry Pi 4 or 5 is enough for a pruned node.
- A broadband connection. Steady-state bandwidth is roughly 100-200 GB per month for a listening node serving peers, much less for a non-listening one. Initial Block Download is the heavy event.
An SSD is strongly recommended because the Initial Block Download involves heavy random reads and writes. An HDD will work but can extend it from hours to weeks. For the full walkthrough, see how to set up and run a Bitcoin node.
Initial Block Download (IBD)
Initial Block Download (IBD) is the one-time process where a new node downloads and validates every block from genesis to the chain tip. On a modern SSD with good bandwidth, IBD takes hours to a day or two. On an HDD, IBD can take days to weeks because the disk thrashes verifying the chainstate. Most of the wall-clock time is spent on signature and script verification, not on the network download.
After IBD, the node is in sync and uses very little additional resources to keep up. New blocks arrive on average every 10 minutes (the protocol targets 600 seconds via the difficulty adjustment), so the steady-state workload is small.
How Many Bitcoin Nodes Exist Today?
Bitnodes counts around 23,000 reachable Bitcoin nodes (as of May 2026). Reachable means the node accepts incoming TCP connections on the public internet. The actual node count is meaningfully higher, because most nodes run behind network address translation (NAT) or firewalls and do not accept inbound connections; those nodes still validate and relay but are invisible to crawlers.
The reachable count has been stable in the 15,000-25,000 range for years, with peaks during fee spikes and dips during quieter periods. The geographic distribution skews to the United States, Germany, France, and the Netherlands, with smaller clusters across the rest of Europe and Asia.
Bitcoin Core and Alternative Implementations
Bitcoin Core is the reference implementation of the Bitcoin protocol, maintained at github.com/bitcoin/bitcoin. It is the software that the great majority of nodes run. The most recent release at the time of writing is Bitcoin Core 31.0. Bitcoin Core is not the protocol itself; the protocol is defined by the consensus rules that every implementation must match.
Other implementations exist and are protocol-compatible:
- Bitcoin Knots is a derivative of Bitcoin Core with additional policy options.
- btcd is a full-node implementation written in Go.
- libbitcoin is a C++ library and node implementation.
Running a non-Core implementation carries the risk that subtle differences in consensus behavior cause a fork in some unusual edge case, so most operators run Bitcoin Core or Knots.
Running a Node Alongside a Wallet
A node by itself does not hold any bitcoin. Spending it requires a Bitcoin wallet. The node validates the chain and serves blocks. A node operator connects a wallet to the node over Remote Procedure Call (RPC) or via electrum-server middleware such as Electrs or Fulcrum. Sparrow and Specter Desktop can both talk to a personal node, which means the wallet checks balances and broadcasts transactions against the operator's own copy of the blockchain instead of trusting a third party.
A Jade hardware wallet pairs with these wallet apps and adds a hardware boundary for private keys. The combination of a hardware wallet, a self-custodial wallet app, and a personal node is the strongest configuration for verifying Bitcoin transactions without trusting any third party.
Why Blockstream Cares About Bitcoin Nodes
Blockstream operates infrastructure that depends on the Bitcoin node network. Blockstream Explorer is powered by Esplora, an open-source explorer that indexes data from Bitcoin Core nodes. Greenlight lets developers run Core Lightning nodes managed by Blockstream while users keep custody of their funds. Bitcoin Core developers at Blockstream contribute upstream to the reference implementation.
A healthy network of independent nodes is a precondition for everything Blockstream builds. The more nodes the merrier, particularly nodes operated by individuals rather than commercial services.
The Economic Role of Non-Mining Node Operators
A non-mining node earns no block subsidy and no transaction fees. It runs at the operator's expense in disk, bandwidth, and electricity. Its economic role is rule enforcement: by refusing to accept invalid blocks, every running node raises the cost of any attempt to change the protocol unilaterally.
If only miners ran nodes, a coordinated supermajority could quietly alter the rules, for example by increasing the block subsidy. Because end users, businesses, and exchanges run their own nodes and reject any block that violates the rules they expect, miners face the prospect of producing blocks no one will accept. That asymmetry is the structural reason non-mining nodes hold consensus power even though they cannot mint a single satoshi.
Bitcoin Node vs. Miner
A Bitcoin node verifies the rules; a miner produces new blocks. Every miner runs a node, but most nodes do not mine. On its own, a node validates transactions and blocks, relays valid data, and rejects anything invalid. A miner does that same validation and then competes to extend the chain by performing proof-of-work hashing, earning the block subsidy and fees when its block is accepted. A node earns nothing and needs no specialized hardware; a miner stakes electricity and ASIC capacity on finding a valid block. The node decides whether a miner's block is valid, which is why validation, not hashing, is the network's source of authority.
What a Bitcoin Node's Role Is Not
Several common assumptions about nodes are wrong.
- A standard node does not mine, because mining is a separate function that assembles a candidate block and performs SHA-256 proof-of-work hashing. A validation node does neither; it validates the blocks that miners produce without participating in block construction or hashing itself.
- A node does not directly earn fees or subsidy. Only the miner whose block is accepted earns the coinbase reward.
- A node does not vote in proportion to economic stake. Each node enforces the rules it runs; there is no weighted ballot. Consensus emerges from the set of rules every node independently chooses to enforce.
- A node does not need to be a wallet. Many operators run a dedicated validation node and connect a separate wallet to it.
- A node does not require trust in any third party.
Frequently Asked Questions
What is a Bitcoin node?
A Bitcoin node is a computer running Bitcoin software (most commonly Bitcoin Core) that connects to other Bitcoin nodes over a peer-to-peer network, validates transactions and blocks against the consensus rules, and stores a copy of the blockchain. A node enforces the rules of Bitcoin independently of any third party.
What is the difference between a full node and a pruned node?
A full archival node stores the entire blockchain (about 742 GB as of May 2026). A pruned node validates every block the same way but deletes old block data after verification, keeping the storage footprint as low as 550 MB plus the chainstate and recent blocks. Both apply the full consensus rules; the difference is only how much historical block data is kept.
How many Bitcoin nodes are there?
Bitnodes counts around 23,000 reachable Bitcoin nodes (as of May 2026). Reachable means the node accepts incoming connections on the public internet. The true number of nodes is higher, because non-listening nodes behind NAT or firewalls are not counted.
What hardware does a Bitcoin node need?
A full archival node currently needs roughly 1 TB of disk, 8 GB of RAM, a modest CPU, and a broadband connection. A pruned node can run with as little as 550 MB of block storage. An SSD is strongly recommended because the Initial Block Download involves heavy random reads and writes.
Is Bitcoin Core the same thing as the Bitcoin protocol?
No. Bitcoin Core is the reference implementation of the protocol, maintained at github.com/bitcoin/bitcoin. Other compatible implementations exist, including Bitcoin Knots, btcd, and libbitcoin. The protocol is defined by the consensus rules that every implementation must match.
Do I need a node to use Bitcoin?
No, but running a node is the only way to verify Bitcoin transactions without trusting a third party. Wallets that do not connect to a node rely on someone else's view of the blockchain. Connecting a wallet such as Sparrow, Specter, or the Blockstream app to a personal node closes that trust gap.
What is the difference between policy and consensus rules?
Consensus rules are network-wide rules that every node must enforce, such as signature validity and the block subsidy schedule. Policy rules are local rules each node applies to its own mempool, such as a minimum relay fee or a dust limit. Policy controls what a node relays; consensus controls what a node accepts as valid. A block that breaks a node's local policy but satisfies consensus is still accepted.
Why does running a Bitcoin node matter if it earns nothing?
A non-mining node enforces the consensus rules independently. Without a critical mass of node operators verifying every block, a coordinated group of miners could change protocol rules unilaterally. Each independent node also gives its operator a trust-minimized view of the chain and reduces reliance on third parties.
How does a Bitcoin node prevent an eclipse attack?
A node maintains anchor connections that persist across restarts, prefers outbound peers in diverse network groups, and can connect over Tor or I2P alongside clearnet. The combination makes it harder for an adversary to control every connection a node uses to learn about the chain.
Running a Bitcoin node is a meaningful contribution to the network and a meaningful step toward self-custodial Bitcoin use. Pair a node with a Jade hardware wallet and the Blockstream app for an end-to-end self-custodial setup that verifies every transaction against the operator's own copy of the blockchain.