Published on: 2023-03-06T18:53:59+00:00
The proposed solution to prevent jamming attacks on the Lightning Network includes upfront fees and reputation-based forwarding. It aims to differentiate between active attackers and low-traffic neighbors. Each node gives a binary reputation to its neighbor, and channels have quotas for transactions based on neighbor reputation. Alice gains and maintains a good reputation by continuously paying more fees to Bob than potential damage. The proposal highlights the importance of local reputation and suggests treating reputation scores as continuous values. It also addresses the challenge of reporting confidence truthfully without negative impacts.The Lightning-dev mailing list serves as a platform for discussions related to the development of the Lightning Network. It is used by developers to share ideas, discuss technical issues, and coordinate efforts. The mailing list is open to anyone interested in contributing to the development of the Lightning Network.The Lightning Network development team is seeking early feedback on a draft for a neighbor reputation setting recommendation to prevent jamming in the network. The proposed solution includes upfront fees along with reputation-based forwarding. This approach aims to address the issue of "slow jamming," where transactions take a long time to resolve.Under this solution, each node assigns a binary reputation to its direct neighbors. Additionally, each channel has a designated quota of liquidity and slots specifically allocated for transactions from neighbors with a reputation of 0 or for transactions from neighbors with a reputation of 1 that were not endorsed by the neighbor.To maintain a "good" reputation, Alice must continuously pay more fees to Bob than the potential damage she could inflict. The main parameters for reputation that each node operator selects are S, L, and M. S represents the maximum time an HTLC (Hash Time Locked Contract) can remain unresolved in any of Bob's channels. M represents the revenue generated by Bob's node within the time S, representing the potential damage Alice could cause. L is the time window within which Alice must generate M revenue for Bob in order to have a reputation score of 1. It is suggested that L be set as 10 times the value of S (L=10S).For Alice to achieve a reputation score of 1, she must have forwarded payments in the last L seconds that generated M satoshi in fees. The fee for a single transaction is normalized based on the time it took for the HTLC to resolve, counted in slots of 10 seconds.Reputation management is handled locally, and the only required protocol change is the ability to signal endorsement as a TLV (Type-Length-Value) in the UpdateAddHTLC message. The proposed formula treats reputation scores as continuous values between 0 and 1, rather than binary classes. Using more bits allows for greater precision in rejecting specific HTLCs, thereby reducing the number of innocent casualties.It is important to note that reputation is only assigned to direct neighbors, and this is the only reliable data available when deciding whether or not to forward an HTLC. The team acknowledges that the current recommendation suggests a binary reputation for simplicity, but also recognizes the potential value in exploring multiple reputation buckets for further study. Reputation primarily comes into play during channel attacks, where not all transactions are permitted to go through.
Updated on: 2023-08-01T01:02:18.660919+00:00