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

lnpeer/lnworker: refactor htlc_switch

Public commit record

What the developer wrote

Authored by f321x

58/100 · Thin
lnpeer/lnworker: refactor htlc_switch

refactor `htlc_switch` to new architecture to make it more robust
against partial settlement of htlc sets and increase maintainability.
Htlcs are now processed in two steps, first the htlcs are collected into
sets from the channels, and potentially failed on their own already.
Then a second loop iterates over the htlc sets and finalizes only on
whole sets.

# Conflicts:
# electrum/lnpeer.py
✓ Descriptive subject✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This is a large internal refactor of Electrum's Lightning code that handles incoming multi-part payments (MPP). The change restructures how individual HTLCs are collected into sets and how those sets are validated, forwarded, or settled. The commit message frames it as improving robustness and maintainability, not as a security fix. The diff shows new consistency checks for trampoline onions, stricter state transitions for payment sets, and a wallet database upgrade to migrate old state. There is no vendor statement that this fixes a known vulnerability, and no CVE or researcher attribution is present in the supplied materials.

Recommended action

Treat this as a high-risk maintenance refactor rather than a confirmed vulnerability fix. Reviewers should focus on: correctness of the new two-phase HTLC/set state machine, whether `SETTLING` sets can get stuck without failure paths, the wallet DB migration logic for old forwarding/swap state, and whether the moved expiry/cltv checks could change behavior for in-flight payments. Regression testing of MPP, trampoline forwarding, hold invoices, and submarine swaps is strongly advised before release.

Security signals we found

01

Large refactor of payment-settlement state machine with new explicit state transitions

02

New validation/consistency checks for trampoline onion payloads and multi-trampoline MPP

03

Constant-time comparison added for payment secret

04

Invoice expiry and min-final-cltv-delta checks moved earlier in HTLC processing

05

Wallet database upgrade required to migrate persisted MPP/unfulfilled-HTLC state

06

Hold-invoice and swap cleanup paths changed (unregister_hold_invoice now fails pending HTLCs if no preimage)

07

No CVE, advisory, or vendor security statement present in commit or supplied references

Risk score

Why this scored 59/100

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