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

funding+commitments: zero channel reserve safety #959

Open
Roasbeef opened this issue Feb 14, 2022 · 2 comments
Open

funding+commitments: zero channel reserve safety #959

Roasbeef opened this issue Feb 14, 2022 · 2 comments

Comments

@Roasbeef
Copy link
Collaborator

Was discussed in the spec meeting: is it ok to propose and accept a zero reserve channel? Some implementations already do this in the wild today, and it appears there's an interaction here with the dust limit and the current fee rate.

Initial conclusion was that this might only be safe with the latest version of anchor outputs. Before anchor outputs, you had a risk where you'd end up with a commitment transaction with zero outputs as everything has been trimmed. With the latest version of anchors, you only need to pre-commit the fee to include the first-level HTLC output in the commitment transaction. As a result, you can compute the smallest channel type, that'll still have a non-dust output, if the channel has been fully loaded (maxed out HTLCs in both directions).

Implementation wise, this may make sense as a new channel type feature bit, as it allows users to more directly ensure that this is the channel type they're expecting.

@t-bast
Copy link
Collaborator

t-bast commented Feb 15, 2022

If I'm not mistaken, assuming we use option_anchors_zero_fee_htlc_tx, if there is a single htlc above dust (not trimmed, really just above dust) there will be an output. So the only case where we can end up with no outputs in the commit tx is if:

  • there are no htlcs or they are all below dust
  • there is no output for the fundee
  • the funder's main output is trimmed to dust

The worst case to run into this would be to have 2 * 483 HTLCs just below dust.
If we use a dust_limit of 546 sat, that means a total value of 527 436 sat.
If our worst-case feerate is 100 sat/byte, since the commit weight is 1124 WU, the fee would be 28 100 sat.
So as long as your channel is bigger than 555 536 sat, you shouldn't run into this situation.

The parameters that influence this value are:

  • max_accepted_htlc
  • max_dust_htlc_exposure_msat
  • dust_limit
  • your expected worst-case commit tx feerate

@Crypt-iQ
Copy link
Contributor

I read the above and the calculations make sense to me. I'll just note that during channel negotiation, you should check both commitments due to the dust limits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants