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 <bast...@acinq.fr> 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 <elzei...@gmail.com> 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@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
