[feature]: Pathfinding To Blinded Routes

[carlaKC]

This issue outlines a proposal for adding support for pathfinding to blinded routes.
Parent: #5594

Background

Blinded payments offer an improvement to receiver-side privacy in the Lightning Network by allowing recipients to generate a blinded route to their node and pass obfuscated information about this route to the sender. Relevant components of a blinded path are as follows:

• Introduction Node: An unblinded public node in the network that is the beginning of the blinded path
• Blinding Point: An ephemeral public key that is transmitted to the introduction node to be used for decrypting encrypted data. This key is also tweaked and passed to each blinded node to do the same, but this isn’t relevant to the sender.
• Blinded Nodes: An in-order set of blinded node IDs that follow the introduction node.
• Encrypted data: An in-order set of encrypted data blobs (starting at the introduction node, ending at the final blinded node) that provide forwarding information for the nodes in the blinded path.
• Aggregate relay: The aggregate base fee, proportional fee and cltv delta for the binded section of the route (as the sender doesn’t know these values).
• Payment Constraints: The maximum cltv for the payment (included to limit the lifespan of the route) and lowest minimum htlc in the blinded section of the route.

Pathfinding

Given the following basic network layout, where E chooses C as an introduction node:

From the perspective of the sending node A, we have the following topology.

The pathfinding node needs to find a route to C, which is inclusive of the total fee and delta of the blinded portion, and include some additional data in each hop for the introduction and blinded route. Hops in the blinded portion of the route are expected to have zero delays and forwarding amounts, as the forwarding nodes themselves will take care of this.

For a 1000 msat payment (final delta = 60, current height= 100), our end goal is a route with the following structure (visually expressed as hops):

Code Change 1: Additional Hop Information

When we build a route from a set of hops, edges are directly constructed from a set of cached edge policies. We can easily wrap the cached edge policy in a hopInfo struct which contains the hop’s policy, encrypted data and blinding point to allow insertion of route blinding fields.

type hopInfo struct{
    edgePolicy *channeldb.CachedEdgePolicy
    encryptedData []byte
    blindingPoint *btcec.PublicKey
}

func (h *hopInfo) createHop(amt, delay, …)*route.Hop{...}

These new values can just be copied across in every hop during route construction, so that pathfinding doesn’t need to be aware of where we require specific fields to be filled. This allows us to isolate all blinded hop related logic in a single BlindedRouteToHints function that understands where to populate the blinding point and encrypted data.

Code Change 2: Blinded Paths as Route Hints

LND’s pathfinding already supports chained hop hints, which provides an easy way to express a blinded path as a single chain of hints. The values set for each hint’s fees/cltv delta can be modified to ensure that the route is formed with the correct values as outlined in the route blinding specification. These hints can be introduced where we currently have for hop hints, with validation that either hop hints or blinded paths are set (since both do not make sense).

Blinded Path Hints:

• Aggregate fees and delay: included as the policy for the introduction node -> first blinded node in the route.
• Aggregate constraints: included for every hop in the route.

Alternative: An entire blinded route can also be expressed as a single hop hint, but then you have to go back in after the route has been constructed and edit the last hop (removing final hop fields) + fill in the blinded hops. With the way LND is currently set up, I'm pretty confident a chain of hints will be less intrusive / allow more logic re-use.

Minor Modifications

Other (hopefully) uncontroversial changes include:

• Extending payload TLVs encoding to include encrypted data and blinded point TLVs
• Update QueryRoutes to include an experimental blinded payment field (for the purpose of itests, can alternatively leave un-surfaced and just unit test or add a new subserver)

Conveniently Out of Scope

What about pathfinding to multiple blinded routes I hear you say? This gets a little trickier because distinct blinded paths to the same node will have different final blinded public keys. Once we have construction of hops abstracted away using hopInfo, we can set a dummy target public key in the final hop of each blinded route for pathfinding, and switch out the actual blinded public key when we construct the route so that the correct pubkey is used for the onion. Provided that there are no shared blinded node IDs in the paths (there won’t be / we can validate that), pathfinding will be able to produce paths to the destination using multiple routes. Visual representation here.

It’s tempting to consider pathfinding just to the introduction node and appending the blinded portion to the end of the route. So tempting, in fact, that one might spend day writing code for it only to realize that it won’t work. This approach just kicks the bucket down the proverbial road, because different blinded paths may have different introduction nodes.

[saubyk]

@yyforyongyu @carlaKC can this issue be closed now, cause #7267 has been merged?

[carlaKC]

@yyforyongyu @carlaKC can this issue be closed now, cause #7267 has been merged?

❤️‍🔥 it can