Author: Antoine Riard 2023-03-06 17:29:12
Published on: 2023-03-06T17:29:12+00:00
The Lightning Network developers are currently seeking feedback on a draft for a neighbor reputation setting recommendation as a jamming mitigation. The proposed solution aims to prevent full access to liquidity and slots in a channel, which can result in jamming. It does so by allowing full access only to neighbors that forward HTLCs that resolve quickly and generate more profit than the damage they can potentially create.To implement this solution, each node gives a binary reputation to its neighbor, with each channel having a quota of liquidity and slots dedicated to transactions coming from neighbors with reputation 0 or for transactions coming from neighbors with reputation 1 that were not endorsed by the neighbor. There are three main parameters for reputation that each node operator picks, including S, L, and M. S should be chosen as the maximum time an HTLC can be unresolved in any of Bob’s channels, while M is the revenue generated by Bob’s node in the time S, representing the damage Alice could inflict. L is the time in which Alice should generate M revenue for Bob for her to have a good reputation of 1. Alice gains “good” reputation (i.e., a score of 1) by continuously paying more fees to Bob than the damage she can inflict.For most use cases, having reputation 0 is more than enough. However, the local reputation scheme may suffer from exploitable reputation asymmetries by a jamming adversary, and the dynamic reduction of available outbound liquidity/slots in the occurrence of reputation=0 counterparty's HTLC being only known at the link-level could break the expectations of the HTLC senders' scoring algorithms. This deficiency could be fixed by ensuring a proportionality of the reputation acquisition cost between the inbound channels and the cost requested by a counterparty on an outbound channel, but it would come with the downside that any update in reputation cost should be recursively applied to the downstream links. Additionally, the scheme could suffer from spontaneous jamming by "honest" long-term held packets, where even if Alice is not scored to 1 by Bob, she always settles her long-term held packets.The provided context contains a link to a specific section of code on the GitHub repository for lnd, a Lightning Network Daemon implementation. The link leads to line 51 of the file "link.go" in the "htlcswitch" directory. Additionally, there is a link to an email thread on the lightning-dev mailing list hosted by the Linux Foundation. The email thread contains discussions related to the Lightning Network and its development.
Updated on: 2023-06-03T12:06:04.451772+00:00