It depends on the CPU. I think 211 kB is larger than the L1 cache, so if you lower the loop count and set the OMP affinity to a single core (maybe through the env vars) I'd say it may run faster.

You can also enable -march=native and various compiler flags like enable/disable AVX512. I experienced different results (better or worse) when playing with these options - for example, with some flags it is much better when running just a single thread, but worse when using more threads, due to AVX bottlenecks.

For specific purposes the speed can go even higher. As it is, both X and Y get computed and converted from 5x52 to 4x64. I would conjecture that a BSGS implementation can be blazing fast with these tweaks:

- Y is not needed (except for the last computed point, which updates the center pivot)
- use directly the 5x52 native representation

Baby steps ("i" index + key hash) would then be stored into the DB (for example the hash can be just the lower 48 bits of X, which is the lower 64-bit limb of the native FE). This will be slow because insertions can't be parallelized.

Giant steps ("j") would then simply run in parallel and do the lookups and collision handling also in parallel (DB is read only). But this requires updating the code to allow a stride size (giant step multiples), which is was, I think, the main reason it was requested by shinji366.

AFAIK this will solve in at most 1.41 * sqrt(b) additions the ECDLP, over a interval of size b, where half of them are the baby steps.

Maybe I will add the stride option in a few weeks and try some BSGS on top. Not a huge priority for me since it doesn't really scale well for high bits.

36 consecutive alpha h160

efbdefdbbdbbfedbacefafaafcbacaeffffa36d9

Proof:
f756a602faaff8784d1e6ecd2454a12b7468ecdc7081c352a4b02811736405ba (sha256 of public key, comp)

riiiight, so either the script is running on dozens of single cores, or is leveraging cupy/pycuda/etc., or is orchestrating the cuda backend instantiation, or..?

as in "An Aes Sedai never lies, but the truth she speaks, may not be the truth you think you hear."

or perhaps you forgot to x6 your speed for the endo and x1000 for the milliseconds

I jest, but that speed seems hard to swallow when I'm running at several times that and have several orders of magnitude less results

holey shucks, cuda be a beast

cool! triple points for the triple zeds

I found a couple more 6 (12), but I suppose the next milestone is now 7 (14) for base58 palindromes

all-number h160s (40 numbers) seem incredibly abundant, so I'm discounting these, but finding leading-letter h160s seems more challenging. so far my highest is 24 with aebecfcecaceafcbefcdfcbb489f7d6aea18934d

32-length base58 seem quite plentiful, but I've found nothing lower yet

I haven't looked at pubkeys, xpoints or real-words yet, but will do soon

ahoy!

6 (12)-character palindrome address

12VNTA4BUgA6MKH75vTMqcvnFcxUATNV21

Proof:
a5652319307b789b1bc8b7aac5ef4ee33e04a973875a590e145f8a5326b345c9 (sha256 of public key, comp)