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

lnsweep: lnwatcher needs to keep_watching if htlc in dont_settle_htlcs

Public commit record

What the developer wrote

Authored by SomberNight

73/100 · Adequate
lnsweep: lnwatcher needs to keep_watching if htlc in dont_settle_htlcs

If RHASH is in lnworker.dont_settle_htlcs, we should not reveal
the preimage. But also, we should not disregard the htlc either.

E.g. during a JIT channel open, payment going A->B->C,
C would release the preimage to B (lsp) to cover the costs of the
JIT channel-open. If the upstream A->B channel gets force-closed, B should
only pull the HTLC's funds if he is sure he can forward them to C.

lnwatcher needs to keep watching (i.e. wait) until the RHASH gets removed from
lnworker.dont_settle_htlcs, or until the CLTV of the HTLC expires.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes a logic bug in Electrum's Lightning channel-sweeping code. Previously, if a payment hash was in a special 'do not settle yet' list used during JIT (just-in-time) channel opens, the wallet would simply ignore the related HTLC output instead of continuing to watch it. That could let an attacker or a forced channel close steal funds because the wallet might stop monitoring before it was safe to claim the money. The fix makes the watcher keep watching those outputs until either the condition clears or the HTLC's deadline expires.

Recommended action

Users running Lightning nodes with JIT channel support should upgrade to a version containing this commit. Reviewers should verify that KeepWatchingTXO objects are handled in all sweep-info consumers and that no other sites compare payment_hash objects to hex-string sets.

Security signals we found

01

Funds-at-risk in forced channel close during JIT channel open

02

Incorrect set membership check (payment_hash object vs hex string) bypassed intended delay

03

Missing keep_watching logic for delayed-settle HTLC outputs

04

Lightning protocol safety: preimage revelation timing

Risk score

Why this scored 59/100

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