Thread by @JohnCantrell97

The lightning network offers interesting privacy properties compared to on-chain txs. However, the way routing works allows the sender to learn who the recipient is.

A proposal called Route Blinding aims to eliminate this drawback.

Let me break it down for you 👇

In my previous explanation of how routing works we learned that the sender is responsible for building up paths to use for routing a payment to the recipient of the payment.

This requires the sender to know who the recipient is.

https://twitter.com/JohnCantrell97/status/1552008378901209089

I also explored how the recipient could gain privacy by using Rendezvous Routing:

https://twitter.com/JohnCantrell97/status/1552344287295295488

Route Blinding is similar to rendezvous routing but provides a bit more flexibility.

To understand how route blinding works we should clarify what is meant by the term blinding.

You’ll see it often when reading about cryptography, bitcoin, and the lightning network.

Blinding might sound confusing but it’s pretty simple.

Blinding is a technique to hide some input from someone in a way that they can operate on it without learning anything about the original input and then later the output can be unblinded, revealing the actual information.

A popular use-case is for blind signing.

You might want an entity to sign something where they don’t actually know what they are signing.

You can blind the message to be signed and then unblind the signature revealing a valid signature for the original message.

Okay, so in route blinding what we want to blind are the public keys for the hops along a route.

This way we can give a blinded route to the sender in such a way they can construct the rest of the route and never learn the actual nodes involved.

This means the sender uses our favorite trick, Elliptic Curve Diffie-Helman (ECDH), to generate shared secrets for each node it’s trying to include in the blinded route.

It uses this shared secret to blind the node’s public key and then encrypt the next node’s public key.

From the senders perspective, they have no idea what nodes are involved in the last couple hops of the payment.

It only sees these blinded node ids and uses them to construct the onion exactly as it normally would.

A node in the blinded path generates the shared secret using ECHD on its private key and the ephemeral public key provided by the previous hop.

It can derive the blinding factor and the private key for its blinding public key the sender used to encrypt and wrap the onion.

Once the onion is decrypted it will reveal the encrypted data that will tell the node who the next hop is supposed to be.

The node can use the shared secret to decrypt the data and generate the next ephemeral public key to give to the next hop who then repeats this process.

So let's zoom out again.

The idea is that normally the sender encrypts and wraps the onion using a shared secret generated from each node’s public key and an ephemeral public key.

This means each node can generate the same secret using their private key.

In a blinded route the sender doesn’t actually know the public key of each node so it uses each node’s blinded public key that it got from the recipient when generating the shared secret used to encrypt and wrap the onion.

This is the key idea, the sender is able to perform the normal onion operations on a blinded public key such that each node is able to calculate the blinding factor used and unwrap the onion as normal.

TLDR; A blinded route is a way for the recipient to give a sender the last part of a path such that the sender does not learn the node ids for any of the nodes along that path.

So why is this any better than rendezvous routing? If you recall, in a rendezvous payment the recipient gives the sender the entire wrapped onion to use.

With blinded routes, the sender still constructs the entire onion.

Because the sender constructs the entire onion, they are able to include whatever data they might want to in the payload for each node.

This would not be possible in a rendezvous payment because they cannot alter the onion the recipient sends them in any way.

The only potential downside compared to rendezvous routing is that this flexibility to construct the onion opens the door to potential probing attacks the sender can do to try to expose some of the nodes along the blinded path.

I hope this helped you understand how blinded routes can enhance recipient privacy in a more flexible way compared to rendezvous routing.

Feel free to ask any questions you might have about onion, rendezvous, or blinded routing.

Oh and if you'd like more details you can review the proposal here:
github.com/lightning/bolt…