Bitcoin Opinion · September 8, 2026

What a Brute-Force Key Checker Taught Me About Bitcoin

This site pages through Bitcoin's actual private key space and checks each one, live, for a balance. Not a simulation, not a mockup: real keys, real addresses, real balance lookups against the network. I built it, and I still find the numbers difficult to hold in my head. Not because the tool is clever. Because of what it accidentally demonstrates every time someone loads a page.

The number itself

A Bitcoin private key is a number less than the order of the secp256k1 curve, which works out to roughly 1.16 × 10⁷⁷, near enough to 2²⁵⁶ that the difference doesn't matter for anything a human needs to reason about. People reach for the "more private keys than atoms" line to make that number feel real, and it's worth being precise about which atoms, because the common version of that comparison is actually wrong. The observable universe is estimated to hold something like 10⁸⁰ atoms, which is *more* than Bitcoin's keyspace, not less. The comparison that actually holds up is Earth specifically: roughly 1.3 × 10⁵⁰ atoms, by current estimates. Divide one into the other and Bitcoin's keyspace comes out to somewhere around 10²⁷ times the number of atoms on this planet. Still absurd. Just a different, more defensible kind of absurd.

What that number actually means for brute force

Here's a hypothetical worth running the actual arithmetic on rather than waving at. Say you could check a billion keys a second, sustained, forever, starting today. Run that for five billion years, roughly the time our sun has left before it swells into a red giant, and you'd have checked on the order of 1.6 × 10²⁶ keys. Against a keyspace of 1.16 × 10⁷⁷, that leaves you having sampled something like one part in 10 ⁵¹ of the total space. You would not be close. You would not be measurably closer than not having started. This is the number this site exists to make visible, one page of fifty real keys at a time, and it's also the reason nobody needs to worry about a hobbyist script, or a well-funded adversary, or frankly any conceivable amount of computing power stumbling onto a funded key by chance.

The part that actually broke

For a while, this site supported Ethereum and Solana too, same idea, different chains, separate journeys through each one's keyspace. The cryptography behind all three has never shown so much as a hairline crack in real-world use. What broke, almost immediately, was the infrastructure around it. Ethereum's balance lookups started hitting rate limits fast enough that we had to cut the number of addresses shown per page just to keep pages loading reliably. Solana's public RPC endpoint didn't even bother with a soft rate limit, it returned a hard 403 on nearly every request once real traffic hit it, blocking the exact pattern of use its own documentation warns it's not built for. Both are shared, free, publicly-run pieces of infrastructure straining under ordinary curiosity from a few thousand visitors. Not an attack. Not anything resembling one. Just people clicking a button.

We ended up pulling both and going back to Bitcoin only, partly for simplicity, but mostly because the contrast was too on-the-nose to ignore. A public API serving free balance lookups couldn't survive a page of curious visitors without falling over. The 256-bit curve underneath it has survived sixteen years of every incentive imaginable to break it, at a scale of attention and money that dwarfs anything a small crypto tool could throw at a rate limiter.

A different kind of computing power, for scale

It's worth separating two things that get conflated constantly: Bitcoin mining and private key recovery are not the same math problem. Mining repeatedly hashes a block header with SHA-256 looking for an output below a target value. Recovering a private key from an address means solving the elliptic curve discrete logarithm problem on secp256k1, a fundamentally different and vastly more expensive operation per attempt. But the mining number is still a useful way to gesture at the scale of real computing power already pointed at Bitcoin: as of early September 2026, the network's total hashrate sits above 900 exahashes per second, on the order of 10²¹ hashes every second, sustained, worldwide, continuously, for going on seventeen years.

Even granting that number a wildly generous benefit of the doubt, pretending for a moment that checking a private key costs no more than a single hash (it costs dramatically more), and redirecting the entire global mining industry toward brute-forcing keys instead of mining blocks, running that for the five billion years the sun has left would produce somewhere around 1.6 × 10³⁸ attempts. Against a keyspace of 1.16 × 10 ⁷⁷, that covers roughly one part in 10³⁸ of the total space. The real number, accounting for how much more expensive an actual elliptic curve operation is than a hash, is smaller than that by more orders of magnitude than I want to try to estimate precisely here. Either way, the entire Bitcoin mining industry, repurposed for this single task and running past the death of the sun, doesn't meaningfully dent the problem.

The keys that actually did get stolen

None of this means Bitcoin's real-world security record is spotless, and it's worth being specific about the one category of incident that actually happened, because it illustrates the point better than any hypothetical. In August 2013, a flaw was discovered in Android's implementation of Java's SecureRandom function, the component responsible for generating the random values Bitcoin's signing process depends on. Every Bitcoin app that generated addresses on an affected Android device was exposed, including several widely used wallets at the time. The failure wasn't that anyone brute-forced a private key out of the full keyspace. It was that the signing process, for some affected wallets, reused the same random value across more than one transaction, and reusing that value in ECDSA is enough to let someone solve directly for the private key using nothing more than two signatures. Bitcoin's developers issued a public alert, wallets pushed emergency fixes, and community estimates at the time put the confirmed losses around 55.82 BTC. Small in absolute terms even by 2013 prices, and completely unrelated to the size of the keyspace this site pages through. The math held. The randomness feeding into it, on one specific platform, for a while, didn't.

The one caveat worth being honest about

Everything above is about classical brute force, and classical brute force isn't a threat to Bitcoin's cryptography in any timeframe worth worrying about. Quantum computing is a different problem, and it deserves an honest answer rather than either dismissal or alarmism. Shor's algorithm, run on a sufficiently capable quantum computer, could in theory solve the elliptic curve discrete logarithm problem underlying secp256k1 directly, rather than searching the keyspace at all. That's a fundamentally different kind of attack, and it's the one real long-term question mark over this cryptography. As of 2026, no machine capable of it exists. Current hardware sits at roughly a thousand physical qubits and only tens to about a hundred logical qubits, the more meaningful measure for this kind of computation. A Google Quantum AI paper published in March 2026 meaningfully lowered the estimated bar, down to somewhere under 500,000 physical qubits and 1,200 to 1,450 logical qubits, from estimates in the tens of millions just a few years earlier. That's a real, closing gap, and Bitcoin developers are already discussing migration proposals for quantum-resistant address types in anticipation of it. It's also still a gap measured in orders of magnitude beyond anything that exists today. Worth watching. Not worth confusing with the brute-force question this site actually demonstrates, which isn't closing at all. For the full picture on where that research actually stands, see can quantum computers actually break Bitcoin.

The private key for every Bitcoin wallet on Earth is on this website, even Satoshi's. But even if you try for a million years, you'll never find a funded one.

Try the key collider now

Where the real vulnerability actually sits

None of this means Bitcoin's security model is flawless in every place people assume it is; it means the flawed places are almost never the cryptography itself. Lost keys, phished seed phrases, and compromised exchanges have cost people vastly more than any theoretical attack on secp256k1 ever will. If anything, building this tool made that gap more concrete for me than reading about it ever did: watching a page of fifty random keys come back empty, over and over, key after key, page after page, is a strange way to internalize just how enormous the actual number is. The site works through the keyspace fifty keys at a time, checking each one's compressed and uncompressed address against a live balance lookup, and every single page renders the same way: a table of real addresses, a live check against the network, and a result of zero, every time, because the alternative would require a coincidence on a scale nothing in human experience prepares you to reason about correctly. For more on the practical side of that gap, see keeping your private key safe and whether Bitcoin can actually be hacked.