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
Prioritize private channels when relaying payments (#3248)
When relaying payments, we want to select private channels first and
keep as much liquidity available as possible in public channels, to
ensure that we don't send a `channel_update` that would otherwise
disable the public channel (and thus make the private channels also
unusable since they aren't visible by path-finding algorithms) or
limit the `htlc_maximum_msat` of this public channel (which also
indirectly applies to private channels).
We also change the order in which we select channels that have the
same visibility: we prioritize channels with smaller balances, to
ensure that we keep our larger balances for larger payments. When
balances are equal, we prioritize the largest channel, which creates
a larger inbound liquidity to allow receiving larger payments.
if (requestedChannelId_opt.contains(channel.channelId)) {
397
-
context.log.debug("requested short channel id is our preferred channel")
398
-
Some(channel)
399
-
} else {
400
-
context.log.debug("replacing requestedShortChannelId={} by preferredShortChannelId={} with availableBalanceMsat={}", requestedShortChannelId_opt, channel.channelUpdate.shortChannelId, channel.commitments.availableBalanceForSend)
401
-
Some(channel)
402
-
}
388
+
.sortWith {
389
+
// we always prioritize private channels to avoid exhausting our public channels and disabling them or lowering their htlc_maximum_msat
390
+
case (channel1, channel2) if channel1.commitments.announceChannel != channel2.commitments.announceChannel =>!channel1.commitments.announceChannel
391
+
// otherwise, we use the channel with the smallest capacity to ensure we keep high-capacity channels enabled
392
+
// (if we ran out of liquidity in a large channels, we would send a channel_update to disable it, which would
393
+
// negatively impact our score in path-finding algorithms)
394
+
case (channel1, channel2) if channel1.commitments.capacity != channel2.commitments.capacity => channel1.commitments.capacity <= channel2.commitments.capacity
395
+
// otherwise, we use the channel with the smallest balance, to ensure we keep higher balances for larger payments
396
+
case (channel1, channel2) => channel1.commitments.availableBalanceForSend <= channel2.commitments.availableBalanceForSend
0 commit comments