Coinbase Transaction

Claiming the block reward

Diagram showing the coinbase transaction as the first transaction in the block claiming the block reward (block subsidy + fees).

A coinbase transaction is the first transaction in a block.

It's placed there by the miner when they construct their candidate block so they can claim the block reward (block subsidy + fees) if they are successful in mining the block.

It's a special type of transaction that has a single blank input. So in other words, the outputs from coinbase transactions are the source of new bitcoins.

Diagram showing the outputs of coinbase transactions in the blockchain as the source of all new bitcoins.

Requirements

What's different about a coinbase transaction?

A coinbase transaction has the same basic structure as a normal transaction, but it has a few special requirements:

So basically a coinbase transaction just has a blank input, and then locks the block reward to a new output.

Over time there have been a few additional requirements placed on the coinbase transaction due to upgrades, but the basic structure of the transaction has remained the same.

Examples

What does a coinbase transaction look like?

Here are some examples of typical coinbase transactions you'll find in the blockchain.

1. Basic

Height: 0 to 227,835

This is the coinbase transaction for block 150,007:

01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0804233fa04e028b12ffffffff0130490b2a010000004341047eda6bd04fb27cab6e7c28c99b94977f073e912f25d1ff7165d9c95cd9bbe6da7e7ad7f2acb09e0ced91705f7616af53bee51a238b7dc527f2be0aa60469d140ac00000000
{
  "version": "01000000",
  "inputcount": "01",
  "inputs": [
    {
      "txid": "0000000000000000000000000000000000000000000000000000000000000000",
      "vout": "ffffffff",
      "scriptsigsize": "08",
      "scriptsig": "04233fa04e028b12",
      "sequence": "ffffffff"
    }
  ],
  "outputcount": "01",
  "outputs": [
    {
      "amount": "30490b2a01000000",
      "scriptpubkeysize": "43",
      "scriptpubkey": "41047eda6bd04fb27cab6e7c28c99b94977f073e912f25d1ff7165d9c95cd9bbe6da7e7ad7f2acb09e0ced91705f7616af53bee51a238b7dc527f2be0aa60469d140ac"
    }
  ],
  "locktime": "00000000"
}

Transaction: 18a16d322b235f636ab90e62e79a9f20a0b9c14e8da51e9dc0974f99f82ee444

As you can see, it only has one blank input. The TXID is set to all zeros and the VOUT is set to the maximum value of 0xffffffff. This is the basic requirement for all coinbase transactions.

The miner was free to put any data they like in the ScriptSig (because there is nothing to be unlocked). These bytes do not decode to any ASCII text in particular, so the miner was most likely just using this field as an ExtraNonce (and not using it to store any miner tag or message).

There is only one output, and it has an amount of 5000350000 sats:

They then locked this output to their own public key using a P2PK locking script (which is the typical locking script used for coinbase transactions early on in the blockchain).

2. Height in Coinbase

Height: 227,836+ (BIP 34)

This is the coinbase transaction for block 400,021:

01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff1b03951a0604f15ccf5609013803062b9b5a0100072f425443432f200000000001ebc31495000000001976a9142c30a6aaac6d96687291475d7d52f4b469f665a688ac00000000
{
  "version": "01000000",
  "inputcount": "01",
  "inputs": [
    {
      "txid": "0000000000000000000000000000000000000000000000000000000000000000",
      "vout": "ffffffff",
      "scriptsigsize": "1b",
      "scriptsig": "03951a0604f15ccf5609013803062b9b5a0100072f425443432f20",
      "sequence": "00000000"
    }
  ],
  "outputcount": "01",
  "outputs": [
    {
      "amount": "ebc3149500000000",
      "scriptpubkeysize": "19",
      "scriptpubkey": "76a9142c30a6aaac6d96687291475d7d52f4b469f665a688ac"
    }
  ],
  "locktime": "00000000"
}

Transaction: 2844c6f512f5609705c90c1603e9258779a0fe5e200664b0c1a1abad33da637e

Once again this coinbase transaction has one blank input.

In addition, due to BIP 34, from block height 227,836 onwards miners are required to put the height of the current block at the start of the ScriptSig. This is the decoded ScriptSig:

OP_PUSHBYTES_3
951a06
OP_PUSHBYTES_4
f15ccf56
OP_PUSHBYTES_9
013803062b9b5a0100
OP_PUSHBYTES_7
2f425443432f20
03951a0604f15ccf5609013803062b9b5a0100072f425443432f20
Script

This ScriptSig contains four separate data pushes:

  1. 951a06 – This is the current block height in little-endian byte order. So if we convert that to big-endian we get 061a95, and if we convert that from hexadecimal to decimal we get 400021.
    Little-Endian
  2. f15ccf56 – Unknown. These bytes do not decode to any particular ASCII text, so it may have been an ExtraNonce.
  3. 013803062b9b5a0100 – Unknown. These bytes do not decode to any particular ASCII text, so it may have been an ExtraNonce.
  4. 2f425443432f20 – This is ASCII-encoded bytes for the text string "/BTCC/", which is the miner's tag.
    ASCII

Only the first data push for the current block height was required. The miner was free to include any data they liked in the ScriptSig after that.

There is also only one output with a value of 2501166059 sats:

This output was then locked up using a P2PKH locking script.

So the only real change between this coinbase transaction and a basic one is the height at the start of the ScriptSig.

The reason for including the height in the coinbase transaction is to prevent duplicate TXIDs.

3. Segwit

Height: 481,824+ (BIP 141)

This is the coinbase transaction for block 538,403:

010000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff2503233708184d696e656420627920416e74506f6f6c373946205b8160a4256c0000946e0100ffffffff02f595814a000000001976a914edf10a7fac6b32e24daa5305c723f3de58db1bc888ac0000000000000000266a24aa21a9edfaa194df59043645ba0f58aad74bfd5693fa497093174d12a4bb3b0574a878db0120000000000000000000000000000000000000000000000000000000000000000000000000
{
  "version": "01000000",
  "marker": "00",
  "flag": "01",
  "inputcount": "01",
  "inputs": [
    {
      "txid": "0000000000000000000000000000000000000000000000000000000000000000",
      "vout": "ffffffff",
      "scriptsigsize": "25",
      "scriptsig": "03233708184d696e656420627920416e74506f6f6c373946205b8160a4256c0000946e0100",
      "sequence": "ffffffff"
    }
  ],
  "outputcount": "02",
  "outputs": [
    {
      "amount": "f595814a00000000",
      "scriptpubkeysize": "19",
      "scriptpubkey": "76a914edf10a7fac6b32e24daa5305c723f3de58db1bc888ac"
    },
    {
      "amount": "0000000000000000",
      "scriptpubkeysize": "26",
      "scriptpubkey": "6a24aa21a9edfaa194df59043645ba0f58aad74bfd5693fa497093174d12a4bb3b0574a878db"
    }
  ],
  "witness": [
    {
      "stackitems": "01",
      "0": {
        "size": "20",
        "item": "0000000000000000000000000000000000000000000000000000000000000000"
      }
    }
  ],
  "locktime": "00000000"
}

Transaction: 31e9370f45eb48f6f52ef683b0737332f09f1cead75608021185450422ec1a71

Again, this coinbase transaction contains one blank input.

This is the decoded ScriptSig for this input:

OP_PUSHBYTES_3
233708
OP_PUSHBYTES_24
4d696e656420627920416e74506f6f6c373946205b8160a4
OP_PUSHBYTES_37
6c0000946e0100
03233708184d696e656420627920416e74506f6f6c373946205b8160a4256c0000946e0100

This ScriptSig contains three separate data pushes:

  1. 233708 – This contains the block height 538403 in little-endian byte order.
    Little-Endian
  2. 4d696e656420627920416e74506f6f6c373946205b8160a4 – This contains the ASCII-encoded string "Mined by AntPool79F [`".
    ASCII
  3. 6c0000946e0100 – This was probably an ExtraNonce.

The witness for this input contains the required 32-byte witness reserved value. This was all zeros, as this was not used for committing any extra data to the block:

0000000000000000000000000000000000000000000000000000000000000000

This coinbase transaction then contains two outputs:

The first output was used to claim the block reward of 1250006517 sats.

The second output was used for the required wTXID commitment. To calculate this, you need to start by gathering all of the wTXIDs for the transactions included in the block:

0000000000000000000000000000000000000000000000000000000000000000 6440ffe0a58cbec4692d075bc74877cdf7554a25eee5a02fa6ff3bb55dbb0802 9e4fa066c9587e65845065a6b5ad02cbec6cfdad8b0158953dcee086ff420ffd 57661a181f4762861fc2bc5c6001c27b54e26992e845b4742a6f0f867609b2c2

The witness root hash (merkle root for all of the wTXIDs) for this block was therefore:

Merkle Root

8a8cc0634b8847eb38e7e884970deda26c2dfeefd923c4eba08ca11d110bb6e3

When calculating the witness root hash, the wTXID for the coinbase transaction must be set to all zeros to avoid a circular reference.

If you concatenate and HASH256 the witness root hash with the witness reserved value you get the wTXID commitment:

HASH256

faa194df59043645ba0f58aad74bfd5693fa497093174d12a4bb3b0574a878db

This was then placed in the ScriptPubKey for the second output:

OP_RETURN
OP_PUSHBYTES_36
aa21a9edfaa194df59043645ba0f58aad74bfd5693fa497093174d12a4bb3b0574a878db
6a24aa21a9edfaa194df59043645ba0f58aad74bfd5693fa497093174d12a4bb3b0574a878db

If you look closely you'll see that wTXID commitment is at the end of the data push. It's prepended with the commitment header aa21a9ed so that we know that this ScriptPubKey contains the wTXID commitment.

This ScriptPubKey also starts with OP_RETURN, which means this output is unspendable, but that's fine as it doesn't contain any satoshis and is merely used for the wTXID commitment.

So basically, all coinbase transactions since the segwit upgrade need to include a witness reserved value in the witness field for the input, and then use that along with a witness root hash to put a wTXID commitment in the ScriptPubKey of one of the outputs in the transaction.

All of this is just part of committing the extra data from segwit transactions to the block.

If the block does not contain any segwit transactions, the coinbase transaction does not need to include the witness reserved value in the witness or put a wTXID commitment in one of the outputs. Block 526,637 is an example.

Coinbase Maturity

When can you spend a coinbase transaction?

The output(s) of a coinbase transaction can only be spent after the transaction is 100 blocks deep in the blockchain.

Why? Because if a miner spent their coinbase transaction output immediately, and there was a chain reorganisation which meant that the block that included that coinbase transaction was removed from the blockchain, then that transaction and all of its descendants would become invalid.

Diagram showing transactions becoming invalid due to the coinbase transaction being removed from the longest chain due to a chain reorganisation.

This is bad, because all of those child transactions depend upon that single coinbase transaction.

If that coinbase transaction gets moved out of the blockchain, there is no way for that exact same coinbase transaction to re-enter the blockchain later on (because it contains the height, and changing the height would change its TXID). Therefore, all of those child transactions become permanently invalid, which would be annoying.

So by waiting 100 blocks you can be confident that the coinbase transaction is set in stone, and so it's almost impossible that a coinbase transaction will be removed from the blockchain after it's 100 blocks deep (chain reorganisations are typically only 1 or 2 blocks deep).

Diagram showing transactions avoiding becoming invalid due to a chain reorganisation as the coinbase transaction is 101 block deep in the longest chain.

The coinbase maturity setting be found in consensus.h.

The coinbase transaction could be removed after 100 blocks due to a 51% attack. However, the 100-block coinbase maturity rule is just there to protect against problems caused by typical chain reorganisations.

Example

The coinbase transaction in block 400,000 was spent at the earliest opportunity in block 400,101:

Notes

Resources