Privacy in Lightning

Feb 27 2018

A few days ago I was contacted by Rachel O’Leary from CoinDesk regarding an article she was writing about the privacy of Lightning payments compared to Bitcoin on-chain transactions: Will Lightning Help or Hurt Bitcoin Privacy?. These are very common questions, so I thought I might as well publish my raw answers.

I’d like to preface this by saying that privacy is neither a binary, nor a linear thing. Privacy is a multi-facetted issue and comparing two systems is difficult, so a tradeoff may be sensible in one setting it may not be in another.

Why is privacy a consideration for Lightning developers?

Payments in the lightning network are fundamentally different from payments in bitcoin. We move away from a broadcast medium in which everybody sees every transaction, towards a model in which only the interested parties, i.e., sender, recipient and intermediate hops, see a payment. This is what gives us the high scalability in the first place, however it also makes it easier to identify the endpoints of a payment. Without the onion routing, every payment would contain the destination’s address in order for the payment to be routed correctly, so every node could know the destination, and with sufficient network access we could also infer who the sender is.

Will Lightning improve or worsen privacy?

That is hard to answer, since payments are so different. In bitcoin we have every payment permanently recorded in the blockchain, with a lot of research already showing the possibility of creating extensive user profiles, tracing payments and deanonymizing many users. It takes a lot of effort to stay truly anonymous in bitcoin.

Using lightning we don’t create that permanent record for payments in the first place so this kind of analysis is no longer possible. To learn about a payment now you have to be part of the route that the payment went through in the first place, otherwise you’ll be completely unaware of anything happening. Even if you are part of the route all you learn is that you got some funds from one side, along with instructions were to forward them next. You do not learn anything about the sender, the recipient or even your position in the route.

This protection is certainly not perfect, as some have pointed out, timing attacks can identify relationships between individual hops, and the public knowledge about the network’s topology may allow attackers to infer additional information. However I personally believe that we are in a better position. The payment information is ephemeral and attackers need substantially more resources and access to learn anything about the payments that occur in the network. It’s not perfect, but a step forward.

Why is there dispute about this?

The dispute is mostly comparing the security of our onion routing with Tor. The key observation is that our routing is restricted to follow the topology of the overlay network created by lightning. This is different from Tor, where each hop in a circuit can be chosen arbitrarily from a set of public nodes, whereas we are restricted to chose adjacent nodes.

This criticism is valid, and may impact the mix quality, though I can’t say what the exact impact is. While we are bound to follow the topology, it also means that to get from one point to another we have to traverse more hops, which again improves our mix quality. While Tor uses just a few hops for reasonable privacy, Lightning can use up to 20 hops, counteracting the limited choice for each individual hop.

This is less of a dispute about the privacy of bitcoin versus lightning, instead it is more about the onion routing as implemented in lightning versus the Tor network.

If I wanted to send a private Lightning transaction now, could I?

Ideally the client would always attempt to maximize your privacy for you, so there wouldn’t be anything specific required on your part. The countermeasures that all three tearms are currently implementing comprise a topology randomization and route randomization. Topology randomization tries to avoid having hubs that can observe traffic, by opening channels in a random fashion, which also strengthens the network as a whole against single points of failure. Route randomization involves computing multiple routes and chosing one of them at random. This may result in slightly longer routes, and thus slightly higher fees, but increases privacy a lot by making the routes less predictable.

How will Hornet improve on some of these problems?

Hornet is a protocol that optimizes bidirectional communication along an existing circuit that was established using the sphinx protocol. We implement sphinx for our onion routing, so that determines the route that all subsequent communication would take. We stepped away from the idea of implementing hornet as part of lightning since it’d create a general purpose communication layer that we don’t really need. With its single roundtrip design sphinx perfectly matches our requirements for a payment, and adding a communication layer that is not bound to payments could potentially have unintended consequences. We want lightning to be a payment network, not a way to stream movies anonymously :-)

What other privacy proposals also address this?

We could separate the onion routing from the end-to-end connectivity, i.e., first creating a publicly routed base network that allows us to send payments from A to B, and then build onion routing on top of that. This would more closely match the Tor network in which the base network is TCP/IP and the onion routing is built on top. However, in the first iteration we decided that all payments should be private and thus use onion routing, and not allow users to skip the onion routing and just use the base routing. This may eventually be picked up again, but so far it’s not on the roadmap.