Bitcoin Core connection logic is split into two main types: inbound and outbound connections. A node will always try to establish and maintain a certain number of outbound connections, whereas only a subset of nodes will accept inbound ones.

Inbound connections

Nodes accepting inbound connections are usually known as reachable nodes, and they are a fundamental resource for the P2P network to operate. Each outbound connection created by a node maps to an inbound connection accepted by another, meaning that connectivity is not possible if some nodes do not accept inbound connections. However, inbound connections are inherently less secure than outbounds, given we do not chose them, and therefore, they could be requested by nodes controlled by the same entity. Hence, the security model of Bitcoin Core’s P2P network relies on outbound connections and we will generally assume all inbound can be malicious.

As per the default maximum amount of inbound connections, when applicable, it is currently 114:

mMaxConnections = 125
m_max_outbound = m_max_outbound_full_relay + m_max_outbound_block_relay + nMaxFeeler;
							 = 8 + 2 + 1 = 11
nMaxInbound = nMaxConnections - m_max_outbound
						= 125 - 11 = 114

Outbound connections

Outbound connections are established and managed by our own node to make sure that our own transactions, if any, can reach the rest of the network, and that our chain of blocks is up to date. At the time of writing, a node maintains three different types of outbound connections:

• full-relay outbound connections, that is, connections initiated by the node and intended to exchange transactions, blocks, and node addresses. There are usually up to 8 of these
• block-relay only connections, intended for block data only. There are usually up to 2 of these
• feeler connections intended to test out the reachability of our potential peers but also, used to try to get out of a “stale tip” state when applicable. Our node creates up to 1 of this type

When establishing outbound connections, the logic for which one to create (if any 1️⃣) goes as follows:

• First, if anchors are defined and we haven’t reached our block-relay only limit, we create a BLOCK_RELAY connection and flag it as anchor 2️⃣
• Otherwise, if we haven’t reached our full-relay outbound limit, we create an OUTBOUND_FULL_RELAY connection
• Otherwise, if the block-relay only limit has not been reached (independently of anchors) we create a BLOCK_RELAY connection, but not flag it as anchor
• Otherwise, if a stale tip is detected, which happens if a new chain tip has not been found after 30 min (and it is checked at 10 min intervals), we create an extra (short-lived 3️⃣) OUTBOUND_FULL_RELAY connection. This is used to prevent being eclipsed, but has the caveat that, as long as an attacker can feed us a valid tip once every 30 min, he will prevent us from triggering it
• Otherwise, if we are not doing IBD and our extra block-relay only connection timer has gone off (which happens once every 5 min on average, sampling from an exponential distribution) we create an additional short lived BLOCK_RELAY connection. The purpose of this connection is also to prevent against eclipse attacks. Notice how this is completely independent from detecting a stale tip, so it is complementary to the previous eclipse attack prevention, specially designed to circumvent its caveat
• Otherwise, if our feeler connection timer has gone off, we create a FEELER connection. This connection is meant to grab peers from our addrman new table and test them, in order to move them to out tried table when valid
• Finally, if none of the above hold, we are running on defaults (that is, m_max_outbound_full_relay == MAX_OUTBOUND_FULL_RELAY_CONNECTIONS) and we’ve reached the outbound full relay max connection limit, we try to create an additional OUTBOUND_FULL_RELAY connection ****to one of our supported networks were we have no outbound full-relay peers in order to diversify our connectivity and aiming to reach, at least, one full-relay peer per supported network

If none of the aforementioned conditions are met, no additional connection is performed during this cycle.