AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 32 Bitcoin

Prioritize private channels when relaying payments (#3248)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

93/100 · Strong
Prioritize private channels when relaying payments (#3248)

When relaying payments, we want to select private channels first and
keep as much liquidity available as possible in public channels, to
ensure that we don't send a `channel_update` that would otherwise
disable the public channel (and thus make the private channels also
unusable since they aren't visible by path-finding algorithms) or
limit the `htlc_maximum_msat` of this public channel (which also
indirectly applies to private channels).

We also change the order in which we select channels that have the
same visibility: we prioritize channels with smaller balances, to
ensure that we keep our larger balances for larger payments. When
balances are equal, we prioritize the largest channel, which creates
a larger inbound liquidity to allow receiving larger payments.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit changes how Eclair lightning nodes pick which outgoing channel to use when forwarding payments. The new logic prefers private (unannounced) channels first, then smaller public channels, to avoid draining or disabling the larger public channels that other nodes rely on for routing. It is a routing-optimization and operational-hardening change rather than a fix for a known exploit. The commit message explicitly frames the change as avoiding public-channel exhaustion and disabled channel_updates, which has indirect security relevance for node availability and routing reputation.

Recommended action

Treat as a normal operational improvement. Reviewers should verify that preferring private channels does not inadvertently overload private-channel peers or violate local fee/routing policies, and that the sortWith ordering is stable and deterministic. No urgent security patch action is indicated.

Security signals we found

01

Operational hardening: reduces the chance of public channel disabling due to low liquidity

02

Availability signal: preserving public channel htlc_maximum_msat indirectly protects dependent private channels

03

No input validation, cryptographic, or authorization change

04

No memory safety, concurrency, or exception-handling change

05

No CVE, advisory, or researcher attribution present in commit or references

Risk score

Why this scored 32/100

Our methodology →
Potential impact 5/30
Exploitability 3/25
Stealth signal 6/15
Affected reach 8/15
Confidence 7/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.