When you transfer funds via the Lightning Network, you can do so via a direct channel with your peer, be that a family member or an application you enjoy using regularly, or you can route a payment through the network.
As you can imagine, it wouldn’t be practical to ask a user to create a payment channel with every peer they want to interact with, so routing is the more efficient method of settling payment and makes up a majority of the transactions. When you route a payment through the Lightning Network, you broadcast the amount, and the network will look for possible paths between various nodes; each node will update its balance and pass on the funds until it reaches the end user.
A Lightning Network payment is a lot like Shrek; it has plenty of layers, and these onion messages are what allow different Lightning nodes to transfer payments between one another through a series of hops until they reach their intended destination.
While senders on the Lightning Network have better anonymity guarantees thanks to onion routing, receivers currently have no anonymity as their nodes’ public keys are embedded in their invoices.
To mitigate privacy concerns, several techniques like rendezvous routing, hidden destinations, and blinded paths are being explored as possible solutions.
These privacy techniques should allow a Lightning node to send a payment to an unannounced node without learning where that node is in the network topology or what channels it shares with other nodes.
What is blinded routing?
A blinded path is a payment path generated through “route blinding”, a technique that obscures some portion of the payment path from the public view. The proposal isolates the information available to participants, including the nodes that transmit it.
Only the receiver knows the entire path, while external observers only know part of the payment path until it reaches a certain node, and then the route is hidden, and the privacy of the receiver is preserved.
Blind routing ensures the system hides the final part of a transaction’s path.
The process to create a blinded path involves the use of an encryption algorithm called “Elliptic Curve Diffie-Hellman” (ECDH). This algorithm allows two parties, each with their own secret key, to derive a shared secret that can be used to encrypt and decrypt data.
Using this shared secret, both parties can encrypt and decrypt data while those on the path are viewing payments can’t see the information being passed on between these two nodes in cahoots.
For blinded paths to work, the following parties would need to upgrade their nodes and how they construct invoices.
- Receivers: Need to construct blinded node pubkeys and encrypted data.
- Senders: Need to include blinding points and encrypted data into their onions.
- Forwarders: Need to derive shared secret to decrypt forwarding data.
What are the pros and cons of blind routing?
As with every BOLT or BIP, there are trade-offs involved and edge cases where privacy with blind routing can be uncovered.
Pros of blinded routing
- Onions can be reused across multiple invoices.
- There is no need for the receiver to explicitly request how many hops the sender should include in their payment.
- Only the parties involved in helping settle the transaction are required to upgrade to support blinded paths, but the more nodes upgrade to support blinded routes, the bigger the selection of nodes for end destinations.
- IDs of the nodes in the blinded path are obscured,
- Blinded routing can also be used to route payments through private lightning channels (channels not announced in the gossip protocol) without revealing them.
Cons of blinded routing
- Compared to rendezvous routing, blinded paths’ privacy guarantees are a bit weaker and require more work (e.g. when handling errors).
- Upon payment failure, interaction is required from the receiver to generate a new onion.
- Bigger routes mean potentially higher fees for the sender and more time to execute route finding, especially with fake hops and processing tweaks.
- Channels have the potential to be unblinded with payment probing attacks.
- BOLT12 could make probing attacks on blinded routes even easier.
- Blinded routing might only be interoperable with the network if all instances of Lightning adopt this feature.
- Adds more computational load for nodes and the network.
Keep prying eyes off your payments.
If the Lightning Network is to become the daily settlement layer for most Bitcoin transactions, where you will be making frequent payments and routing funds through different paths, you would need better privacy assurances, as cash does today.
In the same way, we might spend cash at certain establishments to keep the slipe off our debt or credit card; users might want to opt for blinded routing in some cases, while others might want to use it as their default payment method.
Blinded routing is a clever way to route payments through the Lightning Network without revealing the identities of the sender and receiver, but this is still early days, and attack vectors need to be reviewed, while the UX for it also needs to be refined.
Lightning, with its ability to provide instant, low-cost payments, has a unique selling point that is attractive enough for users to provide liquidity but will not catch on non-custodially if users can continue to leak data.
“Blind routes solve the privacy problem at the node level by replacing ‘hop hints’ with a cryptographically obfuscated route. At a high level, the receiver can construct a route of one or more hops [hop hints, hops between nodes], collect the public keys for each node, and then obfuscate them so that the sender of the payment uses them to find his route, but doesn’t know how many nodes or hops are part of it.”
Olaoluwa Osuntukun – Lightning Labs
Do your own research.
If you want to learn more about Blinded Paths on Lightning, use this article as a jumping-off point and don’t trust what we say as the final say. Take the time to research, check out their official resources below or review other articles and videos tackling the topic.
