Pending HTLCs are not considered in balance calculations

[rkfg]

It seems that the proportional strategy can be gamed with pending HTLCs. Sometimes they hang for a long time and your local or remote balance is therefore decreased. If update happens during this time the resulting proportional fee would be incorrect because it's not guaranteed for the HTLC to be settled. For example, the attacker can drain from your currently expensive channel by putting an incoming HTLC there. The remote balance decreases because of that and the local/remote ratio becomes higher. Then the attacker waits for your fee to update (it goes down because the channel seems "full" due to the remote balance being low), sends a payment in the opposite direction (so that it goes out of this channel using the reduced fee) and fails the first pending HTLC.

I see that in some situations this behavior might be desirable, if the node is busy with many pending HTLCs you'd rather consider your currently available balances than full (available + pending). But if the activity isn't that high, big pending HTLCs might randomly drop the fees if the update happens at the wrong moment, and you might be left with an empty channel and no collected fees.

[feelancer21]

It is not only a problem with proportional fees. It has also side effects e.g. if you disable the channel depending on the local balance. Then you can run in a situation where updates are made forth and back.

I think pending htlcs should be included with the assumption that they will fail.

[silenzara]

I agree with both commenters above, using the settled balance is the option that benefits the operator (and the network at large) the most.

For example: As a LOOP peer I have experienced many issues related to unsettled balance as a way to calculate the ratio. When looping out, a whole bunch of routes are tried (via MPP and being held by using a "hold" invoice) to find the cheapest option. This process can take up to an hour to complete. If during this process the fee gets updated (or even worse, max_htlc and/or channel disabled entirely) then the entire LOOP out can fail. Not because there are no suitable routes but because of pre-emptively setting policies. This not only happens to my peer but to all peers in the entire chain of hops that lead to my node (if they happen to run charge-lnd and use ratios). Often this happens to channel that I am a strong source to and my peers would love to have inbound from my side.

In the above case, even with the assumption that the htlc will eventually settle you still probably do not want to act on the change in unsettled balance yet. You could argue that the operator should not use proportional/ratio based fees in this case but it is possible they would not even know they missed out the htlc's because the policy change prevented it from happening and they do not adapt their strategy accordingly.

As you can see, using unsettled balance with long lasting htlc's that use multi path payments over multiple hops this can have pretty large consequences and can lead to inefficiencies that ripple through the entire network. I also think this can potentially be abused even more than jamming attacks because with jamming you need the htlc to be pending all (or most of) the time to block a channel. If you know someone is using unsettled ratio based policies and you know at what time the policies get updated then you only need to hold the htlc during that update window and can release it when the policy is updated (in the abusers favour).

There are however a few use-cases for the unsettled balance though. Ironically they mostly have to do with peers that use the unsettled balance and have a "proportional" type fee system. In those cases you might want use the same calculations as your peer.

[feelancer21]

Hey, guys. I added some stuff in a personal branch. Considering pending htlcs is part of it. But I need more time to the stuff until I start a PR here.

Feel free if you like to test:
feelancer21#1

[rkfg]

@feelancer21 what parameters exactly would solve the problem I described? It's not very clear from the improvements.

[feelancer21]

@rkfg there is no parameter. I have changed the general behavior of the balance calculation. The amounts of the pending htlcs are always added to the page that initiated the htlc. We are therefore working with the assumption that the htlc will fail.
The balance is then used consistently, both for proportional fees and for balance-dependent policies.

2499f74