pull down to refresh

Will Taproot wizards and other spam companies and projects start using OP_RETURN to put jpegs on the blockchain?
242 sats \ 0 replies \ @rijndael 6h
I can't speak for the "spam companies and projects", but as far as we're concerned:
I'm not going to emphatically say "no" because who knows, maybe in the future we'll have some application where it makes sense but we currently do not. We have released and sold two inscription collections (that both put data in witness data). In both of those cases, it's not clear to me that having the data in OP_RETURNs would have been better. The main reason we put the data in witness data was for compatibility with the ordinals protocol. Our collectors want to be able to manage, store, and trade our collection in wallets they're already using -- and there are several ordinals-specific wallets out there, and any wallet with coin control could technically be used. You could add opreturns to ordinals, but it would be weird. imo, having inscription data in the input instead of the output makes the protocol cleaner and easier to implement.
So for our collections, compatibility is a bigger concern than something like the witness discount. High-value inscriptions are actually reasonably price-insensitive when we're talking about a 4x cost premium. We did a LOT of work on Quantum Cats to bring the cost down, but that was by a factor of about 100, not 4.
Outside of digital collectables, we've done a lot of work with OP_RETURNs holding data commitments for multi-transaction protocols using OP_CAT or other covenants. In those cases, usually we're putting one or two merkle roots and maybe a little metadata tag in an opreturn. So we actually haven't felt any real pain with the 80-byte limit. We actually run into consensus limits more often than we run into the OP_RETURN limit.
In general, if we did want to stick a bunch of data into an opreturn it would probably be something where:
  • we are not inspecting it in a future transaction (a la the OP_CAT state caboose trick)
  • it's something where either its an op_return-specific protocol or something other than ordinals (maybe something we cook up, maybe something our customers want)
  • its something where we really care about malleability (opreturns get covered by SIGHASH_ALL, witness data does not)
Nothing currently fits that bill, so I don't think so, but you never know. Maybe some of the people mad about this have a fun idea they can share.
reply
i don’t know… when it comes to our so-called “spam” work, it’s supposed to have cultural/sentimental value to some people
for example, for some people, a wizard jpeg is a way to express their love for bitcoin
it’s hard to predict if under some circumstance OP_RETURN will somehow increase the cultural/sentimental value of some jpeg, but my intuition is it probably will not?
then again, if for some reason it does, you can expect a lot of people will do that. from that standpoint, for those who for some reason want to avoid “spam”, it would make more sense not to remove OP_RETURN limits, to prevent the possibility that collectors ascribe some cultural/sentimental value to that in the future
reply
10 sats \ 0 replies \ @Murch 6h
To add a data payload via OP_RETURN, you have to add an additional output to a transaction. This requires 11 bytes of transaction data overhead. The data is not subject to segwit’s witness discount.
Vojtěch Strnad shows that inscriptions have at least 118.75 vB overhead. However, the data payload of inscriptions is subject to segwit’s witness discount.
According to Strnad‘s calculation, data payloads of 143 bytes or larger are cheaper with inscriptions. It would therefore only make sense for small payloads to move to OP_RETURN, and it seems economically unattractive to prefer OP_RETURN outputs over inscriptions to embed images in the blockchain.
reply