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

askrene: add askrene-bias-node rpc

Public commit record

What the developer wrote

Authored by Lagrang3

68/100 · Adequate
askrene: add askrene-bias-node rpc

Changelog-Added: askrene-bias-node: an RPC command to set a bias on node's outgoing or incoming channels.

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 adds a new RPC command, askrene-bias-node, to Core Lightning's askrene routing plugin. It lets users tell the routing engine to prefer or avoid paths that go through a specific Lightning node. The change is a feature addition: it extends existing layer/bias machinery with a new per-node bias type, updates generated RPC bindings, schemas, documentation, and tests. There is no direct evidence in the commit of a security vulnerability, but any new RPC that influences route selection can affect payment reliability, fees, and potentially be misused by an authenticated caller to degrade routing behavior.

Recommended action

No immediate security action is required. As a routine review step, verify that askrene-bias-node enforces the documented -100..+100 bias range, respects the plugin's RPC permission model, and that node bias lookups cannot introduce pathological runtime behavior (e.g., unbounded layer growth or biased-node loops). Consider adding tests for invalid/edge bias values and concurrent layer modifications if not already present.

Security signals we found

01

New RPC surface added (askrene-bias-node) increases authenticated attack surface.

02

Bias values are bounded to -100..+100 per schema, which limits magnitude of routing influence.

03

No explicit authorization checks in the diff; relies on Core Lightning's existing RPC permission model.

04

No memory-safety red flags visible in the changed C/Rust code, but the diff is partial and does not show full handler implementation.

05

Feature is additive and follows existing askrene-bias-channel pattern, suggesting low likelihood of novel vulnerability class.

Risk score

Why this scored 23/100

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