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

Prevent `channel_id` collisions (#3337)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

78/100 · Adequate
Prevent `channel_id` collisions (#3337)

* Reject channel if initial DB write fails

If the first DB write of a channel fails, we want to abort the channel
immediately, otherwise our state may be unusable. If for some reason
we already have a channel (for example because of a partial restore
from a DB backup), we want to avoid overwriting this state as well.

* Add global `channel_id`s collision resistance

We add a global, concurrent map that keeps track of every temporary
and final `channel_id` being used. We always add to this map before
creating channel actors or transitioning to a final `channel_id`
(and thus before storing channel data in the DB).

We only remove from that map when a channel actor dies: no other
channel can be associated with the corresponding temporary or
final `channel_id` since the channel was created after registering
the IDs.
✓ Descriptive subject✓ 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 commit hardens the Eclair Lightning node against two related problems when opening payment channels: it prevents the same channel ID from being reused by two different channels at the same time, and it aborts channel creation if the very first database write fails (for example because a channel with that ID already exists from a backup). Before this change, a colliding or partially-restored channel ID could cause one channel's state to overwrite another's, potentially leading to loss of funds or an inconsistent node state.

Recommended action

Deploy this patch to nodes that open or accept Lightning channels. Monitor logs for the new collision warnings and DB-insertion errors, which may indicate backup-restore issues or misbehaving peers. Ensure any partial database restores are reconciled before restarting the node, because the new addChannel() will now reject channels whose IDs already exist.

Security signals we found

01

State overwrite / collision prevention for channel identifiers

02

Abort-on-first-DB-write-failure to avoid inconsistent persistence

03

Global concurrent map guarding temporary and final channel_id usage

04

New insert-only DB method returning failure instead of silently upserting

05

Rollback of funding transaction attempt when DB insertion fails

06

Defense-in-depth: per-peer map check retained alongside global map

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.