If you were on Nostr or Bitcoin x today, you may have noticed some stirrings in the OP_RETURN debate. Recently @petertodd opened a pr to remove limits on OP_RETURN outputs.
To preface this, for those not aware, "OP_RETURN is a script opcode in the Bitcoin protocol that allows a transaction to store arbitrary data on the blockchain. It is a way to embed data, such as text, images, or other types of information, into a Bitcoin transaction."1
To my understanding, it is this opcode that allows for ordinals.
In a recent bitcoindevs mailing list discussion, "Relax OP_RETURN Standardness Restrictions", a few heavy hitting bitcoin core devs, besides Todd, throw their weight around re OP_RETURN (pertinent quotes and a summary of their positions to follow).
Honestly, when I read this, and see the staunch oppositions, it feels like mom and dad are fighting. I am powerless and must be content to understand but little of what is actually happening. Perhaps they both want what's best for me, although, they clearly have differing points of view.
In sum, many of the devs contributing to the discussion support dropping the OP_RETURN limits, which has raised concern.2
At any rate, I used AI to help me understand better so you don't have to.
A summary of their positions
Antoine Poinsot proposes relaxing the restrictions on OP_RETURN outputs to stop encouraging harmful behavior and allow more flexible use of the blockchain.:
Since the restrictions on the usage of OP_RETURN outputs encourage harmful practices while being ineffective in deterring unwanted usage, i propose to drop them.
Sjors Provoost suggests dropping both the size limit and the limit on the number of OP_RETURN outputs per transaction to avoid repeating the discussion in the future.:
Increasing the OP_RETURN limit reduces harm compared to the two alternatives: 1. UTXO set bloating with fake public keys 2. Large scale bypassing of the (default) mempool...
Peter Todd agrees with dropping both limits at the same time.
I would suggest removing both limits at the same time. While multiple OP_Return outputs are more expensive than a single one for the same amount of total data. In some cases they're necessary for technical reasons, e.g. if signing with SIGHASH_SINGLE.
Pieter Wuille conceptually acknowledges (ACK) relaxing the OP_RETURN limits, including removing them entirely, due to the existing demand for such transactions and the potential for pushing that demand to bypass the public network.
Concept ACK on relaxing the OP_RETURN limits, including removing them entirely... I recognize the reality that demand exists, and the alternative of pushing that demand to bypass the public network is far more damaging.
Luke Dash Jr strongly opposes the idea, citing concerns about spam and abuse, and suggests that the bugs should be fixed rather than embracing the abuse.
It should be needless to say, but this idea is utter insanity... The bugs should be fixed, not the abuse embraced.
Antoine Riard mentions a potential downside of relaxing OP_RETURN restrictions, where a single transaction output with an "exogeneous" value could be worth more than the block reward, potentially leading to issues with double-spends and chain reorganizations.:
That could be an issue where a single transaction output owner with an 'exogeneous' value braodcast a tx for a double-spend where this condition can only be included if the block is reorged-out...
Vojtěch Strnad references a stack exchange post that explains his reasoning for how OP_RETURN restrictions are not effective in deterring unwanted usage.
Sjors Provoost and Pieter Wuille discuss the potential consequences of pushing demand for transactions to bypass the public network, including centralization and the loss of permissionlessness.
Footnotes
-
Written with the help of MapleAI ↩
OP_RETURNis not usable for ordinals because the outputs are unspendable. So you cant transfer that rare numbered sat because it will error out when you try. What this allows is inscription of data other than transactional data, without needing the script interpreter (it basically errors out on the first byte of the script, which isOP_RETURNitself)libbitcoinindexes them but even if, would be easy to prune them if you don't need them.