Commit 51414fb
committed
Use
While walking nodes in our Dijkstra's pathfinding, we may find a
channel which is amount-limited to less than the amount we're
currently trying to send. This is fine, and when we encounter such
nodes we simply limit the amount we'd send in this path if we pick
the channel.
When we encounter such a path, we keep summing the cost across hops
as we go, keeping whatever scores we assigned to channels between
the amount-limited one and the recipient, but using the new limited
amount for any channels we look at later as we walk towards the
sender.
This leads to somewhat inconsistent scores, especially as our
scorer assigns a large portion of its penalties and a portion of
network fees are proportional to the amount. Thus, we end up with a
somewhat higher score than we "should" for this path as later hops
use a high proportional cost. We accepted this as a simple way to
bias against small-value paths and many MPP parts.
Sadly, in practice it appears our bias is not strong enough, as
several users have reported that we often attempt far too many MPP
parts. In practice, if we encounter a channel with a small limit
early in the Dijkstra's pass (towards the end of the path), we may
prefer it over many other paths as we start assigning very low
costs early on before we've accumulated much cost from larger
channels.
Here, we swap the `cost` Dijkstra's score for `cost / path amount`.
This should bias much stronger against many MPP parts by preferring
larger paths proportionally to their amount.
This somewhat better aligns with our goal - if we have to pick
multiple paths, we should be searching for paths the optimize
fee-per-sat-sent, not strictly the fee paid.
However, it might bias us against smaller paths somewhat stronger
than we want - because we're still using the fees/scores calculated
with the sought amount for hops processed already, but are now
dividing by a smaller sent amount when walking further hops, we
will bias "incorrectly" (and fairly strongly) against smaller
parts.
Still, because of the complaints on pathfinding performance due to
too many MPP paths, it seems like a worthwhile tradeoff, as
ultimately MPP splitting is always the domain of heuristics anyway.cost / path amt limit as the pathfinding score, not cost
1 parent a31da0a commit 51414fb
1 file changed
+27
-14
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
1396 | 1396 | | |
1397 | 1397 | | |
1398 | 1398 | | |
1399 | | - | |
| 1399 | + | |
1400 | 1400 | | |
1401 | 1401 | | |
1402 | 1402 | | |
| |||
2122 | 2122 | | |
2123 | 2123 | | |
2124 | 2124 | | |
2125 | | - | |
| 2125 | + | |
| 2126 | + | |
| 2127 | + | |
| 2128 | + | |
| 2129 | + | |
| 2130 | + | |
| 2131 | + | |
| 2132 | + | |
| 2133 | + | |
| 2134 | + | |
2126 | 2135 | | |
2127 | 2136 | | |
2128 | 2137 | | |
| |||
2991 | 3000 | | |
2992 | 3001 | | |
2993 | 3002 | | |
2994 | | - | |
| 3003 | + | |
2995 | 3004 | | |
2996 | | - | |
| 3005 | + | |
2997 | 3006 | | |
2998 | | - | |
2999 | | - | |
3000 | | - | |
| 3007 | + | |
| 3008 | + | |
| 3009 | + | |
| 3010 | + | |
| 3011 | + | |
| 3012 | + | |
| 3013 | + | |
| 3014 | + | |
| 3015 | + | |
| 3016 | + | |
3001 | 3017 | | |
3002 | | - | |
| 3018 | + | |
3003 | 3019 | | |
3004 | 3020 | | |
3005 | 3021 | | |
| |||
3008 | 3024 | | |
3009 | 3025 | | |
3010 | 3026 | | |
3011 | | - | |
| 3027 | + | |
3012 | 3028 | | |
3013 | 3029 | | |
3014 | 3030 | | |
| |||
3558 | 3574 | | |
3559 | 3575 | | |
3560 | 3576 | | |
3561 | | - | |
3562 | | - | |
3563 | | - | |
3564 | | - | |
| 3577 | + | |
3565 | 3578 | | |
3566 | 3579 | | |
3567 | 3580 | | |
| |||
3587 | 3600 | | |
3588 | 3601 | | |
3589 | 3602 | | |
3590 | | - | |
| 3603 | + | |
3591 | 3604 | | |
3592 | 3605 | | |
3593 | 3606 | | |
| |||
0 commit comments