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

askrene: exclude stubchannels from routing

Public commit record

What the developer wrote

Authored by niftynei

80/100 · Strong
askrene: exclude stubchannels from routing

My node has some recovered channels, which were causing a crash
in askrene, due to the fact that they have duplicate scids.

Easy fix is simply to skip recovered stubs when planning
routes.

Aug 15 16:34:14 citrine lightningd[1976574]: cln-askrene: ./plugins/askrene/child/additional_costs.h:26: additional_cost_htable_add: Assertion `!additional_c ost_htable_getmatch_(ht, k, h, v, &i)' failed.

Changelog-Fixed: Crash when trying to pay and you have recovered channel stubs in your peers list
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit fixes a crash in Core Lightning's routing plugin (askrene) that occurred when a user had 'recovered channel stubs'—placeholder records left behind after restoring a node from a backup. These stubs all share the same placeholder channel ID (1x1x1), which caused an internal table that expects unique IDs to fail an assertion and crash the plugin. The fix makes askrene skip these stubs when planning routes. The crash is triggered by normal user actions (trying to pay with recovered stubs present), not by a remote attacker, and the plugin can be restarted.

Recommended action

Apply the patch and run the new regression test. Users who have performed static-backup recovery and still see askrene crashes should upgrade. No immediate remote mitigation is needed because the crash requires local recovered stubs.

Security signals we found

01

Denial-of-service condition: local askrene plugin aborts on assertion failure

02

Root cause: non-unique placeholder SCIDs in recovered channel stubs

03

Fix: filter stub SCIDs before routing

04

Regression test added to prevent reintroduction

Risk score

Why this scored 60/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 8/15
Affected reach 10/15
Confidence 8/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.