Show HN: SHAllenge – Compete to get the lowest hash

Original Article ↗ Hacker News Discussion ↗

A browser-based SHA-256 “mining” game is prompting programmers to compete for the lowest hash values, experimenting with everything from naïve JavaScript to hand‑tuned C, Rust, CUDA, OpenCL, FPGA, and GPU‑accelerated implementations. Participants trade optimization tricks, hash‑rate benchmarks, and architecture quirks, while also estimating the energy cost of chasing additional leading zeros and comparing the exercise to Bitcoin’s proof‑of‑work and historic coding contests. Many note how quickly AI tools help bootstrap working miners, turning the challenge into both a performance tuning playground and an accessible introduction to cryptographic hashing and GPU programming.

Overall impressions & accessibility

  • Many find the challenge fun, nostalgic, and well-designed (UI and concept).
  • The built‑in JavaScript miner is praised for making it easy to try, but widely acknowledged as uncompetitive versus native code.
  • Several participants quickly reach high leaderboard positions with simple CPU code generated largely by ChatGPT.

Implementation strategies & performance

  • Progression paths: JS → multithreaded C/C++/Go/Rust → GPU (CUDA/OpenCL/Metal) → FPGA.
  • Reported hash rates:
    • JS: ~2–3 MH/s with workers.
    • CPU C/C++/Rust/Go: from ~1 MH/s (naive) up to ~1.1 GH/s on high‑end desktop CPUs, with optimizations like -march=native, SIMD, hand‑tuned SHA-256, and midstate tricks.
    • Apple M1/M1 Pro/M1 Max GPU via Metal: ~230–340 MH/s.
    • Consumer GPUs via CUDA/OpenCL: hundreds of MH/s to tens of GH/s (e.g., ~18–21 GH/s on RTX 4090).
    • FPGA: ~22 GH/s on a high‑end board, with ~40 GH/s considered attainable.
  • Optimization themes:
    • Sequential nonces are faster than random; random input generation often becomes the bottleneck.
    • Short, fixed‑length messages allow skipping padding and parts of SHA-256.
    • Precomputing partial state (“midstate”), hand‑unrolling loops, exploiting big‑endian layout, tweaking Base64 encoding, and using CPU/GPU-specific instructions all help.

Energy use & efficiency

  • Some question energy “wasted” on the leaderboard; rough back‑of‑the‑envelope estimates suggest MWh‑scale total consumption, but are admitted to be very rough.
  • GPU mining can significantly reduce time and thus energy per result compared to CPU only.

Cryptographic properties & SHA-256

  • Multiple replies stress that there is no known cheaper way to compute only the “first character/bytes” of SHA-256; shortcuts would be a serious vulnerability.
  • Clarifications that SHA-256 output is bytes, usually hex-rendered, and that preimage shortcuts or partial-output algorithms would undermine security.

Relation to Bitcoin and proof of work

  • Several note the similarity to Bitcoin’s proof‑of‑work (leading zeroes).
  • Discussion clarifies:
    • Difficulty retargeting keeps block time roughly constant.
    • Money supply schedule (halvings, 21M cap) is independent of hash rate.
    • Mining secures decentralized consensus and prevents double spending, not directly “limiting money printers.”
  • Debate over proof‑of‑work vs proof‑of‑stake, including environmental concerns and security tradeoffs.

Bugs, UX, and extras

  • A Base64 validation bug around “=” padding is discussed; it was later tightened, with prior submissions grandfathered.
  • Suggestions include closing submissions after the thread leaves the front page and exposing aggregate data; an endpoint providing the full submission dataset is later added.
  • Several share or link their implementations as learning exercises for Rust, GPU programming, and parallelism.