For low-bit BTC puzzles, I use my own experimental solver version that I wrote in C++ loosely based on Bitcrack, but with heavily optimized CUDA kernels where its sequential scanhashing is from 80% up to 120% faster, depending on the Nvidia GPU model and architecture, than the original Bitcrack.
My Nvidia GPUs go like this with it, depending on card OC, at 100% power limit up to:
GTX 1080 Ti, 950 Mkey/s
RTX 2080 Ti, 1800 Mkey/s
RTX 3090, 3700 Mkey/s
RTX 4090, 6800 Mkey/s
In addition to significant optimization speed-up per GPU, my version has also modified scanhash search logic to be able to run in "skipping approach" and "forced pattern(s)" mode
Aham. Is that the speed of actually computing and hashing a key, or it's the speed of "hey, let's skip some keys because I think they look unlikely" or "hey, let's use endomorphism even though it's useless for searching a range"?
Because the first wall of real speed is actually computing a full X and Y (to have the parity) so you can correctly go to next step (hashing). If you skip private keys (or use derived X's via endo) you cannot include them as computed, right?
Also, what does it mean to you that a random sequence of 66 bits is "strange"? Letters and numbers are just an alphabet that maps some short sequence of bits to a symbol, what if we change the alphabet, will you then discard the new "letters series" and "too many numbers in a row"? See, you can always arrange something that's random to look like it's "too strange to ever happen", if you simply change the higher-level alphabet. A proper entropy test should be done at binary level, but IMHO it's just a waste of computing time with no real benefits (low-entropy strings are extremely rare to bother about them, for example only 66 strings that have a single "0", out of 2**66 strings).