k ∈ [2N−1, 2N)
Bitcoin
Puzzle Series.
The lower and mid-tier puzzles (like #64 down to #1) have been completely swept by crowdsourced brute-force arrays. Higher-level puzzles remain active targets that require massive parallel computing grids to slowly chip away at. Private key for puzzle N is always in the half-open interval [2N−1, 2N).
YOUR CONTRIBUTION
IDLE
Puzzle workbench
Pubkey-exposed targets reveal a compressed public key. Generic discrete-log methods can reduce the expected work to roughly the square root of the published keyspace; this browser workbench still uses sequential key derivation.
GPU / hybrid uses an aggressive multi-worker pool when WebGPU is present. secp256k1 stays on the CPU (incremental point addition + hash160). Native CUDA/OpenCL key search remains far faster for production grinding.
Idle. No browser computation is active.
No range assigned
0 keys
BATCH TIME—
KEYS / SEC—
LOCAL SCANS0
MATCHES0
Trust boundary: workers derive compressed hash160 values via incremental secp256k1 addition and compare them locally to the target. A match is a cryptographic fact you can re-verify offline. High-bit puzzles remain infeasible in the browser; specialized GPU tools (BitCrack, KeyHunt, etc.) and discrete-log solvers for pubkey-exposed targets are required for realistic progress.
PUBKEY-EXPOSED TARGETS
5 puzzles with published compressed public keys
Pubkey-exposed puzzles come first because their published key material permits generic discrete-log methods. Each row states the full private-key search space and, where applicable, the square-root generic estimate.
| # | Address | Key range | Search-space complexity | Balance (approx.) |
|---|
Optimized sequential search
Private key for puzzle N lies in [2N−1, 2N). Workers perform one full scalar multiplication at the start of each micro-batch, then walk the range with cheap +G point additions. Only hash160 is compared (no Base58 per key). Multiple Web Workers partition the range in parallel.
Pubkey-exposed targets
Puzzles 140, 145, 150, 155 and 160 revealed compressed public keys via partial spends. These admit discrete-log algorithms that are asymptotically faster than pure brute force. The browser workbench still runs sequential derivation for demonstration; production solvers should use dedicated discrete-log tools.