## Finding Description When a reorg occurs, the system marks blocks above the common ancestor as non-canonical via [handle_reorg_events()](https://cantina.xyz/code/ce181972-2b40-4047-8ee9-89ec43527686/core/src/bitcoin_syncer.rs?lines=315,333). However, previously persisted indices—specifically the spent-UTXO records created by [save_transaction_spent_utxos()](https://cantina.xyz/code/ce181972-2b40-4047-8ee9-89ec43527686/core/src/bitcoin_syncer.rs?lines=164,180) and the `txid`→`block` mappings inserted by `insert_txid_to_block`—are not pruned or filtered for canonical status afterward. Read paths like [_get_transaction_spent_utxos()](https://cantina.xyz/code/ce181972-2b40-4047-8ee9-89ec43527686/core/src/bitcoin_syncer.rs?lines=186,195) retrieve spent entries using `db.get_spent_utxos_for_txid()` with no canonical filter, returning results that may originate from blocks that have been reclassified as non-canonical. This allows non-canonical history to leak into consumers that assume canonical-only data: spend tracking, double-spend checks, availability proofs, or any logic that interprets “spent” as an event on the finalized branch. As a result, downstream logic may conclude that UTXOs were spent (or transactions existed) when, in canonical history, they were not, breaking critical chain-consistency invariants. The root cause is the absence of canonical-awareness in both write and read paths for these indices. Non-canonical blocks are marked as such, but their dependent indices are neither removed nor gated by canonical checks during retrieval. The highest-impact scenario is any consensus-adjacent component relying on spent-UTXO or tx→block mappings for canonical correctness: it can produce incorrect proofs or trigger erroneous actions based on non-canonical data. In core/src/bitcoin_syncer.rs the code marks reorged blocks as non-canonical in [handle_reorg_events()](https://cantina.xyz/code/ce181972-2b40-4047-8ee9-89ec43527686/core/src/bitcoin_syncer.rs?lines=315,333) but does not delete or canonical-filter spent-UTXO nor `txid`→`block` mappings written by [save_transaction_spent_utxos()](https://cantina.xyz/code/ce181972-2b40-4047-8ee9-89ec43527686/core/src/bitcoin_syncer.rs?lines=164,180); [_get_transaction_spent_utxos()](https://cantina.xyz/code/ce181972-2b40-4047-8ee9-89ec43527686/core/src/bitcoin_syncer.rs?lines=186,195) reads without a canonical filter. MUST mention function/functions [https://cantina.xyz/code/ce181972-2b40-4047-8ee9-89ec43527686/core/src/bitcoin_syncer.rs?lines=315,333](https://cantina.xyz/code/ce181972-2b40-4047-8ee9-89ec43527686/core/src/bitcoin_syncer.rs?lines=320,332) ```rust function handle_reorg_events() UPDATE bitcoin_syncer SET is_canonical = false WHERE height > $1; // no follow-up DELETE/UPDATE on bitcoin_syncer_spent_utxos or bitcoin_syncer_txs ``` [https://cantina.xyz/code/ce181972-2b40-4047-8ee9-89ec43527686/core/src/bitcoin_syncer.rs?lines=164,180](https://cantina.xyz/code/ce181972-2b40-4047-8ee9-89ec43527686/core/src/bitcoin_syncer.rs?lines=164,180) ```rust async fn save_transaction_spent_utxos( db: &Database, dbtx: DatabaseTransaction<'_, '_>, tx: &bitcoin::Transaction, block_id: u32, ) -> Result<(), BridgeError> { let txid = tx.compute_txid(); db.insert_txid_to_block(dbtx, block_id, &txid).await?; for input in &tx.input { db.insert_spent_utxo( dbtx, block_id, &txid, &input.previous_output.txid, input.previous_output.vout as i64, ) .await?; } Ok(()) } ``` [https://cantina.xyz/code/ce181972-2b40-4047-8ee9-89ec43527686/core/src/bitcoin_syncer.rs?lines=186,195](https://cantina.xyz/code/ce181972-2b40-4047-8ee9-89ec43527686/core/src/bitcoin_syncer.rs?lines=186,195) ```rust async fn _get_transaction_spent_utxos( db: &Database, dbtx: DatabaseTransaction<'_, '_>, txid: bitcoin::Txid, ) -> Result, BridgeError> { let utxos = db.get_spent_utxos_for_txid(Some(dbtx), txid).await?; let utxos = utxos.into_iter().map(|utxo| utxo.1).collect::>(); Ok(utxos) } ``` ## Recommendation Make the indices canon-aware and reorg-safe: Option A (cleanup): Upon reorg in [handle_reorg_events()](https://cantina.xyz/code/ce181972-2b40-4047-8ee9-89ec43527686/core/src/bitcoin_syncer.rs?lines=315,333), delete or flag as non-canonical all `spent_utxo` and `txid_to_block` entries whose `block_id` was marked non-canonical. Option B (read gating): Ensure all read paths (e.g., `db.get_spent_utxos_for_txid()`) filter out non-canonical rows by joining on canonical `block_id`s. This is safer if historical data must be retained for auditing. If the database layer supports canonical filtering, update the read path to enforce it. Otherwise, add cleanup in the reorg handler. Example conceptual diff for adding a canonical filter at read time (illustrative; replace with actual DB API): ```diff --git a/core/src/bitcoin_syncer.rs b/core/src/bitcoin_syncer.rs --- a/core/src/bitcoin_syncer.rs +++ b/core/src/bitcoin_syncer.rs @@ -188,7 +188,12 @@ async fn _get_transaction_spent_utxos( dbtx: DatabaseTransaction<'_, '_>, txid: bitcoin::Txid, ) -> Result, BridgeError> { - let utxos = db.get_spent_utxos_for_txid(Some(dbtx), txid).await?; + // Only consider canonical spent-UTXO records to avoid non-canonical leakage post-reorgs. + let utxos = db + .get_spent_utxos_for_txid_canonical_only(Some(dbtx), txid) + .await?; let utxos = utxos.into_iter().map(|utxo| utxo.1).collect::>(); Ok(utxos) ```

0xnija

Public reviews