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

onionmessage: use BackpressureMailbox for onion peer actors

Public commit record

What the developer wrote

Authored by Gijs van Dam

78/100 · Adequate
onionmessage: use BackpressureMailbox for onion peer actors

This commit adds per-peer backpressure control to the onion message
actor system by introducing a BackpressureMailbox that uses Random
Early Detection (RED) to probabilistically drop messages when the
per-peer queue depth exceeds a configurable threshold.

The OnionActorFactory type now accepts variadic ActorOptions, allowing
the spawn call site (brontide) to provide per-peer mailbox configuration.
A DefaultOnionActorOpts helper provides the standard RED thresholds so
callers don't need to wire up the BackpressureMailbox manually.

Key changes:
- OnionActorFactory signature extended with ...ActorOption[*Request,
*Response] so backpressure policy is no longer baked into the factory.
- NewOnionActorFactory drops its shouldDrop parameter; it forwards opts
through to serviceKey.Spawn.
- DefaultOnionActorOpts(shouldDrop) returns the default backpressure
options (BackpressureMailbox + DefaultOnionMailboxSize).
- peer.Config gains OnionActorOpts callback for per-peer customization.
- server.go creates default opts once and returns them for every peer.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit adds a safety valve to how LND handles 'onion messages'—a type of private Lightning Network message. Before this change, a flood of onion messages from a peer could fill up an internal queue and stall the connection handler. Now, when a per-peer queue gets too full, messages are probabilistically dropped using a technique called Random Early Detection (RED), and the handler uses a timeout so it cannot block forever. The change is defensive hardening rather than a fix for a known active attack.

Recommended action

Treat as a defensive hardening patch. Review the RED threshold math and the fallback drop-all path for correctness, and consider whether 50/40 thresholds are adequate for expected onion-message load. Monitor for follow-up commits that add per-peer customization, since the current callback returns identical defaults for all peers.

Security signals we found

01

Adds backpressure/RED-based probabilistic dropping to prevent unbounded mailbox growth for onion messages

02

Replaces unbounded context.TODO() with a 30-second timeout around actor Tell to avoid readHandler stalls

03

Comment frames change as preventing a blocked readHandler, indicating prior stall risk

04

Default mailbox size is small (50) with RED starting at 40, suggesting DoS/queue-flooding concern

05

No CVE, advisory, or vendor security disclosure is present in the commit or supplied references

Risk score

Why this scored 40/100

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