From elzeigel at gmail.com Fri Apr 23 21:44:07 2021 From: elzeigel at gmail.com (Eugene Siegel) Date: Fri, 23 Apr 2021 17:44:07 -0400 Subject: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs In-Reply-To: References: Message-ID: Thanks for replying. I was under the impression that long-term update_fee was going to be removed since second-level HTLC txn's can bring their own fees? On Fri, Apr 23, 2021 at 12:24 PM Bastien TEINTURIER wrote: > Hi Eugene, > > The reason dust HTLCs count for the 483 HTLC limit is because of > `update_fee`. > If you don't count them and exceed the 483 HTLC limit, you can't lower the > fee anymore > because some HTLCs that were previously dust won't be dust anymore and you > may end > up with more than 483 HTLC outputs in your commitment, which opens the > door to other > kinds of attacks. > > This is the first issue that comes to mind, but there may be other > drawbacks if we dig into > this enough with an attacker's mindset. > > Bastien > > Le ven. 23 avr. 2021 ? 17:58, Eugene Siegel a ?crit : > >> I propose a simple mitigation to increase the capital requirement of >> channel-jamming attacks. This would prevent an unsophisticated attacker >> with low capital from jamming a target channel. It seems to me that this >> is a *free* mitigation without any downsides (besides code-writing), so I'd >> like to hear other opinions. >> >> In a commitment transaction, we trim dust HTLC outputs. I believe that >> the reason for the 483 HTLC limit each side has in the spec is to prevent >> commitment tx's from growing unreasonably large, and to ensure they are >> still valid tx's that can be included in a block. If we don't include dust >> HTLCs in this calculation, since they are not on the commitment tx, we >> still allow 483 (x2) non-dust HTLCs to be included on the commitment tx. >> There could be a configurable limit on the number of outstanding dust >> HTLCs, but the point is that it doesn't affect the non-dust throughput of >> the channel. This raises the capital requirement of channel-jamming so >> that each HTLC must be non-dust, rather than spamming 1 sat payments. >> >> Interested in others' thoughts. >> >> Eugene (Crypt-iQ) >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: