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

multi: actor-based onion message forwarding

Public commit record

What the developer wrote

Authored by Gijs van Dam

68/100 · Adequate
multi: actor-based onion message forwarding

Add onion message forwarding capability using the OnionPeerActor for
communication. Messages are routed through a receptionist pattern where
each peer has a dedicated OnionPeerActor for handling message sends.

The OnionEndpoint uses the sphinx router for decoding and decrypting the
onion message packet and the encrypted recipient data in the payload of
the onion messages.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds the ability for LND nodes to forward encrypted 'onion messages' through intermediate peers, rather than only sending them directly. It introduces new actor-based code for routing these messages, expands the RPC API response to expose more message details, and adds integration tests. There is no direct evidence in the commit that this fixes a known security bug; it appears to be a feature implementation. However, any new message-forwarding path can affect privacy, denial-of-service exposure, and correctness of cryptographic handling, so it warrants careful review.

Recommended action

Treat as a feature commit requiring security review rather than an emergency patch. Review the OnionEndpoint's handling of malformed packets, replay prevention, rate limiting on forwarded messages, and validation of next-hop identifiers (node ID vs SCID). Verify that exposing encrypted_recipient_data and custom_records over RPC does not leak sensitive routing information. Run the new integration tests and consider fuzzing the onion message parser.

Security signals we found

01

New network-facing message forwarding path added

02

Sphinx/onion cryptography used for decryption and routing

03

RPC response now exposes encrypted recipient data and custom TLV records

04

New feature bit advertised for optional onion messages

05

Large refactor with generated protobuf churn limits line-by-line assurance

Risk score

Why this scored 39/100

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