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).
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.
This key is shown only in your browser. It is never sent to MathGrinder's servers and is never logged or persisted anywhere.
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.
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.