Merge pull request #15 from dunxen/switch-2302-for-2312

Swap 2302 for 2312

Author: dunxen

_posts/2023-06-06-#2302.md

@@ -0,0 +1,35 @@
+---
+layout: pr
+date: 2023-06-06
+title: "Avoid generating unpayable routes due to balance restrictions"
+pr: 2312
+authors: [TheBlueMatti, naumenkogs]
+components: ["Channel", "routing", "fees"]
+host: dunxen
+status: upcoming
+commit:
+---
+
+## 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](https://github.com/lightningdevkit/rust-lightning/blob/master/CONTRIBUTING.md#peer-review)?
+1. What is the difference between "dust" outputs and "uneconomical" outputs and how do they affect Lightning payments?
+
+More questions to follow.
+
+[`outbound_capacity_msat`]: https://github.com/lightningdevkit/rust-lightning/blob/ede06d84de6467404fd1f94c77ad327b815ea302/lightning/src/ln/channelmanager.rs#L1370
+[PR 1435]: https://github.com/lightningdevkit/rust-lightning/pull/1435