TheRealSteve
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2015, 11:31:38 PM |
|
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.
|
|
|
|
organofcorti
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2015, 11:40:08 PM |
|
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
Legendary
Offline
Activity: 3962
Merit: 8580
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2015, 11:51:50 PM |
|
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
Newbie
Offline
Activity: 53
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 25, 2015, 11:59:18 PM |
|
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: ./vanitygen 1tst Difficulty: 4553521 Pattern: 1tst Address: 1tstajg1J32HDSVnFDpCoQ8rTCxmNRYvy Privkey: 5KUruEhXzvmmCJuKhEUtzadNe51DgQzHuGA7EFeBM5mcwRDR2C1
oclvanitygen provides something different. Example: ./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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2015, 12:01:44 AM |
|
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.: vanitygen.exe -o output.lst -F compressed -k 1 Or a regex that matches everything (not sure why you would, given the aforementioned): 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
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2015, 12:15:50 AM |
|
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.: vanitygen.exe -o output.lst -F compressed -k 1 Or a regex that matches everything (not sure why you would, given the aforementioned): 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
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2015, 12:16:34 AM |
|
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
Legendary
Offline
Activity: 3962
Merit: 8580
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2015, 12:29:15 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2015, 01:25:48 AM |
|
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
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2015, 01:52:32 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2015, 02:42:08 AM |
|
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
Donator
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2015, 03:38:46 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2015, 06:16:54 AM |
|
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 ![Grin](https://bitcointalk.org/Smileys/default/grin.gif)
|
|
|
|
Muhammed Zakir
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2015, 10:57:25 AM |
|
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 ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) If you change it to 3, it will be multisig address but Vanitygen made till now isn't compatible with multisig. -MZ
|
|
|
|
TheRealSteve
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2015, 12:36:17 PM |
|
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/VanitygenYou 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: https://en.bitcoin.it/wiki/List_of_address_prefixesHowever, 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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2015, 03:32:53 PM Last edit: December 14, 2017, 04:45:02 PM by achow101 |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
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
Legendary
Offline
Activity: 1792
Merit: 1008
/dev/null
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2015, 04:42:18 PM Last edit: December 14, 2017, 04:45:15 PM by achow101 |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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
|
[GPG Public Key]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
TheRealSteve
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2015, 05:14:07 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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: 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
Legendary
Offline
Activity: 1792
Merit: 1008
/dev/null
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2015, 05:19:50 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) 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: 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: $ ./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): $ ./oclvanitygen 1K1773R Difficulty: 15058417127 [1.68 Mkey/s][total 71303168][Prob 0.5%][50% in 1.7h]
|
[GPG Public Key]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
TheRealSteve
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 26, 2015, 07:33:23 PM |
|
just showing your build/windows/src is not a good combination. A laptop with Core i5 2450M gives this: $ ./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.
|
|
|
|
|