lightning-dev

Hold fees: 402 Payment Required for Lightning itself

Hold fees: 402 Payment Required for Lightning itself

Original Postby Antoine Riard

Posted on: October 15, 2020 13:39 UTC

The Lightning Network faces the issue of spamming the network with HTLCs or holding HTLCs to incapacitate channels, which can be done at low cost to an attacker.

Rate limits and other limits increase the cost of an attack but may also limit the capabilities of honest users. Trustless payment schemes have been considered, but none are satisfactory, and a small bit of trust in Lightning already exists.A proposed solution is for peers to charge each other a hold fee for forwarded HTLCs based on the actual lock time and the HTLC value. This is separate from the routing fee earned when the payment settles. The implementation could involve prepayment or be tightly integrated with the HTLC add/fail/settle messages. Hold fees don't need to be symmetric, and this asymmetry is meant to prevent channel jamming attacks. Honest users will face some costs, and they will have to be selective when building a route. The hold fee scheme is looser compared to previously proposed schemes.However, defining better threat models and agreeing on expected network dynamics resulting from any solution trade-offs sounds required before working on any solution. Statistical observations through a reputation system could mitigate the issue, but it would still not provide resource consumption security to the routing peer in a deterministic way. The evaluation of a reputation-based solution to deter DoS must be evaluated based on the loss of the reputation bearer related to the potential damage that can be inflicted. Efficiency evaluation should consider that reputation sounds harder to compute accurately than a pure payment-based DoS protection system.In this email, Joost proposes leveraging trust relations to present a bill to the actor who deserves it. He invites opinions on this proposal and encourages prioritizing the spam/jam issue in Lightning development. He acknowledges there is more work to be done but emphasizes the urgency of addressing potential adversaries. The Lightning-dev mailing list hosted by the Linux Foundation was the recipient of the email. It is essential to avoid getting stuck in a false trust-vs-trustlessness dichotomy and always bound the discussion to a specific situation. Finally, striving for the most liquid Lightning market possible avoids bias towards past actors and thus may contain centralization inertia.