Blinded paths with unannounced introduction nodes by jkczyz · Pull Request #3132 · lightningdevkit/rust-lightning

jkczyz · 2024-06-17T21:06:31Z

When creating blinded paths for receiving onion messages or payments, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending messages or payments without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

Also add support for paying through a BlindedPath where we are the introduction node.

Fixes#2952.

When creating blinded paths for receiving onion messages, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending messages without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

When creating blinded paths for receiving onion payments, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending payments without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

When using advance_path_by_one when we are the introduction node, any error will result having the first hop of the input blinded path removed. Instead, only remove the first hop on success. Otherwise, the path will be invalid.

Similar to blinded paths for onion messages, if given a blinded payment path where we are the introduction node, the path must be advanced by one in order to use it.

DefaultRouter will ignore blinded paths where the sender is the introduction node. Similar to message paths, advance such paths by one so that payments may be sent to them.

When creating blinded paths, introduction nodes are limited to peers with at least three channels to prevent easily guessing the recipient. Relax this check when the recipient is unannounced since they won't be in the NetworkGraph.

TheBlueMatt · 2024-06-18T19:24:05Z

+ .map(|details| details.counterparty.node_id)
+ .map(|node_id| first_hops
+ .iter()
+ .skip(1)


nit: you dont need to skip this its always equal :)

That's why I'm skipping it :)

tnull

LGTM

jkczyz · 2024-06-17T21:06:31Z

When creating blinded paths for receiving onion messages or payments, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending messages or payments without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

Also add support for paying through a BlindedPath where we are the introduction node.

Fixes#2952.

When creating blinded paths for receiving onion messages, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending messages without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

When creating blinded paths for receiving onion payments, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending payments without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

When using advance_path_by_one when we are the introduction node, any error will result having the first hop of the input blinded path removed. Instead, only remove the first hop on success. Otherwise, the path will be invalid.

Similar to blinded paths for onion messages, if given a blinded payment path where we are the introduction node, the path must be advanced by one in order to use it.

DefaultRouter will ignore blinded paths where the sender is the introduction node. Similar to message paths, advance such paths by one so that payments may be sent to them.

When creating blinded paths, introduction nodes are limited to peers with at least three channels to prevent easily guessing the recipient. Relax this check when the recipient is unannounced since they won't be in the NetworkGraph.

TheBlueMatt · 2024-06-18T19:24:05Z

+ .map(|details| details.counterparty.node_id)
+ .map(|node_id| first_hops
+ .iter()
+ .skip(1)


nit: you dont need to skip this its always equal :)

That's why I'm skipping it :)

tnull

LGTM

jkczyz · 2024-06-17T21:06:31Z

When creating blinded paths for receiving onion messages or payments, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending messages or payments without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

Also add support for paying through a BlindedPath where we are the introduction node.

Fixes#2952.

When creating blinded paths for receiving onion messages, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending messages without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

When creating blinded paths for receiving onion payments, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending payments without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

When using advance_path_by_one when we are the introduction node, any error will result having the first hop of the input blinded path removed. Instead, only remove the first hop on success. Otherwise, the path will be invalid.

Similar to blinded paths for onion messages, if given a blinded payment path where we are the introduction node, the path must be advanced by one in order to use it.

DefaultRouter will ignore blinded paths where the sender is the introduction node. Similar to message paths, advance such paths by one so that payments may be sent to them.

When creating blinded paths, introduction nodes are limited to peers with at least three channels to prevent easily guessing the recipient. Relax this check when the recipient is unannounced since they won't be in the NetworkGraph.

TheBlueMatt · 2024-06-18T19:24:05Z

+ .map(|details| details.counterparty.node_id)
+ .map(|node_id| first_hops
+ .iter()
+ .skip(1)


nit: you dont need to skip this its always equal :)

That's why I'm skipping it :)

tnull

LGTM

jkczyz · 2024-06-17T21:06:31Z

When creating blinded paths for receiving onion messages or payments, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending messages or payments without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

Also add support for paying through a BlindedPath where we are the introduction node.

Fixes#2952.

When creating blinded paths for receiving onion messages, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending messages without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

When creating blinded paths for receiving onion payments, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending payments without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

When using advance_path_by_one when we are the introduction node, any error will result having the first hop of the input blinded path removed. Instead, only remove the first hop on success. Otherwise, the path will be invalid.

Similar to blinded paths for onion messages, if given a blinded payment path where we are the introduction node, the path must be advanced by one in order to use it.

DefaultRouter will ignore blinded paths where the sender is the introduction node. Similar to message paths, advance such paths by one so that payments may be sent to them.

When creating blinded paths, introduction nodes are limited to peers with at least three channels to prevent easily guessing the recipient. Relax this check when the recipient is unannounced since they won't be in the NetworkGraph.

TheBlueMatt · 2024-06-18T19:24:05Z

+ .map(|details| details.counterparty.node_id)
+ .map(|node_id| first_hops
+ .iter()
+ .skip(1)


nit: you dont need to skip this its always equal :)

That's why I'm skipping it :)

tnull

LGTM

jkczyz · 2024-06-17T21:06:31Z

When creating blinded paths for receiving onion messages or payments, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending messages or payments without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

Also add support for paying through a BlindedPath where we are the introduction node.

Fixes#2952.

When creating blinded paths for receiving onion messages, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending messages without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

When creating blinded paths for receiving onion payments, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending payments without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

When using advance_path_by_one when we are the introduction node, any error will result having the first hop of the input blinded path removed. Instead, only remove the first hop on success. Otherwise, the path will be invalid.

Similar to blinded paths for onion messages, if given a blinded payment path where we are the introduction node, the path must be advanced by one in order to use it.

DefaultRouter will ignore blinded paths where the sender is the introduction node. Similar to message paths, advance such paths by one so that payments may be sent to them.

When creating blinded paths, introduction nodes are limited to peers with at least three channels to prevent easily guessing the recipient. Relax this check when the recipient is unannounced since they won't be in the NetworkGraph.

TheBlueMatt · 2024-06-18T19:24:05Z

+ .map(|details| details.counterparty.node_id)
+ .map(|node_id| first_hops
+ .iter()
+ .skip(1)


nit: you dont need to skip this its always equal :)

That's why I'm skipping it :)

tnull

LGTM

jkczyz · 2024-06-17T21:06:31Z

When creating blinded paths for receiving onion messages or payments, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending messages or payments without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

Also add support for paying through a BlindedPath where we are the introduction node.

Fixes#2952.

When creating blinded paths for receiving onion messages, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending messages without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

When creating blinded paths for receiving onion payments, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending payments without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

When using advance_path_by_one when we are the introduction node, any error will result having the first hop of the input blinded path removed. Instead, only remove the first hop on success. Otherwise, the path will be invalid.

Similar to blinded paths for onion messages, if given a blinded payment path where we are the introduction node, the path must be advanced by one in order to use it.

DefaultRouter will ignore blinded paths where the sender is the introduction node. Similar to message paths, advance such paths by one so that payments may be sent to them.

When creating blinded paths, introduction nodes are limited to peers with at least three channels to prevent easily guessing the recipient. Relax this check when the recipient is unannounced since they won't be in the NetworkGraph.

TheBlueMatt · 2024-06-18T19:24:05Z

+ .map(|details| details.counterparty.node_id)
+ .map(|node_id| first_hops
+ .iter()
+ .skip(1)


nit: you dont need to skip this its always equal :)

That's why I'm skipping it :)

tnull

LGTM

jkczyz · 2024-06-17T21:06:31Z

When creating blinded paths for receiving onion messages or payments, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending messages or payments without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

Also add support for paying through a BlindedPath where we are the introduction node.

Fixes#2952.

When creating blinded paths for receiving onion messages, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending messages without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

When creating blinded paths for receiving onion payments, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending payments without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

When using advance_path_by_one when we are the introduction node, any error will result having the first hop of the input blinded path removed. Instead, only remove the first hop on success. Otherwise, the path will be invalid.

Similar to blinded paths for onion messages, if given a blinded payment path where we are the introduction node, the path must be advanced by one in order to use it.

DefaultRouter will ignore blinded paths where the sender is the introduction node. Similar to message paths, advance such paths by one so that payments may be sent to them.

When creating blinded paths, introduction nodes are limited to peers with at least three channels to prevent easily guessing the recipient. Relax this check when the recipient is unannounced since they won't be in the NetworkGraph.

TheBlueMatt · 2024-06-18T19:24:05Z

+ .map(|details| details.counterparty.node_id)
+ .map(|node_id| first_hops
+ .iter()
+ .skip(1)


nit: you dont need to skip this its always equal :)

That's why I'm skipping it :)

tnull

LGTM

jkczyz · 2024-06-17T21:06:31Z

When creating blinded paths for receiving onion messages or payments, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending messages or payments without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

Also add support for paying through a BlindedPath where we are the introduction node.

Fixes#2952.

When creating blinded paths for receiving onion messages, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending messages without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

When creating blinded paths for receiving onion payments, allow using the recipient's only peer as the introduction node when the recipient is unannounced. This allows for sending payments without going through an intermediary, which is useful for testing or when only connected to an LSP with an empty NetworkGraph.

When using advance_path_by_one when we are the introduction node, any error will result having the first hop of the input blinded path removed. Instead, only remove the first hop on success. Otherwise, the path will be invalid.

Similar to blinded paths for onion messages, if given a blinded payment path where we are the introduction node, the path must be advanced by one in order to use it.

DefaultRouter will ignore blinded paths where the sender is the introduction node. Similar to message paths, advance such paths by one so that payments may be sent to them.

When creating blinded paths, introduction nodes are limited to peers with at least three channels to prevent easily guessing the recipient. Relax this check when the recipient is unannounced since they won't be in the NetworkGraph.

TheBlueMatt · 2024-06-18T19:24:05Z

+ .map(|details| details.counterparty.node_id)
+ .map(|node_id| first_hops
+ .iter()
+ .skip(1)


nit: you dont need to skip this its always equal :)

That's why I'm skipping it :)

tnull

LGTM

jkczyz requested review from TheBlueMatt and tnull June 17, 2024 21:06

jkczyz added 8 commits June 18, 2024 09:26

Don't modify path when advance_path_by_one errors
efc4647
When using advance_path_by_one when we are the introduction node, any error will result having the first hop of the input blinded path removed. Instead, only remove the first hop on success. Otherwise, the path will be invalid.

Add advance_path_by_one for blinded payment paths
b6fcd84
Similar to blinded paths for onion messages, if given a blinded payment path where we are the introduction node, the path must be advanced by one in order to use it.

Rename variable
79122d6

Re-order imports
55ba2aa

Advance self blinded payment paths
642913c
DefaultRouter will ignore blinded paths where the sender is the introduction node. Similar to message paths, advance such paths by one so that payments may be sent to them.

Relax channel count check for unannounced nodes
c1eda4b
When creating blinded paths, introduction nodes are limited to peers with at least three channels to prevent easily guessing the recipient. Relax this check when the recipient is unannounced since they won't be in the NetworkGraph.

jkczyz force-pushed the 2024-06-bolt12-unannounced branch from 2046b4a to c1eda4bCompare June 18, 2024 14:26

TheBlueMatt approved these changes Jun 18, 2024
View reviewed changes

tnull approved these changes Jun 19, 2024
View reviewed changes

tnull merged commit f45a840 into lightningdevkit:mainJun 19, 2024

TheBlueMatt mentioned this pull request Jun 19, 2024
Expose advance_path_by_one#3134
Closed

This was referenced Jun 21, 2024
Compact BlindedPath representation for onion messaging #2921
Closed
BOLT12 Offers Tracking Issue #1970
Open