Hey guys.

Would a 5090 produce even better results than a 4090 in what we're trying to do? You can only go so fast. Thoughts?

5090 is about 50% faster compared to 4090.

I don't know what you mean by "perfect cuda programming". This is clearly an oxymoron like "perfect programming".
Anyway, in my own benchmarks I get about 50% difference. Vanity shows up to 5500MK/s using 4090 and up to 8000MK/s using 5090.
If you measure per Watt speed, both 4090 and 5090 perform the same.
It's all just estimates, so YMMV.

Hey has the privatekeys.pw site been down all day for you guys too?

A few Cyclone updates: threads and public key skipping if it starts with K leading zeroes, because 71 partial hash generates with 1 max 2 leading zeroes  public key X ccordinates.
https://github.com/Dookoo2/Cyclone

You have an error in AVX512 version, the 10th key, index 9 will never receive its actual SHA-256 hash but a copy of the previous result (outPtr[8]), so the hash will be incorrect for this key. On line 258.

I won’t update it, may be later.

Cyclone_avx2# g++ -std=c++17 -Ofast -funroll-loops -ftree-vectorize -fstrict-aliasing -fno-semantic-interposition -fvect-cost-model=unlimited -fno-trapping-math -fipa-ra -fipa-modref -flto -fassociative-math -fopenmp -mavx2 -mbmi2 -madx -o Cyclone Cyclone.cpp SECP256K1.cpp Int.cpp IntGroup.cpp IntMod.cpp Point.cpp ripemd160_avx2.cpp p2pkh_decoder.cpp sha256_avx2.cpp
g++: error: unrecognized command-line option ‘-fipa-modref’

Absolutely not. Kangaroo isn't a lottery contest (like a hash brute force search is). It's only reason of being more and more likely to find a solution after some number of operations is because it uses the output of those some number of operations. 100.000 separate guys will need to each compute for themselves those ops before ever reaching equal odds. Not a one-ticket lottery. at all

Some may say this is wrong and anyone can hit the key from the first try.

Totally agree. Just as feasible as having that one-legged unicorn riding a monocycle, on a tight rope, over a volcano, blind-folded, with meteors popping off.

If I understood your question right, maybe one possible way to simplify the check is to first verify whether both points are n-torsion points (nP = O and nQ = O). If not, you can already rule out that they belong to the same n-order subgroup. If they both are, i think you have to build up the entire subgroup as you said, i don't think there is a direct way to check. But at least the n-torsion check can help "quickly" exclude cases that definitely don’t match, or at least use less computation. Could this make sense?