Anyone got a guestimate as to the energy used to make that leaderboard?
There's 13 8s, so that's 1365Wh. 5 9s is 8400Wh, 2 10s is 53760Wh, 3 11s is 1290240Wh.
Total that's ~1.35MWh, which might cost $100 to $180. Very weak estimate, though.
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.
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.
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
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.
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 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!
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!
Start time: 1718742386
1718742387 SHA-256 hash of "NAHWheatCracker/486005487" is: 00000000cbed8e14c5e52b0c9bef443f017564aa6870da37f85ec92dd01b544d
1718742394 SHA-256 hash of "NAHWheatCracker/993155254" is: 0000000031fadb4805db8036ec66d872bdd9f04a507e0bbfea9f60d1d00b86f2
1718742395 SHA-256 hash of "NAHWheatCracker/436316829" is: 00000000e20d059e8a7dc687b85bd6b33e891f7d4b27e98aaf0c991d0264066e
End time: 1718742403
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.
EDIT 2: Added some better timing. Interestingly, I modified it to use 64 bit integers and it was dramatically slower. Like, orders of magnitude slower.
Again, I didn't write it, but did add some timestamps.
But seletskiy is, as you can see in his nonce which tells us that he uses an RTX4090 and has 18 Giga Hashes per second. I'm really curious how he wrote that program, as I have a Rx 7900 XTX and would love to use it for this competition haha
The code runs at steady rate of 18.00-18.40 GH/s at cloud GPU. In fact it's not hashes-per-second, but actually messages-per-second checked.
It launches a 64⁶ kernels in a loop, where each launch checks first two bytes of the SHA of a message concatenated with unique 6-byte nonce per kernel + 6-byte incremental nonce for each launch. There is only one block, so SHA algorithm is heavily trimmed. Also, most of the message is hard-coded, so pre-calculated SHA state is used; it's 10 loops less than needed to encode whole block. Since we only 2 bytes of the hash to check, last two loops also unrolled by hand to exclude parts that we wouldn't need. All code also in big-endian since SHA is, so message hardcoded in big-endian as well.
Base64-encoding is pretty time-consuming, so I've optimized it a bit by reordering the alphabet to be in ASCII-ascending order. I've got to the point where single binary-op optimization can earn 100-500 MH/s speed-up, and I don't really know what else here is remaining.
I don't have RTX4090, so instead I just rented 4090 GPU to run code on. It's less than $0.3 per hour.
I've tried GPT-4 to get some directions for optimization, but every single proposal was useless or straight wrong.
I by no means a C/GPU programmer, so probably it can be optimized much more by someone who more knowledgeable of CUDA.
GPU's are ridiculously fast. It freaks me out that I can compute >18,000,000,000 non-trivial function calls per second.
Anyways, if you want to chat, my e-mail is in the profile.
If you limit your variable portion to a base16 alphabet like A-P, radix encoding would just be `nibble + 0x41`. Sure you're encoding 4x as many values, but with full branch predictability. You'd have to experimentally determine if that performs any better.
You could also do something theoretically clever with bitmasking the 4 nibbles then adding a constant like 0x4141 or 0x00410041 or something (I'm too tired to think this through) and then you can encode twice as many per op assuming 32-bit bitwise ops are similar in speed to 16-bit bitwise ops.
Anyways this has been a cool challenge. You might also enjoy hunting for amulets - short poems whose sha256 hash contains a substring that's all 8: https://news.ycombinator.com/item?id=26960729
If you carefully organize the nonce at the end and use all 55 bytes, you can pre-hash the first ~20/64 rounds of state and the first several rounds of W generation and just base further iterations off of that static value (this is known as a "midstate optimization.")
> If you limit your variable portion to a base16 alphabet like A-P
The more nonce bits you decide to use, the less you can statically pre-hash.
In FPGA, I am using 64 deep, 8-bit-wide memories to do the alphabet expansion. I am guessing in CUDA you could something similar with `LOP3.LUT`.
Also have been using ChatGPT to do the code translations.
I'm currently stuck in yak shaving, I cannot compile CUDA programs here yet as on fedora 40 I need an earlier gcc (13.2) which I am now also having to compile from source.
With hashcat and opencl I could get 12GH/s but I couldn't find a way to use hashcat for this use case.
Got an optimised C++ version with no deps averaging about ~24 MH/s on an i7-11800H.
I've got 9 zeros; if I get a result that ranks top 10 I think I'll submit and call it a day.
I don't know how I got it working, but I'm now at 3GH/s with my OpenCL implementation. I basically converted 90% of my rust logic to opencl and now my GPU is at 100% usage and I also needed to switch to a tty, as my window manager became unresponsive haha
I'm kind of glad about this HN post, as I had absolutely no clue about how sha256 and opencl worked before this challenge.
Thanks @quirino
If anyone's curious, I'm getting 4.5MH/s single-threaded and 12.2MH/s multi-threaded on a slightly old i7 with 4 cores.
It's my own C++ implementation, which I've made about 20% faster than the fastest one I found online (Zig/stdlib, also tried Go/stdlib, C++/cgminer, rust/ring, C++/VanitySearch and Python/stdlib).
I think it might be faster just because I was able to skip some steps, since all inputs are short and of the same length.
I've just finished testing 10^12 inputs. I think I'll stop with 10 zeroes, which is very likely to happen in the next couple of days, according to my calculations. I might revisit it later to learn some GPU programming.
But same, I also was able to skip some steps as I can make some assumptions about the input as its fixed in length and doesn't need padding.
I got lucky and found a hash with 12 zeroes in 60s with my OpenCL implementation, and now I got my second spot back.
GPUs are so crazy
Running this for 1.5 hours would consume 1KWh of energy, and compute 1.134e14 hashes (or 2^46.7 if you prefer).
Assuming SHA-256 hashes are essentially normally distributed, that means that finding a hash with 13 leading hex zeroes should be a 1-in-(16^13) aka 1-in-(2^52) odds.
This gives 2^(52-46.7) or 39.7KWh on average to generate a single 13-zero hash, and ~16x that (635KWh) for a 14-zero hash. I got very lucky finding a 14-zero hash quickly, vastly earlier than average expectation, so my energy usage is quite a bit lower than that.