bitcoinpuzzle.online
How the Bitcoin puzzle works
The puzzle is a deliberately sized search problem. Understanding it means understanding how a Bitcoin private key becomes an address, and why a known range makes some of these keys findable at all.
Private keys and ranges
A Bitcoin private key is just a very large integer — up to about 2^256. Normally a key is drawn uniformly from that whole space, which is why guessing one is impossible. The puzzle's creator instead chose keys from small, known ranges: puzzle #n has its key between 2^(n−1) and 2^n − 1. So puzzle #71's key is a 71-bit number: somewhere in a range of about 2^70 possibilities. The range is public; the exact key is not.
From key to address
To check whether a candidate key is the answer, you derive its address and compare. The chain is: multiply the key by the secp256k1 generator point to get a public key, compress that point to 33 bytes, take SHA-256 then RIPEMD-160 of it (together called "hash160"), and Base58Check-encode the result into the familiar address starting with "1". Two keys give the same address only if they are the same key, so matching the address means you found it.
Why address-only puzzles need brute force
For most unsolved puzzles only the address is visible on-chain — the public key has never been revealed, because the address holds hash160(public key), not the key itself. That matters because the fast key-finding algorithms (Pollard's kangaroo, baby-step giant-step) need the public key to work. Without it, the only option is to generate candidate keys and hash each one — pure search. A handful of puzzles (every fifth one above 70, those that once sent a transaction) did expose their public keys, and those are attacked with kangaroo methods instead.
Making the search fast
Naively, each candidate key needs a full elliptic-curve multiplication, which is expensive. The efficient trick is to walk through consecutive keys by repeatedly adding the generator point instead of multiplying from scratch, and to batch the costly modular inversions using Montgomery's trick so that hundreds of points share one inversion. Our scanner does exactly this in a secp256k1 engine compiled to WebAssembly, then computes hash160 for each candidate — reaching millions of keys per second per machine.
The odds, honestly
Speed does not make the puzzle easy. Puzzle #71's range holds about 2^70 keys; at five million keys per second, sweeping all of them would take far longer than the age of the universe. Searching is really buying lottery tickets: each key checked is one more ticket, and the ticket count you can afford per second is what throughput buys you. People who cracked higher puzzles used large GPU/FPGA clusters and still got lucky. That is the honest framing — this is a superb way to learn applied cryptography, not a way to make money.