<blockquote>
<p>Would a block be accepted in which the coinbase transaction has an empty input scriptSig field? Is there an example of such?</p>
</blockquote>
<p>No, for unknown reasons there is a consensus rule that the coinbase input scriptSig must be between 2 and 100 bytes in length. Its contents however does not matter; it does not need to consist of valid opcodes even.</p>
<p>Since BIP34 activated in 2012, there is an additional rule that the coinbase scriptSig starts with a push of the block height (in a particular format). This forces all coinbase transactions to be unique.</p>
<blockquote>
<p>Can any other fields be left out, e.g. could the input TXID and VOUT be omitted (as have implied values)?</p>
</blockquote>
<p>No, because there is not even a way to signal missing fields.</p>
<p>Overall, a coinbase transaction is subject to these special rules:</p>
<ul>
<li>It has a version number and locktime like other transactions, but their values are ignored.</li>
<li>It must have exactly one input:
<ul>
<li>Its prevout hash must be the all-zero hash (indicating it is &quot;spending&quot; new coins, if you will)</li>
<li>Its prevout index must be 0xFFFFFFFF, a value that cannot occur for normal UTXOs.</li>
<li>Its nSequence value must be present, but is ignored.</li>
<li>Its scriptSig must be between 2 and 100 bytes inclusive, and since BIP34 start with a push of the block height.</li>
</ul>
</li>
<li>It must have 1 or more outputs. These outputs are treated like all other outputs; without them, there would be no way to signal where the created/mined coins go.</li>
</ul>

CC BY-SA 4.0
2023-09-02T18:02:27.940Z
re. "all-zero hash" my interpretation is that the input prevout field should be zeros `0x00000...` , not `SHA256(0x0000)`?
Lee
CC BY-SA 4.0
2023-09-02T18:04:45.053Z
Also, the coinbase version and locktime can be used for arbitrary bytes? It would be interesting to find an example in the wild...
Lee
CC BY-SA 4.0
2023-09-02T18:17:34.657Z
@Lee Correct. The prevout hash must be all zero bytes, not the hash of all zeroes.
Pieter Wuille
CC BY-SA 4.0
2023-09-03T06:31:35.300Z
> Also, the coinbase version and locktime can be used for arbitrary bytes? It would be interesting to find an example in the wild... 

@Lee check this [question](https://bitcoin.stackexchange.com/questions/110474/why-are-miners-setting-the-locktime-in-coinbase-transactions/119370#119370)
bordalix
CC BY-SA 4.0
2023-09-05T15:28:37.897Z
It seems `nSequence` can be arbitrary too.
Lee
CC BY-SA 4.0
2023-09-05T15:40:20.763Z
Yes, I said so above.
Pieter Wuille
CC BY-SA 4.0
2023-09-05T15:56:14.857Z
Apologies, intention was to correct/complete my previous comment.
Lee
CC BY-SA 4.0
2023-09-02T11:24:38.027Z
2023-09-02T11:24:38.027Z
Pieter Wuille
<p>Is it correct to say:</p>
<blockquote>
<p>As the coinbase transaction doesn't need to identify an output, there
is no need for the input scriptSig.</p>
</blockquote>
<p><strong>Would a block be accepted in which the coinbase transaction has an empty input scriptSig field?</strong> Is there an example of such?</p>
<p><strong>Can any other fields be left out</strong>, e.g. could the input TXID and VOUT be omitted (as have implied values)<strong>?</strong></p>
<hr />
<p>Specifically, given this example coinbase transaction (from <a href="https://learnmeabitcoin.com/technical/coinbase-transaction" rel="nofollow noreferrer">here</a>):</p>
<p><code>01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4503ec59062f48616f4254432f53756e204368756e2059753a205a6875616e67205975616e2c2077696c6c20796f75206d61727279206d653f2f06fcc9cacc19c5f278560300ffffffff01529c6d98000000001976a914bfd3ebb5485b49a6cf1657824623ead693b5a45888ac00000000</code></p>
<p>Would it still be accepted as (input scriptSig removed):</p>
<p><code>01000000010000000000000000000000000000000000000000000000000000000000000000ffffffffffffffff01529c6d98000000001976a914bfd3ebb5485b49a6cf1657824623ead693b5a45888ac00000000</code></p>
<p>Or even (input TXID and VOUT removed):</p>
<p><code>0100000001ffffffff01529c6d98000000001976a914bfd3ebb5485b49a6cf1657824623ead693b5a45888ac00000000</code></p>

CC BY-SA 4.0
2023-10-22T12:40:48.057Z
Possible duplicate of https://bitcoin.stackexchange.com/q/20721/5406
Murch
<transactions><mining-reward><raw-transaction><coinbase-transaction><input-script>
What fields of a coinbase transaction can be empty?
Lee
# What fields of a coinbase transaction can be empty?

(Asked by: username_0 on 2023-09-02)

Is it correct to say:

> As the coinbase transaction doesn't need to identify an output, there
> is no need for the input scriptSig.

**Would a block be accepted in which the coinbase transaction has an empty input scriptSig field?** Is there an example of such?

**Can any other fields be left out**, e.g. could the input TXID and VOUT be omitted (as have implied values)**?**

---

Specifically, given this example coinbase transaction (from [here](https://learnmeabitcoin.com/technical/coinbase-transaction)):

`01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4503ec59062f48616f4254432f53756e204368756e2059753a205a6875616e67205975616e2c2077696c6c20796f75206d61727279206d653f2f06fcc9cacc19c5f278560300ffffffff01529c6d98000000001976a914bfd3ebb5485b49a6cf1657824623ead693b5a45888ac00000000`

Would it still be accepted as (input scriptSig removed):

`01000000010000000000000000000000000000000000000000000000000000000000000000ffffffffffffffff01529c6d98000000001976a914bfd3ebb5485b49a6cf1657824623ead693b5a45888ac00000000`

Or even (input TXID and VOUT removed):

`0100000001ffffffff01529c6d98000000001976a914bfd3ebb5485b49a6cf1657824623ead693b5a45888ac00000000`

**Tags:** transactions, mining-reward, raw-transaction, coinbase-transaction, input-script

> **Comments:**
> **username_1**: Possible duplicate of https://bitcoin.stackexchange.com/q/20721/5406  

---

## 1 answers

### Answer by username_2 on 2023-09-02. Score: 3 | Accepted answer

> Would a block be accepted in which the coinbase transaction has an empty input scriptSig field? Is there an example of such?

No, for unknown reasons there is a consensus rule that the coinbase input scriptSig must be between 2 and 100 bytes in length. Its contents however does not matter; it does not need to consist of valid opcodes even.

Since BIP34 activated in 2012, there is an additional rule that the coinbase scriptSig starts with a push of the block height (in a particular format). This forces all coinbase transactions to be unique.

> Can any other fields be left out, e.g. could the input TXID and VOUT be omitted (as have implied values)?

No, because there is not even a way to signal missing fields.

Overall, a coinbase transaction is subject to these special rules:

* It has a version number and locktime like other transactions, but their values are ignored.
* It must have exactly one input:
  + Its prevout hash must be the all-zero hash (indicating it is "spending" new coins, if you will)
  + Its prevout index must be 0xFFFFFFFF, a value that cannot occur for normal UTXOs.
  + Its nSequence value must be present, but is ignored.
  + Its scriptSig must be between 2 and 100 bytes inclusive, and since BIP34 start with a push of the block height.
* It must have 1 or more outputs. These outputs are treated like all other outputs; without them, there would be no way to signal where the created/mined coins go.

> **Comments:**
> **username_0**: re. "all-zero hash" my interpretation is that the input prevout field should be zeros `0x00000...` , not `SHA256(0x0000)`?  
> **username_0**: Also, the coinbase version and locktime can be used for arbitrary bytes? It would be interesting to find an example in the wild...  
> **username_2**: @username_0 Correct. The prevout hash must be all zero bytes, not the hash of all zeroes.  
> **username_3**: > Also, the coinbase version and locktime can be used for arbitrary bytes? It would be interesting to find an example in the wild...   @username_0 check this [question](https://bitcoin.stackexchange.com/questions/110474/why-are-miners-setting-the-locktime-in-coinbase-transactions/119370#119370)  
> **username_0**: It seems `nSequence` can be arbitrary too.  
> **username_2**: Yes, I said so above.  
> **username_0**: Apologies, intention was to correct/complete my previous comment.  

---

