Avoid generating unpayable routes due to balance restrictions (Channel, routing, fees)

https://github.com/lightningdevkit/rust-lightning/pull/2312

Host: dunxen  -  PR authors: TheBlueMatti , naumenkogs

Notes

  • Currently, when calculating the available balance we have for sending the next HTLC, there are cases where we overcount and end up generating routes which are not payable in reality, leading to payment failures. Originally, the outbound_capacity_msat for a channel was used when considering the maximum amount we can send in a single additional HTLC. However, due to factors such as HTLC in-flight limits, a channel’s HTLC maximum value, or our feerate buffer, this balance could mismatch the amount we could actually send in an HTLC. It also doesn’t take into acount any pending inbound or outbound HTLCs which have not fully resolved yet. The value has always been documented as “not exact” and not likely to be spendable.
  • PR 1435 split out an next_outbound_htlc_limit_msat from outbound_capacity_msat for more correctly handling next HTLC value limits. It takes into account pending outbound HTLC value to provide an upper bound for the actual value we can send in the next HTLC. It also addressed the max-in-flight-HTLC limit that was contributing to the inaccuracy mentioned above. However, it should be noted that since next_outbound_htlc_limit_msat is an upper bound, we could still generate routes that are unpayable if they’re too small.
  • PR 2312 addresses the lower limit for the next HTLC by introducing a next_outbound_htlc_minimum_msat for a channel. Things become a little more complex at the lower bound for HTLC amounts as dust limits come into play and adding HTLC outputs inherently changes commitment transaction fees. Things can get weird.

Questions

  1. Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK?
  2. What is the difference between “dust” outputs and “uneconomical” outputs and how do they affect Lightning payments?

More questions to follow.