<blockquote>
<p><strong>the resulting hash should start with difficulty number of zeroes before a block can be mined.</strong></p>
</blockquote>
<p>No, the hash should be less than the target for the mined block to be valid (acceptable to others).</p>
<p>The often repeated &quot;number of leading zeroes&quot; is not the reality.</p>
<p>The difficulty is not a count of leading zeroes and is not used in Bitcoin's assessment of block-hashes.</p>
<blockquote>
<p><strong><code>H(HashOfPreviosBlock + nonce) &lt; target</code></strong></p>
</blockquote>
<p>The block hash is a hash of much more data than that. It includes, for example, the Merkle root and some other items in the block header.</p>
<blockquote>
<p><strong>why is a 64 bit number guaranteed to generate</strong></p>
</blockquote>
<p>The nonce is a 32 bit number and it isn't guaranteed that there exists a 32-bit value that would generate a hash less than a target. (See links under &quot;Related&quot; at right of web-page)</p>
<p>For many years it has been necessary for miners to vary much more than the nonce. There is ExtraNonce, selection and order of transactions, contents of coinbase transaction, timestamp, etc.</p>

CC BY-SA 4.0
2022-05-26T08:54:52.760Z
2022-05-26T09:07:30.663Z
2022-05-26T09:07:30.663Z
RedGrittyBrick
<p>The <strong>4-byte</strong> <code>nonce</code> field is not nearly enough.</p>
<p>However, the block hash is a hash of the full block header (80 bytes, see below for reference), not just the <code>previous block hash</code> &amp; <code>nonce</code>.</p>
<p>So what do miners do? They roll other parts of the block header: <code>version</code> and <code>timestamp</code> have some more &quot;free&quot; bits with which they can play, and every time contents of the block template get changed the whole <code>merkle root</code> gets pseudo-randomly updated and effectively allows a new pass over the <code>nonce</code>, <code>version</code> &amp; <code>timestamp</code> bits.</p>
<p>So, in order to not waste the work - the <code>merkle root</code> must be updated often enough, and pools can easily automate this to be independent of user-made TXs: roll some part of the coinbase TX every now and then.</p>
<h2>Block Header Format</h2>
<div class="s-table-container">
<table class="s-table">
<thead>
<tr>
<th>Field</th>
<th>Length</th>
<th>Format</th>
<th>Description</th>
</tr>
</thead>
<tbody>
<tr>
<td>version</td>
<td>4 bytes</td>
<td>unsigned integer<sup>(LE)</sup></td>
<td>The block format version.</td>
</tr>
<tr>
<td>previous block hash</td>
<td>32 bytes</td>
<td>block hash<sup>(LE)</sup></td>
<td>The hash of the block immediately preceding this block in the blockchain.</td>
</tr>
<tr>
<td>merkle root</td>
<td>32 bytes</td>
<td>merkle root<sup>(LE)</sup></td>
<td>The merkle tree root of the transactions in the block.</td>
</tr>
<tr>
<td>timestamp</td>
<td>4 bytes</td>
<td>unix timestamp<sup>(LE)</sup></td>
<td>The epoch timestamp of the block in seconds.</td>
</tr>
<tr>
<td>target</td>
<td>4 bytes</td>
<td>compressed target<sup>(LE)</sup></td>
<td>The target that the block hash must be below to be valid.  This value is determined by the timestamps of previously mined blocks.</td>
</tr>
<tr>
<td>nonce</td>
<td>4 bytes</td>
<td>bytes<sup>(LE)</sup></td>
<td>A random value that is repeatedly changed during block mining in order to achieve the block hash requirements.</td>
</tr>
</tbody>
</table>
</div>
<p>Example, the Bitcoin genesis block header is:</p>
<pre><code>0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c
</code></pre>
<p>and it hashes to <code>000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f</code>. You can get the hash using shell with:</p>
<pre><code>echo '0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c' -n | xxd -r -p | sha256sum | xxd -r -p | sha256sum | cut -b 1-64 | tac -rs '..'; echo
</code></pre>

CC BY-SA 4.0
2023-11-17T09:15:26.967Z
2023-11-17T09:20:44.380Z
2023-11-17T09:20:44.380Z
bca-0353f40e
<p>The difficulty is now 1 in 2^68 chance of a correct  hash.  So 64 bits would not be sufficient either.  The number of 0s on the output says how many bits on the input must change effectively.</p>

CC BY-SA 4.0
2023-11-17T02:36:37.670Z
2023-11-23T23:30:56.833Z
2023-11-23T23:30:56.833Z
Gregory Morse
<p>As far as I can understand the resulting hash should start with <code>difficulty</code> number of zeroes before a block can be mined. That is: <code>H(HashOfPreviosBlock + nonce) &lt; target</code> but why is a 64 bit number guaranteed to generate</p>

CC BY-SA 4.0
2022-05-26T02:35:13.857Z
The nonce is only 32 bits.
Pieter Wuille
<nonce>
Why is a nonce enough to be 64 bits?
Lumbda Kokolala
# Why is a nonce enough to be 64 bits?

(Asked by: username_0 on 2022-05-26)

As far as I can understand the resulting hash should start with `difficulty` number of zeroes before a block can be mined. That is: `H(HashOfPreviosBlock + nonce) < target` but why is a 64 bit number guaranteed to generate

**Tags:** nonce

> **Comments:**
> **username_1**: The nonce is only 32 bits.  

---

## 3 answers

### Answer by username_2 on 2022-05-26. Score: 2

> **the resulting hash should start with difficulty number of zeroes before a block can be mined.**

No, the hash should be less than the target for the mined block to be valid (acceptable to others).

The often repeated "number of leading zeroes" is not the reality.

The difficulty is not a count of leading zeroes and is not used in Bitcoin's assessment of block-hashes.

> **`H(HashOfPreviosBlock + nonce) < target`**

The block hash is a hash of much more data than that. It includes, for example, the Merkle root and some other items in the block header.

> **why is a 64 bit number guaranteed to generate**

The nonce is a 32 bit number and it isn't guaranteed that there exists a 32-bit value that would generate a hash less than a target. (See links under "Related" at right of web-page)

For many years it has been necessary for miners to vary much more than the nonce. There is ExtraNonce, selection and order of transactions, contents of coinbase transaction, timestamp, etc.


---

### Answer by username_3 on 2023-11-17. Score: 2

The 4-byte nonce field is not nearly enough.
However, the block hash is a hash of the full block header (80 bytes, see below for reference), not just the previous block hash & nonce.
So what do miners do? They roll other parts of the block header: version and timestamp have some more "free" bits with which they can play, and every time contents of the block template get changed the whole merkle root gets pseudo-randomly updated and effectively allows a new pass over the nonce, version & timestamp bits.
So, in order to not waste the work - the merkle root must be updated often enough, and pools can easily automate this to be independent of user-made TXs: roll some part of the coinbase TX every now and then.
Block Header Format




Field
Length
Format
Description




version
4 bytes
unsigned integer(LE)
The block format version.


previous block hash
32 bytes
block hash(LE)
The hash of the block immediately preceding this block in the blockchain.


merkle root
32 bytes
merkle root(LE)
The merkle tree root of the transactions in the block.


timestamp
4 bytes
unix timestamp(LE)
The epoch timestamp of the block in seconds.


target
4 bytes
compressed target(LE)
The target that the block hash must be below to be valid.  This value is determined by the timestamps of previously mined blocks.


nonce
4 bytes
bytes(LE)
A random value that is repeatedly changed during block mining in order to achieve the block hash requirements.




Example, the Bitcoin genesis block header is:
0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c

and it hashes to 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f. You can get the hash using shell with:
echo '0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c' -n | xxd -r -p | sha256sum | xxd -r -p | sha256sum | cut -b 1-64 | tac -rs '..'; echo


---

### Answer by username_4 on 2023-11-17. Score: -2

The difficulty is now 1 in 2^68 chance of a correct hash. So 64 bits would not be sufficient either. The number of 0s on the output says how many bits on the input must change effectively.


---

