Local Reputation to Mitigate Slow Jamming



Summary:

The Lightning network protocol is being developed to prevent jamming attacks on the network. The proposed solution includes upfront fees along with reputation-based forwarding to solve "slow jamming", where the jamming transaction takes a long time to resolve. Each node gives a binary reputation to its neighbour, and each channel has a quota of liquidity and slots dedicated to transactions coming from neighbours with reputation 0 or for transactions coming from neighbours with reputation 1 that were not endorsed by the neighbour. To gain good reputation, Alice starts at 0 and gains and keeps her reputation score of 1 by continuously paying more fees to Bob than the damage she can inflict. The three main parameters for reputation that each node operator picks are S,L and M. S should be chosen as the maximum time an HTLC can be unresolved in any of Bob’s channels. 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 has reputation 1 if, in the last L seconds, she has forwarded payments that generated M satoshi in fees. The reputation management happens locally, and the only protocol change needed is the ability to signal endorsement as a TLV in UpdateAddHTLC. The various parameters can be selected for various risk preferences. The proposed formula for reputation is detailed in the document shared by Thomas HUET. He suggests that the local reputation is more important than upfront fees and should be worked on first because slow jamming attack is more likely against the network today. Regarding the formula itself, he would treat all scores as continuous values between 0 and 1 instead of binary classes. The advantage of using more bits is that we can be more precise in which HTLCs we reject and reduce the number of innocent casualties. The reputation management happens locally, and the only protocol change needed is the ability to signal endorsement as a TLV in UpdateAddHTLC. The various parameters can be selected for various risk preferences. Following this thread, it is important to note that we are only giving reputation to our direct neighbours. An advantage of this is that we have repeated interactions with them. In practice, this is also the only clean data we have to use when deciding whether to forward an HTLC or not.


Updated on: 2023-06-03T12:04:24.464960+00:00