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

[TheRealSteve]

Does anyone know of a fast address generator? I can regex a batch myself (to look for vanity addresses), but the address generators I've written are far too slow. As a plain address generator, even vanitygen is slow. Any ideas

Are you trying to generate just any address, or vanity addresses?  oclvanitygen even on modest hardware should be able to do millions of generic addresses per second, so I'm not sure what sort of rate you're looking for.

[1713244872]

1713244872

[1713244872]

1713244872

[1713244872]

1713244872

[organofcorti]

Does anyone know of a fast address generator? I can regex a batch myself (to look for vanity addresses), but the address generators I've written are far too slow. As a plain address generator, even vanitygen is slow. Any ideas

Are you trying to generate just any address, or vanity addresses?  oclvanitygen even on modest hardware should be able to do millions of generic addresses per second, so I'm not sure what sort of rate you're looking for.

Just generic addresses, I want to regex the addresses later in a regex format I'm more familiar with. I create a few million addresses, then regex them.  I can't get oclvanitygen to run on my nvidia 750ti (on ubuntu).

I might just be using it wrong  - how do you get just plain addresses out of vanitygen?

[xhomerx10]

Does anyone know of a fast address generator? I can regex a batch myself (to look for vanity addresses), but the address generators I've written are far too slow. As a plain address generator, even vanitygen is slow. Any ideas

Are you trying to generate just any address, or vanity addresses?  oclvanitygen even on modest hardware should be able to do millions of generic addresses per second, so I'm not sure what sort of rate you're looking for.

Just generic addresses, I want to regex the addresses later in a regex format I'm more familiar with. I create a few million addresses, then regex them.  I can't get oclvanitygen to run on my nvidia 750ti (on ubuntu).

I might just be using it wrong  - how do you get just plain addresses out of vanitygen?

 You don't.  It was designed to pattern match.

[oktar]

Hi,
I have a question to oclvanitygen users.
I successfully compiled the software under Debian linux. I have old mining rig with 4 GPU.
Everything seems to work but the load of the cards is quite low: 70-90% and not stable.  Nothing that I'm used to when I recall old mining times with stable 99% load in cgminer.
How to increase the load to 99% ? It lowers performance a lot with ~80%.

Second question. I'm unsure how to read the results.
vanitygen provides simple and clear output:

Example:

Code:

./vanitygen 1tst
Difficulty: 4553521
Pattern: 1tst                                                                 
Address: 1tstajg1J32HDSVnFDpCoQ8rTCxmNRYvy
Privkey: 5KUruEhXzvmmCJuKhEUtzadNe51DgQzHuGA7EFeBM5mcwRDR2C1

oclvanitygen provides something different.

Example:

Code:

./oclvanitygen -D 0:0 -D 0:1 -D 0:2 -D 0:3 1tst
Difficulty: 4553521
Match idx: 0
CPU hash: a159f76402d9bab648b806082fbc347818825e98
GPU hash: 09cfb112e8f825a6a2ea5b6f83b96e33ac70c459
Found delta: 5955016 Start delta: 1

How to convert it to normal BTC address and private key?

I also noticed when I turn on single GPU workload rises to 97-98%.

I applied the patch and it works now however I still have shitty GPU loads. The more GPUs the less load.
With -D 0:0 -D 0:1 -D 0:2 -D 0:3 it's ~70% each, hashing with 4x GPUs only @ 56 Mkeys/s while single GPU has 26Mkeys/s.
Is that normal?

[TheRealSteve]

Just generic addresses, I want to regex the addresses later in a regex format I'm more familiar with. I create a few million addresses, then regex them.  I can't get oclvanitygen to run on my nvidia 750ti (on ubuntu).

I might just be using it wrong  - how do you get just plain addresses out of vanitygen?

You don't.  It was designed to pattern match.

Sure, but a pattern can be anything as long as it's valid, now can't it?

E.g.:

Code:

vanitygen.exe -o output.lst -F compressed -k 1

Or a regex that matches everything (not sure why you would, given the aforementioned):

Code:

vanitygen.exe -o output.lst -F compressed -k -r .*

Edit: fixed quotes, and for what it's worth - on a mobile quad core CPU the first one generated 13,700 addresses in 1 minute, so say close to 100,000/minute if I stuck it on all threads.  oclvanitygen would still be many times faster.

[organofcorti]

Just generic addresses, I want to regex the addresses later in a regex format I'm more familiar with. I create a few million addresses, then regex them.  I can't get oclvanitygen to run on my nvidia 750ti (on ubuntu).

I might just be using it wrong  - how do you get just plain addresses out of vanitygen?

You don't.  It was designed to pattern match.

Sure, but a pattern can be anything as long as it's valid, now can't it?

E.g.:

Code:

vanitygen.exe -o output.lst -F compressed -k 1

Or a regex that matches everything (not sure why you would, given the aforementioned):

Code:

vanitygen.exe -o output.lst -F compressed -k -r .*

Edit: fixed quotes, and for what it's worth - on a mobile quad core CPU the first one generated 13,700 addresses in 1 minute, so say close to 100,000/minute if I stuck it on all threads.  oclvanitygen would still be many times faster.

OK, yes you can get plain addresses if you just match the leading '1', but that's slower than matching eg '123' for some reason. On my machine, anyway.

[organofcorti]

Does anyone know of a fast address generator? I can regex a batch myself (to look for vanity addresses), but the address generators I've written are far too slow. As a plain address generator, even vanitygen is slow. Any ideas

Are you trying to generate just any address, or vanity addresses?  oclvanitygen even on modest hardware should be able to do millions of generic addresses per second, so I'm not sure what sort of rate you're looking for.

Just generic addresses, I want to regex the addresses later in a regex format I'm more familiar with. I create a few million addresses, then regex them.  I can't get oclvanitygen to run on my nvidia 750ti (on ubuntu).

I might just be using it wrong  - how do you get just plain addresses out of vanitygen?

 You don't.  It was designed to pattern match.

Which is why I started by asking: "Does anyone know of a fast address generator?"

[xhomerx10]

Does anyone know of a fast address generator? I can regex a batch myself (to look for vanity addresses), but the address generators I've written are far too slow. As a plain address generator, even vanitygen is slow. Any ideas

Are you trying to generate just any address, or vanity addresses?  oclvanitygen even on modest hardware should be able to do millions of generic addresses per second, so I'm not sure what sort of rate you're looking for.

Just generic addresses, I want to regex the addresses later in a regex format I'm more familiar with. I create a few million addresses, then regex them.  I can't get oclvanitygen to run on my nvidia 750ti (on ubuntu).

I might just be using it wrong  - how do you get just plain addresses out of vanitygen?

 You don't.  It was designed to pattern match.

Which is why I started by asking: "Does anyone know of a fast address generator?"

  Well yeah but vanitygen is fast so I didn't understand what you were asking.  Why not create a file with all the "words" you're looking to find including their variants and use the -f switch?  That way you can still use OCLvanitygen and it's a lot faster than using the CPU version and regex.

[TheRealSteve]

Why not create a file with all the "words" you're looking to find including their variants and use the -f switch?  That way you can still use OCLvanitygen and it's a lot faster than using the CPU version and regex.

Because:

I can't get oclvanitygen to run on my nvidia 750ti (on ubuntu).

I'm not seeing regular vanitygen being slower with '1' vs '123' in terms of number of addresses output per time interval.  It's certainly possible that internally it is slower just because with the former it has to go through all the code of writing out those addresses, whereas with '123' there's a bunch it can just ignore.

That said - there's probably a more appropriate address generator.. just haven't seen need to use one, and a very brief Google search shows a lot of people do recommend vanitygen run as aforementioned.

[organofcorti]

Thanks for your ideas gentlemen.

It really looks like I need to get that GPU working, eh? I should have mentioned that the sorts of results I want are very unlikely - I managed to get 1QC2KE4GZ4SZ8AnpwVT483D2E97SLHTGCG after about 8 days on an oldish CPU (sacrificing work cycles, not mine!) and I'd like to be able to get something a bit more interesting, like ^1[A-Z]{1,30}npw[A-Z]{1,30}$.

[TheRealSteve]

I do wonder if you wouldn't be better off serving the regex to vanitygen (ocl one doesn't do regex - nobody's bothered to add that to the opencl engine), given that otherwise you'll be dealing with quite large output files to match against.  Bit of a processing power vs memory thing.

If the storage+search later option is faster, I'd say remove all the pattern matching bits and only write out the address and private key (which needn't be WIF or even plaintext, binary representation of the number should do).  That should make the code a lot leaner, and certainly a lot faster.  Though given the very different scope, and the fact that vanitygen itself has some bits of code that are not necessarily optimal, I could certainly understand if this were done 'from scratch'.

[organofcorti]

I do wonder if you wouldn't be better off serving the regex to vanitygen (ocl one doesn't do regex - nobody's bothered to add that to the opencl engine), given that otherwise you'll be dealing with quite large output files to match against.  Bit of a processing power vs memory thing.

There is one advantage of batch processing - if I change my mind and want something different, I'll have a store of billions of addresses I can run the regex against (if I can get oclvanitygen running). Vanitygen is generating addresses but only keeping them if they match some criteria. Given that the storage requirements are low, if you want to do multiple vanity addresses you're better off keeping addresses that don't match your current criteria.

If you have a very unlikely string that you want to match, then having a few billion addresses already on your drive could reduce the time to find an address containing it down to a few seconds rather than weeks.

If the storage+search later option is faster, I'd say remove all the pattern matching bits and only write out the address and private key (which needn't be WIF or even plaintext, binary representation of the number should do).  That should make the code a lot leaner, and certainly a lot faster.  Though given the very different scope, and the fact that vanitygen itself has some bits of code that are not necessarily optimal, I could certainly understand if this were done 'from scratch'.

Unfortunately my coding skills are limited so it hadn't occurred to me to try that. It might be a good opportunity to learn - thanks!

[AllTheBitz]

The start number 1 can't be changed ? I want to change it to something like 3
Also   The speed of my cpu is 230 kb/s is that slow ?
Its a nice tool i get his address with it : 1BiTzCkUyBZPSVDmQCuWe5W1BKZLMzccui tip here 

[Muhammed Zakir]

The start number 1 can't be changed ? I want to change it to something like 3
Also   The speed of my cpu is 230 kb/s is that slow ?
Its a nice tool i get his address with it : 1BiTzCkUyBZPSVDmQCuWe5W1BKZLMzccui tip here 

If you change it to 3, it will be multisig address but Vanitygen made till now isn't compatible with multisig.

   -MZ

[TheRealSteve]

Also   The speed of my cpu is 230 kb/s is that slow ?

No way to tell without knowing what your CPU is, and what other people with the same or comparable CPU are getting.
This outdated page gives you some indication: https://en.bitcoin.it/wiki/Vanitygen
You can add to that list: 1.12Mkey/s on i7-4702MQ 2.2GHz
I'd definitely try to get oclvanitygen working, though - GPUs are much faster than CPUs, even most of the Intel integrated ones.

The start number 1 can't be changed ? I want to change it to something like 3

You can use the network version flag, X, to determine the output:

Code:

vanitygen.exe -X 5 3E

https://en.bitcoin.it/wiki/List_of_address_prefixes

However, as Muhammed says:

If you change it to 3, it will be multisig address but Vanitygen made till now isn't compatible with multisig.

Just because you can generate an address that looks valid, doesn't mean it is valid.  Multisig addresses specifically require the input keys to generate the appropriate address.  So if you did use the above, all you'd really have is a regular Bitcoin address..that a lot of programs are not going to recognize as such.

Best to stick to the leading '1' if you want to generate Bitcoin addresses.

[TheRealSteve]

Just to get back to the performance bit of non-ocl vanitygen (standard v0.22 lifeboat version), some figures (applicable to the i7-4702MQ 2.2GHz config).

Ran each test for 5 minutes.  Relative efficiency is based only on the number of 'found' keys in that timespan.

type	command	generated keys	'found' keys	% matched	relative efficiency
regex	vanitygen.exe -o file.lst -k -q -F compressed -r .*	21,262,638	82,797	0.38940%	98.72%
standard	vanitygen.exe -o file.lst -k -q -F compressed 1	21,534,544	83,874	0.38949%	100.00%
input list (1A,1B,..,1a,1b,..,11,12,..)	vanitygen.exe -o file.lst -k -q -F compressed -f input.lst	21,688,744	84,499	0.38960%	100.75%
case insensitive	vanitygen.exe -o file.lst -k -q -F compressed -i 1	21,917,217	85,410	0.38969%	101.83%
non-compressed	vanitygen.exe -o file.lst -k -q 1	22,324,562	87,019	0.38979%	103.75%
64-bit version	vanitygen64.exe -o file.lst -k -q -F compressed 1	27,455,567	106,980	0.38965%	127.55%
64-bit, non-compressed	vanitygen64.exe -o file.lst -k -q 1	29,042,542	113,150	0.38960%	134.90%
64-bit, non-compressed, four processes	vanitygen64.exe -o file.lst -k -q 1	104,220,011	406,105	0.38966%	484.18%

Using compressed keys adds a few percent overhead, so dropping that might be a reasonable idea (remember though that 'compressed keys' are preferred).  The 64bit version is quite a bit faster than the 32bit version as well.  Combining the two there's a pretty reasonable speed gain.  There's maybe a bit more to gain with the case-insensitive option, but I'd have to run much longer tests to see if that's a real gain or just a wee bit of luck in that run.
Running four concurrent processes was much faster still - apparently there's a good bit of overhead of code that doesn't/can't be run multithreaded when using such short prefixes.

The other thing that stands out is that even though there's a significant number of keys generated, vanitygen only selects a very, very small portion of them as matches - even though every single one of them should be valid.  This is primarily why a program that's specifically written for the task would be much better.  In fact, given how few vanitygen actually returns here, I wouldn't be surprised if one of the existing python libraries or even javascript (bitaddress.org's bulk generator is slower, but there might be some performance to gain in their implementation as well) would perform much better.  It also reminds me of that weird bounty/'rendezvous points' hunt, which - at least for CPU - might be an easier starting point for modification (if not starting from scratch)

A comparison against longer patterns:

type	command	generated keys	'found' keys	% matched	relative efficiency
'1'	vanitygen.exe -o file.lst -k -q -F compressed 1	21,534,544	83,874	0.38949%	100.00%
'1A'	vanitygen.exe -o file.lst -k -q -F compressed 1A	16,982,045	66,152	0.38954%	78.87%
'1AA'	vanitygen.exe -o file.lst -k -q -F compressed 1AA	72,843,612	49,592	0.06808%	59.13%
'1AAA'	vanitygen.exe -o file.lst -k -q -F compressed 1AAA	256,016,211	3,419	0.00134%	4.08%

One thing that stands out here is that the percentage that 'matched' is the same for patterns '1' and '1A', which I think shouldn't be the case.
The other thing is the total number of keys generated.  '1A' having generated fewer than '1', while '1AA' and '1AAA' generated more and far more respectively.

tl;dr: vanitygen is weird when used for purposes other than what it was designed for

Edit: As the above tables were made using the Lifeboat version of vanitygen, the tables again with vanilla v0.22 (note that there's no 'compressed key' support unless patched in):

type	command	generated keys	'found' keys	% matched	relative efficiency
input list (1A,1B,..,1a,1b,..,11,12,..)	vanitygen.exe -o file.lst -k -f input.txt -q 1	21,858,878	85,213	0.38983%	98.62%
regex	vanitygen.exe -o file.lst -k -r -q .*	22,057,282	85,920	0.38953%	99.44%
standard	vanitygen.exe -o file.lst -k -q 1	22,179,614	86,408	0.38958%	100.00%
case insensitive	vanitygen.exe -o file.lst -k -i -q 1	22,208,398	86,570	0.38981%	100.19%
64-bit version	vanitygen64.exe -o file.lst -k -q 1	29,060,532	113,316	0.38993%	131.14%
64-bit version, four processes	vanitygen64.exe -o file.lst -k -q 1	94,486,821	368,135	0.38962%	426.04%

type	command	generated keys	'found' keys	% matched	relative efficiency
1	vanitygen64.exe -o file.lst -k -q 1	29,060,532	113,316	0.38993%	100.00%
1A	vanitygen64.exe -o file.lst -k -q 1A	23,848,310	93,430	0.39177%	82.45%
1AA	vanitygen64.exe -o file.lst -k -q 1AA	92,005,255	63,455	0.06897%	56.00%
1AAA	vanitygen64.exe -o file.lst -k -q 1AAA	316,811,630	4,000	0.00126%	3.53%

[K1773R]

Just to get back to the performance bit of non-ocl vanitygen (standard v0.22), some figures (applicable to the i7-4702MQ 2.2GHz config).

Ran each test for 5 minutes.  Relative efficiency is based only on the number of 'found' keys in that timespan.

type	command	generated keys	'found' keys	% matched	relative efficiency
regex	vanitygen.exe -o file.lst -k -q -F compressed -r .*	21,262,638	82,797	0.38940%	98.72%
standard	vanitygen.exe -o file.lst -k -q -F compressed 1	21,534,544	83,874	0.38949%	100.00%
input list (1A,1B,..,1a,1b,..,11,12,..)	vanitygen.exe -o file.lst -k -q -F compressed -f input.lst	21,688,744	84,499	0.38960%	100.75%
case insensitive	vanitygen.exe -o file.lst -k -q -F compressed -i 1	21,917,217	85,410	0.38969%	101.83%
non-compressed	vanitygen.exe -o file.lst -k -q 1	22,324,562	87,019	0.38979%	103.75%
64-bit version	vanitygen64.exe -o file.lst -k -q -F compressed 1	27,455,567	106,980	0.38965%	127.55%
64-bit, non-compressed	vanitygen64.exe -o file.lst -k -q 1	29,042,542	113,150	0.38960%	134.90%
64-bit, non-compressed, four processes	vanitygen64.exe -o file.lst -k -q 1	104,220,011	406,105	0.38966%	484.18%

Using compressed keys adds a few percent overhead, so dropping that might be a reasonable idea (remember though that 'compressed keys' are preferred).  The 64bit version is quite a bit faster than the 32bit version as well.  Combining the two there's a pretty reasonable speed gain.  There's maybe a bit more to gain with the case-insensitive option, but I'd have to run much longer tests to see if that's a real gain or just a wee bit of luck in that run.
Running four concurrent processes was much faster still - apparently there's a good bit of overhead of code that doesn't/can't be run multithreaded when using such short prefixes.

The other thing that stands out is that even though there's a significant number of keys generated, vanitygen only selects a very, very small portion of them as matches - even though every single one of them should be valid.  This is primarily why a program that's specifically written for the task would be much better.  In fact, given how few vanitygen actually returns here, I wouldn't be surprised if one of the existing python libraries or even javascript (bitaddress.org's bulk generator is slower, but there might be some performance to gain in their implementation as well) would perform much better.  It also reminds me of that weird bounty/'rendezvous points' hunt, which - at least for CPU - might be an easier starting point for modification (if not starting from scratch)

A comparison against longer patterns:

type	command	generated keys	'found' keys	% matched	relative efficiency
'1'	vanitygen.exe -o file.lst -k -q -F compressed 1	21,534,544	83,874	0.38949%	100.00%
'1A'	vanitygen.exe -o file.lst -k -q -F compressed 1A	16,982,045	66,152	0.38954%	78.87%
'1AA'	vanitygen.exe -o file.lst -k -q -F compressed 1AA	72,843,612	49,592	0.06808%	59.13%
'1AAA'	vanitygen.exe -o file.lst -k -q -F compressed 1AAA	256,016,211	3,419	0.00134%	4.08%

One thing that stands out here is that the percentage that 'matched' is the same for patterns '1' and '1A', which I think shouldn't be the case.
The other thing is the total number of keys generated.  '1A' having generated fewer than '1', while '1AA' and '1AAA' generated more and far more respectively.

tl;dr: vanitygen is weird when used for purposes other than what it was designed for

not every input creates a valid "bitcoin address".
also, use the -t threads option instead of running multiple instances.
dont use it with winblows, its slower.
the vanitygen your using is not the standard one too
use -mtune=native

[TheRealSteve]

not every input creates a valid "bitcoin address".

Shouldn't every ECDSA key -> pubkey -> hashamahash -> base58check- > address be valid?
Granted, vanitygen might not take those exact steps - or I'm mistaken

use the -t threads option instead of running multiple instances.

By default it already runs with 8 threads on that machine, but just for kicks:

Code:

vanitygen.exe -t 8 -k -q -o out.log 1
[74.97 Kkey/s][total 903612][Found 3665]
vanitygen.exe -t 1 -k -q -o out.log 1
[70.36 Kkey/s][total 876884][Found 3412]

dont use it with winblows, its slower.

Undoubtedly, but I was looking at relative performance.  Maybe you can run some tests under AmigaOS.

the vanitygen your using is not the standard one too

Ah, you're right - I was using the lifeboat one for the 'compressed key' support.  I'll re-run (minus the compressed key tests) on v0.22 proper.  mea culpa.

use -mtune=native

Pretty sure running my own compile optimized for my system would be more efficient overall, but I'm not sure how that would affect the relative values - or the conclusion.

[K1773R]

not every input creates a valid "bitcoin address".

Shouldn't every ECDSA key -> pubkey -> hashamahash -> base58check- > address be valid?
Granted, vanitygen might not take those exact steps - or I'm mistaken

use the -t threads option instead of running multiple instances.

By default it already runs with 8 threads on that machine, but just for kicks:

Code:

vanitygen.exe -t 8 -k -q -o out.log 1
[74.97 Kkey/s][total 903612][Found 3665]
vanitygen.exe -t 1 -k -q -o out.log 1
[70.36 Kkey/s][total 876884][Found 3412]

dont use it with winblows, its slower.

Undoubtedly, but I was looking at relative performance.  Maybe you can run some tests under AmigaOS.

the vanitygen your using is not the standard one too

Ah, you're right - I was using the lifeboat one for the 'compressed key' support.  I'll re-run (minus the compressed key tests) on v0.22 proper.  mea culpa.

use -mtune=native

Pretty sure running my own compile optimized for my system would be more efficient overall, but I'm not sure how that would affect the relative values - or the conclusion.

just showing your build/windows/src is not a good combination.
A laptop with Core i5 2450M gives this:

Code:

$ ./vanitygen 1K1773R
Difficulty: 15058417127
[481.98 Kkey/s][total 2934016][Prob 0.0%][50% in 6.0h]

your CPU is far better than mine, but you only reach 70 Kkey/s.

And this is the result of a bad laptop GPU (the one in your laptop is probably also much better):

Code:

$ ./oclvanitygen 1K1773R
Difficulty: 15058417127
[1.68 Mkey/s][total 71303168][Prob 0.5%][50% in 1.7h]

[TheRealSteve]

just showing your build/windows/src is not a good combination.
A laptop with Core i5 2450M gives this:

Code:

$ ./vanitygen 1K1773R
Difficulty: 15058417127
[481.98 Kkey/s][total 2934016][Prob 0.0%][50% in 6.0h]

your CPU is far better than mine, but you only reach 70 Kkey/s.

The 70Kkey/s is for the pattern '1'.  If I try the pattern '1K1773R' I get approximately 820Kkey/s.  See the second table for related material.  Perhaps you can try the pattern '1' as well.