Latency and Privacy in Lightning

The recent specification meeting brought to light a general consensus on the diminished necessity of relying on forwarding delays for privacy protection against on-path attackers, given the advent of receiver-side delays. This development paves the way for the implementation and deployment of Proposal 1263, which is expected to significantly enhance privacy safeguards against known attacks. The conversation also highlighted that, in a scenario dominated by receiver delays, forwarding delays primarily serve to complicate the efforts of off-path adversaries in tracing payment paths throughout the network.

Despite the outlined benefits, the effectiveness of forwarding delays in preserving privacy remains a topic of debate, particularly concerning their ability to mitigate the risk of sender/receiver deanonymization by off-path adversaries. The challenge lies in determining an optimal delay duration that accommodates the highly variable nature of node traffic, influenced by factors such as time of day and dynamic channel activities. This complexity invites further exploration into alternative privacy measures that could potentially offer more robust protections without the drawbacks associated with forwarding delays.

Among the alternatives discussed, message padding and the implementation of cover traffic mechanisms, akin to Dandelion for the Lightning Network (LN), emerge as promising solutions. These strategies are favored for several reasons: they extend privacy protections to less trafficked nodes at the network's periphery; they present a more acceptable bandwidth/privacy trade-off compared to the latency/privacy compromise inherent to forwarding delays; and they allow for latency probing by attackers without directly attributable failures, albeit at a cost. This analysis suggests that forwarding delays might not be the most effective or promising method for future privacy enhancements within the network.

In light of these considerations, the proposal to maintain millisecond encoding while introducing a sender-side advisory against penalizing hops under a certain latency threshold (e.g., 300ms) was put forward. This approach aims to establish a default setting that alleviates pressure on forwarding delays without precluding the possibility of future adjustments based on emerging privacy concerns or findings. The expectation is that the majority of the network will adopt this default, likely without explicit awareness, thereby ensuring a balance between operational flexibility and privacy preservation.