Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2021-04-24 📝 Original message: The update_fee message ...
📅 Original date posted:2021-04-24
📝 Original message:
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 <bastien at 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 <elzeigel at 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 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210424/b09dc276/attachment.html>;
📝 Original message:
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 <bastien at 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 <elzeigel at 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 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210424/b09dc276/attachment.html>;