What is the Bitcoin puzzle?
In January 2015 someone sent small amounts of bitcoin to 256 addresses whose private keys were deliberately restricted to increasingly large ranges. It was, in the creator’s own later description, a crude measuring instrument for the state of the art in key search. A decade on it is still running, and still unsolved past a certain point.
The transaction that started it
On 15 January 2015 a single Bitcoin transaction sent small, precisely graduated amounts to 256 freshly created addresses. The first address received 1 satoshi times a tiny multiplier, the next slightly more, and so on up the list. What made the transaction remarkable was not the money — the total was around 32 BTC — but the private keys behind those addresses. They were not random. Key number one was 1. Key number two was somewhere in the two-value range 2 to 3. Key number ten lay somewhere among 512 possibilities. Key number 160 lay somewhere among roughly 7.3 × 10^47.
The creator stayed quiet for two years, then posted an explanation on Bitcointalk in 2017. There was no hidden message and no clever trick; the addresses were, in their words, a way of watching how far the community could push key search over time. Anyone could measure progress simply by noting which puzzle had most recently fallen.
Why the ranges double
The structure is the whole point. Puzzle #n confines its key to the interval from 2^(n−1) to 2^n−1, so each puzzle contains exactly twice as many candidate keys as the one before it. That gives a clean logarithmic difficulty scale: solving puzzle #66 rather than #65 represents exactly one additional bit of search capability, no matter what hardware or algorithm you used to get there.
It also produces a brutal wall. The jump from #70 to #80 is a factor of 1,024. The jump from #70 to #100 is a factor of about 1.07 billion. Rewards, by contrast, were set to rise roughly in proportion to the puzzle number — #71 holds 7.1 BTC, #160 holds 16 BTC — so the reward per unit of work collapses as you climb. The economically rational target is always the smallest unsolved puzzle, which is why #71 attracts nearly all the attention.
What has actually been solved
Puzzles 1 through 70 have all fallen, along with #75, #80, #85, #90, #95, #100, #105, #110, #115, #120, #125 and #130. That last group is unusual: those addresses had spent transactions at some point, which exposed their public keys, and an exposed public key changes the problem completely. Instead of brute-forcing the key space, a solver can run Pollard's Kangaroo algorithm and finish in roughly the square root of the work — turning a 2^129 problem into something closer to 2^65. That is why puzzles in the hundreds were solved while #71 was not.
The remaining 78 puzzles have never spent, so only their public key hashes are known. For those, no square-root shortcut exists. Brute force over the full range is the only published approach.
What the solver on this site does
The engine derives, for each candidate private key k in the chosen range, the public key k·G on the secp256k1 curve, compresses it to 33 bytes, and computes RIPEMD-160(SHA-256(pubkey)). If those twenty bytes equal the puzzle address's HASH160, k is the answer.
Doing that naively means one full scalar multiplication per key — around 256 point doublings and additions, each involving a modular inversion. The optimisation that makes a browser solver viable is to do a single scalar multiplication when entering a range, then move through the range by repeatedly adding precomputed multiples of G. Point addition still needs a modular inverse, but Montgomery's batch inversion trick converts 4,096 separate inversions into one inversion plus three multiplications each. Combined with SHA-256 and RIPEMD-160 routines specialised to their exact fixed-size input and written to allocate nothing, the per-key cost drops to about 1.6 microseconds — roughly a hundred times faster than the obvious implementation.
A note on expectations
None of that engineering changes the fundamental picture. Half a million keys per second per core is a good number for JavaScript and a meaningless number against 2^70. The honest reason to run this solver is that it makes an abstract difficulty concrete: you can watch the counter climb, watch the percentage of the range covered stay pinned at zero, and develop an intuition for exponential scale that no amount of reading provides.