A CUDA engine for hunting Cunningham chains of the first kind at
CC20/CC21 scale. Successor in spirit to
cc18_filter_cuda_CpC_v15.cu, but with a fundamentally different
architecture: instead of one sieve shape, it iterates Q-values across
~4,200 fingerprint shapes drawn from the empirical distribution of
real CC10+ chain roots.
For each variant V (a small-prime fingerprint D_V taken from the
historical CC10+ catalog), it samples a value Q in the configured
bit band and tests whether p = Q · D_V − 1 starts a Cunningham chain
of the first kind. The construction guarantees small primes never
divide p (because D_V | (p+1)), so the candidates pass a strong
structural filter before the engine spends a cycle on Miller-Rabin.
Throughput at the current optimum: ~150 G(Q,V)/s per RTX 5090.
Open Cunningham-chain search code is conspicuously absent. Existing record announcements publish numbers, not implementations. The methodology here — fingerprint pool derived from a real chain corpus, external-prefix structural validator, GPU sieve + CPU prove pipeline — is the part worth contributing.
If you use this engine to find a new chain, please:
pzktupel [at] pzktupel [dot] de.# 1. Build (requires CUDA 13.x, GCC supporting sm_120 for Blackwell/RTX 5090)
make -j
# 2. Run the long-run search preset on GPU 0, two prove threads per core,
# output to ./run/ — runs forever until Ctrl+C
./scripts/run_cc20_hunter.sh
# 3. Watch hits roll in
tail -F run/*/hit.log
| Target | Cunningham chains of the first kind, length ≥ 10 |
| Default bit band | p_0 ∈ [2^89, 2^107 − 1] (90–107 bit roots) — keeps the target-21 chain top < 2^127, inside u128 |
| Default depth | 21 (filters small-prime composites at chain positions 0..20) |
| Pool size | 4,248 fingerprints (96.78 % coverage of historical CC10+); plus a primorial-quotient pool (3,000 V’s) for exhaustive-mode runs |
| Hardware | One CUDA GPU (RTX 5090 reference); 8+ CPU cores for prove |
| License | Apache-2.0 |
README.md (this file) |
What it is, why, quick start |
HOWTO.md |
Step-by-step: build, run, interpret, report findings |
CONFIGURATION.md |
CLI reference, recommended configs for different hardware |
DESIGN.md |
Architecture deep-dive: q-iteration construction, GPU pipeline, comparison vs v15 |
BUGS_AND_LESSONS.md |
Postmortems on bugs we hit so you can avoid them |
LICENSE |
Apache-2.0 |
Makefile |
make -j produces bin/cc20_first_kind_immune_v16 |
cc20_first_kind_immune_v16.cu |
The engine. ~5300 lines, CUDA + GMP |
pools/ |
Fingerprint pool files (text, human-readable) |
scripts/ |
Pool generators + the production wrapper run_cc20_hunter.sh |
tools/snapshot_replay.py |
External-prefix structural validator |
data/ |
Fetch script + README for the CC10+ root snapshot. The CSV itself lives in the cunningham-chain-data release; only needed if you want to regenerate pools or run snapshot_replay.py |
examples/ |
One-command tmux launchers for each pool size — read this first |
Pools can share fingerprints. For example, known_fingerprints_top10.txt
is a subset of known_fingerprints_exp_d.txt, and a chain root has many
variants (D_V) framing it — so the same chain is in principle
reachable from more than one pool.
Recommended default: single-seed sequential. Put one fingerprint in
your pool file and run --q-order sequential. The single variant gets
the full GPU bandwidth (~160 G(Q,V)/s on RTX 5090), the Q-walk is
deterministic and resumable, and you can launch as many parallel
campaigns as you want — each on a different fingerprint — with zero
overlap. The engine emits a WARNING at startup if it detects
deterministic Q coverage across multiple variants, since that combination
is the only one that can re-cover the same primes across concurrent
runs.
Multi-seed broad campaigns (--seed-pool-file
known_fingerprints_exp_d.txt, _all.txt, etc.) are also safe — but
only under --q-order random with the default --q-seed 0
(auto-seeded from /dev/urandom). Each run draws an independent
Q-sequence, so overlap with concurrent runs is probabilistically
negligible. Avoid --q-order sequential or --q-band-mode exhaustive
on multi-seed pools unless you are running a single campaign per pool
or your pools are disjoint. See
CONFIGURATION.md
for the trap table.
Experimental. This is research code under active iteration. The default configuration finds chains; specific parameters and even the file/binary basename may change between commits.