4

I’m looking at this coinbase transaction. I'm confused why there are two outputs and why one of them is labelled with OP_RETURN.

Improve this question
3
  • Are you asking about what OP_RETURN is in general (explained in detail here) or why a miner decided to put one in a coinbase transaction (only the miner knows for sure)?
    – Nate Eldredge
    Apr 20, 2018 at 2:27
  • Possible reasons why a miner decided to put one in a coinbase transaction. An explanation perhaps, I've never seen this before.
    – arshbot
    Apr 20, 2018 at 13:06
  • 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 ♦
    Nov 1 at 2:35

2 Answers 2

Reset to default
11

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.

Improve this answer
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 which involves placing one or more other system's block identifiers into the input script. Additionally the miner might create one or more OP_RETURNs 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, is the block 733578 coinbase transaction in which the miner mined for three other blockchains (Namecoin, RSK, and Vcash, as well as BTC). The Namecoin (fabe6d6d) block is identified in the input scriptsig. RSK and Vcash blocks are included in the coinbase transaction's OP_RETURNs; RSK (52534b424c4f434b3a) and Vcash (b9e11b6d).

Per @Murch's answer here, the third OP_RETURN in this example is the segregated witness merkle root (aa21a9ed).

Interestingly, there is no limit to the number of OP_RETURNs in the coinbase transaction, other than the size of the transaction, which itself is ~only constrained by the size of the block its in.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.