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

htlcswitch: forward node-ID blinded hops via non-strict forwarding

Public commit record

What the developer wrote

Authored by bitromortac

81/100 · Strong
htlcswitch: forward node-ID blinded hops via non-strict forwarding

Fixes lightningnetwork/lnd#10937: forward a blinded-route payment when the
recipient identifies the next hop by node ID rather than a short channel
ID. The htlcPacket carries the decoded next hop to the switch, whose
handlePacketAdd resolves the pubkey to the peer's links via getLinks() and
lets the existing non-strict forwarding logic load-balance across the
peer's channels.

outgoingChanID stays a ShortChannelID. It is the persisted CircuitKey and
is set to the selected channel after non-strict selection. The circular
route check filters candidate channels before selection.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit fixes a bug in LND's payment forwarding for 'blinded routes'—a privacy feature in the Lightning Network. Previously, if the next hop was identified by node ID rather than a specific channel ID, the payment could not be forwarded correctly. The change lets LND resolve the node ID to any active channel with that peer and load-balance across them. It also adds safeguards to avoid leaking private channel identifiers in error messages, which could otherwise reveal information about hidden channels.

Recommended action

Reviewers should verify that outgoingHop is consistently populated from hop.ForwardingInfo.NextHop in all forwarding paths, that the circular-route filter correctly handles alias SCIDs, and that no other failure paths for node-ID hops emit channel_update data. Consider whether the new FailAdd path preserves the original obfuscator behavior for locally initiated payments.

Security signals we found

01

Fixes a functional forwarding failure for blinded-route payments using node-ID next hops (issue #10937).

02

Prevents private channel SCID leakage in failure messages for node-ID blinded hops by returning FailUnknownNextPeer instead of a channel_update.

03

Adds circular-route filtering for node-ID next hops before non-strict forwarding selection.

04

Adds unit tests validating correct forwarding, circular-route rejection, and failure-message type for node-ID hops.

Risk score

Why this scored 59/100

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