Latency and Privacy in Lightning

[carla]

@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)

@tnull

I don’t think we need to add sender-side retry delays if we wouldn’t retry over exactly the same route.

I’m in agreement with all of the above.

@t-bast

they mentioned during the spec meeting that intermediate forwarding delays are important for privacy even when we have random message padding and cover traffic,

@tnull

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.

Just to re-iterate @t-bast’s question. Wouldn’t the whole point of cover traffic be that we have “fake” HTLCs propagating through the network at the same time as real ones so that an attacker gets false positives on this type of surveillance?