Post
Topic
Board Development & Technical Discussion
Re: Removing OP_return limits is a huge mistake
by
d5000
on 03/05/2025, 23:10:56 UTC
But even if we thought that making it more expensive for them would be useful it has to be balanced against what it costs.   Having some developer going around playing wack-a-mole blocking stuff that isn't perfectly immitating ordinary transactions is a huge liability.
I wasn't referring here to the heuristic methods the "ordinal blocker" camp was trying to implement e.g. in Bitcoin Knots. I think such methods are ineffective as it could become a cat and mouse game between the Ordinals devs and the Core/Knots devs, and I agree with you about the costs such a "hardcoded" ordinal blocking method would generate. My remark was more general, for example one could think about a size limit that could be applied to Taproot witnesses.

The more I think about it however I guess that finding such methods is next to impossible without significant collateral damage to "financial" use cases and that's not worth it. An extreme example: In the height of the Ordinals discussions, some have mentioned Grin's transaction format, which indeed would make inscriptions very expensive because only a few bytes per transaction can be selected in an "arbitrary" manner. Of course this format makes "useful" scripting (Lightning and friends) very difficult or impossible.

And of course what you write about the economics of the Ordinals "inscribers" is correct, the cost isn't really that important. Winning the attention game is the important thing here (see also below).

From another of your answers I think I'm understanding the intent behind the proposed deletion of the code related to the datacarrier size a bit better, and I may thus be considering switching my stance related to the PR to ACK (still a layman ACK of course, heh).

- Above certain size (~150bytes) [1], it is claimed it's cheaper to abuse witness exploit so not sure why you're so sure that ppl with malicious intent to embed large jpegs/data will switch to using OP_RETURN.
That claim was actually made by me so I'm answering here. It's of course a speculative answer, as everything we can say about the future.

Currently we have three main methods to stuff data into the blockchain: Inscriptions ("witness exploit"), Fake adresses, and OP_RETURN. While the witness exploit is the cheapest, it has the disadvantage that it's a bit complex, above all because you need two transactions (in most cases) to inscribe the NFT (and in the case of BRC-20, which caused the fees to explode in 2023, you even need two transactions per transfer).

For the Ordinals fad, it's not much that can be done, it has already done a (small) bit of harm but is probably fading away, see also the post from gmaxwell I reference above and my answer.

However, the creators of future fads would have these three methods to select from. Maybe if OP_RETURN limits are in place, they would instead try to create a Stampchain fad. Fads also have often to be novel to work, so they would probably try to dismiss Ordinals as something old and outdated.

Maybe there is also an indirect effect which could make spam levels decrease if OP_RETURN limits are lifted: new protocols trying to benefit from this change could emerge, and they would enter into competition with Ordinals and Stampchain-style "fake address" methods. That could generate "noise" in the NFT community, i.e. there would not be longer a dominating method which captures all the attention as it was the case in 2023 with Ordinals. Such a situation could be compared with the situation in 2013-15 when the first NFT/token protocols on Bitcoin were implemented, there were several systems in competition (Mastercoin/Omni and Counterparty, mainly); none of them "won" the "battle" decisively, and eventually they both faded away, at least none of them created any significant congestion or fee spike.

The Ordinals fad imo however was as successful as it was not because the Taproot method was cheaper than Counterparty and other older methods, but because they were able to sell it as an "unique" or "best" method to store data on the Bitcoin chain. I think many of the BRC-20 folks really believed that this was the first and best method to implement ERC-20 style tokens on Bitcoin, when it's in fact one of the most inefficient mechanics and even the older methods are better in many ways.