TIL. I wonder why that myth is so commonly perpetuated.
> The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits.
Performance as in "it takes less time to verify the PoW," or something else? Because the "leading zeros" and "less than target" approaches would both take a negligible amount of time.
[0] https://github.com/bitcoin/bitcoin/blob/e071a3f6c06f41068ad1...
btw, the whitepaper probably used "number of leading zeros" because that's what Hashcash does.
I don't know who told you that, but they were weirdly confused.
It not unlikely the case that sometime early in development (long before publication) that it was bits-based, not only is this how the standard hashcash code works-- but the Bitcoin code calls the relevant field that encods the difficulty "bits".
But Bitcoin itself never worked that way, not from the first instant. Changing it would have been a consensus incompatible change, and Bitcoin is still more or less consensus compatible all the way back. (There are outright bugs that make the old software get stuck, but if you fix those, it follows along).
No bitcoin software was ever released that worked another way.
The bitcoin whitepaper told them that, in more than one place too, so it's not a simple typo, e.g.
...we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits.
-log_2 (H / 2^256) = 256 - log_2 H leading 0s
and allow for fractional number of leading 0s.
The nBits header field closely resembles a 32-bit floating point representation of this number (I say resembles because it's really a floating point representation of the threshold H value).