bdk_chain::bitcoin::blockdata::transaction

Function predict_weight

pub fn predict_weight<I, O>(inputs: I, output_script_lens: O) -> Weight
where
    I: IntoIterator<Item = InputWeightPrediction>,
    O: IntoIterator<Item = usize>,
Expand description

Predicts the weight of a to-be-constructed transaction.

This function computes the weight of a transaction which is not fully known. All that is needed is the lengths of scripts and witness elements.

§Arguments

  • inputs - an iterator which returns InputWeightPrediction for each input of the to-be-constructed transaction.
  • output_script_lens - an iterator which returns the length of script_pubkey of each output of the to-be-constructed transaction.

Note that lengths of the scripts and witness elements must be non-serialized, IOW without the preceding compact size. The length of preceding compact size is computed and added inside the function for convenience.

If you have the transaction already constructed (except for signatures) with a dummy value for fee output you can use the return value of Transaction::script_pubkey_lens method directly as the second argument.

§Usage

When signing a transaction one doesn’t know the signature before knowing the transaction fee and the transaction fee is not known before knowing the transaction size which is not known before knowing the signature. This apparent dependency cycle can be broken by knowing the length of the signature without knowing the contents of the signature e.g., we know all Schnorr signatures are 64 bytes long.

Additionally, some protocols may require calculating the amounts before knowing various parts of the transaction (assuming their length is known).

§Notes on integer overflow

Overflows are intentionally not checked because one of the following holds:

  • The transaction is valid (obeys the block size limit) and the code feeds correct values to this function - no overflow can happen.
  • The transaction will be so large it doesn’t fit in the memory - overflow will happen but then the transaction will fail to construct and even if one serialized it on disk directly it’d be invalid anyway so overflow doesn’t matter.
  • The values fed into this function are inconsistent with the actual lengths the transaction will have - the code is already broken and checking overflows doesn’t help. Unfortunately this probably cannot be avoided.