# The Coinbase transaction
The **first transaction** in every Bitcoin block is known as the **Coinbase transaction**.
It serves a special purpose: this is where a **node rewards itself** with the **block reward**, which includes both:
* The **block subsidy**, and
* The **transaction fees** from all processed transactions in the block.
Each Coinbase transaction is **unique** to the mining node, as it references the miner’s **PublicKeyHash** to receive the reward. Importantly, the transaction is only **recorded to the blockchain** — and its reward **becomes spendable after 100 additional blocks** have been built on top of it — once the block is **accepted as valid** and forms part of the **longest chain**.
***
#### **Structure and Validation of the Coinbase Transaction**
Unlike regular transactions, the Coinbase transaction **does not spend existing outputs**.
Because these coins are newly created, there is **no previous transaction hash** or **unlocking script**.
Key validation checks include:
* The **value field** must **not exceed** the sum of the **block subsidy** and **total transaction fees**.
* If it **exceeds** this amount, the miner is effectively trying to **create new tokens** — a **rule-set violation**, making the transaction **invalid**.
* If a miner **fails to claim** the full reward available, the **unclaimed tokens are lost** from circulation permanently.
In some cases, the **previous hash field** has been used to include **miner identification**, though this can easily be **spoofed** and is not considered reliable.
***
#### **The Role of the Extranonce**
When all **4.3 billion nonce iterations** have been exhausted for a block header, the miner can modify the **extranonce** within the **coinbase transaction**.
(*The extranonce is an additional variable field found inside the Coinbase transaction of a Bitcoin block.*
*It serves as an extension of the regular nonce in the block header — allowing miners to continue searching for a valid Proof-of-Work after all 4.29 billion possible nonce values (the 32-bit range) in the block header have been tried.*)
Changing this value **alters the serialized coinbase transaction**, which in turn changes:
1. The **Merkle root**, since the coinbase hash is part of it.
2. The **interior nodes** along the left-hand edge of the Merkle tree.
This mechanism allows miners to continue hashing without altering the rest of the transaction set.
In **pooled mining**, extranonces are also used to **allocate different ranges** of values to different mining machines — ensuring that no two miners duplicate proof-of-work efforts on the same Merkle root.
***
#### **Block Subsidy and Transaction Fees**
The **block subsidy** was programmed to **decrease over time**, based on fixed block intervals. This gradual reduction was designed to:
* **Bootstrap the network** in its early stages.
* **Incentivize miners** to commit computational power.
* Transition rewards from **subsidy-based** to **fee-based** as usage grows.
Transaction fees are calculated as:
* The **difference between total inputs and outputs** of all transactions in the block.
* Often measured in **satoshis per byte** of transaction data for validation and relay.
Together, the block subsidy and fees form the **total coinbase reward**, which compensates the node for:
* **Validating transactions**, and
* **Constructing large Merkle trees** representing the block’s dataset.
***
#### **Coinbase as the First Leaf in the Merkle Tree**
When the block is constructed, the **double SHA-256 hash** of the **coinbase transaction** becomes the **first leaf node (index 0)** of the Merkle tree.\
As the block grows, nodes perform **Proof-of-work** on the **Merkle root** and **previous block hash**, ensuring each block cryptographically links to the last.
This connection between blocks forms the **immutable chain of verified transactions**, commonly known as the **blockchain**.
***
#### **Dynamic Recalculation During Construction**
As new transactions are appended to the Merkle tree, the **node’s fees** accumulate and are reflected in the **coinbase transaction**.
Because of this:
1. The **coinbase transaction data** changes each time new fees are added.
2. Its **leaf node hash (index 0)** must be **recalculated**.
3. Consequently, the **left-hand interior nodes** and **Merkle root** also update continuously.
Thus, the **Merkle tree evolves dynamically** until the block is finalized, maintaining consistency between the reward structure and the transaction dataset.
***
#### **Key Takeaway**
The **coinbase transaction** is the **foundation of every block**, representing both a **reward mechanism** and a **structural anchor** for the Merkle tree.
It ties the **economic incentives** of miners to the **mathematical integrity** of the blockchain.
By linking new coins to validated transactions, Bitcoin ensures that **value creation**, **data verification**, and **network honesty** all align through one elegant cryptographic design.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://hub.bsvblockchain.org/higher-learning/bsv-academy/bitcoin-primitives-merkle-trees/merkle-trees-and-verifying-proof-of-work/the-coinbase-transaction.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.