How is the calculation of the amount of sats reserved to pay fees in L1 in case of having to launch a penalty transaction or make a forced closure of a channel? In bolt2 I have read that 1% of the channel capacity is recommended but it does not make much sense as this 1% could be below the current fee rate and therefore the transaction will not be confirmed.

Added to this, is there a difference between how LND and CLN treat this?

1 Answer 1


These are two separate things:

  • The funder is in charge of setting aside sufficient funds to get an eventual close to confirm. That either means they have to set the fee of commitment transactions high enough for it to confirm some time in the future, or a collaborative close at the time of creation. This also shows why unilateral closes are more expensive, as they need to account for the possibility of rising fees and they often need to confirm more rapidly (in case of a stuck HTLC).
  • Both sides of the channel are forced by the other side to keep 1% of funds in the channel on their side. This is in order to ensure cheating always costs something (at least 1% of the channel balance). The reserves cannot be used as fees generally speaking since that'd be a way to reduce the impact of an eventual punishment.

So, while both earmark some satoshis for a specific purpose, these purposes are very different.

  • As for differences between CLN and lnd, I'm sure there are when it comes to fee estimation, however the protocol will ensure both implementations agree on a feerate for closes and a reserve that they'll impose on the counterparty.
    – cdecker
    Mar 28 at 11:38
  • Thanks for the response! So there's no dynamic "fee reserve" for the commitment transactions? At the very beginning, both agree on what will be the feerate of the commitment transactions at all time? Mar 28 at 12:17
  • 1
    No, the Reserve value, i.e., the amount either side cannot dip into, is determined at funding of the channel, and will not change. It is however unrelated to the feerate for commitment txs, which gets negotiated over and over again to ensure a timely settling. They are two distinct things and do not interact.
    – cdecker
    Mar 29 at 17:59
  • 1
    It ises the estimatesmartfee method of bitcoin-cli, with 100 blocks as target in case you are using anchor channels (github.com/ElementsProject/lightning/blob/…)
    – cdecker
    Apr 1 at 12:29
  • 1
    CLN also polls the bitcoin backend at regular intervals to get up to date estimates, and then we smooth over a 5 minute interval, slowly moving from the previous to the current estimate. The smoothing is there so the counterparty does not get upset if there is a big jump in estimates, and the peer has not checked recently.
    – cdecker
    Apr 8 at 17:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.