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

witness beacon: report node-ID next hop to the on-chain HTLC interceptor

Public commit record

What the developer wrote

Authored by bitromortac

73/100 · Adequate
witness beacon: report node-ID next hop to the on-chain HTLC interceptor

Extend the on-chain interceptor path in the witness beacon to expose a
node-ID next hop, mirroring the off-chain path. A node-ID next hop has no
outgoing channel of its own, so the beacon reports hop.Exit as the outgoing
channel (via ForwardingInfo.NextHopChannel().UnwrapOr) and the requested
next node's public key. The RPC boundary maps that to the NodeIDForwardSCID
sentinel so the forward is not misread as a final receive.

This is the requested next hop, not the channel eventually selected by
non-strict forwarding, so the beacon deliberately does not resolve it
against the circuit map.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This change fixes a reporting gap in LND's 'witness beacon,' a component that watches on-chain transactions and tells the HTLC interceptor where a payment should go next. Previously, when the next hop was identified by a node ID rather than a specific channel ID, the on-chain interceptor only reported an 'exit' channel and omitted the actual next node's public key. The patch makes the on-chain path mirror the off-chain path by also reporting the requested node's public key and using a special sentinel value so clients don't mistake the forward for a final payment delivery. It is best understood as a correctness/parity fix that prevents misrouting or misclassification of intercepted forwards.

Recommended action

Review the RPC mapping to NodeIDForwardSCID in related files to ensure the sentinel is consistently handled, and confirm that downstream interceptor clients correctly interpret OutgoingNodeID alongside OutgoingChanID. Consider whether any existing on-chain interceptor integrations were relying on the previous incomplete reporting and need updates.

Security signals we found

01

Missing security-critical metadata in on-chain interception path

02

Behavioral parity between on-chain and off-chain HTLC interception

03

Potential misclassification of node-ID forwards as final receives

04

Non-strict forwarding semantics preserved (no circuit-map resolution)

Risk score

Why this scored 25/100

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