lightning-dev

Hold fees: 402 Payment Required for Lightning itself

Hold fees: 402 Payment Required for Lightning itself

Original Postby Bastien TEINTURIER

Posted on: October 19, 2020 15:38 UTC

The email thread discusses proposals, attacks, and threat models for Lightning Network's spam-prevention measures.

The author of the email has started summarizing these proposals on GitHub, hoping to help readers avoid pitfalls that previous proposals encountered. The author has kept the summary high-level for now, with the intention of adding technical details as solutions are developed. The email also includes a proposal for a "reverse upfront payment" system, where nodes pay a fee for receiving HTLCs instead of sending them, with a grace period during which no fees are paid. The fee must increase as the HTLC travels downstream to ensure nodes that hold HTLCs longer are penalized more than nodes that fail them fast. The email raises open questions about this proposal, such as whether the fee needs to be based on the time the HTLC is held and what happens when a channel closes.In another part of the email, the thread discusses trustless payment schemes to prevent resource abuse at HTLC relay. The discussion notes that it may be difficult to create a trustless pure payment-based DoS protection system. One suggestion is for peers to charge each other a hold fee for forwarded HTLCs based on the actual lock time and the HTLC value, separate from the routing fee earned when the payment settles. This introduces an asymmetry between the liquidity requester and an honest routing peer. However, there are concerns about the long-term implications of reputation-heavy systems, including the emergence of a reputation market or reputation scarcity, which may introduce bias and centralization inertia. The thread concludes with a call to prioritize finding a good anti-DoS system for Lightning as the outside world develops their trust-based systems.