<p>Cryptographic hash functions are collision resistant and the <a href="https://crypto.stackexchange.com/q/12822/8801">digests produced by SHA-256 are approximately uniformly distributed</a>. This suggests that if the input space to the hash function is magnitudes bigger than the projection space of a hash function, we would expect that every value of the projection space can be hit.</p>
<p>The block header is 80 bytes, and the digest space of SHA-256 is 32 byte (256 bit). Out of the 80 bytes of the block header, <a href="https://bitcoin.stackexchange.com/q/90393/5406">version is unrestricted on 29 of 32 bits</a>, the nonce is a 4-byte arbitrary value, the Merkle root is a 256-bit digest derived from an enormous combination space, the <a href="https://bitcoin.stackexchange.com/q/1482/5406">timestamp is rather flexible</a>—limited to a unix timestamp range of roughly 3h/10,800 seconds (~13 bits), only the previous block hash and difficulty statement are fixed. So, before counting the Merkle root, miners could generate up to 74 bits of entropy in the block header.</p>
<p>The <a href="https://bitcoin.stackexchange.com/q/10479/5406">Merkle root</a> is derived from the set of transactions that a <a href="https://bitcoin.stackexchange.com/q/37191/5406">miner is choosing</a> to include in their Bitcoin block. Not only can the miner arbitrarily pick content and order of the (valid) transactions, but also each miner is paying themselves in the <a href="https://bitcoin.stackexchange.com/q/4571/5406">coinbase transaction</a> of their block candidate. Given that paying to different addresses results in different coinbase transactions, every miner is working on a unique transaction set whose Merkle roots making any overlap between block candidates of different miners astronomically unlikely. Further, parts of the coinbase transaction's input can be picked arbitrarily (the &quot;<a href="https://bitcoin.stackexchange.com/a/32618/5406">extranonce</a>&quot; and most of the remaining 2–100 byte input script of the coinbase transaction) giving miners a way to easily add further entropy to the set of block candidates they're evaluating. Additionally, miners update their block candidate's transaction composition whenever more new transactions paying higher fee rates <a href="https://bitcoin.stackexchange.com/a/54889/5406">arrive</a>. Even if there were no transactions to add in the block, miners could just generate a different address to pay themselves for use in the Coinbase after exhausting the nonce and extranonce space.</p>
<p>Given the power set of all possible transaction orders, the address space of Bitcoin, and the 100 byte input script in sum by far exceed the 32-byte digest size of SHA-256d, I'd argue that the Merkle root provides a full 32 bytes of entropy.</p>
<p><strong>In sum that gives the miners ~41 bytes of arbitrary input data to produce a 32-byte digest i.e. an input space 2<sup>72</sup> bigger than the projection space.</strong> Meanwhile, a block is only restricted to the current difficulty which is significantly smaller than 2<sup>224</sup> (the difficulty of requiring a block hash <code>000…0</code>).</p>
<p>While this doesn't meet the requirements of a rigorous mathematical proof, I'd surmise that miners do not have to worry about running out of possible block candidates. Therefore, it's just a matter of time until someone happens to succeed at creating a new valid block.</p>
<p>Also see this closely related question here: <a href="https://bitcoin.stackexchange.com/q/22978/5406">How can we be sure that a new block will be found?</a>.</p>

CC BY-SA 4.0
2020-06-23T19:29:16.800Z
Nice! Thanks, @Murch, it makes more sense now.  The nice and detailed answer, thank you.  One more question. If I want to play with this, any way to connect to the pool of unapproved transactions and try to compose block myself (by using local custom programs), instead of using bitcoins standard mining tools. Any API, or similar thing to get unapproved transactions.
Ruben
CC BY-SA 4.0
2020-06-23T22:59:10.887Z
I think you may be looking for [getrawmempool](https://bitcoincore.org/en/doc/0.16.0/rpc/blockchain/getrawmempool/). Not sure about programs to build blocks from that then, though. I guess some miner controller might do?
Murch
CC BY-SA 4.0
2020-06-11T22:52:28.053Z
2020-06-22T23:38:02.213Z
2020-06-22T23:38:02.213Z
Murch
<p>Version, hashPrevBlock, Bits (a representation of the current difficulty) are static for the current block, the timeStamp is a unix representation of the current time, the miner can change it to change the blockheader too (untill 2 hours in the future)</p>

CC BY-SA 4.0
2020-06-12T17:09:50.460Z
2020-06-12T17:09:50.460Z
Hamita
<p>Sorry for the obvious question, but I'm looking for a mathematical prove.</p>

<p>Block header is calculated as a concatenation of the following values.</p>

<ul>
<li>Version</li>
<li>hashPrevBlock</li>
<li>hashMerkleRoot</li>
<li>timeStamp</li>
<li>Bits</li>
<li>Nonce (32-bit number)</li>
</ul>

<p>First 5 parameters are static for each block. Miner only tries to find out Nonce value, such that Hash(Block_header) will start with a certain number of zeroes. </p>

<p>Is that proved that for each combination of Version, hashPrevBlock, hashMerkleRoot, timeStamp and Bits there is a Nonce value, that will make block hash to start with a certain number of zeroes?</p>

<p>If yes, can you please share any article that explains that prove?</p>

CC BY-SA 4.0
2020-06-18T17:06:27.437Z
32 bits nonce + maybe a few bits in timestamp which you can change in hope to get a hash with 9.5 bytes of zeroes in front (19 hex-zeros) it is highly unlikely (as off June 2020 difficulty rate). Thus, you have to change your Merkle root. Just change the transactions inside the block (add, delete or rearrange or modify the coinbase tx )
Cisco Mmu
CC BY-SA 4.0
2020-06-23T20:24:47.403Z
Part of the requirement of a secure cryptographic hash function is that the output should be unpredictable, and therefore it should not be possible to say much with certainty about what can and can't happen.  It's overwhelmingly likely that every block can be mined, as explained in the answer.  But if there were a mathematical proof that it's always possible, that would be an indication that SHA256 is too predictable and that we ought not to be using it.
Nate Eldredge
CC BY-SA 4.0
2020-06-11T17:24:13.213Z
the hashMerkleRoot is not static, as it is calculated from the set of transactions included in the block, which can vary. The miner is free to organize these however they like, with the only restriction being that the first transaction must be the coinbase.
Mark H
CC BY-SA 4.0
2020-06-12T17:34:25.813Z
The odds of any nonce producing a valid block are miniscule. The vast majority of blocks cannot be mined. Miners have to try to mine billions of blocks before they succeed in mining one.
David Schwartz
<blockchain><hash><nonce>
Is that proved that for each block there is always nonce value which will make block hash to start by n count of 0
Ruben
# Is that proved that for each block there is always nonce value which will make block hash to start by n count of 0

(Asked by: username_0 on 2020-06-11)

Sorry for the obvious question, but I'm looking for a mathematical prove.

Block header is calculated as a concatenation of the following values.

* Version
* hashPrevBlock
* hashMerkleRoot
* timeStamp
* Bits
* Nonce (32-bit number)

First 5 parameters are static for each block. Miner only tries to find out Nonce value, such that Hash(Block\_header) will start with a certain number of zeroes.

Is that proved that for each combination of Version, hashPrevBlock, hashMerkleRoot, timeStamp and Bits there is a Nonce value, that will make block hash to start with a certain number of zeroes?

If yes, can you please share any article that explains that prove?

**Tags:** blockchain, hash, nonce

> **Comments:**
> **username_3**: the hashMerkleRoot is not static, as it is calculated from the set of transactions included in the block, which can vary. The miner is free to organize these however they like, with the only restriction being that the first transaction must be the coinbase.  
> **username_4**: The odds of any nonce producing a valid block are miniscule. The vast majority of blocks cannot be mined. Miners have to try to mine billions of blocks before they succeed in mining one.  
> **username_1**: 32 bits nonce + maybe a few bits in timestamp which you can change in hope to get a hash with 9.5 bytes of zeroes in front (19 hex-zeros) it is highly unlikely (as off June 2020 difficulty rate). Thus, you have to change your Merkle root. Just change the transactions inside the block (add, delete or rearrange or modify the coinbase tx )  
> **username_2**: Part of the requirement of a secure cryptographic hash function is that the output should be unpredictable, and therefore it should not be possible to say much with certainty about what can and can't happen.  It's overwhelmingly likely that every block can be mined, as explained in the answer.  But if there were a mathematical proof that it's always possible, that would be an indication that SHA256 is too predictable and that we ought not to be using it.  

---

## 2 answers

### Answer by username_5 on 2020-06-11. Score: 3

Cryptographic hash functions are collision resistant and the [digests produced by SHA-256 are approximately uniformly distributed](https://crypto.stackexchange.com/q/12822/8801). This suggests that if the input space to the hash function is magnitudes bigger than the projection space of a hash function, we would expect that every value of the projection space can be hit.

The block header is 80 bytes, and the digest space of SHA-256 is 32 byte (256 bit). Out of the 80 bytes of the block header, [version is unrestricted on 29 of 32 bits](https://bitcoin.stackexchange.com/q/90393/5406), the nonce is a 4-byte arbitrary value, the Merkle root is a 256-bit digest derived from an enormous combination space, the [timestamp is rather flexible](https://bitcoin.stackexchange.com/q/1482/5406)—limited to a unix timestamp range of roughly 3h/10,800 seconds (~13 bits), only the previous block hash and difficulty statement are fixed. So, before counting the Merkle root, miners could generate up to 74 bits of entropy in the block header.

The [Merkle root](https://bitcoin.stackexchange.com/q/10479/5406) is derived from the set of transactions that a [miner is choosing](https://bitcoin.stackexchange.com/q/37191/5406) to include in their Bitcoin block. Not only can the miner arbitrarily pick content and order of the (valid) transactions, but also each miner is paying themselves in the [coinbase transaction](https://bitcoin.stackexchange.com/q/4571/5406) of their block candidate. Given that paying to different addresses results in different coinbase transactions, every miner is working on a unique transaction set whose Merkle roots making any overlap between block candidates of different miners astronomically unlikely. Further, parts of the coinbase transaction's input can be picked arbitrarily (the "[extranonce](https://bitcoin.stackexchange.com/a/32618/5406)" and most of the remaining 2–100 byte input script of the coinbase transaction) giving miners a way to easily add further entropy to the set of block candidates they're evaluating. Additionally, miners update their block candidate's transaction composition whenever more new transactions paying higher fee rates [arrive](https://bitcoin.stackexchange.com/a/54889/5406). Even if there were no transactions to add in the block, miners could just generate a different address to pay themselves for use in the Coinbase after exhausting the nonce and extranonce space.

Given the power set of all possible transaction orders, the address space of Bitcoin, and the 100 byte input script in sum by far exceed the 32-byte digest size of SHA-256d, I'd argue that the Merkle root provides a full 32 bytes of entropy.

**In sum that gives the miners ~41 bytes of arbitrary input data to produce a 32-byte digest i.e. an input space 272 bigger than the projection space.** Meanwhile, a block is only restricted to the current difficulty which is significantly smaller than 2224 (the difficulty of requiring a block hash `000…0`).

While this doesn't meet the requirements of a rigorous mathematical proof, I'd surmise that miners do not have to worry about running out of possible block candidates. Therefore, it's just a matter of time until someone happens to succeed at creating a new valid block.

Also see this closely related question here: [How can we be sure that a new block will be found?](https://bitcoin.stackexchange.com/q/22978/5406).

> **Comments:**
> **username_0**: Nice! Thanks, @username_5, it makes more sense now.  The nice and detailed answer, thank you.  One more question. If I want to play with this, any way to connect to the pool of unapproved transactions and try to compose block myself (by using local custom programs), instead of using bitcoins standard mining tools. Any API, or similar thing to get unapproved transactions.  
> **username_5**: I think you may be looking for [getrawmempool](https://bitcoincore.org/en/doc/0.16.0/rpc/blockchain/getrawmempool/). Not sure about programs to build blocks from that then, though. I guess some miner controller might do?  

---

### Answer by username_6 on 2020-06-12. Score: 0

Version, hashPrevBlock, Bits (a representation of the current difficulty) are static for the current block, the timeStamp is a unix representation of the current time, the miner can change it to change the blockheader too (untill 2 hours in the future)


---

