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.– FrownyFrogJan 27, 2020 at 16:36
Add a comment
|
2 Answers
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..– zndtoshiJan 27, 2020 at 7:37
-
1Replacing 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, 2020 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.
nBitsis a compact encoding of the target. Jan 27, 2020 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?– zndtoshiJan 29, 2020 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, 2020 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 asBCD× 2^(8*(A-3)). That’sBCDwithA-3zero 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 as1c926eb9, meaning926eb9with 25 zero bytes after (1c–3 = 19, hex code for 25).
