Latency and Privacy in Lightning

[tnull]

@t-bast

Based on my current understanding, my preferred choice would be:

• receiver-side random delays
• sender-side random delay on retries
• small randomized batching interval at intermediate nodes (mostly for performance, but also to add a small amount of noise of relay latency)
• random message padding / cover traffic (which I think doesn’t have to be CBR to be effective)

Yes, totally agree in generally here.

Although I don’t think we need to add sender-side retry delays if we wouldn’t retry over exactly the same route. And, AFAIK, only LND currently does this under certain circumstances where they give a node a ‘second chance’ if they report back one of a certain set of failure codes.

@t-bast

As you say, this doesn’t rule out the current 1ms encoding for attributable failures. But I’d be curious to have @MattCorallo and @tnull’s thoughts here: they mentioned during the spec meeting that intermediate forwarding delays are important for privacy even when we have random message padding and cover traffic, and I don’t understand why. So I may be missing something important.

So, while the attack described in the Revelio paper is mostly based on a heuristic that exploits the distinct packet sizes, they still group the streams of IP packages / 3-tuple (sender IP, receiver IP, message length, basically) that an adversary might observe at different points by their timing. Basically, the adversary would be able to observe the HTLC dance at one point in time / in the network, and then an HTLC dance at a later point / a different point in the network. To correlate these two observations and reconstruct that it was in fact the same payment they use timing information. The same approach could be utilized by an on-path adversary with multiple vantage points in the network post-PTLCs, but of course currently they can simply match the payment hash to ensure that two observations are indeed the same payment.

So yes, the more entropy/noise we add/maintain to/in the forwarding process the harder we make the adversary’s job of coming up with reliable models, which is why we likely wouldn’t want to drop the forwarding delay entirely (although note it’s mostly about maximizing uncertainty not the added net delay necessarily).