Fee-Based Spam Prevention For Lightning

It details three types of fees: Upfront Fees, Hold Fees, and Success Fees, each designed to cover the costs and risks associated with processing payments. Upfront Fees consist of a fixed component and two proportional components aimed at covering immediate expenses and risks related to channel funds allocation and potential loss from failed payments. Hold Fees compensate nodes for the opportunity cost tied to funds locked in pending transactions, calculated to yield a 19% annual return. Success Fees, collected upon completing a transaction, incentivize efficient processing through both fixed and proportional components. This protocol also introduces matching fund requirements for burn outputs as a countermeasure to griefing attacks, ensuring mutual interest in transaction success and security.

An update to the paper includes an extensive specification for a lower-latency bug fix, indicating a commitment to continuous improvement and addressing challenges presented in spam mitigation within payment channels. This improvement focuses on retaining network efficiency and user experience despite necessary adjustments for handling not-immediately-settled payments. The clarification around the misconception of needing collateral equivalent to a channel's capacity further refines the protocol by specifying that only the maximum amount of Upfront and Hold fees for current Hashed Time-Locked Contracts (HTLCs) plus a fixed fraction is required. This adjustment signifies a more efficient approach than previously suggested, leveraging psychological insights and automated protocols to safeguard users from exploitation during transactions.

The correspondence elucidates several aspects of implementing a new protocol within the Lightning Network, highlighting solutions to latency issues introduced by a bug fix and proposing a streamlined transaction process. It suggests excluding update_add_htlc messages and assuming symmetric commitment transactions to simplify the operational flow. Despite the potential increase in full resolution time, the discussion posits hold fees within Modified Adjusted Duration (MAD)-based Optimistic Payment Routing (OPR)-style protocols as a means to ensure fair compensation for delayed payments. Furthermore, it explores the adoption of hold invoices to cater to demands for not immediately settling payments while ensuring equitable remuneration for involved nodes.

In discussing the handling of Hold Fees for HTLCs, a two-step update process for the downstream node's Commitment transaction is proposed. This process aims to mitigate the identified problem by safely incorporating increased burn funds to cover both Upfront and Hold Fees. The suggested modification to the current operational flow involves adding a stage where increased burn funds are included without an HTLC output, followed by their inclusion in subsequent transactions. This ensures a race-free channel environment and explores the use of burn outputs with matching funds as a solution to charge fees based on the duration an HTLC was held.

Addressing criticisms concerning the handling of held HTLCs, the proposal highlights the absence of a universal clock and the challenge of proving message delivery, which could lead to exploitation and unwarranted hold fees. This scenario underscores the potential financial vulnerabilities for parties forced to consider force-closing the channel to avoid further losses. Lastly, the refined protocols propose mechanisms for fee allocation that incentivize cooperation and deter malicious behavior, offering a comprehensive framework for enhancing network performance and reducing spam. This includes strategies for precise fee distribution while protecting privacy and ensuring fair compensation for delayed capital, marking significant progress towards a more secure and cooperative Lightning Network ecosystem.