<p>Addresses for outbound connections are largely chosen at random. The filtering of addresses comes at the time the addresses are first received by the node before they are added to the address database. This filter checks what services the nodes offer, what network they are on (e.g. IPv4, IPv6, TOR), and the time that they were reported to last be seen. Your node will choose to store addresses that are recent, use a network that your node is connected to, and offers full node services (<code>NODE_NETWORK</code> and <code>NODE_NETWORK_LIMITED</code>). We also avoid nodes that have been recently disconnected or banned.</p>
<p>These addresses are stored in buckets. These buckets are based on /16 for IPv4 and /32 for IPv6. In the future, these buckets will be determined by <a href="https://en.wikipedia.org/wiki/Autonomous_system_(Internet)" rel="nofollow noreferrer">Autonomous System</a>.</p>
<p>When making outbound connections, nodes are basically chosen at random. Your node will ensure that each outbound node belong to different buckets. If a node is chosen that belongs to a bucket that already has an outbound connection, it is skipped. We also try to choose nodes that we didn't already try to connect to recently unless we have built up a lot of failed connection attempts. Lastly, your node will try connect to nodes using the default port unless there have been a lot of failed connection attempts.</p>
<p>For nodes that you are specifically adding with <code>addnode</code>, these nodes do not take up the standard outbound connection slots. There are an additional 8 addnode connection slots. If these are full, then the node that you are adding will simply wait until one of those nodes disconnects before a connection to it is attempted. So there is no kicking of outbound peers at all.</p>

CC BY-SA 4.0
2021-11-17T20:30:24.007Z
@Andy Chow, I realize that this is an old post but with regard to the filter checks that determine the services the nodes have to offer, can you help elaborate on the services available? Are you referring to the roles of full nodes vs. lightweight clients, where full nodes can fully validate transactions/blocks, and help lightweight nodes to transmit their transactions to the network and by notifying them when a transaction affects their wallet? By looking at the connected peers through my bitcoin core, is there a way for me to tell if the peers is a full nodes or lightweight nodes?
TuanP
CC BY-SA 4.0
2021-11-18T01:44:43.783Z
@TuanP Sservice flags indicate what a node is capable of sending over the network but not whether they validate anything sent. Currently in use are `NODE_NETWORK` (can serve the entire blockchain), `NODE_BLOOM` (can serve BIP 37 bloom filters), `NODE_WITNESS` (can serve blocks and txs with witnesses per BIP 144), `NODE_COMPACT_FILTERS` (can serve BIP 157 block filters), and `NODE_NETWORK_LIMITED` (can serve the most recent 288 blocks per BIP 159). You can make assumptions (e.g. lack of `NODE_NETWORK` and `NODE_NETWORK_LIMITED` may imply SPV peers), but there are no guarantees.
Ava Chow
CC BY-SA 4.0
2021-11-19T11:53:30.197Z
Thank you so much! I used getpeerinfo via the console and was able to obtain the services names as described. "servicesnames": [ "NETWORK", "WITNESS", "NETWORK_LIMITED" ], Is there any significant info with regard to the "connection type" param? From my peers I got: "connection_type": "outbound-full-relay" (this is the most significant type for my peers ~ 80%), and "connection_type": "block-relay-only"
TuanP
CC BY-SA 4.0
2021-11-19T17:28:17.617Z
@TuanP No, there is not. It is just what your node has configured that particular connection to be. Some connections are limited to block relay only, whether that is because the peer requested it, or your node is conserving bandwidth. It has no relation to the services offered and whether the peer is validating.
Ava Chow
CC BY-SA 4.0
2020-08-04T20:22:55.877Z
2020-08-04T20:22:55.877Z
Ava Chow
<p>I understand that a full node can have up to 10 outbound connections (8 full relay peers and 2 block-relay-only peers). I wonder how my full node decides which nodes to connect to for outbound. What are the selection criteria does a node use to evaluate if a peer is good?</p>
<p>If I want to connect to a new specific peer (let's say I know the node's owner IRL or something) but I have already reached my outbound capacity, what specific criteria does my node use to decide which outbound peer to drop in order to make room for the new peer?</p>

<bitcoin-core><network><full-node><peer-discovery><p2p>
How does a full node decide which outbound peers to have?
glowang
# How does a full node decide which outbound peers to have?

(Asked by: username_0 on 2020-08-04)

I understand that a full node can have up to 10 outbound connections (8 full relay peers and 2 block-relay-only peers). I wonder how my full node decides which nodes to connect to for outbound. What are the selection criteria does a node use to evaluate if a peer is good?

If I want to connect to a new specific peer (let's say I know the node's owner IRL or something) but I have already reached my outbound capacity, what specific criteria does my node use to decide which outbound peer to drop in order to make room for the new peer?

**Tags:** bitcoin-core, network, full-node, peer-discovery, p2p


---

## 1 answers

### Answer by username_1 on 2020-08-04. Score: 4 | Accepted answer

Addresses for outbound connections are largely chosen at random. The filtering of addresses comes at the time the addresses are first received by the node before they are added to the address database. This filter checks what services the nodes offer, what network they are on (e.g. IPv4, IPv6, TOR), and the time that they were reported to last be seen. Your node will choose to store addresses that are recent, use a network that your node is connected to, and offers full node services (`NODE_NETWORK` and `NODE_NETWORK_LIMITED`). We also avoid nodes that have been recently disconnected or banned.

These addresses are stored in buckets. These buckets are based on /16 for IPv4 and /32 for IPv6. In the future, these buckets will be determined by [Autonomous System](https://en.wikipedia.org/wiki/Autonomous_system_(Internet)).

When making outbound connections, nodes are basically chosen at random. Your node will ensure that each outbound node belong to different buckets. If a node is chosen that belongs to a bucket that already has an outbound connection, it is skipped. We also try to choose nodes that we didn't already try to connect to recently unless we have built up a lot of failed connection attempts. Lastly, your node will try connect to nodes using the default port unless there have been a lot of failed connection attempts.

For nodes that you are specifically adding with `addnode`, these nodes do not take up the standard outbound connection slots. There are an additional 8 addnode connection slots. If these are full, then the node that you are adding will simply wait until one of those nodes disconnects before a connection to it is attempted. So there is no kicking of outbound peers at all.

> **Comments:**
> **username_2**: @Andy username_1, I realize that this is an old post but with regard to the filter checks that determine the services the nodes have to offer, can you help elaborate on the services available? Are you referring to the roles of full nodes vs. lightweight clients, where full nodes can fully validate transactions/blocks, and help lightweight nodes to transmit their transactions to the network and by notifying them when a transaction affects their wallet? By looking at the connected peers through my bitcoin core, is there a way for me to tell if the peers is a full nodes or lightweight nodes?  
> **username_1**: @username_2 Sservice flags indicate what a node is capable of sending over the network but not whether they validate anything sent. Currently in use are `NODE_NETWORK` (can serve the entire blockchain), `NODE_BLOOM` (can serve BIP 37 bloom filters), `NODE_WITNESS` (can serve blocks and txs with witnesses per BIP 144), `NODE_COMPACT_FILTERS` (can serve BIP 157 block filters), and `NODE_NETWORK_LIMITED` (can serve the most recent 288 blocks per BIP 159). You can make assumptions (e.g. lack of `NODE_NETWORK` and `NODE_NETWORK_LIMITED` may imply SPV peers), but there are no guarantees.  
> **username_2**: Thank you so much! I used getpeerinfo via the console and was able to obtain the services names as described. "servicesnames": [ "NETWORK", "WITNESS", "NETWORK_LIMITED" ], Is there any significant info with regard to the "connection type" param? From my peers I got: "connection_type": "outbound-full-relay" (this is the most significant type for my peers ~ 80%), and "connection_type": "block-relay-only"  
> **username_1**: @username_2 No, there is not. It is just what your node has configured that particular connection to be. Some connections are limited to block relay only, whether that is because the peer requested it, or your node is conserving bandwidth. It has no relation to the services offered and whether the peer is validating.  

---

