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

Reject `temporary_channel_id` duplicates early (#3324)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

93/100 · Strong
Reject `temporary_channel_id` duplicates early (#3324)

We previously rejected duplicate `temporary_channel_id` immediately, but
we didn't immediately reject `temporary_channel_id`s that conflict with
a *final* `channel_id` with the same peer: the rejection would happen
later in the flow when transitioning from temporary to final IDs, which
made debugging harder.

Since the channel interceptor step isn't atomic, we must check for
duplicate channel IDs *after* rate-limiting, to ensure that we don't
try inserting an entry in the channels map that is already there.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This change tightens how Eclair handles incoming Lightning channel requests. It now rejects a new channel's temporary ID if it collides with an existing final channel ID for the same peer, and it re-checks for collisions after rate-limiting. Previously, some collisions were caught only later, which could make the node misbehave or make problems harder to diagnose. The patch is defensive hardening rather than a clear exploit fix.

Recommended action

Treat as a defensive hardening patch. Review whether any in-flight channel state could still bypass the new checks, and consider whether the same collision logic should be applied to other channel-opening code paths.

Security signals we found

01

duplicate identifier collision now rejected earlier

02

non-atomic interceptor step followed by re-check

03

final channel ID included in collision detection

04

new regression test for ID reuse against confirmed channel

Risk score

Why this scored 37/100

Our methodology →
Potential impact 8/30
Exploitability 6/25
Stealth signal 5/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.