Difficulty adjusts by very granular percentages to target for 10 minutes blocks. But adding another zero at the end of the chain of zeroes from the header hash requirement for a valid block would increase the difficulty exponential. So how does the Alogrithm target so precisely the right difficuly only through the use of "zeroes"?

  • The number of leading zeroes is never, at any point, ever, taken into account. – FrownyFrog Jan 27 '20 at 16:36

The difficulty is actually represented by the target threshold encoded in the nBits value in the block header. Where difficulty represents the human readable representation ("how often do we need to try to find a solution"), the target threshold defines the prefix a block must undershoot in order to be valid. This means that the 256-bit block hash interpreted as a number must be lower than the target threshold. Although, nBits is only a 4-byte value, it is a compressed representation of a 256-bit (32-byte) number. The first byte defines the exponent, the remaining three bytes give a 24-bit mantissa for the target.

While this leaves most of the 32 byte in the target threshold to be just composed of zeroes, the difficulty can adjust in a much more granular fashion than just adding leading zeros.

David Harding has elaborated the full details in How is the target section of a block header calculated?.

  • Ok I understand that nBits is actually the difficulty target, which is part of the header. I still don't understand what this has to do with the header hash leading zeroes: I assume a full node takes the header, double sha256s it and gets a header hash that it compares to the nBits to see if it's right. Correct? My question is how are those leading zeroes more granular for finding the right hash of the header? I think I'm missing something here.. – zndtoshi Jan 27 '20 at 7:37
  • 1
    Replacing a leading one with a leading zero doubles the difficulty, while lowering a 24-bit prefix by one count only increases the difficulty by a factor of 1.00000006. – Murch Jan 27 '20 at 19:12
  • 3
    @zndtoshi I think your confusion stems from the common (but wrong) saying that PoW is about "the number of leading zeroes". It is not, at all. The PoW rule is that the block hash, when interpreted as a number, must be below the target. nBits is a compact encoding of the target. – Pieter Wuille Jan 27 '20 at 19:21
  • Ok. So the target is given by nBits (which is very granular and that's perfect). But if this is true, why do you need zeroes in front of the header hash? Wouldn't you just take the nBits target and verify the header hash is correct? Or are the hash header leading zeros exponentially increasing difficulty? – zndtoshi Jan 29 '20 at 7:26
  • I'm not sure I understand the question. The target is so low that for a header hash to undershoot it, there are a number of leading zeroes. If you always represent your numbers with 9 digits, but have to pick one below two thousand, you'll always have five leading zeroes. But it's still a difference whether you have hit below 2000 or below 1999. – Murch Jan 29 '20 at 15:36

As a complement to @Murch's answer, I'd like to cite an example from Grokking Bitcoin:

The target is written in the block header as 4 bytes, ABCD; the 32-byte target is calculated as BCD × 2^(8*(A-3)). That’s BCD with A-3 zero bytes after it. It’s this awkward because we must be able to express a wide range of targets, 1–2^256, with only 32 bits. The target in Qi’s [a character in the book] block is written as 1c926eb9, meaning 926eb9 with 25 zero bytes after (1c–3 = 19, hex code for 25).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.