[Request] Command to manually update the commitment fee rate

[junderw]

Problem: During a fee event, users might want to increase the fees of the commitment just in case they need to close during the fees at the time.

Proposed Solution:

1. User sends a command to update the fee to a certain sat/byte or fee/kweight
2. Partner responds
3. If successful, commitment fees are increased.

• This will allow users to increase or decrease the fees on the commitment.

[C-Otto]

Some additional context:
During a bilateral, mutual close, where both peers agree and are able to communiate, the fee can be set in a closing_signed protocol message: https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#closing-negotiation-closing_signed

If, however, a channel should be closed without relying on the peer (force close, unilateral close), the fee is determined by the last update_fee message that has been acknowledged: https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#updating-fees-update_fee and https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#rationale-10

This issue asks for a manual command that can be used to set/increase the fee rate (by sending an update_fee message to the peer), so that this value can be used without relying on the peer (again).

UpdateFee in lnd: https://github.com/lightningnetwork/lnd/blob/master/lnwire/update_fee.go

An update_fee message is sent periodically based on a timer (updateFeeTimer):
https://github.com/lightningnetwork/lnd/blob/master/htlcswitch/link.go#L1087
https://github.com/lightningnetwork/lnd/blob/master/htlcswitch/link.go#L496

As such, even if the peer is responding and accepting new fees, the fee may be out of date (the network fee changed and the timer did not fire, yet). Furthermore, the fee is only updated if is off by at least 10% compared to the network fee. As such, a channel might have just 91% of the desired network fee, without any update being triggered.

[C-Otto]

Note that the fee may be adjusted (down) again in case the logic cited above is triggered again. As an example, if the (missing) command is used to set the fee to 1000 (whatever the unit may be), a few seconds later the updateFeeTimer may fire, compare 1000 to the network fee value of 500, determine that 1000 is way above 500, and adjust the fee back down to 500. This might not be in the best interest of the human who manually used the command to set the fee to 1000.

How should manual efforts interact with the timed updates? Is there a cooldown phase? Should the timer be disabled for a while? What about restarts (is this information persisted)?

[C-Otto]

Maybe it's a better idea to adjust the automated process so that no manual adjustments are necessary?

[Roasbeef]

So the current direction we're going in here (post anchor commitments) is just do clamp at say 20 sat/byte (never use a value above that), and then rely on CPFP'ing the anchor output to let users modify the fee. At first they can use BumpFee to do so, but eventually it'll be dynamic to try and sure that the commitment gets into the chain in time if it has any active HTLCs.

[Roasbeef]

Based on the above, I think we can close this since w/ anchors you can bump the fee rate after the fact, and also use the config to set a high water mark.