Vanitygen is a command-line tool that helps you generate customized bitcoin addresses.
If you're fed up with the random and confusing addresses that normal bitcoin clients spit out, vanitygen lets you craft a more unique address. Imagine telling someone to send bitcoins to 1stDownqyMHHqnDPRSfiZ5GXJ8Gk9dbjL instead of some gibberish. Plus, it also allows you to create random addresses without being online.
You just input a pattern or a list of patterns you want, and it gives you a list of addresses along with matching private keys. Keep in mind, it works in a probabilistic way; how long it takes to find a specific pattern depends on how complex the pattern is, the speed of your computer, and a bit of luck.
Here's a quick example of how a session on vanitygen looks. It took about 10 seconds to complete on my Core 2 Duo E6600 CPU running x86-64 Linux.
Vanitygen can search for addresses using both your CPU (vanitygen) and your OpenCL-compatible GPU (oclvanitygen). You can compile both from source, and they come included in the Windows package too. There's also oclvanityminer, the mining client for vanity addresses, which can help you automatically claim rewards on sites like ThePiachu's vanity pool.
Current version: 0.22
Get the Windows x86 and x64 binaries here. PGP signature is available as well.
You can grab the source code from GitHub, which comes with Makefiles for Linux and Mac OS X.
FAQ
What kind of patterns can vanitygen look for?
Vanitygen can handle simple prefixes or regular expression matches. A prefix is an exact string that needs to show up at the beginning of the address.
I've just pushed a bugfix, and can't reproduce the problem now. Could you try again?
PS: yes, it's quite normal your code is a lot faster - the vanity patch just tried generating random keys until a match was found, requiring generating 256 random bits + an EC multiplication per attempt. Your code only needs an EC addition per attempt.
It uses linux time() (measured in seconds) and process PID when EC_KEY_generate_key() is invoked.
I suppose its standard behavior of programs based on OpenSSL.
EC_KEY_generate_key() adds entropy (based on time()) every 1000000 keys or so.
Basically private key (integer) starts from random number and increases for 1000000 keys.
Then new entropy added and new private key generated.
Should be secure after first iteration (1M).
I have a system with 2 CPUs. According to the CPU usage applet, the original bitcoind + vanity patch uses both CPUs, but vanitygen seem to use only one.
Unfortunately I'm unable to provide a fix, sorry.
Hi,
great job! I am still running that bash script for a couple of days and it hasn't found a simple ^1Abcd type of address yet.
Thanks a bunch for this!!! At first I was unable to compile the source, but I found out which package to install for PCRE support: libpcre3 and libpcre3-dev.
It's testing away now with 10,000 keypairs a second. Wow, this really could get me hooked on trying out OpenCL coding, if only I had the time...
This method sucks! Snuff the weak source of entropy is the favourite side attack for a half-skilled hacker.
Use at least /dev/random And consider pick random bits from hotbits and random.org.
Would you be more inclined to use this program if it had a command line option to initialize private keys from /dev/random, or one of those network sources, instead of using the OpenSSL default mechanism? I'm more than happy to add it or apply a patch if it will make you feel safer about using the generated keys.
I think the generate_address_regex() function is broken. Looks like &b58[p] is calculated incorrectly.
I stuck a printf right before output_match() is called:
./vanitygen -r 1.{26}XX
Before output_match: 1H6d1q8niPVvci5zGnpbTkRfaBhWhWSXX5
After output_match: 1H6d1q8niPVvci5zGnpbTkRfaBhWhXcbEn
The address that the regex is being compared to is never a valid address, and the (valid) end address always differs in the last few characters.
Took me the longest time to figure out this was why all my regexes with $ in it behaved ... unexpectedly.
try "vanitygen -r [Ww]iLL"
(no need to use [Ii] and/or [Ll] because l (small L) and I are not in base58, I think.
EDIT: found one in seconds: 1NZED7AR8hbwiLLkTWwXgZvM89FZqFiXnj
maybe I found a bug, or maybe I'm using regex wrongly:
"./vanitygen/vanitygen -r [Mm]oL[Ee][Cc]" gave me 1H3fttgZCe89zhViCRmk7DX8JmoLJ2mvTV (missing "ec")
found 1BYYdM3vfndwmoLec6tQjcx7sAeLRxTvTq with the same command
Yep, that's a bug! The regular expression search loop incorrectly generates the lower four byte test code.
I'll post a new version in a bit with a fix for that problem.
Thanks for pointing it out.