Peer Management

Peer management is the set of rules a node uses to decide which connections to keep, which to drop, and how to respond to misbehavior.

Bitcoin Core's defaults, as of version 31.1:

• 8 outbound full-relay peers, which the node trades everything with: blocks, transactions and addresses.
• 2 outbound block-relay-only peers, which pass only blocks. Because they carry no transactions or addresses, outsiders have a harder time spotting these connections, which helps protect the node against attempts to cut it off from the rest of the network.
• 1 outbound "feeler" connection, made about every two minutes, which briefly checks whether a known address is still online and then disconnects.
• Up to 114 inbound peers. The -maxconnections setting (125 by default) caps the connections the node makes and accepts on its own, and the 11 outbound slots above come out of that total first.
• Up to 8 more connections to peers the operator names with -addnode, counted separately from -maxconnections.

Outbound peers are spread out on purpose. On IPv4 and IPv6, Bitcoin Core connects out to only one peer in each address group, which for IPv4 means each /16 range (addresses that share their first two numbers). If the operator turns on the -asmap option, the groups follow the network operator an address belongs to instead (see asmap). Version 31.0 started shipping that map inside the program, but the option is still off by default. The node also tries to keep at least one outbound peer on each network it can reach (IPv4, IPv6, Tor, I2P and CJDNS), opening an extra connection when one is missing. And every few minutes it briefly connects to one more peer just to check for new blocks. The code says the point is to make eclipse attacks, where an attacker takes over all of a node's connections, very difficult to pull off.

When the inbound slots are full and a new peer wants in, the node looks for an inbound peer to drop. First it sets aside the ones it wants to keep: peers with the noban permission, 4 chosen by address group in a way an attacker can't predict, the 8 with the fastest ping times, the 4 that most recently sent it new transactions, up to 8 peers that don't relay transactions and 4 others that most recently sent it new blocks, and the longest-connected half of whoever is left, with some of those spots kept for peers on Tor, I2P, CJDNS or the same machine. Of the peers that remain, discouraged ones go first. Otherwise the node drops the newest peer from the address group with the most connections. If nobody is left to drop, the newcomer is turned away.

A peer that breaks certain protocol rules, for example by sending an invalid block or an oversized list of items, is disconnected after a single offense, and its address is "discouraged": the node won't connect out to it or pass its address on, and drops it first when it needs room for new incoming peers. There is no misbehavior score and no automatic ban. A ban happens only when the operator sets one with the setban command. Peers added by hand and peers with the noban permission are never punished this way. See node autoban for how this used to work. Bitcoin Core's own code notes that neither banning nor discouraging an address stops a denial-of-service attack, since the attacker can come back from another IP address.

Operators can change most of this. -maxconnections sets the total, -onlynet limits automatic outbound connections to chosen networks, -asmap turns on grouping by network operator, and -addnode, -connect and -whitelist handle peers the operator picks by hand (see peer bookmark).