<blockquote>
<p>What does exactly cause the output containing OP_RETURN to be unspendable?</p>
</blockquote>
<p>Simply the fact that no input can possibly unlock coins which are encumbered with such an OP_RETURN-containing script. Whenever the script interpreter encounters an OP_RETURN instruction, it instantly aborts and cause the entire script to fail.</p>
<p>However, OP_RETURN does more than make a script unspendable. It makes it <em>noticably</em> and <em>provably</em> unspendable, and triggers special logic. For example, creating an output that pay to a normal P2WPKH address for a key you generated, and then throwing away the key, also makes the coin unspendable. However, it isn't obvious to the network that it is unspendable, and you can't prove to anyone that is.</p>
<p>This is different with OP_RETURN: any script that starts with OP_RETURN is <em>obviously</em> unspendable, and at least the Bitcoin Core software notices this as a special case, and will avoid storing such outputs in its database, because it is known that they cannot be spent. Attempts to spend it will trigger a &quot;coin not found&quot; rather than &quot;script validation&quot; error, but the result is the same: the transaction won't be allowed to proceed.</p>
<blockquote>
<p>And why do I have to use the byes after OP_RETURN for keeping data in the blockchain and I can't use bytes before OP_RETURN?</p>
</blockquote>
<p>For two reasons:</p>
<ul>
<li>By putting the OP_RETURN at the front, the special certainly-can't-be-spent-so-can-be-forgotten-about logic will trigger, which is lighter on all future full nodes that implement this logic.</li>
<li>Standard relay policies implemented in most network nodes only permit a certain limited number of output templates. These include payments to typical addresses, and also scripts up to a certain size that start with OP_RETURN. If you'd try to create an output that put the data before the opcode, it would be considered a non-standard output type and not relayed by most nodes.</li>
</ul>

CC BY-SA 4.0
2021-09-20T14:12:10.973Z
"and will avoid storing such outputs in its database" - 1. If the output is part of a transaction, then the whole transaction is saved and you can't avoid saving only that specific output, right? 2. If it's not saved, then what's the point in doing it? The idea was to save the data in the blockchain.
Rony Tesler
CC BY-SA 4.0
2021-09-20T14:18:24.623Z
The UTXO database is distinct from the blockchain. All transactions that are mined are part of a block, and if you're running a non-pruning node, you'll be storing the blockchain in full. The UTXO database is a separate, and much small, non-optional set of all transaction _outputs_ that have not been spent yet (and, are possibly spendable). OP_RETURN avoids creating an entry in that UTXO database; it doesn't mean the transaction doesn't become part of the blockchain.
Pieter Wuille
CC BY-SA 4.0
2022-11-25T15:10:16.123Z
If by `burn coins` one means to make some amount of BTC unspendable, OP_RETURN outputs cannot really do this, as they have to have 0 amount (at least as enforced by Bitcoin Core).  I base this on description from here: https://developer.bitcoin.org/devguide/transactions.html#null-data
OptOut
CC BY-SA 4.0
2021-09-20T02:15:49.827Z
2021-09-20T02:15:49.827Z
Pieter Wuille
<p>What exactly causes the output containing OP_RETURN to be unspendable?
And why do I have to use the byes after OP_RETURN for keeping data in the blockchain and I can't use bytes before OP_RETURN?</p>

<script><op-return>
How does OP_RETURN burn coins?
Rony Tesler
# How does OP_RETURN burn coins?

(Asked by: username_0 on 2021-09-20)

What exactly causes the output containing OP\_RETURN to be unspendable?
And why do I have to use the byes after OP\_RETURN for keeping data in the blockchain and I can't use bytes before OP\_RETURN?

**Tags:** script, op-return


---

## 1 answers

### Answer by username_1 on 2021-09-20. Score: 12 | Accepted answer

> What does exactly cause the output containing OP\_RETURN to be unspendable?

Simply the fact that no input can possibly unlock coins which are encumbered with such an OP\_RETURN-containing script. Whenever the script interpreter encounters an OP\_RETURN instruction, it instantly aborts and cause the entire script to fail.

However, OP\_RETURN does more than make a script unspendable. It makes it *noticably* and *provably* unspendable, and triggers special logic. For example, creating an output that pay to a normal P2WPKH address for a key you generated, and then throwing away the key, also makes the coin unspendable. However, it isn't obvious to the network that it is unspendable, and you can't prove to anyone that is.

This is different with OP\_RETURN: any script that starts with OP\_RETURN is *obviously* unspendable, and at least the Bitcoin Core software notices this as a special case, and will avoid storing such outputs in its database, because it is known that they cannot be spent. Attempts to spend it will trigger a "coin not found" rather than "script validation" error, but the result is the same: the transaction won't be allowed to proceed.

> And why do I have to use the byes after OP\_RETURN for keeping data in the blockchain and I can't use bytes before OP\_RETURN?

For two reasons:

* By putting the OP\_RETURN at the front, the special certainly-can't-be-spent-so-can-be-forgotten-about logic will trigger, which is lighter on all future full nodes that implement this logic.
* Standard relay policies implemented in most network nodes only permit a certain limited number of output templates. These include payments to typical addresses, and also scripts up to a certain size that start with OP\_RETURN. If you'd try to create an output that put the data before the opcode, it would be considered a non-standard output type and not relayed by most nodes.

> **Comments:**
> **username_0**: "and will avoid storing such outputs in its database" - 1. If the output is part of a transaction, then the whole transaction is saved and you can't avoid saving only that specific output, right? 2. If it's not saved, then what's the point in doing it? The idea was to save the data in the blockchain.  
> **username_1**: The UTXO database is distinct from the blockchain. All transactions that are mined are part of a block, and if you're running a non-pruning node, you'll be storing the blockchain in full. The UTXO database is a separate, and much small, non-optional set of all transaction _outputs_ that have not been spent yet (and, are possibly spendable). OP_RETURN avoids creating an entry in that UTXO database; it doesn't mean the transaction doesn't become part of the blockchain.  
> **username_2**: If by `burn coins` one means to make some amount of BTC unspendable, OP_RETURN outputs cannot really do this, as they have to have 0 amount (at least as enforced by Bitcoin Core).  I base this on description from here: https://developer.bitcoin.org/devguide/transactions.html#null-data  

---

