đź“… Original date posted:2021-04-26
đź“ť Original message:
I looked into this more closely, and as far as I understand it, the spec
already states that you should not count dust HTLCs:
*if result would be offering more than the remote's max_accepted_htlcs
HTLCs, in the remote commitment transaction: *
- *MUST NOT add an HTLC.*
Note that it clearly says "in the remote commitment transaction", which
means
you don't count HTLCs that are dust or trimmed.
That matches eclair's behavior: we don't count dust HTLCs towards that
limit.
Is lnd including them in that count? What about other implementations?
If that's the case, that can simply be fixed in lnd without any spec change
IMHO.
Note that this also excludes trimmed HTLCs from the count, which means that
nodes that set `max_accepted_htlcs` to 483 may be exposed to the issue I
described earlier (impossible to lower the feerate because the HTLC count
would
become greater than the limit).
Bastien
Le sam. 24 avr. 2021 Ă 10:01, Bastien TEINTURIER <bastien at acinq.fr> a
Ă©crit :
> 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/20210426/a59c0007/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:02:23
in reply to nevent1q…r6vw
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:02:23Event JSON
{
"id": "16df8cf3e0a972a8524928f35871f88271e7f53d5c4bd65d473aa80ba169894a",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315743,
"kind": 1,
"tags": [
[
"e",
"b3e1babcd18c032cd663f50739c5addeb9efde0924211109d945ef414e2f663d",
"",
"root"
],
[
"e",
"61a967e617ff4e1fe590ff4d34ddc022b0ede0a7b3c748662e0ea39fa9e01fae",
"",
"reply"
],
[
"p",
"f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb"
]
],
"content": "📅 Original date posted:2021-04-26\n📝 Original message:\nI looked into this more closely, and as far as I understand it, the spec\nalready states that you should not count dust HTLCs:\n\n*if result would be offering more than the remote's max_accepted_htlcs\nHTLCs, in the remote commitment transaction: *\n\n - *MUST NOT add an HTLC.*\n\nNote that it clearly says \"in the remote commitment transaction\", which\nmeans\nyou don't count HTLCs that are dust or trimmed.\n\nThat matches eclair's behavior: we don't count dust HTLCs towards that\nlimit.\nIs lnd including them in that count? What about other implementations?\nIf that's the case, that can simply be fixed in lnd without any spec change\nIMHO.\n\nNote that this also excludes trimmed HTLCs from the count, which means that\nnodes that set `max_accepted_htlcs` to 483 may be exposed to the issue I\ndescribed earlier (impossible to lower the feerate because the HTLC count\nwould\nbecome greater than the limit).\n\nBastien\n\nLe sam. 24 avr. 2021 à 10:01, Bastien TEINTURIER \u003cbastien at acinq.fr\u003e a\nécrit :\n\n\u003e You're right, I was thinking about trimmed HTLCs (which can re-appear in\n\u003e the commit tx\n\u003e if you lower the feerate via update_fee).\n\u003e\n\u003e Dust HTLCs will never appear in the commit tx regardless of subsequent\n\u003e update_fees,\n\u003e so Eugene's suggestion could make sense!\n\u003e\n\u003e Le sam. 24 avr. 2021 à 06:02, Matt Corallo \u003clf-lists at mattcorallo.com\u003e a\n\u003e écrit :\n\u003e\n\u003e\u003e The update_fee message does not, as far as I recall, change the dust\n\u003e\u003e limit for outputs in a channel (though I’ve suggested making such a change).\n\u003e\u003e\n\u003e\u003e On Apr 23, 2021, at 12:24, Bastien TEINTURIER \u003cbastien at acinq.fr\u003e wrote:\n\u003e\u003e\n\u003e\u003e \n\u003e\u003e Hi Eugene,\n\u003e\u003e\n\u003e\u003e The reason dust HTLCs count for the 483 HTLC limit is because of\n\u003e\u003e `update_fee`.\n\u003e\u003e If you don't count them and exceed the 483 HTLC limit, you can't lower\n\u003e\u003e the fee anymore\n\u003e\u003e because some HTLCs that were previously dust won't be dust anymore and\n\u003e\u003e you may end\n\u003e\u003e up with more than 483 HTLC outputs in your commitment, which opens the\n\u003e\u003e door to other\n\u003e\u003e kinds of attacks.\n\u003e\u003e\n\u003e\u003e This is the first issue that comes to mind, but there may be other\n\u003e\u003e drawbacks if we dig into\n\u003e\u003e this enough with an attacker's mindset.\n\u003e\u003e\n\u003e\u003e Bastien\n\u003e\u003e\n\u003e\u003e Le ven. 23 avr. 2021 à 17:58, Eugene Siegel \u003celzeigel at gmail.com\u003e a\n\u003e\u003e écrit :\n\u003e\u003e\n\u003e\u003e\u003e I propose a simple mitigation to increase the capital requirement of\n\u003e\u003e\u003e channel-jamming attacks. This would prevent an unsophisticated attacker\n\u003e\u003e\u003e with low capital from jamming a target channel. It seems to me that this\n\u003e\u003e\u003e is a *free* mitigation without any downsides (besides code-writing), so I'd\n\u003e\u003e\u003e like to hear other opinions.\n\u003e\u003e\u003e\n\u003e\u003e\u003e In a commitment transaction, we trim dust HTLC outputs. I believe that\n\u003e\u003e\u003e the reason for the 483 HTLC limit each side has in the spec is to prevent\n\u003e\u003e\u003e commitment tx's from growing unreasonably large, and to ensure they are\n\u003e\u003e\u003e still valid tx's that can be included in a block. If we don't include dust\n\u003e\u003e\u003e HTLCs in this calculation, since they are not on the commitment tx, we\n\u003e\u003e\u003e still allow 483 (x2) non-dust HTLCs to be included on the commitment tx.\n\u003e\u003e\u003e There could be a configurable limit on the number of outstanding dust\n\u003e\u003e\u003e HTLCs, but the point is that it doesn't affect the non-dust throughput of\n\u003e\u003e\u003e the channel. This raises the capital requirement of channel-jamming so\n\u003e\u003e\u003e that each HTLC must be non-dust, rather than spamming 1 sat payments.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Interested in others' thoughts.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Eugene (Crypt-iQ)\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e Lightning-dev mailing list\n\u003e\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\n\u003e\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210426/a59c0007/attachment.html\u003e",
"sig": "09474ba8df4b45f2861f9418262416e61f5cfe82ce959e3d5041bced8e7365ccd28d852500cb3b538856a18b211ec639b6c651388b5002a62346eaf4cebc8ce4"
}