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

contractcourt: update close logic to handle re-orgs of depth n-1, where n is num confs

Public commit record

What the developer wrote

Authored by Olaoluwa Osuntokun

83/100 · Strong
contractcourt: update close logic to handle re-orgs of depth n-1, where n is num confs

In this commit, we update the close logic to handle re-ogs up to the
final amount of confirmations. This is done generically, so we're able
to handle events such as: coop close confirm, re-org, breach confirm,
re-org, force close confirm, re-org, etc.

The upcoming set of new tests will exercise all of these cases.

We modify the block beat handling to unify the control flow. As it's
possible we get the beat, then see the spend, or the oher way around.
✓ 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 changes how LND watches for channel-closing transactions on the Bitcoin blockchain. Previously, the code might act immediately when it saw a spend, which could be risky if the blockchain later reorganized (a 're-org') and removed that transaction. Now it waits for a configurable number of confirmations before processing the close, and can reset cleanly if a re-org happens. This reduces the chance of LND taking wrong actions (for example, failing to punish a breach or incorrectly marking a channel closed) during temporary blockchain reorganizations.

Recommended action

Review the new state machine for edge cases: ensure confNtfn and spendNtfn are always cancelled on all exit paths, verify requiredConfsForSpend returns sensible values for tiny and very large channels, and run or add the promised integration tests covering coop-close-reorg-breach and force-close-reorg sequences. Consider whether a re-org that re-mines the same tx at a different height is handled correctly by the re-registered spend notification.

Security signals we found

01

Re-org safety: waits for N confirmations before acting on a channel close

02

Negative confirmation handling reverts state and re-registers for spend notifications

03

Duplicate spend detection prevents double registration for the same transaction

04

Different spend detection cancels old confirmation registration and replaces it

05

Confirmation depth scales with channel capacity via lnwallet.CloseConfsForCapacity

06

Blockbeat and spend-notification paths are unified through the same state machine

Risk score

Why this scored 71/100

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