You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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):
The node sending to the two blinded paths will have the following topology:
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):
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.
The text was updated successfully, but these errors were encountered:
LND currently supports payment to a single blinded path (via
QueryRoutes
andSendToRoute
), 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):
The node sending to the two blinded paths will have the following topology:
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):
Mission Control Considerations
When mission control handling for a single blinded path was added in #8095, the following was accounted for:
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: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.
The text was updated successfully, but these errors were encountered: