📅 Original date posted:2021-04-23
📝 Original message:
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210423/9068d4e9/attachment-0001.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 13:02:22
in reply to nevent1q…dra3
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 13:02:22Event JSON
{
"id": "d687bd8536234d1cbfd05f8d7506c35820dca9b5e03b4448818200e21e53541a",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315742,
"kind": 1,
"tags": [
[
"e",
"b3e1babcd18c032cd663f50739c5addeb9efde0924211109d945ef414e2f663d",
"",
"root"
],
[
"e",
"edb6a428332d8e642b711559bff7aaa6f9fb1ccde8e43e28034e7d72e3cd9673",
"",
"reply"
],
[
"p",
"897fddf7e8d6dceae0590dbd4ecf88e3702c23e1384b9916dd4eecc41896af39"
]
],
"content": "📅 Original date posted:2021-04-23\n📝 Original message:\nHi Eugene,\n\nThe reason dust HTLCs count for the 483 HTLC limit is because of\n`update_fee`.\nIf you don't count them and exceed the 483 HTLC limit, you can't lower the\nfee anymore\nbecause some HTLCs that were previously dust won't be dust anymore and you\nmay end\nup with more than 483 HTLC outputs in your commitment, which opens the door\nto other\nkinds of attacks.\n\nThis is the first issue that comes to mind, but there may be other\ndrawbacks if we dig into\nthis enough with an attacker's mindset.\n\nBastien\n\nLe ven. 23 avr. 2021 à 17:58, Eugene Siegel \u003celzeigel at gmail.com\u003e a écrit :\n\n\u003e I propose a simple mitigation to increase the capital requirement of\n\u003e channel-jamming attacks. This would prevent an unsophisticated attacker\n\u003e with low capital from jamming a target channel. It seems to me that this\n\u003e is a *free* mitigation without any downsides (besides code-writing), so I'd\n\u003e like to hear other opinions.\n\u003e\n\u003e In a commitment transaction, we trim dust HTLC outputs. I believe that\n\u003e the reason for the 483 HTLC limit each side has in the spec is to prevent\n\u003e commitment tx's from growing unreasonably large, and to ensure they are\n\u003e still valid tx's that can be included in a block. If we don't include dust\n\u003e HTLCs in this calculation, since they are not on the commitment tx, we\n\u003e still allow 483 (x2) non-dust HTLCs to be included on the commitment tx.\n\u003e There could be a configurable limit on the number of outstanding dust\n\u003e HTLCs, but the point is that it doesn't affect the non-dust throughput of\n\u003e the channel. This raises the capital requirement of channel-jamming so\n\u003e that each HTLC must be non-dust, rather than spamming 1 sat payments.\n\u003e\n\u003e Interested in others' thoughts.\n\u003e\n\u003e Eugene (Crypt-iQ)\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210423/9068d4e9/attachment-0001.html\u003e",
"sig": "01eee2fbbffa93bed0beecb7ea9ba88a86a6486677e47e8f304ff0a30c27c963bbdb8818b3b89a9de00be04ab6f09a8a18d392578207fa3a3b237df87b4c40a2"
}