Rethink default dust limit #2922
Comments
|
Isn't this mainly an issue on Signet? Should we start introducing more per-network defaults/settings which would, e.g., also allow us to introduce some (~static) defaults for Testnet? This might improve the interop situation with LND and CLN, which (AFAIK both) set static fee rates on testnet that regularly conflict with our dynamic estimates. |
|
Hmm, I mean if feerates ever drop back down to 1 sat/vB on mainnet it would be an issue there as well, I assume. It may be that there's no reasonable value here that scales across feerates (and maybe we need a multiplier + const config, rather than a simple multiplier), but it would be good to run some analysis here that's more rigorous. |
|
As for static feerates on testnet, I think we can just do that downstream of LDK? Maybe document it in the estimator? I guess we could add wrappers in |
Yeah, might be a separate issue. But, I think it would be good to either automatically set defaults compatible with what LND/CLN is doing or to at least provide very clear guidance in the docs somewhere, because users keep running into these issues on testnet. |
|
Can you open an issue to track it (maybe with some color on how often we see this and in exactly which ways)? |
Done: #2925 |
Now that we're including excess counterparty commitment transaction fees in our dust calculation, we need to update the docs accordingly. We do so here, describing some of the considerations and risks that come with the new changes. We also take this opportunity to double the default value, as users have regularly complained that non-anchor channels fail to send HTLCs with the default settings with some feerates. Fixes lightningdevkit#2922
It seems the current dust limit (5k * current feerate) is low enough that with a 1sat/vB feerate we may not allow any dust HTLCs at all. Someone should run the math more carefully and we should pick a new default.
The text was updated successfully, but these errors were encountered: