<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.


---

