1

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.

2

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.

  • 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 Sep 11 '18 at 13:45
  • @JBaczuk It's a coinbase tx. – MCCCS Sep 11 '18 at 13:47
  • you're right, but it's only free for coinbase not any tx with OP_RETURN – JBaczuk Sep 11 '18 at 13:48
  • @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? – Capemer Sep 11 '18 at 14:11
  • 1
    In this case, that output is part of segwit. It is for the witness data commitment. See BIP 141: github.com/bitcoin/bips/blob/master/…. The reason OP_RETURN is used is so that the UTXO will not be added to the UTXO set as it is provably unspendable. – Andrew Chow Sep 11 '18 at 20:23
1

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 and a similar question

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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