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

multi: represent the blinded forwarding next hop as an fn.Either

Public commit record

What the developer wrote

Authored by bitromortac

73/100 · Adequate
multi: represent the blinded forwarding next hop as an fn.Either

The forwarding next hop is currently always a short channel ID. To allow a
blinded route to identify the next hop by node ID instead, change
ForwardingInfo.NextHop to fn.Either[lnwire.ShortChannelID, [33]byte], where
the Left is the outgoing channel ID and the Right (wired up in a follow-up
commit) is the next node's public key.

This commit is a pure representational change with no behavioural effect:
every next hop is still a channel ID. The Either is encapsulated behind
ForwardingInfo methods so callers never destructure it directly: IsExit()
is the single source of truth for exit-hop detection (used by the link and
the contract court) and NextHopChannel() yields the outgoing SCID.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit is a behind-the-scenes code cleanup in the LND Lightning node. It changes how the 'next hop' for forwarding payments is stored internally so that, in the future, blinded routes can identify the next hop by a node's public key instead of only by a channel ID. The commit explicitly says it has no behavioral effect yet: every next hop is still a channel ID. There is no direct security vulnerability introduced here, but it is a preparatory step for a larger feature (blinded routing) that will need careful review when fully implemented.

Recommended action

No immediate action required. Treat this as a benign refactoring. When the follow-up commit that wires up node-ID next hops for blinded routes is reviewed, pay close attention to: validation of the node ID, non-strict forwarding channel selection, replay/loop prevention, fee validation, and ensuring exit-hop detection cannot be spoofed by a malformed Either value.

Security signals we found

01

Refactor of core HTLC forwarding data structure (ForwardingInfo.NextHop)

02

Preparation for blinded route next-hop identification by node public key

03

Encapsulation of Either type behind IsExit() and NextHopChannel() to centralize exit-hop detection

04

No behavioral change claimed by author; all next hops remain channel IDs

05

Mock serialization explicitly rejects node-ID next hops, indicating feature is not yet active

Risk score

Why this scored 18/100

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