Listed below are some calculations based mostly on the Protocol Documentation.
A Bitcoin Transaction consists of the next:
- Model (4 Bytes)
- TxIn Depend (1 ~ 9B)
- For every TxIn:
- Outpoint (36B)
- Script Size (1 ~ 9B)
- ScriptSig(?)
- Sequence (4B)
- TxOut Depend (1 ~ 9B)
- For every TxOut:
- Worth (8B)
- Script Size(1 ~ 9B)*
- Script (?)*
- LockTime (4B)
Assuming a typical P2SH/P2PKH transaction is created, the script size marked in asterisk will probably be certain to 1byte because the Script Size is encoded as a variable integer; whereas the script dimension marked in asterisks will probably be certain to 24bytes as it’ll solely comprise a script hash.
So, in abstract, we are able to assume that the utmost certain of every TxOut to be 34
bytes if we’re paying to a P2SH/P2PKH tackle, since there are 4 opcodes in every output script. An amazing breakdown will be discovered right here.
Assuming we’re spending P2PKH outpoints for our TxIn. Our ScriptSig (composed of a 72byte DER Encoded Transaction Signature + 33byte Public Key) could be 146bytes in dimension and our script size will solely devour 1byte as the scale of the ScriptSig is lower than 0xFD.
Due to this fact, a typical P2PKH/P2SH transaction spending a ONE UTXO redeemable with a primary ScriptSig paying to solely ONE output is 189bytes. In any other case, we are able to additionally additional generalise this to:
in marks the variety of TxIns
out marks the variety of TxOuts
Assuming that in < 254 and out < 254.
Measurement of P2SH/P2PKH Transaction = in * 146 + out * 33 + 10
Computing the scale of P2SH/P2PKH transaction that’s being funded with advanced inputs (i.e. UTXOs spendable with M-of-N signatures, hashed-timelocked contracts) is inherently tough and relies on the complexity of the redeemScript used to provide the scriptHash of the prior P2SH transaction.