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

Bitcoin Data GuideBitcoin Reference

Node Operations

Node Bandwidth and Peers

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 what it is willing to pass on. The bandwidth it spends is the price of participating in the network rather than only reading from it.

Last reviewed 2026-09-21Source: Bitcoin Core P2P documentation; Bitcoin Developer Guide — P2P NetworkPeer counts and defaults change between Bitcoin Core releases; the behaviour described is that of current releases.

How a node finds its peers

A node does not need a central directory to find other nodes. It starts from a small set of hardcoded addresses, called seed nodes, which are used only to learn about other peers. From there it discovers addresses through the peer-to-peer protocol itself: nodes exchange the addresses they know about, and the new node builds up a list of candidates it can connect to.

The node maintains a target number of outbound connections, which it chooses itself, and accepts a number of inbound connections from other nodes. The outbound connections are the ones the node controls, and they are the ones it relies on for the data it needs. The inbound connections are other nodes choosing to connect to it, and they are how the node contributes to the network's connectivity.

The distinction matters for the eclipse attack described on the eclipse attack page. An attacker who can control all of a node's connections can show it a false view of the network. The defence is to keep enough connections, and enough of them chosen by the node itself, that surrounding it becomes impractical.

Where the bandwidth goes

The largest share of a node's bandwidth is block relay. Every new block is sent to the node by its peers and, once validated, offered to the peers that have not seen it. Because blocks are the largest messages in the protocol, the bandwidth cost of a node is dominated by how many peers it serves blocks to. A node with many inbound connections spends more bandwidth than one with few.

Transaction relay is smaller per message but continuous. A node receives unconfirmed transactions from its peers, checks them against its relay policy, and offers the ones it accepts to its other peers. The volume depends on the prevailing fee market: a busy mempool means more transactions to relay, and a quiet one means less.

The node also spends bandwidth on the peer-to-peer protocol itself — address gossip, ping messages, and the header announcements that let peers learn about new blocks before requesting them. These are small individually but constant, and they are the reason a node has a baseline bandwidth cost even when nothing is happening.

Managing the connections

A node does not keep every connection it makes. It disconnects peers that misbehave, that fail to respond, or that send invalid data, and it replaces them from its list of candidates. The connection set is therefore a moving population rather than a fixed list, and the node is continuously evaluating the peers it has.

The operator can influence this. A node can be configured to connect only to specified peers, which is useful for a private setup, or to accept connections on a particular interface. It can also be told to limit the number of connections, which caps the bandwidth cost at the price of contributing less to the network.

The relay policy a node applies to the transactions it receives is a separate decision from its connection management, and it is covered on the mempool policy page. A node can be well connected and still refuse to relay a transaction that another node would accept, because policy is local and consensus is not.

Sources and references

The description of peer discovery, connection management and bandwidth use is taken from the Bitcoin Core documentation and the peer-to-peer protocol description.

Related reading