Struct bdk_chain::bitcoin::Transaction

pub struct Transaction {
    pub version: Version,
    pub lock_time: LockTime,
    pub input: Vec<TxIn>,
    pub output: Vec<TxOut>,
}

Expand description

Bitcoin transaction.

An authenticated movement of coins.

See Bitcoin Wiki: Transaction for more information.

§Bitcoin Core References

CTtransaction definition

§Serialization notes

If any inputs have nonempty witnesses, the entire transaction is serialized in the post-BIP141 Segwit format which includes a list of witnesses. If all inputs have empty witnesses, the transaction is serialized in the pre-BIP141 format.

There is one major exception to this: to avoid deserialization ambiguity, if the transaction has no inputs, it is serialized in the BIP141 style. Be aware that this differs from the transaction format in PSBT, which never uses BIP141. (Ordinarily there is no conflict, since in PSBT transactions are always unsigned and therefore their inputs have empty witnesses.)

The specific ambiguity is that Segwit uses the flag bytes 0001 where an old serializer would read the number of transaction inputs. The old serializer would interpret this as “no inputs, one output”, which means the transaction is invalid, and simply reject it. Segwit further specifies that this encoding should only be used when some input has a nonempty witness; that is, witness-less transactions should be encoded in the traditional format.

However, in protocols where transactions may legitimately have 0 inputs, e.g. when parties are cooperatively funding a transaction, the “00 means Segwit” heuristic does not work. Since Segwit requires such a transaction be encoded in the original transaction format (since it has no inputs and therefore no input witnesses), a traditionally encoded transaction may have the 0001 Segwit flag in it, which confuses most Segwit parsers including the one in Bitcoin Core.

We therefore deviate from the spec by always using the Segwit witness encoding for 0-input transactions, which results in unambiguously parseable transactions.

§A note on ordering

This type implements Ord, even though it contains a locktime, which is not itself Ord. This was done to simplify applications that may need to hold transactions inside a sorted container. We have ordered the locktimes based on their representation as a u32, which is not a semantically meaningful order, and therefore the ordering on Transaction itself is not semantically meaningful either.

The ordering is, however, consistent with the ordering present in this library before this change, so users should not notice any breakage (here) when transitioning from 0.29 to 0.30.

Fields§

§version: Version

The protocol version, is currently expected to be 1 or 2 (BIP 68).

§lock_time: LockTime

Block height or timestamp. Transaction cannot be included in a block until this height/time.

§Relevant BIPs

§input: Vec<TxIn>

List of transaction inputs.

§output: Vec<TxOut>

List of transaction outputs.

Implementations§

§

impl Transaction

pub const MAX_STANDARD_WEIGHT: Weight = _

Maximum transaction weight for Bitcoin Core 25.0.

pub fn ntxid(&self) -> Hash

👎Deprecated since 0.31.0: ntxid has been renamed to compute_ntxid to note that it’s computationally expensive. use compute_ntxid() instead.

Computes a “normalized TXID” which does not include any signatures.

This method is deprecated. Use compute_ntxid instead.

pub fn compute_ntxid(&self) -> Hash

Computes a “normalized TXID” which does not include any signatures.

This gives a way to identify a transaction that is “the same” as another in the sense of having same inputs and outputs.

pub fn txid(&self) -> Txid

👎Deprecated since 0.31.0: txid has been renamed to compute_txid to note that it’s computationally expensive. use compute_txid() instead.

Computes the Txid.

This method is deprecated. Use compute_txid instead.

pub fn compute_txid(&self) -> Txid

Computes the Txid.

Hashes the transaction excluding the segwit data (i.e. the marker, flag bytes, and the witness fields themselves). For non-segwit transactions which do not have any segwit data, this will be equal to Transaction::compute_wtxid().

pub fn wtxid(&self) -> Wtxid

👎Deprecated since 0.31.0: wtxid has been renamed to compute_wtxid to note that it’s computationally expensive. use compute_wtxid() instead.

Computes the segwit version of the transaction id.

This method is deprecated. Use compute_wtxid instead.

pub fn compute_wtxid(&self) -> Wtxid

Computes the segwit version of the transaction id.

Hashes the transaction including all segwit data (i.e. the marker, flag bytes, and the witness fields themselves). For non-segwit transactions which do not have any segwit data, this will be equal to Transaction::txid().

pub fn weight(&self) -> Weight

Returns the weight of this transaction, as defined by BIP-141.

Transaction weight is defined as Base transaction size * 3 + Total transaction size (ie. the same method as calculating Block weight from Base size and Total size).

For transactions with an empty witness, this is simply the consensus-serialized size times four. For transactions with a witness, this is the non-witness consensus-serialized size multiplied by three plus the with-witness consensus-serialized size.

For transactions with no inputs, this function will return a value 2 less than the actual weight of the serialized transaction. The reason is that zero-input transactions, post-segwit, cannot be unambiguously serialized; we make a choice that adds two extra bytes. For more details see BIP 141 which uses a “input count” of 0x00 as a marker for a Segwit-encoded transaction.

If you need to use 0-input transactions, we strongly recommend you do so using the PSBT API. The unsigned transaction encoded within PSBT is always a non-segwit transaction and can therefore avoid this ambiguity.

pub fn base_size(&self) -> usize

Returns the base transaction size.

Base transaction size is the size of the transaction serialised with the witness data stripped.

pub fn total_size(&self) -> usize

Returns the total transaction size.

Total transaction size is the transaction size in bytes serialized as described in BIP144, including base data and witness data.

pub fn vsize(&self) -> usize

Returns the “virtual size” (vsize) of this transaction.

Will be ceil(weight / 4.0). Note this implements the virtual size as per BIP141, which is different to what is implemented in Bitcoin Core. The computation should be the same for any remotely sane transaction, and a standardness-rule-correct version is available in the policy module.

Virtual transaction size is defined as Transaction weight / 4 (rounded up to the next integer).

pub fn is_coinbase(&self) -> bool

Checks if this is a coinbase transaction.

The first transaction in the block distributes the mining reward and is called the coinbase transaction. It is impossible to check if the transaction is first in the block, so this function checks the structure of the transaction instead - the previous output must be all-zeros (creates satoshis “out of thin air”).

pub fn is_explicitly_rbf(&self) -> bool

Returns true if the transaction itself opted in to be BIP-125-replaceable (RBF).

§Warning

Incorrectly relying on RBF may lead to monetary loss!

This does not cover the case where a transaction becomes replaceable due to ancestors being RBF. Please note that transactions may be replaced even if they do not include the RBF signal: https://bitcoinops.org/en/newsletters/2022/10/19/#transaction-replacement-option.

pub fn is_absolute_timelock_satisfied(&self, height: Height, time: Time) -> bool

Returns true if this Transaction’s absolute timelock is satisfied at height/time.

§Returns

By definition if the lock time is not enabled the transaction’s absolute timelock is considered to be satisfied i.e., there are no timelock constraints restricting this transaction from being mined immediately.

pub fn is_lock_time_enabled(&self) -> bool

Returns true if this transactions nLockTime is enabled (BIP-65).

pub fn script_pubkey_lens(&self) -> impl Iterator<Item = usize>

Returns an iterator over lengths of script_pubkeys in the outputs.

This is useful in combination with predict_weight if you have the transaction already constructed with a dummy value in the fee output which you’ll adjust after calculating the weight.

pub fn total_sigop_cost<S>(&self, spent: S) -> usize
where S: FnMut(&OutPoint) -> Option<TxOut>,

Counts the total number of sigops.

This value is for pre-taproot transactions only.

In taproot, a different mechanism is used. Instead of having a global per-block limit, there is a per-transaction-input limit, proportional to the size of that input. ref: https://bitcoin.stackexchange.com/questions/117356/what-is-sigop-signature-operation#117359

The spent parameter is a closure/function that looks up the output being spent by each input It takes in an OutPoint and returns a TxOut. If you can’t provide this, a placeholder of |_| None can be used. Without access to the previous TxOut, any sigops in a redeemScript (P2SH) as well as any segwit sigops will not be counted for that input.