Lightning: 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: https://github.com/ElementsProject/lightning/pull/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: https://github.com/ElementsProject/lightning/pull/3390#issuecomment-570584095

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.

[darosior]

I've a commmit which adds a new RPC command, setmutualclosefeerate to set the value we use to start negotiating fees when either we or our peer initiates a mutual close.

I've not made it a close parameter to handle the case where our peer initiates the close, but it makes the usage a bit awkward.
That's the reason of this comment : what do you think about this usage ? You could set this and also make a stubborn fee negotiation when you initiate the close, as per #3390, so this combines well.

[whitslack]

@darosior: It looks like this is a global configuration option. Shouldn't it be per channel, to give the same flexibility as specifying it as a close parameter would?

[darosior]

Good point, thank you for the quick feedback.

Fwiw, making it per-channel means it cannot be a plugin command anymore, and will add way more complexity.

[whitslack]

Maybe this setmutualclosefeerate could establish the default mutual close fee rate, and then close could grow a new parameter to allow overriding this default when we initiate a mutual close. Mutual closes initiated by the peer would always use the default mutual close fee rate.

[darosior]

Nice tradeoff, looks good to me.

[whitslack]

@rustyrussell: #3390 doesn't actually seem to address the feature being requested in this issue. You now have a way of affecting the negotiation step, but you still have no way of overriding the initial proposed fee.

[darosior]

Yep, not Rusty's fault though: #3390 was marked as closing this. Maybe @bitcoin-software can reopen, otherwise I think you can opena new issue to track the setting of the initial proposed fee.

[vasild]

Yeah, I wrote "Partially resolves #3270" in https://github.com/ElementsProject/lightning/pull/3390 and github interpreted it as "resolves #3270".

I think this issue should be reopened as there is a second part to it - in addition to the step to be able to manually specify the starting point (instead of getting it from bitcoind estimates).

[Moller40]

@darosior: This setmutualclosefeerate would be nice to have. Any plans to bring it in?