Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22] - page 190. (Read 1153619 times)
Any chance a trusted member can provide a windows binary for this? I can not compile things on windows for the life of me!
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)
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?
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.
I just pasted version 0.3. It should:
The new version needs to be built with "-lm" in addition to the other libraries.
- 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.
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.
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.
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.
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.
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.
Oh, study, what an old Perlish friend 
.
Now it's working. Thanks for the prompt reply!
.Now it's working. Thanks for the prompt reply!
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.
Problems here:
I suspect it chokes on numbers:
Edit: err no, it's more complex than that:
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
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.
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.
Pretty cool! Pretty fast too! Thanks.
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.
Quote
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.
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?
I just pasted version 0.2. It should:
- Fix the regular expression problem reported by pyna and molecular.
- Add support for multi-pattern searching.
I think the generate_address_regex() function is broken. Looks like &b58[p] is calculated incorrectly.
I stuck a printf right before output_match() is called:
./vanitygen -r 1.{26}XX
Before output_match: 1H6d1q8niPVvci5zGnpbTkRfaBhWhWSXX5
After output_match: 1H6d1q8niPVvci5zGnpbTkRfaBhWhXcbEn
The address that the regex is being compared to is never a valid address, and the (valid) end address always differs in the last few characters.
Took me the longest time to figure out this was why all my regexes with $ in it behaved ... unexpectedly.
I stuck a printf right before output_match() is called:
./vanitygen -r 1.{26}XX
Before output_match: 1H6d1q8niPVvci5zGnpbTkRfaBhWhWSXX5
After output_match: 1H6d1q8niPVvci5zGnpbTkRfaBhWhXcbEn
The address that the regex is being compared to is never a valid address, and the (valid) end address always differs in the last few characters.
Took me the longest time to figure out this was why all my regexes with $ in it behaved ... unexpectedly.
This reply was just merged here.
maybe I found a bug, or maybe I'm using regex wrongly:
"./vanitygen/vanitygen -r [Mm]oL[Ee][Cc]" gave me 1H3fttgZCe89zhViCRmk7DX8JmoLJ2mvTV (missing "ec")
found 1BYYdM3vfndwmoLec6tQjcx7sAeLRxTvTq with the same command
"./vanitygen/vanitygen -r [Mm]oL[Ee][Cc]" gave me 1H3fttgZCe89zhViCRmk7DX8JmoLJ2mvTV (missing "ec")
found 1BYYdM3vfndwmoLec6tQjcx7sAeLRxTvTq with the same command
Yep, that's a bug! The regular expression search loop incorrectly generates the lower four byte test code.
I'll post a new version in a bit with a fix for that problem.
Thanks for pointing it out.
maybe I found a bug, or maybe I'm using regex wrongly:
"./vanitygen/vanitygen -r [Mm]oL[Ee][Cc]" gave me 1H3fttgZCe89zhViCRmk7DX8JmoLJ2mvTV (missing "ec")
found 1BYYdM3vfndwmoLec6tQjcx7sAeLRxTvTq with the same command
"./vanitygen/vanitygen -r [Mm]oL[Ee][Cc]" gave me 1H3fttgZCe89zhViCRmk7DX8JmoLJ2mvTV (missing "ec")
found 1BYYdM3vfndwmoLec6tQjcx7sAeLRxTvTq with the same command
Jump to: