search

lightningdevkit / rust-lightning

A highly modular Bitcoin Lightning library written in Rust. It's rust-lightning, not Rusty's Lightning!
Other
1.17k stars 367 forks source link

Add max_no_channel_peers to UserConfig #3382

Open domZippilli opened 1 month ago

domZippilli commented 1 month ago

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 commented 1 month ago

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

domZippilli commented 1 month ago

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 commented 1 month ago

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.

TheBlueMatt commented 4 weeks ago

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 commented 4 weeks ago

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 commented 4 weeks ago

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.