htlcswitch: avoid proposing fee updates exceeding max fee allowed #3401
In this PR, we begin to enforce a maximum channel commitment fee for channel initiators when attempting to update their commitment fee. Now, if the new commitment fee happens to exceed their maximum, then the fee update won't be proposed and the channel will remain with its previous commitment fee. Note that this won't cause the channel to be closed, but will likely be done at a later time.
A default of up to 50% of the channel initiator's balance is enforced for the maximum channel commitment fee. It can be modified through the
The text was updated successfully, but these errors were encountered:
With the current design of the system, yes the link would likely still be responsible for this. However with the new format, a new upper limit in the coop close fee would need to be agreed upon (atm the commitment fee is the upper limit). As far as deployment, I think we'll end up going with a multi-stage approach, where the first deployment only adds the anchor outputs, but leaves the current update_fee semantics in place.
That would depend on how proactive we want to be. We may not want to close due to rising fees, but perhaps due to lack of uptime by the peer instead. When we do choose to close, we'll still eventually have the opportunity to add more/less fees if we want. It's also the case that since this is the latest state, if no HTLCs are present, then we may want to be more lax about our confirmation expectations. Once our transaction engine is complete, it can also use that pending close output as an input for other transactions such as a channel funding or regular on-chain transaction. We'll then essentially be doing a "demand based" adhoc CPFP whenever we need those funds as inputs.
It's only meant to address complaints by users that their 50k satoshis channel has 40k allocated to fees. Moving to the new format in a safe manner will also require us to wait for new bitcoin full node software to be released, and a majority of miners upgrading to this new software.
You mentioned offline that by clamping the fee here we may exacerbate waiting issues in times of high fees, however what we should be doing in those times in for safety reasons is dynamically modifying our CLTV delta across our channels. We can regulate this value to give us more/less time to get commitments w/ HTLCs in the chain depending on the current fee climate.
We're worried mostly about mass closure events across the network if we have this be the default in the next release. Even then, if the logic is very twitchy, then responders to a channel funding may end up preemptively closing their channels due to a short lived burst in estimate fees (for example Bitmex doing their daily withdraws). We deploy any automated closing logic with caution, as we've seen in the earlier days that it can cause users unwarranted agony (for example back when CL would force close channels due to a fee disagreement).
In this commit, we begin to enforce a maximum channel commitment fee for channel initiators when attempting to update their commitment fee. Now, if the new commitment fee happens to exceed their maximum, then a fee update of the maximum fee allocation will be proposed instead if needed. A default of up to 50% of the channel initiator's balance is enforced for the maximum channel commitment fee. It can be modified through the `--max-channel-fee-allocation` CLI flag.