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

Ignore repeated invalid `tx_signatures` (#3328)

Public commit record

What the developer wrote

Authored by Bastien Teinturier

88/100 · Strong
Ignore repeated invalid `tx_signatures` (#3328)

When our peer sends us an invalid `tx_signatures`, we processed it and
ignored the failure when we've already sent our own `tx_signatures`,
because the transaction may be broadcast and may confirm anyway.

We now stop processing those invalid `tx_signatures` repeatedly: if our
peer sends us more than 3 invalid `tx_signatures` for a given funding
transaction, they're definitely buggy so we'll just wait for the
transaction to confirm without trying to obtain the fully signed one
locally.

We also now avoid unnecessary DB writes on `shutdown`.
We don't need to write to the DB every time we receive `shutdown` from
our peer, since the BOLTs require `shutdown` to be retransmitted on
reconnection.
✓ 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 update changes how the Eclair Lightning node handles repeated bad 'tx_signatures' messages from a peer during dual-funded channel opens and splices. Previously, every bad signature was processed and logged, which could waste CPU and disk writes and might be abused to keep a node busy. Now, after three bad signatures for the same funding transaction, the node stops processing them and just waits for the on-chain confirmation. The patch also removes unnecessary database writes when receiving repeated 'shutdown' messages. The commit message frames this as a robustness improvement against buggy or malicious peers, not as a critical vulnerability fix.

Recommended action

Treat as a defensive hardening patch. Operators should upgrade to reduce resource-consumption risk from misbehaving peers during dual-funded opens and splices. No immediate emergency response is indicated by the commit content alone. Monitor for follow-up security advisories from ACINQ.

Security signals we found

01

Rate-limiting of invalid peer messages (tx_signatures) to prevent repeated CPU/disk consumption

02

Removal of unnecessary DB writes on shutdown receipt, reducing disk-wear and potential DoS surface

03

No channel force-close on invalid signatures; node remains open and waits for on-chain confirmation

04

Counter reset on funding confirmation and state transitions to avoid stale state

Risk score

Why this scored 47/100

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