Setting manual channel closure fee (question)

[bitcoin-software]

Reffering to this question: https://bitcoin.stackexchange.com/questions/91755/private-agreement-between-two-c-lightning-nodes-on-channel-closure-fee

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?

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

Would like to hear your thoughts.

[rustyrussell]

When nodes mutual close, they negotiate iteratively until they agree. By default we split the difference between what we want and what they want. The feerates perkb gives you an indication of what fees we'll aim for in each case.

There's currently no way to force a lowball fee, though it would be easy to add one to the close command. It's a negotiation though, so the other side needs to agree or we can't close.

[whitslack]

It's a negotiation though, so the other side needs to agree or we can't close.

@rustyrussell: Can the negotiation safely be abandoned (leaving the channel open) if the peer wants too high a fee? I can see a use case like "mutually close this channel if it can be done for less than 500 sats; otherwise, leave it open."

[ZmnSCPxj]

It may require a spec change, as once the closing negotiation is initiated, we refuse to forward over that channel. We would have to include something in the closing negotiation that says "never mind, cancel the closing negotiation" which would be sendable only by the peer that initiated the closing negotiation. Code-wise we need infrastructure to transfer from closingd back to channeld.

It still does not quite do what you want, which is basically to ensure that a particular feerate is used.

[ZmnSCPxj]

There's currently no way to force a lowball fee, though it would be easy to add one to the close command. It's a negotiation though, so the other side needs to agree or we can't close.

More specifically

The spec requires that we move the fee we propose by at least 1 unit at each round of the negotiation.

What we currently do now is that we start with our fee then when the other node counter-proposes we average our last proposal and the other node last proposal, until roundoff makes us send the same feerate as the other node.

What we could do would be to add a flag somewhere in the closingd_init which, if set, makes us instead propose to move by exactly 1 unit towards the other node instead of averaging. This still does not quite get you to what we want (i.e. use a very very specific feerate) but you can get close.

If the other side decides to use the same behavior if it notices you using that behavior, though.....

[vasild]

Indeed insisting on a particular fee and cancelling the close if the other side disagrees with our insisted-on-fee would require a spec change.

Within the current spec we can, as @ZmnSCPxj suggested above, negotiate one satoshi at a time instead of bisecting. I created a draft PR to do that at: #3390. Maybe it also makes sense to provide a way to manually specify the negotiation starting fee. Some comments and questions about the details on the PR page: #3390 (comment)

If the other side decides to use the same behavior (two stubborn parties negotiating!) then the process will still complete after many iterations. I think that is reasonable.