Now, in Bitcoin, I'm thinking of a number between one and 2^160 (in fact, it's a little less, but let's not delve into technical details too much).
there is a tiny mistake here. that "number" that we choose in bitcoin (aka private key) is between 1 and a little less than 2
256 then that number is "converted" and "compressed" using one way operations to a smaller size (2
160).
It's actually a little more complicated than that.
There is (AFAIK) no really good answer to how many "guesses" we're talking about in this "game".
There are indeed 2^256 private keys (or slightly less), but they translate to a "mere" 2^160 addresses.
More than one private key translates to one address, but it's not as simple as saying "x private keys translate to one address".
that's a different topic though.
if we are talking about collision then it is not just about finding a hash collision in 2
160 range, that would be pointless. we have to find two "private keys" that collide to the same hash result. so the bounds for the loop that is used to choose the keys are from 1 to 2
256 instead.
now how many keys should be checked before we find a collision is what you are pointing out here. and in cryptography it usually is half of the final size meaning theoretically after checking 2
80 keys we may start seeing collisions.
At this moment the hash rate of bitcoin network is about 2^67 hashes/s, i.e. about 2^92 hashes/year.
that is a good number but also a bit of an unfair comparison. the hashrate is the result of computing double SHA256 of a mostly fixed 80 bytes message whereas a collision is going to be computing multiple things starting from an elliptic curve multiplication then 1 SHA256 followed by 1 RIPEMD160 of either a 33 byte input or a 65 byte input. most of the optimization that has gone into mining won't work here not to mention that there isn't much room to optimize RIPE-MD algorithm. the result should be a lot less than 2
92 for this process even if ASICs were made for it.