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

[sgravina]

I lost my wallet dat but I still remember my bitcoin Address, can I recover it using vanity?

Yes, you just need one other tool, a time machine.  You generate a very long time and use it to create the bitcoin address you remember.  It will also create the private key that goes with that address.  I forget how much time you need but it is something like all the time in the world.

[1714107470]

1714107470

[1714107470]

1714107470

[1714107470]

1714107470

[1714107470]

1714107470

[pyromaniac]

I lost my wallet dat but I still remember my bitcoin Address, can I recover it using vanity?

Not even if you had all the computing power on the planet...

How did you loose it? If you accidentally deleted or formatted it there's still a chance you can recover it.

My HDD was crushed by a power surge, because PSU load was too high.

[crazyates]

My HDD was crushed by a power surge, because PSU load was too high.

See my Sig.  
 |
 |
 V

[pyromaniac]

My HDD was crushed by a power surge, because PSU load was too high.

See my Sig.  
 |
 |
 V

10x

[Remember remember the 5th of November]

Bitcoin also uses OpenSSL, and I noticed that they feed OpenSSL a seed on Windows. Is this perhaps required for Vanitygen for Windows, too(unless it already uses it)?

The OpenSSL documentation also states

OpenSSL makes sure that the PRNG state is unique for each thread. On systems that provide /dev/urandom, the randomness device is used to seed the PRNG transparently. However, on all other systems, the application is responsible for seeding the PRNG by calling RAND_add(), RAND_egd(3) or RAND_load_file(3).

Then check out this thread https://bitcointalk.org/index.php?topic=113496.0

[gyverlb]

Just noticed a problem with the latest fizzisist fork on a 6 GPU rig (5870 and 5970).
Got this:

Code:

clEnqueueNDRange(0): CL_OUT_OF_RESOURCES
Device: Cypress
Vendor: Advanced Micro Devices, Inc. (1002)
Driver: CAL 1.4.1720
Profile: FULL_PROFILE
Version: OpenCL 1.2 AMD-APP (923.1)
Max compute units: 20
Max workgroup size: 256
Global memory: 536870912
Max allocation: 134217728
clEnqueueNDRange(0): CL_OUT_OF_RESOURCES
Device: Cypress
Vendor: Advanced Micro Devices, Inc. (1002)
Driver: CAL 1.4.1720
Profile: FULL_PROFILE
Version: OpenCL 1.2 AMD-APP (923.1)
Max compute units: 20
Max workgroup size: 256
Global memory: 536870912
Max allocation: 134217728

and oclvanityminer stopped working (no updated Key/s stats and GPU load went to 0 and temp went down)

[gyverlb]

Note : a simple restart of oclvanityminer made it mine for vanity addresses again.

[fizzisist]

Just noticed a problem with the latest fizzisist fork on a 6 GPU rig (5870 and 5970).
Got this:

Code:

clEnqueueNDRange(0): CL_OUT_OF_RESOURCES
Device: Cypress
Vendor: Advanced Micro Devices, Inc. (1002)
Driver: CAL 1.4.1720
Profile: FULL_PROFILE
Version: OpenCL 1.2 AMD-APP (923.1)
Max compute units: 20
Max workgroup size: 256
Global memory: 536870912
Max allocation: 134217728
clEnqueueNDRange(0): CL_OUT_OF_RESOURCES
Device: Cypress
Vendor: Advanced Micro Devices, Inc. (1002)
Driver: CAL 1.4.1720
Profile: FULL_PROFILE
Version: OpenCL 1.2 AMD-APP (923.1)
Max compute units: 20
Max workgroup size: 256
Global memory: 536870912
Max allocation: 134217728

and oclvanityminer stopped working (no updated Key/s stats and GPU load went to 0 and temp went down)

Thanks for reporting. I still haven't had a chance to really test my latest changes out, so I suggest you stick with samr7's original for now, at least until I submit a pull request. Probably something wrong with how I put the thread to sleep...

[gyverlb]

Just noticed a problem with the latest fizzisist fork on a 6 GPU rig (5870 and 5970).
Got this:

Code:

clEnqueueNDRange(0): CL_OUT_OF_RESOURCES
Device: Cypress
Vendor: Advanced Micro Devices, Inc. (1002)
Driver: CAL 1.4.1720
Profile: FULL_PROFILE
Version: OpenCL 1.2 AMD-APP (923.1)
Max compute units: 20
Max workgroup size: 256
Global memory: 536870912
Max allocation: 134217728
clEnqueueNDRange(0): CL_OUT_OF_RESOURCES
Device: Cypress
Vendor: Advanced Micro Devices, Inc. (1002)
Driver: CAL 1.4.1720
Profile: FULL_PROFILE
Version: OpenCL 1.2 AMD-APP (923.1)
Max compute units: 20
Max workgroup size: 256
Global memory: 536870912
Max allocation: 134217728

and oclvanityminer stopped working (no updated Key/s stats and GPU load went to 0 and temp went down)

Thanks for reporting. I still haven't had a chance to really test my latest changes out, so I suggest you stick with samr7's original for now, at least until I submit a pull request. Probably something wrong with how I put the thread to sleep...

Same problem just happened with smar7's version.

[Remember remember the 5th of November]

I've had it too. It's a driver issue. Update the drivers if you have not done so, or downgrade to an earlier version.

[kaerf]

question about the [50% in XXX] number.

when I run oclvanityminer i get one number for XXX, but if I manually plug in the public key and pattern to oclvanitygen, i get a very different XXX number. the one from oclvanityminer reports in "hours" while oclvanitygen reports in "years".

i haven't read this whole thread so i might missed it somewhere, but aren't those two values supposed to be the same since we're still basically solo mining with oclvanityminer?

[fizzisist]

question about the [50% in XXX] number.

when I run oclvanityminer i get one number for XXX, but if I manually plug in the public key and pattern to oclvanitygen, i get a very different XXX number. the one from oclvanityminer reports in "hours" while oclvanitygen reports in "years".

i haven't read this whole thread so i might missed it somewhere, but aren't those two values supposed to be the same since we're still basically solo mining with oclvanityminer?

Oclvanityminer will search for many patterns belonging to the same public key (ie submitted by the same person). The difficulty of finding any match is what oclvanityminer is reporting, and this is lower than for finding any single, specific match alone.

[cambda]

question about the [50% in XXX] number.

when I run oclvanityminer i get one number for XXX, but if I manually plug in the public key and pattern to oclvanitygen, i get a very different XXX number. the one from oclvanityminer reports in "hours" while oclvanitygen reports in "years".

i haven't read this whole thread so i might missed it somewhere, but aren't those two values supposed to be the same since we're still basically solo mining with oclvanityminer?

Oclvanityminer will search for many patterns belonging to the same public key (ie submitted by the same person). The difficulty of finding any match is what oclvanityminer is reporting, and this is lower than for finding any single, specific match alone.

First make sure GPU is used, you can see verbose output with -v
If CPU is used (much lower Key/s) use device specifier -d or -D  like -D 0:0 or -d 0

to list all patterns for a specific public key, use -f patternfile.txt
put in the file all patterns, one pattern per line

use -k to continue search after you found match

The speeds should be the same, i tried it myselves and i have the same speeds

[kaerf]

Oclvanityminer will search for many patterns belonging to the same public key (ie submitted by the same person). The difficulty of finding any match is what oclvanityminer is reporting, and this is lower than for finding any single, specific match alone.

thanks. didn't know oclvanityminer had that feature already (i read somewhere in this thread that it was suggested).

[Lurk]

i have an old laptop   its saying it will take 42 days to generate the address....is this normal....and will it harm my computer?

[crazyates]

i have an old laptop   its saying it will take 42 days to generate the address....is this normal....and will it harm my computer?

Depend on how fast you're hashing, and what address you're trying to find. I can find a 1xxx key in seconds, but a 1xxxxxxxx key would take years.

[scrybe]

Very cool program, thanks samr7!

I got lucky and generated my first case sensitive 5 letter vanity address in 24 hours (50% in 9.3 days)

I had to use CPU since my GPU is a Pitcairn, has anyone got the 7k AMD series working through opencl yet?

(no tips for now cause I'm illiquid in BTC, but I'll get you sometime after I get unlocked and working again.)

[JackH]

So is it fair to assume that getting a long address such as xxxxxxxxxxxxxxx is going to take very very long time and is out of the question for a regular cpu?

Is there an option to use mining equipment to create a vanity address? I got two FPGA boards that are pushing out very little BTC, and I may as well just use them to make a cool sounding BTC address instead. Possible?

[deepceleron]

So is it fair to assume that getting a long address such as xxxxxxxxxxxxxxx is going to take very very long time and is out of the question for a regular cpu?

Is there an option to use mining equipment to create a vanity address? I got two FPGA boards that are pushing out very little BTC, and I may as well just use them to make a cool sounding BTC address instead. Possible?

It would be possible with an FPGA, but not your FPGA miner, which was specifically made for mining.

Mining iteratively changes four bytes in a 512 byte data set and hashes it twice using the SHA256() algorithm, it then compares the beginning of the resulting hash to see if it contains all zero bits, and returns the value of the hashed data that met the challenge. This is likely all the FPGA is programmed to do.

Bitcoin address requires multiple steps with different algorithms and different criteria:

Generate a cryptographically secure random 64 bit private key.
Iterate through multiple increments of this key.
For each iteration, generate a public bitcoin address from the key:

• Generate a ECDSA secp256k1 public key for the private key
• SHA256 hash the public key
• RipeMD160 hash the above result
• SHA256 hash the result twice to generate a checksum
• Convert to a Base58 address prefix

check result against all vanity criteria being searched for, if not, do it all again.

You can see this requires much more code and algorithms than mining. So no.

[scrybe]

...

• Generate a ECDSA secp256k1 public key for the private key
• SHA256 hash the public key
• RipeMD160 hash the above result
• SHA256 hash the result twice to generate a checksum
• Convert to a Base58 address prefix

check result against all vanity criteria being searched for, if not, do it all again.

You can see this requires much more code and algorithms than mining. So no.

Is this list accurate? (IHNRTFS)

Wouldn't it be more efficient to convert the target pattern into hex for a case sensitive search? For case insensitive it might be doable, but harder.