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

multi: migrate OnionMessagePayload to lnwire.BlindedPath

Public commit record

What the developer wrote

Authored by bitromortac

83/100 · Strong
multi: migrate OnionMessagePayload to lnwire.BlindedPath

Switch OnionMessagePayload.ReplyPath from *sphinx.BlindedPath to
*lnwire.BlindedPath. The reply-path TLV is now produced and consumed by
(*lnwire.BlindedPath).Record(), which honours the BOLT 4 sciddir_or_pubkey
introduction-node form. The legacy decoder gated on a 67-byte minimum
length and silently rejected reply paths whose introduction node used
the 9-byte sciddir variant.

The legacy replyPathRecord / replyPathSize / encodeReplyPath /
decodeReplyPath / blindedHopSize / encodeBlindedHop / decodeBlindedHop
helpers and the unused ErrNoHops sentinel are deleted.

Consumers update mechanically: routing/route's
OnionMessageBlindedPathToSphinxPath replyPath parameter, the
onionmessage.OnionMessageUpdate field, the rpcserver onion-message
subscription bridge, and the lnwire test utilities now use the lnwire
type directly. The new TestOnionMessagePayloadRoundTrip "sciddir intro
reply path" subtest pins the BOLT 4 spec fix.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes how LND reads the 'reply path' inside onion messages. Previously, the code only accepted reply paths whose first hop was a full 33-byte public key, and silently ignored a valid shorter format allowed by the Lightning spec (a 9-byte short-channel-id plus direction). The change switches to a shared lnwire.BlindedPath type that correctly handles both formats, so onion messages with the shorter reply-path form are no longer dropped or mishandled.

Recommended action

Review the new lnwire.BlindedPath.Record() implementation for correct TLV length-prefix handling of both PubkeyIntro and SciddirIntro variants, and ensure the RPC sciddirResolver TODO is tracked so RPC consumers do not receive ambiguous introduction-node bytes.

Security signals we found

01

Protocol compliance fix for BOLT4 sciddir_or_pubkey introduction-node encoding

02

Legacy decoder silently dropped valid reply paths due to 67-byte minimum-length gate

03

Migration from package-local encoding to shared lnwire.BlindedPath TLV record

04

New test coverage for sciddir introduction-node reply-path round trip

05

RPC bridge TODO indicates remaining sciddir resolution work

Risk score

Why this scored 50/100

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