MultiCyclone v3.0

Not on an RTX 50-series card? The binaries here are sm_120 only and will
not run on anything else. Use
v3.0-multiarch
instead — same code, built for Turing through Blackwell (sm_75/80/86/89/90/120),
at identical speed.

Read this first

Both binaries are built for sm_120 only — RTX 50-series. They will not run on
any other GPU. For anything else, build from source; it takes a few minutes:

make -j$(nproc) CUDA_ARCHS=120     # just your own GPU
make -j$(nproc)                    # every architecture your nvcc supports

asset	built with	needs
CUDACyclone-v3.0-windows-x64-sm120.exe	CUDA 13.1 + MSVC 14.44	NVIDIA driver for CUDA 13.x
CUDACyclone-v3.0-linux-x64-sm120	CUDA 12.8 + g++, Ubuntu 24.04	NVIDIA driver for CUDA 12.8+, chmod +x

Stop and resume

Ctrl+C or --seconds now writes a checkpoint; the same command plus --resume
picks up where it left off, as many times as you like.

^C
======== INTERRUPTED (Ctrl+C) ==========================
Checkpoint saved to cyclone_checkpoint.txt at 18.32% (73282879488 keys checked, encrypted)
Resume with the same command plus --resume

--resume refuses to run unless the target, --range, --grid, --slices,
--tpb and the GPU set all match what the checkpoint was written under — each
of those re-tiles the range across threads, so a saved offset would no longer
mean what it did. Mismatches are reported field by field rather than silently
searching the wrong keys.

Checkpoints are encrypted. In the clear the file would name the address you
are hunting, the range, and how far you have got. The key is derived from the
search identity (target hash160 + range), so resuming needs no extra secret —
--resume already requires the same --address and --range. Add
--checkpoint-pass PASS (or set CUDACYCLONE_CHECKPOINT_PASS) to mix in a
passphrase, which also seals it against someone who does know the target;
lose that passphrase and the progress is unrecoverable. SHA-256 counter mode,
encrypt-then-MAC with HMAC-SHA256, fresh random nonce per write, MAC verified
before anything is parsed.

Idle GPUs take over the CPU tail

--cpu-threads splits a --cpu-percent slice off the end of the range for the
CPU. That split is fixed up front, so if it over-allocates the CPU the GPUs
finish and sit idle. They no longer wait:

GPUs finished their share; taking over the CPU sidecar's remaining
FFCAD3992A - 10000000001 (0.89B keys)

Each CPU thread reports its position, and the takeover starts at the lowest one
— a superset of the outstanding work, so nothing can be missed. Measured 8.4 s
against ~169 s on a 2-billion-key CPU tail. --cpu-auto still benchmarks both
sides and splits so they finish together; the takeover is the safety net for
when that drifts.

Fixes

• --seconds no longer claims the range was exhausted. It printed
  KEY NOT FOUND (exhaustive) and exited 0 after stopping at any coverage at
  all. Now prints STOPPED (time limit) and exits 2.
• Reported hash rate was swinging ±10% while real throughput was steady. The
  per-thread counter flushed at 65536, but a thread only does slices * B keys
  per launch (32768 at the default 64 x 512), so it never fired and the
  counter only moved at kernel end — aliasing against the 1 s sampling. Now
  3.7% solo and 1.4% with the CPU active, at unchanged throughput.
• make could not build on Windows at all (23 errors in Int.h). cpu_avx2
  gates its MSVC vs GCC intrinsic paths on WIN64, not the _WIN64 MSVC
  predefines, and the Makefile never defined it. CMakeLists.txt already did.
• host_sha256::sha256 overruns its stack buffer above 55 bytes. It handles
  exactly one 64-byte block. Safe for its existing 25- and 32-byte callers, but
  a landmine for reuse; the checkpoint crypto uses a proper multi-block
  implementation, verified against FIPS 180-4 and RFC 4231 vectors.

Exit codes

code	meaning
0	key found, or range searched exhaustively
1	bad arguments, or a --resume checkpoint that does not match
2	stopped by --seconds before the range was exhausted
130	interrupted with Ctrl+C

2 and 130 mean the range was not fully searched — both leave a checkpoint.

---

Earlier releases and the pre-v3.0 history remain available under the v2.5,
v2.1 and Release tags.