Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature]: Support Payment to Multiple Blinded Paths #8363

Open
carlaKC opened this issue Jan 9, 2024 · 0 comments
Open

[feature]: Support Payment to Multiple Blinded Paths #8363

carlaKC opened this issue Jan 9, 2024 · 0 comments
Labels
blinded paths enhancement Improvements to existing features / behaviour mission control

Comments

@carlaKC
Copy link
Collaborator

carlaKC commented Jan 9, 2024

LND currently supports payment to a single blinded path (via QueryRoutes and SendToRoute), with the option for the end user to supply multiple blinded paths in future iterations of the feature. As the privacy benefits of blinded paths come with a reliability tradeoff (by restricting the last-mile hops available to the sender), we're going to want to extend LND to allow payment to multiple blinded paths.

Pathfinding Considerations

Blinded routes are expressed as a chained set of hop hints in LND's pathfinding, where the channel policies are node IDs are simply filled in from the information provided by the blinded route. When making a payment to a single destination with multiple blinded routes, the destination node will appear to be different for each blinded path (because the blinded pubkey has a different tweak for each path). To still allow the use of chained hop hints, we can use a special "marker" pubkey for the final hop in the route and switch it out at the time of route construction.

Visual Example

Given the following topology, with node E generating multiple blinded routes (C/D/E and F/G/E):
Screenshot 2024-01-09 at 12 08 10 PM

The node sending to the two blinded paths will have the following topology:
Screenshot 2024-01-09 at 12 06 38 PM

We can reconcile this with pathfinding by adding a “fake” terminal public key for our final node, and switching it out with the actual blinded key at the point of route construction (so that the onion will have the correct key):

Screenshot 2024-01-09 at 12 05 09 PM

Mission Control Considerations

When mission control handling for a single blinded path was added in #8095, the following was accounted for:

  • The introduction node is always the "reporting" node for failures, so a solution must be mindful to not "poison" the introduction node.
  • The node ID of blinded hops after the introduction node are ephemeral (ie, single use blinded pubkeys), and we do not want to pollute mission control with single-use entries, so only the final hop in the blinded route is penalized and persisted (note, this is already an issue with route hints).

There is an edge case where we have a two hop blinded route (the introduction node and the recipient/dummy) and we receive a InvalidBlinding failure from the introduction node:

  • We don't want to penalized the introduction node, as stated above.
  • Penalizing the final hop would impact the introduction node, as it shares the edge with the failing blinded node.

In the single path case, we can just fail the payment permanently, because it doesn't have a shot at succeeding, but in the multi path case we need to find a way to penalize that blinded route specifically so that pathfinding can proceed to retry another route.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
blinded paths enhancement Improvements to existing features / behaviour mission control
Projects
None yet
Development

No branches or pull requests

1 participant