<p>These are the requirements on the coinbase transaction that I am currently aware of.</p>
<p>The transaction is structured like every other transaction, though not all fields have the same meaning.</p>
<ul>
<li>Version: a 32-bit LE integer. For normal transactions, the version number can only be 1 or 2 (for relative timelock semantics, see BIP 68). For coinbase transactions it has no meaning, and can be anything.</li>
<li>Transaction inputs: for normal transactions, refers to the set of unspent previous transaction outputs that are being spent. For coinbase transactions it is different, there must be exactly 1 input, and it must have specific values.
<ul>
<li>Prevout hash: must be 0000...000</li>
<li>Prevout index: must be 0xffffffff</li>
<li>scriptSig: for normal (non-segwit, see BIP141) transactions contains the proof that this transaction is authorized by the previous holder of the coin being spent. For coinbase transactions, it has different semantics. Instead it must:
<ul>
<li>Start with a push of the block height (as specified in BIP34)</li>
<li>Be followed by arbitrary data (which is often called the extraNonce)</li>
<li>The entire scriptSig must be between 2 and 100 bytes exactly (this rule predates BIP34, so its lower bound 2 is now superseded by the fact that the block height push is already larger than that).</li>
</ul>
</li>
<li>nSequence: for normal transactions this field affects BIP125 RBF semantics, and relative locktime semantics (BIP 68), but these don't apply to coinbase transactions. Can be anything.</li>
</ul>
</li>
<li>Transaction outputs: determines which UTXOs are created by this transaction. The semantics are identical for normal transactions and coinbase transactions. In particular, it can contain any number of outputs. Typically it will contain one or more outputs that give mined coins (subsidy + tx fees from other transactions in the block) to the miner, plus some dummy 0-value outputs for various purposes (one of them being the segwit commitment, if this is a segwit block, see BIP141).</li>
<li>nLockTime: This has absolute locktime semantics (stating when the transaction becomes valid), both for normal transactions and coinbase transactions.</li>
</ul>
<p>So to answer your question directly:</p>
<pre><code> - version                      - 4 Bytes   - LE  - 01000000 
</code></pre>
<p>In fact it can be any 4-byte value.</p>
<pre><code> - input count                  - 1 Bytes   - xx  - 01 
 - prev tx                      - 32 Bytes  - xx  - 0000000000...0000
 - prev out n                   - 4 Bytes   - xx  - ffffffff (outpoint index or fake index)
</code></pre>
<p>Correct.</p>
<pre><code> - coinbase script length (LCS) - &lt;?&gt; Bytes - &lt;?&gt; - &lt;what is value range of LCS i.e. min and max Bytes?&gt;
 - coinbase script              - LCS Bytes : 
                                                1 Bytes       - xx - 03 (Size of Block Height in next 3 Bytes)
                                                3 Bytes       - LE - __ (Valid Block Height in LE for Block being mined)
                                                [LCS-4 Bytes] - xx - xx (ANY binary string is Valid. ANY STRING!!!!)
</code></pre>
<p>The coinbase scriptSig is encoded as 1 byte encoding the length of the script, plus the script itself. That script must be between 2 and 100 bytes. The script has to start with a push of the block height, due to BIP34. For the current range of heights (65536 through 16777215), that's a 0x03 to indicate a 3-byte push, followed by 3 bytes encoding the block height in LE. After that, up to 96 other bytes can follow, whose contents does indeed not matter at all.</p>
<pre><code> - sequence                     - 4 Bytes   - xx  - ffffffff
</code></pre>
<p>This can be anything.</p>
<pre><code> - output count                 - 1 Bytes   - xx  - 01
 - value                        - &lt;?&gt; Bytes - LE  - __ (mining reward + transaction fee of all other included transactions in Satoshi)
</code></pre>
<p>Correct. You can have multiple outputs in fact (and their sum of values has to match the subsidy + tx fees), but 1 works fine. If you want to create a segwit block (see BIP141), there also needs to be another zero-value output with a specific structure; see the BIP for details.</p>
<pre><code> - script length (SL)           - 1 Bytes   - xx  - (what is value range of SL i.e. min and max bytes, or is it fixed size?)
 - pubkey script                - SL Bytes  - &lt;?&gt; - __ (What is this?! Is it the wallet address or the public key or something else - of the person who recieves the funds in 'value'?)
</code></pre>
<p>This is the scriptPubKey corresponding to the address you want to receive the mining reward for. There are many software libraries that can decode addresses to scripts for you, and answers on this site that explain it.</p>
<pre><code> - locktime                     - 4 Bytes   - xx  - 00000000
</code></pre>
<p>Not strictly required, as there are other permitted values, but they must result in a &quot;final&quot; transaction, which depends on the height and timestamp of block. Choosing 00000000 here will always work.</p>

CC BY-SA 4.0
2021-08-21T14:25:45.830Z
I understand. Since this is extremely technical and requires the knowledge of quiet a few protocols I am a bit lost. Can you please go through the above and see through the doubts and also see if I missed anything? I would be grateful. I don't know how else to understand/create a coinbase transaction rather than by hand like this.
J.Doe
CC BY-SA 4.0
2021-08-21T14:30:41.877Z
If you're asking how to actually build coinbase transactions in production, that's a very different question. Generally you'd use mining software, which uses the GBT (BIP22) protocol to ask a full node for the set of transactions and other information about the current state of the network, and uses this to build a block candidate, which is then sent to hasher hardware that searches for nonces plus updates the extranonce to find a full block. In my answer I've given the rules (and references to rules) that are relevant, but there simply isn't space to fully explain block building on this site.
Pieter Wuille
CC BY-SA 4.0
2021-08-21T14:35:49.303Z
Lets say I don't want to build a block candidate with other transactions from mempool but just with exactly 1 coinbase transaction why is it difficult to built it by hand? And can't the block itself be build too that way? What are the hinderences and is it that difficult for such a small block too? I am struggling to see any? if possible can you point to a free/opensource library that can do the same for me in python/C++. P.S. I don't have bitcoin core and I can't afford to download 400 GB for this as of now.
J.Doe
CC BY-SA 4.0
2021-08-21T14:43:38.500Z
If you mean for documentation purposes, sure - among others, the Bitcoin Core test framework has a full (but obviously incredibly slow) implementation of what is needed to build blocks. If you only want a coinbase transaction it's pretty simple (I'll try to extend my answer later to include some specifics). For production purposes none of that matters, however, you need ASIC mining hardware these days, and it comes with built-in firmware that does a significant part of the block building, including automatically connecting to pools (using Stratum protocol); nothing on your part needed.
Pieter Wuille
CC BY-SA 4.0
2021-08-21T14:46:44.757Z
I understand. Please ignore the practicality of mining as a single CPU computer since I know its pretty much hopeless without pools. If you can have a look at the doubts and see the structure w.r.t. your knowledge of the protocols that would be enough.
J.Doe
CC BY-SA 4.0
2021-08-21T16:44:20.563Z
I went over your list, and added comments in my answer.
Pieter Wuille
CC BY-SA 4.0
2021-08-21T17:08:32.177Z
thanks a lot! it really clarified quiet a bit. thanks again.
J.Doe
CC BY-SA 4.0
2021-08-21T14:21:28.850Z
2021-08-21T17:18:42.740Z
2021-08-21T17:18:42.740Z
Pieter Wuille
<p>I was trying to understand the structure of coinbase transaction. I tried a few sources but I still have a few doubts regarding the structure with exactly 1 output. Here is what I know and the doubts are marked by a <strong>?</strong>:</p>
<pre><code>[PARAMETER]           [SIZE]   [ENDIANNESS] [ALLOWED VALUES]

 - version            - 4 Bytes   - LE  - 01000000 
 - input count        - 1 Bytes   - xx  - 01 
 - prev tx            - 32 Bytes  - xx  - 0000000000...0000
 - prev out n         - 4 Bytes   - xx  - ffffffff (outpoint index or fake index)
 - coinbase script    - &lt;?&gt; Bytes - &lt;?&gt; - &lt;what is value range of LCS i.e. min and max Bytes?&gt;
   length (LCS)
 - coinbase script              - LCS Bytes : 
                                                1 Bytes       - xx - 03 (Size of Block Height in next 3 Bytes)
                                                3 Bytes       - LE - __ (Valid Block Height in LE for Block being mined)
                                                [LCS-4 Bytes] - xx - xx (ANY binary string is Valid. ANY STRING!!!!)

 - sequence           - 4 Bytes   - xx  - ffffffff
 - output count       - 1 Bytes   - xx  - 01
 - value              - &lt;?&gt; Bytes - LE  - __ (mining reward + transaction fee of all other included transactions in Satoshi)

 - script length (SL) - 1 Bytes   - xx  - (what is value range of SL i.e. min and max bytes, or is it fixed size?)
 - pubkey script      - SL Bytes  - &lt;?&gt; - __ (What is this?! Is it the wallet address or the public key or something else - of the person who recieves the funds in 'value'?)
 - locktime           - 4 Bytes   - xx  - 00000000


Notation:

LE    - Little Endian.
BE    - Big Endian.
xx    - Endianness doesn't matter.
__    - User input.
&lt;..?&gt; - Unclear.
</code></pre>
<p>Q1: Can someone please address the doubts marked by ? and validate if rest of the structure is correct?</p>
<p>Q2: Does coinbase script have any additional structure, rules or constraints that I missed including here (other than above) that can make the transaction invalid?</p>

<mining-theory><coinbase-transaction>
Some doubts regarding the structure of the Coinbase Transaction?
J.Doe
# Some doubts regarding the structure of the Coinbase Transaction?

(Asked by: username_0 on 2021-08-21)

I was trying to understand the structure of coinbase transaction. I tried a few sources but I still have a few doubts regarding the structure with exactly 1 output. Here is what I know and the doubts are marked by a **?**:

```
[PARAMETER]           [SIZE]   [ENDIANNESS] [ALLOWED VALUES]

 - version            - 4 Bytes   - LE  - 01000000 
 - input count        - 1 Bytes   - xx  - 01 
 - prev tx            - 32 Bytes  - xx  - 0000000000...0000
 - prev out n         - 4 Bytes   - xx  - ffffffff (outpoint index or fake index)
 - coinbase script    - <?> Bytes - <?> - <what is value range of LCS i.e. min and max Bytes?>
   length (LCS)
 - coinbase script              - LCS Bytes : 
                                                1 Bytes       - xx - 03 (Size of Block Height in next 3 Bytes)
                                                3 Bytes       - LE - __ (Valid Block Height in LE for Block being mined)
                                                [LCS-4 Bytes] - xx - xx (ANY binary string is Valid. ANY STRING!!!!)

 - sequence           - 4 Bytes   - xx  - ffffffff
 - output count       - 1 Bytes   - xx  - 01
 - value              - <?> Bytes - LE  - __ (mining reward + transaction fee of all other included transactions in Satoshi)

 - script length (SL) - 1 Bytes   - xx  - (what is value range of SL i.e. min and max bytes, or is it fixed size?)
 - pubkey script      - SL Bytes  - <?> - __ (What is this?! Is it the wallet address or the public key or something else - of the person who recieves the funds in 'value'?)
 - locktime           - 4 Bytes   - xx  - 00000000

Notation:

LE    - Little Endian.
BE    - Big Endian.
xx    - Endianness doesn't matter.
__    - User input.
<..?> - Unclear.

```

Q1: Can someone please address the doubts marked by ? and validate if rest of the structure is correct?

Q2: Does coinbase script have any additional structure, rules or constraints that I missed including here (other than above) that can make the transaction invalid?

**Tags:** mining-theory, coinbase-transaction


---

## 1 answers

### Answer by username_1 on 2021-08-21. Score: 5 | Accepted answer

These are the requirements on the coinbase transaction that I am currently aware of.

The transaction is structured like every other transaction, though not all fields have the same meaning.

* Version: a 32-bit LE integer. For normal transactions, the version number can only be 1 or 2 (for relative timelock semantics, see BIP 68). For coinbase transactions it has no meaning, and can be anything.
* Transaction inputs: for normal transactions, refers to the set of unspent previous transaction outputs that are being spent. For coinbase transactions it is different, there must be exactly 1 input, and it must have specific values.
  + Prevout hash: must be 0000...000
  + Prevout index: must be 0xffffffff
  + scriptSig: for normal (non-segwit, see BIP141) transactions contains the proof that this transaction is authorized by the previous holder of the coin being spent. For coinbase transactions, it has different semantics. Instead it must:
    - Start with a push of the block height (as specified in BIP34)
    - Be followed by arbitrary data (which is often called the extraNonce)
    - The entire scriptSig must be between 2 and 100 bytes exactly (this rule predates BIP34, so its lower bound 2 is now superseded by the fact that the block height push is already larger than that).
  + nSequence: for normal transactions this field affects BIP125 RBF semantics, and relative locktime semantics (BIP 68), but these don't apply to coinbase transactions. Can be anything.
* Transaction outputs: determines which UTXOs are created by this transaction. The semantics are identical for normal transactions and coinbase transactions. In particular, it can contain any number of outputs. Typically it will contain one or more outputs that give mined coins (subsidy + tx fees from other transactions in the block) to the miner, plus some dummy 0-value outputs for various purposes (one of them being the segwit commitment, if this is a segwit block, see BIP141).
* nLockTime: This has absolute locktime semantics (stating when the transaction becomes valid), both for normal transactions and coinbase transactions.

So to answer your question directly:

```
 - version                      - 4 Bytes   - LE  - 01000000 

```

In fact it can be any 4-byte value.

```
 - input count                  - 1 Bytes   - xx  - 01 
 - prev tx                      - 32 Bytes  - xx  - 0000000000...0000
 - prev out n                   - 4 Bytes   - xx  - ffffffff (outpoint index or fake index)

```

Correct.

```
 - coinbase script length (LCS) - <?> Bytes - <?> - <what is value range of LCS i.e. min and max Bytes?>
 - coinbase script              - LCS Bytes : 
                                                1 Bytes       - xx - 03 (Size of Block Height in next 3 Bytes)
                                                3 Bytes       - LE - __ (Valid Block Height in LE for Block being mined)
                                                [LCS-4 Bytes] - xx - xx (ANY binary string is Valid. ANY STRING!!!!)

```

The coinbase scriptSig is encoded as 1 byte encoding the length of the script, plus the script itself. That script must be between 2 and 100 bytes. The script has to start with a push of the block height, due to BIP34. For the current range of heights (65536 through 16777215), that's a 0x03 to indicate a 3-byte push, followed by 3 bytes encoding the block height in LE. After that, up to 96 other bytes can follow, whose contents does indeed not matter at all.

```
 - sequence                     - 4 Bytes   - xx  - ffffffff

```

This can be anything.

```
 - output count                 - 1 Bytes   - xx  - 01
 - value                        - <?> Bytes - LE  - __ (mining reward + transaction fee of all other included transactions in Satoshi)

```

Correct. You can have multiple outputs in fact (and their sum of values has to match the subsidy + tx fees), but 1 works fine. If you want to create a segwit block (see BIP141), there also needs to be another zero-value output with a specific structure; see the BIP for details.

```
 - script length (SL)           - 1 Bytes   - xx  - (what is value range of SL i.e. min and max bytes, or is it fixed size?)
 - pubkey script                - SL Bytes  - <?> - __ (What is this?! Is it the wallet address or the public key or something else - of the person who recieves the funds in 'value'?)

```

This is the scriptPubKey corresponding to the address you want to receive the mining reward for. There are many software libraries that can decode addresses to scripts for you, and answers on this site that explain it.

```
 - locktime                     - 4 Bytes   - xx  - 00000000

```

Not strictly required, as there are other permitted values, but they must result in a "final" transaction, which depends on the height and timestamp of block. Choosing 00000000 here will always work.

> **Comments:**
> **username_0**: I understand. Since this is extremely technical and requires the knowledge of quiet a few protocols I am a bit lost. Can you please go through the above and see through the doubts and also see if I missed anything? I would be grateful. I don't know how else to understand/create a coinbase transaction rather than by hand like this.  
> **username_1**: If you're asking how to actually build coinbase transactions in production, that's a very different question. Generally you'd use mining software, which uses the GBT (BIP22) protocol to ask a full node for the set of transactions and other information about the current state of the network, and uses this to build a block candidate, which is then sent to hasher hardware that searches for nonces plus updates the extranonce to find a full block. In my answer I've given the rules (and references to rules) that are relevant, but there simply isn't space to fully explain block building on this site.  
> **username_0**: Lets say I don't want to build a block candidate with other transactions from mempool but just with exactly 1 coinbase transaction why is it difficult to built it by hand? And can't the block itself be build too that way? What are the hinderences and is it that difficult for such a small block too? I am struggling to see any? if possible can you point to a free/opensource library that can do the same for me in python/C++. P.S. I don't have bitcoin core and I can't afford to download 400 GB for this as of now.  
> **username_1**: If you mean for documentation purposes, sure - among others, the Bitcoin Core test framework has a full (but obviously incredibly slow) implementation of what is needed to build blocks. If you only want a coinbase transaction it's pretty simple (I'll try to extend my answer later to include some specifics). For production purposes none of that matters, however, you need ASIC mining hardware these days, and it comes with built-in firmware that does a significant part of the block building, including automatically connecting to pools (using Stratum protocol); nothing on your part needed.  
> **username_0**: I understand. Please ignore the practicality of mining as a single CPU computer since I know its pretty much hopeless without pools. If you can have a look at the doubts and see the structure w.r.t. your knowledge of the protocols that would be enough.  
> **username_1**: I went over your list, and added comments in my answer.  
> **username_0**: thanks a lot! it really clarified quiet a bit. thanks again.  

---

