What Is a Coinbase Transaction?

By Kurt Wuckert Jr.

What Is a Coinbase Transaction?

In every Bitcoin-style block, the very first transaction has a special role. This is the coinbase transaction. It is the mechanism a mining node uses to pay itself the block reward. That reward is made up of two parts:

  • The block subsidy, which is newly issued coins.

  • The sum of all transaction fees from the transactions included in that block.

This coinbase transaction is unique to each miner because it sends the reward to an address controlled by that miner, usually expressed as a public key hash. The transaction only becomes “real” if the block that contains it is accepted by the network as valid and becomes part of the longest chain of proof of work.

Since the coinbase creates new coins directly, it does not spend any previous outputs. There is no previous transaction hash or unlocking script attached to the coinbase input. Older implementations sometimes used the “previous hash” field to embed identifying information about the node, but that information is not authoritative and can be faked.

How Other Nodes Check a Coinbase Transaction

Because the coinbase does not have normal inputs, other nodes validate it in a different way. They look at the total value in the coinbase output and compare it with the maximum allowed for that block, which is:

  • The current block subsidy, plus

  • The total fees from all other transactions in that block.

If the coinbase output tries to claim even one satoshi more than this amount, the miner is effectively trying to create extra coins outside the rules. In that case, nodes must treat the coinbase as invalid and therefore reject the block that contains it. On the other hand, if a miner pays themselves less than the full amount available, the difference is simply lost from circulation and can never be spent.

Extranonce and More Room for Mining Attempts

The coinbase transaction also contains fields that miners can change to create additional variations in the block header once the normal nonce range has been exhausted. These fields are often referred to as extranonce values.

A standard 32-bit nonce allows roughly 4.3 billion different header variants. If a miner has tried all of those and still has not found a valid hash below the target, it can change the extranonce inside the coinbase transaction. Changing that value alters the serialized coinbase transaction, which in turn changes the TXID of the coinbase and therefore the Merkle root of the block.

In pooled mining, the extranonce is also useful for coordination. The pool can assign different ranges of extranonce values to different hashing machines. This reduces the chance that multiple machines will repeat the same proof of work on identical transaction sets.

Block Subsidy and Transaction Fees

The block subsidy is programmed to decrease over time at fixed block intervals. This schedule was designed to kickstart the network with higher rewards in the early years and then phase down the subsidy as usage grows and transaction fees become the main source of income for miners.

Transaction fees are calculated from the difference between the sum of inputs and the sum of outputs across all transactions in the block. In practice, wallets choose fees using a rate per byte of transaction data. There is usually:

  • A higher fee per byte for the cost of validation and inclusion in a block.

  • A smaller fee per byte for simple relay across the network.

The total of these fees plus the subsidy describes what the miner is allowed to claim in the coinbase. This structure makes it clear that miners are paid for real work: processing and validating scripts, maintaining connectivity and constructing Merkle trees for ever larger blocks.

Coinbase, Merkle Trees and Block Linking

Once the coinbase transaction is built, its serialized form is double-hashed with SHA-256 to create its TXID. That TXID becomes the first leaf node in the block’s transaction Merkle tree. All other transaction TXIDs in the block fill out the remaining leaves.

The Merkle tree is then built layer by layer until it produces a Merkle root. This root is placed in the block header, alongside the previous block hash. The new header is what the miner hashes repeatedly in the proof of work process. When a valid proof of work is found and the block is accepted, the Merkle root in the header acts as a compact summary of all transactions in the block, including the coinbase.

As blocks are added, the hash of each block header is referenced in the next block’s header. In this way, the header chain, the Merkle roots and the coinbase transactions all cooperate to link together an ordered sequence of verified transaction sets.

How the Coinbase Changes as Transactions Are Added

As a miner collects transactions from the network to build a block, each new transaction brings its own fee. Those fees belong to the miner who eventually solves the block. However, the miner’s coinbase transaction must reflect the total of all fees included.

This creates a subtle but important dynamic: each time the miner decides to include more transactions, the raw data of the coinbase transaction must be updated to reflect the new total reward. Updating the coinbase changes its TXID, which changes the first leaf in the Merkle tree. When the first leaf changes, every interior node on that side of the tree changes, and the Merkle root changes as well.

At the same time, the right-hand side of the tree is being extended as new transactions are added, so its values are also changing. The miner is constantly rebalancing between:

  • Updating the coinbase to capture the correct fee total.

  • Recomputing the Merkle root.

  • Feeding the updated root back into the block header for further proof of work attempts.

This process continues until a header hash is found that meets the difficulty target and the block is broadcast to the network.

ELI5(ish…)

Think of a coinbase transaction as a miner’s paycheck inside each block.

  • The miner is allowed to pay themselves the fixed “salary” for that block (the subsidy) plus all the tips from users (the fees in every transaction in that block).

  • That paycheck transaction has no normal sender, because the system itself is issuing the coins. Other nodes just check that the miner did not overpay themselves.

The coinbase sits at the very beginning of the transaction list and becomes the first brick in a special tree of hashes called a Merkle tree. All the other transactions are the other bricks. The top of the tree is a single hash that summarizes everything inside the block, including the miner’s paycheck.

While the miner is building the block, new transactions keep arriving, which means more tips. Every time the miner decides to include more, they adjust their paycheck to match. That change ripples through the tree and updates the block’s summary hash. The miner then keeps trying different nonces and extra values to find a block hash that is small enough to satisfy the difficulty rules.

When they finally find a winning hash, they broadcast the block. The rest of the network can quickly verify:

  • The paycheck is not too big.

  • The summary hash matches all the transactions.

  • The hash of the header beats the difficulty target.

If all that checks out, the block is accepted, and the miner’s coinbase transaction becomes spendable later as their confirmed reward.