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

[nagnagnag2]

1 BTC bounty for a fix for 13.x catalyst + vanitygen patch working, with source and builds for Linux, Windows, etc.

I will add 0.1 BTC to that.

[jackjack]

Is samr7 still developing Vanitygen?

[K1773R]

hes inactive since a long time

[wtfvanity]

hes inactive since a long time

Date Registered:   June 08, 2011, 10:59:48 PM
Last Active:   October 24, 2012, 03:59:55 PM

[malevolent]

I think he may return; last time he came back with a new version of vanitygen after 11 months of inactivity.

[Lethos]

I'm sure some might find this funny, but has anyone tried this on a Raspberry Pi - vanitygen that is.
I got a little project going (My RPi will arrive soon) and it might be nice to have a few of my preferred bitcoin tools on there.

I don't expect fast results, I just wondered if anyone had done it.

[K1773R]

the CPU is too bad for it

[Remember remember the 5th of November]

Pardon my abilities, but I think the error may come from the bignum implementation. At least, after removing the functions that cause it to crash, I started re-adding them, then I started to remove pieces of code from functions and ended up with an OK compile which led me to this theory.

To further support my theory, change this:

Code:

typedef struct {
	bn_word d[BN_NWORDS];
} bignum;

to this

Code:

typedef struct {
	bn_word d[0];
} bignum;

The program won't work correctly, but the calc_addr.cl kernel will compile.

[MeatPopsicle]

How'd you figure out the functions that were causing it to crash?

[Remember remember the 5th of November]

How'd you figure out the functions that were causing it to crash?

I was more than clear in my post.

Anyway, I was still wrong. After talking on the #opencl channel on freenode, an OpenCL C compiler developer said that the issue is caused by incorrect instructions produced by the OpenCL compiler.

[drrussellshane]

Forgive me if this is a stupid post, but is vanitygen safe?

That is to say, are the keys that it generates always 100% working keys that can be imported into a Bitcoin client? Is there a chance of creating a "bad private key" from vanitygen, such that one cannot, for some reason, import said key into a wallet?

Are the keys that are generated with vanitygen random enough, or at least as random as addresses generated with the standard Bitcoin client?

Also, I am assuming that smarter folks than I have made sure that this little program doesn't create keys and then send them all back to the vanitygen creator or something else likewise nefarious, right?

[Remember remember the 5th of November]

Forgive me if this is a stupid post, but is vanitygen safe?

That is to say, are the keys that it generates always 100% working keys that can be imported into a Bitcoin client? Is there a chance of creating a "bad private key" from vanitygen, such that one cannot, for some reason, import said key into a wallet?

Are the keys that are generated with vanitygen random enough, or at least as random as addresses generated with the standard Bitcoin client?

Also, I am assuming that smarter folks than I have made sure that this little program doesn't create keys and then send them all back to the vanitygen creator or something else likewise nefarious, right?

The keys should be safe in terms of importing and should be cryptographically safe.

I've examined OpenSSL's code and saw that it creates a screenshot of the screen and uses that as seed, then it also uses CryptGenRandom for further seeding on Windows. You are free to seed it yourself as well.

[Shevek]

Forgive me if this is a stupid post, but is vanitygen safe?

That is to say, are the keys that it generates always 100% working keys that can be imported into a Bitcoin client? Is there a chance of creating a "bad private key" from vanitygen, such that one cannot, for some reason, import said key into a wallet?

Go here, https://www.bitaddress.org , and select the "wallet details" option. Then put there the private key created by vanitygen (you can download the html-js code and create your own page, if you don't trust) and check it

Are the keys that are generated with vanitygen random enough, or at least as random as addresses generated with the standard Bitcoin client?

The second option (AFAIK from my last contact with the program)

Also, I am assuming that smarter folks than I have made sure that this little program doesn't create keys and then send them all back to the vanitygen creator or something else likewise nefarious, right?

The code is open for your revision.

[MeatPopsicle]

How'd you figure out the functions that were causing it to crash?

I was more than clear in my post.

Anyway, I was still wrong. After talking on the #opencl channel on freenode, an OpenCL C compiler developer said that the issue is caused by incorrect instructions produced by the OpenCL compiler.

Need to borrow a shovel?

[yuzhe]

Hello,

I've created workaround for buggy 13.x catalyst driver, needs some testing though (especially the miner and win32).

For the impatient:
linux:

Code:

$ git clone https://github.com/wyuzhe/vanitygen.git
$ cd vanitygen
$ make oclvanitygen
$ ./oclvanitygen -vv -D x:y 1Blah

In case you get odd output like:

Code:

Match idx: 0
CPU hash: 0ecfec41290a506e784a4521597213398abf9a98
GPU hash: 08e030855f47c3141a5808d8767a89562ec5c655
Found delta: 497669 Start delta: 1

It means the compiler backend is still outputting broken code (although it compiles). To fix that try:

Code:

./catalystwrap ./oclvanitygen -vv -D 0:0 1ov

Windows users can try applying the dll override script in the directory of official vanitygen binaries [edit: link with resulting archive removed due security concerns].

The gory details:

https://github.com/wyuzhe/vanitygen/commit/6f7fd04adc609b19520cdab4cc12d648e364adbe

In short, ATI LLVM-IR backend miscompiles stuff like:

Code:

uint x, b, c;
x += (a < b)

The boolean result of (a < b) is expressed as byte (u8 in crash report), but VLIW architectures know no such thing. Workaround is using artificially complex expressions which cannot be readily expressed as setcc in llvm ir (but will be optimized away during R600 lowering anyway).

[deepceleron]

Hello,

I've created workaround for buggy 13.x catalyst driver, needs some testing though (especially the miner and win32).

For the impatient:
linux:

Code:

$ git clone https://github.com/wyuzhe/vanitygen.git
$ cd vanitygen
$ make oclvanitygen
$ ./oclvanitygen -vv -D x:y 1Blah

In case you get odd output like:

Code:

Match idx: 0
CPU hash: 0ecfec41290a506e784a4521597213398abf9a98
GPU hash: 08e030855f47c3141a5808d8767a89562ec5c655
Found delta: 497669 Start delta: 1

It means the compiler backend is still outputting broken code (although it compiles). To fix that try:

Code:

./catalystwrap ./oclvanitygen -vv -D 0:0 1ov

win32 binaries are available at:
https://www.dropbox.com/s/lddvyiyl58uhgio/vanitygen-0.22-catalystmod.zip

However received little to no testing, so comments are welcome.

The gory details:

https://github.com/wyuzhe/vanitygen/commit/6f7fd04adc609b19520cdab4cc12d648e364adbe

In short, ATI LLVM-IR backend miscompiles stuff like:

Code:

uint x, b, c;
uint x += (a < b)

The boolean result of (a < b) is expressed as byte (u8 in crash report), but VLIW architectures know no such thing. Workaround is using artificially complex expressions which cannot be readily expressed as setcc in llvm ir (but will be optimized away during R600 lowering anyway).

Warning, the link has binaries and no source. The file dates were not changed so this is likely virused up, not recompiled.

[yuzhe]

Warning, the link has binaries and no source. The file dates were not changed so this is likely virused up, not recompiled.

Actually, the vanitygen binaries are verbatim from official zip, plus just opencl dlls stitched in the archive. Naturally you should test on untrusted machine, as every binary code posted on forums.

For paranoid users, i'd recommend to use the linux version.

[deepceleron]

Warning, the link has binaries and no source. The file dates were not changed so this is likely virused up, not recompiled.

Actually, the vanitygen binaries are verbatim from official zip, plus just opencl dlls stitched in the archive. Naturally you should test on untrusted machine, as every binary code posted on forums.

For paranoid users, i'd recommend to use the linux version.

Then why does the github https://github.com/wyuzhe/vanitygen/commit/6f7fd04adc609b19520cdab4cc12d648e364adbe show that "the fix" is modified calc_addrs.cl, oclengine.c, oclvanitygen, etc which would indicate new binaries?

[yuzhe]

Warning, the link has binaries and no source. The file dates were not changed so this is likely virused up, not recompiled.

Actually, the vanitygen binaries are verbatim from official zip, plus just opencl dlls stitched in the archive. Naturally you should test on untrusted machine, as every binary code posted on forums.

For paranoid users, i'd recommend to use the linux version.

Then why does the github https://github.com/wyuzhe/vanitygen/commit/6f7fd04adc609b19520cdab4cc12d648e364adbe show that "the fix" is modified calc_addrs.cl, oclengine.c, oclvanitygen, etc which would indicate new binaries?

win32 is just downgrade of opencl compiler - no further changes made at this point.

I'll provide script to build resulting archive to avoid further implications.

I'n the meantime, I'd like to offer you 1BTC for factual evidence aforementioned archive is "virused up" - since it was created on a linux workstation, it is higly unlikely but I'd prefer to be on the safe side - I'm certainly no expert in that area. I've removed the link from my post, in case your accusation is proven to be true.

[Remember remember the 5th of November]

The fix does not work, I compiled from source, updated CL kernel. I used APP SDK's OpenCL.dll and and amdocl64.dll files, but unfortunately the program hangs before it even prints "Compiling kernel". It doesn't crash, it just hangs with these DLLs and huge CPU usage, but nothing.