|
| 1 | +--- |
| 2 | +layout: pr |
| 3 | +date: 2023-06-06 |
| 4 | +title: "Avoid generating unpayable routes due to balance restrictions" |
| 5 | +pr: 2312 |
| 6 | +authors: [TheBlueMatti, naumenkogs] |
| 7 | +components: ["Channel", "routing", "fees"] |
| 8 | +host: dunxen |
| 9 | +status: upcoming |
| 10 | +commit: |
| 11 | +--- |
| 12 | + |
| 13 | +## Notes |
| 14 | + |
| 15 | +* Currently, when calculating the available balance we have for sending the next HTLC, there are cases where we overcount and end up |
| 16 | + generating routes which are not payable in reality, leading to payment failures. Originally, the [`outbound_capacity_msat`] for a channel was used |
| 17 | + 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 |
| 18 | + 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 |
| 19 | + 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. |
| 20 | +* [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 |
| 21 | + pending outbound HTLC value to provide an *upper bound* for the actual value we can send in the next HTLC. |
| 22 | + It also addressed the max-in-flight-HTLC limit that was contributing to the inaccuracy mentioned above. |
| 23 | + 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. |
| 24 | +* 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 |
| 25 | + lower bound for HTLC amounts as dust limits come into play and adding HTLC outputs inherently changes commitment transaction fees. Things can get weird. |
| 26 | + |
| 27 | +## Questions |
| 28 | + |
| 29 | +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)? |
| 30 | +1. What is the difference between "dust" outputs and "uneconomical" outputs and how do they affect Lightning payments? |
| 31 | + |
| 32 | +More questions to follow. |
| 33 | + |
| 34 | +[`outbound_capacity_msat`]: https://github.com/lightningdevkit/rust-lightning/blob/ede06d84de6467404fd1f94c77ad327b815ea302/lightning/src/ln/channelmanager.rs#L1370 |
| 35 | +[PR 1435]: https://github.com/lightningdevkit/rust-lightning/pull/1435 |
0 commit comments