<blockquote>
  <p>As I understood, in the block hash, the amount of zero's is the nonce,</p>
</blockquote>

<p>No, that is incorrect.</p>

<p>The nonce is a value in the block header, which is then hashed. By changing the nonce, a new block header is effectively created which has its own unique hash.</p>

<blockquote>
  <p>Then the hash is recomputed for each value until a hash containing the required number of zero bits is found.</p>
</blockquote>

<p>No. Contrary to popular belief, the correct hash is not based on the number of zeros in the block hash. That is just an abstraction to make it easier for people to understand.</p>

<p>What the correct hash actually uses is a target value. This target value is a 256 bit integer. In order for a block hash to be considered having a valid proof of work, it, when interpreted as a 256 bit integer must be less than or equal to the target value.</p>

<p>Since it is actually an integer comparison and not checking the number of 0 bits, there are far more possible target values.</p>

CC BY-SA 3.0
2018-01-29T05:29:08.183Z
2018-01-29T05:29:08.183Z
Ava Chow
<p>The example you give implies that you are concerned about a target set as low as 256 (two hex digits).  I don't think you realize just how much of an increase in difficulty that would represent.</p>

<p>As Andrew's answer points out, it's not actually looking for a number of leading zeros.  That is merely a consequence of numbers that are less than a target value.  However, this might not be a bad way to think about it in order to appreciate how this scales.  For each additional zero, it is 16 times harder to find a hash.  There are currently about 18 leading zeros, and hashes have a total of 64 hex digits.  To get to the example you are concerned about (2 nonzero hex digits), where there are 44 fewer leading zeroes, the network would have to increase its total hashrate to 16^44 its current rate.</p>

<p>That is simply not going to happen.  With our current method of building computers, I'm not even sure our planet contains enough atoms to construct the transistors required to perform such a proof of work in a ten minute span.</p>

CC BY-SA 3.0
2018-01-29T06:52:57.200Z
2018-01-29T06:52:57.200Z
Jestin
<p>As I understood, in the block hash, the amount of zero's is the nonce, like this:</p>

<pre><code>0000000000000000005f54622d97866453137466737289c2500e67f6fce1cd4e
</code></pre>

<p>When there are more blocks found than in the average of 10 minutes, the nonce will increase. Then the hash is recomputed for each value until a hash containing the required number of zero bits is found.</p>

<p>But imagine the development of ASIC's accerlates expotentially, so the nonce for the required hash will be like this, for example:</p>

<pre><code>000000000000000000000000000000000000000000000000000000000000004e
</code></pre>

<p>I know there are more information required, but let's imagine this in 2020 if the development of new ASIC could accelerate. </p>

<p>So in theory there are only 28 (note the position of 4 in block hash) x 28 (position of e in block hash) = 784 remaining possible hashes. Would thatn't mean that the Bitcoin ecosystem with an insane difficulty will eventually runs out of possible hash combinations for blocks?</p>

<block-hash>
In the case the difficulty increases as much in future, will the possible hashes run out/be insecure?
ReneFroger
# In the case the difficulty increases as much in future, will the possible hashes run out/be insecure?

(Asked by: username_0 on 2018-01-28)

As I understood, in the block hash, the amount of zero's is the nonce, like this:

```
0000000000000000005f54622d97866453137466737289c2500e67f6fce1cd4e

```

When there are more blocks found than in the average of 10 minutes, the nonce will increase. Then the hash is recomputed for each value until a hash containing the required number of zero bits is found.

But imagine the development of ASIC's accerlates expotentially, so the nonce for the required hash will be like this, for example:

```
000000000000000000000000000000000000000000000000000000000000004e

```

I know there are more information required, but let's imagine this in 2020 if the development of new ASIC could accelerate.

So in theory there are only 28 (note the position of 4 in block hash) x 28 (position of e in block hash) = 784 remaining possible hashes. Would thatn't mean that the Bitcoin ecosystem with an insane difficulty will eventually runs out of possible hash combinations for blocks?

**Tags:** block-hash


---

## 2 answers

### Answer by username_1 on 2018-01-29. Score: 1

> As I understood, in the block hash, the amount of zero's is the nonce,

No, that is incorrect.

The nonce is a value in the block header, which is then hashed. By changing the nonce, a new block header is effectively created which has its own unique hash.

> Then the hash is recomputed for each value until a hash containing the required number of zero bits is found.

No. Contrary to popular belief, the correct hash is not based on the number of zeros in the block hash. That is just an abstraction to make it easier for people to understand.

What the correct hash actually uses is a target value. This target value is a 256 bit integer. In order for a block hash to be considered having a valid proof of work, it, when interpreted as a 256 bit integer must be less than or equal to the target value.

Since it is actually an integer comparison and not checking the number of 0 bits, there are far more possible target values.


---

### Answer by username_2 on 2018-01-29. Score: 0

The example you give implies that you are concerned about a target set as low as 256 (two hex digits). I don't think you realize just how much of an increase in difficulty that would represent.

As Andrew's answer points out, it's not actually looking for a number of leading zeros. That is merely a consequence of numbers that are less than a target value. However, this might not be a bad way to think about it in order to appreciate how this scales. For each additional zero, it is 16 times harder to find a hash. There are currently about 18 leading zeros, and hashes have a total of 64 hex digits. To get to the example you are concerned about (2 nonzero hex digits), where there are 44 fewer leading zeroes, the network would have to increase its total hashrate to 16^44 its current rate.

That is simply not going to happen. With our current method of building computers, I'm not even sure our planet contains enough atoms to construct the transistors required to perform such a proof of work in a ten minute span.


---

