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
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?
___
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
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
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
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
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
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
