Advanced Lesson 4 4 min read

Tools: keyhunt, VanitySearch, and similar ones

What each tool does, on what hardware it runs, and where each one is the right choice.

All key search programs essentially do the same thing. What changes between them is which of the two worlds from Lesson 1 of the previous module they target, what hardware they run on, and how much work has been done to make the arithmetic fast. Knowing the map prevents you from wasting weeks using the wrong tool.

Inside it's the same engine. What changes is the bodywork.

VanitySearch, by French developer Jean-Luc Pons, was created in 2019 for an innocent task: finding addresses that began with a chosen prefix for those who wanted an address starting with their own name. It's an address search tool, runs on graphics cards, and became important for another reason — its code demonstrated, in practice, the optimizations everyone started using: batch inversion and leveraging a symmetry unique to secp256k1 that saves a third of the work.

Kangaroo, by the same author, is the implementation of the method from the previous Lesson 4. It solves discrete logarithms in a known interval, requires the public key, uses distinguished points, and comes with a client-server mode: multiple machines jump and send the distinguished points to a central server that detects the collision. It's the tool that cracked the highest-numbered challenges.

Keyhunt, by the developer known as albertobsd, is the Swiss army knife of the subject. It runs on a processor, and what makes it useful is the number of modes: address search, public key search, hash search, and a practical implementation of the baby-step giant-step method. It's the right tool when you want to test millions of targets at the same time, not just one.

BitCrack is older and more straightforward: brute force over intervals, on a graphics card, looking for addresses. It remains in use because it's simple to operate.

A paragraph is warranted for the piece that supports searching for many targets at once, because it's ingenious. Comparing each candidate with ten million addresses would require ten million comparisons; the solution is a Bloom filter, a structure that responds very quickly and with a useful asymmetry. When it says the candidate is not on the list, it's absolutely certain. When it says it might be, you need to check for real — and this happens so rarely that the cost disappears.

The sieve never says yes. It says no, quickly, and the rest is examined manually.

Regarding performance, three warnings to avoid disappointment. The announced numbers are not comparable between modes: keys per second in an address search, jumps per second in a kangaroo, and comparisons per second against a loaded list are different magnitudes. Much of the gain of one tool over another comes from the filter, not the calculation. And real performance depends heavily on the card, the compiler, and the parameters — the same program can vary by a factor of ten between two configurations.

Finally, the most important warning. These tools manipulate private keys, and a precompiled version downloaded from an unknown source can do exactly what it promises and, at the same time, send the found key elsewhere. It has happened. The rule is simple: use open source code, read what you can, compile it yourself, and run the search on a machine that stores nothing else.

The tool someone has already compiled for you may have been compiled for them.

And the rule stated in the previous lesson still applies here, because it's what separates exercise from crime: searching for keys of addresses published as challenges is legitimate because whoever put the money there did so to be found. Pointing the same tools at other people's wallets is another matter, and it's not a technical issue.

You have completed the entire course: from barter to the white paper, from key to signature, from seed to node, from curve to kangaroo. Only one more round remains — how a challenge is born, verified, and paid on this platform. In the next lesson, the last one.