Node Operations

What it takes to run a node

Running a Bitcoin node is the act that turns a claim about the network into something you can check for yourself. This hub collects the pages that explain what that involves: the initial block download that validates the whole chain from genesis, the storage the result requires, the peers a node maintains and the bandwidth it spends on them, and the relay policy that decides which unconfirmed transactions it will pass on. The recurring theme is that a node's value is the verification it performs, not the copy of the chain it keeps.

Most people who use Bitcoin never run a node, and that is a reasonable choice. A wallet can ask someone else's node what the balance of an address is, and the answer will usually be correct. What the wallet cannot do in that arrangement is verify the answer independently, and the whole argument for Bitcoin's settlement guarantees rests on the possibility that someone, somewhere, is checking. Running a node is how that possibility becomes a fact for a particular person.

The pages here are written for someone considering that step. They set out the resources involved honestly — the disk, the bandwidth, the time the first sync takes — and they separate the choices that are genuinely consequential from the ones that are merely preferences. Where a figure depends on the current size of the chain or the prevailing fee market, the page says so rather than presenting a number that will be stale within a year.

Sync & Validation

What does a node have to do before it can be trusted?

A node that has just been installed knows nothing. Before it can tell you anything useful about a transaction, it has to download every block since the genesis block and check each one against the consensus rules, a process known as initial block download. This strand explains why that process is deliberately slow, what it proves once it finishes, and how the node stores the result. The point is that a node's value is not that it holds a copy of the chain but that it has independently verified the chain it holds, which is a distinction that matters when someone else's node is telling you what happened.

Start with Initial Block Download

Running the Node

What does a node consume, and who does it talk to?

Once synced, a node is not idle. It maintains connections to a set of peers, relays transactions and blocks between them, and applies its own policy about which unconfirmed transactions it is willing to pass on. This strand covers the resources that involves — the bandwidth a node sends and receives, the way it discovers and manages peers — and the relay rules that decide what enters its mempool. It is the strand to read if you want to understand why two honest nodes can disagree about which transactions they will relay without either of them being wrong.

Start with Node Bandwidth & Peers

Every page in this section

The strands above are the way in. This is the full contents of the section, grouped by whether the page covers the sync that establishes trust or the steady-state operation that follows.

Sync & Storage

The validation a node performs from genesis, the disk it needs to keep the result, and the verification path that makes the copy trustworthy.

Peers & Relay Policy

The connections a node maintains, the bandwidth it spends on them, and the rules that decide which unconfirmed transactions it will pass on.

The reference pages behind the strands

The strands above explain the operation. These pages hold the underlying record and the methodology, for when you want to check a figure or follow a source.

Where the node meets the protocol

A node is the enforcement point for the protocol's rules. These pages carry the mechanics it checks against.