Bitcoin

op return – When is OP_RETURN cheaper than OP_FALSE OP_IF?

TL;DR: OP_RETURN is cheaper for data smaller than 143 bytes.

Graph comparing OP_RETURN to inscription

The overhead of OP_RETURN output is at least 11 bytes.

  • Amount (8 bytes)
  • Compact script size (minimum 1 byte)
  • script:
    • OP_RETURN opcode (1 byte)
    • Push opcode (minimum 1 byte)

The overhead of an inscription is at least 118.75 vB (84 base bytes and 139 watch 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-sized surveillance stack (1WU)
      • Compact size signature (1WU)
      • Signature (64WU)
      • Compact sized script (minimum 1WU)
      • script:
        • Public key push opcode (1WU)
        • Public key (32WU)
        • OP_CHECKSIG operation code (1WU)
        • OP_FALSE operation code (1WU)
        • OP_IF operation code (1WU)
        • Push opcode (minimum 1WU)
        • OP_ENDIF operation code (1WU)
      • Compact size control block (1WU)
      • Control block (33WU)

The surveillance discount offsets the larger overhead at 143 bytes of data. This requires 155vB with OP_RETURN and 154.75vB with inscription. Anything smaller than that is cheaper than OP_RETURN.

note:

  • The above assumes a best-case scenario where P2TR inputs serve some other purpose and are included in transactions that are performed anyway. This is often not the case, in which case the overhead is at least 129.25vB and OP_RETURN is cheaper for up to 158 bytes of data.
  • In the inscription, the data should be split into 520-byte chunks, but in the OP_RETURN output, it should not be split. This only affects data that is large enough to not change the answer.
  • Here we ignore the standard limit of 80 bytes for OP_RETURN.

Related Articles

Back to top button