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

[jackjack]

Just to let you know, the error was on Ubuntu, not Windows

I don't have access to my laptop right now, i'll test asap

Also I made a mini script to compile when make doesn't find cl.h
I didn't make a pull request because it's rather dirty but it might be useful for some
It's useful for me because I can compile without modifying oclvanitygen.c: the script modifies oclvanitygen.c, runs make, then modifies oclvanitygen.c back

[1714904568]

1714904568

[1714904568]

1714904568

[1714904568]

1714904568

[1714904568]

1714904568

[defxor]

• Edit: Mac OS X platform support and makefile, added by dinox

Seems to work fine - thanks! I built in on my MBP (had to install pcre first) and tried both vanitygen (~100kk/s - 1 thread, ~170kk/s with 2) and oclvanitygen (~140kk/s) although I haven't imported any keys into a wallet and used them for transactions.

I did fail building it towards a newer version of OpenSSL (1.0.0d, installed via macports) though, even though I added both a hardcoded lib path and the correct include paths to the Makefile. I guess it's been too many years since I developed anything in C. (Or did I succeed and it's just the version check prompt that gets its knowledge from elsewhere?)


edit: This.

Code:

$ otool -L vanitygen
vanitygen:
	/usr/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0)
	/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
$ otool -L oclvanitygen
oclvanitygen:
	/usr/lib/libpcre.0.dylib (compatibility version 1.0.0, current version 1.1.0)
	/opt/local/lib/libcrypto.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
	/System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL (compatibility version 1.0.0, current version 1.0.0)

vs

Code:

$ ./vanitygen
WARNING: Built with OpenSSL 0.9.8l 5 Nov 2009
WARNING: Use OpenSSL 1.0.0d+ for best performance
Vanitygen 0.16 (OpenSSL 0.9.8l 5 Nov 2009)
Usage: ./vanitygen [-vqrikNT] [-t <threads>] [-f <filename>|-] [<pattern>...]

I've also tried

Code:

export DYLD_LIBRARY_PATH=/opt/local/lib/

in the event it was a runtime loading problem but it didn't change anything.

[RaTTuS]

+1
new Address in my sig 

[samr7]

I did fail building it towards a newer version of OpenSSL (1.0.0d, installed via macports) though, even though I added both a hardcoded lib path and the correct include paths to the Makefile. I guess it's been too many years since I developed anything in C. (Or did I succeed and it's just the version check prompt that gets its knowledge from elsewhere?)

First, congrats on getting oclvanitygen to run!  What GPU are you using?  The key rate is probably a lot slower than it could be, but at least the OpenCL compiler isn't crashing.

Regarding the OpenSSL warning, that check is a compile-time one, so switching out the shared library won't stop the warning.  This brings up a potential issue: I thought that between OpenSSL 0.9.8 and 1.0.0, a bunch of changes were made that broke binary compatibility.  To the effect that attempting to build against the header files for 0.9.8 and link with a 1.0.0 library would cause problems.  While it doesn't seem to be crashing for you, it should run at about twice the speed you report.  Anyway, when building from source, you want to use the header files for 1.0.0.

What we really need is a set of pre-built binaries for OS X, with the 3rd party dependencies static-linked.

[defxor]

First, congrats on getting oclvanitygen to run!  What GPU are you using?  The key rate is probably a lot slower than it could be, but at least the OpenCL compiler isn't crashing.

Regarding the OpenSSL warning, that check is a compile-time one, so switching out the shared library won't stop the warning.  This brings up a potential issue: I thought that between OpenSSL 0.9.8 and 1.0.0, a bunch of changes were made that broke binary compatibility.  To the effect that attempting to build against the header files for 0.9.8 and link with a 1.0.0 library would cause problems.  While it doesn't seem to be crashing for you, it should run at about twice the speed you report.  Anyway, when building from source, you want to use the header files for 1.0.0.

What we really need is a set of pre-built binaries for OS X, with the 3rd party dependencies static-linked.

Yeah I just managed to fix it, posting as a reply to you now instead of yet another edit to my original post It was indeed me just being rusty at writing makefiles. For those who install a newer version of OpenSSL using Macports the Makefile needs to look like this:

Code:

LIBS=-L/opt/local/lib -lpcre -lcrypto -lm -lpthread
INCL=-I/opt/local/include
CFLAGS=-ggdb -O3 -Wall $(INCL)
OBJS=vanitygen.o oclvanitygen.o pattern.o
PROGS=vanitygen
TESTS=

all: $(PROGS)

vanitygen: vanitygen.o pattern.o
        $(CC) $^ -o $@ $(CFLAGS) $(LIBS)

oclvanitygen: oclvanitygen.o pattern.o
        $(CC) $^ -o $@ $(CFLAGS) $(LIBS) -framework OpenCL

clean:
        rm -f $(OBJS) $(PROGS) $(TESTS)

It makes no difference in speed compared to using the right lib and the wrong header files (I think there was a 20% speedup or so between the 0.9.8 and 1.0.0 libs though) - but since I'm on a laptop I have no opinion on what's good or bad.

My MBP is a 2.53GHz C2D with an NVidia GeForce 9400M. This is the output I can get from oclvanitygen by playing around with the parameters and crashing it

Code:

Device: GeForce 9400M
Vendor: NVIDIA
Driver: CLH 1.0
Profile: FULL_PROFILE
Version: OpenCL 1.0 
Max compute units: 2
Max workgroup size: 512
Global memory: 268435456
Max allocation: 134217728

Agree about pre-built binaries from a trusted source for those who don't want to spend a few hours going from no build environment to a working one I like doing it since I was a developer many years ago and want to prove to myself that I haven't forgotten everything. In this case it took way too long to figure out I had put the include path flag at the wrong place ...

[RaTTuS]

Oh yeah that was using
oclvanitygen
on a Nvidia280 Card running at about 3.7Mh/s [it took about 3 days]

[samr7]

It makes no difference in speed compared to using the right lib and the wrong header files (I think there was a 20% speedup or so between the 0.9.8 and 1.0.0 libs though) - but since I'm on a laptop I have no opinion on what's good or bad.

Interesting, so it is binary compatible on OS X?  Regardless, something still seems off.  You have a smokin' fast CPU.  My older C2D 2.0GHz laptop gets 155 Kkey/s with a single thread.  Maybe OpenSSL isn't being built with the assembly code enabled?

My MBP is a 2.53GHz C2D with an NVidia GeForce 9400M. This is the output I can get from oclvanitygen by playing around with the parameters and crashing it

Code:

Device: GeForce 9400M
Vendor: NVIDIA
Driver: CLH 1.0
Profile: FULL_PROFILE
Version: OpenCL 1.0 
Max compute units: 2
Max workgroup size: 512
Global memory: 268435456
Max allocation: 134217728

Tell me about the crash!

With a 9400M, the number you got might not be too bad.  It probably needs tweaks to work well on smaller laptop GPUs, and I don't have one to test with.  I'll guess that it has long, uncomfortable display lag?  The work unit autoconfiguration certainly hasn't been tested with your GPU, and you might get performance or responsiveness improvements from command-line tweaks like -w256 or -g512x256 or -b1024.  It needs a built-in benchmark, among other things.

[samr7]

+1
new Address in my sig 

Nice!

If the capitalization was intentional (and it looks like it was), that's one of the most complex prefixes that anyone has found to date.

[defxor]

My older C2D 2.0GHz laptop gets 155 Kkey/s with a single thread.  Maybe OpenSSL isn't being built with the assembly code enabled?

Interesting. I would be surprised if the Apple default Snow Leopard OpenSSL installation (0.9.8) wasn't optimized though - the Macports version (1.0.0d) was after all slightly faster. I didn't verify the compile flags used though.

Maybe we should just wait for other Mac users to report in :) My system could possibly have other issues.

Tell me about the crash!

Sure. Not really understanding the different options I tried starting it with a really low value for worksize:

Code:

$ ./oclvanitygen -w2 -d0 1pattern
Difficulty: 15318045009
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Fatal Error : Kernel execute caused an error that invalidated the queue (0x1004103b0). This may be  due to a resource allocation failure at execution time.
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid command queue

vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : clEnqueueNDRangeKernel failed: queue (0x1004103b0) has been invalidated.
clEnqueueNDRange(2): CL_INVALID_COMMAND_QUEUE

(followed by the GPU information I posted above)

With a 9400M, the number you got might not be too bad.  It probably needs tweaks to work well on smaller laptop GPUs, and I don't have one to test with.  I'll guess that it has long, uncomfortable display lag?  The work unit autoconfiguration certainly hasn't been tested with your GPU, and you might get performance or responsiveness improvements from command-line tweaks like -w256 or -g512x256 or -b1024.  It needs a built-in benchmark, among other things.

Really bad lag, yes. Just for reference, for anyone who wants to start fine tuning, I ran (very briefly) all your examples above:

• -w256 - no obvious difference in speed or responsiveness
• -g512x256 - ~15% slower, more responsive
• -b1024 - no obvious difference in speed or responsiveness

[RaTTuS]

Nice!

If the capitalization was intentional (and it looks like it was), that's one of the most complex prefixes that anyone has found to date.

it was, though I'm looking for another one that stands out a bit more ... but I'm fairly happy with that one 

[jackjack]

Nice!

If the capitalization was intentional (and it looks like it was), that's one of the most complex prefixes that anyone has found to date.

it was, though I'm looking for another one that stands out a bit more ... but I'm fairly happy with that one  

I found Jackjack7eYNdGkbgUUrtKBraSWBUV5DJP too
With such speeds I think an address with 8 fixed characters can be found
Maybe more with vanitygen pools


That might interest some people here: I just finished a web interface for pywallet
Download the last version, run ./pywallet --web and go to localhost:8989

[dinox]

Tell me about the crash!

With a 9400M, the number you got might not be too bad.  It probably needs tweaks to work well on smaller laptop GPUs, and I don't have one to test with.  I'll guess that it has long, uncomfortable display lag?  The work unit autoconfiguration certainly hasn't been tested with your GPU, and you might get performance or responsiveness improvements from command-line tweaks like -w256 or -g512x256 or -b1024.  It needs a built-in benchmark, among other things.

Intresting it works on OS X for others, it's probably my MBP which is the problem. I'm throwing 10.7 Lion at it now so let's see if that fixes the problem...

[coblee]

Sorry if this was already answered. Is there a way to easily verify that a private/public key pair is valid without having to import it?

Specifically, I want to use vanitygen to generating a few savings account address offline and possibly just write those keys down or print them out. I would prefer to not have to connect my computer to the internet to be safe. But I'm worried about a possible bug in the vanitygen code that may cause it to generate invalid keys. So I don't want to generate an address, put in 1000 bitcoins, then 5 years later find out that the corresponding private key doesn't work!

[jackjack]

Sorry if this was already answered. Is there a way to easily verify that a private/public key pair is valid without having to import it?

Specifically, I want to use vanitygen to generating a few savings account address offline and possibly just write those keys down or print them out. I would prefer to not have to connect my computer to the internet to be safe. But I'm worried about a possible bug in the vanitygen code that may cause it to generate invalid keys. So I don't want to generate an address, put in 1000 bitcoins, then 5 years later find out that the corresponding private key doesn't work!

As vanitygen and pywallet "privkey to pubkey" functions weren't programmed by the same person you can use pywallet (getinfo function) to reassure you

[coblee]

Sorry if this was already answered. Is there a way to easily verify that a private/public key pair is valid without having to import it?

Specifically, I want to use vanitygen to generating a few savings account address offline and possibly just write those keys down or print them out. I would prefer to not have to connect my computer to the internet to be safe. But I'm worried about a possible bug in the vanitygen code that may cause it to generate invalid keys. So I don't want to generate an address, put in 1000 bitcoins, then 5 years later find out that the corresponding private key doesn't work!

As vanitygen and pywallet "privkey to pubkey" functions weren't programmed by the same person you can use pywallet (getinfo function) to reassure you

I only see am importprivkey command. I assume that takes in a private key. That doesn't really confirm that the private key matches the public key. And I won't be able to be sure unless I send some money to the public key.

Would it be easy for you to add a command to let me validate priv/pub key pair without importing anything? I don't care for importing it into a wallet.dat file.

[jackjack]

The --info flag does that, and doesn't import the key, even if the command is importkey:

Code:

./pywallet.py --info --importprivkey yourkey

Or you can use the web interface if you prefer

[coblee]

Thanks, that works.

[samr7]

Interesting. I would be surprised if the Apple default Snow Leopard OpenSSL installation (0.9. wasn't optimized though - the Macports version (1.0.0d) was after all slightly faster. I didn't verify the compile flags used though.

Maybe we should just wait for other Mac users to report in My system could possibly have other issues.

There were some posts by another guy who built vanitygen on a Mac Pro, and had the same problem with OpenSSL.  Somehow he built OpenSSL from source by hand, and got the expected performance.  Here's one of his posts documenting what he got from openssl speed with 0.9.8.  Four posts up, he lists the 0.9.8 key rate, and two posts down, he got the key rate to nearly double.

Code:

$ ./oclvanitygen -w2 -d0 1pattern
Difficulty: 15318045009
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Fatal Error : Kernel execute caused an error that invalidated the queue (0x1004103b0). This may be  due to a resource allocation failure at execution time.
vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : Failed to wait for events! Event 0 in waitlist failed. Invalid command queue

vg_ocl_context_callback error: [CL_INVALID_COMMAND_QUEUE] : OpenCL Error : clEnqueueNDRangeKernel failed: queue (0x1004103b0) has been invalidated.
clEnqueueNDRange(2): CL_INVALID_COMMAND_QUEUE

(followed by the GPU information I posted above)

Clearly you have a talent for finding bugs.  I never even thought to try -w1.  Anyway, to fix this, perhaps all it needs is a set of checks to enforce the NDRange maximum sizes.

Really bad lag, yes. Just for reference, for anyone who wants to start fine tuning, I ran (very briefly) all your examples above:

• -w256 - no obvious difference in speed or responsiveness
• -g512x256 - ~15% slower, more responsive
• -b1024 - no obvious difference in speed or responsiveness

I guess that's expected.  If you combine -g512x256 and -w256 it might have similar performance with less lag.  To get this right with every GPU would require some sort of auto-tuning after initial configuration.  That will be trickier.

[samr7]

I found Jackjack7eYNdGkbgUUrtKBraSWBUV5DJP too

Wow!

Is that: 1Jackjack7eYNdGkbgUUrtKBraSWBUV5DJP, or without the 1?

How long did it take you to find it?

[samr7]

Intresting it works on OS X for others, it's probably my MBP which is the problem. I'm throwing 10.7 Lion at it now so let's see if that fixes the problem...

Let me know how this goes!  Probably, it worked for defxor because he has an NVIDIA GPU.  Or, do the drivers actually share compiler infrastructure on OS X?