Coinbase transaction

Every block starts with a coinbase transaction. The miner places it there to claim the block reward, which is the new subsidy plus the fees from the other transactions. It is the only transaction that can create new bitcoin, and it has no real input to spend. Its output is what makes new coins exist.

The coinbase has the same basic shape as any transaction, but a few rules apply only to it. This page covers those rules, two real examples, and the witness commitment that SegWit added. For the short definition, see the coinbase word page.

What rules does a coinbase transaction follow?

A coinbase transaction must meet these requirements, and each one comes from a consensus rule or a soft fork.

• It is the first transaction in the block.
• It has exactly one input. Its txid is 32 zero bytes, and its vout is ffffffff, the maximum value. Nothing is spent, so there is nothing to unlock.
• Its scriptSig starts with the block height, under BIP 34. Version 2 blocks began at block 227,836, and the height rule has applied since block 227,931. The whole scriptSig must be between 2 and 100 bytes.
• If the block has SegWit transactions, the input's witness must hold a 32-byte reserved value, and one output must carry the witness commitment. Both come from BIP 141.
• It can have several outputs, and the total they pay out must not be more than the subsidy plus the fees.

The rest is up to the miner. The scriptSig has room for arbitrary data after the height, so miners put in a pool tag or an extra nonce.

What does a real coinbase look like?

Block 400,021 is a good example of the pre-SegWit form. The coinbase has one blank input and one output:

Field	Value	Meaning
Input txid	32 zero bytes	No previous transaction
Input vout	ffffffff	The maximum value, as required
ScriptSig	27 bytes	The height and some free data
Output 0	2,501,166,059 sats	25 BTC subsidy plus 0.01166059 BTC fees
Output script	P2PKH	Locked to the miner's address

The scriptSig decodes into four pushes. The first one is the height, and it is the only part the consensus rules require:

03 951a06                    push 3 bytes: 951a06, little-endian, = 400,021
04 f15ccf56                  push 4 bytes: extra nonce
09 013803062b9b5a0100        push 9 bytes: extra nonce
07 2f425443432f20            push 7 bytes: the ASCII pool tag "/BTCC/", then a space

The height is written little-endian, so 951a06 reads as 061a95 in big-endian, and that is 400,021 in decimal. Only the first push is required. Everything after it is the miner's choice.

Why does the height go in the coinbase?

Before BIP 34, nothing in a coinbase tied it to its block. Two coinbase transactions could come out identical, and so share a txid. Putting the height in the first push gives every block a coinbase of its own. Each height appears once, so each coinbase txid is different.

How does a SegWit coinbase differ?

Block 538,403 is a SegWit example. Its coinbase has three differences from the pre-SegWit one.

1. The transaction has a witness. Its single input carries one stack item, the 32-byte witness reserved value, which is all zeros here.
2. It has two outputs. The first pays the subsidy of 12.5 BTC plus 6,517 sats in fees. The second pays nothing and carries the commitment.
3. The second output is an OP_RETURN with the commitment in it.

The commitment is what ties the witness data into the block. Here is how it is made.

1. Take the wTXID of every transaction in the block. The coinbase counts as 32 zero bytes, because its own witness cannot be part of the commitment it creates.
2. Build a merkle root from those wTXIDs, in natural byte order. This is the witness root. For block 538,403 it is 8a8cc0634b8847eb38e7e884970deda26c2dfeefd923c4eba08ca11d110bb6e3.
3. Compute HASH256 of the witness root followed by the 32-byte reserved value. For block 538,403 this gives faa194df59043645ba0f58aad74bfd5693fa497093174d12a4bb3b0574a878db.
4. Put that hash in the second output, after a 6-byte header 6a24aa21a9ed. 6a is OP_RETURN, 24 is a 36-byte push, and aa21a9ed marks it as a witness commitment.

This Python sketch makes the same calculation. It uses the wTXIDs in natural byte order, the reverse of the explorer form. Run on the four wTXIDs of block 538,403, it returns the commitment above.

import hashlib

def hash256(data: bytes) -> bytes:
    return hashlib.sha256(hashlib.sha256(data).digest()).digest()

def witness_commitment(wtxids: list[bytes]) -> bytes:
    """wtxids in natural byte order; the coinbase's entry is 32 zero bytes."""
    level = list(wtxids)
    while len(level) > 1:
        if len(level) % 2:                       # an odd level repeats its last entry
            level.append(level[-1])
        level = [hash256(level[i] + level[i + 1]) for i in range(0, len(level), 2)]
    return hash256(level[0] + b"\x00" * 32)      # the reserved value is 32 zero bytes

If a block has no SegWit transactions, the coinbase needs neither the reserved value nor the commitment. That is why blocks mined before SegWit activated at block 481,824 do not carry one.

When can you spend the coinbase?

The outputs of a coinbase transaction cannot be spent until the block is 100 blocks deep in the chain. That is the coinbase maturity rule, set in the consensus code.

The reason is reorganization. A short chain reorganization, of one or two blocks, is common. If a coinbase were spent right away and its block was dropped, every transaction that spent it would become invalid too. The coinbase cannot simply come back either. Its height is part of its txid, so a block at a different height would have a different coinbase. Waiting 100 blocks makes that outcome practically impossible.

Coinbase maturity protects against ordinary reorganizations. A deep attack, such as a 51% attack, can rewrite more than that, so the rule is no guarantee against one. It is a practical safety margin.

Can a miner claim less than the reward?

Yes, and some have. The coinbase may pay out less than the subsidy plus fees, and the difference is lost for good, because no one can spend coins that no output holds. Block 526,591 is one case. Its subsidy was 12.5 BTC, but its coinbase paid out only 6.25 BTC. A miner would have no reason to do this on purpose, so it is usually a mistake in the mining software.

The rule only sets an upper limit. A coinbase that claims more than the subsidy plus fees makes its block invalid, so every node rejects it.

Which order should you read this section in?

Read this page after the candidate block page, which explains why the coinbase is built last. Then read the block reward page for the amounts it can claim.