What is the purpose of the script like RETURN PUSHDATA(36)(...)

Question

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.

Answer 1

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.

Answer 2

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

Answer 3

As MCCCS 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. 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.