Why weren’t Inscriptions possible before taproot by just using OP_RETURN to store the data?

Question

With the recent rise of Inscriptions using the script in the taproot input, why wasn't this possible previously just using OP_RETURN? What is special about the taproot upgrade that made this feasible to do?

Answer 1

It may have been possible but it would be more expensive to do so. From Michael Folkson Was the lifting of the Taproot transaction size limit "accidental"? Why would ordinals want to fill a block with OP_RETURNs?

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.

From Pinhead (in the same thread)

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.

Not using OP_RETURN allows the script size to be implicitly limited by the block weight limit. Otherwise you would need to pay for each OP_RETURN on top of the size of the data itself and would be limited by OP_RETURN's maximum script size.

Answer 2

It seems like Pipe is using OP_RETURNs now: https://github.com/BennyTheDev/pipe-specs