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

wallet: handle reorgs for our_outputs/our_txs by hand

Public commit record

What the developer wrote

Authored by Sangbida Chaudhuri

73/100 · Adequate
wallet: handle reorgs for our_outputs/our_txs by hand

The legacy tables rely on their blocks(height) ON DELETE SET NULL
foreign keys to mark rows unconfirmed/unspent when a block is reorged
out. our_outputs/our_txs deliberately carry no blocks FK (bwatch does
not maintain a blocks table), so block disconnect and rollback must
demote their blockheight/spendheight fields explicitly.

Demote, never delete: a row also carries state the chain cannot
re-deliver (reserved_til, onchaind close metadata), and this path runs
not just on real reorgs but on every startup, when chaintopology
invalidates its rescan window. Rediscovery re-promotes the row via
wallet_add_our_output / wallet_transaction_add; a tx that never
re-confirms just stays unconfirmed and unspendable.

Co-authored-by: Cursor <cursoragent@cursor.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit fixes how Core Lightning's wallet records handle blockchain reorganizations (reorgs) for two newer database tables, our_outputs and our_txs. Previously, these tables were not properly updated when blocks were removed or rolled back, meaning the wallet could incorrectly believe funds were confirmed or spent when they no longer were. The fix explicitly resets those records to an unconfirmed state during reorgs and startup rescan windows, matching the behavior of older tables. This prevents internal accounting errors and potential loss or misreporting of funds after a reorg.

Recommended action

Review and merge this fix, then verify that reorg and rescan scenarios correctly demote our_outputs/our_txs rows without deleting them. Consider adding regression tests for reorg handling of these tables.

Security signals we found

01

Incorrect state persistence across blockchain reorgs

02

Missing reorg handling for wallet tables without foreign-key cascade

03

Potential stale spend/confirmation metadata in our_outputs/our_txs

04

Fix runs on every startup rescan, not just real reorgs

Risk score

Why this scored 54/100

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