Bitcoin Core – What is the rule of thumb for setting the maximum number of connections?

that much -maxconnections Settings are mainly inbound Connections that the peer can accept. The outbound count is independently limited (~10). -maxconnections If set lower than 10, outbound connections will not be affected.

My mental model is that inbound connections are primarily a service you provide to the network. Nodes have no control over who connects to you (except for removing “bad” connections when they exceed connection limits), so the quality of inbound connections is not guaranteed. Certainly those can be helpful too, but that cannot be assumed in a hostile situation. Therefore, we generally assume that outbound connections are “better” (but this is very difficult to quantify).

So I believe the answer to the question, “What should I set up?” -maxconnections” is simply as much as you can tolerate, but there is little personal benefit to be gained.

Let’s look at some of the aspects that this setting affects.

• (+) Eclipse/Partition Resistance: More connections means there is a higher chance of having at least one honest connection to the network, but with the caveat that outbound is much better at achieving this due to limited control over inbound connections. Of course, connectable slots are also (sometimes) a scarce resource, limiting the number of outbound connections a node is suitable to make.
• (-) (average) bandwidth Having more connections (a problem Erlay aims to partially solve) has an impact on bandwidth. This is primarily because every transaction is announced at least once for every connection (~36 bytes per transaction) in one of two directions. On average, this adds up to about 1 KiB/s per connection in an honest steady-state situation (block-only connections have a lower impact).
• (-) Block propagation delay time More connections mean more nodes to announce newly discovered blocks. Getting them all at the same time can saturate your network connection and increase connection latency.
• (-) memory usage This is probably the most important impact of connectivity in a typical situation. The various buffers and data structures used to maintain a connection can reach several megabytes (especially under adversarial conditions). There are certainly systems running Bitcoin nodes that cannot withstand thousands of times more.
• (-) CPU usage There are no specific numbers for this, but the CPU impact of the additional connections is expected to be relatively low. After all, just as you would expect to see every single (honest) block or transaction, you cannot see more blocks or transactions with more connections in a meaningful way. There is also a cost on the P2P side (with BIP324 all you have to do is shuffle, checksum, and decrypt the message). And under unfavorable circumstances, an attacker can saturate the Bitcoin Core network threads with just a few connections anyway.

There are projects to increase the default number of inbound connection slots for block-only connections (lower bandwidth/memory costs) in Bitcoin Core, and possibly increase the default outbound connection limit in the future.