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

htlcswitch/hop: decode next_node_id blinded hops

Public commit record

What the developer wrote

Authored by bitromortac

68/100 · Adequate
htlcswitch/hop: decode next_node_id blinded hops

Some implementations (e.g. Core Lightning) identify the next hop in a
blinded route by the next node's ID (next_node_id) instead of a short
channel ID. Decode such a hop into a node-ID next hop, the Right of
ForwardingInfo.NextHop, holding the next node's public key. The switch
resolves that key to one of our channels with the peer in a later commit.

BOLT 4 requires a non-final blinded hop to carry exactly one of
short_channel_id or next_node_id, so a hop that sets both is rejected.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds support in LND for a different way of identifying the next hop in a private ('blinded') Lightning payment route. Previously LND expected the next hop to be identified by a channel ID; now it also accepts the next node's public key, which some other Lightning implementations already use. The change also enforces a BOLT 4 rule that a blinded hop must set exactly one of those two identifiers, rejecting any hop that sets both. It is primarily an interoperability/standards-compliance change, not a clear security fix, though the new mutual-exclusivity check removes a small ambiguity in route parsing.

Recommended action

Treat as a normal standards-compliance/interoperability commit. Include in routine review and testing; no urgent security response required. Verify downstream switch logic correctly resolves a node-ID next hop to an outgoing channel before this code path is used in production routes.

Security signals we found

01

New validation enforces BOLT 4 mutual exclusivity of short_channel_id and next_node_id in blinded route data

02

Previously ambiguous or unhandled next_node_id forwarding case now explicitly decoded

03

No memory-safety, cryptographic, or authorization changes observed

04

No vendor disclosure, CVE, or researcher attribution present in commit

Risk score

Why this scored 29/100

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