Part V · Special Transactions Chapter 13

The Coinbase Transaction

Every transaction we have parsed so far has one thing in common: it spends existing bitcoin. Inputs reference previous outputs; signatures prove authorization; the chain of ownership extends backward, UTXO by UTXO, all the way to the moment each coin was created. But where does that chain begin? What transaction has no inputs to reference, no previous outputs to spend, no signatures to verify? sloppypar

The answer is the coinbase transaction—the first transaction in every block. It is the only transaction type that creates new bitcoin. Its single "input" references nothing: the previous txid is 32 bytes of zeros, the previous vout is 0xFFFFFFFF, and the scriptSig contains not a signature but arbitrary data chosen by the miner. Its outputs distribute the block subsidy (newly minted bitcoin) plus all transaction fees from the block's other transactions.

Our specimen is the coinbase of block 840,000—the fourth halving block—where the subsidy dropped from 6.25 BTC to 3.125 BTC. On this historic day, the Runes protocol launched simultaneously, driving fees so high that the miner collected 37.63 BTC in fees on top of the 3.125 BTC subsidy—twelve times the subsidy in a single block.

13.1The Specimen

Txid:^†

a0db149ace545beabbd87a8d6b20ffd6aa3b5a50e58add49a3d435f898c272cf

Metric	Value	Notes
Block	840,000	4th halving block
Miner	ViaBTC	"/ViaBTC/Mined by buzz120/"
Timestamp	April 20, 2024	00:09:27 UTC
Total size	316 B	Including witness
Weight	1,156 WU	\(280 \times 3 + 316\)
Subsidy	3.125 BTC	First block at new rate
Fees	37.626 BTC	Runes launch frenzy
Total reward	40.751 BTC	\(3.125 + 37.626\)

13.2The Null Input

The coinbase's single input is unlike any other in Bitcoin:

Field	Coinbase	Regular transaction
Previous txid	32 bytes of 00	Hash of a real transaction
Previous vout	0xFFFFFFFF	Index of a real output
ScriptSig	Arbitrary data (2–100 B)	Unlocking script
Sequence	Typically 0xFFFFFFFF	RBF/locktime signal

The all-zeros txid and 0xFFFFFFFF vout are the coinbase's fingerprint. Every Bitcoin node recognizes this pattern: the transaction is not spending an existing UTXO but creating new bitcoin according to the consensus rules. No signature is required—the miner who found the valid proof-of-work has earned the right to claim the reward.

13.3The Coinbase ScriptSig

The coinbase scriptSig is the miner's canvas—up to 100 bytes of arbitrary data. Our specimen's 96-byte scriptSig contains three distinct components:

13.3.1Block Height (BIP 34)

Since block 227,835 (March 2013), BIP 34^† requires the coinbase scriptSig to begin with the block height encoded as a Script number:

03_push 3 bytes 40 d1 0c_840,000 (LE)

The first byte 03 is OP_PUSHBYTES_3, followed by the 3-byte little-endian encoding of 840,000: \[ \texttt{0x0cd140} = 12 \times 65{,}536 + 209 \times 256 + 64 = 840{,}000 \]

BIP 34 was introduced to prevent duplicate txids. Before BIP 34, two coinbase transactions in different blocks could have identical content (same outputs, same scriptSig), producing the same txid. By forcing the block height into the scriptSig, every coinbase is guaranteed to be unique.

13.3.2Mining Pool Tag

The next 25 bytes encode the pool's identity:

/ViaBTC/Mined by buzz120/

Mining pools embed their name in the coinbase as a form of attribution—proving which pool found the block. This tradition began with Satoshi embedding The Times headline in the Genesis block's coinbase and continues today with every major pool.

13.3.3Auxiliary Data

The remaining bytes contain merge-mining commitments (the fabe6d6d prefix signals RSK/Rootstock merge-mining data) and extra nonce space for the mining hardware. Miners who exhaust the 4-byte nonce in the block header can vary these coinbase bytes to search additional hash space.

13.4The Outputs

Our specimen has three outputs:

13.4.1Output 0: The Block Reward

Field	Value
Value	4,075,061,499 sats (40.751 BTC)
Type	P2PKH
Address	18cBEMRxXHqzWWCxZNtU91F5sbUNKhL5PX

This output collects the entire block reward: the 3.125 BTC subsidy plus all transaction fees. The total value must not exceed the sum of the subsidy and fees—this is a consensus rule enforced by every node.

13.4.2Output 1: RSK Merge-Mining (OP_RETURN)

OP_RETURN RSKBLOCK:<41-byte hash>

This OP_RETURN output commits to an RSK (Rootstock) sidechain block hash. Through merge-mining, the same proof-of-work that secures Bitcoin simultaneously secures the RSK network. The miner embeds the RSK block hash in the coinbase at no additional energy cost.

13.4.3Output 2: SegWit Witness Commitment

OP_RETURN aa21a9ed <32-byte hash>

The 4-byte magic prefix aa21a9ed identifies this as the SegWit witness commitment required by BIP 141.^† The 32-byte hash commits to the Merkle root of all witness data in the block:

\[ \text{witness commitment} = \text{SHA-256d}(\text{witness root} \| \text{coinbase nonce}) \]

The witness root is computed by building a Merkle tree of all transactions' wtxids (with the coinbase's wtxid replaced by 32 zero bytes). The coinbase nonce is a 32-byte value in the coinbase's own witness field (see below).

This commitment ensures that witness data is cryptographically bound to the block header—even though the block header's Merkle root uses txids (which exclude witness data). Without this commitment, a node could strip witness data from a block without invalidating the header.

13.5The Coinbase Witness

The coinbase witness contains a single item: a 32-byte nonce (all zeros in our specimen):

The nonce is part of the witness commitment computation. Miners can vary this nonce to produce different witness commitment hashes without changing any transaction content—providing additional hash-grinding space beyond the block header nonce and extra nonce in the scriptSig.

In practice, most miners use all zeros for the coinbase witness nonce, since the extra nonce in the scriptSig already provides sufficient search space.

13.6The Maturity Rule

Coinbase outputs cannot be spent until they have 100 confirmations—the coinbase maturity rule. A coinbase created in block \(n\) becomes spendable at block \(n + 100\). Our specimen's reward at block 840,000 became spendable at block 840,100.

This rule exists because blockchain reorganizations can invalidate coinbase transactions. If block 840,000 is orphaned (replaced by a competing block at the same height), its coinbase disappears—and any transactions spending it would become invalid. The 100-block wait provides a safety margin, making reorganizations that deep extremely unlikely.

13.7Weight Analysis

Component	Bytes	Notes
Non-witness data	280 B	Version, input, outputs, locktime
Marker + flag	2 B	SegWit serialization
Witness	34 B	1 item count + 1 length + 32 nonce
Total	316 B
Stripped	280 B	\(316 - 2 - 34\)
Weight	1,156 WU	\(280 \times 3 + 316\)
vsize	289 vB	\(1,156 / 4\)

The coinbase contributes to the block's weight like any other transaction. Since the SegWit witness commitment is mandatory (for blocks containing SegWit transactions), every modern coinbase includes the 34-byte witness overhead.

13.8What We Learned

• The coinbase is the first transaction in every block and the only one that creates new bitcoin.
• Its input is a null reference: 32 zero bytes for the txid, 0xFFFFFFFF for the vout.
• The scriptSig contains arbitrary miner data: block height (BIP 34), pool tags, extra nonce space, and optional merge-mining commitments.
• The block reward (subsidy + fees) is collected in the output(s). The subsidy halves every 210,000 blocks.
• The SegWit witness commitment (aa21a9ed prefix) binds witness data to the block via a Merkle root in an OP_RETURN output.
• The coinbase witness nonce (32 bytes, typically all zeros) is part of the witness commitment hash.
• Coinbase outputs require 100 confirmations before they can be spent (the maturity rule).

13.8.1Looking Ahead

The coinbase's OP_RETURN outputs hint at a larger story. Chapter 15 explores OP_RETURN as a general-purpose data embedding mechanism—from simple messages to the protocols that drive Ordinals, Runes, and on-chain attestations.

*Exercises

Litmus (L)

1. What two values identify the coinbase's null input?
2. What does BIP 34 require at the beginning of every coinbase scriptSig? Why?
3. What is the SegWit witness commitment, and where does it appear in the coinbase?
4. How long must a coinbase output wait before it can be spent? Why?
5. In our specimen, what is the block subsidy? How does it compare to the total fees?

Hands-On (H)

1. Decode the block height from the scriptSig bytes 03 40 d1 0c. Verify it equals 840,000.
2. Compute the total block reward. Given the subsidy of 3.125 BTC and total output value of 40.751 BTC, what are the total fees? Express the fee-to-subsidy ratio.
3. Parse the coinbase witness. What is the nonce value? How many bytes is it? Why does this exist even though the coinbase has no real input to sign?
4. Identify the ASCII text in the coinbase scriptSig. What mining pool mined this block? Who is "buzz120"?

Proofs and Reasoning (P)

1. Why were duplicate coinbase txids possible before BIP 34? Construct a scenario in which two blocks produce identical coinbase transactions.
2. Prove that after all 33 halvings, the total supply converges to exactly 20,999,999.9769 BTC (2,099,999,997,690,000 sats). Show the geometric series.
3. Why does the witness commitment use \(\text{SHA-256d}(\text{witness root} \| \text{nonce})\) rather than just the witness root directly? What flexibility does the nonce provide?

Connections (C)

1. Merge-mining. Our specimen contains an RSK merge-mining commitment. Explain how merge-mining works: how can one proof-of-work simultaneously secure two blockchains? What are the trade-offs?
2. Fee economics. At block 840,000, fees were 12\(\times\) the subsidy. Is this sustainable? What does it imply about Bitcoin's long-term security budget as the subsidy approaches zero?

Bridge (B)

1. The coinbase's OP_RETURN outputs carry data (RSK hash, witness commitment). Chapter 15 explores OP_RETURN in depth. What other protocols use OP_RETURN, and what data do they embed?
2. How does the coinbase maturity rule interact with Lightning Network channel funding? Can a Lightning channel be opened with coinbase funds before 100 confirmations?

*Solutions

L1. The null input has: (1) a previous txid of 32 zero bytes (00…00), and (2) a previous vout of 0xFFFFFFFF (4,294,967,295). Together, these signal that the input is not referencing any existing UTXO but is a coinbase (new coin creation).

L2. BIP 34 requires the coinbase scriptSig to begin with the block height encoded as a Script number (push opcode + little-endian bytes). This prevents duplicate coinbase txids: without the height, two blocks with identical reward structures could produce the same coinbase transaction content and thus the same txid.

L3. The SegWit witness commitment is a hash that binds all witness data in the block to the block header. It appears as an OP_RETURN output in the coinbase with the magic prefix aa21a9ed followed by a 32-byte hash: \(\text{SHA-256d}(\text{witness Merkle root} \| \text{coinbase nonce})\).

L4. 100 confirmations (the coinbase maturity rule). This protects against blockchain reorganizations: if the block is orphaned, its coinbase is invalidated, and any transactions spending it would also become invalid. The 100-block wait makes such deep reorganizations extremely unlikely before the funds are spent.

L5. The subsidy is 3.125 BTC (312,500,000 sats)—the first block at the 4th halving rate. Total fees: \(40.751 - 3.125 = 37.626\) BTC. Fees exceeded the subsidy by a factor of 12\(\times\), driven by the simultaneous launch of the Runes protocol.

H1. 03 = push 3 bytes. 40 d1 0c in little-endian = 0x0cd140:

\[ 12 \times 65{,}536 + 209 \times 256 + 64 = 786{,}432 + 53{,}504 + 64 = 840{,}000 \]

H2. Total output: 4,075,061,499 sats (40.751 BTC). Subsidy: 312,500,000 sats (3.125 BTC). Fees: \(4,075,061,499 - 312,500,000 = 3,762,561,499\) sats (\(\approx\)37.626 BTC). Fee-to-subsidy ratio: \(37.626 / 3.125 \approx 12.0\times\).

H3. The coinbase witness has 1 item (01), of length 32 bytes (20), with value all zeros. This 32-byte nonce is used in the witness commitment computation: \(\text{SHA-256d}(\text{witness root} \| \text{nonce})\). It provides miners additional hash-grinding space, though most use all zeros since the scriptSig extra nonce is sufficient.

H4. The ASCII text /ViaBTC/Mined by buzz120/ identifies the mining pool as ViaBTC, and "buzz120" is the identifier of the specific worker or mining rig within the pool that found the winning hash.

P1. Before BIP 34, the coinbase scriptSig could contain anything. Consider two blocks at different heights that:

1. Have the same coinbase outputs (same addresses, same amounts).
2. Use the same scriptSig data (e.g., both empty or both containing the same pool tag).

Since the txid is SHA-256d of the serialized transaction, identical content produces identical txids. This actually occurred: blocks 91,722 and 91,880 had identical coinbase transactions (both paid 50 BTC to the same address with identical scriptSigs). BIP 34 forces the block height into the scriptSig, making every coinbase unique.

P2. The total supply is:

\[ S = \sum_{k=0}^{32} 210{,}000 \times \frac{50 \times 10^8}{2^k} \text{ sats} \]

Since sats are integers and the subsidy is halved (integer division), the exact sum uses \(\lfloor 50 \times 10^8 / 2^k \rfloor\):

\[ S = 210{,}000 \times 10^8 \times \sum_{k=0}^{32} \frac{50}{2^k} = 210{,}000 \times 10^8 \times 50 \times \left(2 - \frac{1}{2^{32}}\right) \]

Accounting for integer truncation at each halving, the precise total is 2,099,999,997,690,000 sats = 20,999,999.97690000 BTC, just under 21 million.

P3. The nonce provides commitment flexibility. If the witness commitment were just the witness root, miners could not vary it without changing a transaction (which changes the witness root). With the nonce, miners can produce different commitment hashes by changing the 32-byte nonce in their coinbase witness—useful for additional proof-of-work grinding. The nonce also future-proofs the commitment structure: additional protocol commitments could be bound to the nonce in future soft forks without changing the OP_RETURN format.

C1. Merge-mining allows a miner to submit the same proof-of-work to both the Bitcoin blockchain and a secondary chain (like RSK). The miner includes a commitment to the secondary chain's block hash in the Bitcoin coinbase (the RSKBLOCK OP_RETURN). When the miner finds a valid Bitcoin block, the embedded commitment proves they also did work on the secondary chain. The secondary chain accepts this as proof-of-work for its own block.

Trade-offs: the secondary chain inherits Bitcoin's hashrate security (positive), but miners must run software for both chains (operational overhead). Miners can also choose not to mine the secondary chain (no enforcement), and the secondary chain's block times are constrained by Bitcoin's 10-minute blocks.

C2. Block 840,000's extreme fee ratio was unusual—driven by Runes launch speculation, not normal transaction demand. For long-term security, fees must eventually replace the declining subsidy. Whether this is sustainable depends on Bitcoin's transaction demand: if each block consistently generates significant fee revenue (through Lightning channel operations, Ordinals, or simple transfers), the security budget remains adequate. The halving block demonstrated that fees can far exceed the subsidy—but whether they will on average remains one of Bitcoin's most important open questions.

B1. Protocols using OP_RETURN include: (1) Omni Layer (formerly Mastercoin) for token issuance, (2) OpenTimestamps for timestamping, (3) USDT (Tether, on Omni Layer), (4) Counterparty for asset creation, and (5) various anchoring/attestation services. The Runes protocol (Chapter 20) uses OP_RETURN with the OP_PUSHNUM_13 tag. Chapter 15 examines these in detail.

B2. No. Lightning channel funding requires spending an output to create the 2-of-2 multisig funding output. If that output comes from a coinbase, it must have 100 confirmations first. The Lightning node will reject the funding attempt if the input has insufficient maturity. In practice, miners who want to fund Lightning channels must wait 16.5 hours (100 blocks \(\times\) 10 minutes) after mining a block before using the coinbase reward.