Coinbase transaction

Imagine Anna preparing a candidate block for mining. She collects users’ payments and places a special transaction before them, naming the reward’s recipients. In our example, the rules allow 3.125 BTC of new coins and the selected payments contribute 0.075 BTC in fees. Anna may therefore claim at most 3.2 BTC. This first transaction is coinbase. Writing it does not yet earn her the reward: the block must meet the mining requirement and every other condition, which receiving nodes verify for themselves. An excessive claim makes them reject the whole block, however much energy she spent finding it. No central account sends her a payout. New coins arise under shared rules within an accepted block. Of the example’s 3.2 BTC, only 3.125 BTC is new; users paid the remainder. This illustrates a reward, not profit: mining costs have not been deducted. [6] [4]

The permitted new issuance is called Block Subsidy and is periodically cut in half at a Halving. A satoshi is bitcoin’s smallest unit. Fees instead depend on the actual payments in the block, so two blocks need not earn the same reward. The reward ceiling is the new-coin subsidy for the block height, calculated by GetBlockSubsidy in Bitcoin Core, plus fees from all other valid transactions in the block. Only the subsidy creates new satoshis; fees are existing satoshis. A miner may claim less, but cannot collect the omitted amount later: unclaimed subsidy is never issued and unclaimed fees become permanently unspendable. Even a one-satoshi overclaim makes the entire block invalid. [4] [6]

The reward often goes to a mining pool, which coordinates several miners’ work. A locking script is a short program that sets the conditions for spending an output later. PPS, FPPS and PPLNS below name different ways pools distribute earnings among participants. Coinbase outputs use ordinary locking scripts. The reward can go to one collection address, be divided among recipients or include a pool operator’s share. Nodes check amounts and spending conditions, not contracts or beneficial ownership. PPS, FPPS and PPLNS accounting, minimum payouts and later transfers to participants are pool rules, not Bitcoin consensus rules. [6] [7]

Anna can see the reward in a block but cannot yet use it to pay her electricity bill. No exchange is withholding it: Bitcoin’s own rules enforce the wait. Block height is a block’s position number; H here denotes the height of the block that created the reward. COINBASE_MATURITY requires a difference of at least 100 between the spending block height and the creation height. An output created at H can first be spent in a valid block at H+100. Wallet confirmation counts can look different because the creating block already counts as the first. The height difference matters, not an estimate in hours. Meeting it does not guarantee that the block will never leave the chain. [5]

A reorganization means a node switches to another valid branch with more accumulated mining work. UTXOs are unspent outputs, the individual available amounts. A reward can disappear from that record along with the block that created it. A reorganization can remove the original block from the valid active chain with the most cumulative work. Its coinbase outputs then disappear from the active UTXO set. Transactions spending the reward can also be affected. Waiting 100 blocks limits the impact of short reorganizations but is not an absolute guarantee. A pool must distinguish rewards in the active chain, their spendability and its own obligations to miners. [4] [5]

A few names describe the exact format: an input normally points to funds being spent, while an output sets an amount and its spending conditions. The txid identifies the transaction, its version specifies the format, and locktime can limit when it may be included. Every block must contain at least one transaction, and only its first transaction may be coinbase. It has exactly one input with a null reference to a previous output: a hash of 32 zero bytes and index 0xffffffff. This reference, called an outpoint, spends nothing earlier, so there is no ordinary signature check for a spent output. The transaction still has its own txid, version, locktime and one or more outputs. [1] [2] [3]

Height is a block’s position number. BIP34 names a proposal whose rule Bitcoin adopted; scriptSig is an input data field, and CScript is Bitcoin’s way of representing script instructions and numbers. BIP34 requires scriptSig to start with the block height as a minimally encoded CScript number. The whole field must be 2–100 bytes. The height can be followed by an extra nonce, pool identification or merged-mining data. An incorrect height or length causes rejection. Although this input is not executed as an ordinary unlocking script, signature opcodes in it can count toward the sigops limit on signature operations. [1] [9]

Mining repeatedly calculates a hash, a digital fingerprint of the block’s short summary, called its header. A nonce is a changing number, and the Merkle root is a combined fingerprint of transactions. Changing a transaction thus opens more attempts. The block header nonce has 32 bits, and mining hardware quickly exhausts its possibilities. Software therefore also changes an extra nonce in coinbase. That changes the transaction txid, the Merkle root and then the block header, opening another search space for a suitable hash. A mining pool divides work among devices to avoid trying the same candidates unnecessarily. The extra nonce creates no additional coins. [6] [7] [12]

SegWit separates some verification data, such as signatures, into a part called witness. A commitment is a verifiable binding to data, not another payout. The format below is a technical reference for that binding. If the block contains witness data, BIP141 requires a coinbase output with a witness commitment, a cryptographic binding to that data. Its script starts 6a24aa21a9ed: OP_RETURN, a push of 36 bytes and the aa21a9ed marker. Next comes a 32-byte double SHA-256 hash of the witness Merkle root concatenated with the reserved value. The coinbase input witness must contain just that single 32-byte reserved value. If several outputs match, the highest output index applies. This is not a spendable payout; without witness data in the block, the commitment is optional. [10]

A Full Node is a computer independently checking Bitcoin’s rules. Block weight measures use of the permitted data capacity; the Mempool is a local store of ordinary unconfirmed transactions. Checking the reward is part of checking the whole block. A Full Node requires coinbase first and rejects any additional coinbase in that block. It checks scriptSig, the BIP34 height, amount ranges, block weight, fees and any required witness commitment. Output totals are checked against permitted issuance plus fees; later spending must satisfy maturity. A miner cannot validly award itself any amount it wishes. Coinbase without its block does not enter the mempool. [3] [4] [10]

The Genesis Block is Bitcoin’s starting block. Its special status and earlier repeated identifiers explain why today’s ordinary rules must not be applied indiscriminately to every historical case. Before the height was mandatory, different coinbase transactions could have the same txid. BIP30 prevents older unspent outputs from being overwritten; BIP34 adds a distinguishing height in ordinary modern blocks. The Genesis Block is special. Its serialized block includes coinbase, but initialization did not make its output spendable. The original 50 BTC genesis output cannot be spent; this is not ordinary waiting for 100 blocks. [8] [9] [11]