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

[samr7]

I just pasted version 0.2.  It should:

• Fix the regular expression problem reported by pyna and molecular.
• Add support for multi-pattern searching.

[molecular]

I just pasted version 0.2.  It should:

• Fix the regular expression problem reported by pyna and molecular.
• Add support for multi-pattern searching.

Does this mean I might've generated invalid addresses?

I imported one (the one that had "molec" in it correctly) using importprivkey. If that works, does it mean the address is ok?

[samr7]

Does this mean I might've generated invalid addresses?

The bug would cause vanitygen to output an address that didn't match your regular expression.  In any case, the output should still be a consistent address/private key pair on which you should be able to receive transactions.

I imported one (the one that had "molec" in it correctly) using importprivkey. If that works, does it mean the address is ok?

Yep, it's fine.

If you want to be absolutely sure about it, that's exactly how to check: import the private key into bitcoin and verify that bitcoin accepts the private key and derives the same address from the private key.

[bitlotto]

Pretty cool! Pretty fast too! Thanks.

[Yeti]

Thanks for this really quick vanity address generator! This morning I found my desired 1Yeti-address. Unfortunately there's somebody just generating vanity addresses to reserve firstbits for possible resale. Not watching the casing. Ugh. This sucks!

If you're (like me) looking for a cool address to be firstbitted, check first if it's not gone already. In the time bitcoind took to not find an address for me and the release of Vanitygen, this guy (or girl) grabbed those addresses just last Friday.

[dserrano5]

Problems here:

Code:

$ ./vg -r [Bb][Aa][Rr]    ## a good one
Address       : 1A6CtPf9UyTBARz6qu7aEntJJg1n7aK1wy
$ ./vg -r 1[Bb][Aa]
Regex error: (null)
No suitable regular expressions
$ ./vg -r 1a
Regex error: (null)
No suitable regular expressions
$ ./vg -r ^1
Regex error: (null)
No suitable regular expressions

I suspect it chokes on numbers:

Code:

$ ./vg -r foo1bar
Regex error: (null)
No suitable regular expressions

Edit: err no, it's more complex than that:

Code:

$ ./vg -r ^[a-z]
Regex error: (null)
No suitable regular expressions
$ ./vg -r [a-z]$
Address       : 13vfXkCGVm4DXDDf3rK4TGHr8nty6nsEhk
$ ./vg -r kk$
Regex error: (null)
No suitable regular expressions
$ ./vg -r [k]$
Regex error: (null)
No suitable regular expressions

[samr7]

Problems here:

Code:

$ ./vg -r [Bb][Aa][Rr]    ## a good one
Address       : 1A6CtPf9UyTBARz6qu7aEntJJg1n7aK1wy
$ ./vg -r 1[Bb][Aa]
Regex error: (null)
No suitable regular expressions
$ ./vg -r 1a
Regex error: (null)
No suitable regular expressions
$ ./vg -r ^1
Regex error: (null)
No suitable regular expressions

Darn it!  The return value from pcre_study() isn't being interpreted correctly.  The version of PCRE that I used to develop never returned NULL there, but apparently yours does.  The fix is simple.  I'll post a new version in a bit.  In the mean time, you can change the check after pcre_study() from "if (!regex_extra[nres])" to "if (pcre_errptr)".

Thanks for the report.

[dserrano5]

Oh, study, what an old Perlish friend .

Now it's working. Thanks for the prompt reply!

[jrmithdobbs]

I'd like to present a standalone command line vanity address generator called vanitygen.

There are plenty of quality tools to do this right now already.  So why use vanitygen?  The main reason is that it is fast, more than an order of magnitude faster than the official bitcoin client with the vanity address patch applied.  This is despite the fact that it runs on the CPU and does not use OpenCL or CUDA.  Vanitygen is also a bit more user-friendly in that it provides feedback on its rate of progress and how many keys it has checked.

I definitely believe your claims. I noticed the same thing when writing similar code (for a more generalized purpose). Care to help figure out why bitcoin proper is soooo slow doing this? I've not had time to sit down with it and profile properly since I found out a few weeks ago.

[samr7]

I definitely believe your claims. I noticed the same thing when writing similar code (for a more generalized purpose). Care to help figure out why bitcoin proper is soooo slow doing this? I've not had time to sit down with it and profile properly since I found out a few weeks ago.

I'd be happy to propose a cleaned-up version of the patch, but believe that this functionality is outside the scope of bitcoin proper.  I will guess that Gavin wrote the first generator as a patch to bitcoin not because it was the best place to put this functionality, but because bitcoin already did 95% of what he wanted and he found it easier to reuse the existing code, and also to work around the problem of importing private keys.

[jrmithdobbs]

I definitely believe your claims. I noticed the same thing when writing similar code (for a more generalized purpose). Care to help figure out why bitcoin proper is soooo slow doing this? I've not had time to sit down with it and profile properly since I found out a few weeks ago.

I'd be happy to propose a cleaned-up version of the patch, but believe that this functionality is outside the scope of bitcoin proper.  I will guess that Gavin wrote the first generator as a patch to bitcoin not because it was the best place to put this functionality, but because bitcoin already did 95% of what he wanted and he found it easier to reuse the existing code, and also to work around the problem of importing private keys.

No, I mean it can take >3-5 seconds to refill the keypool (only creating 100 keypairs) when it gets exhausted. I'm not talking about generating vanity addresses.

[samr7]

No, I mean it can take >3-5 seconds to refill the keypool (only creating 100 keypairs) when it gets exhausted. I'm not talking about generating vanity addresses.

Got it.  Ouch, that's terrible!  I can certainly see about making a patch for that.

[samr7]

I just pasted version 0.3.  It should:

• Resolve the pcre_study() bug reported by an0therlr3
• Add probability so far and time estimates suggested by davux
• Clean up the display, make it look more like phoenix miner

The new version needs to be built with "-lm" in addition to the other libraries.

[davux]

Add probability so far and time estimates suggested by davux

Works, and in a really neat way. Congratulations and thanks!

By the way, did you find anything about the single-proc behaviour? I'm not sure my laptop would handle the heat of having both CPUs working anyway, but other people with several CPUs might be interested in taking advantage of all of them.

I just pasted version 0.3.

You should maybe use git to continue developing the program. If you didn't use a revision system so far, at least create one commit per distributed revision: the initial one, 0.2, and this one.

[BitVapes]

this is cool.   I noticed it seems to only fill up 1 cpu core.  Should I kick off multiple instances so as to max out all my CPU power?   Or will it be redundant re-searching keyspace it already searched for my vanity phrase?

[phillipsjk]

No, I mean it can take >3-5 seconds to refill the keypool (only creating 100 keypairs) when it gets exhausted. I'm not talking about generating vanity addresses.

Got it.  Ouch, that's terrible!  I can certainly see about making a patch for that.

Proper entropy is hard.

Process ID is 16 bits. Unix time is about 26 bits of entropy (assuming 2 year span, second resolution). Total Entropy: 42 bits. (unless I am missing a source of entropy)

</wild ass guess>

[Ryland R. Taylor-Almanza]

Any chance a trusted member can provide a windows binary for this? I can not compile things on windows for the life of me!

[EricJ2190]

Any chance a trusted member can provide a windows binary for this? I can not compile things on windows for the life of me!

Not sure if I qualify as "trusted" but here is a quick Cygwin build: http://www.sendspace.com/file/yzsf0z

[SgtSpike]

Any chance a trusted member can provide a windows binary for this? I can not compile things on windows for the life of me!

Not sure if I qualify as "trusted" but here is a quick Cygwin build: http://www.sendspace.com/file/yzsf0z

Thanks.  I get this error though:

assertion "check_upper || ((bnlow2 == NULL) && (bnhigh2 == NULL))" failed: file
"vanitygen.c", line 482, function: get_prefix_ranges
    113 [sig] vanitygen 956 open_stackdumpfile: Dumping stack trace to vanitygen
.exe.stackdump

[error]

Any chance a trusted member can provide a windows binary for this? I can not compile things on windows for the life of me!

Not sure if I qualify as "trusted" but here is a quick Cygwin build: http://www.sendspace.com/file/yzsf0z

Thanks.  I get this error though:

assertion "check_upper || ((bnlow2 == NULL) && (bnhigh2 == NULL))" failed: file
"vanitygen.c", line 482, function: get_prefix_ranges
    113 [sig] vanitygen 956 open_stackdumpfile: Dumping stack trace to vanitygen
.exe.stackdump

You probably should paste that file somewhere.