Would like to add some comments to a few of the points made in previous messages:
@joostjager: In my view, it is more sustainable to design the network to be resilient and private even when nodes compete on latency, rather than relying on weak measures that only obscure the problem and leave critical questions unanswered.
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.
On top of that the sender may be considered the only actor that deserves to know as much as possible w.r.t what’s going on with their payment, they’re the ones piloting it at the end of the day.
@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.
I don’t really see the value of having the prefix. If you want to round up or down to buckets of 100ms then you’re free to do so in the simple uint64 encoding. Why would the sender want to know whether you’re doing it or not?
@t-bast: Sacrificing those to get performance gains for which we don’t have any concrete use-case today doesn’t make any sense to me.
A 2-part reply:
a) We’re not really sacrificing privacy, it’s more like being honest about the current situation. Similarly, we are not gaining any privacy by obfuscating the latency that is reported to the sender. Adversaries face no extra difficulties in analyzing traffic.
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.
@t-bast: As we’ve highlighted several times during spec meetings, privacy loves company: you can only achieve good enough privacy if that is the default behavior of the network.
I still don’t understand whether we’re assuming that most people are willing to strip away parts of the software for the sake of speed. If that’s the assumption, then the real mitigations for privacy (forwarding & sender/receiver delays) are really questionable, as anyone can just set the delays to 0s for a faster experience.
As you mentioned above “you can only achieve good enough privacy if that is the default behavior of the network”, I believe there’s a reason we don’t want to say “the enforced behavior of the network”, as in we still want to allow people to tweak their node if they really want to.
If all implementations have forwarding batching, sender & receiver delays and many other enhancements for privacy turned on (maybe some not even configurable), then would the majority of the network choose to nullify them? All we can really do is guide the user into making the right choices by controlling what’s configurable, what the default values are, and by making sure to highlight the privacy impact of certain configuration choices in documentation.
Final personal note
Attributable failures are very good at defining the hop that gets the blame in a route, not retrieving the latencies. The reported latencies are by nature “handwavy”, it’s what the node claims to have held the HTLC for. Any (sane) pathfinding algorithm would normalize that value first before incorporating it.
One of the arguments against expressive latency is that we’re guiding nodes into picking the super fast chosen few routing nodes for payments and channel opens, weakening the topology of the lightning network. That’s already happening today by having websites score nodes for you and then guiding you into choosing the best ones, which is already a worse version of the problem being played out right now.
Instead I’d like to see a future where we don’t have to rely on external websites to source metrics and data for the network from and what your own node provides locally would be more than sufficient. The very existence of these websites is an indicator that people desire performance, and it’s better to satisfy performance locally and on a p2p level (alongside privacy) rather than by submitting or fetching stats.
Proposed way forward
Keep the latency encoding as a uint64, where the value is the milliseconds the HTLC was held for. Each implementation is free to do bucketing or thresholds on the values they report when forwarding, without the need to report it. Similarly, the sender is free to apply thresholds or bucketing on the reported values, without signalling if they’re doing it or not. Whether the former are going to be configurable is also up to the implementations (personal opinion is to not have it configurable, i.e someone has to build their own binary to change it).
If we ever have a more solid foundation on changing the encoding to be something specific then we can always upgrade to a more strict encoding (use a new TLV field and eventually deprecate the old one).