Puzzle Keys Are Random. They’re made to be unpredictable. No amount of crunchin’ numbers or shufflin’ letters will show you a pattern ‘cause there ain’t one. The only way to crack the puzzle (all together) is to know the master random seed. Good luck with that. It could be up to 30 characters long.

A=1, B=2, etc. Is Made Up. That letter-to-number thing you’re usin’? Total guesswork. The puzzle maker never said nothin’ about it, and unless they straight-up confirmed it, you’re just chasin’ your own tail. You’re tryna force a pattern where there ain’t one.

AI Can’t Beat Randomness. Any AI "predictin’" missing values (like sayin’ Y=4) is just catchin’ lucky breaks in tiny samples. Try it on a bigger batch or different keys, and it’ll flop. Random means no steady trios or trends. Just pure chaos.

The "69" puzzle key got found early ‘cause brute-forcin’ a small range is all about luck and odds.

Swappin’ the first few digits (like turnin’ 6 into 4) might seem like a win in your tiny sample, but stats don’t lie. Every possible key’s got the same shot.

The only real ways to solve these puzzles? Brute-force it (check keys one by one or jump around) or get stupid lucky. Even that "first 25%" guess is just a shot in the dark. The key could be anywhere in the range.


Good luck, but don’t overcomplicate randomness



Yo, you're on the right track with that batch point addition logic from JLP, especially how you're mixing in batch processing like Cyclone does. But here’s the thing. You need a compressed (even/odd) database. Or, if you wanna keep it light, whip up a database that only takes up 8 bytes. Kinda like that slick public key database from @Mcdouglas-X3. That’ll speed things up big time, givin’ you enough bandwidth to hit at least 90 bits.

So, according to this it is possible to reach up to 90bit using only RAM, CPU and database (big storage) for even/odd points ? 

I have a question and why two different private keys can lead to the same address in certain circumstances?
Example:000000000000000000000000000000000000000000000050574a424748444e47
fffffffffffffffffffffffffffffffebaaedce6af48a08c171ca0d4187a8f88
1ECDtqs8nAUyxNuTY4kTV6rHr6NoVUkMna

This is where the Key range ends fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140

How did you come up with that private key???

Here's private keys in the permitted range:
000000000000000000000000000000000000000000000050777fa42474
fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd2af044fda65b5
5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEFZx7SbUFZwUky8
5Km2kuu7vtFDPpxywn4u3NLpbr5jKpTB3jsuDYYXQoaUyo4Bo7F
1M11bSzALREuhhLooRM2T1NMnfVk3sUc9S

You say, for example, this specific key is not permitted:
5Km2kuu7vtFDPpxywn4u3NLu7gtP9wNBvb8bwE71ENjYimUMdZY
146h7J8tRLa13oRt914DUtTgz6erwLKPAS
If I installed the same specialty in the Electrum wallet.

Something ticked today... and it's so freaking simple. The "math" also works out, but I'll need some time to implement the end-to-end concept.

All I can say for now is that the kernel's processing 11 GKeys/s on a RTX 3090 and 22.8 Gkeys/s on a RTX 4090.

The main idea is that computing public keys as fast as possible is even faster if they're not moving around blindly, like what happens in Kangaroo. But no one tried to use this effectively. I think this is because on a CPU there's basically zero performance difference, but on a GPU... the speed rockets (not that it wasn't already freaking fast) because the unknown dynamics disappear. Hence, a speed 3 to 4 times higher.

The beautiful thing is to answer this question though: what the hell can one do with such computations. They definitely can't be extracted, right?

But no, this is not about magic splitting methods or reducing ranges. It still requires sqrt(N) total ops, however they run much much faster, and it's also fully deterministic (guaranteed upper bound). Oh, and no worries, it doesn't require amounts of storage the size of our galaxy.

Now, please don't scratch your head, call it BS, or whatever. If you want some hints, try to research some papers on DP alternatives, and move that idea to another algorithm.

So can you say what these valid keys are? If you say the keys are the limit that you said, now the specific key I say is much bigger than it, but as you say, this is a valid key. What is the difference?
5Km2kuu7vtFDPpxywn4u3NLu8iSdrqhxWT8tUKjdbgPsxn6ctw9
115792089237316195423570985008687907853269984665640564039457584007909433131315
ffffffffffffffffffffffffffffffffffffffffffffffffffffffff23abc133
1MLjw3cSC4rnkXxPRRKugGJaYDTU7nTT49

---

"In response to your question, I have conducted studies on the elliptic curve that allow me to simplify some key encryption calculations. One of these is the calculation of the compressed address of the private key. To compute this, we first determine the decimal representation of the key and then multiply the result by 256. This gives us the decimal number of the private key for the compressed address we are looking for."
5HpHagT65TZzG1PH3CSu63k8DbpvD8s6GJmReYUvFeeoYmkGcfC
Uncompressed: 1LG2ZwyaX8GdofxzBoApa3D9vjjd3iguk9
Dec: 404560468236045398516257
404560468236045398516257 × 256 = 103567479868427622020161792
Dec Compressed : 103567479868427622020161792
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi6EZR5nhxE3fBrTAEyMEVe
1PBVLeJdrLTBVx2j3NqxbPAQ3s8hzLat78

Thank you for your guidance.

Good afternoon


How many hours of GTX 4090 needs for solve puzzle 135 with RogueCoder SOTA software ?

BR.