Here are some calculations based on the Protocol Documentation.
A Bitcoin Transaction is composed of the following:
- Version (4 Bytes)
- TxIn Count (1 ~ 9B)
- For each TxIn:
- Outpoint (36B)
- Script Length (1 ~ 9B)
- Sequence (4B)
- TxOut Count (1 ~ 9B)
- For each TxOut:
- Value (8B)
- Script Length(1 ~ 9B)*
- Script (?)*
- LockTime (4B)
Assuming a standard P2SH/P2PKH transaction is created, the script length marked in asterisk will be bound to 1byte as the Script Length is encoded as a variable integer; while the script size marked in asterisks will be bound to 24bytes as it will only contain a script hash.
So, in summary, we can assume that the maximum bound of each TxOut to be 34
bytes if we are paying to a P2SH/P2PKH address, since there are 4 opcodes in each output script. A great breakdown can be found here.
Assuming we are spending P2PKH outpoints for our TxIn. Our ScriptSig (composed of a 72byte DER Encoded Transaction Signature + 33byte Public Key) would be 146bytes in size and our script length will only consume 1byte as the size of the ScriptSig is less than 0xFD.
Therefore, a standard P2PKH/P2SH transaction spending a ONE UTXO redeemable with a basic ScriptSig paying to only ONE output is 189bytes. Otherwise, we can also further generalise this to:
in marks the number of TxIns
out marks the number of TxOuts
in < 254 and
out < 254.
Size of P2SH/P2PKH Transaction =
in * 146 +
out * 33 + 10
Computing the size of P2SH/P2PKH transaction that is being funded with complex inputs (i.e. UTXOs spendable with M-of-N signatures, hashed-timelocked contracts) is inherently difficult and is dependent on the complexity of the redeemScript used to produce the scriptHash of the prior P2SH transaction.