Add config option to set maximum total routing fee

[tnull]

Fixes #2339.
Closes #2596.
Based on #2555.

Currently, users have no means to upper-bound the total fees accruing when finding a route. Here, we add a corresponding field to PaymentParameters which is used to limit the candidate set during path finding.

To this end, we exclude any candidate hops if we find that using them would let the aggregated path routing fees exceed max_total_routeing_fee_msat. Moreover, we return an error if the aggregated fees over all paths of the selected route would surpass max_total_routeing_fee_msat.

[tnull]

Drafting for now as I'm not super happy that we only filter on a per-path basis and then fail entirely if the aggregate route surpasses the routing fee limit. So far experimented with the approach we took for the minimal_value_contribution, i.e., having static per-path quotas, but discarded this as it would for example limit the per-path total fee to max_total_routing_fee_msat/max_path_count, i.e., to only 10% of the given value by default.

I think it's not super bad currently as we already pre-sort and filter routes by their cost/value ratio, which however also includes the penalty. Considering whether it would make sense to, whenever max_total_routing_fee_msat is set, add yet another pre-filtering step that only takes total fees into account to decrease the chances of unnecessarily returning an empty route.

This also currently doesn't account for retries. We might need to track the 'used' fees in a structure similar to InFlightHtlcs.

[codecov-commenter]

Codecov Report

Attention: 19 lines in your changes are missing coverage. Please review.

Comparison is base (7e7e7a0) 88.83% compared to head (77afeac) 89.68%.
Report is 35 commits behind head on main.

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2417      +/-   ##
==========================================
+ Coverage   88.83%   89.68%   +0.85%     
==========================================
  Files         113      113              
  Lines       84489    89980    +5491     
  Branches    84489    89980    +5491     
==========================================
+ Hits        75052    80696    +5644     
+ Misses       7205     7055     -150     
+ Partials     2232     2229       -3     

Files	Coverage Δ
lightning/src/ln/blinded_payment_tests.rs	100.00% <100.00%> (ø)
lightning/src/ln/functional_test_utils.rs	93.62% <ø> (+2.45%)	⬆️
lightning/src/ln/channelmanager.rs	87.68% <50.00%> (+6.55%)	⬆️
lightning-invoice/src/payment.rs	77.30% <33.33%> (-0.26%)	⬇️
lightning/src/ln/payment_tests.rs	98.06% <98.60%> (+0.01%)	⬆️
lightning/src/ln/outbound_payment.rs	90.03% <92.94%> (+1.23%)	⬆️
lightning/src/routing/router.rs	93.73% <93.22%> (+0.10%)	⬆️

... and 17 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[TheBlueMatt]

This is fine, I think. I agree we should clean it up later to more aggressively find paths even though our first choice was fee-limited out, but this is certainly better than not having fee limiting.

[valentinewallace]

Looks good to me as a first step, given where we're at with the release!

[alecchendev]

Nice

[valentinewallace]

LGTM after squash

[tnull]

LGTM after squash

Squashed fixups without further changes.

[tnull]

Rebased on main to get rid of the CI failure.

[TheBlueMatt]

We should land this to get the API in place for a second alpha, but we should get some of these comments fixed (at least the total-fee final check one) for 0.0.117.

[TheBlueMatt]

Not a regression, but this is wrong - this includes any overpayment amount, ensuring we overpay again when we go to retry, rather than just recalculating the amount sent against the intended amount. Lets definitely fix this ASAP.

[tnull]

(nevermind my previous reply): Tacked a corresponding commit onto #2575.

[tnull]

Actually, thinking about this once more, I think my previous comment was kinda correct: if we find a route and need to overpay for some of the paths, we may reduce the value of the others to meet the final value, i.e., the route's split is essentially determined at this time. If now some of the overpaid paths fail and we start to only retry the net. value (excluding overpaid amounts), the sum of all paths might not meet the expected final value. I suspect this is no issue if we have infinite auto-retries as we'd retry until the expected value is met, but if we're limited we probably will run out of retry attempts sooner than expected/necessary. Not sure how we'd want to resolve this?

[TheBlueMatt]

My point here is we don't need to think about paths in this specific case - we tried to send a payment for route.route_params.final_value_msat and we now have route.get_total_amount() - pending_amt_unsent pending. We should retry pending_amt_unsent - (route.get_total_amount() - route.route_params.final_value_msat).

[tnull]

My point here is we don't need to think about paths in this specific case - we tried to send a payment for route.route_params.final_value_msat and we now have route.get_total_amount() - pending_amt_unsent pending. We should retry pending_amt_unsent - (route.get_total_amount() - route.route_params.final_value_msat).

Right, then we seem to be on the same page that per-path accounting doesn't make sense, but only to account for the overpayment for the whole route.

I think what you propose unfortunately doesn't work as is though as for the immediate/legacy retry case we'd recursively reduce final_value_msat while we don't do this in the newer auto-retry case where we'd leave final_value_msat static, but account for for the pending amounts differently. In d7ab0ef I solved this by taking the min, but this seems to be pretty hacky.

[TheBlueMatt]

Hmm, this is nice but isn't what I was mostly interested about. I'm really curious to test overpaying the final recipient and ensuring the route_params' final_value_msat is correct, not just the remaining fees.

[tnull]

Ah, had understood above request slightly differently. IIUC, this might now more or less be covered by the new test introduced in #2604?

[TheBlueMatt]

That test tests the router end of it, but I'm really worried about the outbound_payment part overpaying.