Redesign `TxBuilder`

[evanlinjin]

Description

We can design a more intuitive transaction-building flow by splitting tx-building into the follow stages:

1. Coin Control
   • Determine which coins can be candidates, and which coins to filter out.
   • Determine coin groups (which coins must be spent together, and which coins must NOT be spent together).
   • Add plan to each coin (from planning module).
2. Coin Selection
   • Select coins for the actual transaction.
   • Determine whether we need a drain output (change policy).
3. Transaction Finalization
   • Formulate unsigned transaction.
   • Reordering/shuffling of inputs/outputs.
4. PSBT Preparation
   • Maps the candidates chosen by coin selection to their plans and uses the plan to create the PSBT input.
   • Maps the outputs (including drain if exists) into the PSBT.
5. Signing

Implementation Details

• For "must be spent together", group them somehow like: Vec<(Plan, TxOut, OutPoint)>.

Related

• Meeting minutes: https://hackmd.io/@evanlinjin/bdk_minutes_20221005
• Old ticket: Implement transaction builder LLFourn/bdk_core_staging#40

[evanlinjin]

@stevenroose mentioned the following to me in a private conversation:

with bdk, it should be easy to say "hey, I have this tx, I want to add inputs from my bdk and sign them"

basically like "fundrawtx" in Core

This is probably something we should keep in mind when redesigning the TxBuilder.

[ValuedMammal]

• An ergonomic design would try to decouple signing a PSBT from finalizing it. Technically the finalizer shouldn't require a descriptor or signing keys, per BIP174. This isn't the case in BDK's finalize_psbt which intends to use descriptor.satisfy(). For more context Question: Finalizing a fully signed PSBT bdk-ffi#469.

• BIP174 states that "All other data except the UTXO and unknown fields in the input key-value map should be cleared from the PSBT," but BDK only partially respects this or treats it as optional (the extra customization could be justified). See finalize_mut for how this might look.