> For the complete documentation index, see [llms.txt](https://hub.bsvblockchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.bsvblockchain.org/wiki/blocks-and-the-blockchain/blockchain/coinbase.md).

# Coinbase

**Coinbase** is the special name given to the first transaction in every block. These can also be called 'Generation Transactions'. The winning Miner creates this special transaction as part of the block templating process. A coinbase transaction follows the same format as a normal transaction, except:

* It has exactly one txin.
* This txin's prevout hash is 0000...0000.
* This txin's prevout index is 0xFFFFFFFF.
* The txin's prevout script is an arbitrary byte array which has historically been used by Miners to signal identity and pass messages from block winning nodes to the rest of the network.
* The sum of the values of all txout's cannot exceed the total of the Block subsidy and the mining fees paid by all other transactions included in the block. A part of the coinbase can also used as an 'extra nonce' during the block discovery process due to a single ASIC Miner being able to test more combinations than allowed for, in the 2^32 possible combinations that changing the nonce in the block header can create. The extra nonce field is incremented in the Coinbase transaction, which requires that a small number of hashes in the merkle tree are updated, changing the Merkle root in the block header allowing for a further 2^32 possible block hashes to be attempted. A Coinbase transaction can have as many outputs attached as are needed by the miner. These can be used for second layer functions including: \*Merchant API, otherwise known as MAPI, which allows the winning Miner to provide a dynamically accessible transaction pricing service enabling users to request pricing and transaction broadcast services from miners on the network. \*MinerID also uses the Coinbase transaction to present information to the network such as node identity, MAPI access points and more. This data will use standard formats such that user wallets shall be able to read and parse the information, giving them up-to-date knowledge of which nodes are competing on the network and more. Due to some early problems with blocks containing only a coinbase transaction with an identical coinbase text and outputs generating coinbase transactions with identical TXIDs, miners agreed through consensus to begin enforcing [BIP 0034](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki) as a protocol rule. This change mandated that the block height value be specified in the first item of the coinbase transaction. Prior to this, the coinbase script size was between 2 and 100 bytes. Currently the minimum length is 4 bytes which is needed to hold the blockheight in a VarInt. The maximum value storable in 3 bytes is 16,777,215 so with the generating blocks at a rate of approximately 59,000 per year so if this level of network activity is sustained then from approximately the year 2,300 the minimum length of a coinbase script size will need to increase to 5 bytes.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://hub.bsvblockchain.org/wiki/blocks-and-the-blockchain/blockchain/coinbase.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.