Skip to content

test: prove out-of-order block processing causes stale UTXOs#650

Draft
lklimek wants to merge 1 commit intov0.42-devfrom
test/out-of-order-block-stale-utxo
Draft

test: prove out-of-order block processing causes stale UTXOs#650
lklimek wants to merge 1 commit intov0.42-devfrom
test/out-of-order-block-stale-utxo

Conversation

@lklimek
Copy link
Copy Markdown
Contributor

@lklimek lklimek commented Apr 16, 2026

Summary

  • Adds test_out_of_order_block_processing_stale_utxo to key-wallet-manager proving that out-of-order block processing leaves spent UTXOs in the wallet
  • Test currently fails — it asserts correct behavior (balance=0) which is violated by the bug
  • Both correct-order (H1→H2, passes) and out-of-order (H2→H1, fails) scenarios in one test

The Bug

When compact block filters match multiple blocks and they are downloaded/processed in non-ascending height order, UTXO spends are silently missed:

  1. Block H2 (spending tx) is processed first — no UTXO exists to remove → sent=0
  2. Block H1 (creating tx) is processed second — UTXO is added permanently
  3. The wallet now holds a stale UTXO that was already spent on-chain

Observed in production on Dash testnet: block 1458904 (spending) was processed 48ms before block 1458841 (creating). Trace logs confirmed sent=0 for the spending tx.

Closes #649

Test plan

  • cargo test -p key-wallet-manager test_out_of_order_block_processing_stale_utxo — currently FAILS (proving the bug)
  • After fix: same test should PASS

🤖 Co-authored by Claudius the Magnificent AI Agent

Adds test_out_of_order_block_processing_stale_utxo which demonstrates
that when blocks are processed in non-ascending height order, spent
UTXOs are never removed from the wallet.

Scenario: Block H1 creates a UTXO for our address, block H2 spends it
to an external address. In correct order (H1→H2) the balance returns
to zero. In reverse order (H2→H1) the spending tx finds no UTXO to
remove (sent=0), then the creating tx adds the UTXO permanently.

The test currently FAILS — it asserts the expected correct behavior
(balance=0 after both blocks) which is violated by the bug.

Closes #649

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug: out-of-order block processing causes SPV wallet to miss UTXO spends

1 participant