Estimate recovery time without inventing a success rate

Two measurements, two different jobs

The size of your candidate set and the rate at which your setup checks that set determine a rough exhaustive runtime. A candidate preview using --listpass measures generation behavior; it does not measure the expensive wallet verification step. Our candidate-lab counts therefore cannot be used as a wallet benchmark.

Use the upstream benchmark documentation and GPU support notes for your specific workflow. A speed from another wallet format, a different derivation range or another computer is not automatically transferable.

The simplest runtime model

With N candidates and a sustained rate r candidates per second, exhaustive runtime is approximately N/r seconds. For 1,000,000 candidates at an assumed 100 checks/second, that is 10,000 seconds, or about 2 hours 47 minutes. This is an illustrative calculation, not a measured BTCRecover benchmark.

The search-space calculator lets you change independent fixed-position choice counts and an optional rate. It deliberately does not attempt to simulate arbitrary tokenlist permutations, overlapping typo rules or seed derivation work.

When halfway is misleading

“Half the exhaustive time on average” assumes exactly one matching candidate exists, its position is uniformly distributed and the checking rate is stable. Those assumptions rarely describe the full uncertainty of a real recovery. If the right password is missing from the candidate set, completing the search will not recover it at any speed.

Prioritized guesses also violate the uniform-position assumption. A carefully ordered search can find a likely guess early, but there is no justified numerical success probability without evidence about the candidate distribution. This website does not assign one.

What to record with a benchmark

• BTCRecover commit, Python version and relevant dependencies.
• Wallet format and the exact checking mode.
• CPU/GPU model, worker count and acceleration settings.
• Candidate rules, duplicate handling and address range when applicable.
• Observed steady checking rate and how long it was observed.

Keep wallet-specific details private. Compare one change at a time and distinguish startup/counting time from steady checking. A published benchmark should say whether it used synthetic or actual wallet data; never include private wallet material.

Correctness comes before acceleration

Start with a tiny controlled search whose expected behavior is known. Verify support for your wallet and chosen backend, then consider acceleration. Increasing hardware spend before checking coverage can make the wrong search finish faster without improving the chance of a match.