Skip to content

routing+htlcswitch: add support for selecting, and encoding+decoding blinded paths  #6690

@Roasbeef

Description

@Roasbeef

This is a master tracking issue that tracks the prototyping/implementation of blinded paths: lightning/bolts#765.

Blinded paths re-uses a few of the Sphinx tricks to allow a receiver to give a sender an obfuscated path that hides the set of nodes traversed (subject to leakage via the routing policies) to the sender. We have code lying around some where that already implements all the blinding/encrypting bits. What's missing, and what will be the long tail to deployment (imo) is: figuring out exactly which paths to place in the blinded payload. Selecting these paths poorly may make a receiver hard to pay. On top of that, the paths selected decay over time, as routing policy changes may cause routes to no longer be used (fee is now 4x, etc).

Related to the question of which paths to select is: how many of them to stuff into the invoice. Unlike the normal last-hop hop hints usage in the invoice, these paths may extend into the public graph. As a result, there's more possibilities w.r.t which hops/nodes to include in a payload. As a result, when encoding for a BOLT 11 QR code, there's a sort of satisficement/optimization problem at hand. On the other hand, if something like LN-URL or BOLT 12 are used, then you're fetching these invoices over HTTP (or w/e) so you don't need to be as concerned w/ the side of the payload.

Metadata

Metadata

Assignees

Labels

advancedIssues suitable for very experienced developersblinded pathsprivacyGeneral label for issues/PRs related to the privacy implications of using the softwareroutingspec

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions