Bitcoin Forum
December 07, 2016, 10:40:01 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 [101] 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 ... 155 »
  Print  
Author Topic: Vanitygen: Vanity bitcoin address generator/miner [v0.22]  (Read 809015 times)
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
February 25, 2015, 11:40:08 PM
 #2001

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?


Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
1481107201
Hero Member
*
Offline Offline

Posts: 1481107201

View Profile Personal Message (Offline)

Ignore
1481107201
Reply with quote  #2

1481107201
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481107201
Hero Member
*
Offline Offline

Posts: 1481107201

View Profile Personal Message (Offline)

Ignore
1481107201
Reply with quote  #2

1481107201
Report to moderator
xhomerx10
Legendary
*
Offline Offline

Activity: 1134


I've never had an Alt.


View Profile
February 25, 2015, 11:51:50 PM
 #2002

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.


Puțin dai, puțin primești.
oktar
Jr. Member
*
Offline Offline

Activity: 45


View Profile
February 25, 2015, 11:59:18 PM
 #2003

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
Hero Member
*****
Offline Offline

Activity: 686

FUN > ROI


View Profile
February 26, 2015, 12:01:44 AM
 #2004

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
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
February 26, 2015, 12:15:50 AM
 #2005

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.


Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
organofcorti
Donator
Legendary
*
Offline Offline

Activity: 1960


Poor impulse control.


View Profile WWW
February 26, 2015, 12:16:34 AM
 #2006

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?"


Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
xhomerx10
Legendary
*
Offline Offline

Activity: 1134


I've never had an Alt.


View Profile
February 26, 2015, 12:29:15 AM
 #2007

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.



Puțin dai, puțin primești.
TheRealSteve
Hero Member
*****
Offline Offline

Activity: 686

FUN > ROI


View Profile
February 26, 2015, 01:25:48 AM
 #2008

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 Offline

Activity: 1960


Poor impulse control.


View Profile WWW
February 26, 2015, 01:52:32 AM
 #2009

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





Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
TheRealSteve
Hero Member
*****
Offline Offline

Activity: 686

FUN > ROI


View Profile
February 26, 2015, 02:42:08 AM
 #2010

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 Offline

Activity: 1960


Poor impulse control.


View Profile WWW
February 26, 2015, 03:38:46 AM
 #2011

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!


Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
AllTheBitz
Full Member
***
Offline Offline

Activity: 229



View Profile
February 26, 2015, 06:16:54 AM
 #2012

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

▓▓▓▓   New Real-time Cryptocurrency Exchange            → CREATE  ACCOUNT ▓▓▓▓
▅▅▅▅▅▅▅▅▅▅▅▅▅▅▅▅▅▅▅▅▅▅▅  BIT-X.com  ▅▅▅▅▅▅▅▅▅▅▅▅▅▅▅▅▅▅▅▅▅▅
▓▓▓▓   Supported Currencies: BTC, LTC, USD, EUR, GBP → OFFICIAL THREAD ▓▓▓▓
Muhammed Zakir
Hero Member
*****
Offline Offline

Activity: 518


Bit-x.com - Fast & Easy Trade with Low Fees!


View Profile WWW
February 26, 2015, 10:57:25 AM
 #2013

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

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

   -MZ

TheRealSteve
Hero Member
*****
Offline Offline

Activity: 686

FUN > ROI


View Profile
February 26, 2015, 12:36:17 PM
 #2014

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
Hero Member
*****
Offline Offline

Activity: 686

FUN > ROI


View Profile
February 26, 2015, 03:32:53 PM
 #2015

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.
typecommand
generated keys
'found' keys
% matched
relative efficiency
regexvanitygen.exe -o file.lst -k -q -F compressed -r .*
21,262,638
82,797
0.38940%
98.72%
standardvanitygen.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 insensitivevanitygen.exe -o file.lst -k -q -F compressed -i 1
21,917,217
85,410
0.38969%
101.83%
non-compressedvanitygen.exe -o file.lst -k -q 1
22,324,562
87,019
0.38979%
103.75%
64-bit versionvanitygen64.exe -o file.lst -k -q -F compressed 1
27,455,567
106,980
0.38965%
127.55%
64-bit, non-compressedvanitygen64.exe -o file.lst -k -q 1
29,042,542
113,150
0.38960%
134.90%
64-bit, non-compressed, four processesvanitygen64.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): https://github.com/hipio/rpoints-FiatKiller

A comparison against longer patterns:
typecommand
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


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):
typecommand
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%
regexvanitygen.exe -o file.lst -k -r -q .*
22,057,282
85,920
0.38953%
99.44%
standardvanitygen.exe -o file.lst -k -q 1
22,179,614
86,408
0.38958%
100.00%
case insensitivevanitygen.exe -o file.lst -k -i -q 1
22,208,398
86,570
0.38981%
100.19%
64-bit versionvanitygen64.exe -o file.lst -k -q 1
29,060,532
113,316
0.38993%
131.14%
64-bit version, four processesvanitygen64.exe -o file.lst -k -q 1
94,486,821
368,135
0.38962%
426.04%
typecommand
generated keys
'found' keys
% matched
relative efficiency
1vanitygen64.exe -o file.lst -k -q 1
29,060,532
113,316
0.38993%
100.00%
1Avanitygen64.exe -o file.lst -k -q 1A
23,848,310
93,430
0.39177%
82.45%
1AAvanitygen64.exe -o file.lst -k -q 1AA
92,005,255
63,455
0.06897%
56.00%
1AAAvanitygen64.exe -o file.lst -k -q 1AAA
316,811,630
4,000
0.00126%
3.53%

K1773R
Legendary
*
Offline Offline

Activity: 1526


/dev/null


View Profile
February 26, 2015, 04:42:18 PM
 #2016

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.
typecommand
generated keys
'found' keys
% matched
relative efficiency
regexvanitygen.exe -o file.lst -k -q -F compressed -r .*
21,262,638
82,797
0.38940%
98.72%
standardvanitygen.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 insensitivevanitygen.exe -o file.lst -k -q -F compressed -i 1
21,917,217
85,410
0.38969%
101.83%
non-compressedvanitygen.exe -o file.lst -k -q 1
22,324,562
87,019
0.38979%
103.75%
64-bit versionvanitygen64.exe -o file.lst -k -q -F compressed 1
27,455,567
106,980
0.38965%
127.55%
64-bit, non-compressedvanitygen64.exe -o file.lst -k -q 1
29,042,542
113,150
0.38960%
134.90%
64-bit, non-compressed, four processesvanitygen64.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): https://github.com/hipio/rpoints-FiatKiller

A comparison against longer patterns:
typecommand
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
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]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
TheRealSteve
Hero Member
*****
Offline Offline

Activity: 686

FUN > ROI


View Profile
February 26, 2015, 05:14:07 PM
 #2017

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

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
Legendary
*
Offline Offline

Activity: 1526


/dev/null


View Profile
February 26, 2015, 05:19:50 PM
 #2018

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

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]

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
TheRealSteve
Hero Member
*****
Offline Offline

Activity: 686

FUN > ROI


View Profile
February 26, 2015, 07:33:23 PM
 #2019

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.

Kangaderoo
Member
**
Offline Offline

Activity: 79


View Profile
February 26, 2015, 08:13:50 PM
 #2020

Quote
Shouldn't every ECDSA key -> pubkey -> hashamahash -> base58check- > address be valid?
This is correct, every key should give a valid address... that is if the all calculations were fully completed.
vanitygen doesn't complete address for the check-sum part. These last bytes are all set to 0 to make sure the length is correct.
The first part of the generated address ~25 chars will not change due to this check-sum.
By skipping this part a lot of speed is gained when searching for longer match.
(this part is actually always executed in the -regex mode, the speed difference can be observed)

Only when a match is found the checksum is calculated en and the WIF and final address is stored.
When matching a valid bitcoin address i.e. just the leading "1" this match requires the check-sum to be generated.
This part is currently not as optimized for speed as the generator part; for the function of vanitygen this optimization is actually not needed.

On the CPU the hashing is done in batches of 256 ECDSA keys, I have to recheck the code but I think that when a match is found
the remaining 255 might no longer be checked/validated.
The ECDSA part of the generation is more than 70% of the cpu time.
Probably the reason the "1" and "1A" are relative equal in speed, statistically each batch will have about 10 "1A" matches.

The ECSDA engine and the hashing up to the checksum is very optimized.
When optimizing the checksum and base58 part as well, skipping the match check, just storing all results to file would make
this prog a faster 'any address' generator.




 

Slow but steady Android coin mining with NeoNeonMiner
BTC:1NeoArmnGyWHKfbje9JNWqw3tquMY7jHCw
Pages: « 1 ... 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 [101] 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 ... 155 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!