<p>TL;DR The formula comes from turning an algorithm into a mathematical formula. <code>nBits</code> encodes the target with the first bytes as the size of the final target, followed by the 3 most significant bytes of that target. This can be converted into that crazy formula.</p>
<hr />
<p>The formula is the mathematical representation of the actual algorithm that was used for the compression. To understand why the formula is as it is, we need to first take a look at the original code that encodes a 256 bit target as a 4 byte <code>nBits</code>. This is from 0.1.5 in the bitcoin/bitcoin source tree, but is the same in 0.1.0:</p>
<pre><code>unsigned int GetCompact() const
{
    unsigned int nSize = BN_bn2mpi(this, NULL);
    std::vector&lt;unsigned char&gt; vch(nSize);
    nSize -= 4;
    BN_bn2mpi(this, &amp;vch[0]);
    unsigned int nCompact = nSize &lt;&lt; 24;
    if (nSize &gt;= 1) nCompact |= (vch[4] &lt;&lt; 16);
    if (nSize &gt;= 2) nCompact |= (vch[5] &lt;&lt; 8);
    if (nSize &gt;= 3) nCompact |= (vch[6] &lt;&lt; 0);
    return nCompact;
}
</code></pre>
<p>Now the first thing to look at is this <code>BN_bn2pi</code> function. Early versions of Bitcoin used OpenSSL's Bignum module for these calculations. So we need to look at the <a href="https://www.openssl.org/docs/man1.1.0/man3/BN_bn2mpi.html" rel="nofollow noreferrer">OpenSSL's docs</a> for this function. From the docs, we read:</p>
<blockquote>
<p>BN_bn2mpi() and BN_mpi2bn() convert BIGNUMs from and to a format that consists of the number's length in bytes represented as a 4-byte big-endian number, and the number itself in big-endian format, where the most significant bit signals a negative number (the representation of numbers with the MSB set is prefixed with null byte).</p>
<p>BN_bn2mpi() stores the representation of a at to, where to must be large enough to hold the result. The size can be determined by calling BN_bn2mpi(a, NULL).</p>
</blockquote>
<p>This means that <code>BN_bn2mpi</code> will place into a buffer the Bignum in the format</p>
<pre><code>&lt;4 byte size&gt; | &lt;variable length number&gt;
</code></pre>
<p>Calling <code>BN_bn2mpi</code> with <code>NULL</code> as the buffer will return the number of bytes that that buffer will need to be. This is useful to know how many bytes to allocate for the buffer.</p>
<p>So let's go back to the <code>GetCompact</code> function. We see <code>BN_bn2mpi(this, NULL);</code>. This means that <code>nSize</code> is now the size that is needed to encode the Bignum. Because this encoding also includes the size of the number itself, we later see <code>nSize -= 4;</code> which sets <code>nSize</code> to be the size of the actual number itself.</p>
<p><code>BN_bn2mpi(this, &amp;vch[0]);</code> now encodes the Bignum into <code>vch</code> which was set to the size specified by the first <code>BN_bn2mpi</code> call. It is important to remember that the first 4 bytes are the length of the number, so the actual number itself begins at index 4 (<code>vch[4]</code>).</p>
<p>Finally, the compact number itself is constructed. <code>nSize &lt;&lt; 24</code> is just to set the rightmost byte of <code>nSize</code> to be the leftmost byte of <code>nCompact</code>. Then the function is setting the rest of the compact number. Each byte is just being shifted to it's final position in the 4 byte int and OR'd with <code>nCompact</code> to set it. The <code>if</code> statements are for the case that the target is so low that it is encoded in fewer bytes than the compact size itself.</p>
<p>Looking at this function, we learn that the compact encoding is really just one byte indicating the length of the target, and 3 bytes for the 3 most significant bytes in that target. If you looked at the <code>SetCompact</code> function which takes a compact <code>nBits</code> and converts it into a Bignum, you would see that it is just the inverse of <code>GetCompact</code>, so I won't explain it.</p>
<p>Now the question is, how do we get to the crazy looking formula? How did we go from this code that strictly is just byte manipulation to a mathematical formula?</p>
<p>In your example, based on the above algorithm, we know that the final number is going to be <code>0x00ffff0000000000000000000000000000000000000000000000000000</code>. We want the first 3 bytes, which we got from the <code>nBits</code>, to be by themselves, so let's divide this number by that:</p>
<pre><code>0x00ffff0000000000000000000000000000000000000000000000000000 / 0x00ffff = 0x010000000000000000000000000000000000000000000000000000
</code></pre>
<p><code>0x010000000000000000000000000000000000000000000000000000</code> is a 1 followed by 26 bytes of 0, so it's <code>256**26</code> (256 since there are 256 possible values in a byte). Now how do we get this number from the <code>nBits</code>? We can take the first byte, representing the length of the full thing, and subtract 3 from it.</p>
<pre><code>256**(0x1d-3)
</code></pre>
<p>We can expand this further because <code>256 = 2**8</code> and some people like things represented as a power of 2. So this can become <code>2**(8*0x1d-3)</code>. Thus</p>
<pre><code>0x010000000000000000000000000000000000000000000000000000 = 2**(8*0x1d-3)
</code></pre>
<p>Therefore:</p>
<pre><code>0x00ffff0000000000000000000000000000000000000000000000000000 = 0x010000000000000000000000000000000000000000000000000000 * 0x00ffff = 2**(8*0x1d-3) * 0x00ffff
</code></pre>
<p>The final result is <code>2**(8*0x1d-3) * 0x00ffff</code>. And, of course, this generalizes.</p>
<hr />
<p>A semi-related question then is why does the Bignum encoding have a leading <code>0x00</code> byte? An encoding that represents this maximum target with a little bit more precision would have been <code>0x1cffffff</code> so we could avoid this extraneous <code>0x00</code> byte.</p>
<p>That leading <code>0x00</code> byte is all because the Bignum is signed and the target is a positive integer. The most significant bit indicates whether it is negative. If the target had been encoded <code>0xffff....</code>, then decoding this would mean that the target is negative, which is wrong. So the encoding puts a leading <code>0x00</code> so that the number remains positive.</p>

CC BY-SA 4.0
2024-01-30T15:46:03.783Z
I probably miss something, but `0x010000000000000000000000000000000000000000000000000000` is 27 byte long, not 26?
LeaBit
CC BY-SA 4.0
2024-01-30T16:57:39.100Z
@LeaBit Indeed, good catch. I've updated the answer.
Ava Chow
CC BY-SA 4.0
2020-06-14T23:07:15.863Z
2024-01-30T16:57:20.457Z
2024-01-30T16:57:20.457Z
Ava Chow
<p>I'm only answering this question because I saw Murch had tweeted Andrew Chow's answer. I researched this a bit while writing my book, Programming Bitcoin, but it didn't make it into the book, so I thought this would be a good place to put it.</p>

<p>You can think of "bits" as a lossy compressed large base-256 number (that is, each 8-bit byte is a digit). The numbers we're talking about here are 32 digits as base-256 for a SHA256 (or HASH256) hash.</p>

<p>The "exponent" here is really just the length, in bytes, of the base-256 number we're compressing. The coefficient is the top three significant digits. As we want to be able to encode negative numbers, the top bit in particular is reserved to indicate a negative number. Thus, we put the 0-byte in front if the top bit is set (this is done, for example in the DER encoding).</p>

<p>Really, it's:</p>

<p>nBits = (top 3 digits) * 256^(digit length of base 256 number)</p>

<p>When you look at it that way, it's a little more logical.</p>

CC BY-SA 4.0
2020-06-14T23:50:56.907Z
2020-06-14T23:50:56.907Z
Jimmy Song
<p>I don't know which paper you got this from, but I will attempt to answer your questions.</p>

<ol>
<li>The author simply decided to write 256 as a power of 2. This is a matter of preference. I haven't looked at the code itself, but either way, there should be very little overhead doing it this way. Perhaps, since this formula is in hexadecimal, it shouldn't have base-10 coefficients written in them as a matter of convention.</li>
<li>The number 3 puts an upper bound on the hex digits h0 and h1. If it wasn't here, and h0 and h1 = 0xF (h0||h1 = 0xFF), the difficulty could reach such a high level that the developers never intended, and a block would never be found because it is nearly impossible to mine.</li>
<li>256 is the total number of combinations of a byte. Bitcoin doesn't work with values smaller than a byte, and it wouldn't gain any benefit from working at bit level, either. Making the difficulty target some power of 2 doesn't make a big difference since the network difficulty takes 2016 blocks to change, anyways. Working with bytes is easier in the code.</li>
</ol>

CC BY-SA 4.0
2020-06-14T20:54:48.677Z
2020-06-14T21:09:16.077Z
2020-06-14T21:09:16.077Z
Expectator
<p>Why this ugly looking formula to calculate 'target' from 'nBits' in block header:  target = coefficient * 256**(exponent-3).</p>

<p><a href="https://i.sstatic.net/uzJxx.jpg" rel="nofollow noreferrer"><img src="https://i.sstatic.net/uzJxx.jpg" alt="enter image description here"></a></p>

<p>Why not? :  target = coefficient * 256**(exponent). What is the need of subtracting 3. All we need is to be able to generate 256 bit long number and enough precision (which we already have with 3 bytes dedicated for coefficient)</p>

<p>Even better, why not? : target = coefficient * 2**(exponent)</p>

<difficulty><nbits>
Why this ugly looking formula to calculate 'target' from 'nBits' in block header: target = coefficient * 256**(exponent-3)
Ravi Patel
# Why this ugly looking formula to calculate 'target' from 'nBits' in block header: target = coefficient * 256**(exponent-3)

(Asked by: username_0 on 2020-06-04)

Why this ugly looking formula to calculate 'target' from 'nBits' in block header: target = coefficient \* 256\*\*(exponent-3).

[![enter image description here](https://i.sstatic.net/uzJxx.jpg)](https://i.sstatic.net/uzJxx.jpg)

Why not? : target = coefficient \* 256\*\*(exponent). What is the need of subtracting 3. All we need is to be able to generate 256 bit long number and enough precision (which we already have with 3 bytes dedicated for coefficient)

Even better, why not? : target = coefficient \* 2\*\*(exponent)

**Tags:** difficulty, nbits


---

## 3 answers

### Answer by username_1 on 2020-06-14. Score: 10

TL;DR The formula comes from turning an algorithm into a mathematical formula. `nBits` encodes the target with the first bytes as the size of the final target, followed by the 3 most significant bytes of that target. This can be converted into that crazy formula.

---

The formula is the mathematical representation of the actual algorithm that was used for the compression. To understand why the formula is as it is, we need to first take a look at the original code that encodes a 256 bit target as a 4 byte `nBits`. This is from 0.1.5 in the bitcoin/bitcoin source tree, but is the same in 0.1.0:

```
unsigned int GetCompact() const
{
    unsigned int nSize = BN_bn2mpi(this, NULL);
    std::vector<unsigned char> vch(nSize);
    nSize -= 4;
    BN_bn2mpi(this, &vch[0]);
    unsigned int nCompact = nSize << 24;
    if (nSize >= 1) nCompact |= (vch[4] << 16);
    if (nSize >= 2) nCompact |= (vch[5] << 8);
    if (nSize >= 3) nCompact |= (vch[6] << 0);
    return nCompact;
}

```

Now the first thing to look at is this `BN_bn2pi` function. Early versions of Bitcoin used OpenSSL's Bignum module for these calculations. So we need to look at the [OpenSSL's docs](https://www.openssl.org/docs/man1.1.0/man3/BN_bn2mpi.html) for this function. From the docs, we read:

> BN\_bn2mpi() and BN\_mpi2bn() convert BIGNUMs from and to a format that consists of the number's length in bytes represented as a 4-byte big-endian number, and the number itself in big-endian format, where the most significant bit signals a negative number (the representation of numbers with the MSB set is prefixed with null byte).
>
> BN\_bn2mpi() stores the representation of a at to, where to must be large enough to hold the result. The size can be determined by calling BN\_bn2mpi(a, NULL).

This means that `BN_bn2mpi` will place into a buffer the Bignum in the format

```
<4 byte size> | <variable length number>

```

Calling `BN_bn2mpi` with `NULL` as the buffer will return the number of bytes that that buffer will need to be. This is useful to know how many bytes to allocate for the buffer.

So let's go back to the `GetCompact` function. We see `BN_bn2mpi(this, NULL);`. This means that `nSize` is now the size that is needed to encode the Bignum. Because this encoding also includes the size of the number itself, we later see `nSize -= 4;` which sets `nSize` to be the size of the actual number itself.

`BN_bn2mpi(this, &vch[0]);` now encodes the Bignum into `vch` which was set to the size specified by the first `BN_bn2mpi` call. It is important to remember that the first 4 bytes are the length of the number, so the actual number itself begins at index 4 (`vch[4]`).

Finally, the compact number itself is constructed. `nSize << 24` is just to set the rightmost byte of `nSize` to be the leftmost byte of `nCompact`. Then the function is setting the rest of the compact number. Each byte is just being shifted to it's final position in the 4 byte int and OR'd with `nCompact` to set it. The `if` statements are for the case that the target is so low that it is encoded in fewer bytes than the compact size itself.

Looking at this function, we learn that the compact encoding is really just one byte indicating the length of the target, and 3 bytes for the 3 most significant bytes in that target. If you looked at the `SetCompact` function which takes a compact `nBits` and converts it into a Bignum, you would see that it is just the inverse of `GetCompact`, so I won't explain it.

Now the question is, how do we get to the crazy looking formula? How did we go from this code that strictly is just byte manipulation to a mathematical formula?

In your example, based on the above algorithm, we know that the final number is going to be `0x00ffff0000000000000000000000000000000000000000000000000000`. We want the first 3 bytes, which we got from the `nBits`, to be by themselves, so let's divide this number by that:

```
0x00ffff0000000000000000000000000000000000000000000000000000 / 0x00ffff = 0x010000000000000000000000000000000000000000000000000000

```

`0x010000000000000000000000000000000000000000000000000000` is a 1 followed by 26 bytes of 0, so it's `256**26` (256 since there are 256 possible values in a byte). Now how do we get this number from the `nBits`? We can take the first byte, representing the length of the full thing, and subtract 3 from it.

```
256**(0x1d-3)

```

We can expand this further because `256 = 2**8` and some people like things represented as a power of 2. So this can become `2**(8*0x1d-3)`. Thus

```
0x010000000000000000000000000000000000000000000000000000 = 2**(8*0x1d-3)

```

Therefore:

```
0x00ffff0000000000000000000000000000000000000000000000000000 = 0x010000000000000000000000000000000000000000000000000000 * 0x00ffff = 2**(8*0x1d-3) * 0x00ffff

```

The final result is `2**(8*0x1d-3) * 0x00ffff`. And, of course, this generalizes.

---

A semi-related question then is why does the Bignum encoding have a leading `0x00` byte? An encoding that represents this maximum target with a little bit more precision would have been `0x1cffffff` so we could avoid this extraneous `0x00` byte.

That leading `0x00` byte is all because the Bignum is signed and the target is a positive integer. The most significant bit indicates whether it is negative. If the target had been encoded `0xffff....`, then decoding this would mean that the target is negative, which is wrong. So the encoding puts a leading `0x00` so that the number remains positive.

> **Comments:**
> **username_2**: I probably miss something, but `0x010000000000000000000000000000000000000000000000000000` is 27 byte long, not 26?  
> **username_1**: @username_2 Indeed, good catch. I've updated the answer.  

---

### Answer by username_3 on 2020-06-14. Score: 3

I'm only answering this question because I saw Murch had tweeted Andrew username_1's answer. I researched this a bit while writing my book, Programming Bitcoin, but it didn't make it into the book, so I thought this would be a good place to put it.

You can think of "bits" as a lossy compressed large base-256 number (that is, each 8-bit byte is a digit). The numbers we're talking about here are 32 digits as base-256 for a SHA256 (or HASH256) hash.

The "exponent" here is really just the length, in bytes, of the base-256 number we're compressing. The coefficient is the top three significant digits. As we want to be able to encode negative numbers, the top bit in particular is reserved to indicate a negative number. Thus, we put the 0-byte in front if the top bit is set (this is done, for example in the DER encoding).

Really, it's:

nBits = (top 3 digits) \* 256^(digit length of base 256 number)

When you look at it that way, it's a little more logical.


---

### Answer by username_4 on 2020-06-14. Score: 0

I don't know which paper you got this from, but I will attempt to answer your questions.

1. The author simply decided to write 256 as a power of 2. This is a matter of preference. I haven't looked at the code itself, but either way, there should be very little overhead doing it this way. Perhaps, since this formula is in hexadecimal, it shouldn't have base-10 coefficients written in them as a matter of convention.
2. The number 3 puts an upper bound on the hex digits h0 and h1. If it wasn't here, and h0 and h1 = 0xF (h0||h1 = 0xFF), the difficulty could reach such a high level that the developers never intended, and a block would never be found because it is nearly impossible to mine.
3. 256 is the total number of combinations of a byte. Bitcoin doesn't work with values smaller than a byte, and it wouldn't gain any benefit from working at bit level, either. Making the difficulty target some power of 2 doesn't make a big difference since the network difficulty takes 2016 blocks to change, anyways. Working with bytes is easier in the code.


---

