<p>Unique hashes are not something that we are likely to run out of in the near-to-medium term future, unless huge advancements in computation are made (in which case we'd have other issues to worry about).</p>

<p>When Bitcoin adds a zero to the front of the target, it is not a zero in hexadecimal (how hashes are usually visualized), it is adding it in binary.  The difference is huge:</p>

<pre><code>0FFF -&gt; 00FF
</code></pre>

<p>means this in binary:</p>

<pre><code>0000111111111111 -&gt; 0000000011111111
</code></pre>

<p>What really happens is this:</p>

<pre><code>0000111111111111 -&gt; 0000011111111111
</code></pre>

<p>Or in hex:</p>

<pre><code>0FFF -&gt; 07FF
</code></pre>

<p>This means it will take 4 times as long to reach your point of concern as you thought.  Also, let's look at the block hash you posted:</p>

<pre><code>000000000000000000bbfa2afceac352a16db934867103aa85e6a83dc0fb6dfb
</code></pre>

<p>There are currently 18 leading hex zeros, which translates to 72 leading binary zeros.  This leaves 184 bits (256 - 72) for a unique hash value, or 2^184 unique hashes.  So right now, if the difficulty never increased and assuming a 10 minute block time, that still leaves us with 4.66*10^50 years worth of hashes (which is roughly 5 time the age of the universe).  When the difficulty doubles, we now only have 183 bits of hash space.  This means it's about 4.66*10^25 years, or about 2.5 times the age of the universe of hash space left.  As you can see, it will take some time for the difficulty to reach a point where hash space is a reasonable issue.</p>

<p>However, the real problem is not with total hash space, but with probable collisions.  Let's say that we have gotten to the point where there are only 56 bits available for hash space.  First, this would take a truly massive hashing increase in the Bitcoin network to ever come about (difficulty would have to double 128 times), but we'll ignore that for this example.  While 2^56 may seem like a small hash in modern cryptography, for this use case, it's not.  We still have enough hashes left to cover the entire age of the universe, but again, we are concerned with someone finding a block with a hash that matches an existing block (or competing block).</p>

<p>So what would we do?  I'm sure there'd be some debate if this ever came up, but I think the simple solution would be to reject that hash, just as if it were above the target difficulty.  Miners would be forced to continue hashing until another block was found.  After all, there is still plenty of room in the hash space, even when reduced to 56 bits (which is currently preposterous). Such a change to the protocol would only be a soft fork.</p>

<p>To summarize, even with our best estimates of future computing technology the remaining time for Bitcoin hashes is best measured in multiples of the age of the universe.  Even if this became an issue, a simple soft fork could fix it.  There's really not much to worry about here.</p>

CC BY-SA 3.0
2017-08-23T17:08:38.387Z
Your arithmetic is off. 2^184 blocks is about 4.7e50 years, but 2^183 reduces the _significand_ to 2.4e50 years not the exponent to 4.7e25. And those are about 3.4e41 and 1.7e41 times the age of the universe (1.4e10 years) not 5 and 2.5.
dave_thompson_085
CC BY-SA 3.0
2017-08-23T23:09:26.753Z
Whoops.  Late night math.
Jestin
CC BY-SA 3.0
2017-08-23T06:18:08.690Z
2017-08-23T06:18:08.690Z
Jestin
<p>This is another one of the scaling issues. Bitcoin has been designed to last for a long time, but many issues, like the one concerning block size of as recent, are still going to take a while to come into play. As you can see here: <a href="https://blockchain.info/block/000000000000000000bbfa2afceac352a16db934867103aa85e6a83dc0fb6dfb" rel="nofollow noreferrer">https://blockchain.info/block/000000000000000000bbfa2afceac352a16db934867103aa85e6a83dc0fb6dfb</a> the latest block has about 1/3 of the total potential target as zeroes. That means that the difficulty could double and we would still be fine. </p>

CC BY-SA 3.0
2017-08-23T04:15:08.933Z
Doubling the difficulty would only result in *one* additional leading zero.  Exponential growth FTW!  Doubling the number of leading zeros would require *squaring* the difficulty.
Nate Eldredge
CC BY-SA 3.0
2017-08-23T04:21:26.707Z
("Leading zero" here is in terms of bits, of course.)
Nate Eldredge
CC BY-SA 3.0
2017-08-22T22:41:57.003Z
2017-08-22T22:41:57.003Z
James P.
<p>I'm a bitcoin/blockchain layman. I'm just getting my head around the hashing of blocks and the increase in difficulty (number of zeros) required as more miners get involved. I understand this is to maintain the 10 minute hash rate.</p>

<p>I understand the generation of more difficult hashes is attractive because it makes the chain more difficult to re-write and therefore safer. </p>

<p>As I read-on, the escalated use of computing power required is a point of conflict in my mind. We can't continue to increase the difficulty because the hashes are fixed length and need to be unique? Can't keep adding zeros. Am I missing something?</p>

<p>What's the plan, longer hash digests with a different algorithm?</p>

<p>Is there research I can read on hashing algorithm development?</p>

<blockchain><hash><hashpower>
Sustainability of current hashing
DVCITIS
# Sustainability of current hashing

(Asked by: username_0 on 2017-08-22)

I'm a bitcoin/blockchain layman. I'm just getting my head around the hashing of blocks and the increase in difficulty (number of zeros) required as more miners get involved. I understand this is to maintain the 10 minute hash rate.

I understand the generation of more difficult hashes is attractive because it makes the chain more difficult to re-write and therefore safer.

As I read-on, the escalated use of computing power required is a point of conflict in my mind. We can't continue to increase the difficulty because the hashes are fixed length and need to be unique? Can't keep adding zeros. Am I missing something?

What's the plan, longer hash digests with a different algorithm?

Is there research I can read on hashing algorithm development?

**Tags:** blockchain, hash, hashpower


---

## 2 answers

### Answer by username_1 on 2017-08-23. Score: 1 | Accepted answer

Unique hashes are not something that we are likely to run out of in the near-to-medium term future, unless huge advancements in computation are made (in which case we'd have other issues to worry about).

When Bitcoin adds a zero to the front of the target, it is not a zero in hexadecimal (how hashes are usually visualized), it is adding it in binary. The difference is huge:

```
0FFF -> 00FF

```

means this in binary:

```
0000111111111111 -> 0000000011111111

```

What really happens is this:

```
0000111111111111 -> 0000011111111111

```

Or in hex:

```
0FFF -> 07FF

```

This means it will take 4 times as long to reach your point of concern as you thought. Also, let's look at the block hash you posted:

```
000000000000000000bbfa2afceac352a16db934867103aa85e6a83dc0fb6dfb

```

There are currently 18 leading hex zeros, which translates to 72 leading binary zeros. This leaves 184 bits (256 - 72) for a unique hash value, or 2^184 unique hashes. So right now, if the difficulty never increased and assuming a 10 minute block time, that still leaves us with 4.66\*10^50 years worth of hashes (which is roughly 5 time the age of the universe). When the difficulty doubles, we now only have 183 bits of hash space. This means it's about 4.66\*10^25 years, or about 2.5 times the age of the universe of hash space left. As you can see, it will take some time for the difficulty to reach a point where hash space is a reasonable issue.

However, the real problem is not with total hash space, but with probable collisions. Let's say that we have gotten to the point where there are only 56 bits available for hash space. First, this would take a truly massive hashing increase in the Bitcoin network to ever come about (difficulty would have to double 128 times), but we'll ignore that for this example. While 2^56 may seem like a small hash in modern cryptography, for this use case, it's not. We still have enough hashes left to cover the entire age of the universe, but again, we are concerned with someone finding a block with a hash that matches an existing block (or competing block).

So what would we do? I'm sure there'd be some debate if this ever came up, but I think the simple solution would be to reject that hash, just as if it were above the target difficulty. Miners would be forced to continue hashing until another block was found. After all, there is still plenty of room in the hash space, even when reduced to 56 bits (which is currently preposterous). Such a change to the protocol would only be a soft fork.

To summarize, even with our best estimates of future computing technology the remaining time for Bitcoin hashes is best measured in multiples of the age of the universe. Even if this became an issue, a simple soft fork could fix it. There's really not much to worry about here.

> **Comments:**
> **username_2**: Your arithmetic is off. 2^184 blocks is about 4.7e50 years, but 2^183 reduces the _significand_ to 2.4e50 years not the exponent to 4.7e25. And those are about 3.4e41 and 1.7e41 times the age of the universe (1.4e10 years) not 5 and 2.5.  
> **username_1**: Whoops.  Late night math.  

---

### Answer by username_3 on 2017-08-22. Score: 0

This is another one of the scaling issues. Bitcoin has been designed to last for a long time, but many issues, like the one concerning block size of as recent, are still going to take a while to come into play. As you can see here: <https://blockchain.info/block/000000000000000000bbfa2afceac352a16db934867103aa85e6a83dc0fb6dfb> the latest block has about 1/3 of the total potential target as zeroes. That means that the difficulty could double and we would still be fine.

> **Comments:**
> **username_4**: Doubling the difficulty would only result in *one* additional leading zero.  Exponential growth FTW!  Doubling the number of leading zeros would require *squaring* the difficulty.  
> **username_4**: ("Leading zero" here is in terms of bits, of course.)  

---

