Latency and Privacy in Lightning

[MattCorallo]

@roasbeef

They can also further bisect the reported values, either by iteratively probing nodes in the path, or connecting out to them to measure ping latency. This brings forth a related third question: what do we gain by encoding less precise values?

With randomized delays (plus randomization in I/O latency), doing iterative probing may require a very nontrivial number of tries to map the whole network. With future upfront fees, this may be impractical. In practice, we see people who try this largely fail to provide reasonably accurate data today (at least in the sense that we care about here - they can certainly provide “this node is terrible/on tor” vs “this node seems reasonable”-type data, which is obviously a thing we want to provide to all nodes here).

@roasbeef

One way to partially address this concern would be to: prefix the latency encoding with the type and parameter. So the final value on the wire would be encoding_type || encode_param || encoding_value. This would:

I don’t buy that its worth us all implementing a configuration knob and multiple encoding options for this. Sometimes more flexibility isn’t the right answer

@roasbeef

Let nodes choose if they wanted to give granular information or not (hey! I’m fast, pick me!).

This would defeat the whole purpose of attempting to reduce the information provided - privacy loves company - the whole point of the discussion here was to ensure that nodes cannot (in a standardized way) communicate granular latency information as it incentivizes them to do so as senders would (presumably) use that information to (strongly) prefer nodes with even marginal decreases in latency.

@GeorgeTsagk

It’s also important to note that there are more crucial things to address that directly improve privacy over lightning, like forwarding and sender/receiver delays to mitigate the on/off path adversaries as described previously in this thread. Without addressing these, applying a privacy-dressing on the sender’s feedback is only a partial illusion of privacy.

Indeed, but providing fine-grained latency information strongly incentivizes nodes to remove any forwarding/batching delays, effectively limiting our options later to improve privacy (at least by ensuring everyone has a batching delay, at least by default). I don’t think this conversation was ever about whether this, itself, provides privacy, but rather whether it closes off privacy features we want.

@GeorgeTsagk

b) Focusing on the performance of LN is a fundamental use-case. Every day someone pays for their food or ticket with LN and the payment resolves fast is a small win for the whole network. I’m not saying we need 100ms instead of 1s, but we definitely need to treat performance as a fundamental requirement of the network.

Its important that we be clear about what this means - lightning has some fundamental limits, and will (in its current protocol) certainly never achieve reliable payment latencies below a second or so (and is already achieving such latencies in practice!). Indeed, changes in payment latency by an order of magnitude absolutely changes what lightning can be used for and opens up new use-cases which we should want. However, in Carla’s analysis in the OP it seems like forwarding/batching delays round an RTT or less can result in reasonable privacy improvements (assuming enough traffic on nodes and some other network-level improvements we want to make).

Thus, declining to offer fine-grained latency information and encouraging nodes to always batch forwards/failures on the order of 100ms will not change the set of use-cases LN is usable for, nor change the user experience of a lightning payment, nor materially change the “performance of LN”. Given this, and the fact that privacy is also a critical feature of LN (whether we have it today or not), I’m not entirely clear on why its worth providing fine-grained latency information here. We don’t currently envision a serious use-case for that kind of data, and there’s some (even if marginal) risk in making it available.