Coinbase Transaction

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.

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:

• It must be the first transaction in the block.
• It must only contain one input.
  • The TXID must be all zeros.
  • The VOUT must be set to the maximum value.
  • BIP 34: The start of the ScriptSig must contain the height of the current block it's included in.
  • BIP 141: If the block contains segwit transactions, the witness field must contain a 32-byte witness reserved value.
• It can contain multiple outputs (as normal).
  • The total value of the outputs must not be greater than the sum of the block reward (block subsidy + transaction fees).
  • BIP 141: If the block contains segwit transactions, one of the outputs must contain the wTXID commitment.

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"
}

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:

• The block subsidy was 5000000000 sats (50 BTC).
• The other 350000 sats was the fees collected from the other 10 transactions included in the block

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"
}

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

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:

• The block subsidy was 2500000000 sats (25 BTC).
• The other 1166059 sats was the fees collected from the other 45 transactions included in the block

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"
}

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 block subsidy was 1250000000 sats (12.5 BTC).
• The other 6517 sats was the fees collected from the other 3 transactions included in the block

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:

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

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:

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.

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).

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:

• a8d0c0184dde994a09ec054286f1ce581bebf46446a512166eae7628734ea0a5 – Coinbase transaction in block 400,000.
• db3aa6d43629953a5af092a480259eab383b2f86c13fb559eb49ff92c3a43a6d – Coinbase transaction output spent in block 400,101.

Notes

• Coins can be lost forever if a miner does not claim the full block reward. For example, the block subsidy for block 526,591 was 12.5 BTC, but the miner only sent themselves 6.25 BTC in the output of the coinbase transaction, so they effectively lost out on 6.25 BTC. There is no reason why a miner would want to do this, but it just goes to show coins can be lost forever if a miner does not construct their coinbase transaction correctly to collect the full block subsidy and the fees from the transactions included the block.

Resources

• Coinbase transaction's 100-block cooldown period
• What happens when a miner does not claim all fees/generated coins?