<p>These are two separate things:</p>
<ul>
<li>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).</li>
<li>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.</li>
</ul>
<p>So, while both earmark some satoshis for a specific purpose, these purposes are very different.</p>

CC BY-SA 4.0
2024-03-28T11:38:35.460Z
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
CC BY-SA 4.0
2024-03-28T12:17:26.283Z
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?
polespinasa
CC BY-SA 4.0
2024-03-29T17:59:17.313Z
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
CC BY-SA 4.0
2024-03-31T14:49:50.480Z
How does CLN calculate the commitment tx feerate? Does it use _estimatesmartfee_ or _estimaterawfee_ from core cli? If so, which confirmation target do they ask for? It uses the return value or they even increment it a bit?
polespinasa
CC BY-SA 4.0
2024-04-01T12:29:41.400Z
It ises the `estimatesmartfee` method of `bitcoin-cli`, with 100 blocks as target in case you are using anchor channels (https://github.com/ElementsProject/lightning/blob/9a4be1a4ac0b2269e355a18619e9a776d13a9c2c/lightningd/chaintopology.c#L614-L633)
cdecker
CC BY-SA 4.0
2024-04-08T08:03:28.217Z
I was told that LND uses a timer that is trigger at random intervals in a range in order to re-calculate and negotiate the feerate for the commitment tx. Does CLN work in a similar way? Do you have this documented so I can dip into it?
polespinasa
CC BY-SA 4.0
2024-04-08T17:21:06.880Z
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
CC BY-SA 4.0
2024-03-28T11:37:01.297Z
2024-03-28T11:37:01.297Z
cdecker
<p>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 <a href="https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#rationale-8" rel="nofollow noreferrer">bolt2</a> 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.</p>
<p>Added to this, is there a difference between how LND and CLN treat this?</p>

<lightning-network><lightning-network-daemon><core-lightning><fee-estimation><channels>
Lightning Network channel reserve
polespinasa
# Lightning Network channel reserve

(Asked by: username_0 on 2024-03-28)

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](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md#rationale-8) 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?

**Tags:** lightning-network, lightning-network-daemon, core-lightning, fee-estimation, channels


---

## 1 answers

### Answer by username_1 on 2024-03-28. Score: 1 | Accepted answer

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.

> **Comments:**
> **username_1**: 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.  
> **username_0**: 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?  
> **username_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.  
> **username_0**: How does CLN calculate the commitment tx feerate? Does it use _estimatesmartfee_ or _estimaterawfee_ from core cli? If so, which confirmation target do they ask for? It uses the return value or they even increment it a bit?  
> **username_1**: It ises the `estimatesmartfee` method of `bitcoin-cli`, with 100 blocks as target in case you are using anchor channels (https://github.com/ElementsProject/lightning/blob/9a4be1a4ac0b2269e355a18619e9a776d13a9c2c/lightningd/chaintopology.c#L614-L633)  
> **username_0**: I was told that LND uses a timer that is trigger at random intervals in a range in order to re-calculate and negotiate the feerate for the commitment tx. Does CLN work in a similar way? Do you have this documented so I can dip into it?  
> **username_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.  

---

