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?

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?

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.

  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.

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}$.

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.


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!

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

   -MZ

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%

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

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

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

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.

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.

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.