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

Clear duplicate monitor-pending RAA on signer resend

Public commit record

What the developer wrote

Authored by Wilmer Paulino

83/100 · Strong
Clear duplicate monitor-pending RAA on signer resend

The `chanmon_consistency` fuzz target found a reconnect ordering where
`signer_pending_revoke_and_ack` and `monitor_pending_revoke_and_ack`
could both describe the same owed `revoke_and_ack`.

The channel first received a `commitment_signed` whose monitor update
completed, but the signer could not provide the next point or secret,
leaving `signer_pending_revoke_and_ack` set. Later, receiving the peer
`revoke_and_ack` freed holding-cell HTLCs and produced a held monitor
update. While that monitor update was still blocked,
`channel_reestablish` saw the peer one state behind and recorded
`monitor_pending_revoke_and_ack`, plus the corresponding monitor-pending
`commitment_signed`, so the messages could be replayed once monitor
updating was restored.

If the signer unblocked before the held monitor update was released,
`signer_maybe_unblocked` generated and sent the already monitor-safe RAA
using `signer_pending_revoke_and_ack`. The monitor-pending flag was not
cleared at that point, so `monitor_updating_restored` later generated
the same RAA again when the held update completed. The peer had already
advanced after accepting the signer-unblocked RAA, so it rejected the
duplicate secret as not corresponding to its current pubkey and
force-closed.

Fix this by clearing `monitor_pending_revoke_and_ack` in the
signer-resume path only once a signer-pending RAA is actually being
returned.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit fixes a bug in the Lightning Dev Kit where, after a peer reconnects, the same cryptographic 'revoke_and_ack' message could be generated and sent twice. The duplicate would contain a secret the peer had already accepted, so the peer would reject it and force-close the payment channel. The fix clears an internal 'monitor-pending' flag when the signer-resume path actually produces the message, preventing the later duplicate.

Recommended action

Apply the patch. The change is small, targeted, and includes a regression test. Nodes running with async signers or under reconnect/monitor-delay stress are most exposed; upgrading avoids unnecessary channel force-closures.

Security signals we found

01

Duplicate cryptographic revocation secret sent to peer

02

Peer force-closes channel on rejection of stale revocation secret

03

State-flag collision between signer-pending and monitor-pending resend paths

04

Fuzz target (chanmon_consistency) discovered the trigger ordering

05

Regression test added: test_signer_unblocked_clears_monitor_pending_raa_after_reestablish

Risk score

Why this scored 66/100

Our methodology →
Potential impact 22/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.