Fee-Based Spam Prevention For Lightning

The email discusses a detailed protocol aimed at addressing the latency issues introduced by a bug fix in a payment channel network, specifically focusing on the context of time-dependent Hold Fees for not-immediately-settled payments. Initially, it highlights the latency increase from 1.5 to 2.5 RTTs due to the necessity for the downstream node to wait for the revocation of the upstream node’s commitment transaction that does not include the HTLC output. The sender proposes a method to eliminate this latency penalty while implementing time-dependent Hold Fees with the bug fix. This involves allowing the downstream node to provide consecutive signatures for both the burn funds increase and the addition of the HTLC output without requiring an additional round-trip time. The procedure ensures that if the downstream node commits to the increased burn funds within a grace period, the overall latency remains at 1.5 RTTs, facilitating faster payment propagation.

The email outlines two main scenarios based on whether the increased burn amount is committed during or after the grace period. In the first scenario, where the receiver commits within the grace period, the process follows a streamlined flow that maintains a low latency of 1.5 RTTs for HTLC propagation. The second scenario deals with commitments made after the grace period, resulting in a potential failure to propagate the payment within the desired timeframe but still ensures that the payment fails without unnecessary delays, using a total of 2.5 RTTs. This approach minimizes the impact on network performance and user experience.

Furthermore, the communication details an improved spam prevention protocol that adjusts the rules for providing pc_points and pc_secrets to accommodate up to three current (signed and not revoked) transactions at any time. This adjustment is crucial for maintaining network security and integrity while implementing the proposed latency improvements. The detailed protocol sections meticulously describe the sequence of actions required for adding an HTLC, including update_add_htlc, commitment_signed, and revoke_and_ack messages, showcasing a comprehensive strategy for handling different transaction states effectively.

Lastly, the email delineates allowed flows for the spam prevention protocol with low latency, categorizing various state configurations and transitions that indicate whether an HTLC is speculative, successful, or has failed. These specifications aim to ensure that the network can efficiently manage HTLCs without compromising on latency or security, demonstrating a thoughtful consideration of the technical challenges involved in optimizing payment channel networks.