Peer Bookmark

"Peer bookmark" is an informal name for Bitcoin Core's settings that tell a node which peers to connect to:

• -addnode=<ip> adds a peer that the node connects to and tries to keep connected, on top of the peers it picks on its own. If the connection drops, the node keeps retrying, about once a minute. Up to 8 of these connections can be open at a time, counted separately from the -maxconnections limit. The addnode command does the same while the node is running.
• -connect=<ip> connects only to the peers listed, under the same rules as -addnode, and makes no other automatic outbound connections. It also turns off DNS seed lookups and listening for incoming connections, unless those are switched back on. This suits a setup where the operator wants full control, like a private test network or a node that should only talk to machines its owner runs.

Typical uses:

• Someone running two nodes, say one at home and one on a rented server, can point each at the other with -addnode so the two always stay connected.
• A business can keep its payment node linked to its own backup node the same way.
• A private test network or lab can use -connect so each node talks only to the machines the operator chose.

Peers added with -addnode, -connect or the addnode command already get gentle treatment: Bitcoin Core never disconnects or discourages them for misbehavior.

The -whitelist setting does something else. It gives extra permissions to peers at chosen IP addresses or ranges. By default it applies only to incoming connections. Its in and out flags choose whether it covers incoming connections, peers the node connects to by hand, or both. -whitebind does the same for every peer that connects to a chosen local address and port. With no permissions named, these peers get four:

• noban: never disconnected or discouraged for misbehavior, allowed to connect even if banned or discouraged, and never dropped to make room for a new incoming peer.
• download: can ask for block headers while the node is still syncing, and isn't cut off when the node reaches its -maxuploadtarget upload limit.
• relay: the node accepts their transactions even in blocks-only mode, with no cap on how many transaction announcements it tracks from them.
• mempool: can ask for a list of the transactions in the node's mempool.

Other permissions can be named one at a time. One example is addr, which frees a peer from the rate limit on the addresses it sends. There is no ban score for any of these to skip. In current versions of Bitcoin Core, a peer that misbehaves is disconnected and discouraged after one offense, unless it has noban or was added by hand (see node autoban for how this used to work).

Without any of these settings, Bitcoin Core finds peers on its own, from addresses it has saved, addresses other peers pass along, and DNS seeds when it runs low (see peer discovery).