Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump dust exposure threshold so we can send HTLCs #2261

Closed
TheBlueMatt opened this issue May 4, 2023 · 5 comments · Fixed by #2354
Closed

Bump dust exposure threshold so we can send HTLCs #2261

TheBlueMatt opened this issue May 4, 2023 · 5 comments · Fixed by #2354
Milestone

Comments

@TheBlueMatt
Copy link
Collaborator

TheBlueMatt commented May 4, 2023

Currently our default max dust exposure threshold is quite low (5k sats). For a single payment between that number and the dust threshold we'll refuse to send any HTLCs at all. With today's fee market this causes all payments or HTLC forwards between 5k sats and the dust threshold (often up to 10k-15k sats today) to fail entirely.

This doesn't apply to anchor channels.

@TheBlueMatt TheBlueMatt added this to the 0.0.116 milestone May 4, 2023
@TheBlueMatt TheBlueMatt self-assigned this May 4, 2023
@ariard
Copy link

ariard commented May 6, 2023

Currently our default max dust exposure threshold is quite low (5k sats). For a single payment between that number and the dust threshold we'll refuse to send any HTLCs at all.

Yeah this only apply to legacy channels due to the feerate being encompassed for second-stage transaction, and the HTLC being trimmed if it’s not economically rational. Note, I think we still have a throughput limit on anchor channels for concurrent low-value payments. We might go to discard dust HTLC output from max_accepted_htlc, or another way could be to advocate for a special policy regime in Core and have under-dust outputs allowed under the condition they are immediately spend by a CPFP in the same block (an extension of the ephemeral anchor idea).

@TheBlueMatt
Copy link
Collaborator Author

In discussion with some LDK users it seems like maybe we should limit this as a global dust HTLC limit (which would kill parallelism so kinda annoying), or just a dust HTLC count limit, which lets it scale nicely with channel feerates. Annoying part with that is that if the channel is inbound it would let a counterparty select the dust limit high and then send a single huge dust HTLC and screw us, so maybe we need to split the handling based on anchors.

@ariard
Copy link

ariard commented May 16, 2023

so maybe we need to split the handling based on anchors.

With today level of feerates and given our dust exposure is function of update_fee, I think it’s better if we split the handling based on anchors. For the global dust HTLC limit, we can introduce a new all_channels_max_dust_htlc_exposure_msat, there is some trade-off between your forward HTLC throughput, your dust exposure and your liquidity efficiency though dunno yet the math relations.

@TheBlueMatt
Copy link
Collaborator Author

Not sure why I had assigned this to myself, happy for someone else to work on it.

@alecchendev
Copy link
Contributor

I can open this PR - what's a good number to bump to? Maybe 25k sats?

@TheBlueMatt TheBlueMatt linked a pull request Jul 2, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants