lightningnetwork
Don't reject high remote `dust_limit_satoshis` when `anchor_outputs_zero_fee_htlc_tx` is used
Pre-Submission Checklist
- [x] I have searched the existing issues and believe this is a new bug.
- [x] I am not asking a question about how to use lnd, but reporting a bug (otherwise open a discussion).
LND Version
v0.19.3-beta
LND Configuration
Nothing specific.
Backend Version
Bitcoin Core v29.1
Backend Configuration
Nothing specific.
OS/Distribution
Ubuntu 24
Bug Details & Steps to Reproduce
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).
Expected Behavior
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).
Debug Information
No response
Environment
No response
I've created a related spec PR in https://github.com/lightning/bolts/pull/1301
