panic (assertion) in try_filter_chain_txouts

[stevenroose]

Describe the bug
I'm hitting this assertion in the tx_graph.rs try_filter_chain_txouts method:

                    assert!(
                        _res.is_none(),
                        "tried to replace {:?} with {:?}",
                        _res,
                        txid
                    );

Is this because one of the txs I made is being double spent?
We are not doing the most innocent bitcoin txs, but we're not doing any weird fiddling with bdk either. Just make a tx and then it gets double spent away on chain. And then the sync procedure panics with this message.

I'm not sure I understand what's going on here or in that method during sync. But it sounds like bdk will crash your program if sync is called while one of your transcations is double spent on-chain or in mempool?

To Reproduce
Not sure it's easy to reproduce. I created a tx that didn't pass mempool checks, and then another tx onchain double spent that tx.

Expected behavior
Sync shouldn't panic if no broken bdk functions were called?

Build environment

• BDK tag/commit: branch based on 0a20724, but assert also present in master
• OS+version: nixos
• Rust/Cargo version: 1.84.0
• Rust/Cargo target: linux

Additional context
n/a

[luisschwab]

Can you share the code you're using to create the transactions?

[evanlinjin]

Looks like you have some inconsistencies in your tx history (i.e. conflicting txs that are both confirmed)...

I think there might be a bug with something you are using to update the wallet. Could you provide more details in this regard?

Or there is something wrong with our canonicalization logic...

[stevenroose]

They can't be both confirmed, but there are double spends possible here, yes. We are hitting this both in our server and client code atm. We use fee anchors to confirm "neutral" txs (they're pre-signed and "owned" by no one, that is to say that multiple parties might want to confirme them). Because the fee anchors are anyone-can-spend, it's possible that two parties are trying to use them to confirm the tx. Eventually one of them will succeed, the other won't. It's also possible that if our tx takes too long to confirm, the just create a new one, double spending our own that adds more fee.

This is how we spend fee anchors: https://codeberg.org/ark-bitcoin/bark/src/commit/b2bc6375421a2a1c4fb41ff0fcb2bddf46e98341/bitcoin-ext/src/bdk.rs#L18-L29

Less relevant, but this is how we construct the CPFP tx to confirm the fee anchor txs: https://codeberg.org/ark-bitcoin/bark/src/commit/b2bc6375421a2a1c4fb41ff0fcb2bddf46e98341/bitcoin-ext/src/bdk.rs#L80-L153

@evanlinjin I am using a branch that has your evicted_at PR backported to v1.0.0.

[stevenroose]

Possibly we are producing double spends ourselves and BDK might not be able to deal with that. Ideally we'd be able to cancel double spent txs ourselves, but that's not supported.

We might just pull all these kinds of txs out of BDK entirely.