Latency and Privacy in Lightning

The discussion emphasizes the importance of addressing fundamental privacy improvements in the Lightning Network (LN) beyond merely applying superficial privacy measures to sender feedback. It highlights that real privacy enhancements, such as implementing forwarding and sender/receiver delays, are crucial for mitigating vulnerabilities against on/off path adversaries. These strategies are viewed as more substantial than obfuscating latency data sent to the sender, which does not significantly hinder an adversary's ability to analyze traffic.

The conversation also touches upon the debate over the necessity of a prefix in latency reporting within the network. The consensus suggests that maintaining simplicity in latency encoding (using uint64 for milliseconds the HTLC was held for) without requiring explicit notification of rounding or bucketing practices is preferred. This simplification aligns with the assertion that genuine privacy and performance enhancements should not compromise the network's usability or speed, as these attributes are fundamental to LN's daily operational success.

Furthermore, the dialogue underscores an essential perspective on user autonomy and the default behavior of network configurations. It advocates for a balance between guiding users towards privacy-respecting choices and allowing individual adjustments to node settings. The goal is to encourage the adoption of privacy-enhancing features as standard, potentially non-configurable elements of the network, thereby fostering a more secure environment by default.

A critical point of concern raised is the potential for latency metrics to influence the centralization of routing decisions, steering users toward a select few high-performance nodes and thus impacting the network's overall topology. The discussion suggests moving away from reliance on external websites for node metrics, advocating for a future where nodes locally provide sufficient data for performance and privacy decision-making, enhancing the LN's p2p ethos.

The proposed way forward maintains the uint64 encoding for latency reporting, allowing implementations the freedom to apply bucketing or thresholds as they see fit without mandatory disclosure of these practices. This approach aims to preserve flexibility and simplicity in latency reporting while keeping the door open for future protocol enhancements that could introduce more specific encoding methodologies if deemed necessary.