The trick is to remember that: pub_key + (N+M)*base_ec_point == pub_key + N*base_ec_point + M*base_ec_point

Parallelism is possible by computing:

• A row of sequential EC points (pub_key + k*base_ec_point) for k=0,1,2,...N
• A column of EC points i*N*base_ec_point for i=0,1,2,...

..and then add each possible combination of row and column member in parallel.

The trickiest part of implementing this in OpenCL is the bigint arithmetic.  I'm actually testing a kernel right now.  It's monstrous, easily dwarfing the various miner kernels in compiled size, and only moderately fast -- on my GTX 285, it can produce ~1.1Mkey/sec.

Version 0.13 is up.  The only major change is to display hints when impossible address prefixes are entered, suggested by a user via email.  It's not worth downloading if you already have 0.12.

Under the hood, the source tree has been reorganized a bit, and a new OpenCL version, oclvanitygen, is now present.

Regarding the current state of oclvanitygen:

• It isn't built by default, you need to run: make oclvanitygen.  Build it on Windows at your own peril.
• It isn't optimized at all.  Specifically, it can't outperform the CPU with AMD hardware, and while it is faster with nVidia hardware, the profiler claims 25% occupancy.

I hope it's not too risky

I have been running it on my windows machine for a few days with no complaints.

It is trivial for someone to make a slightly-modified executable that appeared in all respects to work correctly but such that given the account name, they could deduce the private key. That said, I think it's highly unlikely that anyone has bothered.

You can actually check for such a thing. Unless someone specifically thought that someone would test for this, the most obvious way to do that would leave a tell. Create a specific vanity key, say "1Dag". Then create that same vanity key again. And then do it one more time. If any of your keys are the same, you have a sabotaged binary. If not, then you either don't have a sabotaged binary or the sabotage is very subtle. (The obvious way to sabotage it would be to use a defined pattern of keys rather than a random one.)

To report on the current state of oclvanitygen, I've made some progress optimizing it for various GPUs.  So far it has been depending on the CPU to compare addresses with prefix targets.  The performance with higher-end GPUs has progressed to the point that the CPU has become the bottleneck, and the prefix checking will certainly need to be offloaded next.  And don't even think about using regular expressions!

Obligatory performance numbers, searching for a single case-sensitive prefix:

• nVidia GTX 285 + C2D 6600: 3.5 Mkey/s, 100% CPU 90% GPU
• AMD 5830 + Sempron 140: 5.5 Mkey/s, 100% CPU 60% GPU

I found a really cool address with this thing.  As it would turn out though, somebody already claimed it on 1stbits two days ago.   Regardless, 7- and 8-character prefixes are no longer out of reach for a single gaming system.

got this without useing vanity gen

1YCqF14gcummp4Gj4GGdqXFLn7qAssvju

any fighter pilots making a movie?

That's awesome!!

The GPU idle statistic is a mess right now, but to get it, use "-v".

Oh my, this could be an OpenCL implementation bug.  Which type of card is this?  Doesn't Apple have their own implementation, or how does that work on OS X?

You could grab the openclcc standalone compiler from http://code.google.com/p/openclcc/ and use it to test-compile the kernel.  At the very least, this program might not segfault, which would confirm that oclvanitygen is doing something wrong.  You could also run oclvanitygen under gdb and collect a stack trace, which could be helpful either way.

There will definitely need to be a Makefile.OSX in the near future, or maybe cmake.

Sorry that was difficult.  There are a few OpenCL compiler frontends, that was just the one that worked on Linux.  The first one I tried -- http://clcc.sourceforge.net/ -- wouldn't build, but should build and run on OS X.

Are you using the openclcc-embed frontend?  I don't know what that program is doing with the build options, but it must be changing them around.  In the CL/cl.h from nVidia, -43 is CL_INVALID_BUILD_OPTIONS.  Try using the plain openclcc program, or clcc.


Sweet!!  I'll look forward to this.  Would you be available to try out new releases on OS X in the future?