<p>There are a number of different address formats and other standard transaction types:</p>
<ul>
<li><p><strong>Pay to Public Key (P2PK)</strong> 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.<br />
Input¹: 114 B<br />
Output: 44 B (compressed), 76 B (uncompressed)</p>
</li>
<li><p><strong>Multisig</strong> 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.<br />
Input:  variable (depends on m-of-n)<br />
Output: variable (must include all pubkeys)</p>
</li>
<li><p><strong>Pay to Public Key Hash (P2PKH)</strong> is today the most commonly used address format. A P2PKH output signs over funds directly to an address derived from a single recipient key.<br />
Input¹: 148 B (compressed), 180 B (uncompressed)<br />
Output: 34 B</p>
</li>
<li><p><strong>Pay to Script Hash (P2SH)</strong> 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: &quot;Nested Pay to Witness Public Key Hash&quot; (P2SH-PWPKH or NP2WPKH) and &quot;Nested Pay to Script Hash&quot; (P2SH-P2WSH or NP2WSH) can be sent to by any client that can send to P2SH.<br />
Input¹: variable (2-of-3: 297 B, NP2WPKH: 91 vBytes, NP2WSH 2-of-3: 139 vBytes)<br />
Output: 32 B</p>
</li>
<li><p><strong>Pay to Witness Public Key Hash (P2WPKH)</strong> 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.<br />
Input¹: 68 vBytes<br />
Output: 31 B</p>
</li>
<li><p><strong>Pay to Witness Script Hash (P2WSH)</strong> 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.<br />
Input¹: variable (2-of-3: 105 vBytes)<br />
Output: 43 B</p>
</li>
<li><p><strong>Pay to Taproot (P2TR)</strong> 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.<br />
Input: <a href="https://bitcoin.stackexchange.com/a/111396/5406">variable</a> (keypath: 57.5 vB, scriptpath 2-of-3²: 82.75 vB–115.5 vB)<br />
Output: 43 B</p>
</li>
<li><p><strong>Null Data</strong> (OP_RETURN) transactions are allowed to have a single output that writes up to 83 bytes of data to the blockchain.<br />
Input: N/A<br />
Output: x ≤ 83 + 11(?) bytes</p>
</li>
<li><p><strong>Non-standard</strong> 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.</p>
</li>
</ul>
<p>Additionally, transaction overhead adds 10 bytes for non-segwit transactions and 10.5 vbytes for segwit transactons (for numInputs, numOutputs &lt; 256).</p>
<pre><code>  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
</code></pre>
<p>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.</p>
<hr />
<p>¹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.</p>
<p>²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. <a href="https://bitcoin.stackexchange.com/a/96018/5406">https://bitcoin.stackexchange.com/a/96018/5406</a>.</p>
<hr />
<p>Many of the above formats may produce variable input and output sizes.
Generally, the average transaction size has been <a href="https://tradeblock.com/bitcoin/historical/1w-f-tsize_per_avg-01101" rel="nofollow noreferrer">514 bytes in the past week</a>. 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.</p>
<p><a href="https://p2sh.info/" rel="nofollow noreferrer">p2sh.info</a> 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.</p>
<p><a href="https://transactionfee.info" rel="nofollow noreferrer">transactionfee.info</a> has a number of statistics regarding transactions including use of output types and <a href="https://transactionfee.info/charts/transactions-sizes/" rel="nofollow noreferrer">transaction size</a>.</p>
<hr />
<p><sup>All size data is provided on a best-effort basis, corrections welcome. Figures with &quot;(?)&quot;, I have been unable to corroborate. H/T to Pieter Wuille, Alex Bosworth, Raghav Sood, Sergi Delgado for corrections.</sup></p>

CC BY-SA 4.0
2018-05-14T05:36:58.480Z
2023-05-24T13:01:37.243Z
2023-05-24T13:01:37.243Z
Murch
<p>Transaction size may vary by input size, address compression and address type.</p>

<p>so far we have <code>P2PKH (Normal)</code>, <code>P2SH-P2WPKH (usually addresses starts with 3)</code>, AND native Segwit addresses <code>P2WPKH and P2WSH</code> (bech32).</p>

CC BY-SA 4.0
2018-01-03T20:30:17.520Z
2018-05-14T04:27:50.043Z
2018-05-14T04:27:50.043Z
Tailer
<p>I found this interesting take on <a href="https://tradeblock.com/blog/analysis-of-bitcoin-transaction-size-trends" rel="noreferrer">Bitcoin transaction type trends from 2015</a>.</p>

<p>As that article is from 2 years ago, I am wondering:</p>

<p>a. Are there any newer transaction types?</p>

<p>b. What is the average size of each of these transactions? </p>

<p>c. Is there a site/way to see the transaction types included in each block? </p>

CC BY-SA 4.0
2019-01-31T12:31:33.340Z
I wrote an article on this https://blog.susanka.eu/types-of-bitcoin-transactions-part-i/
tsusanka
<blockchain><address-format><transaction-weight>
What is the size of different Bitcoin transaction types?
Nona Shah
# What is the size of different Bitcoin transaction types?

(Asked by: username_0 on 2017-12-24)

I found this interesting take on [Bitcoin transaction type trends from 2015](https://tradeblock.com/blog/analysis-of-bitcoin-transaction-size-trends).

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?

**Tags:** blockchain, address-format, transaction-weight

> **Comments:**
> **username_1**: I wrote an article on this https://blog.susanka.eu/types-of-bitcoin-transactions-part-i/  

---

## 2 answers

### Answer by username_2 on 2018-05-14. Score: 15

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](https://bitcoin.stackexchange.com/a/111396/5406) (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](https://tradeblock.com/bitcoin/historical/1w-f-tsize_per_avg-01101). 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](https://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](https://transactionfee.info) has a number of statistics regarding transactions including use of output types and [transaction size](https://transactionfee.info/charts/transactions-sizes/).

---

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.


---

### Answer by username_3 on 2018-01-03. Score: 0

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).


---

