Of course, secp256k1+SHA256+RIPEMD160, not rounding of SHA256 output. But definitely it is acting like rounding.

There are two answers to your question.
1. No other private keys, if you mean the same public key (256 bits of X-coordinate plus one byte for parity of Y-coordinate and pubkey format). This is guaranteed by elliptic curve group structure. Each public point and corresponding coordinates are unique. It's true also for compressed pubkey.
2. Yes, huge amount of private keys, if you mean the same public address (160 bits, wallet address). Approximately there is must be 2^96 different private keys for each public address. This is provided by good statistical properties of SHA256 hash function, which was accurately tested by many cryptographers before this hash function was standardized, i'm sure. We must have unavoidable collisions for 256 bits space of input at rounding of SHA256 output to 160 bits. It is the reason for the creator of the puzzle to cancel problems from #161 to #255 some years ago, because if you can solve #160 by brute force means you can reveal privkey for any address in same time. It is not true for ECDLP, but ECDLP-race started only 4 month ago.

Nice question, thanks.
PS: nobody found collisions with known public address for secp256k1+SHA256 and similar schemes, it's equivalent to solving #160 by brute force. You can also found random, but useless collision by Pollard's rho or kangaroo methods, that equivalent to solve #255 with kangaroos. Yes, here is Pollard again. When the first case will be happened, BTC and all similar cryptocurrencies will be broken. Hopefully, we have only #63 solved right now, and no practical chances for #159 (#160 is occupied by kangaroos) without superquantum computer, which complexity growths even faster with each new qubit than the complexity of brute force, or we need something like Almanach from "Back to the Future" movie with published privkeys. Who knows what is more realistic.

Not 3 weeks ago, 23th Sep 19 only.
#105 key is:
DEC: 29083230144918045706788529192435
HEX: 16f14fc2054cd87ee6396b33df3
WIFc: KwDiBf89QgGbjEhKnhXJuH7Lrcim5eBMkFQwQtRbW6wxT1ajoNqE

I have used my own version of CUDA GPU code which almost exactly reproduces Pollard's Kangaroo algorithm published earlier as Python code. Solving #105 takes 1 month of working of GTX 1080ti at 270-275 Mh/s, and last 2 week of work of all my available GPUs (total h/s was approximately 1800Mh/s). So, it was not so simple as the Python code presented. I haven't reached published by j2002ba2 1600Mh/s. I has obtained only 470Mh/s with a cloud GPU server and one Tesla V100. I'm not a good programmer in CUDA, that why.
I guess, huge power is necessary for problems behind #120, as mentioned before by j2002ba2. At least with today state of art of ECDLP. Not only GPU power, but CPU and storage too, because we need to generate a huge amount of distinguished points (it was 24GB of data in my case) and to analyze this data in appropriate time. I guess, it is the reason why #105 was unsolved so long time.
The luck was 25% in my case. Very good luck. I apologize for my English.

#105 is solved. I'll post the private key later, after learn most significant BTC forks. A checkpoint right now is uncompressed address that corresponds to the same private key: 1JATjHbShdvgkvGHyoRv1vTnEeiibqMVnj.
Thanks very much for the creator of the puzzle! I have learned so many beautiful math at puzzle solving.   

This is really cool! j2002ba2, thank you very much for posting this reference point.

Functions from random module used only in preliminary stage for placement tame and wild herds. So, there is almost no influence on speed of the algorithm. Only if we try to select a huge number of kangaroos. Also, when the problem is very simple (16 bit, for example) the time of the placement may be significant in comparison with the time of solution. But total time still very small for human.
For pseudorandom hops the coordinate X itself is used.
Main goal of the code presented is a template with minimal dependencies. Numpy is external module which requires installation.
But I can't eliminate gmpy2 at all, it is very efficient.
Anyway, the table with time-to-solve estimations posted by j2002ba2 means GPUs are 3..4-order more efficient than the code presented.
j2002ba2, if you are here, how many hops/sec you have reached on single Tesla V100? Is my estimation of 2 GHops/s correct? At least 1 GHops/s required if authomorphisms taken into account, but I can't beat even half of this value.

Network hashrate ~150MH/s почти с нуля за сутки. Как вы это делаете?