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

Don't store duplicate settlement messages (#3336)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

88/100 · Strong
Don't store duplicate settlement messages (#3336)

If our peer is buggy, or if we have a bug in our message queue, we may
receive duplicate settlement messages for pending HTLCs. It is fine to
handle them and relay the settlement downstream (instead of immediately
force-closing), but we shouldn't store the duplicate settlement in the
remote changes, otherwise it will trigger a force-close when exchanging
`commit_sig`.
✓ 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 patch fixes a bug in Eclair's Lightning payment channel code. If a buggy peer (or internal message queue bug) sent the same HTLC settlement message twice, Eclair would store the duplicate in its list of pending remote changes. Later, when signing the next commitment, that duplicate would be treated as a conflicting update and trigger an unnecessary force-close of the channel. The fix ignores duplicate settlement messages instead of storing them again, while still allowing the first one to be relayed downstream. It also still force-closes if a conflicting (different) settlement arrives for the same HTLC.

Recommended action

Treat as a defensive hardening/bugfix with security relevance: merge and backport to supported release branches. Operators should upgrade to avoid unnecessary channel force-closes caused by duplicate settlement messages from peers. No immediate incident response is required unless unexplained force-closes have been observed.

Security signals we found

01

Avoids unilateral channel force-close due to duplicate settlement messages

02

Prevents duplicate remote proposal accumulation in commitment changes

03

Maintains relay of first valid settlement to downstream HTLC origin

04

Still permits force-close when conflicting settlement contents are received

05

Adds unit tests for duplicate UpdateFulfillHtlc and UpdateFailHtlc handling

Risk score

Why this scored 60/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 8/15
Affected reach 10/15
Confidence 8/10
Evidence quality 4/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.