Latency and Privacy in Lightning

[GeorgeTsagk]

@t-bast

We are giving away more information than before, so this is definitely adding privacy risks.

Only the sender gets these latency values. An on/off path adversary does not extract additional data.

@t-bast

It will keep getting harder and harder for adversaries to collect such information when we have random delays, message padding and jamming protection (which will include upfront fees, making probing costly).

As long as all of the above are not implemented it doesn’t matter if the sender sees low or high resolution values. And when the above do get implemented, the number will have a natural threshold anyway.

@t-bast

Nobody is using those to make their payments outside of a small niche of developers / tinkerers who are mostly playing around with running a node because they want to do something with their bitcoin: they’re not the users who make the majority of the payment volume.

If we don’t build for node runners too then won’t LN end up being a handful of centralized routing nodes owned by companies, who will probably submit traffic data directly anyway?

@t-bast

I do think that a 1ms precision isn’t at all important for payment UX, and 100ms precision per-hop would be enough.

Agree, but instead of binding the protocol today with fixed numbers that we come up with we can just let it be uint64 and implementations will enforce the X ms resolution or threshold over that field. This is only bad in the case where we assume everyone in the network to wake up one day and strip away the rounding/thresholds. It also allows us to change the way we report hold times in the future without having to change the way it appears on the wire.