Show HN: SHAllenge – Compete to get the lowest hash

Original Article ↗ Hacker News Discussion ↗

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.