Vanitygen: Vanity bitcoin address generator/miner [v0.22]

[BurtW]

Cool, so you did throw out all checksums that contained numbers and lower case characters, just like I said AND you are correct, there is no real difference between selection made on the address hash itself and the checksum.

You just selected an address with all capital letters - looks great!

[Remember remember the 5th of November]

Are there any reasons why GCC from mingw was not used for this?

With a few hacks, it compiled flawlessly under MinGW-w64

[1QaZxSw2]

Anyone tell me how to generate LTC vanity addresses?

-X 48 does not seem to work.



$ ./vanitygen -X 48 L1QaZ
Prefix 'L1QaZ' not possible
Hint: valid bitcoin addresses begin with "1"

[BurtW]

Anyone tell me how to generate LTC vanity addresses?

-X 48 does not seem to work.



$ ./vanitygen -X 48 L1QaZ
Prefix 'L1QaZ' not possible
Hint: valid bitcoin addresses begin with "1"

AFAIK vanitygen only does namecoin, testnet or bitcoin.  Could be wrong though

[terrytibbs]

Anyone tell me how to generate LTC vanity addresses?

-X 48 does not seem to work.



$ ./vanitygen -X 48 L1QaZ
Prefix 'L1QaZ' not possible
Hint: valid bitcoin addresses begin with "1"

It works, it's just that the address versioning doesn't allow certain characters.

[coblee]

Anyone tell me how to generate LTC vanity addresses?

-X 48 does not seem to work.



$ ./vanitygen -X 48 L1QaZ
Prefix 'L1QaZ' not possible
Hint: valid bitcoin addresses begin with "1"

It works, it's just that the address versioning doesn't allow certain characters.

That's right. Litecoin addresses go from "LK..." to "Li..."
So 1 is not valid for the second character.

[1QaZxSw2]

Anyone tell me how to generate LTC vanity addresses?

-X 48 does not seem to work.



$ ./vanitygen -X 48 L1QaZ
Prefix 'L1QaZ' not possible
Hint: valid bitcoin addresses begin with "1"

It works, it's just that the address versioning doesn't allow certain characters.

That's right. Litecoin addresses go from "LK..." to "Li..."
So 1 is not valid for the second character.

Cool... thanks so much.

[gmaxwell]

Vanitygen is a command-line vanity bitcoin address generator.

I haven't seen any mention of compressed pubkey support.

The latest versions of Bitcoin (perhaps just git, so .6 post but I'm not going to bother checking) will default to creating addresses based on compressed public keys.

These addresses look just like every other address but they take up less space in the blockchain when you spend from them (and thus lower txn fees in the long run).

Every private key has two possible addresses. One based on the compressed public key, one based on the regular public key.   It takes a bit more computation on top of the normal public key generation to get the compressed version.

It would probably be a good idea for vanitygen to offer / default to generating compressed public keys.

Have I missed discussion related to this?

[SgtSpike]

Vanitygen is a command-line vanity bitcoin address generator.

I haven't seen any mention of compressed pubkey support.

The latest versions of Bitcoin (perhaps just git, so .6 post but I'm not going to bother checking) will default to creating addresses based on compressed public keys.

These addresses look just like every other address but they take up less space in the blockchain when you spend from them (and thus lower txn fees in the long run).

Every private key has two possible addresses. One based on the compressed public key, one based on the regular public key.   It takes a bit more computation on top of the normal public key generation to get the compressed version.

It would probably be a good idea for vanitygen to offer / default to generating compressed public keys.

Have I missed discussion related to this?

I'm confused... if the compressed portion is a "behind the scenes" address, why does it need to be generated?  All you need from vanity gen is the Bitcoin address and the private key associated with it.

[BurtW]

Because the public vanity address is the hash of the public key.  If the public key is in a different format then the hash of the public key (the vanity address) would be different.

[SgtSpike]

Because the public vanity address is the hash of the public key.  If the public key is in a different format then the hash of the public key (the vanity address) would be different.

Got it.

Regardless, the new client will still accept older uncompressed public keys, so why bother making the change to vanity gen?  Unless you're trying to "do your part" in helping keep the blockchain as short as it can be...

[lilfiend]

Any chance on a version of this for Litecoin?

[terrytibbs]

Any chance on a version of this for Litecoin?

-X 48

[lilfiend]

Any chance on a version of this for Litecoin?

-X 48

thanks! (was actually reading a few pages before and saw that i missed, it... oops... 

[gmaxwell]

Regardless, the new client will still accept older uncompressed public keys, so why bother making the change to vanity gen?  Unless you're trying to "do your part" in helping keep the blockchain as short as it can be...

Reducing your pubkey sizes will also reduce what you pay in transaction fees when you spend coins sent to those addresses— and potentially it could make vanitygen faster due to having two tries for every private key.

[BurtW]

it could make vanitygen faster due to having two tries for every private key

I think this is a very good reason to implement it into vanitygen.

[The00Dustin]

I am having trouble building this on F15.  I don't have a lot of build experience, but I have done some searching and troubleshooting to make some progress (I also searched this thread, but did not read it in its entirety since it seems to be mostly discussion about the program in its already compiled form).  At this point I am not sure what I need to do and would like to either get some advice or at least information on dependency versions if I'm using the wrong ones.  Note that I also had to learn how to use git to even begin to do this, and I have been deleting and re-cloning vanitygen.git between each step.  Here are the relevant steps from my attempts so far:

My first attempt failed because no -lcrypto (ld).

I installed openssl-devel (for 1.0.0g) via yum and my next attempt failed because no openssl/ec.h.

I downloaded the openssl-1.0.0g source from openssl.org, compiled it, and tricked make into using that source by editing vanitygen.c and oclvanitygen.c.  My next attempt failed because EC is disabled.

I removed openssl-devel via yum and installed openssl-1.0.0g to /usr/local/ssl (default and doesn't interfere with the OS required openssl packages I couldn't remove), and manipulated the LIBS and CFLAGS lines in Makefile as follow:

Code:

LIBS=-L/usr/local/ssl/lib -lpcre -lcrypto -lm -lpthread
CFLAGS=-I/usr/local/ssl/include -ggdb -O3 -Wall

this gave me the following when I tried make:

Code:

$ make
cc -I/usr/local/ssl/include -ggdb -O3 -Wall   -c -o vanitygen.o vanitygen.c
cc -I/usr/local/ssl/include -ggdb -O3 -Wall   -c -o pattern.o pattern.c
cc -I/usr/local/ssl/include -ggdb -O3 -Wall   -c -o util.o util.c
cc vanitygen.o pattern.o util.o -o vanitygen -I/usr/local/ssl/include -ggdb -O3 -Wall -L/usr/local/ssl/lib -lpcre -lcrypto -lm -lpthread
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup':
dso_dlfcn.c:(.text+0x21): undefined reference to `dlopen'
dso_dlfcn.c:(.text+0x34): undefined reference to `dlsym'
dso_dlfcn.c:(.text+0x3f): undefined reference to `dlclose'
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func':
dso_dlfcn.c:(.text+0x364): undefined reference to `dlsym'
dso_dlfcn.c:(.text+0x40b): undefined reference to `dlerror'
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var':
dso_dlfcn.c:(.text+0x484): undefined reference to `dlsym'
dso_dlfcn.c:(.text+0x53e): undefined reference to `dlerror'
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load':
dso_dlfcn.c:(.text+0x5b4): undefined reference to `dlopen'
dso_dlfcn.c:(.text+0x622): undefined reference to `dlclose'
dso_dlfcn.c:(.text+0x650): undefined reference to `dlerror'
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_pathbyaddr':
dso_dlfcn.c:(.text+0x6ce): undefined reference to `dladdr'
dso_dlfcn.c:(.text+0x731): undefined reference to `dlerror'
/usr/local/ssl/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_unload':
dso_dlfcn.c:(.text+0x78a): undefined reference to `dlclose'
collect2: ld returned 1 exit status
make: *** [vanitygen] Error 1

It is at this point that I don't know what to do, I can see that these "undefined references" are mentioned in dso_dlfcn.c (just using cat and grep).  With openssl-devel removed, it's not like the wrong files still exist at (/usr/include/openssl).   Can anyone give me any advice to get this built?

[The00Dustin]

Hmm, looks like you have problems with your Linux distro ( RedHat i guess?)

Yes, F15 = Fedora 15.  Incidentally, when I searched for parts of this error, everything that came up was Ubuntu, isn't that Debian-based?

[idev]

How does one install this on a mac ?

[The00Dustin]

Perhaps you have  problems with libdl-*.**.so, the part of libc.
Or with the compiler.

There was nothing wrong with libdl-*.**.so, however, for whatever reason, ld wasn't using it.  I had to add it directly to the LIBS variable.  This is what finally got me building:

Code:

LIBS=-L/usr/src/ati-stream-sdk-v2.1-lnx64/lib/x86_64 -L/usr/local/ssl/lib /lib64/libdl.so.2 -lpcre -lcrypto -lm -lpthread
CFLAGS=-I/usr/src/ati-stream-sdk-v2.1-lnx64/include -I/usr/local/ssl/include -I/usr/include -ggdb -O3 -Wall

Note that the ATI SDK is in a funny place because that's just where I happened to download it to.  I have never had to list a library directly in libs like that before (/lib64/libdl.so.2 with no leading parameter), but it worked.  Unfortunately, now I'm getting odd output in oclvanitygen compared to what I see in vanitygen:

Code:

$ ./vanitygen -i 1s
Difficulty: 1353
Pattern: 1s
Address: 1sWTv45ThMSacEG9TwLXAECycSj5ybrQm
Privkey: 5HxV9CtT43oXoH4ZrWrbi57UJih88KgAxpVtLss992S12XiqHX2
$ ./oclvanitygen -i 1s
Difficulty: 1353
Match idx: 0
CPU hash: a4900f3de57df3ea62654b295b1a92048ddc994d
GPU hash: 3d0f90a4eaf37de5294b656204921a5b4d99dc8d
Found delta: 1919 Start delta: 1
[151.19 Kkey/s][total 2048][Prob 78.0%][80% in 0.0s]                           Match idx: 0
CPU hash: 5fb13b13d1b464cfa6f2c53d81d7333483d0ec38
GPU hash: 133bb15fcf64b4d13dc5f2a63433d78138ecd083
Found delta: 1918 Start delta: 1
Match idx: 0
CPU hash: 93b30d0ad99f8133a0bc3c4793a27dbad5a0961f
GPU hash: 0a0db39333819fd9473cbca0ba7da2931f96a0d5
Found delta: 1919 Start delta: 1
Match idx: 0
CPU hash: 8030c41b205cf1c395f79223acc4731c8138e2eb
GPU hash: 1bc43080c3f15c202392f7951c73c4acebe23881
Found delta: 1918 Start delta: 1
Match idx: 0
CPU hash: aa8c368c9663f1f15929f4f745d04039fa3403e1
GPU hash: 8c368caaf1f16396f7f429593940d045e10334fa
Found delta: 1918 Start delta: 1
Match idx: 0
CPU hash: a58e04ee7573ae115fed373b0a316c99227de01d
GPU hash: ee048ea511ae73753b37ed5f996c310a1de07d22
Found delta: 2047 Start delta: 1
Match idx: 0
CPU hash: c968065a9670c24c3654930612e70821f5a37082
GPU hash: 5a0668c94cc27096069354362108e7128270a3f5
Found delta: 1663 Start delta: 1
Match idx: 0
CPU hash: 7652fe86bd2a45e82ce111d91ea3a3e8e9e55ab7
GPU hash: 86fe5276e8452abdd911e12ce8a3a31eb75ae5e9
Found delta: 1663 Start delta: 1
Match idx: 0
CPU hash: 757327d079aace35e53aa1cfcf614c552050198f
GPU hash: d027737535ceaa79cfa13ae5554c61cf8f195020
Found delta: 1662 Start delta: 1
Match idx: 0
CPU hash: 5af81f2dc428a8be30f05bb23023bce81553d1ec
GPU hash: 2d1ff85abea828c4b25bf030e8bc2330ecd15315
Found delta: 1663 Start delta: 1
Match idx: 0
CPU hash: 6fa912748c64f7773a1a6acd8d71058e8684abba
GPU hash: 7412a96f77f7648ccd6a1a3a8e05718dbaab8486
Found delta: 2047 Start delta: 1
Match idx: 0
CPU hash: 9f6eab09f51fe0d2ab7ef29ca6176060275c41e4
GPU hash: 09ab6e9fd2e01ff59cf27eab606017a6e4415c27
Found delta: 2047 Start delta: 1
Match idx: 0
CPU hash: 76f461d52e6767dc1295a3c00d7f28509cc08894
GPU hash: d561f476dc67672ec0a3951250287f0d9488c09c
Found delta: 1789 Start delta: 1
Match idx: 0
CPU hash: 623bc0be24cdb542e5005d99850fed085446efee
GPU hash: bec03b6242b5cd24995d00e508ed0f85eeef4654
Found delta: 1919 Start delta: 1
Match idx: 0
CPU hash: 9503160dcca12038ac91bce298c6c19cd90416f5
GPU hash: 0d1603953820a1cce2bc91ac9cc1c698f51604d9
Found delta: 2047 Start delta: 1
Match idx: 0
CPU hash: 63dab8e0ea34d295b5b1c89e0ca3eaddbbb61b8e
GPU hash: e0b8da6395d234ea9ec8b1b5ddeaa30c8e1bb6bb
Found delta: 1661 Start delta: 1
Match idx: 0
CPU hash: b46a27a9fbfcc13da644dcb0306c194f518c3e0c
GPU hash: a9276ab43dc1fcfbb0dc44a64f196c300c3e8c51
Found delta: 1663 Start delta: 1
Match idx: 0
CPU hash: cc1b6bffbb824d51af3283aeafd4b6fd920b6d7d
GPU hash: ff6b1bcc514d82bbae8332affdb6d4af7d6d0b92
Found delta: 1919 Start delta: 1
Match idx: 0
CPU hash: 89d906b7e85d7de50b5ed49f1e17394e5b8ee641
GPU hash: b706d989e57d5de89fd45e0b4e39171e41e68e5b
Found delta: 1791 Start delta: 1
Match idx: 0
CPU hash: a853bf32a17a879e53d5a853bbc34d17df85b3ef
GPU hash: 32bf53a89e877aa153a8d553174dc3bbefb385df
Found delta: 1663 Start delta: 1
Match idx: 0
CPU hash: acf951a982fed9f51b06435194b520dbc3922043
GPU hash: a951f9acf5d9fe825143061bdb20b594432092c3
Found delta: 1660 Start delta: 1
Match idx: 0
CPU hash: 574b20f25084db069658757cc2c4deb3413f3ed2
GPU hash: f2204b5706db84507c755896b3dec4c2d23e3f41
Found delta: 1663 Start delta: 1
Match idx: 0
CPU hash: 55947ac666958b1183d8a2707856b6f19bd9faa7
GPU hash: c67a9455118b956670a2d883f1b65678a7fad99b
Found delta: 1663 Start delta: 1
Match idx: 0
CPU hash: a934e3675124d3f9ddc3ea5a7e4819c6114eb1bf
GPU hash: 67e334a9f9d324515aeac3ddc619487ebfb14e11
Found delta: 1918 Start delta: 1
Match idx: 0
CPU hash: 72b549d5733b52c7525cbba4b51930567b3f9b6d
GPU hash: d549b572c7523b73a4bb5c52563019b56d9b3f7b
Found delta: 1790 Start delta: 1
Match idx: 0
CPU hash: b904cbfd46e83da6bbe15ef8755db40220c0beaa
GPU hash: fdcb04b9a63de846f85ee1bb02b45d75aabec020
Found delta: 1663 Start delta: 1
Match idx: 0
CPU hash: 81c411b505bc4fe0f4c2d4ffb5a5b17e51f8e2c9
GPU hash: b511c481e04fbc05ffd4c2f47eb1a5b5c9e2f851
Found delta: 1789 Start delta: 1
Match idx: 0
CPU hash: 5e5e3718b26724de3d92922b977ddce417f4f8e8
GPU hash: 18375e5ede2467b22b92923de4dc7d97e8f8f417
Found delta: 1791 Start delta: 1
Match idx: 0
CPU hash: cbeb1025944ab7139b3bbc29923617e137efb1c4
GPU hash: 2510ebcb13b74a9429bc3b9be1173692c4b1ef37
Found delta: 1791 Start delta: 1
Match idx: 0
CPU hash: 6c176e5f44008808fa6cadfb7cb429bf2315f9fc
GPU hash: 5f6e176c08880044fbad6cfabf29b47cfcf91523
Found delta: 2047 Start delta: 1
Match idx: 0
CPU hash: a98813ecdde88513abd56cb716655b5d937eb183
GPU hash: ec1388a91385e8ddb76cd5ab5d5b651683b17e93
Found delta: 1790 Start delta: 1
Match idx: 0
CPU hash: 9e930230116b77ea0051e81de1ab018f4f351ef0
GPU hash: 3002939eea776b111de851008f01abe1f01e354f
Found delta: 2047 Start delta: 1
Match idx: 0
CPU hash: 595e56866c2098b493968260ce50ab0eaa4f5c4a
GPU hash: 86565e59b498206c608296930eab50ce4a5c4faa
Found delta: 1791 Start delta: 1
Match idx: 0
CPU hash: a998337cf7fa5c66aaf969d7ab7e19b4b28b9660
GPU hash: 7c3398a9665cfaf7d769f9aab4197eab60968bb2
Found delta: 1663 Start delta: 1
Match idx: 0
CPU hash: c45cd65b2abf95e42ef5a6bab972c1f6e2c19b00
GPU hash: 5bd65cc4e495bf2abaa6f52ef6c172b9009bc1e2
Found delta: 1784 Start delta: 1
Match idx: 0
CPU hash: 6faa2cd4489758678fcf13f213ecc31f9160e5e7
GPU hash: d42caa6f67589748f213cf8f1fc3ec13e7e56091
Found delta: 1790 Start delta: 1
Match idx: 0
CPU hash: 7282c8273e79b01838bbf6130d57db9c80c81c4b
GPU hash: 27c8827218b0793e13f6bb389cdb570d4b1cc880
Found delta: 1790 Start delta: 1
Match idx: 0
CPU hash: 92261bbb216416166f7d6223f1bbd4328828da64
GPU hash: bb1b26921616642123627d6f32d4bbf164da2888
Found delta: 1790 Start delta: 1
Match idx: 0
CPU hash: 6f09ca0b54527e56bd1f0a602a4d4b9d9eea36dd
GPU hash: 0bca096f567e5254600a1fbd9d4b4d2add36ea9e
Found delta: 1790 Start delta: 1
Match idx: 0
CPU hash: 7265677be9bd57042182aa05212ef1e422514a4e
GPU hash: 7b6765720457bde905aa8221e4f12e214e4a5122
Found delta: 1791 Start delta: 1
Match idx: 0
CPU hash: a100c4db9def04e45734f7b9adf98c8c5b83a47c
GPU hash: dbc400a1e404ef9db9f734578c8cf9ad7ca4835b
Found delta: 1790 Start delta: 1
Match idx: 0
CPU hash: 6b366d5d394cb6afc2f4a55b2297145ca6472751
GPU hash: 5d6d366bafb64c395ba5f4c25c149722512747a6
Found delta: 1663 Start delta: 1
Match idx: 0
CPU hash: aa7a26f736df1668c8eeda86fa273181dfa734bc
GPU hash: f7267aaa6816df3686daeec8813127fabc34a7df
Found delta: 1791 Start delta: 1
Match idx: 0
CPU hash: a570a96b24dc5e6ba1af9e1eb97aab12353ae21b
GPU hash: 6ba970a56b5edc241e9eafa112ab7ab91be23a35
Found delta: 1790 Start delta: 1
Match idx: 0
CPU hash: 95a32b74df1473c406f246f531922f048604bcb4
GPU hash: 742ba395c47314dff546f206042f9231b4bc0486
Found delta: 2047 Start delta: 1
Match idx: 0
CPU hash: c8699cbc61465825e1cf9020d450f6d5a85c5a63
GPU hash: bc9c69c8255846612090cfe1d5f650d4635a5ca8
Found delta: 1918 Start delta: 1
Match idx: 0
CPU hash: 8ef42dbbae1b15194deff71edfe23e78b0dae0f4
GPU hash: bb2df48e19151bae1ef7ef4d783ee2dff4e0dab0
Found delta: 1663 Start delta: 1
Match idx: 0
CPU hash: b9b16349b60b4fd9de74dff4807aabd947e98630
GPU hash: 4963b1b9d94f0bb6f4df74ded9ab7a803086e947
Found delta: 2047 Start delta: 1
Match idx: 0
CPU hash: 715c26f488c6cd2a2aa4b5d88318e7328d6fdd8c
GPU hash: f4265c712acdc688d8b5a42a32e718838cdd6f8d
Found delta: 2047 Start delta: 1
^C

Is that output normal?  Seems I can clean it up by doing this:

Code:

 ./oclvanitygen -i 1s 2> /dev/null | grep e
[181.98 Kkey/s][total 2048][Prob 78.0%][80% in 0.0s]
[153.17 Kkey/s][total 184320]
[154.25 Kkey/s][total 337920]
[154.82 Kkey/s][total 493568]
[154.60 Kkey/s][total 649216]
[154.86 Kkey/s][total 804864]
[155.35 Kkey/s][total 960512]
[155.05 Kkey/s][total 1116160]
[155.53 Kkey/s][total 1271808]

since e will include "key/s", "Address", and "Privkey", but still get a lot more unnecessary data onscreen, and as you can see here, no addresses or privkeys are displayed in either of the oclvanitygen ouputs even though it should still find a match almost instantly ("[80% in 0.0s]").  This makes me wonder if something is broken in my setup.

I then discovered that running oclvanitygen with no parameters returns help info, so it looks like if this output is normal, I'll just have it write keys to a file since some searching shows other people using grep with regular expressions to filter output on oclvanitygen (assuming there's not something broken about the fact that it didn't find any keys).  However, the speed is slower than vanitygen, so I thought it must be using the CPU instead of the GPU, searched the thread and found the -d option, which confirms this:

Code:

./oclvanitygen -d 2 -i 1ssss | grep e
Difficulty: 17606948
Available OpenCL platforms:
0: [Advanced Micro Devices, Inc.] ATI Stream
  0: [GenuineIntel] Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz

  This machine is mining fine with cgminer compiling using the SDK links I listed in the LIBS & CFLAGS variables.  Am I missing something completely obvious?

EDIT:  I just realized that when I run oclvanitygen on Windows, the output looks the same as my compiled vanitygen on F15, so I don't know if that means my oclvanitygen output on F15 is odd or not.  I also tried a lot more LIBS and CFLAGS stuff trying to make sure it was linking the right files, but none of that made any difference, and then I realized my last output above does say "0: [Advanced Micro Devices, Inc.] ATI Stream" which implies the right files were used anyway.  Then the obvious clicked, regarding the card not being found, I wasn't using DISPLAY=:0 (duh...).  So now I'm just curious about the extraneous output on oclvanitygen as I compiled it vs vanitygen as I compiled it and oclvanitygen on Windows.

EDIT2:  ACK!  The kernel compiled and ran once, but was still really slow and now I get this:

Code:

$ DISPLAY=:0 ./oclvanitygen -d 1 -i 1ssss | grep e
Difficulty: 17606948
clBuildProgram: CL_BUILD_PROGRAM_FAILURE
Build log:
Internal error: Link failed.
Make sure the system setup is correct.
Device: Cypress
Vendor: Advanced Micro Devices, Inc. (1002)
Driver: CAL 1.4.1417
Profile: FULL_PROFILE
Version: OpenCL 1.0 ATI-Stream-v2.1 (145)
Max compute units: 14
Max workgroup size: 256
Global memory: 268435456
Max allocation: 268435456
$