Of course. Anyone can do that, on any public key.
And then, if that key really has only 135 bits (it lacks DLEQ proofs, so we can assume it is the case, but we cannot be 100% sure), then 026740DAF760406CEAE6D79B0AC803B8D2A7DF71DDC4DB08264325A10BCC3DD66A or 02163134C25215569344912A14EA07CCD8ADA8573458A1672BBF845D0D83F9F6EB has 134 bits. And so on, and so forth: the range can be always reduced. It is possible to generate 32 public keys, where one of them will have 130 bits. But: nobody will know, which one, and it won't make the challenge any easier.

Well, there are some known weaknesses in hash functions. And by observing some patterns, it is possible to skip some keys. However, newbies from this topic know nothing about internal connections of temporary values inside SHA-256 or RIPEMD-160, to use it properly, and really skip some keys. Which means, that prefixes are useless, because by observing the first N bits of RIPEMD-160, you observe random different internal bit positions inside RIPEMD-160. Because the first bit of RIPEMD-160 does not depend on just the first bit of the hashed message. These dependencies are much, much more complex than just that. A single bit of the final hash depends on hundreds, sometimes thousands of bits of the hashed message, and avalanche effect turns all of that into a complete mess.

However, someone, who has some crypto skills, can make some useful optimizations. Because it is not needed to compute every hash function till the end. Here is some SHA-256 example, why it is the case, and how to use it properly. Let's say that we have the hash of the Genesis Block:
And then, when miners grind their nonces, then what is really changed in practice? Only nonce value, set to 0x1dac2b7c is incremented, decremented, or otherwise altered. Which means, that for the first 2^32 computations, after getting a given block template, a lot of computations are identical. A lot of internal SHA-256 states are identical, when first, second, and third message is hashed. Which means, that things doesn't have to be computed every time.

One of the obvious optimizations is saving "exit hash", and then using only two SHA-256 calls, to mine things. However, there are also some less obvious optimizations. For example: if a single 32-bit value is the only thing, which is changed, then the final block hash depends only on these 32 bits. Everything else is constant. All other w-values are the same. Which means, that a lot of things can be computed once, and reused, without triggering the full SHA-256 computation over and over again.

And this fact is obviously used in some ASICs, because they are wired specifically to mine 80-byte block headers, and many things are computed once, and then stored for all future computations. When it comes to RIPEMD-160, executed on top of SHA-256 of some public key, similar optimizations can be done. But it is far from mapping the single bit of the hash, to the single bit of the hashed public key. By analyzing SHA-256 and RIPEMD-160 more deeply, it is possible to create a chain of equations, which would allow skipping some keys, but I doubt prefix searches are smart enough, to even prepare such equations, and switch from their "vanity grinding" into something better, and actually checking the proper bits in RIPEMD-160 output, instead of checking just the beginning.

Just ignore them. Reading this thread after filtering some users is much easier.