lotterypuzzle atlas

Tools · compare

Intervals, on a log scale

Candidate keys span 160 binary orders of magnitude, so the charts are logarithmic and every axis is named with its unit. Each chart has a table equivalent with the exact values — the chart is a picture of the table, not a substitute for it. No chart library, no vendor numbers, no invented benchmarks.

Quick comparison

Odd widths are kept exact.

A vs B

Gap

B is larger by 89 binary orders (×289) in search space.

A · search space
270 candidate keys (1,180,591,620,717,411,303,424)
A · median scan
median scan position ≈ 269
A · containment (w)
20 = 1 (window covers the interval)
A · class
open — address only
B · search space
2159 candidate keys (730,750,818,665,451,459,101,842,416,358,141,509,827,966,271,488)
B · median scan
median scan position ≈ 2158
B · containment (w)
2−63 = 1.08×10−19 (1 in 9,223,372,036,854,775,808)
B · class
open — public key known
Same-window work
A 96-bit window costs ≈ 249 group operations (about 5.63×1014) with the generic 2·√N heuristic — the same for A and B, because window work depends on w, not on the puzzle size. Finishing that budget is not enumeration of the window.

Candidate keys across reference puzzles

  • open — address only
  • open — public key known
  • historical (solved)
Axis: log₂(candidate keys) = search bits — bar length is proportional to the number of search bits (0 to 159). Values are exact powers of two: puzzle N has 2N−1 candidates. Puzzle #1 has a single candidate, so its bar has zero length on this scale. Colour: orange is open, address only; blue is open, public key known; slate is historical (solved).
Exact values, same order as the chart
Puzzle Scalar bits Search bits Candidate keys (exact) Nominal reward (BTC) Class
#1 1 0 20 0.1 historical (solved)
#32 32 31 231 3.2 historical (solved)
#50 50 49 249 5 historical (solved)
#65 65 64 264 6.5 historical (solved)
#71 71 70 270 7.1 open — address only
#80 80 79 279 8 historical (solved)
#100 100 99 299 10 historical (solved)
#120 120 119 2119 12 historical (solved)
#135 135 134 2134 13.5 historical (solved)
#140 140 139 2139 14 open — public key known
#160 160 159 2159 16 open — public key known

Containment of a fixed 96-bit window

  • open — public key known
Axis: log₂(containment) in bits — bar length is proportional to how many halving steps the probability is away from 1 (0 to −63). A 96-bit window inside a much larger interval holds 296 − (N−1) of the keys; the same window costs the same work everywhere, but containment shrinks fast as the interval grows.
96-bit window containment per public-key target (exact)
Target Window Containment exponent Containment odds
#140 96 bits 2−43 1 in 8,796,093,022,208
#145 96 bits 2−48 1 in 281,474,976,710,656
#150 96 bits 2−53 1 in 9,007,199,254,740,992
#155 96 bits 2−58 1 in 288,230,376,151,711,744
#160 96 bits 2−63 1 in 9,223,372,036,854,775,808

How to compare fairly

Named axes, exact units.

Candidate keys are counted in exact powers of two; containment is expressed in halving bits and as exact odds; work is quoted in group operations for a stated w. Nothing is smoothed or scaled to look dramatic.

Work is not one number.

Window work depends on w (and on the method constant), not on the puzzle's size. The number of windows a budget buys depends on that work and on the budget — not on which puzzle you pointed the window at. Containment does depend on the puzzle size and is shown separately.

No fake benchmarks.

There are no throughput rows, no cost-per-key estimates and no vendor comparisons here. Rates belong to the tool user, not to the chart.