Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Bitcoin Data GuideBitcoin Reference

Security & Resilience

What happens when a node goes offline?

Nothing, in the sense that matters. A node is one participant's copy of the ledger and one participant's set of connections. When it stops, the network loses a validator and a relay, and the remaining nodes carry on with the same rules and the same chain. The confusion that surrounds this question comes from treating nodes, miners and wallets as the same thing, when they are three separate roles.

Protocol referenceSource: Bitcoin Developer Guide, P2P NetworkDescribes the peer-to-peer layer that nodes participate in; the roles described here are architectural, not implementation-specific.

Three roles, often confused

A node is a program that keeps a copy of the blockchain, validates every block and transaction it receives against the consensus rules, and relays what it accepts to its peers. A miner is a participant that assembles candidate blocks and searches for a proof of work that meets the difficulty target. A wallet is software that manages private keys and constructs transactions. The three can run on the same machine, and often do, but they are distinct roles with distinct responsibilities, and the network's behaviour when one of them stops depends on which one it is.

A node that goes offline stops validating and stops relaying. It does not stop the chain, because the chain is not stored in any one place. Every other node has its own copy and its own connections, and the blocks that the offline node would have relayed are relayed by its peers instead. The network's topology is a mesh, not a hub, so the loss of one participant is absorbed by the others. This is the property that makes the system resilient to the failure of any single machine, and it is a direct consequence of the decision not to delegate validation to a central server.

A miner that goes offline is a different matter, but still not a fatal one. The network's total hash power falls by that miner's share, and blocks are found more slowly until the difficulty adjustment responds. The chain continues, transactions continue to confirm, and the difficulty mechanism restores the ten-minute average over the following retarget periods. The sharp hashrate declines page works through that case in detail.

What a wallet needs from a node

A wallet does not need to be online to hold coins. The keys are stored locally, and the coins exist as outputs on the chain regardless of whether any particular device is running. What a wallet needs a connection for is to learn about the current state of the chain and to broadcast transactions. A wallet that talks to its own node is verifying that state for itself; a wallet that talks to someone else's server is trusting that server's report. The difference is the same one described on the node verification page.

When a node goes offline, a wallet that depended on it loses its view of the chain until it finds another source. The coins are unaffected. A transaction that was already confirmed remains confirmed, because confirmation is a property of the chain rather than of any node's memory. A transaction that was only in the offline node's mempool may need to be rebroadcast, because mempools are local and are not shared between nodes. This is why a wallet that has broadcast a transaction and then lost its node should check whether the transaction is confirmed before assuming it was lost.

Why the network does not notice

The network is designed so that no participant is indispensable. Nodes discover peers through a combination of hardcoded seeds, DNS seeds and addresses learned from other peers, so a node that loses its connections can find new ones. Blocks propagate through a mesh of connections, so a block that one node fails to relay is relayed by another. Validation is performed independently by every node, so there is no single validator whose absence halts progress.

The practical implication for an operator is that running a node is a contribution to the network's resilience rather than a dependency of it. Stopping a node reduces the number of independent validators and the redundancy of the relay mesh, and it removes that operator's ability to verify their own transactions. It does not stop the chain, and it does not put anyone's coins at risk. The network is built to tolerate exactly this.

Sources

  • Bitcoin Developer Guide, P2P Network — peer discovery, connection management and block relay.
  • Bitcoin Developer Guide, Block Chain — how a node maintains and validates its own copy of the chain.
  • Bitcoin Core, documentation — the reference implementation's node, wallet and networking components.

Related reading