Latency and Privacy in Lightning

[carla]

@tnull

Yes, adding forwarding delays could be perceived to be unaligned with forwarding nodes’ incentives, however, they already do this and also gain some efficiency and performance from batching HTLCs. Of course, there is a latency trade-off here, but generally it holds that the longer you wait, the higher are the chances that you can benefit from the reduced IO and network-latency overhead of batching HTLCs

Indeed. I think being able to toggle these delays to decide on your IO/latency tradeoff makes a lot of sense afaik LND already allows this.

@tnull

So my personal conclusion is that we might be fine with hold times reporting, as long as we establish best practices around receiver-side delays

Seems like a reasonable idea to me - and something that could be turned on by default to make sure that privacy gets some company!

@tnull

and their exemption from sender-side scoring as mentioned above.

Agree. Timing based scoring will already need to take into account the MPP timeout, so would already need a code path to allow this (just needs to be turned on for single-HTLC payments as well).

@tnull

My concerns regarding BOLT12 privacy are indeed invalid as the introduction point would strip the attribution data. This in turn means that the next node upstream would report a huge latency measurement (as it would cover the entire blinded path’s latency), which is of course bogus and would need to be disregarded during scoring.

I think I’m missing the concern for BOLT 12 a bit here - could you spell it out for me why the introduction point needs to strip attribution data?

I would have thought that the receiving node would just add its own delay (possibly breaking this delay up between any fake hops it added to the blinded route) and then report them back?