ecloop a CPU-friendly tool for finding secp256k1 keys

Hey everyone, I want to share a project I've been working on called ecloop. It's a tool designed to efficiently search for Bitcoin public keys (hash160) on the secp256k1 curve. I borrowed some ideas from tools like keyhunt and brainflayer, focusing on clean C code that leverages SIMD acceleration. It can handle both compressed and uncompressed public key formats and uses a Bloom filter for large hash160 scans. This works on MacOS and Linux, and you can run it on Windows with WSL. This is the first time I'm posting it here. Key features: - 256-bit modular arithmetic and ECC coded in a single C file `lib/ecc.c` - Group inversion for adding points / precomputed tables for multiplying points - SIMD acceleration for RIPEMD-160 (AVX2 / NEON) - Fast SHA-256 with SHA extension support (both ARM and x86) - Search by range, random range, list of private keys, or list of words - Bloom filter to effectively filter through large sets of hash160 Benchmarks indicate it’s over 3.5x faster than keyhunt on x86 CPUs. Check out the repo here: https://github.com/vladkens/ecloop

I am using Makefile flags from @nomachine # ./ecloop rnd -f 71.txt -t 12 -o ./BINGO.txt -r 400000000000000000:7fffffffffffffffff  -endo threads: 12 ~ addr33: 1 ~ addr65: 0 ~ endo: 1 | filter: list (1) ---------------------------------------- [RANDOM MODE] offs: 2 ~ bits: 32 0000000000000000 0000000000000000 0000000000000042 8ddff88400000000 0000000000000000 0000000000000000 0000000000000042 8ddff887fffffffc 27.91s ~ 64.92 Mkeys/s ~ 0 / 1,811,939,328 ('p' – pause) i have about 65 Mkeys/s - This is madness.

You're welcome

Thanks for checking out my code and adding it to your collection! I appreciate the feedback, but the comment about the "buy me a coffee" link seems a bit out of place — I include that link in most of my public repos, not because I believe these techniques are mine or somehow original. I know this work builds on well-known ideas from papers, wikis, Bitcoin Core, and other open-source projects. Honestly, JLP's code is quite hard for me to read, so I'm not exactly sure what's implemented there. I wrote ecloop from scratch, originally as a brain wallet checker, and figured out the necessary algorithms as I went. Some concepts, like group inversion, come from Wikipedia and similar sources. I recently noticed JLP's trick with negative points and updated my code to use it. I also borrowed the multiplication (mod N) idea from JLP, since I didn't have enough time at the moment to search for relevant papers. So no, I'm not claiming the ideas are entirely new — just that this is a clean, fast, and (hopefully) simpler implementation that runs well on both x86 and ARM. Maybe it will help others push things forward. --- Also, I forgot to mention in the original post — if anyone knows of other mathematical ideas to improve CPU performance, I'd love to hear about them

That's cool! What CPU are you using? I don't have a good x86 processor at the moment to run proper benchmarks. Also, which compiler did you use? On my side, Clang on Linux gives about 10% better performance compared to GCC, but I haven't figured out the reason for the difference yet.

I have AMD Ryzen 5 3600 +  GCC C++11 - Debian 12 What about the AOCC compiler that was @nomachine mentioned earlier? https://www.amd.com/en/developer/aocc.html This is a specialized Clang for AMD processors. AOCC automatically converts scalar operations into SIMD instructions

It has only one flaw. You can burn the processor if you don't know what you are doing and you have inadequate cooling.

Very cool! You know how to do this using GPU/CUDA? If you can, and want a $$pecial project dm me.

Why does `-endo` show higher speed but takes longer? For the test below, using `-endo` takes 3x longer for the same range. ```console $ time ./ecloop add -f data/btc-puzzles-hash -r 400000000000000000:40000000000fffffff -o ./found_71.txt -t 4 threads: 4 ~ addr33: 1 ~ addr65: 0 ~ endo: 0 | filter: list (160) range_s: 0000000000000000 0000000000000000 0000000000000040 0000000000000000 range_e: 0000000000000000 0000000000000000 0000000000000040 000000000fffffff ---------------------------------------- 11.25s ~ 23.86 Mkeys/s ~ 0 / 268,435,456 ./ecloop add -f data/btc-puzzles-hash -r 400000000000000000:40000000000ffffff  44.70s user 0.03s system 397% cpu 11.256 total $ time ./ecloop add -f data/btc-puzzles-hash -r 400000000000000000:40000000000fffffff -o ./found_71.txt -t 4 -endo threads: 4 ~ addr33: 1 ~ addr65: 0 ~ endo: 1 | filter: list (160) range_s: 0000000000000000 0000000000000000 0000000000000040 0000000000000000 range_e: 0000000000000000 0000000000000000 0000000000000040 000000000fffffff ---------------------------------------- 33.01s ~ 48.79 Mkeys/s ~ 0 / 1,610,612,736 ./ecloop add -f data/btc-puzzles-hash -r 400000000000000000:40000000000ffffff  131.16s user 0.05s system 397% cpu 33.018 total ```

May be because one sixth (non-endo range keys) of 48.79 is equal to one third of 23.86? So the same key is reached, but at a speed rate of three times slower? Endomorphism is like slowing down a fast car, but having more cars instead. However, only one of the cars is the one you actually want to get to the first Starbucks, while the other 5 cars are wondering around the Milky Way.

Ok, makes sense. But this means using `-endo` causes it to search outside the range `-r 400000000000000000:40000000000ffffff` which is explicitly provided. Right?

Right, since that's pretty much the definition of endomorphism: fast mapping of a scalar multiple to some other point. The multiple here being a 256-bits constant.

Hi. Yes, endomorphism will check other keys outside the given range. It's a math property of the equation – more details here: https://bitcointalk.org/index.php?topic=5527935.msg65000919#msg65000919 When converting a privKey to an address, there are two heavy ops: 1) EC point calc (on the curve) 2) hash160(pubKey) EC point calc is heavily optimized using math tricks. Hash160(pubKey) is optimized via SIMD but still slow. Endo helps shift more CPU cycles to hashing, slightly boosting overall keys/sec.