[bug]: Relax restricted peer access rules

[ziggie1984]

The new introduced access manager in LND 19 is very restrictive by disallowing new inbound and outbound connections (no channel peers) after a certain peer count threshold (30 by default). This can be exploited by consuming all available connection slots, thereby hindering our ability to establish new peer connections and open channels to new peers (or allowing new inbound capacity).

To address this, I propose the following adjustments to the access manager's behavior:

1. Unrestricted Outbound Connections: We must always allow outbound connections, irrespective of the current peer count. This guarantees our node's continuous ability to initiate connections with new peers and expand its channel network.

2. Conditional Inbound Connection Allowance: For inbound connections, a new peer should be granted a temporary grace period upon connection. During this brief time-window, the peer is expected to open a channel. If a channel is not established within this specified timeframe, the peer should be automatically disconnected.

[yyforyongyu]

We should increase the default and maintain it as is. Then any outbound connection initialized via connect can bypass this connection limit, and have its own limit - maybe a significantly larger value, but still it cannot be unbounded. This is similar to how bitcoind handles its connection resources.

For inbound connections, a new peer should be granted a temporary grace period upon connection. During this brief time-window, the peer is expected to open a channel.

This would be great but I don't think it's feasible without specs update - like how can a peer signal its intention to open channels?

[BhaagBoseDK]

the restricted connections can be kept in a round robin queue, last in first out.

[ziggie1984]

This would be great but I don't think it's feasible without specs update - like how can a peer signal its intention to open channels?

I was thinking just giving the peer some time like for example 1 minute if he hasn't opened a channel by then we disconnect ?

[yyforyongyu]

I was thinking just giving the peer some time like for example 1 minute if he hasn't opened a channel by then we disconnect ?

How can we distinguish them? This would mean we will disconnect all peers eventually?

[MegalithicBTC]

An LND user running something like an LSP routinely needs to allow hundreds of nodes to connect to it, indeed these nodes might be set "on startup" to automatically connect to the LSP.

Seems like some kind of "FIFO" would be necessary in this case, with some kind of logic like "when we reach the restricted limit, drop the oldest restricted connection to make room for the new one."

Or even more sophisticated could be -- because I think LND stores ping times -- an LRU-style or latency-aware eviction policy: cull the restricted peer with the worst (highest) ping time.

[Crypt-iQ]

This can be exploited by consuming all available connection slots, thereby hindering our ability to establish new peer connections and open channels to new peers (or allowing new inbound capacity).

This was known in the design and is intentional. The real solution is to segment outbound / inbound peers and not prioritize inbound peers. Accepting inbound peers even temporarily is bad and can lead to some serious issues. Conditional inbound acceptance also works.