Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
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
No blocking comments at this point. Only now curious to see if this direction is in line with expectations from additional reviewers. With this PR, we'll stop bleeding all our fees into channels, but ofc there's still a danger zone there which something like moving to the proposed anchor outputs will address.
joostjager left a comment
With the new commitment format (always only minimal tx fee), will the link remain responsible for deciding when to coop close the channel because of fees? If the link is offline, the fees also need to be watched.
As I understand it from the issue description, this pr is a preparation for the new commitment format. But isn't it better to hold off until that format actually lands and think about
The current pr scope doesn't include the non-initiator closing the channel if fees are not sufficient anymore. Aren't you worried that this pr will cause more unconfirmed commitment txes and users not knowing what to do about it? Or unexpected closing fees because the non-initiator needs to cpfp their outputs now?
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.