# Mining: what is the lowest possible target? Could it be a block hash of all zeros?

I had a basic question about Bitcoin mining. I understand that as the bitcoin difficulty adjustment becomes harder the hash output will require more 0s in the beginning of the hash. Is it theoretically possible that the Bitcoin difficulty adjustment would be so large that the hash output would just be all 0s? I know this is theoretical bit I'm just curious.

The retargeting every 2016 blocks is computed as follows:

• `previous_target * (T2-T1) / (20160 minutes)`

Where:

• T2: timestamp of previous block
• T1: timestamp of block at `current height - 2016`
• Target adjustment bounded to factor 4

Ignoring the target adjustment limit: For the resulting target to be zero, `T2-T1` would need to equal zero. That would require an infinite amount of hash-rate. Therefore we can approach your scenario, but never reach it.

• Couldn't the division round down to 0? – Owen Delahoy Jan 28 '19 at 5:22
• For high difficulties, as we currently have, no. The block intervals are too high. For low difficulties, there is a min difficulty of 1, which bounds the max target value. – James C. Jan 28 '19 at 6:44

I understand that as the bitcoin difficulty adjustment becomes harder the hash output will require more 0s in the beginning of the hash.

This is slightly incorrect: a higher difficulty will require a valid block hash to have more leading zeros, but validity is not determined by counting the number of zeros. Rather, it is determined by comparing the value of the hash to the target (as defined by the network difficulty).

In other words: a difficulty adjustment may lower the target, but a valid hash post-adjustment could still have the same number of leading zeros as a valid hash pre-adjustment, despite the target being lower.

To dig in a little deeper, lets consider what the lowest target could be.This question contains some relevant info, as does this one, and this one.

``````difficulty (D) = hashrate / (2^256 / max_target / intended_time_per_block)
= hashrate / (2^256 / (2^208*65535) / 600)
= hashrate / (2^48 / 65535 / 600)
= hashrate / 7158388.055
``````

(where hashrate is expressed in hashes/s)

The target (T) is defined by:

``````D = Tmax/T
``````

where Tmax is: 2^224

Rearranging and combining these formulae, we find:

``````T = Tmax / D
T = Tmax / (hashrate/7158388.055)
``````

So we can see that the lowest possible target would be the result of an infinite hashrate, which of course is not possible. But nonetheless, as hashrate approaches infinity, the target would asymptotically approach zero (but being an asymptote, it would never reach it).

• One question. Difficulty cannot increase more than a factor of 4 at a time. when target hash reaches 0x1 (leading 0s omitted) it will remain there as a jump from 0x1 to 0x0 will be an infinite jump. – Ugam Kamat May 28 '19 at 6:02
• @UgamKamat I think you have confused the rules about the max difficulty change with the change in target. – chytrik Jul 1 '19 at 19:27
• Just so I understand this correctly, let us say that the current difficulty is 2.695953529101131e+67 so, your current target header hash is 0x01. Now to move from 0x01 to 0x00, wouldn't that be impossible as difficulty only adjusted by 4 at a time? – Ugam Kamat Jul 2 '19 at 1:46
• The difficulty could continue to increase 4x per retargeting period, but the target cannot reach zero. So I suppose the target would eventually just stall out in the extreme end of the limit – chytrik Jul 2 '19 at 3:48
• I think that is exactly what I was pointing out. It would stop at 0x01 as non-integer values won't be allowed. Since you mentioned asymptotically approach zero, I was confused – Ugam Kamat Jul 2 '19 at 7:00