<blockquote>
  <p>1) How the coinbase could have more than 12.5 BTC?</p>
</blockquote>

<p>Because of transaction fees</p>

<blockquote>
  <p>2) What is the purpose of the RETURN PUSHDATA(36)(...),</p>
</blockquote>

<p>The purpose is to embed data in the blockchain. No bitcoins were burned (and no transaction fee), so that's a free way to embed data in the blockchain.</p>

CC BY-SA 4.0
2018-09-11T13:45:03.813Z
It's technically not free, though because the fee is based on satoshi/kB and the extra data adds some to the size of the tx.
JBaczuk
CC BY-SA 4.0
2018-09-11T13:47:07.157Z
@JBaczuk It's a coinbase tx.
MCCCS
CC BY-SA 4.0
2018-09-11T13:48:45.437Z
you're right, but it's only free for coinbase not any tx with OP_RETURN
JBaczuk
CC BY-SA 4.0
2018-09-11T14:11:56.587Z
@JBaczuk embed data for what, fun or get the right hash of the block(that should be in the coinbase input)? Will UXTO pool hold this output in memory?
Carpemer
CC BY-SA 4.0
2018-09-11T14:17:17.753Z
@Capemer It will not store unspendable outputs, there is a check that immediately prunes UTXO that start with `OP_RETURN`: https://github.com/bitcoin/bitcoin/commit/ec84e81e8383b3b1e1ef4a6dbcb088193d8de5d7
JBaczuk
CC BY-SA 4.0
2018-09-11T14:20:15.293Z
@JBaczuk, then what is the purpose of this?
Carpemer
CC BY-SA 4.0
2018-09-11T14:23:01.063Z
People abuse it to store any data they want stored "permanently".
JBaczuk
CC BY-SA 4.0
2018-09-11T20:23:38.530Z
In this case, that output is part of segwit. It is for the witness data commitment. See BIP 141: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Commitment_structure. The reason OP_RETURN is used is so that the UTXO will not be added to the UTXO set as it is provably unspendable.
Ava Chow
CC BY-SA 4.0
2018-09-11T13:43:18.223Z
2018-09-11T13:43:18.223Z
MCCCS
<blockquote>
  <p>2) What is the purpose of the RETURN PUSHDATA(36)(...), actually, in
  theory, this output can never be consumed by anyone, because there is
  no OP_CHECKSIG or similar OP at the end to return true in the Script
  stack.</p>
</blockquote>

<p>From my understanding, this is mandatory in SegWit enabled blocks.</p>

<p>The second script (starting with <code>OP_RETURN</code>) provides the merkleroot of the witness tree. IIRC it was created this way to prevent a hard fork. Adding an extra field into the block header would defiantly require a hard fork, so the best alternative was to place the data somewhere already available in all current blocks. Since the <code>OP_RETURN</code> script will never be a valid output, it will simply be ignored.</p>

<p>Reference and more information: <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure" rel="nofollow noreferrer">BIP141 Commitment structure</a> and <a href="https://bitcoin.stackexchange.com/a/74183/85140">a similar question</a></p>

CC BY-SA 4.0
2018-09-11T18:35:48.750Z
2018-09-11T18:41:50.073Z
2018-09-11T18:41:50.073Z
Mason Ticehurst
<p>As MCCCS said, the mining reward is composed of block subsidy and transaction fees.</p>
<p>The second output on the coinbase commits to the witness data in the block.
As you might know, the blockheader commits to transactions in the block via the Merkle root field. The Merkle root is produced by building a Merkle tree from the TXIDs (transaction identifiers) of all transactions. Since TXIDs do not commit to the witness data, the Merkle root alone would leave the witness data mutable.</p>
<p>Every block that includes any segwit transactions must therefore the <a href="https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure" rel="nofollow noreferrer"><em>Witness Commitment</em></a>. The Witness Commitment takes the form of a 36-byte <code>OP_RETURN</code> output on  the coinbase transaction that has the prefix <code>aa21a9ed</code> followed by the 32-byte hash that is the Merkle root of the transactions WTXIDs (witness transaction identifiers). The WTXIDs are produced from the whole transaction, including the witness.</p>

CC BY-SA 4.0
2022-04-29T18:11:39.613Z
2022-04-29T18:11:39.613Z
Murch
<p>The example is in here:
<a href="https://www.blockchain.com/btc/tx/63910fdfa84db96bd1f28fead4c32f97388d5368c10059d035aac3c5f72fcdc0" rel="nofollow noreferrer">https://www.blockchain.com/btc/tx/63910fdfa84db96bd1f28fead4c32f97388d5368c10059d035aac3c5f72fcdc0</a></p>
<p>Actually, there are two outputs
<code>DUP HASH160 PUSHDATA(20)[78ce48f88c94df3762da89dc8498205373a8ce6f] EQUALVERIFY CHECKSIG and  RETURN PUSHDATA(36)[aa21a9ed9463ee420b10cbad1d997bfa132a89dc9ba3de04e7233e6e6954f1bc339ebb1a]</code></p>
<p>The strange point is the first output has 12.77303443 BTC, the second is 0 BTC.</p>
<p>There are two questions about this transaction.</p>
<ol>
<li>How the coinbase could have more than 12.5 BTC?</li>
<li>What is the purpose of the <code>RETURN PUSHDATA(36)(...)</code>, actually, in theory, this output can never be consumed by anyone, becuase there is no <code>OP_CHECKSIG</code> or similar OP at the end to return true in the Script stack.</li>
</ol>

<transactions><script><coinbase-transaction>
What is the purpose of the script like RETURN PUSHDATA(36)(...)
Carpemer
# What is the purpose of the script like RETURN PUSHDATA(36)(...)

(Asked by: username_0 on 2018-09-11)

The example is in here:
<https://www.blockchain.com/btc/tx/63910fdfa84db96bd1f28fead4c32f97388d5368c10059d035aac3c5f72fcdc0>

Actually, there are two outputs
`DUP HASH160 PUSHDATA(20)[78ce48f88c94df3762da89dc8498205373a8ce6f] EQUALVERIFY CHECKSIG and RETURN PUSHDATA(36)[aa21a9ed9463ee420b10cbad1d997bfa132a89dc9ba3de04e7233e6e6954f1bc339ebb1a]`

The strange point is the first output has 12.77303443 BTC, the second is 0 BTC.

There are two questions about this transaction.

1. How the coinbase could have more than 12.5 BTC?
2. What is the purpose of the `RETURN PUSHDATA(36)(...)`, actually, in theory, this output can never be consumed by anyone, becuase there is no `OP_CHECKSIG` or similar OP at the end to return true in the Script stack.

**Tags:** transactions, script, coinbase-transaction


---

## 3 answers

### Answer by username_1 on 2018-09-11. Score: 3 | Accepted answer

> 1) How the coinbase could have more than 12.5 BTC?

Because of transaction fees

> 2) What is the purpose of the RETURN PUSHDATA(36)(...),

The purpose is to embed data in the blockchain. No bitcoins were burned (and no transaction fee), so that's a free way to embed data in the blockchain.

> **Comments:**
> **username_2**: It's technically not free, though because the fee is based on satoshi/kB and the extra data adds some to the size of the tx.  
> **username_1**: @username_2 It's a coinbase tx.  
> **username_2**: you're right, but it's only free for coinbase not any tx with OP_RETURN  
> **username_0**: @username_2 embed data for what, fun or get the right hash of the block(that should be in the coinbase input)? Will UXTO pool hold this output in memory?  
> **username_2**: @Capemer It will not store unspendable outputs, there is a check that immediately prunes UTXO that start with `OP_RETURN`: https://github.com/bitcoin/bitcoin/commit/ec84e81e8383b3b1e1ef4a6dbcb088193d8de5d7  
> **username_0**: @username_2, then what is the purpose of this?  
> **username_2**: People abuse it to store any data they want stored "permanently".  
> **username_3**: In this case, that output is part of segwit. It is for the witness data commitment. See BIP 141: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Commitment_structure. The reason OP_RETURN is used is so that the UTXO will not be added to the UTXO set as it is provably unspendable.  

---

### Answer by username_4 on 2018-09-11. Score: 3

> 2) What is the purpose of the RETURN PUSHDATA(36)(...), actually, in
> theory, this output can never be consumed by anyone, because there is
> no OP\_CHECKSIG or similar OP at the end to return true in the Script
> stack.

From my understanding, this is mandatory in SegWit enabled blocks.

The second script (starting with `OP_RETURN`) provides the merkleroot of the witness tree. IIRC it was created this way to prevent a hard fork. Adding an extra field into the block header would defiantly require a hard fork, so the best alternative was to place the data somewhere already available in all current blocks. Since the `OP_RETURN` script will never be a valid output, it will simply be ignored.

Reference and more information: [BIP141 Commitment structure](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure) and [a similar question](https://bitcoin.stackexchange.com/a/74183/85140)


---

### Answer by username_5 on 2022-04-29. Score: 2

As username_1 said, the mining reward is composed of block subsidy and transaction fees.

The second output on the coinbase commits to the witness data in the block.
As you might know, the blockheader commits to transactions in the block via the Merkle root field. The Merkle root is produced by building a Merkle tree from the TXIDs (transaction identifiers) of all transactions. Since TXIDs do not commit to the witness data, the Merkle root alone would leave the witness data mutable.

Every block that includes any segwit transactions must therefore the [*Witness Commitment*](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#commitment-structure). The Witness Commitment takes the form of a 36-byte `OP_RETURN` output on the coinbase transaction that has the prefix `aa21a9ed` followed by the 32-byte hash that is the Merkle root of the transactions WTXIDs (witness transaction identifiers). The WTXIDs are produced from the whole transaction, including the witness.


---

