lightningdevkit
Don't reject high remote `dust_limit_satoshis` when `anchor_outputs_zero_fee_htlc_tx` is used
When opening channels, you currently reject the channel request if the remote dust_limit_satoshis is too high.
While you should restrict the remote dust_limit_satoshis to avoid constantly running into dust tolerance threshold issues, you should allow values up to around 10 000 sats (at least when using anchor_outputs_zero_fee_htlc_tx or similar channel types where the pre-signed HTLC transactions don't pay fees), otherwise we're needlessly creating outputs in the commitment transactions that cannot be spent on-chain.
Before anchor_outputs_zero_fee_htlc_tx, we used the commitment feerate to "trim" outputs that couldn't be spent on-chain.
With a feerate of 20 sat/byte, the result is that we trimmed HTLC outputs that were below ~4000 sats.
Since we introduced anchor_outputs_zero_fee_htlc_tx, we only use the static dust_limit_satoshis value to decide whether we trim outputs or not.
We must thus allow that value to reflect the real thresholds at which outputs can be spent with a reasonable feerate.
We plan to set our dust limit to 4000 sat by default in eclair, to match the behavior we had with a 20 sat/byte feerate.
Please update your implementation to allow this, otherwise we may be polluting the utxo set for no good reason (and potentially, forever).
Huh, I vaguely recall a spec discussion a few years ago where we said we'd fix the dust limit to the standardness rules from Bitcoin Core as a partial step towards dust-inflation-attack mitigations. I suppose we could allow it to be higher now that we have more cohesive dust-inflation mitigation, though.
we'd fix the dust limit to the standardness rules from Bitcoin Core
I don't see how we could do that for HTLC outputs: if we create a 330 sat HTLC output, we will never be able to economically spend it, even at 1 sat/byte, so it will pollute the utxo set forever, won't it?
I suppose we could allow it to be higher now that we have more cohesive dust-inflation mitigation, though.
Exactly, with anchor_output_zero_fee_htlc_txs and onwards, we don't have the annoying update_fee side effects that we had before (where previously untrimmed outputs suddenly became trimmed and thus created a large dust amount in the commit tx), since pre-signed HTLC transactions never pay fees. It's thus trivial to safely protect against dust inflation without force-closing, so we can use a higher dust_limit_satoshis value to ensure that we don't unnecessarily inflate the commit tx weight with outputs that aren't economical.
I don't see how we could do that for HTLC outputs: if we create a 330 sat HTLC output, we will never be able to economically spend it, even at 1 sat/byte, so it will pollute the utxo set forever, won't it?
I mean the prevailing feerate is now < 1 sat/vB :p. But my point was just that we'd added that check a while ago when there was some agreement from everyone to do it and didn't re-consider it now that we have total dust exposure limits.
Exactly, with anchor_output_zero_fee_htlc_txs and onwards, we don't have the annoying update_fee side effects that we had before (where previously untrimmed outputs suddenly became trimmed and thus created a large dust amount in the commit tx), since pre-signed HTLC transactions never pay fees
It wasn't even just this IIRC, even ignoring update-fee dust increases, there's also just a question of how to limit the dust_limit so that someone can't just stuff the commitment with many dust HTLCs.
It's thus trivial to safely protect against dust inflation without force-closing, so we can use a higher dust_limit_satoshis value to ensure that we don't unnecessarily inflate the commit tx weight with outputs that aren't economical.
Right. Maybe we should update the spec here? Kinda annoying if we never actually updated the spec to require the dust limit field be the policy value, but we should spell that out and spell out that it doesn't need to be for 0FC.
Right. Maybe we should update the spec here?
Definitely, I took a look at it and it doesn't provide good guidance here. I'll make a PR this week to fix that.