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

More aggressive peer scorer idle channels management (#3295)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

81/100 · Strong
More aggressive peer scorer idle channels management (#3295)

We previously lowered fees from idle channels only if our latest update
was from more than 24 hours ago, and closed them if our latest update
was more than 5 days ago and using our minimal fees.

The issue is that our channel update may have been refreshed without
changing the relay fees, for example if our peer disconnected. We don't
track when our relay fees reached the minimum amount, so we may have
a recent channel update even though we reached our minimum relay fees
weeks ago.

We use smaller durations for those thresholds to see if that helps
reclaim liquidity more aggressively.

We also disable old peers revival by default.
This feature is useful when feerates have been high for a while and
funding was thus put on hold, but when feerates are frequently below
our feerate threshold, this is wasting liquidity. It should be enabled
after a high-fee period.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit tweaks Eclair's automated liquidity-management logic so the node becomes more aggressive about lowering fees and closing channels that sit idle. It also turns off a feature that automatically re-funds old peers by default. The changes are operational/economic policy adjustments, not a fix for a software vulnerability that an attacker can exploit. There is a small operational risk that a node could close channels or lower fees more eagerly than before, but that is a business-logic trade-off rather than a security flaw.

Recommended action

Treat this as a routine operational improvement, not a security patch. Operators upgrading should review the new default `revive-old-peers = false` and `idle-channel-closing-threshold-percent = 0.075` to ensure the more aggressive idle-channel management matches their liquidity strategy. No emergency deployment is warranted.

Security signals we found

01

Operational policy change, not a vulnerability fix

02

New configuration parameter idle-channel-closing-threshold-percent with a 0-50% guard

03

Default behavior change: old-peer revival disabled by default

04

Tighter thresholds may increase channel closure / fee-change frequency

05

API response type changed from Boolean to String for configurePeerScorer

Risk score

Why this scored 24/100

Our methodology →
Potential impact 4/30
Exploitability 2/25
Stealth signal 3/15
Affected reach 5/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.