<p>Just use <code>lightning-cli close id</code> the implementation will first try to do a mutual close. Both lightning nodes will use the fee estimator from Bitcoind to suggest fees. If they don't agree there is a communication protocol defined in the BOLTs that they will eventually find a local agreement between themselves. This protocol is described under the section <code>closing negotiation</code> in BOLT 02 c.f.: <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#closing-negotiation-closing_signed" rel="nofollow noreferrer">https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#closing-negotiation-closing_signed</a></p>

<p>Obviously both nodes need to be online and peered before you call the close command otherwise the node will do an expensive force close. Also it makes sense to wait until fees in the mempool are low if you can do that. </p>

CC BY-SA 4.0
2019-11-18T13:52:34.803Z
Hi, Rene! Thank you for fast answer! But this is not the option i am looking for. I want to avoid the use of bitcoind fee estimator and force let's say 1sat/b fee. As mentioned dev told me there is no way to do so with default calls (to be precise he said "this is not implemented in default setup"). I am looking for that custom configuration of node so i can force specific fee as i can do when `lightning-cli fundchannel id amount fee`
baysx
CC BY-SA 4.0
2019-11-18T13:55:05.467Z
the point of doing so is exactly what you described, but in reverse order. I dont want to wait until mempool clears to perform tx. i just want to broadcast it and lay back, so it will be included, when mempool clears. so i dont need to monitor state of mempool
baysx
CC BY-SA 4.0
2019-11-18T14:42:44.453Z
just some additional info: when you open a channel, your node is the only side involved in opening tx, so you can choose the fee yourself. When closing channel, there's multisig tx, that is the reason why you cannot set custom fee (because other part may not agree on low fee). But in case both nodes are co-operative, this should be possible.
baysx
CC BY-SA 4.0
2019-11-18T14:43:21.010Z
Then I guess you should open a feature request in the clightning github and potentially also on the lightning-rfc. It should be possible to just agree on a low fee but I guess it also needs an amendment to the fee negotiation. Technically the fee is paid by the funder but unfortunately that won't help
Rene Pickhardt
CC BY-SA 4.0
2019-11-18T17:08:59.117Z
https://github.com/ElementsProject/lightning/issues/3270

https://github.com/lightningnetwork/lightning-rfc/issues/702
baysx
CC BY-SA 4.0
2019-11-18T13:48:24.017Z
2019-11-18T13:48:24.017Z
Rene Pickhardt
<p>When i was at LNConf, one of the devs of c-lightning (IIRC) told me that there is a custom, manual way to agree between two nodes on channel closing fees.</p>

<p>Can anyone elaborate how this is possible? I am operator of two cln nodes, i would like to close channel between these nodes with minimum possible fee, because i am not in hurry. </p>

<p>Are there some side-effects of doing so?</p>

<lightning-network><core-lightning>
"private" agreement between two c-lightning nodes on channel closure fee
baysx
# "private" agreement between two c-lightning nodes on channel closure fee

(Asked by: username_0 on 2019-11-18)

When i was at LNConf, one of the devs of c-lightning (IIRC) told me that there is a custom, manual way to agree between two nodes on channel closing fees.

Can anyone elaborate how this is possible? I am operator of two cln nodes, i would like to close channel between these nodes with minimum possible fee, because i am not in hurry.

Are there some side-effects of doing so?

**Tags:** lightning-network, core-lightning


---

## 1 answers

### Answer by username_1 on 2019-11-18. Score: 1

Just use `lightning-cli close id` the implementation will first try to do a mutual close. Both lightning nodes will use the fee estimator from Bitcoind to suggest fees. If they don't agree there is a communication protocol defined in the BOLTs that they will eventually find a local agreement between themselves. This protocol is described under the section `closing negotiation` in BOLT 02 c.f.: <https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#closing-negotiation-closing_signed>

Obviously both nodes need to be online and peered before you call the close command otherwise the node will do an expensive force close. Also it makes sense to wait until fees in the mempool are low if you can do that.

> **Comments:**
> **username_0**: Hi, username_1! Thank you for fast answer! But this is not the option i am looking for. I want to avoid the use of bitcoind fee estimator and force let's say 1sat/b fee. As mentioned dev told me there is no way to do so with default calls (to be precise he said "this is not implemented in default setup"). I am looking for that custom configuration of node so i can force specific fee as i can do when `lightning-cli fundchannel id amount fee`  
> **username_0**: the point of doing so is exactly what you described, but in reverse order. I dont want to wait until mempool clears to perform tx. i just want to broadcast it and lay back, so it will be included, when mempool clears. so i dont need to monitor state of mempool  
> **username_0**: just some additional info: when you open a channel, your node is the only side involved in opening tx, so you can choose the fee yourself. When closing channel, there's multisig tx, that is the reason why you cannot set custom fee (because other part may not agree on low fee). But in case both nodes are co-operative, this should be possible.  
> **username_1**: Then I guess you should open a feature request in the clightning github and potentially also on the lightning-rfc. It should be possible to just agree on a low fee but I guess it also needs an amendment to the fee negotiation. Technically the fee is paid by the funder but unfortunately that won't help  
> **username_0**: https://github.com/ElementsProject/lightning/issues/3270  https://github.com/lightningnetwork/lightning-rfc/issues/702  

---

