<p><strong>ExtraNonce</strong>: As well as the Nonce field, There is also an <a href="https://bitcoin.stackexchange.com/q/36455/13866">extranonce</a> convention - a part of the unlocking script in the input of the coinbase transaction is used as an extra nonce by miners.</p>
<p><strong>Timestamp</strong>: The miner can vary the timestamp. It only has to be accurate within about 2 hours. It doesn't have to be greater than the timestamp of the previous block.</p>
<p><strong>Version</strong>: Miners can vary a part of the version number. There is a method known as <a href="https://bitcoin.stackexchange.com/q/79273/13866">ASICboost</a> which helps miners who are using ASICs for mining.</p>
<p><strong>Coinbase output</strong>: The miner can vary the coinbase output. Perhaps selecting a different receiving address or varying the type of script.</p>
<p><strong>Transaction order</strong>: The miner can vary the order of transactions (other than for transactions that spend outputs of prior transactions in same block).</p>
<p><strong>Transactions</strong>: The miner can make an arbitrary select of transactions from their mempool or create their own new arbitrary valid transactions to include. If inventing their own transactions they can vary the fee from zero to maximum and can vary the transaction type from legacy to latest. They can also vary the input amounts from near zero to whole UTXO. The transactions must be valid but that still allows a vast range of variations, assuming the miner owns some bitcoin to start with.</p>
<hr />
<p>From <a href="https://learn.saylor.org/mod/book/view.php?id=36375&amp;chapterid=19427" rel="nofollow noreferrer">Bitcoin for Developers I</a></p>
<blockquote>
<p>Table 2. The structure of a coinbase transaction input</p>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th>Size</th>
<th>Field</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>32 bytes</td>
<td>Transaction Hash</td>
<td>All bits are zero: Not a transaction hash reference</td>
</tr>
<tr>
<td>4 bytes</td>
<td>Output Index</td>
<td>All bits are ones: 0xFFFFFFFF</td>
</tr>
<tr>
<td>1–9 bytes (VarInt)</td>
<td>Coinbase Data Size</td>
<td>Length of the coinbase data, from 2 to 100 bytes</td>
</tr>
<tr>
<td>Variable</td>
<td>Coinbase Data</td>
<td>Arbitrary data used for <strong>extra nonce</strong> and mining tags. In v2 blocks; must begin with block height</td>
</tr>
<tr>
<td>4 bytes</td>
<td>Sequence Number</td>
<td>Set to 0xFFFFFFFF</td>
</tr>
</tbody>
</table>
</div></blockquote>
<p>See also <a href="https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki" rel="nofollow noreferrer">BIP-34</a></p>

CC BY-SA 4.0
2021-08-21T10:38:36.943Z
Thank you. I get the generic idea but I am not clear on the specifics or structure of some things: such as Extranonce, the coinbase script part. Can you please point to a resource where its discussed in details and is more specific (for implementation level details)?
J.Doe
CC BY-SA 4.0
2023-03-19T13:50:30.510Z
The ExtraNonce isn't a "field", it's more a practice. The entire scriptSig of the coinbase transaction input is freely chosen by the miner (except that it has to be between 2 and 100 bytes long, and subject to BIP34's requirement that it starts with a push of the block height). Miners use this field to put messages in, but since very early on, part is also used as an additional overflow nonce field. There are no consensus rules governing this, just miners choosing to use the coinbase scriptSig this way.
Pieter Wuille
CC BY-SA 4.0
2023-03-19T13:57:48.043Z
@Pieter: Thanks, updated.
RedGrittyBrick
CC BY-SA 4.0
2023-03-19T19:01:46.607Z
In the more recent past, miners have also been using the version field as a source of entropy per Overt ASICBoost.
Murch
CC BY-SA 4.0
2023-03-19T21:30:10.803Z
@Murch: Thanks, updated.
RedGrittyBrick
CC BY-SA 4.0
2021-08-21T09:57:21.550Z
2023-03-20T18:29:56.167Z
2023-03-20T18:29:56.167Z
RedGrittyBrick
<p>What are the list of all the variables whose values that the miner can cycle or modify to get a valid hash for this block (with very high probability) ? The only one I am aware of is:</p>
<ol>
<li>Nonce - 4 Bytes.</li>
</ol>
<p>But since Nonce is just 4 bytes it is simply not enough for generating many potential hash candidates that pass the difficuly condition of SHA256 (256 bits).</p>
<p>What are the other variables that can be tweaked for ensuring the existence of a passing hash candidate (with very high probability)?</p>
<p>P.S. We are assuming that all the hashes are calculated immediately so timestamp for each candidate is same. Thus, timestamp wont be able to help as far as I understand.</p>
<p>I am struggling with this for a while and can't find much detailed answer for this (other than nonce).</p>

CC BY-SA 4.0
2021-08-21T17:23:40.823Z
Related: https://bitcoin.stackexchange.com/q/90393/5406, https://bitcoin.stackexchange.com/q/96434/5406
Murch
<mining-theory><hash><block-header>
What parts of a block, other than the nonce, can a miner vary
J.Doe
# What parts of a block, other than the nonce, can a miner vary

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

What are the list of all the variables whose values that the miner can cycle or modify to get a valid hash for this block (with very high probability) ? The only one I am aware of is:

1. Nonce - 4 Bytes.

But since Nonce is just 4 bytes it is simply not enough for generating many potential hash candidates that pass the difficuly condition of SHA256 (256 bits).

What are the other variables that can be tweaked for ensuring the existence of a passing hash candidate (with very high probability)?

P.S. We are assuming that all the hashes are calculated immediately so timestamp for each candidate is same. Thus, timestamp wont be able to help as far as I understand.

I am struggling with this for a while and can't find much detailed answer for this (other than nonce).

**Tags:** mining-theory, hash, block-header

> **Comments:**
> **username_1**: Related: https://bitcoin.stackexchange.com/q/90393/5406, https://bitcoin.stackexchange.com/q/96434/5406  

---

## 1 answers

### Answer by username_2 on 2021-08-21. Score: 4

**ExtraNonce**: As well as the Nonce field, There is also an [extranonce](https://bitcoin.stackexchange.com/q/36455/13866) convention - a part of the unlocking script in the input of the coinbase transaction is used as an extra nonce by miners.

**Timestamp**: The miner can vary the timestamp. It only has to be accurate within about 2 hours. It doesn't have to be greater than the timestamp of the previous block.

**Version**: Miners can vary a part of the version number. There is a method known as [ASICboost](https://bitcoin.stackexchange.com/q/79273/13866) which helps miners who are using ASICs for mining.

**Coinbase output**: The miner can vary the coinbase output. Perhaps selecting a different receiving address or varying the type of script.

**Transaction order**: The miner can vary the order of transactions (other than for transactions that spend outputs of prior transactions in same block).

**Transactions**: The miner can make an arbitrary select of transactions from their mempool or create their own new arbitrary valid transactions to include. If inventing their own transactions they can vary the fee from zero to maximum and can vary the transaction type from legacy to latest. They can also vary the input amounts from near zero to whole UTXO. The transactions must be valid but that still allows a vast range of variations, assuming the miner owns some bitcoin to start with.

---

From [Bitcoin for Developers I](https://learn.saylor.org/mod/book/view.php?id=36375&chapterid=19427)

> Table 2. The structure of a coinbase transaction input
>
> | Size | Field | Description |
> | --- | --- | --- |
> | 32 bytes | Transaction Hash | All bits are zero: Not a transaction hash reference |
> | 4 bytes | Output Index | All bits are ones: 0xFFFFFFFF |
> | 1–9 bytes (VarInt) | Coinbase Data Size | Length of the coinbase data, from 2 to 100 bytes |
> | Variable | Coinbase Data | Arbitrary data used for **extra nonce** and mining tags. In v2 blocks; must begin with block height |
> | 4 bytes | Sequence Number | Set to 0xFFFFFFFF |

See also [BIP-34](https://github.com/bitcoin/bips/blob/master/bip-0034.mediawiki)

> **Comments:**
> **username_0**: Thank you. I get the generic idea but I am not clear on the specifics or structure of some things: such as Extranonce, the coinbase script part. Can you please point to a resource where its discussed in details and is more specific (for implementation level details)?  
> **username_3**: The ExtraNonce isn't a "field", it's more a practice. The entire scriptSig of the coinbase transaction input is freely chosen by the miner (except that it has to be between 2 and 100 bytes long, and subject to BIP34's requirement that it starts with a push of the block height). Miners use this field to put messages in, but since very early on, part is also used as an additional overflow nonce field. There are no consensus rules governing this, just miners choosing to use the coinbase scriptSig this way.  
> **username_2**: @username_3: Thanks, updated.  
> **username_1**: In the more recent past, miners have also been using the version field as a source of entropy per Overt ASICBoost.  
> **username_2**: @username_1: Thanks, updated.  

---

