Unable to initiate payment when remote balance is near its channel reserve

[roeierez]

Background

When the local balance almost reaches its highest value, sometimes LND prevents spending this balance and logs the following error:
Unable to handle downstream add HTLC: commitment transaction dips peer below chan reserve

Describe your issue here.
The issue is based on the following channel state:

{
            "active": true,
            "capacity": "1000000",
            "local_balance": "980000",
            "remote_balance": "11192",
            "commit_fee": "8808",
            "commit_weight": "724",
            "fee_per_kw": "12165",
            "unsettled_balance": "0",
            "total_satoshis_sent": "2830789",
            "total_satoshis_received": "3810790",
            "num_updates": "326",
            "pending_htlcs": [
            ],
            "csv_delay": 144,
            "private": true,
            "initiator": false,
            "chan_status_flags": "ChanStatusDefault",
            "local_chan_reserve": "600",
            "remote_chan_reserve": "10000"
        }

As seen above the remote_balance almost reaches its channel reserve value (10000 sat).
When the local node tries to pay, the code tries to add a new HTLC and enters the validateCommitmentSanity function where after this line: https://github.com/lightningnetwork/lnd/blob/master/lnwallet/channel.go#L3719 the value of theirBalance variable is less than the value of theirInitialBalance variable.
The reason is due to total fee value change which probably was caused by a larger weight of the new commitment transaction.
This causes the remote balance to dip bellow channel reserve and the code to return the error at the following line: https://github.com/lightningnetwork/lnd/blob/master/lnwallet/channel.go#L3756

At this stage the channel can't send any payment and the only way to get the funds is to close the channel.

Your environment

lnd 0.7.0-beta

Expected behavior

Initially I was thinking that the local node should be allowed to spend its balance but not sure how to do that with a pending htlc as this htlc by itself breaks the channel reserve constraint.

One suggestion:
Currently the code limits the balance growth on the initiator side up to the channel reserve + commitment fee.
If there is a way to predict/bound the commitment fee change ( or the growth of the commitment transaction weight) for the next transaction, it can be taken into account when calculating the limit on the initiator side for the current transaction.
This will ensure that the next transaction won't fail due to commitment fee change.

[wpaulino]

One possible solution would be to allow peers to dip below the reserve as long as there are incoming HTLCs that if settled would put them above the reserve. If the HTLCs are failed, then it would put the peer above the reserve again since the commit weight would be lowered.

[roeierez]

One possible solution would be to allow peers to dip below the reserve as long as there are incoming HTLCs that if settled would put them above the reserve. If the HTLCs are failed, then it would put the peer above the reserve again since the commit weight would be lowered.

One question, since the sanity check of the commitment transaction is done by both sides of the channel, will such change require to be stated in the bolt? I am saying that since I know validation failure in one side only will ends up with closed channel.

One other concern is that it could reach a state where the user can't send a small amount which is less than the fee change. for example:

1. remote side is 1 sat above reserve.
2. local side tries to pay 1 sat.
3. fail since the commit fee change is more than 2 sats. so even if the htlc is settled it still dips below the reserve.

[halseth]

This is a very good observation, and I think the solution is not really straight forward.

This is definitely something that should have a BOLT spec clarification, as nodes disagreeing on how to handle this could cause channel failure.

If we allow the node's commitment output to dip below its reserve when we have unsettled HTLCs we run into more edge cases, such that this output now might be below the dust limit, so I don't think that would solve it.

A workaround I think would work is to send many small payments below the channel dust limit. Such payments won't get an HTLC manifested on the commitment transaction, and hence the initiator's fee shouldn't increase.

[halseth]

1. remote side is 1 sat above reserve.
2. local side tries to pay 1 sat.
3. fail since the commit fee change is more than 2 sats. so even if the htlc is settled it still dips below the reserve.

Are you sayin you are able to reach this situation? AFAIK such a 1 sat payment won't lead to an increased commit fee.

[roeierez]

Are you sayin you are able to reach this situation? AFAIK such a 1 sat payment won't lead to an increased commit fee.

It was only a concern to the proposed solution. I didn't try to reach that and apparently I wasn't aware to the fact that 1 sat won't increase the fee. Thanks for the clarification.
The work around you suggested indeed works.

So can we say that the concern I raised seems to be only valid in the case the user tries to send an amount that is more than the dust limit but less than the commitment fee change right?

[halseth]

So can we say that the concern I raised seems to be only valid in the case the user tries to send an amount that is more than the dust limit but less than the commitment fee change right?

Sounds about right.

[Roasbeef]

Fixed by #8096