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

Ignore stale announcement_signatures instead of force-closing

Public commit record

What the developer wrote

Authored by Jeffrey Czyz

86/100 · Strong
Ignore stale announcement_signatures instead of force-closing

A peer may transmit `announcement_signatures` signed over a stale
`short_channel_id` — most plausibly a retransmission or a peer
implementation whose view hasn't caught up to our post-splice
promotion. Verifying such sigs against the current
`UnsignedChannelAnnouncement` (built from `self.funding`) always fails
the hash check, which previously produced a force-close.

BOLT #7 does not require closing in this situation; the mismatch is
expected across splice handoffs. Short-circuit with
`ChannelError::Ignore` when `msg.short_channel_id` doesn't match the
current funding's scid, leaving the genuine invalid-signature paths
in place for sigs that actually target our current scid.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This change fixes a bug where a Lightning node would unnecessarily force-close a payment channel if its peer sent an outdated 'announcement_signatures' message referencing the old channel identifier after a splice (a channel funding update). The node now simply ignores these stale messages, keeping the channel open. The bug was not a direct theft of funds, but it could cause unwanted channel closures and disruption.

Recommended action

Review and merge the patch. It is a defensive fix that improves channel availability without weakening signature validation for messages targeting the current short_channel_id. Monitor for any related edge cases where ignoring might mask genuine misbehavior.

Security signals we found

01

Force-close avoidance on stale but spec-compliant peer message

02

Splicing handoff edge case in BOLT #7 announcement signature handling

03

Channel availability / DoS mitigation

04

Regression test added for stale announcement_signatures after splice lock

Risk score

Why this scored 62/100

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