Difficulty target representation in bitcoin wiki

To explain that, let's look at the code that unpacks the compact format into a 256 bit int.

arith_uint256& arith_uint256::SetCompact(uint32_t nCompact, bool* pfNegative, bool* pfOverflow)
{
    int nSize = nCompact >> 24;
    uint32_t nWord = nCompact & 0x007fffff;
    if (nSize <= 3) {
        nWord >>= 8 * (3 - nSize);
        *this = nWord;
    } else {
        *this = nWord;
        *this <<= 8 * (nSize - 3);
    }
    if (pfNegative)
        *pfNegative = nWord != 0 && (nCompact & 0x00800000) != 0;
    if (pfOverflow)
        *pfOverflow = nWord != 0 && ((nSize > 34) ||
                                     (nWord > 0xff && nSize > 33) ||
                                     (nWord > 0xffff && nSize > 32));
    return *this;
}

The first 8 bits here are the exponent. The next bit is a sign bit, with 1 being negative. The next 23 bits are the mantissa.

So, 0x00800000 is equal to 0x00000000.

Nick ODell

Posted 2016-09-21T23:51:43.147

Reputation: 26 536

Yes 0x00800000 is equal to 0x00000000, but I think the wiki is referring to the part after the Bits removed the first byte, and it says 0x008000 instead of 0x800000 is the smallest positive valid value. – hello.wjx – 2016-09-22T12:03:25.787

0x008000 is also equal to zero, because it is right shifted three times. For that matter, 0x01008000 would equal zero too. – Nick ODell – 2016-09-22T17:57:57.517

Then 0x007000, 0x006000 ... all equal to zero, and all are smaller than 0x008000 – hello.wjx – 2016-09-23T15:08:57.550

Difficulty target representation in bitcoin wiki

Answers