Coinbase and Miner Work: Building Mining Work

The coinbase transaction is the first in the block. It creates the subsidy bitcoins and gathers the fees, under the rules in force. For the miner it is also the lever that moves the Merkle root, and therefore the header, once the 32-bit nonce is exhausted.

What sets the coinbase apart

A normal transaction spends existing outputs. The coinbase has no real input in that sense: it anchors the block's monetary creation. It must meet precise consensus rules, notably block height, encoding, reward cap, and maturity before spending. The applicable detail is whatever the nodes enforce, to be checked in their implementation rather than in an article.

It can carry a message as a string in the script, a pool tag, and above all an extraNonce. None of those fields is the proof-of-work: they are data that feeds into the coinbase hash.

In a pool you generally do not write the whole coinbase. The pool sends two parts, a prefix and a suffix, between which firmware slides the extraNonce that distinguishes your worker. Solo, your node builds the coinbase with your address and the local template.

From coinbase to Merkle root

Every transaction in the block has a hash. Those hashes are combined pairwise in a Merkle tree until they yield a 32-byte root, the third major header field after version and prevhash.

The coinbase sits at the leftmost leaf of that tree. Change a single coinbase byte and its hash changes, so every parent node up to the root changes too. The other transactions do not need re-hashing one by one once you hold the tree's branches, which is exactly why Stratum sends Merkle branches instead of the whole block.

The miner can therefore renew the header without re-downloading the transaction list, as long as the template stays the same.

What the miner actually hashes

Proof-of-work applies to the double SHA-256 of the 80-byte header, never to a hash of every transaction on every nonce. The full sequence:

1. The template fixes the non-coinbase transactions, plus nBits and prevhash.
2. The coinbase is finalized: reward, extraNonce, message.
3. The Merkle root is computed.
4. The header is assembled: version, prevhash, root, nTime, nBits, starting nonce.
5. The nonce rolls. Each try produces a new header and a new double hash.
6. When nonce space runs out, the extraNonce is incremented, or nTime, or allowed version bits, and the calculation restarts at step 3, sometimes at step 2.
7. A hash under the share target goes to the pool; a hash under the network target is a block candidate.

The other transactions' signatures are not mined: they were verified when the template was built. If that template is invalid, no nonce will make the block acceptable.

Who chooses what

• Classic Stratum v1 pool: the pool chooses the transactions and the coinbase structure; you choose the extraNonce within an assigned range, and the nonce.
• Solo, or some Stratum v2 modes: your node chooses the transactions, builds the coinbase, and you hash.
• Payout address: it sits in the coinbase, or in a later payout transaction depending on the pool. It is never a header field.

Two workers using the same extraNonce on the same job would produce duplicate work, and therefore rejected shares. A wrong payout address, by contrast, is an account configuration problem rather than a hashing one.

What you watch

• Is the pool still accepting the job? A stale template carries a Merkle root matching a network state that has already moved on.
• Is the coinbase the firmware encoded the one from the job? One wrong byte and the root no longer matches, so shares fail in series.
• Does the reward amount match the rules in force? A node rejects any block whose coinbase claims more than the cap allows, however good the hash is.

A correctly formed coinbase does not make hashes more likely. It makes them receivable, which is the only thing that matters at the moment the pool validates your share.