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

Clear stale monitor pending resends on reestablish

Public commit record

What the developer wrote

Authored by Wilmer Paulino

73/100 · Adequate
Clear stale monitor pending resends on reestablish

A stale ChannelManager can be reloaded after a monitor update has
already completed in a prior runtime and released its post-update
messages to the counterparty. The latest ChannelMonitor is not stale,
but the serialized manager may still contain the old in-flight monitor
state and `monitor_pending_*` resend flags from before the completion
action ran.

This becomes observable when startup monitor-completion background
events are interleaved with splice promotion. On reload, the completed
monitor update is queued as a background event. If a splice confirmation
is processed before that background event fully resumes the channel,
splice promotion can create a new `RenegotiatedFundingLocked` monitor
update. The old completion is then blocked behind the new in-flight
splice update. Once the channel reconnects and the splice update
completes, `monitor_updating_restored` may consume the stale
`monitor_pending_revoke_and_ack` / `monitor_pending_commitment_signed`
flags and release a duplicate `revoke_and_ack` or `commitment_signed`.

The peer's `channel_reestablish` commitment numbers are authoritative
for this case. If `next_remote_commitment_number` says the peer is not
waiting for a `revoke_and_ack`, clear `monitor_pending_revoke_and_ack`.
Likewise, if `next_local_commitment_number` says the peer already has
our latest `commitment_signed`, clear
`monitor_pending_commitment_signed`.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This patch fixes a bug in the Lightning Dev Kit where a node could accidentally resend old cryptographic messages to a peer after restarting. When a stale saved channel state was reloaded, the node might think it still owed the peer a 'revoke_and_ack' or 'commitment_signed' message that had already been sent. During channel reestablishment, the peer's commitment numbers now authoritatively clear these stale flags, preventing duplicate messages that could confuse or disrupt the channel.

Recommended action

Apply the patch. It is a targeted correctness fix for Lightning channel state resynchronization after restarts involving splicing. No additional immediate action is indicated beyond normal patch deployment and monitoring for related state-machine issues.

Security signals we found

01

Duplicate cryptographic message resend (revoke_and_ack / commitment_signed) due to stale in-flight state

02

State inconsistency between serialized ChannelManager and latest ChannelMonitor after restart

03

Race/interleaving between startup background monitor completion and splice-locked monitor update

04

Potential channel desynchronization or forced closure from duplicate commitment messages

05

Fix uses peer-provided commitment numbers as authoritative ground truth during reestablish

Risk score

Why this scored 66/100

Our methodology →
Potential impact 22/30
Exploitability 12/25
Stealth signal 10/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.