Latency and Privacy in Lightning

The conversation begins with the identification of a gap in the mechanism for enforcing privacy through forwarding times in network nodes. A novel protocol for "receiver-enforced forwarding randomization" is proposed, altering the traditional process of handling Hashed Timelock Contracts (HTLCs) by introducing batching HTLCs. This method inherently introduces additional latency but is seen as a significant step towards enhancing transaction privacy by mandating a specific sequence of message exchanges before the actual sending of HTLCs in a batch.

Further, the discussion explores mitigating risks associated with matching incoming and outgoing update_add_htlc messages by potential adversaries. Implementing cover traffic and padding messages to uniform sizes is suggested as a strategy to obscure transaction paths, thus improving privacy. However, this approach raises concerns regarding increased bandwidth usage and its impact on network performance, highlighting the need for a delicate balance between privacy enhancement and maintaining system efficiency.

A significant concern discussed is the introduction of forwarding delays and its potential to exacerbate performance issues within the Lightning network. The debate centers around the trade-offs between enhancing privacy through such delays and the resulting slowing down of payment processing. An alternative solution proposes applying delays at the source and destination points, offering users control over their privacy and performance preferences without necessitating widespread protocol changes.

During the last LN spec meeting, discussions focused on the privacy implications of revealing granular HTLC hold times and the possibility of undermining payment privacy by discouraging the use of random forwarding delays. Strategies for encoding hold times and managing the dynamic between user experience and privacy benefits were also examined. Additionally, the categorization of attacks on payment privacy based on the attacker's position (on-path vs. off-path) was analyzed, emphasizing the challenges posed by forwarding delays to both types of attackers.

Finally, the discourse acknowledges the current incentive structures within the Lightning Network, which do not strongly motivate nodes to implement privacy-preserving measures like forwarding delays. It raises concerns about relying on node operators to voluntarily adopt such practices. Proposals include implementing delays at the recipient end for enhanced control over privacy and diversifying retry paths for sender privacy. The discussion concludes with an acknowledgment of the need for improvement in the adoption of privacy-preserving forwarding delays across the network, considering the significant portions operated by LND and Eclair that either do not randomize commitment ticks or do not implement forward delays.