Need ability to set a fee rate in event of a unilateral close.

[sat-hoarder]

In the event a unilateral close is necessary, an ability to set a fee rate is needed. CLN picking a fee rate of 1 sat/vB is ridiculously low and unnecessarily ties up funds for long periods of time during congestion.

[whitslack]

That ability already exists. See the commit-fee config variable. man lightningd-config.

[sat-hoarder]

OK, I'll rephrase. The ability needs to exist to override the general lightningd-config commit fee setting while executing lightning-cli close so as to not unnecessarily rely on estimates that are rarely correct or reflect changing conditions thereby tying up funds for extremely long periods of time.

[whitslack]

I believe the plan is to allow various config variables to be changed at runtime via the RPC interface. There are many config variables that would benefit from this. Restarting the daemon just to tweak a knob is unacceptably disruptive and can sacrifice forwarding revenue for an hour or more.

[ekimber]

While it is difficult to estimate the optimal fee, a fee rate of 1 sat/vB with the current mempool just seems like it must be a bug

[whitslack]

Realize that you can only change the feerate of your commitment transaction while you're connected to your peer, as both peers must sign any new commitment. Given that you're wanting to unilaterally close, it sounds like your peer is offline. You can't make a new commitment transaction with a higher fee rate while your peer is offline.

[ekimber]

That's true but I believe the last commitment transaction was made in the current fee environment also

[whitslack]

@ekimber: OP was asking for a way to override the commit-fee setting at the time of initiating a unilateral close. I'm pointing out that by that time it's too late.

[ekimber]

Yes, you are correct, however, I have a stuck transaction with a low feerate also and I am surprised by it because it seems it shouldn't be that low. So I wonder if perhaps it is the same underlying issue. After all, the OP would not want to override it if it wasn't low

I don't understand how "estimatesmartfee 2/CONSERVATIVE" could have been 1 sat/vB for weeks now

[whitslack]

I don't understand how "estimatesmartfee 2/CONSERVATIVE" could have been 1 sat/vB for weeks now

It appears actually to be estimatesmartfee 6 that is used as the basis for the commitment transaction fee rate. The man page is apparently incorrect. But regardless, realize that whatever that fee rate is, it gets multiplied by commit-fee as a percentage. The default commit-fee is 100 (percent), but it can be set lower.

[ekimber]

It could be, although I certainly have not set it lower

[sat-hoarder]

That's correct, it's too late for me now. My close is languishing in depths of the purged mempool transactions. I'll just have to try and rebroadcast someday. My lesson has been learned.