You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use cost / path amt limit as the pathfinding score, not cost
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.
// Verify the liquidity offered by this channel complies to the minimal contribution.
2792
-
let contributes_sufficient_value = available_value_contribution_msat >= minimal_value_contribution_msat;
2793
2807
// Do not consider candidate hops that would exceed the maximum path length.
2794
2808
let path_length_to_node = $next_hops_path_length
2795
2809
+ if $candidate.blinded_hint_idx().is_some(){0} else {1};
@@ -2801,6 +2815,8 @@ where L::Target: Logger {
2801
2815
let exceeds_cltv_delta_limit = hop_total_cltv_delta > max_total_cltv_expiry_delta asu32;
2802
2816
2803
2817
let value_contribution_msat = cmp::min(available_value_contribution_msat, $next_hops_value_contribution);
2818
+
// Verify the liquidity offered by this channel complies to the minimal contribution.
2819
+
let contributes_sufficient_value = value_contribution_msat >= minimal_value_contribution_msat;
2804
2820
// Includes paying fees for the use of the following channels.
2805
2821
let amount_to_transfer_over_msat:u64 = match value_contribution_msat.checked_add($next_hops_fee_msat){
2806
2822
Some(result) => result,
@@ -2950,7 +2966,7 @@ where L::Target: Logger {
2950
2966
// Ignore hops if augmenting the current path to them would put us over `max_total_routing_fee_msat`
2951
2967
if total_fee_msat > max_total_routing_fee_msat {
2952
2968
if should_log_candidate {
2953
-
log_trace!(logger,"Ignoring {} due to exceeding max total routing fee limit.",LoggedCandidateHop(&$candidate));
2969
+
log_trace!(logger,"Ignoring {} with fee {total_fee_msat} due to exceeding max total routing fee limit {max_total_routing_fee_msat}.",LoggedCandidateHop(&$candidate));
2954
2970
2955
2971
ifletSome(_) = first_hop_details {
2956
2972
log_trace!(logger,
@@ -2991,15 +3007,31 @@ where L::Target: Logger {
2991
3007
// but it may require additional tracking - we don't want to double-count
2992
3008
// the fees included in $next_hops_path_htlc_minimum_msat, but also
2993
3009
// can't use something that may decrease on future hops.
0 commit comments