01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0804233fa04e028b12ffffffff0130490b2a010000004341047eda6bd04fb27cab6e7c28c99b94977f073e912f25d1ff7165d9c95cd9bbe6da7e7ad7f2acb09e0ced91705f7616af53bee51a238b7dc527f2be0aa60469d140ac00000000
Coinbase Transaction
Claiming the block reward
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.
- Miners are free to put custom data in the ScriptSig field. Seeing as they do not need to actually unlock anything, they usually use this field for their own miner "tag" (to identify who mined the block), or sometimes for some sort of message.
- The block reward can be sent to multiple locations. For example, the coinbase transaction in block 829,513 split the block reward across 17 outputs.
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:
{ "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:
- 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" }
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
This ScriptSig contains four separate data pushes:
951a06
– This is the current block height in little-endian byte order. So if we convert that to big-endian we get061a95
, and if we convert that from hexadecimal to decimal we get 400021.
Little-Endianf15ccf56
– Unknown. These bytes do not decode to any particular ASCII text, so it may have been an ExtraNonce.013803062b9b5a0100
– Unknown. These bytes do not decode to any particular ASCII text, so it may have been an ExtraNonce.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" }
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:
233708
– This contains the block height 538403 in little-endian byte order.
Little-Endian4d696e656420627920416e74506f6f6c373946205b8160a4
– This contains the ASCII-encoded string "Mined by AntPool79F [`".
ASCII6c0000946e0100
– 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:
0000000000000000000000000000000000000000000000000000000000000000
6440ffe0a58cbec4692d075bc74877cdf7554a25eee5a02fa6ff3bb55dbb0802
9e4fa066c9587e65845065a6b5ad02cbec6cfdad8b0158953dcee086ff420ffd
57661a181f4762861fc2bc5c6001c27b54e26992e845b4742a6f0f867609b2c2
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.