2

I have recently been looking into OP_RETURN and its uses in so far as including data in a transaction. Given the fact that OP_RETURN is limited to 80 bytes I thought what if OP_DROP was used? That way it does not create the same unspendable UTXO as OP_RETURN while still allowing the person to include some data in the transaction plus more than 80 bytes can be added.

Am I off track or could we use:

<data> OP_DROP

to pass data that is not restricted to 80 bytes and does not create a new UTXO?

Are there any transactions that I could look at that make use of this (not sure how to search for something like that)?

4
  • 1
    Are you concerned about UTXO set bloat? OP_RETURN outputs are provably unspendable, so they don't take any space in the UTXO set. Jan 31 at 8:09
  • My initial thought came from hearing about people wanting to pass "hidden messages" not realising the OP_RETURN output created. Which got me thinking if there was a less obvious way of passing messages and came across OP_DROP. Obviously it is not hidden, but less obvious than OP_RETURN creating an output (plus the added benefit of longer message size). Just wanted to explore the concept a bit further. Jan 31 at 8:49
  • Because it's too late the edit the comment. I know trying to pass hidden messages in Bitcoin is stupid, but it doesn't stop people who don't understand Bitcoin from doing it. Jan 31 at 8:59
  • 1
    Trying to make a message "less obvious" will eventually make it more obvious, as it will stand out from the other, more common ways of embedding arbitrary data. Jan 31 at 9:06

1 Answer 1

2

OP_RETURN is only limited to 80 bytes by Bitcoin Core's default standardness rules. Some people increase this limit using the -datacarriersize option. Other people have been running Peter Todd's "Libre Relay" patch that removes this and other standardness limits, and automatically connects to other nodes running the patch. As a result, many transactions that exceed this limit have been mined lately, so you might not actually need to devise a way around it.

Moreover, OP_RETURN is one of only a handful of standard output script templates. Putting <data> OP_DROP into the output script will make it non-standard by Bitcoin Core's (and most other implementations') rules. What you actually need is to put it into a script that's revealed in an input, i.e. a P2WSH witness script or a P2TR leaf script. Doing it this way also means your data makes use of the discount on witness data.

However, <data> OP_DROP is still slightly suboptimal if you're looking to push anything large. The largest push size allowed by consensus rules is 520 bytes, so you'd need to split your data into chunks of 520 bytes like <data> OP_DROP <data> OP_DROP ..., requiring multiple drop opcodes. A more efficient way is OP_FALSE OP_IF <data> <data> ... OP_ENDIF, sometimes known as the "inscription envelope" as it was popularized by ordinal inscriptions. (Note that there's currently a movement to make this specific pattern non-standard by default; how likely it is to succeed I will leave as an exercise for the reader.)

4
  • So using OP_DROP will create one of those non-standard addresses no matter how it is used? Jan 31 at 8:56
  • 1
    There's no such thing as a non-standard address, addresses are standardized encodings of standard output script types. And yes, there is no standard output script type that has OP_DROP in it. Jan 31 at 8:58
  • Sorry for the confusion, I use the term non-standard addresses to refer to these situations. What is a better way to refer to "non-standard scripts that do not resolve to an address" without having to write all that each time? Jan 31 at 9:03
  • 1
    Non-standard output scripts never have a corresponding address, so it's enough to use just that. Jan 31 at 9:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.