Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: SHAllenge – Compete to get the lowest hash

shallenge.quirino.net

Post reply on HN
Print view View original

31–40 of 136 posts

Re: Show HN: SHAllenge – Compete to get the lowest hash

#31

Post by NAHWheatCracker »

SushiHippie wrote: post #21
NAHWheatCracker wrote: post #20

Earlier quoted context omitted.

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.

Re: Show HN: SHAllenge – Compete to get the lowest hash

#32

Post by SushiHippie »

NAHWheatCracker wrote: post #31
SushiHippie wrote: post #21

Earlier quoted context omitted.

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 secon…

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.

Re: Show HN: SHAllenge – Compete to get the lowest hash

#33

Post by SushiHippie »

playingalong wrote: post #30
SushiHippie wrote: post #23

Earlier quoted context omitted.

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…

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.

Re: Show HN: SHAllenge – Compete to get the lowest hash

#34

Post by NAHWheatCracker »

SushiHippie wrote: post #32
NAHWheatCracker wrote: post #31

Earlier quoted context omitted.

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 secon…

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!

Re: Show HN: SHAllenge – Compete to get the lowest hash

#35

Post by amenhotep »

NAHWheatCracker wrote: post #34
SushiHippie wrote: post #32

Earlier quoted context omitted.

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!

Re: Show HN: SHAllenge – Compete to get the lowest hash

#36

Post by NAHWheatCracker »

amenhotep wrote: post #35
NAHWheatCracker wrote: post #34

Earlier quoted context omitted.

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 counte…

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

Re: Show HN: SHAllenge – Compete to get the lowest hash

#37

Post by NAHWheatCracker »

NAHWheatCracker wrote: post #36
amenhotep wrote: post #35

Earlier quoted context omitted.

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 counte…

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

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

Re: Show HN: SHAllenge – Compete to get the lowest hash

#38

Post by cyanydeez »

noman-land wrote: post #19

This is essentially how bitcoin's proof of work algorithm works. They maintain the difficulty by adding 0s as computers get faster.

Isn't the reason more about limiting currency. Most of the crypto bros all hate the money printers.

The fact that faster hashers will come about just adds some natural competition, but it's still about limiting money supplies.

Re: Show HN: SHAllenge – Compete to get the lowest hash

#39

Post by quirino »

cyanydeez wrote: post #38
noman-land wrote: post #19

This is essentially how bitcoin's proof of work algorithm works. They maintain the difficulty by adding 0s as computers get faster.

Isn't the reason more about limiting currency. Most of the crypto bros all hate the money printers. The fact that faster hashers will come about just adds some natural competition, but it's still about limiting money supplies.

The hashing is about consensus. It's related how a low hash stands as proof of computational power, you can't just fake it.

The "adding more zeros" is done automatically, according to an algorithm, so that the time between blocks is more or less the same.

There's this incredible MIT course about all of this, it's where I got the idea for the site from: https://youtube.com/playlist?list=PLUl4u3cNGP61KHzhg3JIJdK08...

Re: Show HN: SHAllenge – Compete to get the lowest hash

#40

Post by jonas-w »

jonas-w wrote: post #25
wdfx wrote: post #24

Earlier quoted context omitted.

I've also been spending today building a miner. Started in JS, then JS with worker threads (~2.2MH/s), then c++ with openssl (~3.7MH/s) and now attempting CUDA. 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.

I'm also yak shaving currently, as I'm using NixOS... which means spending more time looking for the correct packages and creating environments.

FWIW I got it working with rust and opencl, most of it is written by chatgpt as I have no clue about opencl. GPU usage is only 50-60% and I get 100MH/s.

With hashcat and opencl I could get 12GH/s but I couldn't find a way to use hashcat for this use case.

Post reply on HN