Latency and Privacy in Lightning

Posted by t-bast

Jun 3, 2025/10:05 UTC

In the recent specification meeting, several proposals were evaluated concerning how to report hold times in attributable failures, each with its unique set of advantages and disadvantages. The discussion revolved around three primary options aimed at optimizing the reporting process.

The first option on the table was to maintain the status quo by not altering the current system, which reports hold times with millisecond precision. This approach ensures that no immediate changes are required in the system's infrastructure or reporting mechanisms. However, it may not address potential concerns related to the granularity of time measurement and its impact on data analysis or system performance.

Alternatively, a significant modification was considered: changing the encoding of hold times in attributable failures to a specified granularity, denoted as X milliseconds. This adjustment would standardize time reporting and could potentially simplify data processing and analysis. Yet, determining the optimal value for X poses a challenge, as it necessitates a balance between sufficient detail for analysis and avoiding unnecessary complexity in data handling. Moreover, this change would require updates to the system's architecture, possibly involving considerable effort in implementation and adaptation.

The third proposal introduces a nuanced approach by retaining millisecond granularity but incorporating a hard-coded threshold value from which nodes would subtract when reporting hold times. This method aims to preserve detailed timing information while mitigating certain issues associated with very short or negligible hold times. Various iterations of this idea were discussed, indicating a range of possible implementations. Each variation presents its own set of technical implications, including the potential for added complexity in node operation and the necessity for careful calibration of the threshold value to ensure it effectively addresses the identified issues without introducing new problems.

In summary, the meeting deliberated on three distinct strategies for enhancing the reporting of hold times in attributable failures. Each option comes with its inherent benefits and challenges, ranging from maintaining the existing system for simplicity, adjusting granularity for uniformity, or subtracting a threshold value for refined accuracy. The decision on which path to pursue requires further analysis and consideration of the trade-offs involved in terms of system compatibility, data utility, and implementation feasibility.

Link to Raw Post
Bitcoin Logo

TLDR

Join Our Newsletter

We’ll email you summaries of the latest discussions from authoritative bitcoin sources, like bitcoin-dev, lightning-dev, and Delving Bitcoin.

Explore all Products

ChatBTC imageBitcoin searchBitcoin TranscriptsSaving SatoshiBitcoin Transcripts Review
Built with 🧡 by the Bitcoin Dev Project
View our public visitor count

We'd love to hear your feedback on this project?

Give Feedback