Thanks to everyone that came to the meeting, it was a great conversation and gave us a lot to think about!
Matt – I don't know that I agree with "... upfront payments kinda kill the lightning UX ...". I think that upfront fees are almost essential, even outside the context of jamming. This also helps with probing, general spam, and other aspects. Furthermore, I think that the UX is very explainable, and in general nodes shouldn't be motivated to send a lot of failed payments, and should adopt better routing strategies. About Rusty's suggestions, I plan to look at it again, but if I remember correctly, there are privacy issues there. I agree that we should tread carefully and not rush into things, let's keep discussing this. I'll try to set up another meeting sometime soon. On Mon, Nov 14, 2022 at 4:39 PM Matt Corallo <lf-li...@mattcorallo.com> wrote: > Thanks for committing all the time today. I’m much happier with (binary, > not-so-)local reputation than I was in the past, at least as better than > other reputation systems. > > I believe you’ve stated a few times that local reputation by itself is far > from sufficient and that’s why we need upfront payments. Intuitively this > makes sense to me but I’m sure you have more data to back that up. It’s > come up a few times that upfront payments kinda kill the lightning UX if > they’re at all nontrivial. Just restating here to make sure we’re on the > same page. > > One thing I think we need to research more is how this compares to Rusty’s > old proof-of-channel-closure idea. Philosophically it’s quite nice to > punish the one holding an HTLC over punishing the sender, especially in a > world where people are getting options in USD<->BTC through HTLCs or > sending to mobile nodes that sit on payments. Practically I’m not sure if > there’s a strong need to worry about a large hub sitting on HTLCs to jam > instead of a sender being involved, but having zero mitigation against it > also seems wrong. > > As always I’m a bit dubious of doing something, especially that required > network-wide upgrade, until we’re confident it’s the right direction. Even > binary HTLC reputation flags, I think, carry a very large privacy cost so > it’s strongly worth exploring every alternative before we commit. > > Matt > > On Nov 10, 2022, at 10:35, Clara Shikhelman <clara.shikhel...@gmail.com> > wrote: > > > 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 > >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
