SHA hashes: 134217728 speed: 7485947 hashes/s

Hashed bytes: 22145925120 speed: 1712 MB/s

So 1.7 GB/s with your everyday SHA hasher is not bad, what's bad is that it's doing a single hash of a 22 GB message, not hundreds of millions of hashes of 33 bytes.
In our case, the hash context needs to be reinitialized for every public key we need to hash, so AVX512 and so on maybe can bring a 50% speed-up, nothing to write home about.

Benchmarked OpenSSL Apple CommonCrypto and fast SHA with SSE3.2 intrinsics (last one was like 10% faster, probably because of inlining). I would bet that the CPUs that have hardware support for SHA instructions are actually used by the SHA routines available from the system APIs, and we wouldn't need to hack them ourself.

For AVX you'd actually need a distributed scheduling: https://github.com/minio/sha256-simd

I have ~120 Ekeys/s in BSGS/keyhunt on AMD after used  the AOCC compiler  


I've been tweaking linux for months to get every atom out of Dual CPU configuration.

#RT kernel


should be performance for all cores

/etc/default/grub


Nvme config (It must be a good Heatsink on Nvme, otherwise it goes over 50 C/I have had white smoke from them more than once - SAMSUNG MZVL2512HCJQ.)

temperature            : 42 C
Temperature Sensor 1           : 42 C
Temperature Sensor 2           : 50 C


/etc/fstab

AMD EPYC config

And so on and on....This is only part of it.

Zero clues of how or what you ran, but with a single CPU core, using keyhunt-cuda, it is found pretty much as the program starts:


SO maybe you entered wrong things/flags when trying to run the program.

my search techniques uses this
2^31 and 2^36
(36 bit)
MacBook-Pro:Desktop tepan$ python3 subs.py
Enter the range x: 31  
Enter the range y: 36

> 0x91000000 <

let's hunt.

    let begin: u128 = 0x910000000;
    let end: u128 = 0x9ffffffff;

const TARGET: &str = "1Be2UF9NLfyLFbtm3TCbmuocc9N1Kduci1";


result :

• Puzzle search
• Script started at: 2024-05-26 02:25:21.816449 +07:00
• from:0x910000000 to:0x9ffffffff
• target:1Be2UF9NLfyLFbtm3TCbmuocc9N1Kduci1

 00000000000000000000000000000000000000000000000000000009f7a02888| 1Be2JoBBasXePHijh1AD1FK5Wsui 00000000000000000000000000000000000000000000000000000009f3702fc4| 1Be2m52dDvKNf2wrvbvSoh4V4t8Q 00000000000000000000000000000000000000000000000000000009e2b0702a| 1Be2DebJWkfJWXb8cszjA8mN6fvh 00000000000000000000000000000000000000000000000000000009e6e07a23| 1Be2wkS3jkyDGWnVpiNXVzUYdTtY 00000000000000000000000000000000000000000000000000000009eb10e589| 1Be2f5NaU8Qv35nPzJk4S6Jntzvs 00000000000000000000000000000000000000000000000000000009fbd0fcef| 1Be2uQTHQC5V9QPTqSkHvGNpFA5H 00000000000000000000000000000000000000000000000000000009e2b117d2| 1Be2nTuUQDYvYgyHPfE6S4hBTVNc 00000000000000000000000000000000000000000000000000000009eb119a5e| 1Be2ncy8U6oS9UzUGQU13CW7prqo 00000000000000000000000000000000000000000000000000000009f371a027| 1Be2tHcpUiDPVcqdvu2v2KmtA1m9 00000000000000000000000000000000000000000000000000000009e6e1b74a| 1Be22Wi2usp5z2J1wRvfovS8pD7R 00000000000000000000000000000000000000000000000000000009fbd1be53| 1Be2eU7ktk7abQsFRHgVP1qmmpZW 00000000000000000000000000000000000000000000000000000009f371d249| 1Be2zLYgYPdSjL9cog8kCsWUVjax 00000000000000000000000000000000000000000000000000000009f7a1e133| 1Be2xv3Q6XtLnBAz4SmbqbaSkhs8 00000000000000000000000000000000000000000000000000000009de820a7c| 1Be2UF9NLfyLFbtm3TCbmuocc9N1 00000000000000000000000000000000000000000000000000000009e2b20b15|

• --------------------------------------------------------------------------------
• KEY FOUND! 2024-05-26 02:29:44.164813 +07:00
• private key (WIF): KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9Mg1Upu7eJAtiDr
• private key (hex): 00000000000000000000000000000000000000000000000000000009de820a7c
• public key: 02b3e772216695845fa9dda419fb5daca28154d8aa59ea302f05e916635e47b9f6
• address: 1Be2UF9NLfyLFbtm3TCbmuocc9N1Kduci1
• --------------------------------------------------------------------------------
• Search completed

it's like 3 minutes for search by address.

---

look at this, example of use.

34   2^33...2^34-1   200000000...3ffffffff | x : 29 y: 34 - > > 0x330000000 < [ 0x330000000:0x3ffffffff ] [found on 0x34a65911d ]

38   2^37...2^38-1   2000000000...3fffffffff | x : 33 y: 38 - > > 0x2100000000 < [0x2100000000:0x2ffffffffff] [found on 0x22382facd0 ]

.. etc
i make this premature codes for saving more times with lowkey cpu speed for search, but work until 79 bit, rest of that, the output result for keyspace is not correct.
sorry i cant provide the real codes, because someone can brute that easily with his huge mining GPU farm

I believe Keyhuntcuda2 from siupune has this functioning on the gpu

Hi there nomachine, you got a way for a working make file already done for this one , for amd..
right now i have not yet been able to do so, little time many works, thanks for your effort.

Wow, that's a cool config you have. When I tried to search for keys before, I did not reach a speed of more than 2 Ekeys

What world do you live in, in which the computer can generate "at least 100 million keys per second", I wanna move there.

If you are simply talking about a private key, then a "computer" can generate "number of cores" * "core frequency" private keys per second, but what the hell are you gonna do with a bunch of numbers?

Do you understand the difference between a public key and a private key, and how the first one is computed through the second one? I mean, all the math that's required is not some simple a + b.

I know how and what is generated. I need this for my experiment, but at this rate it's a perversion. And my hardware is quite powerful, 72 cores and 128GB of RAM. The same keyhunt, when brute force, produces 350 million keys at maximum load. But I need exactly this algorithm, hex separately from the public key. So that when I found a public key from the list, I knew its hex.