Had few questions earlier: https://www.reddit.com/r/Bitcoin/comments/n1fg1y/maximum_number_of_outbound_full_relay_connections/. I think most of them are answered now.

-0. I don't see the use case. Mind explaining?

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• doc: update helps for addnode rpc and -addnode/-maxconnections config options #21710 (doc: update helps for addnode rpc and -addnode/-maxconnections config options by jonatack)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

-0. I don't see the use case. Mind explaining?

Not sure if I understand your question correctly. If you are asking about usecase for maxoutfullrelay=0, below are two examples:

Example 1: User wants to have 2 Block Relay outbound connections and 1 Full Relay outbound connection with his other node

Example 2: User wants to have only Block Relay outbound connections (2) for a while

If you are asking about overall usecases for this option maxoutfullrelay, they are already mentioned above and not possible using maxconnections.

I also don't understand why a user would want to reduce the number of outbound connections- having multiple connections to the network is fundamental to safety against eclipse attacks. If a user configured the node to only have outbound block-relay-only connections, they wouldn't be participating in addr relay, so wouldn't have a diverse addrman to identify candidates to connect to. If the user was interested in, for example, reducing bandwidth usage, they could startup in -blocksonly, and give the trusted peer forcerelay permission (see https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-traffic.md for more details).

I also don't understand why a user would want to reduce the number of outbound connections- having multiple connections to the network is fundamental to safety against eclipse attacks.

1. Default is 8 and number of outbound full relay connections can only be reduced by power users who normally experiment with different options in bitcoin.conf
2. Already mentioned few examples above. One more example: Consider someone running a business has two nodes. Node A for personal usage and Node B for business. Node A runs with default settings but user doesn't want Node B to connect with random 8 nodes around the world. So user wants to configure Node B to only have 2 Outbound Full Relay connections (One with Node A) and 2 Block Relay only connections. How would you configure this right now? I don't think its possible. So user will save maxoutfullrelay=1 and use addnode to connect with Node A.
3. Having multiple connections is good IMO but everyone has different needs and the way they want to use the network. I would like to have MAX_OUTBOUND_FULL_RELAY_CONNECTIONS = 32 and it can be done with something like this: https://bitcoin.stackexchange.com/a/105879/ however according to @laanwj (in PR Add a -maxoutbound option for use on pool servers to increase bitcoin network connectivity. #6014):

Making it easily possible to increase the default outgoing connections above 8 would put undue load on the network. See the discussion in #4687 as well as many previous discussions.

But this can not be merged unless you cap the maximum to 8.

So I capped the maximum to 8 in this PR.

4. I am not a fan of hardcoded values for certain things. Mentioned similar approach in other PR to use Default, MIN and MAX: [p2p] Introduce node rebroadcast module  #21061 (comment) I don't even know what should be the response if someone asks why is this 30 and not 25? Or why is this 8 and not 10 or 6? There should be RANGE in which user can decide the value if required.
5. IMO it makes things difficult for anyone spying if users have different values for lot of things in Bitcoin Core instead of creating patterns with hardcoded values that do not change for years.

If a user configured the node to only have outbound block-relay-only connections, they wouldn't be participating in addr relay, so wouldn't have a diverse addrman to identify candidates to connect to.

maxoutfullrelay=0 and no nodes added with addnode is just one of combinations and not necessary everyone will use it. Users who don't care to experiment with bitcoin.conf options will use default value 8 so nothing changes for many users.

If the user was interested in, for example, reducing bandwidth usage, they could startup in -blocksonly, and give the trusted peer forcerelay permission (see https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-traffic.md for more details).

Thanks for sharing this. However -blocksonly=1 is not same as some of the examples I mentioned above for different values of maxoutfullrelay

2. In that case they can just run with -connect=<ip adres of A>. If you have a trusted node that's already well connected, there is no need to make more connections yourself.

3. What different needs do people have? You can say care more about bandwidth or computing resources, but if that's the case, they can just reduce the number of connections. I think that's a more useful trade-off than setting the number of block-only connections.

4. I understand hardcoded constants aren't appealing to everyone's aesthetics, but that's not a good basis for doing design. Real-world protocol implementations are full of hardcoded constants (have you ever looked at https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L42L153 ?). Just because there is a range of potentially reasonable numbers doesn't mean it needs to be configurable - it just means several options existed and the person who coded it up picked one & convinced others that it's a decent choice. Things need to be configurable when you can give concrete advice about when someone should change it. I don't see that here.

5. Quite the contrary. Almost nobody changes defaults. Making things configurable just makes users who change them stand out.

@sipa Thanks for your response. Closing this PR for now. Will reopen if I have better arguments and some data to support adding such option.