<blockquote>
<p>The previous transaction size limit (pre Taproot) was deliberately relaxed though I can't (yet) find links to historical discussion on whether to relax it or not.</p>
</blockquote>
<p>This was <a href="https://twitter.com/remyers_/status/1618650430803968001?s=20&amp;t=a8r1tOLGLqM4ehEVpv6wYQ" rel="nofollow noreferrer">addressed</a> on Twitter by Richard Myers.</p>
<blockquote>
<p>In fact, the lower (500,000) witness size limit was apparently an oversight in segwit fixed by taproot.  The true protection is the standardness rule which only allows tx's smaller than MAX_STANDARD_TX_WEIGHT to be relayed.</p>
</blockquote>
<p>A relevant comment in the Bitcoin Core codebase is <a href="https://github.com/bitcoin/bitcoin/blob/e9262ea32a6e1d364fb7974844fadc36f931f8c6/src/policy/policy.cpp#L101" rel="nofollow noreferrer">here</a>.</p>
<blockquote>
<p>Is there a reason Ordinals or NFTs would need multiple OP_RETURNs in a single transaction?</p>
</blockquote>
<p>This was answered on <a href="https://twitter.com/louneskmt/status/1618610926537830400?s=20&amp;t=CmFZsJW5qB45VuT4MCrf2g" rel="nofollow noreferrer">Twitter</a> by louneskmt.</p>
<blockquote>
<p>Ordinals don't use OP_RETURN, but push a script in the witness
directly.</p>
<p>OP_FALSE OP_IF &lt;push protocol / media data with multiple OP_PUSH&gt;
OP_ENDIF</p>
<p>Bitcoin isn't here used as an anchor layer, but as a storage layer as
arbitrary data conserved in the witness of a tx.</p>
</blockquote>

CC BY-SA 4.0
2023-01-26T20:35:17.217Z
In Casey's naming, an "envelope"...
Mercedes
CC BY-SA 4.0
2023-01-29T06:56:54.557Z
Michael, I think the correct link for Richard Myers twit is https://twitter.com/remyers_/status/1618650430803968001
bordalix
CC BY-SA 4.0
2023-01-29T10:22:52.320Z
Related: [What is the maximum size of a Bitcoin transaction](https://bitcoin.stackexchange.com/q/1823/13866)
RedGrittyBrick
CC BY-SA 4.0
2023-01-29T22:06:40.790Z
@bordalix: Good spot, thanks.
Michael Folkson
CC BY-SA 4.0
2023-05-08T15:59:00.540Z
Was storing data with OP_FALSE OP_IF <data> OP_ENDIF scripts not possible before taproot as p2wsh?
DeLorean88
CC BY-SA 4.0
2023-01-26T14:21:23.067Z
2023-01-29T22:06:01.087Z
2023-01-29T22:06:01.087Z
Michael Folkson
<p>No it was not accidental, see the <a href="https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#user-content-Resource_limits" rel="noreferrer">BIP342 section on Resource Limits</a></p>
<blockquote>
<p>Script size limit: The maximum script size of 10000 bytes does not apply. Their size is only implicitly bounded by the block weight limit.[9]</p>
</blockquote>
<p>and the rationale explained in the footnote:</p>
<blockquote>
<p>Why is a limit on script size no longer needed? Since there is no scriptCode directly included in the signature hash (only indirectly through a precomputable tapleaf hash), the CPU time spent on a signature check is no longer proportional to the size of the script being executed. The maximum script size of 10000 bytes does not apply. Their size is only implicitly bounded by the block weight limit.[9]</p>
</blockquote>

CC BY-SA 4.0
2023-03-01T19:21:01.697Z
2023-03-01T19:21:01.697Z
pinhead
<p>I was reading this Twitter <a href="https://twitter.com/pourteaux/status/1618364013712375810?s=20&amp;t=5_n1jPryZQbEoirs89l2tg" rel="noreferrer">thread</a> from pourteaux. I'm pretty sure there are some inaccuracies in it but I have a couple of questions.</p>
<p>He states:</p>
<blockquote>
<p>Taproot accidentally blew up the old transaction size limit in OP_RETURN</p>
</blockquote>
<p>It wasn't <strong>accidental</strong> at all from what I understand. The previous transaction size limit (pre Taproot) was deliberately relaxed though I can't (yet) find links to historical discussion on whether to relax it or not.</p>
<blockquote>
<p>In the past, arbitrary data was limited to 80 bytes via OP_RETURN, but with this quirk of Taproot you could take up <em>an entire 4MB block</em> with just one NFT transaction.</p>
</blockquote>
<p>The <code>OP_RETURN</code> data limit in a single output remains post Taproot. It is just now with no transaction size limit you could (if you were willing to pay sufficient fee) fill an entire block with a single transaction with many <code>OP_RETURN</code> outputs?</p>
<p>Is there a reason Ordinals or NFTs would need multiple <code>OP_RETURN</code>s in a single transaction? I was under the impression that a single <code>OP_RETURN</code> was sufficient for these use cases as you can effectively embed a Merkle tree root in the <code>OP_RETURN</code>? I'm unsure why these use cases would want to pay the transaction fee(s) to fill blocks with <code>OP_RETURN</code> outputs.</p>

CC BY-SA 4.0
2023-01-26T14:48:29.873Z
related: https://bitcoin.stackexchange.com/q/116875/5406
Murch
<taproot><op-return><blocksize><ordinals>
Was the lifting of the Taproot transaction size limit "accidental"? Why would ordinals want to fill a block with OP_RETURNs?
Michael Folkson
# Was the lifting of the Taproot transaction size limit "accidental"? Why would ordinals want to fill a block with OP_RETURNs?

(Asked by: username_0 on 2023-01-26)

I was reading this Twitter [thread](https://twitter.com/pourteaux/status/1618364013712375810?s=20&t=5_n1jPryZQbEoirs89l2tg) from pourteaux. I'm pretty sure there are some inaccuracies in it but I have a couple of questions.

He states:

> Taproot accidentally blew up the old transaction size limit in OP\_RETURN

It wasn't **accidental** at all from what I understand. The previous transaction size limit (pre Taproot) was deliberately relaxed though I can't (yet) find links to historical discussion on whether to relax it or not.

> In the past, arbitrary data was limited to 80 bytes via OP\_RETURN, but with this quirk of Taproot you could take up *an entire 4MB block* with just one NFT transaction.

The `OP_RETURN` data limit in a single output remains post Taproot. It is just now with no transaction size limit you could (if you were willing to pay sufficient fee) fill an entire block with a single transaction with many `OP_RETURN` outputs?

Is there a reason Ordinals or NFTs would need multiple `OP_RETURN`s in a single transaction? I was under the impression that a single `OP_RETURN` was sufficient for these use cases as you can effectively embed a Merkle tree root in the `OP_RETURN`? I'm unsure why these use cases would want to pay the transaction fee(s) to fill blocks with `OP_RETURN` outputs.

**Tags:** taproot, op-return, blocksize, ordinals

> **Comments:**
> **username_1**: related: https://bitcoin.stackexchange.com/q/116875/5406  

---

## 2 answers

### Answer by username_6 on 2023-03-01. Score: 5 | Accepted answer

No it was not accidental, see the [BIP342 section on Resource Limits](https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#user-content-Resource_limits)

> Script size limit: The maximum script size of 10000 bytes does not apply. Their size is only implicitly bounded by the block weight limit.[9]

and the rationale explained in the footnote:

> Why is a limit on script size no longer needed? Since there is no scriptCode directly included in the signature hash (only indirectly through a precomputable tapleaf hash), the CPU time spent on a signature check is no longer proportional to the size of the script being executed. The maximum script size of 10000 bytes does not apply. Their size is only implicitly bounded by the block weight limit.[9]


---

### Answer by username_0 on 2023-01-26. Score: 3

> The previous transaction size limit (pre Taproot) was deliberately relaxed though I can't (yet) find links to historical discussion on whether to relax it or not.

This was [addressed](https://twitter.com/remyers_/status/1618650430803968001?s=20&t=a8r1tOLGLqM4ehEVpv6wYQ) on Twitter by Richard Myers.

> In fact, the lower (500,000) witness size limit was apparently an oversight in segwit fixed by taproot. The true protection is the standardness rule which only allows tx's smaller than MAX\_STANDARD\_TX\_WEIGHT to be relayed.

A relevant comment in the Bitcoin Core codebase is [here](https://github.com/bitcoin/bitcoin/blob/e9262ea32a6e1d364fb7974844fadc36f931f8c6/src/policy/policy.cpp#L101).

> Is there a reason Ordinals or NFTs would need multiple OP\_RETURNs in a single transaction?

This was answered on [Twitter](https://twitter.com/louneskmt/status/1618610926537830400?s=20&t=CmFZsJW5qB45VuT4MCrf2g) by louneskmt.

> Ordinals don't use OP\_RETURN, but push a script in the witness
> directly.
>
> OP\_FALSE OP\_IF <push protocol / media data with multiple OP\_PUSH>
> OP\_ENDIF
>
> Bitcoin isn't here used as an anchor layer, but as a storage layer as
> arbitrary data conserved in the witness of a tx.

> **Comments:**
> **username_2**: In Casey's naming, an "envelope"...  
> **username_3**: username_0, I think the correct link for Richard Myers twit is https://twitter.com/remyers_/status/1618650430803968001  
> **username_4**: Related: [What is the maximum size of a Bitcoin transaction](https://bitcoin.stackexchange.com/q/1823/13866)  
> **username_0**: @username_3: Good spot, thanks.  
> **username_5**: Was storing data with OP_FALSE OP_IF <data> OP_ENDIF scripts not possible before taproot as p2wsh?  

---

