A coinbase transaction is the first transaction in each block. Unlike regular transactions, it has no real inputs: its only input is a special field called the coinbase field, which can contain arbitrary data. Its outputs, however, are where the reward distribution takes place.

How the coinbase transaction is structured in Bitcoin and BCH

  • version: 4 bytes, commonly version 1 or 2; version 1 is serialised as 0x01000000.
  • inputs: exactly 1, with txid = 0x00…00 (32 zero bytes) and vout = 0xFFFFFFFF.
  • coinbase field (scriptSig): between 2 and 100 bytes. Contains block height (BIP34), extranonce, and pool data such as identifier or message.
  • outputs: one or more, each with a value in satoshis and a scriptPubKey that defines who can spend that output.
  • locktime: 4 bytes, usually 0x00000000.

Coinbase structure in Monero (XMR)

Monero calls this transaction the "miner transaction" (miner tx). Its structure differs significantly from Bitcoin's because Monero does not use Bitcoin's transparent UTXO model: it uses one-time outputs based on elliptic curve cryptography, while normal spends use key images to prevent double-spending (Curve25519).

  • version: varint, currently 0x02 for modern miner transactions.
  • unlock_time: varint. In the miner tx it is set to current_height + 60, enforcing the maturation period directly in the transaction.
  • inputs: exactly 1 input of type txin_gen, containing only the block number (block height). There is no reference to any previous output.
  • outputs: one or more, each with an explicit amount in atomic units and a target of type txout_to_key, which contains a one-time public key derived from the recipient address's view key and spend key.
  • extra: variable-length field. Contains the transaction public key (R = r·G) needed for the recipient to identify the output as theirs using their view key.
  • rct_signatures: not used for the miner tx. Although modern miner transactions use protocol version 2, they do not use RingCT range proofs or signatures; output amounts are transparent and verifiable by consensus.

The one-time public key for each output is computed as: P = Hs(r·V, i)·G + S, where r is the sender's random key, V is the recipient's public view key, S is the recipient's public spend key, i is the output index and Hs is a curve hash. The recipient can identify the output by computing Hs(v·R, i)·G + S and comparing it with P, where v is their private view key and R is the transaction public key from the extra field.

For OwnBlock, the XMR miner tx is built with two outputs: one for the pool fee and one for the miner's reward. Both outputs use independent one-time keys derived from their respective addresses. The miner can verify that the output belongs to them by scanning the block with their view key, without needing to trust that OwnBlock paid them correctly.

How OwnBlock builds the coinbase

When the pool software builds the candidate block and sends the mining job to the miner via Stratum, it already defines the coinbase payout outputs. For OwnBlock, two spendable payout outputs are generated: one with the pool fee (scriptPubKey with the OwnBlock address) and another with the remaining amount, after the pool fee, using the scriptPubKey derived from the mining address provided by the user. Any protocol-required commitment outputs, where applicable, are separate from those payout outputs.

Why this design removes the intermediate custodian

In a deferred-payment pool (PPLNS, PPS, etc.), the pool accumulates rewards and then makes conventional transfers to miners. That transfer is an ordinary transaction that has no visible relationship to the original block. The origin of the funds is obscured from the blockchain's point of view.

With OwnBlock, the miner's address is encoded in the coinbase from the moment the candidate block is built. If the block is accepted by the network, the payment is already there: in the coinbase output, indexed in the block, with the block hash as cryptographic proof that the origin is mining. There is no intermediary that can hold, block or redistribute that reward.

When you can spend a mining reward

Coinbase and miner-tx outputs are not immediately spendable. For BTC and BCH, consensus rules enforce a maturation period before the coinbase UTXO can be referenced as an input in another transaction: 100 confirmations (~16–17 hours). For XMR, the miner-tx output is locked until unlock_time, set to current_height + 60 (~2 hours). During that period the output exists on-chain but is locked by consensus rules.

If this direct-payout model matters to you, review our guides on split coinbase, custody, and pool setup to understand where it reduces trust and where it does not.