Add max_no_channel_peers to UserConfig

[domZippilli]

The MAX_NO_CHANNEL_PEERS constant provides helpful protection from an excessive number of peer connections, but as a constant, isn't user modifiable. The desired number of non-channel peers may vary depending on the application, so here we make it configurable.

[TheBlueMatt]

How many do y'all want? I'm of half a mind to just 10x it and call it a day.

[domZippilli]

Today, 2500 -- tomorrow, THE WORLD!

We currently run a fork with 2500. This is presently plenty of headroom, but I might want to tweak it down...

[br0thersharp]

right. depending on the node's purpose and planned usage, a node operator might want to configure this to be higher or lower. Given how this impacts resource usage, it makes sense for this to be a tunable parameter.

[domZippilli]

Suggested change

	/// peers is reached, we will not accept any new non-channel peer connectionss. This could mean
	/// peers is reached, we will not accept any new non-channel peer connections. This could mean

[TheBlueMatt]

Given how this impacts resource usage, it makes sense for this to be a tunable parameter.

I'm not entirely sure that it does impact resource usage that much. The maximum number of pre-funded channels definitely does, but no-channel peers are incredibly cheap (in ChannelManager). They may cost bandwidth for gossip, but IMO that is best dealt with at the gossip layer, not in the peer count limit.

[domZippilli]

no-channel peers are incredibly cheap

Well, would no limit at all be better?

The options I can think of are (1) no limit, (2) a one-size-fits-all limit, or (3) a customizable limit with a sensible default.

[TheBlueMatt]

Well, would no limit at all be better?

I mean, there is some cost, just not a hell of a lot. Not sure that actually no limit is the right answer given there is some non-zero cost, even if its tiny.

[dunxen]

Maybe leave the current limit as default, make it configurable, and then just add to the doc comment there is a low cost to no-channel peers, but may lead to a higher cost at gossip/bandwidth and use responsibly etc.

[domZippilli]

Maybe leave the current limit as default, make it configurable, and then just add to the doc comment there is a low cost to no-channel peers, but may lead to a higher cost at gossip/bandwidth and use responsibly etc.

SGTM, of course. I think this PR will get you that, minus the doc comment.

[domZippilli]

Hey, I wanted to bump this. I'm happy to rebase it or whatever is necessary. I think the bigger blocker is consensus that this should be configurable.

The main thing we don't seem to know/agree on above is the "cost" of a peer. I'd love to bring some data on the cost of a peer so that we can decide on a number, but it's not fixed. Two things can vary:

• How much your typical peer "costs."
  • For example, last year, our node had an issue with a large population of peers that were sending a from-zero gossip sync every time they connected. We got that to change, and reduced peer-handling resource costs by 99%.
  • The latter is a bug, of course, but any kind of designed behavior could emerge in a Lightning client on either side of peer connection (ourselves, or a peer) that makes this cost increase/decrease.
• What you are able to "pay."
  • Fairly obvious here, but enterprisey routing nodes or custodial wallets have far greater resource access and can therefore support forwarding gossip or answering pings for a much larger population of non-counterparty peers than say, someone bootstrapping without a lot of financial support. For the latter, a fixed amount of 2500 may be far too high and lead to resource exhaustion.