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

[OZR]

How to generate an address similar to the 1ABC**************************ABC ?

* - A random simbol

[refer_2_me]

How to generate an address similar to the 1ABC**************************ABC ?

* - A random simbol

There may be a better way, but you could run vanity gen with just the prefix:

Code:

vanitygen -k -o matches.txt 1ABC

To generate a bunch of addresses that start with 1ABC, then grep to find ones that end with it:

Code:

grep 'ABC$' matches.txt

The '$' looks for matches at the end of a line.

[nimda]

How to generate an address similar to the 1ABC**************************ABC ?

* - A random simbol

There may be a better way, but you could run vanity gen with just the prefix:

Code:

vanitygen -k -o matches.txt 1ABC

To generate a bunch of addresses that start with 1ABC, then grep to find ones that end with it:

Code:

grep 'ABC$' matches.txt

The '$' looks for matches at the end of a line.

^ This way will be faster, but vanitygen supports regex directly with the -r parameter.

[refer_2_me]

OK, I switched it to use OpenSSL for the key derivation, and it is much faster.  Did a 99,171 word dictionary file in 53 seconds: 1,871 per second (3 GHz processor.)  The downside could be that it doesn't work on your system because it's not pure Python.  I think it's supposed to work on Windows if you have OpenSSL DLL's, and maybe on Mac OS too.  It's here: https://gist.github.com/scintill/5829284/54bcc0a9a44809c3fb4b53259239316520bbfe17 .  The OpenSSL wrapper is from here: https://github.com/joric/brutus/blob/master/ecdsa_ssl.py .

Make sure you are using the right compression flag (which translates into the DER-encoding of the pubkey: starts with 04 hex byte if uncompressed, 02 or 03 if compressed.)  Whether your address is compressed will depend on what tool and settings you used to generate it.  If it has been spent from before, then you can look in the blockchain to be sure of whether it is compressed or not.  Otherwise, I don't think you can tell from just the address.  You can tell from the private key, which starts with 5 if uncompressed, K or L if compressed.

The Python way can be parallelized pretty easily by splitting the input file into, say, 4 files, and running 4 instances of the script at a time.

If you want to try OpenCL, from what little I know, I think it would be best to do the SHA256 in batches (so the inputs are the same smallish uniform size they are now), then give all the hashes to the OpenCL kernel, and have each kernel derive the hash160 and see if it equals the target address, and run those in parallel.  I guess the SHA256 becomes a bottleneck, so maybe it would be better to try to do that in the OpenCL kernel, but as far as memory management it might be harder to adjust the vanitygen design for string inputs.

Also, I think the base58-encode is not quite right in the Python. It should pad with "1" for each leading zero in the public key hash.  If your target address doesn't start with "11..." I don't think it will matter though.

Oh man, I can't thank you enough. I can confirm that it works on my installation of Ubuntu 13.04 BTW. I haven't recovered the key yet, but it won't take long now.

Thanks again!

So I'm actually having some troubles. It worked fine with a short list (~2000) passphrases that I tried. But I ran it on a longer list of passphrases (modifications of mine) and it ran for a bit then segfaulted. I tried it again and the same thing. I tried it on a list of random 2 word pass phrases, and it ran through a lot of them then seg faulted. Rerunning it, it segfaults on around the same place about 12,000-12,100 guesses in each time. Any idea what could be going wrong?

And what details about my setup would you need to diagnose it?

Edit: it mostly seems to be crashing at:

Code:

pub_key = ssl.EC_POINT_new(group)

Edit 2: The segfault does not seem to be dependent on the actual passphrase being checked. Pulling out the one that made it crashed into a separate file and then running it runs fine. I think that there may be a memory leak in the ecdsa_ssl.py script, but I'm not sure where.

Edit 3: So after realizing that something (couldn't figure out what) had eaten up 47/48GB of memory, I rebooted (I know, classic) and it seems to be running fine.

[refer_2_me]

How to generate an address similar to the 1ABC**************************ABC ?

* - A random simbol

There may be a better way, but you could run vanity gen with just the prefix:

Code:

vanitygen -k -o matches.txt 1ABC

To generate a bunch of addresses that start with 1ABC, then grep to find ones that end with it:

Code:

grep 'ABC$' matches.txt

The '$' looks for matches at the end of a line.

^ This way will be faster, but vanitygen supports regex directly with the -r parameter.

Ah, i missed that parameter.
You may be right about speed, I'm not sure.
But to answer OZR's question, what you want to do is:

Code:

vanitygen -r '^1ABC.*ABC$'

[scintill]

Edit 3: So after realizing that something (couldn't figure out what) had eaten up 47/48GB of memory, I rebooted (I know, classic) and it seems to be running fine.

Ouch, glad you got it sorted.  It could be leaking memory.  I do see some free() calls, so the author put some consideration into it, but they may have missed others.  Generating tens of thousands of keys in one run isn't a usecase they probably considered.  I don't know much about ctypes to know for sure.  Good luck!

[laughingbear]

Still looking to fix this endless loop bug with the 7970.  It crashes when I try to use safemode.

Anyone have advice?

[murfshake]

Still looking to fix this endless loop bug with the 7970.  It crashes when I try to use safemode.

Anyone have advice?

Same thing on my 7970.  Damn,

[refer_2_me]

Edit 3: So after realizing that something (couldn't figure out what) had eaten up 47/48GB of memory, I rebooted (I know, classic) and it seems to be running fine.

Ouch, glad you got it sorted.  It could be leaking memory.  I do see some free() calls, so the author put some consideration into it, but they may have missed others.  Generating tens of thousands of keys in one run isn't a usecase they probably considered.  I don't know much about ctypes to know for sure.  Good luck!

So I am still running into some issues where it segfaults. Does anyone have any suggestions for things I can do to debug what the problem is? I'm pretty good with python, but I haven't used ctypes before, and I have only a passing familiarity with C.

[adam3us]

Also seeing the CPU hash / GPU hash error message on AMD 7870.

Running with -V has the same problem but slower.  -S crashes.  This on fedora.

I notice there was news of a recent open source update from AMD, not sure if that made it to the package managers yet, but maybe someone wants to try see if that fixes.

Its unclear to me if its an oclvanity bug or an AMD driver bug.  However people in the thread seem to be experiencing the same problem on windows.

Has anyone had any success contacting samr7?  I tried to contact him with a bug report for something else related to vanitygen, and I have to say it strikes me a bit suspicious that a bitcoin related tool that is generating private keys has an uncontactable author and maintainer.  Even email to samr7@cs.washington.edu bounces with no such user, again suspicious.  (Maybe he finished his course, but he has a bitcointalk account also that he doesnt answer).  My bug so far was just about the probably incorrectness of timing estimates based on time to compute strings with and without capitalization. 

eg 7 chars projects 3888 times longer case sensitive vs case insensitive.  Thats seems likely incorrect as the work to find a string that is case insensitive is 2x less for each alphabetic character.  So a 7 char target should be 2^7 = 128x faster not 3888x faster.  Thats out by a factor of 30.  Am I missing anything?

(I mean excluding the leading 1 ie 1abcdefg: vanitygen 1abcdefg vs vanitygen -i 1abcdefg.)

Adam

Edit 3: So after realizing that something (couldn't figure out what) had eaten up 47/48GB of memory, I rebooted (I know, classic) and it seems to be running fine.

Ouch, glad you got it sorted.  It could be leaking memory.  I do see some free() calls, so the author put some consideration into it, but they may have missed others.  Generating tens of thousands of keys in one run isn't a usecase they probably considered.  I don't know much about ctypes to know for sure.  Good luck!

So I am still running into some issues where it segfaults. Does anyone have any suggestions for things I can do to debug what the problem is? I'm pretty good with python, but I haven't used ctypes before, and I have only a passing familiarity with C.

[bitpop]

You are missing that cases differ in many times more bits

[laughingbear]

THis guy claims to have it working on a 7970, by disabling BFI_INT.

https://bitcointalk.org/index.php?topic=57410.msg695201#msg695201

linux, cat 11.12, sdk2.6, vanitygen git, disabled BFI_INT to get correct results
925/1375 28.1Mk/s
1125/1375 32.4Mk/s
1125/1575 33.2Mk/s
1170/1600 34.1Mk/s

some more testing, disabled EXPENSIVE_BRANCHES and DEEP_VLIW, -g 2048x2048 -b 256
925/1375 37.1Mk/s
1125/1375 43.0Mk/s
1125/1575 43.7Mk/s
1170/1600 45.0Mk/s

more tweaking...
925/1375 39.8Mk/s
1125/1375 46.6Mk/s
1170/1600 49.1Mk/s

edit: 50.1Mk/s at 1200/1600

How do I disable BFI_INT ?

[FlappySocks]

I wonder now hard it would be to get cgminer to generate vanity addresses?  Seems logical it could use the hashing power of your miners to do it.

[refer_2_me]

Why bother, just use vanitygen or oclvanitygen (for GPU). The tool is already written, has a bunch of nice features and it is fast.

[FlappySocks]

Seems to be a lot of problems with it, and it hasn't kept up with FPGAs and ASICs

[bitpop]

Yeah I only have asics now

[laughingbear]

anyone know how I might go about disabling BFI_INT?

[scintill]

anyone know how I might go about disabling BFI_INT?

If you can change source and recompile, try commenting out these two lines.  If you're handy with a hex editor, try searching for the string "cl_amd_media_ops" in your binary and overwriting with X's or some unique string, which should permanently disable BFI_INT (though I wonder if the .exe/ELF/whatever has some checksums that will throw an error when you run the program.)

Seems to be a lot of problems with it, and it hasn't kept up with FPGAs and ASICs

Well, I'm 99% sure no existing Bitcoin-mining ASIC can be repurposed for vanity mining.  FPGAs, maybe, but it requires more skill than GPU programming, so there just aren't that many capable of doing it, and even fewer that would do it for free.

I have to say it strikes me a bit suspicious that a bitcoin related tool that is generating private keys has an uncontactable author and maintainer.

It is interesting.  It looks like the private keys are generated by OpenSSL though, so it should be pretty safe.  For your GPU issue, you might also try disabling the BFI_INT optimization as I mentioned above.

It might be nice to "appoint" a new maintainer of vanitygen, or at least collect all the different patches and get some new builds.  For example, this fork appears to have some build/compatibility improvements, and salfter and I have added compressed address support.

[FlappySocks]

Well, I'm 99% sure no existing Bitcoin-mining ASIC can be repurposed for vanity mining.  FPGAs, maybe, but it requires more skill than GPU programming, so there just aren't that many capable of doing it, and even fewer that would do it for free.

I assumed vanity mining used the same computational process, only doing something different with the output.

[laughingbear]

If you can change source and recompile, try commenting out these two lines.  If you're handy with a hex editor, try searching for the string "cl_amd_media_ops" in your binary and overwriting with X's or some unique string, which should permanently disable BFI_INT (though I wonder if the .exe/ELF/whatever has some checksums that will throw an error when you run the program.)

I tried with the hex editor, and you guessed correctly, it threw an error.   I think this may be beyond me.