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

Merge PR 'Drop since-applied blocked monitor updates before the stale-channel check' (#5046)

Public commit record

What the developer wrote

Authored by Matt Corallo

81/100 · Strong
Merge PR 'Drop since-applied blocked monitor updates before the stale-channel check' (#5046)

from drop-applied-blocked-mon-updates into main

Reviewed-on: https://git.rust-bitcoin.org/lightningdevkit/rust-lightning/pulls/5046
Reviewed-by: Matt Corallo <matt@noreply.git.rust-bitcoin.org>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Links an issue, advisory, or supporting reference
The short version

What changed, and why it matters

This patch fixes a bug in the Lightning Dev Kit's channel startup logic. Previously, if a user's ChannelManager state was older than their ChannelMonitor, the code would force-close the channel and incorrectly fail backwards (cancel) any HTLCs that were added in a monitor update that had already been applied. The fix drops those already-applied blocked updates before doing the stale check, so HTLCs the counterparty is already committed to are not wrongly canceled. This could have caused payment failures or loss of funds in edge cases involving stale backups.

Recommended action

Upgrade to a rust-lightning version containing this commit. Users relying on backup/restore of ChannelManager state should ensure their backup procedures minimize staleness relative to ChannelMonitor state. Review any prior force-closures that occurred after restoring a stale ChannelManager to see if HTLCs were incorrectly failed backwards.

Security signals we found

01

Force-close triggered by stale ChannelManager state

02

Incorrect HTLC failure backwards for already-committed HTLCs

03

ChannelMonitor/ChannelManager state desynchronization

04

Blocked monitor updates not reconciled before stale check

05

Potential payment failure or fund resolution inconsistency

Risk score

Why this scored 64/100

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