I found this interesting take on Bitcoin transaction type trends from 2015.
As that article is from 2 years ago, I am wondering:
a. Are there any newer transaction types?
b. What is the average size of each of these transactions?
c. Is there a site/way to see the transaction types included in each block?
There are a number of different address formats and other standard transaction types:
Pay to Public Key (P2PK) outputs tie payments directly to the public key of the recipient instead of the derived address. These have been almost completely replaced by P2PKH, although sometimes mining rewards are still paid out to P2PK.
Input¹: 114 B
Output: 44 B (compressed), 76 B (uncompressed)
Multisig transactions were possible by using the corresponding op-code directly in the output script even before P2SH was introduced. Most multisig transactions today are done with P2SH transactions today, though.
Input: variable (depends on m-of-n)
Output: variable (must include all pubkeys)
Pay to Public Key Hash (P2PKH) is today the most commonly used address format. A P2PKH output signs over funds directly to an address derived from a single recipient key.
Input¹: 148 B (compressed), 180 B (uncompressed)
Output: 34 B
Pay to Script Hash (P2SH) was in the past foremost used for multisignature transactions, but any valid redeemscript is allowed. Creative use of P2SH allowed the introduction of backwards-compatible segwit addresses: "Nested Pay to Witness Public Key Hash" (P2SH-PWPKH or NP2WPKH) and "Nested Pay to Script Hash" (P2SH-P2WSH or NP2WSH) can be sent to by any client that can send to P2SH.
Input¹: variable (2-of-3: 297 B, NP2WPKH: 91 vBytes, NP2WSH 2-of-3: 139 vBytes)
Output: 32 B
Pay to Witness Public Key Hash (P2WPKH) is the corresponding native segwit format to P2PKH, making use of a witness program rather than a signature script. P2WPKH addresses are encoded with bech32 instead of base58 meaning that only clients that understand the native segwit format can send to them.
Input¹: 68 vBytes
Output: 31 B
Pay to Witness Script Hash (P2WSH) is the corresponding native segwit format to P2SH, making use of a witness program rather than a redeemscript. P2WSH addresses are encoded with bech32 rather than base58, only updated clients can send to them.
Input¹: variable (2-of-3: 105 vBytes)
Output: 43 B
Pay to Taproot (P2TR) is a native segwit format that combines characteristics of P2PK with P2WSH capabilities. It is also the first output type to make use of Schnorr signatures. The outputs contain a version 1 witness program, and addresses are encoded with bech32m which differs from bech32 in the checksum only. Outputs can be spent either via the keypath, which is akin to P2PK in that only a signature is needed, or via the script path where a branch of the taptree is revealed and the leaf script is satisfied in a similar manners as with P2WSH.
Input: variable (keypath: 57.5 vB, scriptpath 2-of-3²: 82.75 vB–115.5 vB)
Output: 43 B
Null Data (OP_RETURN) transactions are allowed to have a single output that writes up to 83 bytes of data to the blockchain.
Input: N/A
Output: x ≤ 83 + 11(?) bytes
Non-standard transactions encompass any other transactions that don't fit one of the above template. Non-standard transactions will not be relayed by most nodes in the network.
Additionally, transaction overhead adds 10 bytes for non-segwit transactions and 10.5 vbytes for segwit transactons (for numInputs, numOutputs < 256).
overhead = version + numInputs + numOutputs + nLocktime = 4 + 1 + 1 + 4 = 10 bytes
segwit overhead = version + numInputs + numOutputs + nLocktime + marker + flag = 16 + 4 + 4 + 16 + 1 + 1 [weight units] = 42 weight units = 10.5 vbytes
If non-segwit and segwit inputs are mixed, the weight of non-segwit inputs is increased by 1 WU for the empty witness stack that is added.
¹Note that due to the formatting chosen to represent ECDSA signatures in Bitcoin, they have variable size up to 72 bytes with most being 71 bytes or 72 bytes. The given figures above represent the maximum size of the input scripts.
²2-of-3 scriptpath spends have variable input weights depending on whether a MuSig construction is used, there is a single leaf with a 2-of-3 construction, or three 2-of-2 leafs at different depths in the tree. See e.g. https://bitcoin.stackexchange.com/a/96018/5406.
Many of the above formats may produce variable input and output sizes. Generally, the average transaction size has been 514 bytes in the past week. I suspect that this number may be absolute transaction data size and not virtual size, unfortunately blockchain data providers are still lagging behind on properly assessing segwit transactions.
p2sh.info collects a number of statistics on various transaction formats, but as far as I can tell unfortunately not the number of transactions using the respective formats in each block.
transactionfee.info has a number of statistics regarding transactions including use of output types and transaction size.
All size data is provided on a best-effort basis, corrections welcome. Figures with "(?)", I have been unable to corroborate. H/T to Pieter Wuille, Alex Bosworth, Raghav Sood, Sergi Delgado for corrections.
Transaction size may vary by input size, address compression and address type.
so far we have P2PKH (Normal), P2SH-P2WPKH (usually addresses starts with 3), AND native Segwit addresses P2WPKH and P2WSH (bech32).
