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

[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.

[ellemouton]

linking here so that it doesn't get lost: PR for creating blinded path, decrypting encrypted data from blinded path & processing an onion as a hop within a blinded path: lightningnetwork/lightning-onion#57

[ellemouton]

About to start opening some PRs so gonna give an outline here of what they will include & what is still missing:

PR 1

This PR will cover a bunch of set up work required for the follow up PRs. This includes:

1. All the set-up work for being able to create the final hop encrypted payload in a blinded path (ie, the data that the recipient basically sends to itself. This will, for example, include the PathID which will basically act as the payment address. We also include the Padding field so that we can ensure that all encrypted payloads are of equal size.
2. Add the new Bolt11 blinded path type along with encoding/decoding logic

PR 2

This is the meat of the series. By the end of the PR, a user will be able to:

1. create an invoice and specify that it include a blinded path.
2. pay to an invoice with a blinded path

More in depth description:

1. Ability to find any candidate blinded paths to self given min/max num hop params
2. Use mission control to determine which of these paths are best.
3. Construct the full blinded path to self and add to a Bolt11 invoice
4. Changes necessary to send an MP payment to a single blinded path.

PR 3

This PR will cover being able to send shards of an MP payment through multiple paths. This will require quite a bit of refactoring which is why it gets its own PR.

PR 4

In PR 1, we start querying MC to choose the best paths towards us but realistically, MC wont have much (if any) data about links in this direction (all of its data currently comes from sending out).
If we use a blinded path to receive, however, we will start gaining some info about success pairs in the correct directions. So this PR will cover tracking this & updating MC accordingly.

[ziggie1984]

In PR 1, we start querying MC to choose the best paths towards us but realistically, MC wont have much (if any) data about links in this direction (all of its data currently comes from sending out).

But don't rebalances of the node also track the direction to us ? So I think we already have MC data pointing into our direction through all the rebalances routing nodes make ?

[ellemouton]

But don't rebalances of the node also track the direction to us ? So I think we already have MC data pointing into our direction through all the rebalances routing nodes make ?

Good point! that will certainly help too 🎉

[saubyk]

But don't rebalances of the node also track the direction to us ? So I think we already have MC data pointing into our direction through all the rebalances routing nodes make ?

The only point I would add here is, even though it covers the scenario of payments being made to the node, the proportion of the nodes on the network actively rebalancing may not be that high. Since a large proportion of the channels on the network are unbalanced i.e. bi-modal liquidity distribution.

[ziggie1984]

Feature request:

Add a parameter when creating the invoice for blinded paths which limits the overall fee of the route blinding section to a specific value. This would give the invoice creator more control so that the sender is not overpaying heavily.

[saubyk]

Closing this as all the relevant prs are merged