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

Stop using an introduction node in blinded message paths

Public commit record

What the developer wrote

Authored by Matt Corallo

73/100 · Adequate
Stop using an introduction node in blinded message paths

lnd is preparing to ship a release with opt-in onion messages
without support for forwarding onion messages from non-channel
peers. This breaks the common BOLT 12 OM flow today where we
direct-connect to the blinded path introduction point and send the
`invoice_request` without a channel. For CLN it turns out this is
fine as they never select a peer for their introduction point at
all. However, for LDK this would break existing nodes as nodes
might now pick an lnd peer as an introduction node but it won't
forward the onion message.

For now, we just drop the separate introduction point selection and
just always use ourselves as an introduction point (assuming we're
an announced node).

This should also have the side-effect of making offers marginally
more robust, which may be worth it, even if it sucks to drop any
pretense of privacy.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit changes how LDK creates hidden ("blinded") messaging paths for BOLT 12 offers. Previously, LDK tried to pick a well-connected peer as an "introduction node" to receive messages on your behalf, which improved privacy. Because lnd nodes will soon refuse to forward such messages from peers without a channel, LDK now always uses the offer creator itself as the introduction node (if publicly announced). This avoids broken offers but reduces privacy. It is a compatibility/reliability fix, not a patch for an active exploit.

Recommended action

Treat as a privacy-affecting compatibility change rather than a critical security fix. Users relying on BOLT 12 offer privacy should be aware that announced LDK nodes now expose themselves as the introduction point. No urgent patching is required for security reasons, but downstream projects should review whether this privacy trade-off is acceptable and whether additional path-length/dummy-hop configuration is needed.

Security signals we found

01

Privacy reduction: blinded paths no longer use an external introduction node for announced recipients, exposing the recipient's node ID as the path entry point

02

Removed recipient anonymity heuristic: MIN_PEER_CHANNELS, Tor-only filtering, and most-connected-peer selection are gone for announced nodes

03

Interoperability fix: avoids lnd peers dropping invoice_request onion messages from non-channel peers

04

No cryptographic weakness, memory-safety bug, or authorization bypass present in diff

Risk score

Why this scored 40/100

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