Difficulty in hashcash is very simple, it is the number of leading bits that are 0 when the SHA1 hash output is viewed in binary.

Hashcash was expected to adjust difficulty every 6months or year, manually based on observed moore's law estimates. It was proposed that this be measured against a benchmark machine by some vague/undefined human consensus process and broadcast via signed difficulty update headers, and/or long TTL DNS TXT records.

In fact even the difficulty headers & DNS TXT records did not get implemented, and it was left to the users to adapt. This was because hashcash adoption on the server side was primarily spamassassin, and it used hashcash with a soft scoring; it was fairly forgiving - the user could put a higher difficulty to give themselves more -ve spam scoring, and adapt that over time as they felt the need. So that was more distributed, and self-organizing so I left it there.

Bitcoin has **automatic inflation control** which is Satoshi Nakamoto's extra innovation that helped make
the leap from non-reusable proof-of-work, to virtual scarcity backed
currency. Note there were some precursor ideas, discussions and implemented
systems and some of them got startlingly close, but they didnt quite put it
together. Anwyay that is a story for another page on some 1999 cypherpunks list posts on distributed ecash.

Bitcoin aims for a smoother inflation control and adjusts inflation every
2 weeks *automatically.*

Bitcoin makes three changes in the way it uses hashcash:

**hash update**bitcoin uses`SHA256`rather than`SHA1`(SHA256 didnt exist back in 1997, and its now conservative to use SHA256 in new systems)**extra security**bitcoin uses double SHA256 ie`SHA256( SHA256( x ) )`to effectively double the rounds, for extra security margin**fractional bits**hashcash difficulty can only double or halve; bitcoin needs more fine grained control, because inflation is adjusted more frequently, so it defines fractional difficulty.

Fractional bits explained: instead of looking for k 0-bits, the bitcoin
fractional bit extension looks for a hash that is less than 1/2^{k}
(when viewed as a fixed point number). So for example 20.5-bits challenge
would be to find a hash when (viewed as a fixed-point hexadecimal) that is
less than `.00000B504h` (to 4 sf). When difficulty k is an integer
this is the same as the base hashcash challenge.

Bitcoin difficulty isnt an absolute number of hashes, but rather a relative
difficulty, the number of times harder than a defined base difficulty. The
defined base difficulty is unfortunately not a power of 2^{10} nor
an even quite a power of 2 though it is very close (0.0015% discrepancy).
The reason for this leads on to the next implementation detail.

Deeper bit-twiddling (here's why base difficulty is not quite a power of 2):
bitcoin for compactness stores the difficulty (which is a 256-bit number
mostly full of 0s) as a 32-bit custom floating point format, 8-bit exponent
and 23-bit mantissa (plus an unused sign bit). And actually can only hold
multiples of 8 (the exponent is multipled by 8 before use). Consequently
(back to the variable precision part) the mantissa varies in size between
23-bits and 16-bits (1-bit bigger than 23-bits and the mantissa is shifted
right 8-bits, 1-bit smaller than 16-bits and the mantissa is shifted left
8-bits). It would have been more space efficient, and allowed constant
23/24-bit precision if the 8-bit exponent had been in bits not bytes (not
multipled by 8 before use). Anyway the minimum difficulty is 16-bit
mantissa FFFFh and exponent 4 (4 * 8-bits = 32-bits due to the byte
interpretation on the exponent value) so the base difficulty is .FFFFh/2^32
= .00000000FFFF000 so that is a little more than 32-bits of difficulty at
-log_{2}(.FFFFh/2^32)=32.00002201394726 (and it doesnt look better
in hex 20.000171552EFD6). (Technically bitcoin treats the target and hash
for less-than testing as 256 bit integers, and not as fixed point numbers.
Consequently the exponent of the minimum difficulty is actually encoded as
33-4 = 29 = 1Dh, not 4; I just found the fixed point view of things more
intuitive when I was reading about and figuring this stuff out.)

There is a claim, apparently, that mining pools set share difficulty to an
integral number of bits (the hashcash challenge), to make them faster to
verify. However that doesnt seem quite right to me because the number of
instructions is the same (intel CMP, JL, CMP, JL vs CMP, JL, AND, JE or if
there is no split over a word boundary CMP, JL in both cases).
And even if the instructions differ in a cycle or two, it hardly matters
for a simple test that you only do 1 in 2^{32} times. Though I do
prefer 2^{32} as a base difficulty as its simpler.

The discrepancy calculation: