Before diving into blinded paths, let’s do a quick recap on payment paths:
In the context of the lightning network, a “path” refers to the route that a payment takes from the sender to the recipient through a set of payment channels. To route the payment via this path, the lightning network uses a mechanism called “Source-based Onion Routing”, commonly known as “SPHINX”.
SPHINX is a tool used for secure communication that involves the sender creating multiple layers of encryption. Each intermediary node progressively removes these layers as the message is transmitted until the intended recipient receives the innermost layer. Each intermediary only knows the node immediately before and after them in the transmission process.
With source routing, the sender is responsible for building the payment path from his node to the receiver’s node.
Privacy Issues
SPHINX provides good anonymity guarantees for senders but not for receivers. Since the sender has to construct the entire path, it knows the final destination and all the nodes along the path.
This means that the sender knows the receiver’s public key. But privacy leakage doesn’t stop there: in a BOLT 11 invoice, the receiver’s public key is embedded directly into the invoice, so everyone who has access to the invoice can also extract the receiver’s public key. This can be a problem if the recipient’s identity is sensitive or if the sender wants to keep the transaction private.
Blinded Paths
A blinded path is a payment path generated using a technique called “route blinding.” The idea is quite simple: route blinding obscures some portion of the payment path from the public view. Only the receiver knows the entire path; external observers only know part of the payment path until it reaches a certain node, the introduction point.
With this technique, the privacy of the receiver is preserved. There is no easy way to discover the identity of the node requesting the payment as this information is now hidden from external observers.
Creating a blinded route
Creating a blinded path involves using an encryption algorithm called “Elliptic Curve Diffie-Hellman” (ECDH). This algorithm allows two parties, each with their secret key, to derive a shared secret that can be used to encrypt and decrypt data. Only the parties involved can encrypt and decrypt this data.
In the first step, the receiver creates shared secrets with every node along the blinded path. The shared secrets are used to derive a “blinded” node ID for every node in the blinded path, which obscures the actual node ID of the nodes and allows the receiver to hide the payment path from the sender. It also creates some encrypted data for each node in the blinded path that will be used by each node to “unblind” the next node in the path.
Finally, to use the blinded path, the recipient sends the following information to the sender:
- The node ID of the introduction point, so the sender can create the payment path until that node, like it normally would;
- The list of “blinded” node IDs for each node in the blinded path, derived from the shared secrets;
- The encrypted data for each node in the blinded path;
- The first “ephemeral blinded key” (ephemeral because it’s only used once per transaction)
Sending to a blinded route
After the sender has all the information needed, it creates the payment path until the introduction point, as it would for a regular payment. The sender also adds the following data to the onion:
- The first blinded ephemeral key for the introduction point;
- The encrypted data that each node will need to be able to “unblind” the next node in the path;
When the node at the introduction point “peels” its onion layer, it finds the first ephemeral blinded key and encrypted data. The node then uses this information to “unblind” the first node in the blinded path and also to compute the ephemeral key that the next node will need so it can execute the same process and find out where it is supposed to route the payment to.
This process continues until the recipient receives the onion. It will find the last onion when it “peels'' its layer. The key takeaway from this process is that, unlike source-based onion routing, the sender doesn’t know the entire path nor the receiver’s identity.
Adoption
You might have noticed that all nodes in the path must do something different from what is currently done in regular routing:
- The receiver has to compute all that extra data to be able to provide the nodes with the information required to unblind the path;
- The sender has to add the extra data to the message it forwards;
- The node at the introduction point and all the nodes in the blinded path have to do specific procedures to unblind the next node in the path
This means that route blinding requires all the nodes in the blinded route, the sender, and the receiver to activate support for this feature. At the time of writing, LND – the most used implementation of the lightning network protocol, with approximately 91% of the network share – still doesn’t support this feature. Conversely, CLN offers support for manually constructing blinded paths via a command line interface, which is not the best user experience.
It’s early, and users can expect unreliability and bad user experiences. If and when this feature gets widely adopted, wallets will have to implement ways of selecting the nodes in the blinded path. User-friendly wallets can make this selection for the user, while wallets for heavy users can allow the user to choose the nodes in the blinded path.
Observations
As the sender can’t know how many nodes are in the blinded path, it may be unfair to make it pay for the fees to accommodate the recipient’s wish for privacy. Ideally, the receiver should discount the fees from the hops in the blinded path from the total value of the payment.
It’s also worth noticing that the sender still knows the upper bound distance between recipients. So if the recipient is close to the introduction point, adding dummy hops in the blinded route might be worthwhile, as the sender can’t distinguish dummy hops from regular blinded hops.
Another great consequence of blinded paths is that, as the IDs of the nodes in the path are obscured, this feature can also route payments through private lightning channels (channels not announced in the gossip protocol) without revealing them. The feature can also be used to force payments to go through a specific set of intermediary nodes that can witness the payment.
One misconception of blinded paths is that it requires BOLT 12 to be implemented. BOLT 11 invoices can be used for blinded paths, but the invoice data will be bigger than for a regular payment. This can make static QR codes harder to scan, but this issue can be solved with animated QR codes, NFC, and LNURL.
Finally, two known attacks can deanonymize the receiver: one involves payment probing when using blinded paths for payments, and the other is a variation of the same technique but can only be explored when blinded paths are being used for making payments. The first one can be avoided by having altruistic relaying nodes inside the blinded path, it relies on nodes routing payments with fees below their current settings. As the obvious economic incentive is to reject those payments, this isn't a viable solution for the attack.
Concluding
Blinded paths are one of the alternatives to solve privacy issues with regular source-based onion routing. It provides anonymity for the receiver. It can also be used to route a payment through a private channel without revealing it and force payment to go through a set of nodes that can witness the payment.
This feature obscures part of the payment path from external observers using an encryption algorithm. This means that the sender – nor anyone with access to the invoice – can’t know the identity of the node requesting the payment. The sender only knows the nodes in the payment path until it reaches an introduction point.
Adoption still is not widespread. The most used lightning network protocol implementation still doesn’t have support for the feature and the ones that do support it don’t provide the best UX to use it.
We hope this was helpful and simplifies how blinded paths work!
Create your node below, or learn more about our Lightning Enterprise solution today.
Also, enjoy exploring our LSP and receiving inbound liquidity with Flow.
