Progress pill
The Bitcoin mining incentive system

The coinbase transaction

Introduction to Bitcoin mining

The coinbase transaction

  • How the coinbase transaction works
  • The basic structure of the coinbase transaction
  • Other coinbase uses
  • The maturity period
In the previous chapters, we presented two important points. Firstly, the miner who succeeds in producing and distributing a valid block receives a reward. On the other hand, we saw that this reward is made up of two distinct elements:
  • a block subsidy (bitcoins created ex nihilo, the maximum amount of which is set by the protocol and gradually reduced via halvings);
  • all transaction fees paid by users whose transactions have been included in the block.
One question remains, however: by what mechanism does the miner collect this reward in Bitcoin? This is precisely the role of a particular transaction called a "coinbase".

How the coinbase transaction works

As we saw in the first part of the course, each Bitcoin block contains a list of pending transactions that it will confirm. The very first of these is always the coinbase transaction. It is what allows the winning miner to receive their reward.
At first glance, it looks like a classic Bitcoin transaction: it has a TXID, outputs, and is included in the block's Merkle tree. However, it differs in one important respect: it doesn't spend any existing UTXO.
In a classic Bitcoin transaction, inputs reference previous unspent outputs (UTXOs), which provide the input value. Outputs then redistribute this value to new UTXOs, with new spending conditions. In other words, to send bitcoins, you must already own them. The coinbase transaction, on the other hand, consumes no bitcoins in input: it creates bitcoins in output directly from scratch.
It is precisely this mechanism that enables new bitcoins to be introduced into circulation via the block subsidy, and credits the miner with the fees associated with the transactions included in the block. The coinbase transaction cannot reference a real existing UTXO (in fact, it references a fictitious UTXO), since its role is precisely to create part of the value (the subsidy) and recover the other part (the fees), without receiving them from a previous transaction. For the whole system to remain consistent, the portion corresponding to fees must exactly equal the sum of bitcoins consumed in inputs but not recreated in outputs in the other transactions of the block.
This transaction is not optional. A block that does not contain a coinbase transaction is invalid and will be systematically rejected by network nodes.
⚠️ Please note: the term "coinbase" has no connection with the exchange platform of the same name. In Bitcoin, "coinbase" historically refers to the transaction that creates the block reward. The company has simply adopted this term for its name.
The coinbase transaction actually fulfils several roles simultaneously:
  • The first is the one we have just detailed: it assigns to the miner the reward they are entitled to for having produced a valid block.
  • Its second, more technical, role is to anchor the cryptographic commitment to the witnesses (signatures) of the SegWit transactions included in the block.
  • A third role, this time not directly protocol-related but linked to the modern industrialization of mining, is that the coinbase is now frequently used to anchor arbitrary technical data. This data is generally linked to the operation of mining pools and their internal organization.
To help you understand these different uses, we'll now take a closer look at the structure of the coinbase transaction.

The basic structure of the coinbase transaction

A coinbase transaction must contain exactly one input. For simplicity's sake, we sometimes say that it has no input, because this input spends no real UTXO. In reality, there is an input with a referenced source, but it deliberately points to a non-existent UTXO.
As we have already seen, every Bitcoin transaction must consume UTXOs as input in order to create valid outputs. In the Bitcoin transaction, this consumption takes the form of referencing an existing UTXO as input. This referencing is done simply by indicating the identifier of the previous transaction (the one in which the UTXO was created), as well as its index among the outputs of this transaction. In concrete terms, a UTXO is defined by a hash (the previous TXID) and an index.
But in the case of the coinbase transaction, instead of referencing a real existing UTXO, the input must necessarily point to this particular fake UTXO, with a TXID full of zeros, which does not correspond to any real TXID:
0000000000000000000000000000000000000000000000000000000000000000
Directly followed by the false index:
0xffffffff
In the basic Bitcoin protocol, as described in Satoshi Nakamoto, this false input is the only constraint imposed on the coinbase transaction.
Like any UTXO referenced in a transaction's input, it is associated with a scriptSig field. In a conventional transaction, this scriptSig field contains the elements needed to satisfy the scriptPubKey and thus unlock the spent UTXO. But in the particular case of coinbase, since the UTXO referenced is deliberately fictitious, the scriptSig field is entirely free. Miners can therefore enter any data they like. We’ll look later at how this freedom is used.
In addition to this false input, there are one or more perfectly standard outputs, which enable the miner to collect the bitcoins from the reward on one of their Bitcoin addresses. These outputs are UTXOs locked by a scriptPubKey (e.g. a script pointing to an address controlled by the miner or the pool). The only peculiarity here lies in the rule for calculating their value: the total sum of the coinbase's outputs must never exceed the maximum subsidy allowed, to which the block fees are added.
Historically, then, the coinbase transaction is boiled down to this simple scheme: a fake input referencing a non-existent UTXO, and one or more outputs designed to distribute the block reward to the winning miner. Today, however, the coinbase is no longer limited to this distribution role. Its special position in the block and the great flexibility of its structure have led to new uses, both in the protocol itself and in mining pool management mechanisms.

Other coinbase uses

Over time, the coinbase transaction has become a particularly convenient insertion point for integrating a variety of information useful for mining and for the block structure itself. Let's take a look at them to better understand the overall coinbase organization.

The BIP-34

BIP-34 is a fork soft deployed in March 2013, starting with block 227,930, which introduced version 2 of Bitcoin blocks. This new version requires each block to include, in the scriptSig of the coinbase transaction, the height of the block being created.
On the one hand, this evolution clarifies the way in which the network agrees to evolve block structure and consensus rules. Secondly, it ensures the uniqueness of each block and coinbase transaction.
Thus, the coinbase's scriptSig is not totally free. Since the activation of BIP-34, it is simply constrained to start with the height of the block in which this coinbase transaction is included.

The extra-nonce

As we saw in the first chapters of this course, the miner has a 32-bit nonce field in the block header, which they modify by trial and error to find a hash less than or equal to the target. This 32-bit space already allows a very large number of combinations to be explored, but when mining difficulty is high, this range can be fully exhausted in a relatively short time and thus may yield no combination that produces a valid hash. If all possible values of the nonce have been tested without success, the miner must then modify another element to change the block header and start a new series of attempts.
As the coinbase transaction offers a free field via the scriptSig of its input, the solution used to extend the nonce's space is to exploit part of this scriptSig. This is generally referred to as the extra-nonce. By modifying the extra-nonce, the miner modifies the coinbase's scriptSig, i.e. the transaction identifier, then the Merkle root of the block, and finally the block header itself. In this way, they obtain a new search space of hashes to explore, without having to modify the other components of their candidate block.

Identifying pools and miners

Today, a very large proportion of the world's hashrate is organized in mining pools. These structures bring together individual miners to combine their work and reduce the variance of their income.
For operational reasons, mining pools also exploit the free field of the coinbase input's scriptSig to insert various pieces of information. These vary from pool to pool and from network protocol to network protocol, but generally include a unique identifier (often an extra nonce structured into several sub-parts) assigned to each miner, to avoid duplication of work within the pool. A pool identification tag is usually added, used for public attribution of found blocks, mining statistics and other tracking purposes.

SegWit's commitment

Since the SegWit soft fork was enabled in 2017, witness data (i.e. generally signatures) has been separated from transaction master data, notably to correct the malleability problem of Bitcoin transactions. This separation therefore introduces a new element to be committed in the block.
To do this, the witnesses are grouped together in another dedicated Merkle tree, whose root is then committed to the coinbase transaction via a OP_RETURN output.
I won't go into more detail on this mechanism in this course, as it's beyond the scope of this course, but just remember that since the introduction of SegWit, the coinbase transaction serves as a vehicle to anchor in the block a fingerprint summarizing all SegWit witnesses. The witnesses are placed in an independent Merkle tree, the root of this tree is written to an output of the coinbase transaction, and this coinbase transaction is itself included in the main Merkle tree along with all the other transactions, whose root appears in the block header. This is how the witnesses, stored separately from the main transaction data, are still committed to the block header.

Arbitrary messages

Since the scriptSig allows free insertion of arbitrary information chosen by the miner, some have taken advantage of the opportunity to add messages of a more personal nature, rather than technical ones. The most famous case is of course Satoshi Nakamoto, with his now-iconic message:
The Times 03/Jan/2009 Chancellor on brink of second bailout for banks
This message, present in the Genesis block (the very first block of Bitcoin) is actually encoded in hexadecimal in the scriptSig of the coinbase transaction:
5468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73

The maturity period

Once the block has been mined and distributed, the coinbase transaction appears on the blockchain like any other transaction. It creates UTXOs for the winning miner, enabling them to collect their reward. However, these UTXOs are not immediately spendable: they are subject to a maturity period. This maturity is set at 100 blocks after the block containing the coinbase. In concrete terms, the coinbase transaction must therefore total 101 confirmations for its outputs to become spendable by the winning miner.
The aim of this rule is to limit the impact of chain reorganizations on the economy. As we have seen in previous chapters, it can happen that at the same height, two distinct valid blocks are found almost simultaneously by different miners. For a brief moment, the network may split: some nodes receive block A first, while others see block B first. Then, over the course of subsequent blocks, one of the two branches accumulates more work and becomes the reference branch. The other branch is abandoned and its blocks become obsolete. The transactions it contained can then, in theory, return to the mempools awaiting confirmation.
In practice, this rarely happens, because the fee market often results in nearly the same transactions appearing in two competing blocks at the same height. This is one of the reasons why a Bitcoin transaction is commonly considered to become immutable after six confirmations: reorganizations of more than six blocks are so unlikely that they can reasonably be considered impossible.
The problem with these reorganizations in the case of the coinbase transaction is that it is no ordinary transaction. It introduces brand-new bitcoins into circulation. If the block reward could be spent immediately, a problematic cascade situation could arise:
  • a miner spends bitcoins from a coinbase,
  • these bitcoins circulate in the economy,
  • then the original block was finally abandoned during a reorganization.
The bitcoins in circulation would then never have existed in the final chain, and a series of transactions that were valid at the time of issue would become invalid a posteriori.
The maturity period imposes a timeframe long enough to make this scenario unrealistic. A reorganization of 101 blocks is considered, in practice, impossible (even if there remains an infinitesimal probability). We don't know exactly why Satoshi chose such a high value for maturity, but it is likely that it was chosen so that the mechanism would remain functional, even in the event of major network malfunctions.
This rule prevents newly-created block-reward money from starting to circulate before the block that generated it has been securely buried under a large amount of accumulated work.
We've now come to the end of our explanation of how Bitcoin mining works. You should now have a clear picture of the basic mechanisms involved.
In the last part of the course, we'll return to more concrete aspects, to show you how Bitcoin mining materializes in the real world: its industrialization, the machines used, the grouping of players, and so on. The aim will be to give you an overall view of Bitcoin mining, both from the theoretical and protocol perspective we've just seen, and also from its practical and operational side.
Quiz
Quiz1/5
Why does the coinbase transaction differ from other transactions?