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

chancloser: remove MarkCoopBroadcasted(nil) calls

Public commit record

What the developer wrote

Authored by Jared Tobin

80/100 · Strong
chancloser: remove MarkCoopBroadcasted(nil) calls

Remove the two call sites that set ChanStatusCoopBroadcasted
before a cooperative close transaction exists:

- BeginNegotiation in the legacy close path (chancloser.go)
- ChannelFlushed handling in the RBF close path
(rbf_coop_transitions.go)

Both calls passed nil as the close tx, creating a "limbo" state
where ChanStatusCoopBroadcasted is set but no close transaction
is stored. This is unnecessary because ShutdownInfo — persisted
earlier by MarkShutdownSent in initChanShutdown / the RBF
ShutdownPending transition — already serves as the durable
signal that the shutdown flow was entered.

ChanStatusCoopBroadcasted should only be set when a real close
transaction exists, which this change preserves.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit cleans up how LND records that a Lightning channel is being closed cooperatively. Previously, the code would mark a channel as 'cooperatively closed' before an actual closing transaction existed, storing a placeholder 'nil' transaction. That created a confusing in-between state in the database. The change removes those premature marks and now requires a real, non-nil closing transaction before the status is set. It also updates restart logic so the node can still recover an unfinished close from other stored information. The commit is defensive hardening rather than a fix for an active exploit.

Recommended action

Reviewers should verify that all call sites of MarkCoopBroadcasted now supply a non-nil transaction, that restartCoopClose correctly falls through to ShutdownInfo-based recovery when no close tx exists, and that no RPC or wallet path still relies on the old nil-tx 'pending close' signal. Consider adding a regression test for crash recovery in the middle of a cooperative close.

Security signals we found

01

Eliminates a 'limbo' channel status where ChanStatusCoopBroadcasted is set without a stored close transaction

02

Adds an explicit non-nil guard in markBroadcasted to prevent future nil close-tx persistence

03

Reduces risk of incorrect state recovery/restart behavior after a crash during cooperative close

04

Improves internal consistency between channel status and stored close transaction

Risk score

Why this scored 46/100

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