Download PDF
OP_RETURN
OP_PUSHBYTES_11
68656c6c6f20776f726c64
OP_RETURN
Storing data on the blockchain
OP_RETURN refers to a standard locking script type that can be used to store data inside transactions.
The OP_RETURN opcode itself immediately ends the execution of the script and marks it as invalid.
Whilst this is an opcode on its own and can be used in a variety of different scripts, the name "OP_RETURN" is also used to refer to a standard script pattern used for storing arbitrary data inside transactions.
This page covers the OP_RETURN locking script pattern.
This locking script cannot be unlocked. Do not lock up any amount of bitcoins using this script pattern.
This is sometimes referred to as a "nulldata" script. But whilst that's the technically correct term, it's not commonly used, which is why I refer to this locking script as "OP_RETURN" instead.
Usage
How does an OP_RETURN script work?
ScriptPubKey
The OP_RETURN standard locking script just contains the OP_RETURN opcode followed by one or more data pushes.
6a0b68656c6c6f20776f726c64Transaction: 6dfb16dd580698242bcfd8e433d557ed8c642272a368894de27292a8844a4e75 (Output 2)
These data pushes can contain any bytes of data you like.
They are commonly used for storing ASCII-encoded text strings (see examples).
ScriptSig
An OP_RETURN locking script is unspendable, so there's no ScriptSig that can unlock it.
So ultimately outputs with the OP_RETURN locking script only exist to store arbitrary bytes of data, and can never be used as inputs in future transactions:
Limits
How much data can you store in an OP_RETURN?
The total maximum size for a standard OP_RETURN script is 83 bytes.
Within this limit you can include multiple data pushes. For example:
OP_RETURN
OP_PUSHBYTES_15
6c6561726e6d6561626974636f696e
6a0f6c6561726e6d6561626974636f696eTransaction: 293af55e572c95ef769bc3fbb4084cb1e4c95f143ce30d923dde26a123c158de (Output 1)
Total Size = 17 bytes (1 x 15-byte data push)
OP_RETURN
OP_PUSHBYTES_15
6c6561726e6d6561626974636f696e
OP_1
OP_2
OP_3
OP_4
6a0f6c6561726e6d6561626974636f696e51525354Transaction: 9aa48ce6b9045d5cd29398272502325255d731ddb97dc207f30d14f35628ed08 (Output 1)
Total Size = 21 bytes (1 x 15-byte data push + 4 x single number data pushes)
Note: The individual OP_N opcodes also count as data pushes, so they can be used within an OP_RETURN standard script too.
OP_RETURN
OP_PUSHBYTES_1
a0
OP_PUSHBYTES_1
a1
OP_PUSHBYTES_1
a2
OP_PUSHBYTES_1
a3
OP_PUSHBYTES_1
a4
OP_PUSHBYTES_1
a5
OP_PUSHBYTES_1
a6
OP_PUSHBYTES_1
a7
OP_PUSHBYTES_1
a8
OP_PUSHBYTES_1
a9
OP_PUSHBYTES_1
b0
OP_PUSHBYTES_1
b1
OP_PUSHBYTES_1
b2
OP_PUSHBYTES_1
b3
OP_PUSHBYTES_1
b4
OP_PUSHBYTES_1
b5
OP_PUSHBYTES_1
b6
OP_PUSHBYTES_1
b7
OP_PUSHBYTES_1
b8
OP_PUSHBYTES_1
b9
OP_PUSHBYTES_1
c0
OP_PUSHBYTES_1
c1
OP_PUSHBYTES_1
c2
OP_PUSHBYTES_1
c3
OP_PUSHBYTES_1
c4
OP_PUSHBYTES_1
c5
OP_PUSHBYTES_1
c6
OP_PUSHBYTES_1
c7
OP_PUSHBYTES_1
c8
OP_PUSHBYTES_1
c9
OP_PUSHBYTES_1
d0
OP_PUSHBYTES_1
d1
OP_PUSHBYTES_1
d2
OP_PUSHBYTES_1
d3
OP_PUSHBYTES_1
d4
OP_PUSHBYTES_1
d5
OP_PUSHBYTES_1
d6
OP_PUSHBYTES_1
d7
OP_PUSHBYTES_1
d8
OP_PUSHBYTES_1
d9
OP_PUSHBYTES_1
e0
6a01a001a101a201a301a401a501a601a701a801a901b001b101b201b301b401b501b601b701b801b901c001c101c201c301c401c501c601c701c801c901d001d101d201d301d401d501d601d701d801d901e0Transaction: 42c4fabe072e70eae555cb41e34291ee5c9ff205c3e5704e230339abc912b339 (Output 1)
Total Size = 83 bytes (41 x 1-byte data pushes)
So as long as the total OP_RETURN ScriptPubKey size remains within the 83-byte limit, you can include as many data pushes as you like.
Single Data Push
A 1-byte data push opcode (i.e. OP_PUSHBYTES_X) can only push up to 75 bytes at a time. For example:
OP_RETURN
OP_PUSHBYTES_75
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006c6561726e6d6561626974636f696e
6a4b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006c6561726e6d6561626974636f696eTransaction: 2033435de7ce307341231e818ed937cd3a5e8597381fd83a7e5b0234f61b38d3 (Output 1)
Total Size = 77 bytes (1 x 75-byte data push)
So if you want to use a single data push of 76 bytes or more, you need to use the OP_PUSHDATA1 opcode instead:
OP_RETURN
OP_PUSHDATA1
50
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006c6561726e6d6561626974636f696e
6a4c5000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006c6561726e6d6561626974636f696eTransaction: 2033435de7ce307341231e818ed937cd3a5e8597381fd83a7e5b0234f61b38d3 (Output 1)
Total Size = 83 bytes (1 x 80-byte data push)
Note: The 0x50 after OP_PUSHDATA1 is used to indicate an upcoming 80 bytes. See data pushes for details.
Therefore, the largest single data push you can include in an OP_RETURN output is 80 bytes.
This is because it requires 3 bytes of overhead (i.e. 6a4c50), which takes us up to the 83-byte limit for a OP_RETURN standard script.
- A standard OP_RETURN script must have a value of 0 satoshis. If you include an amount of bitcoins in the output, it will be considered non-standard and will not be relayed by nodes. This is to save you from losing bitcoins by locking them to an unspendable locking script.
- A transaction can only include one OP_RETURN locking script. Any more and it will be considered non-standard and will not be relayed by nodes.
Examples
Where can you find OP_RETURN scripts?
Anyone can use an OP_RETURN script to store some data in a transaction, and you can find them scattered around the blockchain:
Example 1 — hello world
OP_RETURN
OP_PUSHBYTES_11
68656c6c6f20776f726c64
6a0b68656c6c6f20776f726c64Transaction: 6dfb16dd580698242bcfd8e433d557ed8c642272a368894de27292a8844a4e75 (Output 2)
Example 2 — charley loves heidi
OP_RETURN
OP_PUSHBYTES_19
636861726c6579206c6f766573206865696469
6a13636861726c6579206c6f766573206865696469Transaction: 8bae12b5f4c088d940733dcd1455efc6a3a69cf9340e17a981286d3778615684 (Output 0)
Example 3 — Amazing!
OP_RETURN
OP_PUSHBYTES_8
416d617a696e6721
6a08416d617a696e6721Transaction: 2cf4f1ab0df25610231a0f4fb7e1e18720a6c555f102b75bb115e99b1ad41241 (Output 2)
Example 4 — First OPReturn Message I was here :)
OP_RETURN
OP_PUSHBYTES_36
4669727374204f5052657475726e204d6573736167652049207761732068657265203a29
6a244669727374204f5052657475726e204d6573736167652049207761732068657265203a29Transaction: b33c1252ddc2fdb5396c7dc3ceed3749c587e3310c6df2f3605a38cc3c129e1f (Output 1)
Example 5 (wTXID Commitment)
Since the Segregated Witness upgrade, the OP_RETURN locking script is used within the coinbase transaction to store the wTXID Commitment:
OP_RETURN
OP_PUSHBYTES_36
aa21a9ed6502e8637ba29cd8a820021915339c7341223d571e5e8d66edd83786d387e715
6a24aa21a9ed6502e8637ba29cd8a820021915339c7341223d571e5e8d66edd83786d387e715Transaction: 2d4cdcd29d0004c762790b579bc2541da788f042031fa87fc27e402244080394 (Output 1)
This data push is not ASCII-encoded text. It's just a bunch of bytes, so there's nothing interesting to be found by converting it to ASCII.
If you want to find OP_RETURN scripts in the blockchain, look for outputs with zero amount values. This is because OP_RETURN scripts are unspendable, so they're almost always placed on "empty" outputs.
Purpose
Why do we have OP_RETURN scripts?
OP_RETURN was introduced as a standard locking script in Bitcoin 0.9.0 as a compromise to allow people to include arbitrary data inside transactions.
You see, before OP_RETURN was available, people were adding data to transactions by using the existing standard locking scripts. For example, here's how I could store the text string "learnmeabitcoin" in the place where the public key hash would go in a standard P2PKH locking script:
OP_DUP
OP_HASH160
OP_PUSHBYTES_20
00000000006c6561726e6d6561626974636f696e
OP_EQUALVERIFY
OP_CHECKSIG
76a91400000000006c6561726e6d6561626974636f696e88acThis works, but the problem with this approach is that there's no way for a Bitcoin node to know that it is unspendable, so the output would be stored in the UTXO database forever (which is a permanent waste of RAM).
So this is where the OP_RETURN locking script comes in:
OP_RETURN
OP_PUSHBYTES_15
6c6561726e6d6561626974636f696e
6a0f6c6561726e6d6561626974636f696eThis script contains OP_RETURN, which means it provably unspendable and therefore does not need to be stored in the UTXO database (which saves on precious RAM space when Bitcoin is running).
Using the blockchain for data storage isn't ideal, but you can't stop people from doing it. Therefore, the OP_RETURN script acts as a more reasonable alternative for data storage than previous methods.
There has been some confusion and misunderstanding in the community, regarding the OP_RETURN feature in 0.9 and data in the blockchain. This change is not an endorsement of storing data in the blockchain. The OP_RETURN change creates a provably-prunable output, to avoid data storage schemes – some of which were already deployed – that were storing arbitrary data such as images as forever-unspendable TX outputs, bloating bitcoin’s UTXO database.
Notes
OP_RETURN must be evaluated for a script to fail.
The presence of the OP_RETURN opcode in a script does not automatically render the script invalid.
For example, in the script below the OP_RETURN is in a branch that will never be evaluated, and so the script is valid:
OP_1 OP_IF OP_1 OP_ELSE OP_RETURN OP_ENDIF
You can see an example of this script in action (wrapped inside a P2SH) here.
Thanks to Vincenzo Iovino for pointing this out to me.