Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs
I looked into this more closely, and as far as I understand it, the spec already states that you should not count dust HTLCs: Oops! We do the same thing, we will fix that. On 4/26/21 11:03, Eugene Siegel wrote: I would have to think more about the issue where it's not possible to lower the feerate though. That seems like a spec issue? There is no current in-protocol way to change the dust limit, so the issue doesn't apply here. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs
Lnd counts dust + trimmed HTLCs towards max_accepted_htlcs. We definitely shouldn't be counting dust towards that amount. I would have to think more about the issue where it's not possible to lower the feerate though. That seems like a spec issue? ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs
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 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 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 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 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
Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs
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 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 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 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
Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs
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 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 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
Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs
Thanks for replying. I was under the impression that long-term update_fee was going to be removed since second-level HTLC txn's can bring their own fees? On Fri, Apr 23, 2021 at 12:24 PM Bastien TEINTURIER 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 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
Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs
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 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] Increase channel-jamming capital requirements by not counting dust HTLCs
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
