Bitcoin nodes explained: what a full node does, and why people run one

A full node validates according to its rules and configuration

The word “node” just means a computer running Bitcoin software and talking to other computers doing the same. A full node is the demanding kind. The bitcoin.org guide defines it as a program that fully validates transactions and blocks, and the Bitcoin Wiki spells out what that means: it downloads every block and transaction and checks them against Bitcoin’s consensus rules, the rules every participant has to agree on for the system to work at all.

Those rules cover things like whether every signature is genuine, whether a transaction is trying to spend coins that were already spent, whether the data is formatted correctly, and whether a block’s miner is paying itself no more than the reward allowed. If anything fails, the wiki puts it starkly: the block or transaction is absolutely rejected, even if every other node on the network thinks it is valid. Your node does not take a vote or ask a server. It decides.

That independence is the point. A full node is how a person verifies, rather than trusts, that the bitcoin they have been paid is real and that the ledger they are looking at follows the rules. Everything else a node does, relaying transactions, serving blocks to others, answering a wallet’s questions, sits on top of that.

Validation and block construction are different jobs

A validating node checks whether received blocks and transactions satisfy its configured consensus rules. A miner assembles candidate blocks and searches for proof of work. A valid proof of work does not make an invalid transaction acceptable to a validating node.

Running a node does not require mining hardware and does not by itself earn a block reward. A miner also needs a valid chain view, whether supplied through its own node or other infrastructure. Separate the validation role from the work that proposes a new block.

A pruned node keeps the rules and throws away the old blocks

Pruning removes eligible older raw block and undo files after they have been processed, reducing retained storage. The historical Bitcoin Core 0.11.0 release notes describe its introduction; their compatibility restrictions and disk figures are not a universal description of later versions.

Chainstate and retained recent blocks serve different purposes from an archive of historical block bodies. Deleted files cannot be served or scanned locally unless the required data is obtained again. A pruning target is not the size of the complete data directory.

Pruning itself changes retention, not the consensus validity rules. Synchronization options and validation assumptions should still be evaluated for the actual node configuration.

Why people run a node: validation, privacy and direct network access

The first reason is privacy. A wallet without its own node has to ask someone else’s server about its addresses, and that server learns which addresses are yours. The Bitcoin Wiki calls downloading the whole chain the most private way to operate a wallet. Our article on whether Bitcoin is anonymous goes into what a server can infer from those questions.

A full node can independently check transaction and block validity instead of relying only on a remote service’s account of the chain. Section 8 of the white paper distinguishes this from header-and-inclusion verification. A wallet still needs a trustworthy interface and connection to the intended node; validation does not guarantee that every screen or account label is honest.

The third is the network itself. The bitcoin.org guide points out that if not enough nodes accept incoming connections, other people’s software cannot join the peer-to-peer network and has to fall back on centralized services. Each additional full node is one more independent copy of the rules, and one more place a bad block gets rejected. Satoshi’s own thinking about how the peer-to-peer layer should behave is gathered in the peer-to-peer network hub.

A crawler cannot count every node or operator

Public node crawlers connect to responding endpoints. A machine behind a firewall, or configured only for outbound connections, may validate without appearing in that census. One operator can also run several nodes.

A count must therefore be accompanied by its observation time and crawler method. This entry does not reuse a past live-page count as a fresh measurement or treat endpoint counts as a vote tally.

Storage and bandwidth depend on the configuration

A node needs storage for its chain state, software data and whichever block files and indexes it retains. An archival configuration stores historical blocks; pruning saves disk by deleting older block files. The pruning target does not describe the size of the whole data directory.

Initial synchronization and continuing block downloads also require bandwidth and processing time. Consult the documentation for the actual software version and intended indexes, rather than treating a hardware number in an old article as a permanent minimum.