Coinbase Commitment

A coinbase commitment is the general technique of placing a cryptographic hash or marker inside a block's coinbase transaction so that the committed data inherits the block's proof-of-work without altering the block header. Because the coinbase is a leaf of the regular transaction merkle tree, anything committed there is implicitly secured by the same hashing that protects the rest of the block — and adding such data is a backward-compatible soft fork rather than a network-splitting hard fork. It is one of Bitcoin's most quietly load-bearing design patterns: when the protocol needs to promise something new, the coinbase is where the promise gets carved.

Why the coinbase is the chosen home

The 80-byte block header has no spare room, and extending it would invalidate the assumptions of every node, miner, and ASIC in existence. The coinbase transaction, by contrast, is uniquely flexible: as the block's first transaction it has no real inputs, so its input script (the coinbase scriptSig) is a freely usable field, and it can carry extra outputs beyond the reward payout. Data committed there flows into the merkle root, which is in the header — so the commitment is bound to the proof-of-work at one remove. Older software simply ignores the extra output as unspendable data, while upgraded nodes enforce its meaning. That asymmetry — old nodes tolerate, new nodes enforce — is the exact shape of a soft fork.

Common uses

The most widely deployed example is the SegWit witness commitment: an OP_RETURN output in the coinbase carrying the root of a second merkle tree built over the witness data of every transaction in the block. Merged mining uses the same trick in the scriptSig, committing to an auxiliary chain's block so one round of SHA-256 work secures two chains at once. Research proposals for UTXO-set commitments and other authenticated data structures also lean on the coinbase as the natural anchor point. In every case the pattern is identical: hash the data, place the hash in the coinbase, and let proof-of-work do the rest.

How nodes enforce a commitment

Enforcement is refreshingly mechanical. For the witness commitment, an upgraded node independently rebuilds the witness merkle tree from the block's transactions, hashes the result with a reserved value from the coinbase witness, and compares it against the committed hash in the coinbase output — identified by a fixed four-byte tag (aa21a9ed) following the OP_RETURN. Any mismatch makes the entire block invalid to upgraded nodes, no matter how much proof-of-work it carries. That is the whole trick: the commitment costs miners a few dozen bytes, and in exchange the committed data becomes exactly as hard to forge as the block itself.

What miners actually do with it

For miners, coinbase commitments are mostly handled by the pool or the node software, but they explain a constraint every pooled miner lives with: the coinbase is also where the pool embeds the extranonce that gives each machine its own slice of search space. Commitments and extranonce bytes share the same transaction, and the coinbase must be reassembled and the merkle root recomputed every time either changes — which is precisely the mechanism Stratum's job format is built around. It also raises a sovereignty point worth noticing: whoever builds the coinbase decides what gets committed. Under classic pooled mining that is the pool alone; under Stratum V2 job declaration, miners can construct their own templates and reclaim that authorship. For the canonical instance of the pattern, see the witness commitment above; for a forward-looking application, see UTXO commitments.