Undetected double-spent

[ErikDeSmedt]

Describe the bug

1. Alice has an empty wallet
2. Alice receives a transaction (called tx1a) from Bob and observes it in the mempool.
3. Bob double-spends tx1a creating tx1b
4. A block is mined containing tx1b
5. Alice observes tx1b in a block.

Alice will still consider tx1a as a pending transaction.

To Reproduce
See this https://github.com/ErikDeSmedt/bdk-gists/blob/master/tests/wallet.rs

Expected behavior

I would expect that Alice her wallet wouldn't use tx1a anymore. The output

• should not be used for coin-selection
• should not be part of the balance (untrusted_pending)

Build environment

• BDK tag/commit: 1.0.0-beta.5
• OS+version: debian
• Rust/Cargo version: cargo 1.79.0 (ffa9cf99a 2024-06-03)

Additional context

I discovered this bug in a test-case where the entire wallet was unusable.

[ValuedMammal]

tx1b is not discovered on the second sync because it's not "relevant" to alice's wallet, so you'd have to manually insert it similar to tx1a for it to be seen as conflicting (I wonder if this situation is alleviated by using compact block filters).

[ErikDeSmedt]

I've edited the script and applied tx1b manually.

Using wallet.apply_unconfirmed_transaction([tx1b, 101)] doesn't change the state of the wallet. The apply_unconfirmed_transaction also considers tx1b as not "relevant".

Is there any method to remove tx1b from the wallet?

PS: This is related to #1743. I tried to explicitly cancel the transaction as a work-around

[ValuedMammal]

Thanks for sharing the example code. You're right that apply_unconfirmed_txs won't work in the case of tx1b. I think the way to do this currently is to apply an update to alice's wallet containing tx1b with a later timestamp.

    // We also add tx1b to the wallet
    let tx_update = TxUpdate {
        txs: vec![std::sync::Arc::new(tx1b.clone())],
        ..Default::default()
    };
    let update = bdk_wallet::Update {
        tx_update,
        ..Default::default()
    };
    let _ = alice.apply_update_at(update, Some(101)).unwrap();
    
    println!("After applying tx1b");
    println!("- alice.list_unspent(): {:?}", alice.list_unspent().map(|o| o.outpoint).collect::<Vec<_>>());
    println!("- alice.list_transaction(): {:?}", alice.transactions().map(|t| t.tx_node.txid).collect::<Vec<_>>());
    println!("- alice.list_transaction(): {:?}", alice.transactions().map(|t| t.chain_position).collect::<Vec<_>>());
    println!("- alice.balance: {:?}", alice.balance());

    // I expect list_unspent to be empty.
    // (tx1a) was double-spent
    assert_eq!(alice.list_unspent().collect::<Vec<_>>(), vec![]);
    assert_eq!(alice.transactions().collect::<Vec<_>>().len(), 1);
    let tx = alice.transactions().next().unwrap().tx_node;
    assert_eq!(tx.txid, tx1b.compute_txid());

[ValuedMammal]

I'm not sure if that's the ideal solution long term, depending on the use case. One thing that's unclear from the example is whether alice and Bitcoin Core represent distinct entities or if there's reason to think alice should be aware of the other wallet. If so, I can imagine a feature that would let you add extra keychains to the wallet for the purpose of watching other transactions.

I agree that cancel_tx is under-powered and probably requires more engineering of the internals to make sense.

Also I seem to recall that doing a sync via electrum or esplora would allow you to watch for the status of a txid of interest, in this case the unconfirmed tx1a. We have some example code demonstrating this https://github.com/bitcoindevkit/bdk/tree/master/example-crates/example_esplora

*digging deeper it appears for esplora you would actually watch for the spend status of an outpoint of interest, in this case unspent[0]

[ErikDeSmedt]

I discovered the issue when testing the unilateral exit procedure of our Ark implementation. This issue contains a write-up of what the issue is and how it affects us.

However, to my understanding the issue is broader.
If Alice receives a transaction tx1 which is double-spent by an external actor.

• Alice will always have that transaction tx1 in her wallet.
• Alice has no good method to get rid of that Transaction
• If she makes a payment that combines an output from tx1 and a utxo from her own wallet tx2 will be stuck in the wallet. This will actually lock funds that Alice owns