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

lnchannel: give offered htlcs some time to fail on restart

Public commit record

What the developer wrote

Authored by f321x

85/100 · Strong
lnchannel: give offered htlcs some time to fail on restart

Wait for 30 seconds after restart before force closing channels
due to timed-out htlcs we offered to the peer. Maybe the peer
will fail them offchain once we reestablished the connection.
This should prevent some unnecessary force closes.
We could skip the whole loop but this seems more readable.

Note: it might take some time until the lnwatcher callback calls
should_be_closed_due_to_expiring_htlcs again, however the same issue
affects the existing 30sec timeout above as well.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit changes Electrum's Lightning code so that, after the wallet restarts, it waits 30 seconds before force-closing a payment channel just because an outgoing timed payment (HTLC) looks expired. The goal is to avoid unnecessary on-chain channel closures when the peer would have cancelled the payment off-chain once the connection came back. It is a robustness/usability fix, not a clear security patch, and it does not claim to fix a known vulnerability.

Recommended action

Treat as a normal code-quality/robustness improvement. No urgent security action is indicated by the commit itself. Reviewers may want to confirm the 30-second window does not materially delay legitimate force-closes in adversarial scenarios, but the commit does not present evidence of such a flaw.

Security signals we found

01

Behavioral change in channel force-close timing

02

Adds startup grace period for expiring offered HTLCs

03

No cryptographic or validation changes

04

No mention of vulnerability, CVE, or security bug in commit message

Risk score

Why this scored 30/100

Our methodology →
Potential impact 8/30
Exploitability 4/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.