Coin selection includes unconfirmed v3/TRUC outputs in v2 transactions, causing mempool rejection

[luca0x46]

Describe the bug

When a v3 (TRUC) transaction produces a change output back into the BDK wallet, that unconfirmed output enters BDK's UTXO pool like any other coin. Bitcoin Core's TRUC policy (BIP-431) requires that any transaction spending an unconfirmed v3 output must itself be v3. BDK's coin selection is unaware of this constraint and freely includes unconfirmed v3 change outputs when building standard v2 transactions, which bitcoind then rejects with TRUC-violation, non-version=3 tx cannot spend from version=3 tx.

Once the v3 parent confirms, its outputs become ordinary UTXOs spendable by any transaction version — so the issue only manifests while the v3 parent is still in the mempool.

To Reproduce

1. Create and broadcast a v3 (TRUC) transaction that returns change to the BDK wallet (e.g. a CPFP child for an Ark exit).
2. Sync the wallet so BDK sees the unconfirmed v3 change output.
3. Use TxBuilder to build a standard (v2) transaction — BDK's coin selection may pick the unconfirmed v3 output.
4. Sign and broadcast → bitcoind rejects with:
   sendrawtransaction RPC error -26: TRUC-violation, non-version=3 tx <v2_txid> cannot spend from version=3 tx <v3_txid>

Expected behavior

BDK should either:

• Automatically exclude unconfirmed v3 outputs from coin selection when building non-v3 transactions, or
• Expose enough metadata (parent transaction version) for callers to filter them out, or
• Provide a TxBuilder option to exclude UTXOs whose unconfirmed parent is v3

Note: TxBuilder::exclude_unconfirmed (added in 2.1.0) is a partial workaround but too broad — it excludes unconfirmed UTXOs, not just those subject to TRUC rules.

Build environment

• BDK tag/commit: bdk_wallet 2.1.0
• OS+version: macOS 26.3.1 (aarch64)
• Rust/Cargo version: 1.90.0
• Rust/Cargo target: aarch64-apple-darwin

Which backend(s) are relevant (if any)?

• Electrum
• Esplora
• Bitcoin Core RPC
• None / not backend-related (e.g. bdk_chain, bdk_core)
• Other (please specify): ____

Is this blocking production use?

• Yes
• No

Project or organization (optional)

Ark (Second) — during Ark exits, a CPFP child (v3) is broadcast to bump the exit transaction. Its change output lands in the on-chain wallet, and any subsequent on-chain send fails until the CPFP confirms. Exit tx can claimed/secured once the CPFP confirms.

Additional context

Reproduction evidence from signet:

  VTXO exited:  d4c0eb4e49a064c6d8224efe4e384aa9c8f746dc785ba7cfe07c5204560120a3:0
  CPFP child:   77274504eae4eeb0d82af9cee679cad918c67f9b64a40764450ec41caa0c354c
  Change UTXO:  77274504...354c:0 (9723 sat, unconfirmed, v3)
  Failed send:  a7d53ec248ecdd0d264589657ddfa054052e2e4d90e06b99e5d26d4eb0395b74 (non-v3)

  Error: "sendrawtransaction RPC error -26: TRUC-violation, non-version=3 tx a7d53ec2...
         cannot spend from version=3 tx 77274504..."

[luisschwab]

@luca0x46 can you provide a code snippet with the flow you described above?

[luca0x46]

I was running REST API calls to the Bark daemon. The flow was basically creating an exit transaction with a v3, then trying to use the on-chain wallet before the CPFP was confirmed (I had other confirmed UTXOs without being v3 that could be used). Instead of selecting the non-v3, the wallet tried selecting the v3 as it had a similar amount of the tx I tried making. I asked Claude to make a flow of the code snippets from the REST API calls. Let me know if this is what you were expecting or if you would like more context.

1. Start exit — POST /api/v1/exits/start/vtxos

Registers VTXOs for unilateral exit.

// bark-rest/src/api/v1/exits.rs:190
wallet.exit.write().await.start_exit_for_vtxos(&vtxos).await?;

// bark/src/exit/mod.rs:342
pub async fn start_exit_for_vtxos(&mut self, vtxos: &[impl Borrow<Vtxo<Full>>]) -> anyhow::Result<()> {
    for vtxo in vtxos {
        let exit = ExitVtxo::new(vtxo, tip);
        self.persister.store_exit_vtxo_entry(&StoredExit::new(&exit)).await?;
        self.persister.update_vtxo_state_checked(vtxo_id, VtxoState::Spent, ...).await?;
        self.exit_vtxos.push(exit);
    }
}

2. Progress exit — POST /api/v1/exits/progress

Advances each exit by one step. Builds and broadcasts a v3 (TRUC) CPFP child transaction.

// bark-rest/src/api/v1/exits.rs:260
let result = exit.progress_exits(&wallet, &mut *onchain_lock, fee_rate).await?;

// bark/src/exit/mod.rs:437
for ev in self.exit_vtxos.iter_mut() {
    ev.progress(wallet, &mut self.tx_manager, onchain, fee_rate_override, true).await;
}

The CPFP child is built as a v3 transaction with a change output:

// bitcoin-ext/src/bdk.rs:201-207
let mut b = wallet.build_tx();
b.version(3); // v3/TRUC transaction
b.add_fee_anchor_spend(outpoint, txout);
b.drain_to(change_addr.address.script_pubkey()); // ← creates change output
b.fee_absolute(fee_needed);

After broadcast, the unconfirmed v3 change UTXO is stored in BDK's wallet:

// bark/src/exit/progress/states.rs:241-245
let status = ctx.tx_manager.broadcast_package(&*guard).await?;
if matches!(status, TxStatus::Mempool) {
    let tx = &guard.child.as_ref().expect("child can't be missing").info.tx;
    onchain.store_signed_p2a_cpfp(tx).await?;
}

// bark/src/onchain/bdk.rs:213
async fn store_signed_p2a_cpfp(&mut self, tx: &Transaction) -> anyhow::Result<(), CpfpError> {
    self.apply_unconfirmed_txs([(tx.clone(), timestamp_secs())]); // v3 change now in BDK
    Ok(())
}

3. Check status — GET /api/v1/exits/status?transactions=true

Confirms the CPFP child is in the mempool and its change output exists.

// bark-rest/src/api/v1/exits.rs:122
for e in exit.get_exit_vtxos() {
    let status = exit.get_exit_status(e.id(), history, transactions).await?;
    statuses.push(status.into());
}

4. Sync wallet — POST /api/v1/onchain/sync

BDK syncs with the chain source and fully picks up the unconfirmed v3 change UTXO.

// bark/src/onchain/bdk.rs:299
async fn sync(&mut self, chain: &ChainSource) -> anyhow::Result<()> {
    let request = self.inner.start_sync_with_revealed_spks()
        .outpoints(self.list_unspent().iter().map(|o| o.outpoint).collect())
        .txids(self.inner.transactions().map(|tx| tx.tx_node.txid).collect());
    let update = client.sync(request, PARALLEL_REQS).await?;
    self.inner.apply_update(update)?;
}

5. Get address — POST /api/v1/onchain/addresses/next

// bark/src/onchain/bdk.rs:343
let ret = self.inner.reveal_next_address(KeychainKind::External).address;

6. Send — POST /api/v1/onchain/send ← TRUC-violation

BDK builds a regular v2 transaction, coin-selects the unconfirmed v3 change output, and bitcoind rejects it.

// bark/src/onchain/bdk.rs:353
pub async fn send(&mut self, chain: &ChainSource, dest: Address, amount: Amount, fee_rate: FeeRate
) -> anyhow::Result<Txid> {
    let psbt = self.prepare_tx(&[(dest, amount)], fee_rate)?;
    let tx = self.finish_tx(psbt).await?;
    chain.broadcast_tx(&tx).await?; // ← FAILS
    Ok(tx.compute_txid())
}

// bark/src/onchain/bdk.rs:149
fn prepare_tx(&mut self, destinations: &[(Address, Amount)], fee_rate: FeeRate) -> anyhow::Result<Psbt> {
    let mut b = self.deref_mut().build_tx();
    b.ordering(TxOrdering::Untouched);
    for (dest, amount) in destinations {
        b.add_recipient(dest.script_pubkey(), *amount);
    }
    b.fee_rate(fee_rate);
    b.finish().context("error building tx") // ← no v3 awareness, selects v3 UTXO
}

[luca0x46]

Just to be clear, it did not stop the exit from happening. But I could not make transactions while it was unconfirmed.

In another scenario I could make a change in the transaction builder to remove unconfirmed outputs, but I believe bdk wallet should have awareness in coin selection to avoid v3 -> v2 violation.

[oleonardolima]

@luca0x46 Thanks for the detailed issue and explanation! I was able to reproduce the issue through with bdk_wallet, indeed we don't verify all the TRUC (BIP-431) rules.

I was trying to understand the issue, and I think we should fix it in BDK in the step we're filtering the (required/optional) UTXOs that are passed for the CS, and also we'd need to check the vB size rules after that.

I agree that exclude_uncofirmed is not ideal as workaround. If you have the unconfirmed TRUC Outpoint, you could use add_unspendable when creating a V2 transaction instead.

[oleonardolima]

I agree that exclude_uncofirmed is not ideal as workaround. If you have the unconfirmed TRUC Outpoint, you could use add_unspendable when creating a V2 transaction instead.

@luca0x46 If it helps, you can see how I did the workaround here: oleonardolima@a42c61b

[luca0x46]

Hi @oleonardolima thanks for the throughout answer. It seems to be a good workaround. Thank you!