<p>The <code>-maxconnections</code> setting primarily controls how many <em>inbound</em> connections a peer can accept. The number of outbound ones is independently limited (~10), so unless <code>-maxconnections</code> is set lower than 10, it doesn't affect outbound connections.</p>
<p>My mental model is that inbound connections are primarily a service you provide to the network. As your node cannot control who connects to you (apart from evicting &quot;bad&quot; connections when the limit of connections gets exceeded), quality of inbound connections isn't guaranteed. Certainly they may be helpful too, but in adversarial settings we cannot assume that. Thus, we generally assume outbound connections are &quot;better&quot; (though quantifying this is very hard).</p>
<p>So I believe the answer to your question of &quot;what should I set <code>-maxconnections</code>&quot; to is simply as much as you can tolerate, but there are few benefits to you personally.</p>
<p>Let me go into some aspects that this setting impacts:</p>
<ul>
<li>(+) <strong>eclipse/partition resistance</strong>: More connections does mean that you're more likely to have at least one honest connection to the network, but with the caveat that due to the limited control we have over inbound connections, outbounds are far better to accomplish that. Of course, connectable slots are a (sometimes) scarce resource too, which restricts how many outbound connections is reasonable to have nodes make.</li>
<li>(-) <strong>(average) bandwidth</strong> There is a bandwidth impact from having more connections (something that <a href="https://github.com/bitcoin/bips/blob/master/bip-0330.mediawiki" rel="noreferrer">Erlay</a> aims to partially address), primarily because every transaction will be announced at least once over every connection (~36 bytes per transaction), in one of the two directions. On average this adds maybe ~1 KiB/s per connection in an honest steady-state situation (block-only connections have a lower impact).</li>
<li>(-) <strong>block propagation latency</strong> More connections means more nodes you'll announce newly discovered blocks too; if they all fetch those at the same time, your network connection may get saturated to the point where it increases the latency of your connections.</li>
<li>(-) <strong>memory usage</strong> This is probably the most important impact a connection has in common situations. The various buffers and data structures used to keep connection state can (especially in adversarial conditions) amount to several megabytes. There are certainly systems running Bitcoin nodes that couldn't tolerate thousands of times that.</li>
<li>(-) <strong>CPU usage</strong> I don't really have hard numbers for this, but I expect that the CPU impact of an additional connection is relatively low. After all, you won't see meaningfully more blocks or transactions with more connections, as even with a single (honest) one you're expected to see ~all of them. There is cost on the P2P side of things too (just shuffling messages around, checksumming them, decrypting them in case of BIP324). And in adverserial situations, an attacker can probably saturate the Bitcoin Core network thread with just a few connections anyway.</li>
</ul>
<p>There is a <a href="https://github.com/bitcoin/bitcoin/pull/28463" rel="noreferrer">project</a> to increase the default number of inbound connection slots in Bitcoin Core if they're blocks-only connections (which have lower bandwidth/memory costs), with a prospect to increase the default outbound connection limit later.</p>

CC BY-SA 4.0
2024-01-08T15:59:48.233Z
Thanks, this is a great overview for newcomers. Nevertheless, I think it misses the essence of my question somewhat, which is the trade-off you touch upon in the paragraph "block propagation latency". Indeed, if the node has too many connections, block propagation delay will increase, so "simply as much as you can tolerate" is probably not the final word here. But I admit that this quantifying this without further assumptions, e.g., about the bandwidth of connected nodes, seems pretty hard...
real-or-random
CC BY-SA 4.0
2023-12-24T19:05:09.960Z
2023-12-24T19:12:21.133Z
2023-12-24T19:12:21.133Z
Pieter Wuille
<p>Connectivity of full nodes varies a lot, ranging from phones with mobile service to servers in data centers. Also, many nodes probably have asymmetric bandwidth.</p>
<p>Assuming the goal of maximizing utility for the Bitcoin network, is there a rule of thumb for setting the maximum number of connections (<code>-maxconnections</code>) in a full node? How was the current default value of 125 in Bitcoin Core chosen?</p>
<p>My thinking is that more connections will make it possible to learn about the existence of  (candidate) blocks and transactions earlier, but at some point bandwidth will suffer too much with the effect that transferring the data will take too long.</p>
<p>To keep the scope of the question limited, I'm primarily interested in the networking parameters and not so much in memory and CPU limitations.</p>

<bitcoin-core><network><full-node><peers><connection>
What's a rule of thumb for setting the maximum number of connections?
real-or-random
# What's a rule of thumb for setting the maximum number of connections?

(Asked by: username_0 on 2023-12-21)

Connectivity of full nodes varies a lot, ranging from phones with mobile service to servers in data centers. Also, many nodes probably have asymmetric bandwidth.

Assuming the goal of maximizing utility for the Bitcoin network, is there a rule of thumb for setting the maximum number of connections (`-maxconnections`) in a full node? How was the current default value of 125 in Bitcoin Core chosen?

My thinking is that more connections will make it possible to learn about the existence of (candidate) blocks and transactions earlier, but at some point bandwidth will suffer too much with the effect that transferring the data will take too long.

To keep the scope of the question limited, I'm primarily interested in the networking parameters and not so much in memory and CPU limitations.

**Tags:** bitcoin-core, network, full-node, peers, connection


---

## 1 answers

### Answer by username_1 on 2023-12-24. Score: 6

The `-maxconnections` setting primarily controls how many *inbound* connections a peer can accept. The number of outbound ones is independently limited (~10), so unless `-maxconnections` is set lower than 10, it doesn't affect outbound connections.

My mental model is that inbound connections are primarily a service you provide to the network. As your node cannot control who connects to you (apart from evicting "bad" connections when the limit of connections gets exceeded), quality of inbound connections isn't guaranteed. Certainly they may be helpful too, but in adversarial settings we cannot assume that. Thus, we generally assume outbound connections are "better" (though quantifying this is very hard).

So I believe the answer to your question of "what should I set `-maxconnections`" to is simply as much as you can tolerate, but there are few benefits to you personally.

Let me go into some aspects that this setting impacts:

* (+) **eclipse/partition resistance**: More connections does mean that you're more likely to have at least one honest connection to the network, but with the caveat that due to the limited control we have over inbound connections, outbounds are far better to accomplish that. Of course, connectable slots are a (sometimes) scarce resource too, which restricts how many outbound connections is reasonable to have nodes make.
* (-) **(average) bandwidth** There is a bandwidth impact from having more connections (something that [Erlay](https://github.com/bitcoin/bips/blob/master/bip-0330.mediawiki) aims to partially address), primarily because every transaction will be announced at least once over every connection (~36 bytes per transaction), in one of the two directions. On average this adds maybe ~1 KiB/s per connection in an honest steady-state situation (block-only connections have a lower impact).
* (-) **block propagation latency** More connections means more nodes you'll announce newly discovered blocks too; if they all fetch those at the same time, your network connection may get saturated to the point where it increases the latency of your connections.
* (-) **memory usage** This is probably the most important impact a connection has in common situations. The various buffers and data structures used to keep connection state can (especially in adversarial conditions) amount to several megabytes. There are certainly systems running Bitcoin nodes that couldn't tolerate thousands of times that.
* (-) **CPU usage** I don't really have hard numbers for this, but I expect that the CPU impact of an additional connection is relatively low. After all, you won't see meaningfully more blocks or transactions with more connections, as even with a single (honest) one you're expected to see ~all of them. There is cost on the P2P side of things too (just shuffling messages around, checksumming them, decrypting them in case of BIP324). And in adverserial situations, an attacker can probably saturate the Bitcoin Core network thread with just a few connections anyway.

There is a [project](https://github.com/bitcoin/bitcoin/pull/28463) to increase the default number of inbound connection slots in Bitcoin Core if they're blocks-only connections (which have lower bandwidth/memory costs), with a prospect to increase the default outbound connection limit later.

> **Comments:**
> **username_0**: Thanks, this is a great overview for newcomers. Nevertheless, I think it misses the essence of my question somewhat, which is the trade-off you touch upon in the paragraph "block propagation latency". Indeed, if the node has too many connections, block propagation delay will increase, so "simply as much as you can tolerate" is probably not the final word here. But I admit that this quantifying this without further assumptions, e.g., about the bandwidth of connected nodes, seems pretty hard...  

---

