lotterypuzzle atlas

Tools · probability & EV

What is this budget worth?

A hypothetical scenario, not a prediction: enter a compute budget, a rate, a cost and a price, and read the hit probability and expected value back. Solved puzzles are rejected — this tool models open targets only. You enter every number; the tool only does the arithmetic: no live rewards, no live prices, no measured benchmarks.

Inputs (hypothetical)

Method

Solved records are rejected: their key material is already public, so there is nothing left to find.

No live quote is used; the prize is the catalog's nominal allocation × this number.

Distinct candidates scanned per second — each one is turned into a point and hashed (one HASH160 per candidate). Your own figure, not a benchmark.

Odd widths keep a half-bit in the work estimate (w=97 → 249.5 group operations). The window is placed at a uniformly random offset unless you state otherwise.

Your disclosed assumption about the solver, not the containment probability. 1 means "assume a contained key is found by the budgeted run".

Elliptic-curve group operations per second on your hardware — a different unit from scanned candidate keys. No benchmark is supplied.

Session result

Expected value

−$9.98

Negative expected value: the session costs more than the chance is worth at these inputs.

Target
#71 · 7.1 BTC nominal · open — address only
P(success this session)
3.05×10−8
Odds
1 in 32,794,212
Cost
$10
Prize at your price
$710.00 k (7.1 BTC nominal × your price)

Scan detail

Scanned
3.60×1013 candidate keys scanned
Two models
Uniform without replacement: 3.05×10−8 of the interval is covered. With replacement the same budget gives 3.05×10−8.
Expectations
Without replacement: expected (and median) trials (N+1)/2 = 269 ≈ 5.90×1020; 90% quantile of that uniform position 1.06×1021. With replacement the mean is N = 270 (geometric waiting time) — not the same median.

Model: the key sits at a uniform random position in the interval; scanned candidates are distinct; a hit ends the run. The result is the chance this budget finds the key — it is not progress, and the nominal reward is a catalog allocation, not a market price.

Assumptions, stated up front

Uniform position.

The key is assumed to sit at a uniform random position in the interval. Without a verified position, that is the honest default — and it means the result is a probability, never a schedule.

Two scan models, different numbers.

Scanning distinct candidates without replacement has expected first hit at (N+1)/2 (that is also the median); independent random picks with replacement have expectation N (the mean of a geometric waiting time, whose median is about ln(2)·N). The tool shows both instead of quietly picking the flattering one.

Containment ≠ conditional success.

Containment answers "was the key inside the window?". Solver success given containment is an assumption you supply and it is displayed separately. Finishing a run is not proof that the key was in the window.

A finished window budget is not enumeration.

Hitting the heuristic group-op count is a probabilistic walk, not a certificate that every key in the window was visited. Completing a bounded run remains probabilistic.

Units are not interchangeable.

Candidate throughput (keys hashed per second) and group operations per second belong to different methods; the fields and the results label which one is in play.

Nominal, not live.

The prize is the catalog's nominal allocation × your BTC price. It is not a balance, not a market offer, and no exchange rate is fetched. Costs ignore fees, downtime, variant rewards and the chance that someone else finds the key first.

Stable tiny arithmetic.

Repeated-window probabilities are computed with log1p/expm1, so a 1-in-1013 chance stays 1-in-1013 instead of rounding to zero, and invalid input returns an error rather than NaN or Infinity.

Solved puzzles rejected.

Entering a solved record is an error here: its key is public history, and pretending to model finding it again would only decorate a fantasy.