From bastien at acinq.fr Sat Apr 24 08:01:28 2021 From: bastien at acinq.fr (Bastien TEINTURIER) Date: Sat, 24 Apr 2021 10:01:28 +0200 Subject: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs In-Reply-To: <6475DCEE-4D7C-47B3-8B2E-8339009300AE@mattcorallo.com> References: <6475DCEE-4D7C-47B3-8B2E-8339009300AE@mattcorallo.com> Message-ID: You're right, I was thinking about trimmed HTLCs (which can re-appear in the commit tx if you lower the feerate via update_fee). Dust HTLCs will never appear in the commit tx regardless of subsequent update_fees, so Eugene's suggestion could make sense! Le sam. 24 avr. 2021 ? 06:02, Matt Corallo a ?crit : > The update_fee message does not, as far as I recall, change the dust limit > for outputs in a channel (though I?ve suggested making such a change). > > On Apr 23, 2021, at 12:24, 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 >> > _______________________________________________ > 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: