[HN Gopher] Show HN: SHAllenge - Compete to get the lowest hash
___________________________________________________________________
Show HN: SHAllenge - Compete to get the lowest hash
I've always had an appreciation for the properties of hashing. I
especially like the concept of Proof of Work, so I tried to make a
little competition out of it.
Author : quirino
Score : 80 points
Date : 2024-06-14 18:33 UTC (4 days ago)
(HTM) web link (shallenge.quirino.net)
(TXT) w3m dump (shallenge.quirino.net)
| JSDevOps wrote:
| Quirky and fun
| jimbobthrowawy wrote:
| I like that you linked to a javascript miner. Makes it really
| easy to try instead of needing to write up some code.
|
| Design/colour scheme is nice too.
| quirino wrote:
| Thank you!
|
| Curiously most of the code for that JS miner was written on my
| phone, with the help of ChatGPT.
|
| I didn't have my laptop with me and was curious how fast a
| phone browser would be able to mine.
| Toutouxc wrote:
| Coding and testing JS with the help of ChatGPT is several
| multitasking levels above what I'd be willing to even try on
| a phone. Android, I assume? Big screen? BT keyboard even?
| quirino wrote:
| It was actually much easier than I expected. Just asked for
| it as a single HTML page, copied the output to a file and
| opened it on Chrome. Did very few adjustments.
| logicallee wrote:
| Can you share that ChatGPT conversation, please? (There
| is a share link in ChatGPT.) Thank you.
| NAHWheatCracker wrote:
| I ran the javascript miner for like an hour, then I asked
| ChatGPT to write some go code that worked perfect (minus an
| unused variable error).
|
| The go program beat the javascript miner within seconds. Right
| now it's that easy to get into the top 10.
| quirino wrote:
| Maybe I should include a warning that it is pretty slow.
|
| I'm using my own SHA256 implementation in C++, and it is at
| least 100 times faster than the JS one. I've measured it to
| be about as fast as the one on the Go standard library.
| NAHWheatCracker wrote:
| Anyone who stumbles into your SHAllenge ought to know that
| JS isn't going to be really competitive, so I think you're
| good. A warning might encourage them to delve a little
| deeper. I like that it makes it very accessible.
|
| I assume anyone with knowledge about GPU hashing and the
| will would be able to steal the top spot very quickly.
| Assuming seletskiy isn't already that guy. I don't have a
| good grasp on the compute difference between 8-9 0s and 10
| 0s in a reasonable amount of time.
| nzentzis wrote:
| Assuming hashes are random (which is a reasonable
| assumption, considering it's sha256), every extra leading
| zero cuts the probability of success in half, meaning
| double the candidates searched to find a matching value.
| So each additional leading hex 0 would take on average
| 16x longer than the last.
| omoikane wrote:
| I kept at it mostly as an exercise to test different
| compiler options. I found that a miner implemented in C
| runs in 1/5 the time of a Perl script (but at ~10 times
| more lines of code). Also, compiling with "-march=native"
| reduces the run time by ~10%, and concatenating all C
| files together to compile and link in a single step saves
| another ~0.5%.
|
| I felt like I got enough out of this exercise and don't
| need to burn more CPU cycles on it :)
| londons_explore wrote:
| Anyone got a guestimate as to the energy used to make that
| leaderboard?
| emigrantdd wrote:
| it's just for fun? :)
| playingalong wrote:
| Fun or not, but I think the parent means electricity, i.e.
| how much kWh were wasted/spent on this
| NAHWheatCracker wrote:
| ChatGPT says a desktop CPU uses 105Wh for every hour of maxed
| computations. I think a hash with 8 leading zeros takes around
| an hour and every additional 0 takes 16x that. I'll ignore
| anything less than 8 0s and disregard how close the hashes are
| to gaining or losing a 0.
|
| 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.
| quirino wrote:
| The top competitors are very likely using GPUs, I guess that
| would make this cost much much lower...
| jonas-w wrote:
| At least I'm not (second place currently), I'm using a
| single threaded rust program that chatgpt wrote for me. I'm
| getting 10-15 million hashes per second.
|
| 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
| wdfx wrote:
| 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.
| jonas-w wrote:
| I'm also yak shaving currently, as I'm using NixOS...
| which means spending more time looking for the correct
| packages and creating environments.
| jonas-w wrote:
| 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.
| wdfx wrote:
| I've parked CUDA for now, I don't understand it enough to
| care to fix the tooling.
|
| 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.
| jonas-w wrote:
| Wow 24MH/s on an i7 with 8 cores sounds really good!
|
| 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
| quirino wrote:
| I'm glad you had some fun! This experiment went about as
| well as I could hope!
|
| 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.
| jonas-w wrote:
| Very cool!
|
| 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
| seletskiy wrote:
| Hey. It's nothing very fancy. About 150 lines of C/CUDA
| code with no deps, including args parsing and logging.
|
| 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 646 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.
| jonas-w wrote:
| Thanks, I sent you an e-mail, you might need to check in
| spam folder, as gmail doesn't like my mail server.
| nzentzis wrote:
| I'm using a janky CUDA miner that's getting around 6GH/s on
| a 3090. My code is kind of bad though since I hacked it
| together in a couple of hours last night, so I wouldn't be
| surprised if a proper/competent implementation got 2-3x the
| hashrate mine does.
| jonas-w wrote:
| Mind sharing it? I have an AMD card, so its not that much
| of use for me, but still would be interested
| SushiHippie wrote:
| FWIW getting 8 0s took me 30 seconds, 9 0s definitely less
| than an hour, but after that I only got lower 9 0s, and 10 0s
| do not seem to be in sight
| NAHWheatCracker wrote:
| I guess either my computer or my code is really bad! I only
| got a mid-8 0s with multiple hours.
| SushiHippie wrote:
| 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
| NAHWheatCracker wrote:
| 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.
| SushiHippie wrote:
| 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.
| NAHWheatCracker wrote:
| 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!
| amenhotep wrote:
| 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!
| NAHWheatCracker wrote:
| Yea, I know. It makes me feel better this way, though.
| NAHWheatCracker wrote:
| BTW, I changed it so it's iterative, getting 12.5 MH/s.
| tgmatt wrote:
| 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.
|
| Start time: 1718742386
|
| 1718742387 SHA-256 hash of "NAHWheatCracker/486005487"
| is: 00000000cbed8e14c5e52b0c9bef443f017564aa6870da37f85ec
| 92dd01b544d
|
| 1718742394 SHA-256 hash of "NAHWheatCracker/993155254"
| is: 0000000031fadb4805db8036ec66d872bdd9f04a507e0bbfea9f6
| 0d1d00b86f2
|
| 1718742395 SHA-256 hash of "NAHWheatCracker/436316829"
| is: 00000000e20d059e8a7dc687b85bd6b33e891f7d4b27e98aaf0c9
| 91d0264066e
|
| 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.
| quirino wrote:
| 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.
| SushiHippie wrote:
| 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.
| playingalong wrote:
| Why would the selection of characters matter? (Other than
| making sure you try distinct input strings)
| SushiHippie wrote:
| It doesn't but I'm going sequential, so I needed
| different character sets for each instance I launched.
| playingalong wrote:
| Would it make sense to have some partial/incremental SHA256
| implementation? E.g. one that gives the first character only (in
| ASCII representation). So that you could have a cheaper money
| miner to narrow down the search space?
|
| Is it even possible to have cheaper first character SHA256
| algorithm?
| NAHWheatCracker wrote:
| SHA256 doesn't generate characters, it generates bytes that are
| usually rendered in hex form, which gives you the "first
| character".
|
| There isn't a known way to calculate just the first bytes of a
| SHA256 hash faster. Each step in SHA256 depends on the value of
| the previous step, so you have to calculate the whole thing
| through. SHA256 is meant for cryptography and would be
| considered vulnerable to attacks if a shortcut were known.
| Thorrez wrote:
| >Is it even possible to have cheaper first character SHA256
| algorithm?
|
| What would be the goal of that? Do you want a cryptographic
| hash function, or do you want something else?
| jjmarr wrote:
| Well, such an algorithm existing would be a massive
| breakthrough in cryptography research. The answer _should be_
| no since that make it easier to do a preimage attack than
| brute-force.
| noman-land wrote:
| This is essentially how bitcoin's proof of work algorithm works.
| They maintain the difficulty by adding 0s as computers get
| faster.
| cyanydeez wrote:
| 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.
| quirino wrote:
| 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/p
| laylist?list=PLUl4u3cNGP61KHzhg3JIJdK08...
| noman-land wrote:
| Thanks for the playlist! I've already been going through
| the later videos.
| moffkalast wrote:
| Yep. So much compute and energy thrown away because proof of
| stake wasn't figured out sooner.
| mindcandy wrote:
| You need some proof of work to prime the pump for proof of
| stake. Otherwise, you have no security because there's
| nothing at stake.
|
| Now that we have plenty of proof of work completed, we don't
| really need any more. You can bootstrap your new coin by
| burning Bitcoins as a provable value sink to get it started
| on the path to POS.
| moffkalast wrote:
| You could stake fiat in a bank account I guess?
| mindcandy wrote:
| That's pretty much Tether. You could probably bootstrap a
| POS coin by staking Tether. There would be a lot of
| details in getting it to eventually grow independent of
| Tether. I don't claim to know how that could happen.
| Especially since Tether is not a highly-regarded/trusted
| token in the community.
| stavros wrote:
| Did Ethereum end up moving to PoS? How did that work out?
| ForHackernews wrote:
| Bitcoin still refuses to move to proof of stake. It's obscene
| https://digiconomist.net/bitcoin-energy-consumption
| KomoD wrote:
| Fun, no way I'm beating any of the top 10 scores though.
| nzentzis wrote:
| Getting into the top ten is still not too hard at this point,
| if you wanted to. I hacked together a super basic parallel CPU
| miner quickly before diving into CUDA, and the CPU one still
| gets a value that beats #7 within a few minutes.
| tln wrote:
| Suggestion: close submissions after it leaves the front page :)
| lovasoa wrote:
| Very fun ! I got to the first half of the leaderboard using Rust
| and ChatGPT.
| lovasoa wrote:
| I am now second place, still running on CPU only on a laptop :)
| quirino wrote:
| Just saw you got 12 zeroes! Second place!
|
| Did you start using a GPU or where you just insanely lucky?
| paulgerhardt wrote:
| Ah this brings back fond memories of the EngineYard challenge
| that consumed HackerNews in 2009[1][2][3][4].
|
| From what I recall it was a bunch of YC founders writing janky
| cuda code vs djb who proceeded to smoke us all.
|
| [1] https://news.ycombinator.com/item?id=704182
|
| [2] archive link to the dead link in [1]
| https://web.archive.org/web/20090717104634/http://www.engine...
|
| [3] https://news.ycombinator.com/item?id=716851
|
| [4]
| https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
| asciii wrote:
| > Win and iPhone 3GS
|
| Got a 404 but the title was a nice throwback, $2k in cloud
| credits too!
| Bluestein wrote:
| Might as well ask, as tangentially (even so slightly) related:
| DAE know of a way to get/generate "vanity" (arbitrary or close)
| Bitcoin addresses?
| stavros wrote:
| Yes, vanitygen.
| Exuma wrote:
| I got an amazing one only to find out Zalgo is not supported
| EXUMA :[
___________________________________________________________________
(page generated 2024-06-18 23:00 UTC)