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

Identify failing node by its index (#3224)

Public commit record

What the developer wrote

Authored by Thomas HUET

76/100 · Adequate
Identify failing node by its index (#3224)

When a HTLC is failed remotely, the failing node was previously identified by its node id.
However this is not enough if the same node appears multiple times in the payment route, for instance for circular rebalancing.
We now identify the failing node using its index in the payment route.
✓ 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 fixes a routing bug in the Eclair Lightning node. When a payment failed somewhere along the path, the software used to identify the failing node only by its public key. That caused confusion when the same node appeared more than once in a route (for example, in circular rebalancing payments), because the wrong occurrence could be blamed. The fix adds the failing node's position (index) in the route so the correct hop is identified. This is a correctness/reliability improvement rather than a direct theft-of-funds vulnerability, but misidentifying the failing hop could lead to poor routing decisions, unnecessary retries, or incorrect blacklisting of channels/nodes.

Recommended action

Treat as a reliability/correctness fix and include it in the next maintenance release. Reviewers should verify that `route.hops(index)` cannot throw an out-of-bounds exception for malformed failure packets, and that the index is consistently 1-based across all call sites. No emergency security patch is indicated, but operators running circular-rebalancing or trampoline payments should upgrade to avoid routing degradation.

Security signals we found

01

Failure attribution ambiguity when a node appears multiple times in a route

02

Potential incorrect hop/channel blacklisting due to node-id-only failure identification

03

Routing/liquidity learning could be poisoned by misattributed failures

04

No cryptographic weakness or direct fund-stealing primitive introduced

05

Fix is structural/correctness-oriented across Sphinx, payment lifecycle, and router

Risk score

Why this scored 35/100

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