<p>You can calculate <code>nBits</code> from the target value by first taking its base 256 logarithm and rounding that to the next higher number, which will give you the first Byte out of four, the exponent, of <code>nBits</code>. You now know how many trailing Bytes you can cut off the target (the exponent minus three) and you're left with the mantissa.</p>
<p>Putting that into a closed formula is a bit messy in my opinion. <a href="https://bitcoin.stackexchange.com/a/57186/136006">The existing formula</a> for calculating the target is not very nice in the first place, since <a href="https://bitcoin.stackexchange.com/a/96484/136006">it actually tries to express an algorithm</a>. But here you go (x being the target):</p>
<p><a href="https://i.sstatic.net/ADVhB.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/ADVhB.png" alt="nbits_formula" /></a></p>
<p>Example with the <a href="https://mempool.space/block/00000000000000000000f52d760c45d1907250deb55d3e4a3e30d798784673cf" rel="nofollow noreferrer">current</a> <code>nBits</code> value <code>0x17073039</code>:</p>
<pre><code>x = 0x730390000000000000000000000000000000000000000

(floor(log(x, 256)) + 1) * 0x1000000 = 0x17000000

x / 256 ^ (0x17 - 3) = 0x73039

nBits = 0x17000000 + 0x73039 = 0x17073039
</code></pre>
<p><strong>Please note</strong> that this formula does not work for all values. The mantissa, being a signed integer, should not exceed 2^23 - 1, which is why the exponent needs to be adjusted where this would be the case; e.g. for the maximum target <code>0x1d00ffff</code>, where the expected exponent of <code>0x1c</code> would lead to a mantissa of <code>0xffff00</code> and thus be interpreted negative.</p>

CC BY-SA 4.0
2023-02-20T15:01:53.383Z
The top bit of the mantissa is a sign bit, so the exponent has to be such that the rounded mantissa value is between 2^15 and 2^23-1 (because values above 2^23 are treated as negative). That's why the genesis nBits has an exponent that's seemingly off by one.
Pieter Wuille
CC BY-SA 4.0
2023-02-20T15:20:45.037Z
That makes sense, thanks! There probably isn't an obvious fix to the formula to catch this, is there? At least without complicating it too much.
sutterseba
CC BY-SA 4.0
2023-02-22T12:14:19.400Z
Thank you for that. I've tried putting in some example targets and sometimes it has worked, sometimes it hasn't.
CJ-Programmer
CC BY-SA 4.0
2023-02-22T21:00:42.770Z
You have to check the mantissa as Pieter described in his answer and adjust the exponent accordingly
sutterseba
CC BY-SA 4.0
2023-02-20T13:29:40.993Z
2023-02-20T15:34:50.763Z
2023-02-20T15:34:50.763Z
sutterseba
<p>I believe the algorithm is this:</p>
<ul>
<li>Let <em>b</em> be the number of bits in the target: <em>b = ⌈ log<sub>2</sub>(target+1)⌉</em>.</li>
<li>Let <em>e</em> be the exponent: <em>e = ⌊ (b/8)+1⌋</em>.</li>
<li>Let <em>m</em> be the mantissa: <em>m = ⌊ target/(256<sup>e-3</sup>)⌋</em></li>
<li>The <em>nBits</em> value encodes both <em>m</em> and <em>e</em>: <em>nBits = 2<sup>24</sup>e + m</em>.</li>
</ul>
<p>The computed mantissa should always be between <em>2<sup>15</sup></em> and <em>2<sup>23</sup>-1</em>. If it's larger, it would be interpreted as negative. If it's smaller, a lower exponent would provide more accuracy.</p>

CC BY-SA 4.0
2023-02-20T16:00:00.373Z
2023-02-20T16:00:00.373Z
Pieter Wuille
<p>I was wondering how the nBits are calculated from the target, I know how the the target is calculated from nBits, but how is the nBits calculated from the target?</p>

CC BY-SA 4.0
2023-02-19T17:13:46.023Z
Does one of these answer your questions: https://bitcoin.stackexchange.com/a/57186/5406, https://bitcoin.stackexchange.com/q/8806/5406, https://bitcoin.stackexchange.com/a/61951/5406?
Murch
CC BY-SA 4.0
2023-02-20T05:12:02.847Z
No, I was asking how the target is compressed into nbits, not the other way around.
CJ-Programmer
<difficulty><difficulty-retargetting><nbits>
How to calculate nBits from target?
CJ-Programmer
# How to calculate nBits from target?

(Asked by: username_0 on 2023-02-19)

I was wondering how the nBits are calculated from the target, I know how the the target is calculated from nBits, but how is the nBits calculated from the target?

**Tags:** difficulty, difficulty-retargetting, nbits

> **Comments:**
> **username_1**: Does one of these answer your questions: https://bitcoin.stackexchange.com/a/57186/5406, https://bitcoin.stackexchange.com/q/8806/5406, https://bitcoin.stackexchange.com/a/61951/5406?  
> **username_0**: No, I was asking how the target is compressed into nbits, not the other way around.  

---

## 2 answers

### Answer by username_2 on 2023-02-20. Score: 3

You can calculate `nBits` from the target value by first taking its base 256 logarithm and rounding that to the next higher number, which will give you the first Byte out of four, the exponent, of `nBits`. You now know how many trailing Bytes you can cut off the target (the exponent minus three) and you're left with the mantissa.

Putting that into a closed formula is a bit messy in my opinion. [The existing formula](https://bitcoin.stackexchange.com/a/57186/136006) for calculating the target is not very nice in the first place, since [it actually tries to express an algorithm](https://bitcoin.stackexchange.com/a/96484/136006). But here you go (x being the target):

[![nbits_formula](https://i.sstatic.net/ADVhB.png)](https://i.sstatic.net/ADVhB.png)

Example with the [current](https://mempool.space/block/00000000000000000000f52d760c45d1907250deb55d3e4a3e30d798784673cf) `nBits` value `0x17073039`:

```
x = 0x730390000000000000000000000000000000000000000

(floor(log(x, 256)) + 1) * 0x1000000 = 0x17000000

x / 256 ^ (0x17 - 3) = 0x73039

nBits = 0x17000000 + 0x73039 = 0x17073039

```

**Please note** that this formula does not work for all values. The mantissa, being a signed integer, should not exceed 2^23 - 1, which is why the exponent needs to be adjusted where this would be the case; e.g. for the maximum target `0x1d00ffff`, where the expected exponent of `0x1c` would lead to a mantissa of `0xffff00` and thus be interpreted negative.

> **Comments:**
> **username_3**: The top bit of the mantissa is a sign bit, so the exponent has to be such that the rounded mantissa value is between 2^15 and 2^23-1 (because values above 2^23 are treated as negative). That's why the genesis nBits has an exponent that's seemingly off by one.  
> **username_2**: That makes sense, thanks! There probably isn't an obvious fix to the formula to catch this, is there? At least without complicating it too much.  
> **username_0**: Thank you for that. I've tried putting in some example targets and sometimes it has worked, sometimes it hasn't.  
> **username_2**: You have to check the mantissa as username_3 described in his answer and adjust the exponent accordingly  

---

### Answer by username_3 on 2023-02-20. Score: 1

I believe the algorithm is this:

* Let *b* be the number of bits in the target: *b = ⌈ log2(target+1)⌉*.
* Let *e* be the exponent: *e = ⌊ (b/8)+1⌋*.
* Let *m* be the mantissa: *m = ⌊ target/(256e-3)⌋*
* The *nBits* value encodes both *m* and *e*: *nBits = 224e + m*.

The computed mantissa should always be between *215* and *223-1*. If it's larger, it would be interpreted as negative. If it's smaller, a lower exponent would provide more accuracy.


---

