<p>OP_RETURN is only limited to 80 bytes by Bitcoin Core's default standardness rules. Some people increase this limit using the <code>-datacarriersize</code> option. Other people have been running Peter Todd's &quot;Libre Relay&quot; 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.</p>
<p>Moreover, OP_RETURN is one of only a handful of standard output script templates. Putting <code>&lt;data&gt; OP_DROP</code> 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.</p>
<p>However, <code>&lt;data&gt; OP_DROP</code> 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 <code>&lt;data&gt; OP_DROP &lt;data&gt; OP_DROP ...</code>, requiring multiple drop opcodes. A more efficient way is <code>OP_FALSE OP_IF &lt;data&gt; &lt;data&gt; ... OP_ENDIF</code>, sometimes known as the &quot;inscription envelope&quot; 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.)</p>

CC BY-SA 4.0
2024-01-31T08:56:09.353Z
So using OP_DROP will create one of those non-standard addresses no matter how it is used?
user2334659
CC BY-SA 4.0
2024-01-31T08:58:32.993Z
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.
Vojtěch Strnad
CC BY-SA 4.0
2024-01-31T09:03:27.720Z
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?
user2334659
CC BY-SA 4.0
2024-01-31T09:05:32.847Z
Non-standard output scripts never have a corresponding address, so it's enough to use just that.
Vojtěch Strnad
CC BY-SA 4.0
2024-01-31T07:55:45.293Z
2024-01-31T14:23:41.873Z
2024-01-31T14:23:41.873Z
Vojtěch Strnad
<p>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.</p>
<p>Am I off track or could we use:</p>
<pre><code>&lt;data&gt; OP_DROP
</code></pre>
<p>to pass data that is not restricted to 80 bytes and does not create a new UTXO?</p>
<p>Are there any transactions that I could look at that make use of this (not sure how to search for something like that)?</p>

CC BY-SA 4.0
2024-01-31T08:09:39.390Z
Are you concerned about UTXO set bloat? OP_RETURN outputs are _provably_ unspendable, so they don't take any space in the UTXO set.
Vojtěch Strnad
CC BY-SA 4.0
2024-01-31T08:49:39.860Z
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.
user2334659
CC BY-SA 4.0
2024-01-31T08:59:02.443Z
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.
user2334659
CC BY-SA 4.0
2024-01-31T09:06:16.590Z
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.
Vojtěch Strnad
<script><op-return><input-script><opcodes><output-script>
Can OP_DROP be used to include arbitrary data?
user2334659
# Can OP_DROP be used to include arbitrary data?

(Asked by: username_0 on 2024-01-31)

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)?

**Tags:** script, op-return, input-script, opcodes, output-script

> **Comments:**
> **username_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.  
> **username_0**: 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.  
> **username_0**: 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.  
> **username_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.  

---

## 1 answers

### Answer by username_1 on 2024-01-31. Score: 2 | Accepted answer

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.)

> **Comments:**
> **username_0**: So using OP_DROP will create one of those non-standard addresses no matter how it is used?  
> **username_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.  
> **username_0**: 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?  
> **username_1**: Non-standard output scripts never have a corresponding address, so it's enough to use just that.  

---

