<blockquote>
<p>First of all is my understanding accurate? In other words are the only degrees of freedom the following?:</p>
<ul>
<li>choice of coinbase transaction message</li>
</ul>
</blockquote>
<p>If by that you mean the scriptSig of the coinbase transaction input, yes. Subject to the consensus rules which require it to be between 2 and 100 bytes, and to start with a push of the block height (see BIP34), miners have complete freedom about what to put there.</p>
<p>But in addition to just the scriptSig, the entire coinbase transaction can be chosen by the miner. This includes the payout address(es), and if there are multiple, how the subsidy/fees are distributed over those. Also miscellaneous things like the transaction version number, locktimes, and sequence values of the coinbase transaction could in theory be modified. Lastly, miners could insert dummy 0-value outputs to the coinbase transaction even.</p>
<blockquote>
<ul>
<li>choice of list of transactions to be included in the next block</li>
</ul>
</blockquote>
<p>Indeed. And the order of those transaction (subject to the constraint that if the block contains spends of outputs created within the same block, the creator transaction must come before the spender transaction).</p>
<p>And, miners could also come up with their own transactions to stuff into the block - though that carries the opportunity cost of not being able to use that block space for other fee-paying transactions.</p>
<blockquote>
<ul>
<li>timestamp</li>
</ul>
</blockquote>
<p>Yes, with the restriction that is has to be strictly higher than the median timestamp of the previous 11 blocks, and not more than 2 hours in the future.</p>
<blockquote>
<ul>
<li>nonce field</li>
</ul>
</blockquote>
<p>Yes.</p>
<blockquote>
<p>(what is the concept of extranonce? is it just part of the arbitrary message string for coinbase transaction?)</p>
</blockquote>
<p>Indeed.</p>
<blockquote>
<p>Second, what guarantees that within this search space, a valid block will be found? (is it just a probabilistic guarantee?)</p>
</blockquote>
<p>Yes, it is just probabilistic. Every attempt has an independent chance of being a valid block equal to the target value over <em>2<sup>256</sup></em>, or as of 2023 Nov 11, roughly one in <em>268282661671783234208589</em>.</p>

CC BY-SA 4.0
2023-11-12T22:24:42.567Z
Thanks for your answer :).
Marlex Blank
CC BY-SA 4.0
2023-11-12T03:30:58.713Z
2023-11-12T03:30:58.713Z
Pieter Wuille
<p>I am working on an educational project for bitcoin mining. I searched as much as I could but still haven't understood the following questions:</p>
<ol>
<li>What are the &quot;exact&quot; degrees of freedom in finding a valid block? (What exactly is the search space?)</li>
<li>What guarantees that within those degrees of freedom (search space) a valid block &quot;will&quot; be found?</li>
</ol>
<p>More details about my questions:</p>
<p>I know that a miner asks for a block template via &quot;getblocktemplate&quot; RPC command. Based on the &quot;bits&quot; field it can calculate the target hash relative to which the valid block's hash needs to be smaller than. I know over the course of mining, the network may create new block templates with updated info (for example additional transactions are added). So the miner can use the &quot;longpool&quot; feature to have the most updated version at all times. Moreover, the miner can &quot;choose&quot; which transactions to include in the next block. So they can exclude some transactions (as long as they are not marked mandatory). Furthermore, the miner can choose an arbitrary message string for the coinbase transaction. They can also play with the timestamp to some extend. So for each of these choices they go into a for loop over the &quot;nonce&quot; field from 0 to 2^32-1. If they cover all nonces (for a fixed set of choices) and still the target hash condition is not satisfied they can alter their choices now: for example choose a different message string for coinbase transaction and/or include/exclude transactions and/or modify timestamp.</p>
<p>First of all is my understanding accurate? In other words are the only degrees of freedom the following?:</p>
<ul>
<li>choice of coinbase transaction message</li>
<li>choice of list of transactions to be included in the next block</li>
<li>timestamp</li>
<li>nonce field
(what is the concept of extranonce? is it just part of the arbitrary message string for coinbase transaction?)</li>
</ul>
<p>Second, what guarantees that within this search space, a valid block will be found? (is it just a probabilistic guarantee?)</p>
<p>My apologies in advance if this is a newbie question. I searched a lot and could not get an exact answer.</p>
<p>Thanks.</p>

CC BY-SA 4.0
2023-11-28T18:12:16.517Z
Does one of these answer your question? [Is that proved that for each block there is always nonce value which will make block hash to start by n count of 0](https://bitcoin.stackexchange.com/a/96442/5406), [Which block header fields are miners able to change in an effort to avoid having to recalculate the Merkle Root?](https://bitcoin.stackexchange.com/q/90393/5406), [What parts of a block, other than the nonce, can a miner vary](https://bitcoin.stackexchange.com/q/108184/5406)
Murch
CC BY-SA 4.0
2023-12-10T08:55:57.133Z
It does. Thanks for sharing.
Marlex Blank
<mining-theory><block><block-header>
What are the exact degrees of freedom in finding a valid block?
Marlex Blank
# What are the exact degrees of freedom in finding a valid block?

(Asked by: username_0 on 2023-11-12)

I am working on an educational project for bitcoin mining. I searched as much as I could but still haven't understood the following questions:

1. What are the "exact" degrees of freedom in finding a valid block? (What exactly is the search space?)
2. What guarantees that within those degrees of freedom (search space) a valid block "will" be found?

More details about my questions:

I know that a miner asks for a block template via "getblocktemplate" RPC command. Based on the "bits" field it can calculate the target hash relative to which the valid block's hash needs to be smaller than. I know over the course of mining, the network may create new block templates with updated info (for example additional transactions are added). So the miner can use the "longpool" feature to have the most updated version at all times. Moreover, the miner can "choose" which transactions to include in the next block. So they can exclude some transactions (as long as they are not marked mandatory). Furthermore, the miner can choose an arbitrary message string for the coinbase transaction. They can also play with the timestamp to some extend. So for each of these choices they go into a for loop over the "nonce" field from 0 to 2^32-1. If they cover all nonces (for a fixed set of choices) and still the target hash condition is not satisfied they can alter their choices now: for example choose a different message string for coinbase transaction and/or include/exclude transactions and/or modify timestamp.

First of all is my understanding accurate? In other words are the only degrees of freedom the following?:

* choice of coinbase transaction message
* choice of list of transactions to be included in the next block
* timestamp
* nonce field
  (what is the concept of extranonce? is it just part of the arbitrary message string for coinbase transaction?)

Second, what guarantees that within this search space, a valid block will be found? (is it just a probabilistic guarantee?)

My apologies in advance if this is a newbie question. I searched a lot and could not get an exact answer.

Thanks.

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

> **Comments:**
> **username_1**: Does one of these answer your question? [Is that proved that for each block there is always nonce value which will make block hash to start by n count of 0](https://bitcoin.stackexchange.com/a/96442/5406), [Which block header fields are miners able to change in an effort to avoid having to recalculate the Merkle Root?](https://bitcoin.stackexchange.com/q/90393/5406), [What parts of a block, other than the nonce, can a miner vary](https://bitcoin.stackexchange.com/q/108184/5406)  
> **username_0**: It does. Thanks for sharing.  

---

## 1 answers

### Answer by username_2 on 2023-11-12. Score: 2

> First of all is my understanding accurate? In other words are the only degrees of freedom the following?:
>
> * choice of coinbase transaction message

If by that you mean the scriptSig of the coinbase transaction input, yes. Subject to the consensus rules which require it to be between 2 and 100 bytes, and to start with a push of the block height (see BIP34), miners have complete freedom about what to put there.

But in addition to just the scriptSig, the entire coinbase transaction can be chosen by the miner. This includes the payout address(es), and if there are multiple, how the subsidy/fees are distributed over those. Also miscellaneous things like the transaction version number, locktimes, and sequence values of the coinbase transaction could in theory be modified. Lastly, miners could insert dummy 0-value outputs to the coinbase transaction even.

> * choice of list of transactions to be included in the next block

Indeed. And the order of those transaction (subject to the constraint that if the block contains spends of outputs created within the same block, the creator transaction must come before the spender transaction).

And, miners could also come up with their own transactions to stuff into the block - though that carries the opportunity cost of not being able to use that block space for other fee-paying transactions.

> * timestamp

Yes, with the restriction that is has to be strictly higher than the median timestamp of the previous 11 blocks, and not more than 2 hours in the future.

> * nonce field

Yes.

> (what is the concept of extranonce? is it just part of the arbitrary message string for coinbase transaction?)

Indeed.

> Second, what guarantees that within this search space, a valid block will be found? (is it just a probabilistic guarantee?)

Yes, it is just probabilistic. Every attempt has an independent chance of being a valid block equal to the target value over *2256*, or as of 2023 Nov 11, roughly one in *268282661671783234208589*.

> **Comments:**
> **username_0**: Thanks for your answer :).  

---

