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

Don't rebroadcast announcements for spent channels (#3235)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

93/100 · Strong
Don't rebroadcast announcements for spent channels (#3235)

* Don't rebroadcast spent channels

We introduced a mechanism to keep spent channels in the `Router` until
the spending transaction has enough confirmations to avoid removing
spliced channels from our graph too eagerly. An unwanted side-effect
is that while we're waiting for confirmations, we may broadcast channel
announcements for these spent channels, which looks like spam to our
peers.

We now filter out channels that have been spent for which we're waiting
for confirmations when sending out gossip.

* Notify front nodes immediately when channel is spent

Another side-effect of the splice change is that we didn't notify front
nodes that the channel was spent before it reached enough confirmations
so we kept sending channel gossip to our peers.

We now immediately notify the front nodes so that they stop sending this
channel to our peers.
✓ 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 commit fixes a bug where Eclair would keep advertising Lightning channels that had already been spent (for example, as part of a splice operation) while waiting for the spending transaction to be confirmed. This caused the node to send stale or misleading routing information to its peers, which looks like network spam and could confuse other nodes' routing decisions. The fix filters those spent-but-pending channels out of gossip broadcasts and immediately tells front-end nodes to stop relaying them.

Recommended action

Treat as a routine bug-fix patch with mild operational/security benefit. Upgrade nodes running affected versions to include this commit, especially if they participate in public routing gossip. No emergency response is warranted; monitor for related routing anomalies.

Security signals we found

01

Information disclosure / stale routing data propagation

02

Denial-of-service-like behavior via gossip spam to peers

03

Incorrect routing state in peer network graph during splice confirmation window

04

Fix is defensive: no memory-safety or cryptographic bug, but reduces attack surface for graph-poisoning / eclipse-style routing manipulation

Risk score

Why this scored 41/100

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