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

askrene: rework the caller of the MCF solver

Public commit record

What the developer wrote

Authored by Lagrang3

68/100 · Adequate
askrene: rework the caller of the MCF solver

We use a wrapper around the MCF solver that takes care of finding the
best linearization parameters and fixing the flow values to meet the
htlc_min and htlc_max constraints.
We have reworked the current implementation and made it a bit more
similar to renepay's version.

Out of 50000 simulated payment situations distributed accross payment
amounts of 1e2, 1e3, 1e4, 1e5 and 1e6 sats, we find that 133 failed
cases in the master branch turn to success with the current changes,
while only 3 success cases in the master are not solved by the changes.

master
+-------+------+
| S | F |
+---+-------+------+
| S | 46329 | 133 |
changes +---+-------+------+
| F | 3 | 3535 |
+---+-------+------+

Out of the 133 cases that flipped from failure to success the failed
reasons were:

122 -> "Could not find route without excessive cost"
5 -> "We couldn't quite afford it"
5 -> "Amount *msat below minimum"
1 -> tripped an HTLC min check

Changelog-None.

Signed-off-by: Lagrang3 <lagrang3@protonmail.com>
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit rewrites the payment routing solver in Core Lightning's experimental 'askrene' plugin. It changes how routes are computed, how fees and delays are checked, and how channel capacity reservations are handled. The stated goal is to make more payments succeed in simulation. There is no claim this fixes a security vulnerability, and the changes are in an experimental plugin rather than core payment logic. The main risk is that a bug in the new solver could produce invalid or uneconomic routes, but the commit itself does not introduce an obvious exploitable weakness.

Recommended action

Treat as a normal code-quality/refactor review. Verify that the new iterative solver preserves invariants: total delivered amount equals requested amount, fees do not exceed maxfee, worst delay does not exceed maxdelay, and all HTLC minimum/maximum constraints are respected. Pay attention to the FIXME comments for follow-up work. No urgent security action is indicated by the commit alone.

Security signals we found

01

Code change is in an experimental plugin (askrene), not the main daemon payment path

02

No security-relevant keywords in commit title or message

03

No CVE, advisory, or vendor security disclosure referenced

04

No attribution to an independent security researcher

05

Adds several FIXME comments about future constraints (max route length, max number of routes, recipient-pays-fees option)

06

Modifies fee-budget and delay checks; could affect route validity if implemented incorrectly

07

Uses assertions and abort() on arithmetic failures, which is defensive but not a vulnerability signal

Risk score

Why this scored 23/100

Our methodology →
Potential impact 5/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 5/15
Confidence 4/10
Evidence quality 2/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.