<p><strong>TL;DR</strong>: OP_RETURN is cheaper for data smaller than 143 bytes.</p>
<p><a href="https://i.sstatic.net/ZsQMz.png" rel="noreferrer"><img src="https://i.sstatic.net/ZsQMz.png" alt="graph that compares OP_RETURN with inscriptions" /></a></p>
<p>The overhead of an OP_RETURN output is at least 11 bytes:</p>
<ul>
<li>amount (8 bytes)</li>
<li>compact size of script (at least 1 byte)</li>
<li>script:
<ul>
<li>OP_RETURN opcode (1 byte)</li>
<li>push opcode (at least 1 byte)</li>
</ul>
</li>
</ul>
<p>The overhead of an inscription is at least 118.75 vB (84 base bytes and 139 witness bytes):</p>
<ul>
<li>P2TR output (43 bytes)</li>
<li>P2TR input:
<ul>
<li>outpoint TXID (32 bytes)</li>
<li>outpoint index (4 bytes)</li>
<li>sequence (4 bytes)</li>
<li>compact size of input script (1 byte, script is empty)</li>
<li>witness data:
<ul>
<li>compact size of witness stack (1 WU)</li>
<li>compact size of signature (1 WU)</li>
<li>signature (64 WU)</li>
<li>compact size of script (at least 1 WU)</li>
<li>script:
<ul>
<li>public key push opcode (1 WU)</li>
<li>public key (32 WU)</li>
<li>OP_CHECKSIG opcode (1 WU)</li>
<li>OP_FALSE opcode (1 WU)</li>
<li>OP_IF opcode (1 WU)</li>
<li>push opcodes (at least 1 WU)</li>
<li>OP_ENDIF opcode (1 WU)</li>
</ul>
</li>
<li>compact size of control block (1 WU)</li>
<li>control block (33 WU)</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>The witness discount cancels out the larger overhead at 143 bytes of data, which takes 155 vB using an OP_RETURN and 154.75 vB using an inscription. For anything smaller than that OP_RETURN is cheaper.</p>
<p>Notes:</p>
<ul>
<li>The above assumes a best-case scenario in which the P2TR input is included in a transaction that serves some other purpose and would be made anyway. This often isn't the case, in which case the overhead is at least 129.25 vB and OP_RETURN is cheaper for up to at least 158 bytes of data.</li>
<li>It's necessary to split the data into chunks of 520 bytes in an inscription but not in an OP_RETURN output. This only affects data large enough that it doesn't change the answer.</li>
<li>We're ignoring the 80-byte standardness limit for OP_RETURN here.</li>
</ul>

CC BY-SA 4.0
2024-11-27T15:06:27.377Z
You can drop the 1 byte overhead for the size encoding of the data that follows an OP_RETURN. Any bytes following an OP_RETURN do not need to be a valid (or even parseable) Bitcoin script. Thus, no size encoding is needed.
user2084795
CC BY-SA 4.0
2024-11-27T15:11:13.083Z
@user2084795 That would be a non-standard output script, but otherwise you're absolutely right. You might as well drop the OP_RETURN too and save another byte.
Vojtěch Strnad
CC BY-SA 4.0
2024-03-18T20:49:35.163Z
2024-03-18T20:49:35.163Z
Vojtěch Strnad
<p>Since January 2023 there have been many transactions that embed arbitrary data in the leaf script of a P2TR input using the opcodes OP_FALSE OP_IF (also called &quot;inscription envelope&quot;). This is usually cheaper than using OP_RETURN because the data benefits from the witness discount, but also comes with the overhead of having to first create the P2TR output and then spending it in a subsequent transaction. So, when is it cheaper to use OP_RETURN?</p>

<op-return><transaction-weight><ordinals>
When is OP_RETURN cheaper than OP_FALSE OP_IF?
Vojtěch Strnad
# When is OP_RETURN cheaper than OP_FALSE OP_IF?

(Asked by: username_0 on 2024-03-18)

Since January 2023 there have been many transactions that embed arbitrary data in the leaf script of a P2TR input using the opcodes OP\_FALSE OP\_IF (also called "inscription envelope"). This is usually cheaper than using OP\_RETURN because the data benefits from the witness discount, but also comes with the overhead of having to first create the P2TR output and then spending it in a subsequent transaction. So, when is it cheaper to use OP\_RETURN?

**Tags:** op-return, transaction-weight, ordinals


---

## 1 answers

### Answer by username_0 on 2024-03-18. Score: 8 | Accepted answer

**TL;DR**: OP\_RETURN is cheaper for data smaller than 143 bytes.

[![graph that compares OP_RETURN with inscriptions](https://i.sstatic.net/ZsQMz.png)](https://i.sstatic.net/ZsQMz.png)

The overhead of an OP\_RETURN output is at least 11 bytes:

* amount (8 bytes)
* compact size of script (at least 1 byte)
* script:
  + OP\_RETURN opcode (1 byte)
  + push opcode (at least 1 byte)

The overhead of an inscription is at least 118.75 vB (84 base bytes and 139 witness bytes):

* P2TR output (43 bytes)
* P2TR input:
  + outpoint TXID (32 bytes)
  + outpoint index (4 bytes)
  + sequence (4 bytes)
  + compact size of input script (1 byte, script is empty)
  + witness data:
    - compact size of witness stack (1 WU)
    - compact size of signature (1 WU)
    - signature (64 WU)
    - compact size of script (at least 1 WU)
    - script:
      * public key push opcode (1 WU)
      * public key (32 WU)
      * OP\_CHECKSIG opcode (1 WU)
      * OP\_FALSE opcode (1 WU)
      * OP\_IF opcode (1 WU)
      * push opcodes (at least 1 WU)
      * OP\_ENDIF opcode (1 WU)
    - compact size of control block (1 WU)
    - control block (33 WU)

The witness discount cancels out the larger overhead at 143 bytes of data, which takes 155 vB using an OP\_RETURN and 154.75 vB using an inscription. For anything smaller than that OP\_RETURN is cheaper.

Notes:

* The above assumes a best-case scenario in which the P2TR input is included in a transaction that serves some other purpose and would be made anyway. This often isn't the case, in which case the overhead is at least 129.25 vB and OP\_RETURN is cheaper for up to at least 158 bytes of data.
* It's necessary to split the data into chunks of 520 bytes in an inscription but not in an OP\_RETURN output. This only affects data large enough that it doesn't change the answer.
* We're ignoring the 80-byte standardness limit for OP\_RETURN here.

> **Comments:**
> **username_1**: You can drop the 1 byte overhead for the size encoding of the data that follows an OP_RETURN. Any bytes following an OP_RETURN do not need to be a valid (or even parseable) Bitcoin script. Thus, no size encoding is needed.  
> **username_0**: @username_1 That would be a non-standard output script, but otherwise you're absolutely right. You might as well drop the OP_RETURN too and save another byte.  

---

