How Krackpot works: secp256k1, SHA-256 and RIPEMD-160 in WebGPU

%E2%82%BF">

Skip to content

← Back to the search<br>TECHNICAL WRITE-UP

How Krackpot works: secp256k1, SHA-256 and RIPEMD-160 in WebGPU

By Simon Males

Deep dive

~7 min read

Krackpot points your GPU at Bitcoin Puzzle 71, a wallet whose creator funded it on purpose in 2015 as a public, solvable challenge. The search runs in your browser through WebGPU. No install, no signup, no backend. This page covers how I built it, and it is honest about the odds, because the odds are the whole story.

Where this came from

For years I wanted to build a small educational tool that made one abstract idea concrete: how fast a weak password falls. Type four characters, watch a dictionary run or a brute-force sweep tear through it in seconds.

That idea turned into a browser project I never released. A password cracker for legacy ZipCrypto files, the old and weak ZIP encryption, the kind of thing you would reach for to recover your own locked archive. I built it mostly to race the same brute force against itself across three engines: WebGPU, WebAssembly, and plain Web Workers. The GPU version was the one worth keeping. Then it sat in a folder.

Krackpot is where that WebGPU brute-force engine finally went somewhere. I pointed it at a Bitcoin key instead of a password. The same machine that shreds a four-character password in seconds cannot make a dent in a real 256-bit key. Puzzle 71 lives in a keyspace of 270, and as the next section shows, a single GPU would take roughly a million years to expect a hit. My "how fast do passwords fall" demo became its own opposite: a wall that brute force never climbs.

The odds first

Han Solo said "never tell me the odds." I am going to tell you the odds.

Puzzle 71's key sits somewhere in a range of 270 keys, about 1.18 sextillion. A GPU that checks tens of millions of keys a second still needs hundreds of thousands of years, on average, to sweep that range. These rates come from the live app, not from FLOPS math:

MEASURED IN-APPMEDIAN TO SWEEP 2⁷⁰

RTX 4070~44M keys/sec~430,000 yrs

RTX 3070~22.5M keys/sec~830,000 yrs

Apple M3 Max~26M keys/sec~720,000 yrs

MacBook Air M1~5.95M keys/sec~3,100,000 yrs

These figures are the uniform-sweep midpoint (half the range divided by the rate). Krackpot actually draws chunks at random with replacement, so time-to-find is geometric: the true median is about ln2 times the full-range mean, roughly 1.4x these numbers, and the same order of magnitude either way.

So it is a lottery. One machine will almost certainly never win. A million machines searching at once pulls the median down to about a year. I say this everywhere on the site, because in crypto the fastest way to look like a scam is to be shy about the math.

The pipeline

A Bitcoin address is the end of a one-way chain, and Krackpot runs that whole chain on the GPU for each candidate key:

Private key: a 256-bit integer k.

Public key: the curve point k * G on secp256k1, in compressed form (a 0x02/0x03 prefix byte plus the 32-byte X coordinate).

SHA-256 of the 33-byte compressed public key.

RIPEMD-160 of that SHA-256 digest. The 20-byte result is the public key hash (PKH).

Compare the PKH against the puzzle address's decoded PKH. A match is a solved key.

None of those primitives ship with WGSL, the WebGPU shading language, so each had to be built up from 32-bit integers. I did not write this crypto by hand. It is LLM-assisted, and I lean on the deterministic test vectors below to trust it, not on having personally typed every carry.

256-bit math on a 32-bit machine

WGSL has no big integers. You get 32-bit unsigned integers and little else. So a 256-bit field element becomes eight u32 limbs, and every add, multiply, and reduction modulo the secp256k1 prime is spelled out limb by limb, with the carries propagated explicitly. Elliptic-curve point arithmetic sits on top of that, and the two hash functions on top of their own 32-bit word operations. One wrong bit anywhere and the search still runs, still looks busy, and checks the wrong keys forever. The test suite further down exists precisely because that failure is invisible.

The speed trick: no full scalar multiply per key

The obvious version computes k * G for every candidate. That is roughly 256 doublings and 128 additions per key, and it would drop throughput by 50 to 100 times. Krackpot never does it in the hot loop.

Within a chunk the candidate keys run in sequence: k, k+1, k+2. Their public keys run P, P+G, P+2G. Adding G is a single point addition, far cheaper than a fresh scalar multiply, so the search leans on that:

The CPU computes the chunk's base public key P = k * G once per chunk, in JavaScript, and uploads it.

Each GPU thread owns a slice of consecutive keys. It jumps to the start of its slice with a small precomputed table of multiples of G (22 entries, so a few additions get it there), then walks the slice at one point addition per key.

That drops...