Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2021-04-24 📝 Original message: You're right, I was ...
📅 Original date posted:2021-04-24
📝 Original message:
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 <lf-lists at mattcorallo.com> 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 <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/e0afd2d9/attachment.html>;
📝 Original message:
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 <lf-lists at mattcorallo.com> 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 <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/e0afd2d9/attachment.html>;