<h2>The comparison used is <em>numeric</em></h2>
<p>These are numbers not strings of characters. You can see this by looking at the code in the 2009 main.cpp of the Bitcoin reference implementation:</p>
<pre><code>        uint256 hashTarget = CBigNum().SetCompact(pblock-&gt;nBits).getuint256();
        uint256 hash;

[...]

           if (hash &lt;= hashTarget)
            {
                pblock-&gt;nNonce = tmp.block.nNonce;
                assert(hash == pblock-&gt;GetHash());

                    //// debug print
                    printf(&quot;BitcoinMiner:\n&quot;);
                    printf(&quot;proof-of-work found  \n  hash: %s  \ntarget: %s\n&quot;, hash.GetHex().c_str(), hashTarget.GetHex().c_str());
</code></pre>
<p>Note that <code>if (hash &lt;= hashTarget)</code> is a numeric comparison. Both <code>hash</code> and <code>hashTarget</code> are type <code>uint256</code> - an <strong>u</strong>nsigned <strong>int</strong>eger.</p>
<h2>Numbers expressed in hexadecimal are still numbers</h2>
<p>There is a choice of visual representations but the choice made does not change the underlying nature of the number or the way in which numbers are compared arithmetically or at a machine level in a computer.</p>
<p>Your example, 00005fad, is a number expressed in <a href="https://en.wikipedia.org/wiki/Hexadecimal" rel="nofollow noreferrer">hexadecimal (base 16)</a>, the same number can be written in normal decimal (base 10) as 24493. Anyone unfamiliar with non-decimal representations such as hexadecimal, octal and binary can check this using something like the Windows 10 calculator, in the menu choose &quot;Programmer Mode&quot; then click on &quot;hex&quot; and enter 5fad - it shows the <em>same value</em> in several <em>different representations</em>.</p>
<p>Maybe this will make it clearer?</p>
<div class="s-table-container"><table class="s-table">
<thead>
<tr>
<th>Item</th>
<th>Binary</th>
<th>Comments / Verdict</th>
</tr>
</thead>
<tbody>
<tr>
<td>Target</td>
<td>000000001100</td>
<td></td>
</tr>
<tr>
<td>Block A hash</td>
<td>000000001101</td>
<td>Larger ∴ Failure</td>
</tr>
<tr>
<td>Block B hash</td>
<td>000000001011</td>
<td>Smaller ∴ Success</td>
</tr>
</tbody>
</table></div>
<p>Even though the block hashes have the same number of leading zeroes, one is a failure and the other a success.</p>
<h2>Leading zeroes</h2>
<p>The notion that Bitcoin cares about the number of leading zeroes in, say, a hexadecimal representation, is a commonly repeated mistake (don't ask me how I know this).</p>
<p>If you insist on writing numbers with leading zeroes it is still obviously true that 000015 (fifteen) with four leading zeroes is smaller than 000150 (a hundred and fifty) with only three leading zeroes. It would however be a mistake to think that smaller numbers always have more leading zeroes. Both you and Bitcoin know that 000017 (seventeen) is smaller than 000019 (nineteen) even though both have the same number of leading zeroes.</p>
<p>It is true that <code>a</code> is less than <code>b</code> in exactly the same way that <code>7</code> is less than <code>8</code> or that <code>2</code> is less than <code>3</code>. But it is probably a mistake to start comparing individual digits in a particular visual representation. The hash and hash targets are ordinary numbers (though large) that are compared in an ordinary way.</p>
<p>So where does this talk of leading zeroes come from? According to a prominent contributor:</p>
<blockquote>
<p>hashcash, the original PoW system, had a &quot;difficulty&quot; that was actually the number of zero bits up front in the hash. Bitcoin's proof of work is based on it, but generalized to a big integer comparison.</p>
</blockquote>
<p>See</p>
<ul>
<li><a href="https://en.bitcoin.it/wiki/Difficulty" rel="nofollow noreferrer">Difficulty</a> - Bitcoin Wiki</li>
<li><a href="https://en.bitcoin.it/wiki/Target" rel="nofollow noreferrer">Target</a> - Bitcoin Wiki</li>
<li><a href="https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch08.html#difficulty_bits" rel="nofollow noreferrer">Difficulty Representation</a> - O'Reilly, Mastering Bitcoin</li>
</ul>
<h2>Examples</h2>
<p>Lets look at some recent blocks (most recent at top, reverse chronological order)</p>
<div class="s-table-container"><table class="s-table">
<thead>
<tr>
<th>Block</th>
<th>Mined on</th>
<th>Difficulty</th>
<th>Hash</th>
<th>bits</th>
</tr>
</thead>
<tbody>
<tr>
<td>669315</td>
<td>2021-02-06 02:48</td>
<td>21434395961349</td>
<td>0000000000000000000bbefe7b336aab05ef49c9c6ccd70a895b3cc4669ac924</td>
<td></td>
</tr>
<tr>
<td>669314</td>
<td>2021-02-06 02:36</td>
<td>21434395961349</td>
<td>0000000000000000000ae88c36b136ef612f0a0622bdf614854a7810e3f781cf</td>
<td></td>
</tr>
<tr>
<td>669313</td>
<td>2021-02-06 02:34</td>
<td>21434395961349</td>
<td>0000000000000000000acd9e8fd6512d3832e98a8c87d049afbd805abd44d8c2</td>
<td></td>
</tr>
<tr>
<td>669312</td>
<td>2021-02-06 02:25</td>
<td>21434395961349</td>
<td>0000000000000000000beb9d24f999168c79fa58394868f9fcc5367c28f137dc</td>
<td></td>
</tr>
<tr>
<td>669311</td>
<td>2021-02-06 02:22</td>
<td>20823531150112</td>
<td>00000000000000000004f29390852281bae27d3662f648020bb47cced0d883b8</td>
<td></td>
</tr>
<tr>
<td>669310</td>
<td>2021-02-06 02:18</td>
<td>20823531150112</td>
<td>00000000000000000000cd7ef96b5f6687c8b49df40c2dec2128adc39827707e</td>
<td></td>
</tr>
<tr>
<td>669309</td>
<td>2021-02-06 01:54</td>
<td>20823531150112</td>
<td>00000000000000000009d6c5902b0b8598f2ebd0fe076581b039fe789b4daca6</td>
<td></td>
</tr>
<tr>
<td>669308</td>
<td>2021-02-06 01:37</td>
<td>20823531150112</td>
<td>0000000000000000000be631fd1026989a86cf9dae421e7eca0f80d77b6bba5e</td>
<td></td>
</tr>
</tbody>
</table></div>
<p>Notice that the difficulty <em>increased</em> after block 669311 but the number of leading zeroes in the hashes has not <em>increased</em> (not in hexadecimal and not in binary).</p>
<h2>Implementations</h2>
<p>If you want to see exact details you could look at early versions of the Bitcoin reference implementation in C++. However I would suggest instead looking at the current BTCD implementation in go-lang because that is well commented and, in my opinion, an easier language to read.</p>
<p>e.g. <a href="https://github.com/btcsuite/btcd/blob/master/chaincfg/params.go" rel="nofollow noreferrer">https://github.com/btcsuite/btcd/blob/master/chaincfg/params.go</a></p>
<pre class="lang-go prettyprint-override"><code>    // TargetTimespan is the desired amount of time that should elapse
    // before the block difficulty requirement is examined to determine how
    // it should be changed in order to maintain the desired block
    // generation rate.
    TargetTimespan time.Duration

    // TargetTimePerBlock is the desired amount of time to generate each
    // block.
    TargetTimePerBlock time.Duration
</code></pre>
<p>and <a href="https://github.com/btcsuite/btcd/blob/master/blockchain/difficulty.go" rel="nofollow noreferrer">https://github.com/btcsuite/btcd/blob/master/blockchain/difficulty.go</a></p>
<pre class="lang-go prettyprint-override"><code>    // Calculate new target difficulty as:
    //  currentDifficulty * (adjustedTimespan / targetTimespan)
    // The result uses integer division which means it will be slightly
    // rounded down.  Bitcoind also uses integer division to calculate this
    // result.
    oldTarget := CompactToBig(lastNode.bits)
    newTarget := new(big.Int).Mul(oldTarget, big.NewInt(adjustedTimespan))
    targetTimeSpan := int64(b.chainParams.TargetTimespan / time.Second)
    newTarget.Div(newTarget, big.NewInt(targetTimeSpan))
</code></pre>
<h2>Calculating the hash target</h2>
<p>See</p>
<ul>
<li><a href="https://bitcoin.stackexchange.com/q/44579/13866">How is a block header hash compared to the target (bits)?</a></li>
<li><a href="https://bitcoin.stackexchange.com/q/85896/13866">Mining Difficulty and Leading Zeros</a></li>
<li><a href="https://bitcoin.stackexchange.com/q/855/13866">What keeps the average block time at 10 minutes?</a></li>
<li><a href="https://bitcoin.stackexchange.com/q/2924/13866">How to calculate new &quot;bits&quot; value?</a></li>
<li><a href="https://bitcoin.stackexchange.com/q/56855/13866">Chain with most proof of work - hash target or block header hash?</a></li>
</ul>
<hr />

CC BY-SA 4.0
2021-02-10T01:36:16.277Z
So if more 0's aren't added every time the difficulty increases, what actually changes in regards to its difficult? It started at difficulty 1 with the genesis block and is now at over 21 trillion difficulty, yet has only went from 8 leading 0's to 19 leading 0's. What would have changed when the difficulty went from 1, to 1.18 for example?
L M 
CC BY-SA 4.0
2021-02-10T11:43:12.310Z
@LM: See answers to questions in additional links appended to answer.
RedGrittyBrick
CC BY-SA 4.0
2021-02-09T22:28:32.897Z
2024-02-19T14:57:42.683Z
2024-02-19T14:57:42.683Z
RedGrittyBrick
<p>I did a terrible job of explaining it in the title so I'll explain here. Say the target hash to solve for a block is 00004aef... etc. does that mean that you can't solve the block if you get 00005fad (since 5 is more than 4 so technically you didn't get lower or equal to the hash)? Or is the only thing that matters in relation to the less or equal when it comes to solving the hash the amount of 0's you get?</p>
<p>Also, what if you get a letter after the 0's, for example 0000ba2... does that mean you need to get 0000a... or does it not matter?</p>
<p>Thanks.</p>

<blockchain><block><hash>
How does solving a block work in relation to the first letter/number after the 0's?
L M 
# How does solving a block work in relation to the first letter/number after the 0's?

(Asked by: username_0 on 2021-02-09)

I did a terrible job of explaining it in the title so I'll explain here. Say the target hash to solve for a block is 00004aef... etc. does that mean that you can't solve the block if you get 00005fad (since 5 is more than 4 so technically you didn't get lower or equal to the hash)? Or is the only thing that matters in relation to the less or equal when it comes to solving the hash the amount of 0's you get?

Also, what if you get a letter after the 0's, for example 0000ba2... does that mean you need to get 0000a... or does it not matter?

Thanks.

**Tags:** blockchain, block, hash


---

## 1 answers

### Answer by username_1 on 2021-02-09. Score: 10

## The comparison used is *numeric*

These are numbers not strings of characters. You can see this by looking at the code in the 2009 main.cpp of the Bitcoin reference implementation:

```
        uint256 hashTarget = CBigNum().SetCompact(pblock->nBits).getuint256();
        uint256 hash;

[...]

           if (hash <= hashTarget)
            {
                pblock->nNonce = tmp.block.nNonce;
                assert(hash == pblock->GetHash());

                    //// debug print
                    printf("BitcoinMiner:\n");
                    printf("proof-of-work found  \n  hash: %s  \ntarget: %s\n", hash.GetHex().c_str(), hashTarget.GetHex().c_str());

```

Note that `if (hash <= hashTarget)` is a numeric comparison. Both `hash` and `hashTarget` are type `uint256` - an **u**nsigned **int**eger.

## Numbers expressed in hexadecimal are still numbers

There is a choice of visual representations but the choice made does not change the underlying nature of the number or the way in which numbers are compared arithmetically or at a machine level in a computer.

Your example, 00005fad, is a number expressed in [hexadecimal (base 16)](https://en.wikipedia.org/wiki/Hexadecimal), the same number can be written in normal decimal (base 10) as 24493. Anyone unfamiliar with non-decimal representations such as hexadecimal, octal and binary can check this using something like the Windows 10 calculator, in the menu choose "Programmer Mode" then click on "hex" and enter 5fad - it shows the *same value* in several *different representations*.

Maybe this will make it clearer?

| Item | Binary | Comments / Verdict |
| --- | --- | --- |
| Target | 000000001100 |  |
| Block A hash | 000000001101 | Larger ∴ Failure |
| Block B hash | 000000001011 | Smaller ∴ Success |

Even though the block hashes have the same number of leading zeroes, one is a failure and the other a success.

## Leading zeroes

The notion that Bitcoin cares about the number of leading zeroes in, say, a hexadecimal representation, is a commonly repeated mistake (don't ask me how I know this).

If you insist on writing numbers with leading zeroes it is still obviously true that 000015 (fifteen) with four leading zeroes is smaller than 000150 (a hundred and fifty) with only three leading zeroes. It would however be a mistake to think that smaller numbers always have more leading zeroes. Both you and Bitcoin know that 000017 (seventeen) is smaller than 000019 (nineteen) even though both have the same number of leading zeroes.

It is true that `a` is less than `b` in exactly the same way that `7` is less than `8` or that `2` is less than `3`. But it is probably a mistake to start comparing individual digits in a particular visual representation. The hash and hash targets are ordinary numbers (though large) that are compared in an ordinary way.

So where does this talk of leading zeroes come from? According to a prominent contributor:

> hashcash, the original PoW system, had a "difficulty" that was actually the number of zero bits up front in the hash. Bitcoin's proof of work is based on it, but generalized to a big integer comparison.

See

* [Difficulty](https://en.bitcoin.it/wiki/Difficulty) - Bitcoin Wiki
* [Target](https://en.bitcoin.it/wiki/Target) - Bitcoin Wiki
* [Difficulty Representation](https://www.oreilly.com/library/view/mastering-bitcoin/9781491902639/ch08.html#difficulty_bits) - O'Reilly, Mastering Bitcoin

## Examples

Lets look at some recent blocks (most recent at top, reverse chronological order)

| Block | Mined on | Difficulty | Hash | bits |
| --- | --- | --- | --- | --- |
| 669315 | 2021-02-06 02:48 | 21434395961349 | 0000000000000000000bbefe7b336aab05ef49c9c6ccd70a895b3cc4669ac924 |  |
| 669314 | 2021-02-06 02:36 | 21434395961349 | 0000000000000000000ae88c36b136ef612f0a0622bdf614854a7810e3f781cf |  |
| 669313 | 2021-02-06 02:34 | 21434395961349 | 0000000000000000000acd9e8fd6512d3832e98a8c87d049afbd805abd44d8c2 |  |
| 669312 | 2021-02-06 02:25 | 21434395961349 | 0000000000000000000beb9d24f999168c79fa58394868f9fcc5367c28f137dc |  |
| 669311 | 2021-02-06 02:22 | 20823531150112 | 00000000000000000004f29390852281bae27d3662f648020bb47cced0d883b8 |  |
| 669310 | 2021-02-06 02:18 | 20823531150112 | 00000000000000000000cd7ef96b5f6687c8b49df40c2dec2128adc39827707e |  |
| 669309 | 2021-02-06 01:54 | 20823531150112 | 00000000000000000009d6c5902b0b8598f2ebd0fe076581b039fe789b4daca6 |  |
| 669308 | 2021-02-06 01:37 | 20823531150112 | 0000000000000000000be631fd1026989a86cf9dae421e7eca0f80d77b6bba5e |  |

Notice that the difficulty *increased* after block 669311 but the number of leading zeroes in the hashes has not *increased* (not in hexadecimal and not in binary).

## Implementations

If you want to see exact details you could look at early versions of the Bitcoin reference implementation in C++. However I would suggest instead looking at the current BTCD implementation in go-lang because that is well commented and, in my opinion, an easier language to read.

e.g. <https://github.com/btcsuite/btcd/blob/master/chaincfg/params.go>

```go
    // TargetTimespan is the desired amount of time that should elapse
    // before the block difficulty requirement is examined to determine how
    // it should be changed in order to maintain the desired block
    // generation rate.
    TargetTimespan time.Duration

    // TargetTimePerBlock is the desired amount of time to generate each
    // block.
    TargetTimePerBlock time.Duration

```

and <https://github.com/btcsuite/btcd/blob/master/blockchain/difficulty.go>

```go
    // Calculate new target difficulty as:
    //  currentDifficulty * (adjustedTimespan / targetTimespan)
    // The result uses integer division which means it will be slightly
    // rounded down.  Bitcoind also uses integer division to calculate this
    // result.
    oldTarget := CompactToBig(lastNode.bits)
    newTarget := new(big.Int).Mul(oldTarget, big.NewInt(adjustedTimespan))
    targetTimeSpan := int64(b.chainParams.TargetTimespan / time.Second)
    newTarget.Div(newTarget, big.NewInt(targetTimeSpan))

```

## Calculating the hash target

See

* [How is a block header hash compared to the target (bits)?](https://bitcoin.stackexchange.com/q/44579/13866)
* [Mining Difficulty and Leading Zeros](https://bitcoin.stackexchange.com/q/85896/13866)
* [What keeps the average block time at 10 minutes?](https://bitcoin.stackexchange.com/q/855/13866)
* [How to calculate new "bits" value?](https://bitcoin.stackexchange.com/q/2924/13866)
* [Chain with most proof of work - hash target or block header hash?](https://bitcoin.stackexchange.com/q/56855/13866)

---

> **Comments:**
> **username_0**: So if more 0's aren't added every time the difficulty increases, what actually changes in regards to its difficult? It started at difficulty 1 with the genesis block and is now at over 21 trillion difficulty, yet has only went from 8 leading 0's to 19 leading 0's. What would have changed when the difficulty went from 1, to 1.18 for example?  
> **username_1**: @LM: See answers to questions in additional links appended to answer.  

---

