Askrene: fix constraints #8358
Draft
Askrene: fix constraints #8358
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Lagrang3
force-pushed
the
askrene-fix-constraints
branch
from
425e9cb to
a471749
Compare
Lagrang3
force-pushed
the
askrene-fix-constraints
branch
from
57b4471 to
be9cde6
Compare
Lagrang3
force-pushed
the
askrene-fix-constraints
branch
2 times, most recently
from
ab22991 to
1d475e5
Compare
Refactor MCF solver: remove structs linear_network and residual_network. Prefer passing raw data to the helper functions. Changelog-None Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
The single path solver uses the same probability cost and fee cost estimation of minflow. Single path routes computed this way are suboptimal with respect to the MCF solution but still are optimal among any other single path. Computationally is way faster than MCF, therefore for some trivial payments it should be prefered. Changelog-None. Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Changelog-Added: askrene: an optimal single-path solver has been added, it can be called using the developer option --dev_algorithm=single-path or by adding the layer "auto.no_mpp_support" Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Changelog-None Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Changelog-None Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
From the multiple arcs that derive from the same channel we consider
only those with the smallest cost such that the payment amount and HTLC
max can fit in their combined capacity, ie. we prune high cost arcs that
surely will never be used by the optimal solution.
This reduces the number of arcs in the graph approximately from 8 arcs
per channel to approximately 2 arcs per channel.
No pruning.
amount: 100 1000 10000 100000 1000000
channels: 104741 106163 106607 106654 106666
arcs: 837928 849304 852856 853232 853328
Prune, limit the channel capacity by its HTLC max
amount: 100 1000 10000 100000 1000000
channels: 104741 106163 106607 106654 106666
arcs: 255502 259314 260538 260676 260704
Prune, limit the channel capacity to the payment amount
amount: 100 1000 10000 100000 1000000
channels: 104741 106163 106607 106654 106666
arcs: 209482 216270 228618 295450 432468
Prune, limit the channel capacity to the payment amount and its HTLC max
amount: 100 1000 10000 100000 1000000
channels: 104741 106163 106607 106654 106666
arcs: 209480 212324 213242 215726 228018
This produces a slight speedup for MCF computations:
Amount (sats) | speedup
-----------------------
100 | 1.89
1000 | 1.77
10000 | 1.25
100000 | 1.25
1000000 | 1.18
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Speed in getroutes up by setting the granularity to 1000
Amount (sats) | speedup
-----------------------
100 | 1.00
1000 | 1.00
10000 | 1.06
100000 | 1.31
1000000 | 2.64
Worst runtime of getroutes
Amount (sats) | before (ms) | after (ms)
--------------------------------------
100 | 1507 | 761
1000 | 2129 | 1214
10000 | 1632 | 1043
100000 | 2004 | 1150
1000000 | 27170 | 3289
Changelog-None
Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Try a new way to refine flows, ie. reduce excess due to MCF accuracy and HTLC max constraints after hop amounts are computed with fees included. Changelog-None. Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Changelog-None Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Disable channels with HTLC min violations so that we don't hit them twice when computing routes. Changelog-None Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Lagrang3
force-pushed
the
askrene-fix-constraints
branch
from
1d475e5 to
73fd757
Compare
that can be useful for us in the mcf.c main loop. Changelog-None Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
We use a wrapper around the MCF solver that takes care of finding the best linearization parameters and fixing the flow values to meet the htlc_min and htlc_max constraints. We have reworked the current implementation and made it a bit more similar to renepay's version. Changelog-None. Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
and remove unused helper functions. Changelog-None Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
that new flows respect the HTLC min/max constraints. Changelog-None Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
Lagrang3
force-pushed
the
askrene-fix-constraints
branch
from
73fd757 to
d570cff
Compare
Lagrang3
commented
Jul 17, 2025
| tal_free(working_ctx); | ||
|
|
||
| /* all set! Now squash flows that use the same path */ | ||
| squash_flows(ctx, rq, flows); |
There was a problem hiding this comment.
At first this seemed like a good idea, but now I am hesitant about this. If the previous algorithm has found that the best way to deliver the payment is through
a set of flows for which all HTCL min/max constraints are satisfied. Then by merging any two flows
you might end-up again violating HTLC max.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this PR I am refactoring the wrapper of the MCF solver to fix some issues
we have seen when building routes in some common corner cases.
It addresses issues: #8339 and #7960.
We also take the opportunity to add a couple of features:
If reviewers are fine with it I can include those features in this PR, otherwise I could
create a separate PR for each them.
This is part of a sequence of refactorings and improvements, last one is #8332.