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

multi: OnionPeerActor for per-peer message support

Public commit record

What the developer wrote

Authored by Gijs van Dam

83/100 · Strong
multi: OnionPeerActor for per-peer message support

Introduce a fat OnionPeerActor that handles the full onion message
processing pipeline for each peer connection. The actor decodes incoming
onion messages, determines the routing action (forward or deliver),
executes the action via PeerMessageSender, and dispatches updates to
subscribers via OnionMessageUpdateDispatcher.

Key components:
- OnionRouter interface abstracting sphinx router operations
- PeerMessageSender interface for forwarding to other peers
- OnionMessageUpdateDispatcher interface for subscriber notifications
- OnionActorFactory for spawning per-peer actors with shared deps
- Full test suite calling Receive() directly with NoOpReplayLog
✓ 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 adds a new subsystem for handling 'onion messages' in the LND Lightning node. Onion messages are a way to send data through the Lightning network without a payment. The change introduces a per-peer actor that decodes, routes, and forwards or delivers these messages. It is a large feature addition with new interfaces, routing logic, and tests. There is no direct evidence in the commit that this fixes a known security bug; it appears to be new functionality.

Recommended action

Treat this as a feature commit rather than a security patch. Reviewers should focus on whether the new onion message path introduces denial-of-service or routing risks, particularly around replay protection, path length limits, error handling, and how the actor system isolates per-peer state. No immediate security patch action is indicated by the commit itself.

Security signals we found

01

New network-facing message handling path added (onion messages)

02

Use of actor framework for per-peer concurrency isolation

03

Blinded route processing and ephemeral key derivation

04

Replay protection delegated to NoOpReplayLog in tests; production replay log choice not visible in this commit

05

TODO comment notes magic constant 10 used for incomingCltv replay protection

06

Error paths tested for invalid onion blobs and dispatcher failures

Risk score

Why this scored 31/100

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