Struct Transaction

pub struct Transaction {
    pub version: i32,
    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: i32

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 fn 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

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::wtxid().

pub fn 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 encode_signing_data_to<Write, U>( &self, writer: Write, input_index: usize, script_pubkey: &Script, sighash_type: U, ) -> EncodeSigningDataResult<Error>
where Write: Write, U: Into<u32>,

👎Deprecated since 0.30.0: Use SighashCache::legacy_encode_signing_data_to instead

Encodes the signing data from which a signature hash for a given input index with a given sighash flag can be computed.

To actually produce a scriptSig, this hash needs to be run through an ECDSA signer, the [EcdsaSighashType] appended to the resulting sig, and a script written around this, but this is the general (and hard) part.

The sighash_type supports an arbitrary u32 value, instead of just [EcdsaSighashType], because internally 4 bytes are being hashed, even though only the lowest byte is appended to signature in a transaction.

§Warning

Does NOT attempt to support OP_CODESEPARATOR. In general this would require evaluating script_pubkey to determine which separators get evaluated and which don’t, which we don’t have the information to determine.
Does NOT handle the sighash single bug (see “Returns” section)

§Returns

This function can’t handle the SIGHASH_SINGLE bug internally, so it returns EncodeSigningDataResult that must be handled by the caller (see EncodeSigningDataResult::is_sighash_single_bug).

§Panics

If input_index is out of bounds (greater than or equal to self.input.len()).

pub fn signature_hash( &self, input_index: usize, script_pubkey: &Script, sighash_u32: u32, ) -> LegacySighash

👎Deprecated since 0.30.0: Use SighashCache::legacy_signature_hash instead

Computes a signature hash for a given input index with a given sighash flag.

To actually produce a scriptSig, this hash needs to be run through an ECDSA signer, the [EcdsaSighashType] appended to the resulting sig, and a script written around this, but this is the general (and hard) part.

The sighash_type supports an arbitrary u32 value, instead of just [EcdsaSighashType], because internally 4 bytes are being hashed, even though only the lowest byte is appended to signature in a transaction.

This function correctly handles the sighash single bug by returning the ‘one array’. The sighash single bug becomes exploitable when one tries to sign a transaction with SIGHASH_SINGLE and there is not a corresponding output with the same index as the input.

§Warning

Does NOT attempt to support OP_CODESEPARATOR. In general this would require evaluating script_pubkey to determine which separators get evaluated and which don’t, which we don’t have the information to determine.

§Panics

If input_index is out of bounds (greater than or equal to self.input.len()).

pub fn weight(&self) -> Weight

Returns the “weight” of this transaction, as defined by BIP141.

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 size(&self) -> usize

Returns the regular byte-wise consensus-serialized size of this transaction.

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.

pub fn strippedsize(&self) -> usize

Returns the size of this transaction excluding the witness data.

pub fn verify<S>(&self, spent: S) -> Result<(), Error>
where S: FnMut(&OutPoint) -> Option<TxOut>,

Shorthand for Self::verify_with_flags with flag bitcoinconsensus::VERIFY_ALL.

pub fn verify_with_flags<S, F>(&self, spent: S, flags: F) -> Result<(), Error>
where S: FnMut(&OutPoint) -> Option<TxOut>, F: Into<u32>,

Verify that this transaction is able to spend its inputs.

The spent closure should not return the same TxOut twice!

pub fn is_coin_base(&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.