<h1>Transaction validity vs standardness*</h1>
<p>A transaction that follows the consensus rules is a valid transaction. However, some extra rules were introduced that are called standardness rules.</p>
<p>Bitcoin nodes only relay (propagate) standard transactions. Thus the only way to mine a valid but non-standard transaction is by arranging it with a miner.</p>
<h1>Bitcoin Transaction Limits</h1>
<h2>Transaction size limit</h2>
<p>The maximum size for legacy (or non-Segwit) transactions is 1 MB, effectively the whole block. The standardness limit, however, is 100 kBs. For Segwit transactions the maximum size limit is 4 MBs  (the weight limit). Again, standardness rules reduce that to 400 kBs.</p>
<p>The minimum size for legacy transactions is 65 bytes.</p>
<h2>Inputs/Outputs limit</h2>
<p>Effectively, as many inputs and outputs as the user wants, provided that it fits in the transaction size limit.</p>
<h1>Bitcoin Script Limits</h1>
<h2>Bare scripts limit</h2>
<p>Bare scripts have a size limit of 10k bytes by consensus. However, standardness rules explicitly specify the kind of locking scripts allowed and the scripts are much smaller (e.g. P2PKH is 25 bytes, P2SH is 23 bytes, etc).</p>
<h2>P2SH scripts limits</h2>
<p>P2SH scripts have a size limit of 10k bytes by consensus. Standardness rules only allow for 520 bytes for the redeem script though, which is enough for a 15-of-15 multisig. The maximum unlocking script (scriptSig) size is 1650 bytes.</p>
<h2>P2WSH (Segwit v0) and P2SH-P2WSH limits</h2>
<p>P2WSH scripts have a size limit of 10k bytes by consensus. Standardness rules only allow for 3600 bytes for the script witness. In addition, only 201 non-push opcodes are allowed per script and only 520 bytes can be pushed per stack element.</p>
<h2>P2TR (Segwit v1) limits</h2>
<p>As P2WSH but the script witness is now limited only by the transaction size (4MBs by consensus and 400kBs by standardness).</p>
<h2>OP_RETURN DATA limit</h2>
<p>The consensus rules have no limit to an OP_RETURN size, i.e. the size of the transaction is the limit. One can also have more than one OP_RETURN in a transaction. However, standardness rules specify that only one OP_RETURN output is allowed per transaction with a maximum data size of 80 bytes.</p>
<p>*EDIT: Specific miners can also apply local policy rules in addition to the consensus rules. Since these are custom configurable rules they are not list here but a list of potential policy rules can be found at <a href="https://github.com/bitcoin/bitcoin/tree/master/doc/policy" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/tree/master/doc/policy</a></p>

CC BY-SA 4.0
2023-03-16T10:10:21.773Z
By default all Bitcoin Core nodes enforce the policy limits, it's not specific to miners. Some standardness limits can also be configured, it's not specific to policy limits. Also i think there are a couple mistakes / misses in your standardness limits list. I'll try to compile a list later today if nobody else beat me to it.
Antoine Poinsot
CC BY-SA 4.0
2023-03-16T11:05:50.977Z
But if miners don't have them then the limits are moot.. they won't be included in the block so it's still up to them, no? I am aware of some of the misses which I didn't include as it would require further explanation of some concepts. But please, I'd appreciate any fixes and/or a more complete list!
karask
CC BY-SA 4.0
2023-03-16T07:29:01.237Z
2023-03-16T10:04:49.897Z
2023-03-16T10:04:49.897Z
karask
<p>What are the limits of different transactions and scripts (by consensus and standardness)?</p>
<p>Some stack exchange questions discuss some of them (but not all) and all these are scattered around.</p>
<p>What is a summary with basic information about such limits? Or is there a resource I could consult that has such a summary?</p>

CC BY-SA 4.0
2023-03-16T08:53:51.113Z
Are you interested only in standardness, or also "policy" limits? As in standardness being static and policy depending on context. If the latter there is a (non-exhaustive) list of them here https://github.com/bitcoin/bitcoin/tree/master/doc/policy.
Antoine Poinsot
CC BY-SA 4.0
2023-03-16T09:58:41.753Z
Not that much interested in policy limits but definitely worth mentioning it for the benefit of others! Thanks for the comment.
karask
<transactions><script><consensus><non-standard-transaction>
What are Bitcoin's transaction and script limits?
karask
# What are Bitcoin's transaction and script limits?

(Asked by: username_0 on 2023-03-16)

What are the limits of different transactions and scripts (by consensus and standardness)?

Some stack exchange questions discuss some of them (but not all) and all these are scattered around.

What is a summary with basic information about such limits? Or is there a resource I could consult that has such a summary?

**Tags:** transactions, script, consensus, non-standard-transaction

> **Comments:**
> **username_1**: Are you interested only in standardness, or also "policy" limits? As in standardness being static and policy depending on context. If the latter there is a (non-exhaustive) list of them here https://github.com/bitcoin/bitcoin/tree/master/doc/policy.  
> **username_0**: Not that much interested in policy limits but definitely worth mentioning it for the benefit of others! Thanks for the comment.  

---

## 1 answers

### Answer by username_0 on 2023-03-16. Score: 2

# Transaction validity vs standardness\*

A transaction that follows the consensus rules is a valid transaction. However, some extra rules were introduced that are called standardness rules.

Bitcoin nodes only relay (propagate) standard transactions. Thus the only way to mine a valid but non-standard transaction is by arranging it with a miner.

# Bitcoin Transaction Limits

## Transaction size limit

The maximum size for legacy (or non-Segwit) transactions is 1 MB, effectively the whole block. The standardness limit, however, is 100 kBs. For Segwit transactions the maximum size limit is 4 MBs (the weight limit). Again, standardness rules reduce that to 400 kBs.

The minimum size for legacy transactions is 65 bytes.

## Inputs/Outputs limit

Effectively, as many inputs and outputs as the user wants, provided that it fits in the transaction size limit.

# Bitcoin Script Limits

## Bare scripts limit

Bare scripts have a size limit of 10k bytes by consensus. However, standardness rules explicitly specify the kind of locking scripts allowed and the scripts are much smaller (e.g. P2PKH is 25 bytes, P2SH is 23 bytes, etc).

## P2SH scripts limits

P2SH scripts have a size limit of 10k bytes by consensus. Standardness rules only allow for 520 bytes for the redeem script though, which is enough for a 15-of-15 multisig. The maximum unlocking script (scriptSig) size is 1650 bytes.

## P2WSH (Segwit v0) and P2SH-P2WSH limits

P2WSH scripts have a size limit of 10k bytes by consensus. Standardness rules only allow for 3600 bytes for the script witness. In addition, only 201 non-push opcodes are allowed per script and only 520 bytes can be pushed per stack element.

## P2TR (Segwit v1) limits

As P2WSH but the script witness is now limited only by the transaction size (4MBs by consensus and 400kBs by standardness).

## OP\_RETURN DATA limit

The consensus rules have no limit to an OP\_RETURN size, i.e. the size of the transaction is the limit. One can also have more than one OP\_RETURN in a transaction. However, standardness rules specify that only one OP\_RETURN output is allowed per transaction with a maximum data size of 80 bytes.

\*EDIT: Specific miners can also apply local policy rules in addition to the consensus rules. Since these are custom configurable rules they are not list here but a list of potential policy rules can be found at <https://github.com/bitcoin/bitcoin/tree/master/doc/policy>

> **Comments:**
> **username_1**: By default all Bitcoin Core nodes enforce the policy limits, it's not specific to miners. Some standardness limits can also be configured, it's not specific to policy limits. Also i think there are a couple mistakes / misses in your standardness limits list. I'll try to compile a list later today if nobody else beat me to it.  
> **username_0**: But if miners don't have them then the limits are moot.. they won't be included in the block so it's still up to them, no? I am aware of some of the misses which I didn't include as it would require further explanation of some concepts. But please, I'd appreciate any fixes and/or a more complete list!  

---

