t-bast
commented
2 years ago 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_htlcmax_dust_htlc_exposure_msatdust_limit- your expected worst-case commit tx feerate
Crypt-iQ
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.