I haven't forgotten about you!  To really get to the bottom of this problem, a device-side kernel test suite will be required.  I'm working on this.  All of my testing to date has been done using a host program, and in all cases so far except yours, the code has behaved identically on the device, or caused a nice, clean crash.

In the mean time, does it generate addresses correctly in safe mode, i.e. does not take more than a few seconds to find a match to 1Boat or such?

So, the last version worked in safe mode, but crashed otherwise, and the current version doesn't work at all in either mode?

And, just to verify, the key search rate is still ~3Mkey/s in safe mode?

This is a very interesting result.  In the current version, safe mode does not completely disable loop unrolling, just the long ones.  The shorter loops used in the bignum arithmetic functions are still unrolled by the preprocessor.  There were changes beside this, but it could be a good place to start poking.  I can send you replacement kernel code that disables all preprocessor unrolling if you want to try.


The language is OpenCL-C, and you should already have the code: take a look at calc_addrs.cl.  Unfortunately, I don't have any tips to offer on how to use a device-side debugger, or whether it's even possible using AMD's SDK.

The kernels keep a couple of large temporary value buffers in GPU memory, usually never touched by the CPU.  Their contents could be very informative for diagnosing problems, and all the test suite will do is check the correctness.

This could be pretty cool.

I know this has been discussed elsewhere.  To reiterate, the scheme involves a client/service relationship, where the client:

• Comes up with a list of address patterns that they want.
• Generates a pool of EC private keys, at least one per pattern.
• Submits the public keys of the key pool and the patterns to the address generation service.

The service tests a whole bunch of public key addresses, finds a match, and reports back:

• The matched pattern.
• The base public key Kb from which the match was derived.
• The increment of the matching public key n from the base, where the matching vanity public key Kv = Kb + nG

The client could then compute the private key by finding the private key in their pool matching the base public key and adding the increment to it.  Thus, the service can find vanity addresses without ever having to know their private keys.

The security afforded by this scheme comes at the cost of not being able to pool together the patterns desired by different clients into a single list, which would be dramatically more efficient.  Every work unit executed by the service would end up being specific to a single client.  If there were some way around this, it would make the service much more practical.

Tested with both new and old with -S. Same thing happens on both: the probability cunts up, then goes away, and it just keep counting the # of completed attempts without ever finding anything.

If we had a trusted pool server, it could supply each "miner" with a list of patterns and a public key which only the server knows the public key of. When a match occurs, it's controlled by the server and if it is correct, the miner get's another public key and server sends the vanity key and corresponding private key to the requesting user. We do have to trust the server to not steal the public keys, I don't know if this is a big issue.

This might help a bit. You have to install PCRE also, see http://pcre.org/

https://bt.irlbtc.com/view/25804.msg424122#msg424122

http://blockexplorer.com/address/1BitcoinEaterAddressDontSendf59kuE
this one ?

 
I've generated a 7 letter one that I may use....
but ones associated with my forum name will stay on the forums 

It is valid
We'll just never find the private key