htlcswitch: avoid proposing fee updates exceeding max fee allowed #3401

wpaulino · 2019-08-14T02:54:55Z

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 --max-channel-fee-allocation CLI flag.

Fixes #3006.

Roasbeef · 2019-08-16T23:13:49Z

lnwallet/channel.go

+	switch {
+	// The new fee should not exceed our maximum fee allowed.
+	case newFee > maxFee:
+		return fmt.Errorf("cannot apply fee_update=%v sat/kw, new fee "+


I think we may actually just need to cooperative close at this point, as otherwise the channel won't be able to proceed as is, since we don't (but have some cut out design space for) have the ability to mark rejected updates explicitly. If we return an error here, we won't apply the fee, and the channel will be force closed by the receiving party.

What I had in mind with this PR was that we would refrain from triggering a new fee update if thee sampled fee update was above some threshold. This results in no force closures as we simply regulate our behavior on the end of the initiator. Within the protocol we're missing the ability for the responder to hav some say w.r.t what the final fee is, as they also want to ensure that they're able to close the channel in timely manner, and also this fee serves as the upper bound of what the fee can be for the cooperative closure transaction.

I think we may actually just need to cooperative close at this point, as otherwise the channel won't be able to proceed as is, since we don't (but have some cut out design space for) have the ability to mark rejected updates explicitly.

From a previous discussion offline, it seemed like we indeed want to do this but later down the road?

What I had in mind with this PR was that we would refrain from triggering a new fee update if thee sampled fee update was above some threshold. This results in no force closures as we simply regulate our behavior on the end of the initiator.

Wasn't aware of the force close issue. The fee update is now not proposed if it exceeds the max.

From a previous discussion offline, it seemed like we indeed want to do this but later down the road?

Yep, the goal of this is just to ensure we don't bleed away our entire channel. We can possibly add a flag in this PR to optionally close them out in order to avoid some fee stampede that results in a large number of channels being closed.

Roasbeef

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.

Roasbeef · 2019-08-20T01:21:26Z

lnwallet/channel.go

-func (lc *LightningChannel) CalcFee(feeRate SatPerKWeight) btcutil.Amount {
+// CalcFee returns the commitment fee to use for the given fee rate
+// (fee-per-kw).
+func CalcFee(feeRate SatPerKWeight) btcutil.Amount {


Can be an isolated commit.

Roasbeef · 2019-08-20T01:37:42Z

htlcswitch/link.go

+			// transaction.
+			commitFeeRate := l.channel.CommitFeeRate()
+			balance := l.channel.AvailableBalance().ToSatoshis() +
+				lnwallet.CalcFee(commitFeeRate)


I think most of this logic can be lifted in to shouldAdjustCommitFe (first step may be to make it a method).

I opted not to do so initially because of the additional test changes that it would require, though I can update the PR if desired.

joostjager

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 max_fee in the context of all required changes?

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?

joostjager · 2019-08-20T09:27:29Z

lnwallet/channel.go

-func (lc *LightningChannel) CalcFee(feeRate SatPerKWeight) btcutil.Amount {
+// CalcFee returns the commitment fee to use for the given fee rate
+// (fee-per-kw).
+func CalcFee(feeRate SatPerKWeight) btcutil.Amount {


Can be an isolated commit.

joostjager · 2019-08-20T09:47:07Z

htlcswitch/link.go

 	switch {
+	// The network fee should not exceed our maximum fee allowed.
+	case lnwallet.CalcFee(netFee) > maxFee:
+		return false


I can see that if the fee estimate goes up, we stop adjusting and pick it up again when the fees come down.

But suppose the commit fee does not exceed the max, but then our balance goes down. We should then update the fee to our lowered maxFee, but this clause leaves the fee unchanged.

maxFee depends on our balance and is recomputed before every shouldAdjustCommitFee call, so this should already be handled if our balance decreases?

I was thinking of this scenario:

netFee is constant at 1000

maxFeeAllocation is 50%

AvailableBalance() is 10000 sats

current commitFee is 1000

All is good, as we are below 50%.

Then we spend 9500 sats, AvailableBalance() is 500 sats

balance = AvailableBalance() + current_commit_fee = 1500 sats

maxFee = 1500 * 50% = 750 sats

I'd say the commit fee should now be updated to 750 sats, but in the code above you return early because 1000 > 750?

Ah, good point. The scope of the issue to me seemed just to avoid proposing the fee updates instead of limiting it to the max. Though I guess limiting it to the max would be beneficial as it puts us closer to the network fee if our current fee is way below it.

FWIW, in your example @joostjager, we wouldn't be able to have an available balance of 500 satoshis, as that's below our reserve.

With that aside, I think example stands, but it's out of the scope of the initial target here (just to limit how high we'll go).

Why is it out of scope? Isn't it better to keep sending updates, but cap them to the max?

Depends on what the scope is here, by scope I'm referring to the original posted issue. On the other hand, this can be seen as a new bug. I think it can be resolved by setting the fee to min(maxFee, commitFee) if I understand your example correctly. So then if this value matches the current fee, no change is triggered, otherwise we use that new value.

Yes, that is what I thought indeed, min(maxFee, commitFee).

Roasbeef · 2019-08-23T23:43:34Z

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?

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.

If the link is offline, the fees also need to be watched.

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.

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 max_fee in the context of all required changes?

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.

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?

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).

Roasbeef

Running this on a few of my nodes now.

Roasbeef · 2019-08-23T23:23:58Z

htlcswitch/link.go

 	switch {
+	// The network fee should not exceed our maximum fee allowed.
+	case lnwallet.CalcFee(netFee) > maxFee:
+		return false


With that aside, I think example stands, but it's out of the scope of the initial target here (just to limit how high we'll go).

joostjager · 2019-09-02T14:44:59Z

config.go

+	// Ensure a valid max channel fee allocation was set.
+	if cfg.MaxChannelFeeAllocation <= 0 || cfg.MaxChannelFeeAllocation > 1 {
+		return nil, fmt.Errorf("invalid max channel fee allocation: "+
+			"%v, must be within [0.1, 1]",


Range in error doesn't match range in if condition. Also, because range is used three times (twice here and once in config), extract to constants?

Fixed the range. Don't think we can use the constants in the description of the flag though?

Oh yes, that is a tag. I don't think so indeed. But the range in the tag is still [0.1, 1] instead of [0, 1]. Also the tag mentions percentage which suggests it is in the 0-100 range?

lnwallet/channel.go

htlcswitch/link_test.go

htlcswitch/link.go

htlcswitch/link_test.go

…closure

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.

Roasbeef

LGTM 🐎

wpaulino requested review from cfromknecht, halseth and Roasbeef as code owners August 14, 2019 02:54

wpaulino removed the request for review from halseth August 14, 2019 02:55

wpaulino added channels commitments Commitment transactions containing the state of the channel fees Related to the fees paid for transactions (both LN and funding/commitment transactions) v0.8.0 enhancement Improvements to existing features / behaviour labels Aug 14, 2019

wpaulino added this to the 0.8.0 milestone Aug 14, 2019

Roasbeef requested changes Aug 16, 2019

View reviewed changes

wpaulino force-pushed the channel-initiator-max-fee branch from 40ee38e to f9c5049 Compare August 19, 2019 23:21

wpaulino changed the title ~~htlcswitch+lnwallet: enforce max channel commitment fee for initiators~~ htlcswitch: avoid proposing fee updates exceeding max fee allowed Aug 19, 2019

wpaulino force-pushed the channel-initiator-max-fee branch from f9c5049 to 2c83c14 Compare August 20, 2019 00:17

wpaulino requested a review from Roasbeef August 20, 2019 00:17

Roasbeef reviewed Aug 20, 2019

View reviewed changes

Roasbeef requested review from joostjager and removed request for cfromknecht August 20, 2019 01:44

joostjager suggested changes Aug 20, 2019

View reviewed changes

wpaulino requested review from Roasbeef and joostjager August 23, 2019 19:08

Roasbeef reviewed Aug 23, 2019

View reviewed changes

wpaulino force-pushed the channel-initiator-max-fee branch 2 times, most recently from b02689f to b8e0709 Compare August 30, 2019 19:17

joostjager reviewed Sep 2, 2019

View reviewed changes

wpaulino added 3 commits September 3, 2019 16:49

lnwallet: add MaxFeeRate method to LightningChannel

59d19e0

htlcswitch: refactor TestChannelLinkUpdateCommitFee common code into …

047d5b1

…closure

wpaulino force-pushed the channel-initiator-max-fee branch from b8e0709 to d8dd6b3 Compare September 3, 2019 23:50

wpaulino requested review from Roasbeef and joostjager September 4, 2019 00:39

joostjager approved these changes Sep 4, 2019

View reviewed changes

Roasbeef approved these changes Sep 5, 2019

View reviewed changes

Roasbeef merged commit 866867a into lightningnetwork:master Sep 5, 2019

wpaulino deleted the channel-initiator-max-fee branch September 24, 2019 02:23

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

htlcswitch: avoid proposing fee updates exceeding max fee allowed #3401

htlcswitch: avoid proposing fee updates exceeding max fee allowed #3401

wpaulino commented Aug 14, 2019

Roasbeef Aug 16, 2019

wpaulino Aug 19, 2019

Roasbeef Aug 20, 2019

Roasbeef left a comment

Roasbeef Aug 20, 2019

joostjager Aug 20, 2019

Roasbeef Aug 20, 2019

wpaulino Aug 21, 2019

joostjager left a comment

joostjager Aug 20, 2019

joostjager Aug 20, 2019

wpaulino Aug 21, 2019

joostjager Aug 21, 2019

wpaulino Aug 22, 2019

Roasbeef Aug 23, 2019

Roasbeef Aug 23, 2019

joostjager Aug 26, 2019

Roasbeef Aug 28, 2019

joostjager Sep 2, 2019

Roasbeef commented Aug 23, 2019

Roasbeef left a comment

Roasbeef Aug 23, 2019

joostjager Sep 2, 2019

wpaulino Sep 3, 2019

joostjager Sep 4, 2019

Roasbeef left a comment

htlcswitch: avoid proposing fee updates exceeding max fee allowed #3401

htlcswitch: avoid proposing fee updates exceeding max fee allowed #3401

Conversation

wpaulino commented Aug 14, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Roasbeef left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

joostjager left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Roasbeef commented Aug 23, 2019

Roasbeef left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Roasbeef left a comment

Choose a reason for hiding this comment