Post
Topic
Board Development & Technical Discussion
Merits 4 from 1 user
Re: Removing OP_return limits seems like a huge mistake
by
ABCbits
on 19/05/2025, 09:48:37 UTC
⭐ Merited by mikeywith (4)
As for Ocean, last I checked, I believe they were using the Knots template, which filters out inscriptions and limits OP_RETURN data to 42 bytes. I believe the reasoning behind 42 bytes is that it should fit data commitments, which are 32 bytes. Not sure what the remaining 10 is for--maybe for a 10-byte identifier or just a random number Luke pulled while reading the Bible, which he inscribed into the very blockchain he's now trying to keep clean. Grin


Isn't it because 42 bytes was old limit OP_RETURN that considered as part of standard TX? And i'm sure 2 of 42 bytes is overhead for OPCODES that specify size of data to be pushed.

As for Ocean, last I checked, I believe they were using the Knots template, which filters out inscriptions and limits OP_RETURN data to 42 bytes.
Stampchain uses 34 bytes seemingly for metadata in OP_RETURN, but the rest of the data is stuffed into fake public keys / scripts. See this earlier post.

So no, I don't think it "does the job". This is the most harmful spam, and we can't do anything against it. The Stampchain tx I linked in my earlier post alone creates 28 UTXOs (plus the OP_RETURN which is discarded, and one change output) for a minuscule Pepe image, which will never be spend. Imagine a spam wave based on this technique.

They could go one step further by excluding TX that create new P2MS output, since AFAIK there's no wallet software create P2MS output these days.