Source-routed payments in the lightning network require recipients to provide a destination for pathfinding. Blinded paths have recently been introduced to the specification to improve recipient privacy by providing the sender with an encrypted multi-hop path from a known, cleartext introduction node to themselves. This is similar to Tor’s rendez-vous onion routing protocol, but uses a different cryptographic protocol.

Problem definition

Blinded paths need to provide aggregate information about the fee and time lock required for the encrypted portion of the path so that senders can send payments that meet the routing policies of the nodes in the nodes in the blinded path. This information can be compared to the publicly known lightning graph to attempt to de-anonymize blinded paths.

Open questions for blinded path selection are:

It is not trivial to compute a reliable score for each of the two trade-offs above. But it is important to figure out a way to do so, and a graph algorithm that selects good blinded paths based on that scoring.

State of the art

Close to none. While blinded payments are supported in most lightning implementations today (October 2023), all of them defer the selection of the blinded paths to the end user.