Was the lifting of the Taproot transaction size limit "accidental"? Why would ordinals want to fill a block with OP_RETURNs?

Question

I was reading this Twitter thread 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_RETURNs 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.

Answer 1

No it was not accidental, see the BIP342 section on 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 2

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

Is there a reason Ordinals or NFTs would need multiple OP_RETURNs in a single transaction?

This was answered on Twitter 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.