Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Avoid reusing just-failed channels in the router, making the impossibility penalty configurable #1600

Merged
merged 3 commits into from Jul 15, 2022
Merged

Avoid reusing just-failed channels in the router, making the impossibility penalty configurable #1600

merged 3 commits into from Jul 15, 2022

Commits on Jul 14, 2022

  1. Track channels which a given payment part failed to traverse 

    When an HTLC fails, we currently rely on the scorer learning the
failed channel and assigning an infinite (`u64::max_value()`)
penalty to the channel so as to avoid retrying over the exact same
path (if there's only one available path). This is common when
trying to pay a mobile client behind an LSP if the mobile client is
currently offline.

This leads to the scorer being overly conservative in some cases -
returning `u64::max_value()` when a given path hasn't been tried
for a given payment may not be the best decision, even if that
channel failed 50 minutes ago.

By tracking channels which failed on a payment part level and
explicitly refusing to route over them we can relax the
requirements on the scorer, allowing it to make different decisions
on how to treat channels that failed relatively recently without
causing payments to retry the same path forever.

This does have the drawback that it could allow two separate part
of a payment to traverse the same path even though that path just
failed, however this should only occur if the payment is going to
fail anyway, at least as long as the scorer is properly learning.

Closes lightningdevkit#1241, superseding lightningdevkit#1252.
    @TheBlueMatt
    TheBlueMatt committed Jul 14, 2022
    Copy the full SHA
    93e645d View commit details
    Browse the repository at this point in the history

  2. Make the ProbabilisticScorer impossibility penalty configurable 

    When we consider sending an HTLC over a given channel impossible
due to our current knowledge of the channel's liquidity, we
currently always assign a penalty of `u64::max_value()`. However,
because we now refuse to retry a payment along the same path in
the router itself, we can now make this value configurable. This
allows users to have a relatively high knowledge decay interval
without the side-effect of refusing to try the only available path
in cases where a channel is intermittently available.
    @TheBlueMatt
    TheBlueMatt committed Jul 14, 2022
    Copy the full SHA
    ec2b1ce View commit details
    Browse the repository at this point in the history

  3. Change default "impossibility penalty" to one Bitcoin 

    In general we should avoid taking paths that we are confident will
not work as much possible, but we should be willing to try each
payment at least once, even if its over a channel that failed
recently. A full Bitcoin penalty for such a channel seems
reasonable - lightning fees are unlikely to ever reach that point
so such channels will be scored much worse than any other potential
path, while still being below `u64::max_value()`.
    @TheBlueMatt
    TheBlueMatt committed Jul 14, 2022
    Copy the full SHA
    a3547e2 View commit details
    Browse the repository at this point in the history