Spending P2A Output with a Non-Zero Value can Return CreateTxError::CoinSelection

[PeteClubSeven]

Describe the bug
We use BDK as our onchain wallet for the Bark project, an important part of that is using BDK to spend P2A outputs when users perform an emergency exit. Each "exit transaction" contains a P2A output, typically with a value of zero sats, but sometimes with a non-zero value due to how we manage fees for certain operations. When the P2A value is zero there's no problem, however when it's non-zero you can run into edge cases which result in unexpected errors.

Here's an example scenario:

• The wallet has 1 UTXO of 1,000,000 sats
• We try to create a new transaction to spend the P2A output of an exit transaction which isn't contained in the wallet itself
• We add a drain_to address which is the BDK wallet
• We set absolute_fee to 200 sats (enough to broadcast the exit transaction and the transaction we're constructing as a TRUC package)
• If the P2A output has a value of 0:
  • BDK will pull in the 1,000,000 sat UTXO and drain to a wallet address with a 999,800 sat output
  • This is as expected
• If the P2A output has a value of 1,000:
  • BDK won't use any extra UTXOs and will drain to a wallet address with a 800 sat output
  • This is as expected
• If the P2A output has a value of 500:
  • BDK won't use any extra UTXOs and will error because it can't create a 300 sat output as that is below the dust limit
  • This is not as expected
• If the P2A output has a value of 200:
  • BDK won't use any extra UTXOs and will error because the remaining value is 0 and it enforces the use of at least 1 TxOut even when draining
  • This is not as expected

Expected behavior
The documentation for fee_absolute states the following:

Note that this is really a minimum absolute fee -- it's possible to overshoot it slightly since adding a change output to drain the remaining excess might not be viable.

Under that assumption I would expect that when spending a P2A output which results in zero or dust change, the entire P2A value should be consumed and no output should be created. If BDK mandates there always being at least 1 TxOut, then I would expect the transaction builder to pull in the extra UTXO to drain to a non-dust output.

Build environment

• BDK tag/commit: 2.3.0
• OS+version: macOS 26.2
• Rust/Cargo version: 1.90
• Rust/Cargo target: aarch64-apple-darwin

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

• Esplora
• Bitcoin Core RPC

Is this blocking production use?

• No: We work around it by trying to detect this problem and increase the fee amount to force 1 sat to be used from another UTXO

Project or organization (optional)
Bark

Additional context
This is the source code for where we encounter this issue.

[stevenroose]

Hmm, I guess the semantics of "drain to" are kinda sound here as you're not draining anything rational in the cases that it refuses. Instead here our objective is to actually force it to create a child tx and the "drain to" is just used to make sure that all left-over goes back to us. Semantically it sounds like we'd need a "force tx even if uneconomical [to drain]", but practically it could just be regular "add an input if otherwise change would be dust" behavior?

[ValuedMammal]

question: Are you using the default coin selection algo (BnB) or something else?

I looked at this and it seems the fix would involve checking if the excess is dust and if so continue selecting from the available coins, but only if not doing so would result in a 0-output tx (which is unviable).

However the implementation is non-trivial because we don't always need to force selection of additional inputs if the selection is enough to fund the outputs. But coin selection doesn't know which recipients were explicitly added, if any - it only tries to fund a target amount. In your case you have no recipients and instead rely on the drain output to carry the excess.

For now a simple solution is to have some app-defined threshold (say 1000 sat) under which you force selection of the onchain reserve (1M sat) using add_utxo or drain_wallet or something.

[PeteClubSeven]

question: Are you using the default coin selection algo (BnB) or something else?

I looked at this and it seems the fix would involve checking if the excess is dust and if so continue selecting from the available coins, but only if not doing so would result in a 0-output tx (which is unviable).

However the implementation is non-trivial because we don't always need to force selection of additional inputs if the selection is enough to fund the outputs. But coin selection doesn't know which recipients were explicitly added, if any - it only tries to fund a target amount. In your case you have no recipients and instead rely on the drain output to carry the excess.

For now a simple solution is to have some app-defined threshold (say 1000 sat) under which you force selection of the onchain reserve (1M sat) using add_utxo or drain_wallet or something.

We do use the default coin selection algorithm yes. It's worth noting that while we use drain_to, we don't use the change keychain so from my reading of the code it looked like this would count as a recipient. The workaround I currently implemented is to detect when the P2A output would result in a dust output and increase the required fee to force the transaction builder to pull in an extra UTXO from the wallet.

[ValuedMammal]

By recipient I mean those that were explicitly added using TxBuilder::add_recipient. That's distinct from the drain output which is added dynamically. You could also set a recipient (using a wallet owned address) with an amount greater than the p2a value, and that'll necessarily require selecting additional coins.