<p><strong>Another reason: <em>Merged Mining</em></strong></p>
<p>Whilst not in the OP's example coinbase transaction, another reason for <code>OP_RETURN</code> in a coinbase transaction is merge mining. A miner might follow the <a href="https://en.bitcoin.it/wiki/Merged_mining_specification#Merged_mining_coinbase" rel="nofollow noreferrer">merged mining specification</a> which involves placing one or more other system's block identifiers into the input script. Additionally the miner might create one or more <code>OP_RETURN</code>s with an id code and block information the other blockchain(s), according to the specification of those chains.</p>
<p><strong>Example: <em>block 733578 coinbase Tx</em></strong></p>
<p>An example, as <a href="https://zeroknowledgedefi.com/2022/04/29/merge-mining-and-auxiliary-proof-of-work/#merge_sec6" rel="nofollow noreferrer">explained here</a>, is the block 733578 <a href="https://blockstream.info/nojs/tx/2a85992897c54db7baa8b474bdc03ce7867bd9d8f4b00329cedd223d9997b100?expand" rel="nofollow noreferrer">coinbase</a> <a href="https://blockchair.com/bitcoin/transaction/2a85992897c54db7baa8b474bdc03ce7867bd9d8f4b00329cedd223d9997b100" rel="nofollow noreferrer">transaction</a> in which the miner mined for three other blockchains (Namecoin, RSK, and Vcash, as well as BTC). The <a href="https://chainz.cryptoid.info/nmc/block.dws?632997bd2735b0c7659eee5e72f1bcfd1da17d8e420576d8c5ad19fdb2451b4e.htm" rel="nofollow noreferrer">Namecoin</a> (<code>fabe6d6d</code>) block is identified in the input scriptsig. RSK and Vcash blocks are included in the coinbase transaction's <code>OP_RETURN</code>s; <a href="https://explorer.rsk.co/block/4262866?__ctab=Mining" rel="nofollow noreferrer">RSK</a> (<code>52534b424c4f434b3a</code>) and <a href="https://vcash.tech/block/4869fa8eeb9618a6791a4000a6487ca1f0a4dc277b48051563ac656dd228a044" rel="nofollow noreferrer">Vcash</a> (<a href="https://bitcoin.stackexchange.com/a/113524/34190"><code>b9e11b6d</code></a>).</p>
<p>Per @Murch's answer here, the third <code>OP_RETURN</code> in this example is the <a href="https://bitcoin.stackexchange.com/a/113523/34190">segregated witness merkle root</a> (<code>aa21a9ed</code>).</p>
<hr />
<p>Interestingly, there is <a href="https://bitcoin.stackexchange.com/a/116313/34190">no limit</a> to the number of <code>OP_RETURN</code>s in the coinbase transaction, other than the size of the transaction, which itself is
~only constrained by the size of the block its in.</p>

CC BY-SA 4.0
2022-10-24T13:06:29.343Z
2022-12-10T13:12:36.377Z
2022-12-10T13:12:36.377Z
Lee
<p>Every segwit block has one such OP_RETURN in the coinbase transaction: It's the Merkle root of the witness tree.</p>

<p>When the segwit softfork was activated, this included a fix to the third-party transaction malleability issue that was present on the network before. The issue was that the signature of a transaction could be changed by any other person by inverting the S-value used in the signature. This resulted in another valid (non-standard) transaction spending the same coins to the same recipients, but a different txid.</p>

<p>Segwit prevented this source of transaction malleability by moving the witness program out of the input script to a separate "witness field" in the transaction ("segregated the witness") which is ignored when the txid is calculated. This means that even when signatures are changed for segwit transactions, their txid remains the same. Making the txid independent from the signature also makes it easier to build on top of unsigned transactions (since their txid doesn't change with the signature) which is e.g. useful for smart contracts employed in Lightning Network payment channels.</p>

<p>A block commits to all of its transactions by including the root of the Merkle tree over their txids. However, this would mean that this commitment wouldn't cover the signatures of segwit transactions as they don't contribute to the txid. To commit to the signatures, segwit introduced the a second parallel Merkle tree, built from the witness txids, i.e. a transaction id calculated over the complete transaction data including the witness program. Since the blockheader can't be extended without a hardfork, segwit blocks commit to this witness tree by including the root in an OP_RETURN in the coinbase transaction.</p>

CC BY-SA 3.0
2018-04-20T16:08:04.687Z
2018-04-20T16:08:04.687Z
Murch
<p>I’m looking at <a href="https://blockchair.com/bitcoin/transaction/0bcd7a3a8caa322bcea7589b513f3dae232e4f53ae6c20a5f0ec29a8d2bf6ae9" rel="nofollow noreferrer">this coinbase transaction</a>. I'm confused why there are two outputs and why one of them is labelled with OP_RETURN.</p>

CC BY-SA 3.0
2018-04-20T02:27:47.090Z
Are you asking about what OP_RETURN is in general (explained in detail [here](https://bitcoin.stackexchange.com/questions/29554/explanation-of-what-an-op-return-transaction-looks-like)) or why a miner decided to put one in a coinbase transaction (only the miner knows for sure)?
Nate Eldredge
CC BY-SA 3.0
2018-04-20T13:06:41.407Z
Possible reasons why a miner decided to put one in a coinbase transaction. An explanation perhaps, I've never seen this before.
arshbot
CC BY-SA 4.0
2023-11-01T02:35:28.083Z
Hi @arshbot, I edited your posts to incorporate your comment. Could you please look it over and check that I captured the essence of the comment?
Murch
<segregated-witness><coinbase-transaction><op-return>
Why would a miner put an OP_RETURN in a coinbase transaction?
arshbot
# Why would a miner put an OP_RETURN in a coinbase transaction?

(Asked by: username_0 on 2018-04-20)

I’m looking at [this coinbase transaction](https://blockchair.com/bitcoin/transaction/0bcd7a3a8caa322bcea7589b513f3dae232e4f53ae6c20a5f0ec29a8d2bf6ae9). I'm confused why there are two outputs and why one of them is labelled with OP\_RETURN.

**Tags:** segregated-witness, coinbase-transaction, op-return

> **Comments:**
> **username_1**: Are you asking about what OP_RETURN is in general (explained in detail [here](https://bitcoin.stackexchange.com/questions/29554/explanation-of-what-an-op-return-transaction-looks-like)) or why a miner decided to put one in a coinbase transaction (only the miner knows for sure)?  
> **username_0**: Possible reasons why a miner decided to put one in a coinbase transaction. An explanation perhaps, I've never seen this before.  
> **username_2**: Hi @username_0, I edited your posts to incorporate your comment. Could you please look it over and check that I captured the essence of the comment?  

---

## 2 answers

### Answer by username_2 on 2018-04-20. Score: 11 | Accepted answer

Every segwit block has one such OP\_RETURN in the coinbase transaction: It's the Merkle root of the witness tree.

When the segwit softfork was activated, this included a fix to the third-party transaction malleability issue that was present on the network before. The issue was that the signature of a transaction could be changed by any other person by inverting the S-value used in the signature. This resulted in another valid (non-standard) transaction spending the same coins to the same recipients, but a different txid.

Segwit prevented this source of transaction malleability by moving the witness program out of the input script to a separate "witness field" in the transaction ("segregated the witness") which is ignored when the txid is calculated. This means that even when signatures are changed for segwit transactions, their txid remains the same. Making the txid independent from the signature also makes it easier to build on top of unsigned transactions (since their txid doesn't change with the signature) which is e.g. useful for smart contracts employed in Lightning Network payment channels.

A block commits to all of its transactions by including the root of the Merkle tree over their txids. However, this would mean that this commitment wouldn't cover the signatures of segwit transactions as they don't contribute to the txid. To commit to the signatures, segwit introduced the a second parallel Merkle tree, built from the witness txids, i.e. a transaction id calculated over the complete transaction data including the witness program. Since the blockheader can't be extended without a hardfork, segwit blocks commit to this witness tree by including the root in an OP\_RETURN in the coinbase transaction.


---

### Answer by username_3 on 2022-10-24. Score: 0

**Another reason: *Merged Mining***

Whilst not in the OP's example coinbase transaction, another reason for `OP_RETURN` in a coinbase transaction is merge mining. A miner might follow the [merged mining specification](https://en.bitcoin.it/wiki/Merged_mining_specification#Merged_mining_coinbase) which involves placing one or more other system's block identifiers into the input script. Additionally the miner might create one or more `OP_RETURN`s with an id code and block information the other blockchain(s), according to the specification of those chains.

**Example: *block 733578 coinbase Tx***

An example, as [explained here](https://zeroknowledgedefi.com/2022/04/29/merge-mining-and-auxiliary-proof-of-work/#merge_sec6), is the block 733578 [coinbase](https://blockstream.info/nojs/tx/2a85992897c54db7baa8b474bdc03ce7867bd9d8f4b00329cedd223d9997b100?expand) [transaction](https://blockchair.com/bitcoin/transaction/2a85992897c54db7baa8b474bdc03ce7867bd9d8f4b00329cedd223d9997b100) in which the miner mined for three other blockchains (Namecoin, RSK, and Vcash, as well as BTC). The [Namecoin](https://chainz.cryptoid.info/nmc/block.dws?632997bd2735b0c7659eee5e72f1bcfd1da17d8e420576d8c5ad19fdb2451b4e.htm) (`fabe6d6d`) block is identified in the input scriptsig. RSK and Vcash blocks are included in the coinbase transaction's `OP_RETURN`s; [RSK](https://explorer.rsk.co/block/4262866?__ctab=Mining) (`52534b424c4f434b3a`) and [Vcash](https://vcash.tech/block/4869fa8eeb9618a6791a4000a6487ca1f0a4dc277b48051563ac656dd228a044) ([`b9e11b6d`](https://bitcoin.stackexchange.com/a/113524/34190)).

Per @username_2's answer here, the third `OP_RETURN` in this example is the [segregated witness merkle root](https://bitcoin.stackexchange.com/a/113523/34190) (`aa21a9ed`).

---

Interestingly, there is [no limit](https://bitcoin.stackexchange.com/a/116313/34190) to the number of `OP_RETURN`s in the coinbase transaction, other than the size of the transaction, which itself is
~only constrained by the size of the block its in.


---

