Stop using an introduction node in blinded message paths#4647
Stop using an introduction node in blinded message paths#4647TheBlueMatt wants to merge 1 commit into
Conversation
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.
|
I've assigned @jkczyz as a reviewer! |
| // Exclude Tor-only nodes when the recipient is announced. | ||
| .filter(|(_, is_tor_only, _)| !(*is_tor_only && is_recipient_announced)) |
There was a problem hiding this comment.
This filter and its comment are dead code. Since we're inside the if !is_recipient_announced branch (line 612), is_recipient_announced is always false here, so !(*is_tor_only && false) is always true — the filter never excludes anything.
The comment "Exclude Tor-only nodes when the recipient is announced" is also misleading since this branch is specifically for unannounced recipients.
Either remove the filter entirely (since it's a no-op), or if the intent is to exclude Tor-only introduction nodes for unannounced recipients too, change it to .filter(|(_, is_tor_only, _)| !*is_tor_only).
|
|
||
| // Prefer using non-Tor nodes with the most channels as the introduction node. | ||
| peer_info.sort_unstable_by(|(_, a_tor_only, a_channels), (_, b_tor_only, b_channels)| { | ||
| a_tor_only.cmp(b_tor_only).then(a_channels.cmp(b_channels).reverse()) |
There was a problem hiding this comment.
Similarly, the Tor-only component of this sort is now effectively dead — since the Tor-only filter above is a no-op (see comment there), Tor-only nodes do still get sorted to the back, but they're never excluded. If excluding Tor-only nodes for unannounced recipients isn't intended, the is_tor_only tracking and sorting could be cleaned up for clarity (just sort by channel count).
Review SummaryFound one substantive issue (dead code / misleading comment) in the refactored blinded path logic: Inline comments posted:
Cross-cutting notes:
|
3 participants
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_requestwithout 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.