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

wallet: route transaction reads/writes through our_txs

Public commit record

What the developer wrote

Authored by Sangbida Chaudhuri

73/100 · Adequate
wallet: route transaction reads/writes through our_txs

Now that the bwatch wallet path records every relevant transaction in
our_txs, point the wallet's transaction readers at that table.

Since our_txs.blockheight is NOT NULL with 0 = unconfirmed, the legacy
NULL handling disappears: wallet_transactions_by_height no longer needs
its "IS NULL vs = ?" query split, and wallet_transaction_height reads
the column unconditionally.

wallet_transaction_add keeps dual-writing the legacy transactions
table: the close path still inserts into channeltxs, whose
transaction_id foreign key points at transactions(id), and
wallet_get_funding_spend joins it. That legacy write can only go away
with channeltxs itself.

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 changes how Core Lightning stores and reads wallet-related transactions. It moves most reads to a new table called our_txs while still keeping the old transactions table updated for compatibility. The main concern is that the code now prevents a confirmed transaction from being downgraded back to unconfirmed, which is good, but the change is part of a larger migration and could introduce subtle bugs if the two tables get out of sync. There is no direct evidence this fixes or introduces a security vulnerability.

Recommended action

Review the dual-write logic for consistency, ensure the anti-downgrade behavior is correct during reorgs, and verify that all callers expecting the legacy transactions table behavior are updated. No immediate security patch appears required based solely on this diff.

Security signals we found

01

Dual-write consistency risk between our_txs and legacy transactions table

02

New anti-downgrade logic for confirmed transactions in our_txs

03

Removal of legacy NULL handling for unconfirmed transactions

04

Change from INSERT OR REPLACE to INSERT ... ON CONFLICT DO NOTHING + conditional UPDATE

05

Legacy transactions table still maintained due to channeltxs foreign key dependency

Risk score

Why this scored 32/100

Our methodology →
Potential impact 8/30
Exploitability 5/25
Stealth signal 4/15
Affected reach 6/15
Confidence 6/10
Evidence quality 3/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.