Latency and Privacy in Lightning

During the last LN spec meeting, a significant discussion unfolded around the privacy implications of revealing granular HTLC hold times through attributable failures. The consensus was that while the current specification permits forwarding nodes to disclose the time they held the HTLC in milliseconds, this could potentially undermine payment privacy by discouraging the use of random forwarding delays—a technique proposed to enhance privacy. It was suggested that encoding hold times in terms of block time rather than milliseconds could mitigate this issue, as it would inherently include processing and random delay times, making it harder for nodes to report inaccurately low values.

The conversation also delved into strategies for balancing the trade-offs between user experience, characterized by fast payments, and the privacy benefits of forwarding delays. Questions arose about setting minimum delay values, handling future increases in forwarding delays, and the overall management of this UX/privacy dynamic.

Attacks on payment privacy can be categorized based on the position of the attacker: on-path and off-path. On-path attackers engage directly with the network to deanonymize transactions by analyzing latency and transaction patterns. They create channels to attract traffic and then attempt to identify senders and receivers by comparing transaction times to their latency estimates. A random forwarding delay complicates this analysis by introducing variability that can mislead the attacker's estimations.

Off-path attackers, meanwhile, rely on external monitoring and analysis of network traffic, employing methods like ICMP ping to estimate latencies and then piecing together partial paths of transactions. These attackers use size and direction of messages to infer sender and receiver identities without necessarily depending on timing information. Here, too, forwarding delays pose a challenge by disrupting the attacker's ability to accurately construct transaction paths.

However, the incentive structures within the Lightning Network currently do not strongly motivate nodes to implement measures that preserve privacy, such as forwarding delays. Profit-driven nodes prioritize throughput and efficiency, potentially at the cost of privacy. This raises concerns about the effectiveness of relying on node operators to voluntarily adopt privacy-preserving practices.

Proposals for enhancing privacy protection include implementing delays at the recipient end instead of relying solely on forwarding nodes, which allows recipients more control over their privacy. For sender privacy, diversifying retry paths and introducing cooldown periods between payment attempts are suggested. These measures put more power in the hands of the users most concerned about their privacy.

Finally, the discussion acknowledged that the current state of the Lightning Network lacks widespread adoption of privacy-preserving forwarding delays. With significant portions of the network operated by LND and Eclair, which either do not randomize commitment ticks or do not implement forward delays, there's an identified need for improvement. The debate remains open on whether the best course of action is to enforce the use of forwarding delays through protocol changes or to explore alternative privacy-enhancing measures recommended during the discussion.