Struct bdk::wallet::tx_builder::TxBuilder[][src]

pub struct TxBuilder<'a, B, D, Cs, Ctx> { /* fields omitted */ }
Expand description

A transaction builder

A TxBuilder is created by calling build_tx or build_fee_bump on a wallet. After assigning it, you set options on it until finally calling finish to consume the builder and generate the transaction.

Each option setting method on TxBuilder takes and returns &mut self so you can chain calls as in the following example:

// chaining
let (psbt1, details) = {
    let mut builder = wallet.build_tx();
    builder
        .ordering(TxOrdering::Untouched)
        .add_recipient(addr1.script_pubkey(), 50_000)
        .add_recipient(addr2.script_pubkey(), 50_000);
    builder.finish()?
};

// non-chaining
let (psbt2, details) = {
    let mut builder = wallet.build_tx();
    builder.ordering(TxOrdering::Untouched);
    for addr in &[addr1, addr2] {
        builder.add_recipient(addr.script_pubkey(), 50_000);
    }
    builder.finish()?
};

assert_eq!(
    psbt1.global.unsigned_tx.output[..2],
    psbt2.global.unsigned_tx.output[..2]
);

At the moment coin_selection is an exception to the rule as it consumes self. This means it is usually best to call coin_selection on the return value of build_tx before assigning it.

For further examples see this module’s documentation;

Implementations

Set a custom fee rate

Set an absolute fee

Set the policy path to use while creating the transaction for a given keychain.

This method accepts a map where the key is the policy node id (see Policy::id) and the value is the list of the indexes of the items that are intended to be satisfied from the policy node (see SatisfiableItem::Thresh::items).

Example

An example of when the policy path is needed is the following descriptor: wsh(thresh(2,pk(A),sj:and_v(v:pk(B),n:older(6)),snj:and_v(v:pk(C),after(630000)))), derived from the miniscript policy thresh(2,pk(A),and(pk(B),older(6)),and(pk(C),after(630000))). It declares three descriptor fragments, and at the top level it uses thresh() to ensure that at least two of them are satisfied. The individual fragments are:

  1. pk(A)
  2. and(pk(B),older(6))
  3. and(pk(C),after(630000))

When those conditions are combined in pairs, it’s clear that the transaction needs to be created differently depending on how the user intends to satisfy the policy afterwards:

  • If fragments 1 and 2 are used, the transaction will need to use a specific n_sequence in order to spend an OP_CSV branch.
  • If fragments 1 and 3 are used, the transaction will need to use a specific locktime in order to spend an OP_CLTV branch.
  • If fragments 2 and 3 are used, the transaction will need both.

When the spending policy is represented as a tree (see Wallet::policies), every node is assigned a unique identifier that can be used in the policy path to specify which of the node’s children the user intends to satisfy: for instance, assuming the thresh() root node of this example has an id of aabbccdd, the policy path map would look like:

{ "aabbccdd" => [0, 1] }

where the key is the node’s id, and the value is a list of the children that should be used, in no particular order.

If a particularly complex descriptor has multiple ambiguous thresholds in its structure, multiple entries can be added to the map, one for each node that requires an explicit path.

let mut path = BTreeMap::new();
path.insert("aabbccdd".to_string(), vec![0, 1]);

let builder = wallet
    .build_tx()
    .add_recipient(to_address.script_pubkey(), 50_000)
    .policy_path(path, KeychainKind::External);

Add the list of outpoints to the internal list of UTXOs that must be spent.

If an error occurs while adding any of the UTXOs then none of them are added and the error is returned.

These have priority over the “unspendable” utxos, meaning that if a utxo is present both in the “utxos” and the “unspendable” list, it will be spent.

Add a utxo to the internal list of utxos that must be spent

These have priority over the “unspendable” utxos, meaning that if a utxo is present both in the “utxos” and the “unspendable” list, it will be spent.

Add a foreign UTXO i.e. a UTXO not owned by this wallet.

At a minimum to add a foreign UTXO we need:

  1. outpoint: To add it to the raw transaction.
  2. psbt_input: To know the value.
  3. satisfaction_weight: To know how much weight/vbytes the input will add to the transaction for fee calculation.

There are several security concerns about adding foregin UTXOs that application developers should consider. First, how do you know the value of the input is correct? If a non_witness_utxo is provided in the psbt_input then this method implicitly verifies the value by checking it against the transaction. If only a witness_utxo is provided then this method doesn’t verify the value but just takes it as a given – it is up to you to check that whoever sent you the input_psbt was not lying!

Secondly, you must somehow provide satisfaction_weight of the input. Depending on your application it may be important that this be known precisely. If not, a malicious counterparty may fool you into putting in a value that is too low, giving the transaction a lower than expected feerate. They could also fool you into putting a value that is too high causing you to pay a fee that is too high. The party who is broadcasting the transaction can of course check the real input weight matches the expected weight prior to broadcasting.

To guarantee the satisfaction_weight is correct, you can require the party providing the psbt_input provide a miniscript descriptor for the input so you can check it against the script_pubkey and then ask it for the max_satisfaction_weight.

This is an EXPERIMENTAL feature, API and other major changes are expected.

Errors

This method returns errors in the following circumstances:

  1. The psbt_input does not contain a witness_utxo or non_witness_utxo.
  2. The data in non_witness_utxo does not match what is in outpoint.

Note unless you set only_witness_utxo any psbt_input you pass to this method must have non_witness_utxo set otherwise you will get an error when finish is called.

Only spend utxos added by add_utxo.

The wallet will not add additional utxos to the transaction even if they are needed to make the transaction valid.

Replace the internal list of unspendable utxos with a new list

It’s important to note that the “must-be-spent” utxos added with TxBuilder::add_utxo have priority over these. See the docs of the two linked methods for more details.

Add a utxo to the internal list of unspendable utxos

It’s important to note that the “must-be-spent” utxos added with TxBuilder::add_utxo have priority over this. See the docs of the two linked methods for more details.

Sign with a specific sig hash

Use this option very carefully

Choose the ordering for inputs and outputs of the transaction

Use a specific nLockTime while creating the transaction

This can cause conflicts if the wallet’s descriptors contain an “after” (OP_CLTV) operator.

Build a transaction with a specific version

The version should always be greater than 0 and greater than 1 if the wallet’s descriptors contain an “older” (OP_CSV) operator.

Do not spend change outputs

This effectively adds all the change outputs to the “unspendable” list. See TxBuilder::unspendable.

Only spend change outputs

This effectively adds all the non-change outputs to the “unspendable” list. See TxBuilder::unspendable.

Only Fill-in the psbt::Input::witness_utxo field when spending from SegWit descriptors.

This reduces the size of the PSBT, but some signers might reject them due to the lack of the non_witness_utxo.

Fill-in the psbt::Output::redeem_script and psbt::Output::witness_script fields.

This is useful for signers which always require it, like ColdCard hardware wallets.

Fill-in the PSBT_GLOBAL_XPUB field with the extended keys contained in both the external and internal descriptors

This is useful for offline signers that take part to a multisig. Some hardware wallets like BitBox and ColdCard are known to require this.

Spend all the available inputs. This respects filters like TxBuilder::unspendable and the change policy.

Choose the coin selection algorithm

Overrides the DefaultCoinSelectionAlgorithm.

Note that this function consumes the builder and returns it so it is usually best to put this as the first call on the builder.

Finish the building the transaction.

Returns the BIP174 “PSBT” and summary details about the transaction.

Enable signaling RBF

This will use the default nSequence value of 0xFFFFFFFD.

Enable signaling RBF with a specific nSequence value

This can cause conflicts if the wallet’s descriptors contain an “older” (OP_CSV) operator and the given nsequence is lower than the CSV value.

If the nsequence is higher than 0xFFFFFFFD an error will be thrown, since it would not be a valid nSequence to signal RBF.

Replace the recipients already added with a new list

Add a recipient to the internal list

Sets the address to drain excess coins to.

Usually, when there are excess coins they are sent to a change address generated by the wallet. This option replaces the usual change address with an arbitrary script_pubkey of your choosing. Just as with a change output, if the drain output is not needed (the excess coins are too small) it will not be included in the resulting transaction. The only difference is that it is valid to use drain_to without setting any ordinary recipients with add_recipient (but it is perfectly fine to add recipients as well).

When bumping the fees of a transaction made with this option, you probably want to use allow_shrinking to allow this output to be reduced to pay for the extra fees.

Example

drain_to is very useful for draining all the coins in a wallet with drain_wallet to a single address.

let mut tx_builder = wallet.build_tx();

tx_builder
    // Spend all outputs in this wallet.
    .drain_wallet()
    // Send the excess (which is all the coins minus the fee) to this address.
    .drain_to(to_address.script_pubkey())
    .fee_rate(FeeRate::from_sat_per_vb(5.0))
    .enable_rbf();
let (psbt, tx_details) = tx_builder.finish()?;

Explicitly tells the wallet that it is allowed to reduce the fee of the output matching this script_pubkey in order to bump the transaction fee. Without specifying this the wallet will attempt to find a change output to shrink instead.

Note that the output may shrink to below the dust limit and therefore be removed. If it is preserved then it is currently not guaranteed to be in the same position as it was originally.

Returns an Err if script_pubkey can’t be found among the recipients of the transaction we are bumping.

Trait Implementations

Returns a copy of the value. Read more

Performs copy-assignment from source. Read more

Formats the value using the given formatter. Read more

Auto Trait Implementations

Blanket Implementations

Gets the TypeId of self. Read more

Immutably borrows from an owned value. Read more

Mutably borrows from an owned value. Read more

Performs the conversion.

Instruments this type with the provided Span, returning an Instrumented wrapper. Read more

Instruments this type with the current Span, returning an Instrumented wrapper. Read more

Performs the conversion.

The alignment of pointer.

The type for initializers.

Initializes a with the given initializer. Read more

Dereferences the given pointer. Read more

Mutably dereferences the given pointer. Read more

Drops the object pointed to by the given pointer. Read more

Should always be Self

The resulting type after obtaining ownership.

Creates owned data from borrowed data, usually by cloning. Read more

🔬 This is a nightly-only experimental API. (toowned_clone_into)

recently added

Uses borrowed data to replace owned data, usually by cloning. Read more

The type returned in the event of a conversion error.

Performs the conversion.

The type returned in the event of a conversion error.

Performs the conversion.