One hour later, it seems like you've got your 10th zero! :)

Luck plays a tiny part too, I'm testing sequentially and I got my 9th zero with only ~7e8 hashes, a whopping 100x earlier than expected.

Oh I didn't notice, I've written something so it automatically submits if it's a better value haha.

Yep, crazy how long it took, but currently I'm also running multiple 'variants'. All the same program except the nonce generation, one with numbers, one with 32 character long 'base64' and one with 64 character long 'base64'. I got inspired by seletskiy who instead of using numbers used the whole allowed character set for the nonce.

Why would the selection of characters matter? (Other than making sure you try distinct input strings)

It doesn't but I'm going sequential, so I needed different character sets for each instance I launched.

I guess either my computer or my code is really bad! I only got a mid-8 0s with multiple hours.

How many hashes does your code go through per second?

I just tried your HN username, and it took me these times:

19 seconds for 7 0s - nonce: 293576344

28 seconds for 8 0s - nonce: 436316829

I added some instrumentation and it was doing around 3.3 million hashes per second. Mine isn't sequential, it's generating random strings. Changing from a 64 byte string to a 26 byte string with (14 character nonce) brought it up to around 6 MH/s.

Given the nonces you provided, I guess you're going sequential and you're hashing 2-3 times faster than me. I just got a 7 0 hash in 70 seconds and an 8 0 hash in 164 seconds. You're right and I was overestimating how long I waited around last night.

After experimenting more with this, it seems like with random generation the bottle neck is the "input generation" and not the hashing itself, that's why I went with sequential.

I replaced my nonce generation with a static string and my hashrate went to the moon, so I invested more time in optimizing my input generation.

I profiled my code and you're right that it was using a big chunk of CPU on generating the input. Approximately 40-50% of the CPU time was taken up by go's rand.IntN function.

I was able to optimize it so that I only call rand.Int63 twice per string generation, bringing the CPU time of that part down to 10-15%. I'm getting 11.3 MH/s now!

There is really no point randomising at all, any cycles you spend on it are a total waste - one of the most important properties of a good hash algorithm is that a one bit change in the input should result in an output that's completely unrelated to the previous.

Your random number generator is pretty much equivalent to feeding a counter into SHA256, so using it as input is pretty much equivalent to hashing a counter twice. There's no point!

Yea, I know. It makes me feel better this way, though.

BTW, I changed it so it's iterative, getting 12.5 MH/s.

Curious. I tried with a C program that ChatGPT spat out using 12 threads of my CPU and I get the 8 zeroes almost instantly. It calculates 1 billion in about 13 seconds, apparently.

Tue 18 Jun 20:53:57 BST 2024

SHA-256 hash of "NAHWheatCracker/436316829" is: 00000000e20d059e8a7dc687b85bd6b33e891f7d4b27e98aaf0c991d0264066e

SHA-256 hash of "NAHWheatCracker/486005487" is: 00000000cbed8e14c5e52b0c9bef443f017564aa6870da37f85ec92dd01b544d

SHA-256 hash of "NAHWheatCracker/993155254" is: 0000000031fadb4805db8036ec66d872bdd9f04a507e0bbfea9f60d1d00b86f2

Tue 18 Jun 20:54:10 BST 2024

Admittedly using crude timing but I'm no C programmer so it is what it is.

EDIT: To be clear, I'm not submitting anything to the leaderboard as I appreciate the spirit of the challenge is writing your own code. I'm just having some fun.

Sure: https://pastebin.com/tFPadBVZ

Again, I didn't write it, but did add some timestamps.