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

htlcswitch: classify a node-ID forward as a forward event

Public commit record

What the developer wrote

Authored by bitromortac

73/100 · Adequate
htlcswitch: classify a node-ID forward as a forward event

Now that the switch forwards blinded hops identified by node ID, a new
problem surfaces in the HTLC event stream. A node-ID next hop has no
outgoing short channel ID until non-strict forwarding selects one, so a
forward that fails before selection still carries outgoingChanID ==
hop.Exit. getEventType keys the exit hop off that sentinel, so it
misclassifies such a failed node-ID forward as a receive, mislabeling the
event streamed via SubscribeHtlcEvents (a forwarding failure reported as
a receive failure).

Two paths reach getEventType before an SCID is selected: the fail packet
built by failAddPacket and the resolution packet built by resolve, both
of which dropped the decoded next hop. Carry outgoingHop into both, and
classify a Right (node-ID) outgoingHop as a forward before the hop.Exit
check. A node-ID next hop is always a forward, never the exit hop.
✓ 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 bookkeeping bug in LND's HTLC event stream. When a payment is forwarded to a 'blinded' next hop identified only by a node public key (not a channel ID), and it fails before the switch picks an outgoing channel, the event was wrongly labeled as a 'receive' (final delivery) instead of a 'forward'. The fix carries the original next-hop information through failure and resolution paths so the event is correctly classified as a forward. It is a reporting/telemetry issue, not a code-execution vulnerability.

Recommended action

No immediate operational action beyond normal patching. Operators relying on SubscribeHtlcEvents for monitoring or accounting should update to include this fix so forward failures are not misreported as receive failures.

Security signals we found

01

Event misclassification in HTLC event stream (forward reported as receive)

02

Blinded/node-ID forwarding path introduced prior to this fix

03

Failure and resolution packets dropped next-hop metadata before fix

04

Fix adds explicit node-ID-forward classification and propagation of outgoingHop

Risk score

Why this scored 25/100

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