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

Make `DefaultMessageRouter` use the context to pad/compact paths

Public commit record

What the developer wrote

Authored by Matt Corallo

93/100 · Strong
Make `DefaultMessageRouter` use the context to pad/compact paths

After much discussion in #3246 we mostly decided to allow
downstream developers to override whatever decisions the
`DefaultMessageRouter` makes regarding blinded path selection by
providing easy overrides for the selected `OnionMessageRouter`. We
did not, however, actually select good defaults for
`DefaultMessageRouter`.

Here we add those defaults, taking advantage of the
`MessageContext` we're given to detect why we're building a blinded
path and selecting blinding and compaction parameters based on it.

Specifically, if the blinded path is not being built for an offers
context, we always use a non-compact blinded path and always pad it
to four hops (including the recipient).

However, if the blinded path is being built for an `Offers` context
which implies it might need to fit in a QR code (or, worse, a
payment onion), we reduce our padding and try to build a compact
blinded path if possible.

We retain the `NodeIdMessageRouter` to disable compact blinded path
creation but use the same path-padding heuristic as for
`DefaultMessageRouter`.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit changes how Lightning Dev Kit builds private 'blinded paths' used to route messages without revealing the recipient's exact location. It makes the default router choose shorter, more compact paths when the message is part of a BOLT 12 offer that might be encoded in a QR code, and longer, padded paths otherwise. The goal is to balance privacy with fitting data into QR codes and payment onions. The change itself is a privacy-tuning improvement, not a direct security bug fix, though it touches code that affects how easily a recipient can be identified.

Recommended action

Review the privacy implications of the new context-aware defaults, especially the zero-dummy-hop case for StaticInvoiceRequested. Ensure downstream users are aware that BOLT 12 offer paths are now shorter and that NodeIdMessageRouter disables compact paths. No urgent patch is required, but consider whether the privacy guarantees are adequately documented and whether tests cover edge cases where no suitable intermediate peers exist.

Security signals we found

01

Privacy/path-length trade-off: shorter paths for QR-code offers reduce anonymity set size

02

Async Payments static invoice context allowed zero dummy hops, maximizing size savings but minimizing recipient privacy

03

NodeIdMessageRouter now strips SCIDs and disables compact paths, preventing a previously noted privacy leak

04

Documentation updated to note that one-hop paths with announced introduction nodes may affect privacy

05

No direct memory-safety, cryptographic, or authorization vulnerability visible in diff

Risk score

Why this scored 35/100

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