Hi list,
We would like to share with you our recent research on jamming in Lightning. We propose a combination of unconditional (~ upfront) fees and local reputation to fight jamming. We believe this can be a basis for an efficient and practical solution that can be implemented in the foreseeable future.
The full paper is available [1].
We classify jams into quick (resolve in seconds, mimicking honest payments) and slow (remain in-flight for hours or days). Fees disincentivize an attack where quick jams are constantly resolved and sent again. Reputation, in turn, allows nodes to deprioritize peers who consistently forward slow jams.
We believe that our proposal is practical and efficient. In particular, we have shown that the additional (unconditional) fees can be relatively low (as low as 2% of the total fee) to fully compensate jamming victims for the lost routing revenue. Moreover, the total unconditional fee paid for all failed attempts stays low even if the failure rate is reasonably high. This means that the UX burden of paying for failed attempts is also low. A straightforward PoC implementation [2] demonstrates one approach to implementing the fee-related aspect of our proposal.
Further sections provide more details on our approach and results.
# Jamming
As a reminder, jamming is a DoS attack where a malicious sender initiates payments (jams) but delays finalizing them, blocking channels along the route until the jams are resolved. Jamming may target liquidity or payment slots.
We distinguish between quick and slow jamming. Quick jamming implies that jams are failed and re-sent every few seconds, making them hardly distinguishable from honest failing payments. In slow jamming, jams remain in-flight for hours.
# Unconditional fees
We propose unconditional fees to discourage quick jamming. Currently, jams are free because routing nodes don’t charge for failed payment attempts. With unconditional fees, however, jamming is no longer free.
Our simulations indicate that unconditional fees don’t have to be too high. Under certain assumptions about the honest payment flow, a fee increase by just 2% (paid upfront) fully compensates a routing node under attack. Our simulator is open-source [3]. A PoC implementation demonstrates one approach to implementing unconditional fees and only requires minor changes [2].
We have also considered the UX implications of paying for failed attempts. We have concluded that this should not be a deal-breaker, as the total unconditional fee paid stays low even if the failure rate is reasonably high (even as high as 50%). Privacy and incentives are also discussed in the paper.
# Reputation
Fees are not very effective in preventing slow jamming: this type of attack requires only a few jams, therefore, fees would have to be too high to be effective. Instead, we address slow jamming using local reputation.
As per our proposal, nodes keep track of their peers’ past behavior. A routing node considers its peer “good” if it only forwards honest payments that resolve quickly and bring sufficient fee revenue. A peer that forwards jams, in contrast, loses reputation. Payments endorsed by a high-reputation peer are forwarded on the best efforts basis, while other (“high-risk”) payments can only use a predefined quota of liquidity and slots. Unless the attacker has built up a reputation in advance, it cannot fully jam a channel with at least some liquidity allocated exclusively to low-risk payments. Nodes parameterize their channels according to their risk tolerance.
# Alternatives and Future Work
In this work, we strive for a systematic approach. First, we list five properties a potential mitigation strategy should have: effectiveness, incentive compatibility, user experience, privacy and security, and ease of implementation. Then, we go over the design decisions to be made when constructing a countermeasure against jamming. Based on the desired criteria and the available options, we converge on a solution.
Multiple approaches to jamming mitigation have been discussed on this list and elsewhere. Many of them may well be worth exploring, such as resolution-time-dependent fee amounts or stake certificates for reputation building. However, we believe that our solution strikes a good balance: it addresses the problem in question and is relatively straightforward to implement.
We would love to bring this idea closer to implementation, and we plan to discuss it over the next spec meeting [4] (Monday, 2022-11-07). We’d greatly appreciate your feedback!
Kind regards,
Sergei and Clara
[1] - https://github.com/s-tikhomirov/ln-jamming-simulator/blob/master/unjamming-lightning.pdf
[2] - https://github.com/sr-gi/rust-lightning/commit/ce606)
[3] - https://github.com/s-tikhomirov/ln-jamming-simulator
[4] - https://github.com/lightning/bolts/issues/1038