Hi all, We are planning a call to discuss this proposal further. It will be on Monday the 14th, at 7 pm UTC here: https://meet.jit.si/UnjammingLN
Please let me know if this conflicts with any other Bitcoin event. Hope to see you all there! On Thu, Nov 3, 2022 at 1:25 PM Clara Shikhelman <clara.shikhel...@gmail.com> wrote: > 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 > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
