Hi, guys!
What speed is rtx 4060 in KeyhuntCuda (with any modification, may be)?
My speed (original version of Keyhunt cuda from GitHub) is 1.3Gkey/s but I think, that it will be faster, than my test speed.
Right now I try to do GPU Cyclone and my speed without secp256k1 computing (only compressed public key increment on 1 each iterations, hash160 and comparing to given hash160 (Incrementing pubkey on 1 each iterations not right, but only for tests) is 2.2Gkeys/s and I apologise that this is slow.

Because I am doing it right now:) The main target - to be twice faster than KeyhuntCUDA, but it is possible only with PTX ASM. And also if somebody knows an algo of Modular inverse faster that DRS62 - let me know. this is the main goal for me. Or stupidly do all of the code with PTX, that impossible for me

Well the measurement does not look good 🤣

When computing modular inverses in batch, the individual function to calculate the inverse has very little impact on the overall speed. In my version, a "stock" 4090 achieves around 7Gkey/s with some optimizations.

Still, it's crazy to see how in a group like this, 3/4 of the posts go against all common sense and basic rules of statistics. I'm referring to the absurd theories about prefixes and bit permutations.

Well that is the funny thing, no one believes in true sequential. None of the pools, not even Bram lol.

If solve time is average of 50% regardless of the order of ranges, why don't the pools nor anyone, start at key x and search it all to key z? Does human nature/gut feelings get involved? Or some kind of personal, average probability based on past wallets solved? Would love to hear their reasoning.

So it is funny to see those peeps laugh/mock at others for just trying to think outside the box/come up with new ideas. Who cares lol?! Let them do their thing. It's fine to answer questions, and even tell them, their program idea may not be the best. If they don't care or don't listen, why/how does that impact others? It shouldn't.

When I started learning about the curve and its properties and math, I thought I could find a new "shortcut". But it was only after trying various methods and talking to others, did I finally realize there weren't any. But I had fun learning secp and programming and the different algos. Did it hurt anyone? No.

If one can (has) track what they've searched, or even know what they've done during any jumps/skips based on h160 partial matches, or anything else, it is just as fast at solving than what anyone else is using, meaning same average solve time...50%. Debate your mama lol!

If you go full sequential from 0 to N you’re giving away your progress to the competition. It has nothing to do with better probabilities of finding the key.

For the record the only reason I talk here is to prevent folks from spending money thinking they have a 0.0001% chance of success while it’s in fact more like 0.00000000…..0001%
I’m likely taking 68 but that does not mean I enjoy people throwing their money out the window. Especially when fooled by baseless math theories.

https://github.com/FixedPaul/VanitySearch-Bitcrack

It's not a version of Keyhunt but of VanitySearch-bitcrack, though I don't think it makes much difference

If I'd knew that someone scans from 1 to N, or from N to 1, or from X to Z, or in steps of 1 or 2 or whatever, the first thing I'd do is the complete opposite (backward scan, complementary step sizes, etc.).

Another issue is that if I have 1 billion threads to scan, obviously they would all have to start from a different starting point. But someone can say that this is not a sequential scan as well. Of course, the tradeoff is simple: 999.999.999 EC additions (to compute start points), for a billion to 1 reduction in scan time. At the end, it's still a full sequential scan, no matter when and where each thread starts.

I have a BSGS that solves puzzle 60 in 3 seconds.
The problem is that we don't have public keys.  

We're rounding circles again... I have a Kangaroo precomputed DB that can solve any puzzle up to 75 bits in less than one second. It contains close to 3 billion DP points so far. Takes less than 50 GB of disk space.

The problem is that we don't have public keys.