AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 20 Bitcoin

Use balance estimates from past payments in path-finding (#2308)

Public commit record

What the developer wrote

Authored by Thomas HUET

81/100 · Strong
Use balance estimates from past payments in path-finding (#2308)

We estimate the probability that a given route can relay a given payment as part of route selection.
Until now this estimate was naively assuming the channel balances to be uniformly distributed.
We will now use data from past payment attempts (both successes and failures) to provide a better estimate, hopefully improving route selection.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This commit improves Eclair's Lightning payment routing by optionally using past payment successes and failures to estimate how much money each channel can forward, instead of assuming balances are random. It is a feature enhancement, not a security patch. There is no indication in the commit or supplied references that it fixes a vulnerability.

Recommended action

Review the removed probability-bounds guard to ensure `BalanceEstimate.canSend` cannot return values outside [0,1] under any input; if it can, reintroduce a clamp or invariant check. Monitor for potential probing-based manipulation of the new balance estimator, though this is a normal operational risk rather than an immediate vulnerability.

Security signals we found

01

Removal of a runtime log.error guard in BalanceEstimate.canSend that previously flagged out-of-range probability estimates

02

New heuristic uses historical payment metadata to influence route selection, which could be manipulated if an attacker can induce many failed/successful probes

03

No bounds check is visible in the diff for the probability returned by balance.canSend; the removed guard was the only explicit one

Risk score

Why this scored 20/100

Our methodology →
Potential impact 2/30
Exploitability 1/25
Stealth signal 1/15
Affected reach 3/15
Confidence 9/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.