You are mistaken: my guess is that you are taking the square root because of the birthday paradox, but that is incorrect, and the birthday paradox does not apply here anyway.

The probability of generating a hash with the right prefix is 10 in 16^3, or about 0.25%. Finding a 0e... == 0e... collision has probability ~6e-6, if both inputs are random. The chance that two hashes collide in this way given N random inputs is 1-(1-p)^(N-1), for N>0.

> The likelihood of generating a hash value with that kind of prefix is 2 in 65536.

The prefix is not sufficient though, the suffix must be entirely decimal otherwise it's not a valid number in scientific notation.

The prefix is sufficient. Any hash matching /0e[0-9].*/ works.

As far as I can see the prefix is not sufficient, a single non-digit character in the tail fails the conversion (and the equality check): http://3v4l.org/ctASF (vs http://3v4l.org/5FvJu, exact same strings but for the last character replaced by a digit)

Which means the probability of generating a hash value of the form 0[eE][0-9]{30} is (1/128)(10/16)^30 or 5.9e-9.

It certainly reduces the strength of the hash (and MD5 shouldn't be used anymore in any case), but still a roughly 6 in a billion chance of someone choosing e.g. a password and it happening to be exploitable in this manner.

From the manual:

  > The value is given by the initial portion of the string.
  > If the string starts   with valid numeric data, this will
  > be the value used. Otherwise, the value will be 0 (zero).
  > Valid numeric data is an optional sign, followed by one
  > or more digits (optionally containing a decimal point),
  > followed by an optional exponent. The exponent is an 'e'
  > or 'E' followed by one or more digits.

Also:

  > If you compare a number with a string or the comparison
  > involves numerical strings, then each string is converted
  > to a number and the comparison performed numerically.