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.
Quoting from those answers:
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).
Couldn't the division round down to 0? – Owen Delahoy – 2019-01-28T05:22:35.153
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. – 2019-01-28T06:44:38.403