Pages:
Author

Topic: VanitySearch (Yet another address prefix finder) - page 35. (Read 32072 times)

sr. member
Activity: 462
Merit: 701
it is from -m 2500000 but i have to use it with that grid because i get the warning otherwise:

OK I see, I have to work on that issue, in some configuration, the memory exchange between GPU and CPU is not very well adapted.

but since we are on the topic.. could use a -v verbose option where the total number of combinations is shown and maybe the basekey every time it changes with -r ?

OK I'll add this.

can u explain what exactly [Total 2^39.22][Prob 99.7%][99% in 00:00:00] this means?
why is total growing? the probability is also changing and the third shows exactly what?

Total is the total number of key checked.
Prob is the probability to found at least 1 prefrix after Total tries (so, where you are)  according to the difficulty.
According also to key rate, the third field [99% in 00:00:00] estimate when you will reach the displayed probability of having at least 1 item found.

The difficulty calculation of case insensitive search is trickly and the program may give a bad approximation.
jr. member
Activity: 41
Merit: 1
note that the lookup size printed is the number of the 16bit hash entries of possible prefixes (not the total number of combination):


ahh ok, that clears that up, yeah it's hard without testing on a compiler Wink then i might not have understood the third for loop completely yet..  Wink

but since we are on the topic.. could use a -v verbose option where the total number of combinations is shown and maybe the basekey every time it changes with -r ?

can u explain what exactly [Total 2^39.22][Prob 99.7%][99% in 00:00:00] this means?
why is total growing? the probability is also changing and the third shows exactly what?

jr. member
Activity: 41
Merit: 1
Quote
I'm a bit surprise of your performance using -c.

it is from -m 2500000 but i have to use it with that grid because i get the warning otherwise:

Code:
Vanitysearch.exe -c -b -t 0 -gpu -gpuId 0 -g 680,512 -r 88800 -o found_1.txt -i 11Prefix.txt
VanitySearch v1.17
Search: 11 prefixes (Lookup size 38) [Compressed or Uncompressed]
Start Thu Feb  6 13:30:40 2020
Base Key: Randomly changed every 88800 Mkeys
Number of CPU thread: 0
GPU: GPU #0 GeForce RTX 2080 Ti (68x64 cores) Grid(680x512)

Warning, 2417079 items lost
Hint: Search with less prefixes, less threads (-g) or increase maxFound (-m)
[1069.30 Mkey/s][GPU 1069.30 Mkey/s][Total 2^30.99][Prob 1.9%][50% in 00:01:09][Found 0]


sr. member
Activity: 462
Merit: 701
I just added : printf("%d:%s \n",i,tmp); at line 575

Code:
    for (int j = 0; j < nbLetter; j++) {
      int mask = 1 << j;
      if (mask&i) tmp[letterpos[j]] = toupper(letter[j]);
      else         tmp[letterpos[j]] = letter[j];
    }

    printf("%d:%s \n",i,tmp);

    list.push_back(string(tmp));

It outputs correct combinations, note that the lookup size printed is the number of the 16bit hash entries of possible prefixes (not the total number of combination):

C:\C++\VanitySearch\x64\Release>VanitySearch.exe -c -stop 1abc
VanitySearch v1.17
0:1abc
1:1Abc
2:1aBc
3:1ABc
4:1abC
5:1AbC
6:1aBC
7:1ABC
Difficulty: 19627
Search: 1abc [Compressed, Case unsensitive] (Lookup size 6)
Start Thu Feb  6 13:16:48 2020
Base Key: B0384C0C93590167CF8AE3FD40E06F9065008F9DF2F2D305A21F84963467C3A
Number of CPU thread: 8

PubAddress: 1ABCE4631tuX4TCSqwRARpeJhouCkCHam5
Priv (WIF): p2pkh:L3eTmtQqjPZnBppJHi6L5c6jeLLu3yYaPQtXUFWg6tR8WbDfD4Gg
Priv (HEX): 0xBFC1EC9B163A2B5F10A1153490E222F8B8AEBAD2E0FEABACB5173CBDB6FC4C34

C:\C++\VanitySearch\x64\Release>VanitySearch.exe -c -stop 1abcd
VanitySearch v1.17
0:1abcd
1:1Abcd
2:1aBcd
3:1ABcd
4:1abCd
5:1AbCd
6:1aBCd
7:1ABCd
8:1abcD
9:1AbcD
10:1aBcD
11:1ABcD
12:1abCD
13:1AbCD
14:1aBCD
15:1ABCD
Difficulty: 569190
Search: 1abcd [Compressed, Case unsensitive] (Lookup size Cool
Start Thu Feb  6 13:23:16 2020
Base Key: 15FC12001ECE83FC425FC81BB34F5457138A92020CFB26FF510A958AC689C474
Number of CPU thread: 8

PubAddress: 1AbcD2q4EHSgP6KBynmyycxCSa5jpKwMiG
Priv (WIF): p2pkh:L3zpLCR5HeN2gsJgd6CeEY3vQJGLCpFVMzYZqgZtaMTcHeEfRkxv
Priv (HEX): 0xCA3A8604599F8FAD61A651B812CB44224864F17F298AB49E92183F4196E43E06
jr. member
Activity: 41
Merit: 1
VanitySearch.cpp:94.
I'm a bit surprise of your performance using -c.

yeah me too i have to try with less "-" options to narrow down where that performace hit comes from..

you mean Vanity.cpp:94, yeah i see that now but the pre-build list is not complete right?:
the original question arose because my 11prefix list goes from 6 digits to 16 digits and the programm said 11 prefixes and a list of 38 combinations.. the real number of combinations should be in the thousands since every digit that is not "0O1l" should open a new **2 combination of case-insensitive variants 1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024 just for a 10 digit prefix ..... 65536 for a 16 digit prefix if there is no 0O1l in there..

Vanity.cpp:546
Code:
void VanitySearch::enumCaseUnsentivePrefix(std::string s, std::vector &list)

in metatalk:
first for loop lowers, copys and saves position of all char in prefix
second for loop iterates over length with every position (using the third for loop) and push_back result
third for loop uppers all corresponding char or leaves them in lower .. in all combinations

but the third for loop doeas NOT exactly do that.. i think..

Vanity.cpp:570
Code:
int mask = 1 << j;

the bitshift is clever but it iterates 1, 2, 4, 8 .... for mask

that combined with

Vanity.cpp:571-572
Code:
if (mask&i) tmp[letterpos[j]] = toupper(letter[j]);
      else         tmp[letterpos[j]] = letter[j];

where " mask AND i " the binary addition with i iterating 0, 1, 2, 3, ...

leaves out a few combinations if i'm not mistaken (only by looking.. i don't have a compiler at the readdy for that right now, for testing, i'm not home)

1AB puts out a list of 4 combinations .. thats correct but
at the moment the prefix 1ABC puts out a list of 6 combinations where it shound be 8:
Code:
1ABC
1abc
1Abc
1aBc
1abC
1ABc
1AbC
1aBC

if u run a copy of enumCaseUnsentivePrefix where you upper in the first for loop and lower in the third for loop it should cover the char position 3 and work up to 4 char but that's it..

imlementing a recursion here is the best way i feel where you could replace the second and third for loop with something resembling:

Code:
void VanitySearch::recPrefixBuild(std::string s, std::vector &list) {
...
for ... // find first changable char position

recPrefixBuild(firstStringPart + tolower( s[changableCharPosition] ) + lastStringPart, &list) // lower and recurse
recPrefixBuild(firstStringPart + toupper( s[changableCharPosition] ) + lastStringPart, &list) // upper and recurse
}

since u call enumCaseUnsentivePrefix for every prefix seperatly it shound not eat up memory because the recursion collapses before a new prefix is called with enumCaseUnsentivePrefix. (Vanity.cpp:87 and Vanity.cpp:97)

of coure you could also brute force the recursion like:
Code:
void VanitySearch::recPrefixBuild(std::string s, std::vector &list) {
...
cut of CHAR 1  s[0] and if rest of s != NILL call recPrefixBuild(s[1..(length(s)-1), &dummyList]
copy tolower(s[0]) in front of every dummylist entry into lowerList
copy toupper(s[0]) in front of every dummylist entry into upperList
return lowerList + upperList // push_back in list of course..

}
legendary
Activity: 3696
Merit: 2219
💲🏎️💨🚓
OK, the short story is that

  • I downloaded the newest version (Ver 1.17) which was three days old.
  • Installed NVidia Ver 10.2
  • ran vanitysearch -check
  • then after some trial and error (and reading the last three pages) I have entered

    vanitysearch.exe -t 0 -gpu -stop -i find.txt -o found.txt

And it works.



Originally, I had 2114 search patterns, but I've trimmed it down to a more modest 497 search patterns.  Both were/are pulling about 60Mk/s-65Mk/s although I'm reading that with less to search there are higher speeds.  I haven't done any testing with smaller numbers of patterns.

After about nineteen hours I've found a half a dozen six letter/number files used to ensure the previous program was still working as my search list are mostly eight plus letters/number combinations long and take many days/weeks to find.
sr. member
Activity: 462
Merit: 701

is it "live" checking the case insensitive or does it pre-build a list to that few targets?


It creates a lookup table with all "pre-build" targets. VanitySearch.cpp:94.
I'm a bit surprise of your performance using -c. I tried a file with 11 prefixes and a lookup size similar to your and
It goes from 223MKeys to 169MKeys (compressed) and 83MKeys to 62MKeys (compressed + uncompressed).

jr. member
Activity: 41
Merit: 1
yeah I still can't confirm 10.0 working without problems, but since that ran longer than the 10.2 compiled one.. ?!

btw, i was paying around with my vanity targets and realised the -c is tanking performance..

Code:
VanitySearch.exe -c -b -t 0 -gpu -gpuId 0 -g 680,512 -m 2550000 -r 88800 -o found_1.txt -i 11targets.txt
VanitySearch v1.17
Search: 11 prefixes (Lookup size 38) [Compressed or Uncompressed]
Start Wed Feb  5 10:15:27 2020
Base Key: Randomly changed every 88800 Mkeys
Number of CPU thread: 0
GPU: GPU #0 GeForce RTX 2080 Ti (68x64 cores) Grid(680x512)
[132.63 Mkey/s][GPU 132.63 Mkey/s][Total 2^33.32][Prob 9.2%][50% in 00:08:19][Found 0]

it is down to like 15% from around 660 to 790 Mkeys..
is it "live" checking the case insensitive or does it pre-build a list to that few targets?
member
Activity: 382
Merit: 40
Ditty! £ $ ₹ € ¥ ¢ ≠ ÷ ™
Ok, I've got it running using

-t 0

Will have to post details a little later as I'm just doing something for the next eight or nine hours...

(At least it looked like it's working before I left)
sr. member
Activity: 462
Merit: 701
OK, I will try to install CUDA 10.2 and see what's wrong with it.
VanitySearch.sln is in the git repo:
https://github.com/JeanLucPons/VanitySearch/blob/master/VanitySearch.sln
legendary
Activity: 3696
Merit: 2219
💲🏎️💨🚓
So far I have only installed (upgraded) NVidia Cuda to Ver 10.2

I have this as my command:

Code:
VanitySearch_V1.17>vanitysearch -g 5x,128y -i find.txt -o findout.txt -stop

Not sure what I'm supposed to put at

Code:
-gpu

regardless it starts then crashes.



This is a typical output.

Code:
VanitySearch v1.17
Search: 5 prefixes (Lookup size 5) [Compressed]
Start Wed Feb  5 15:09:14 2020
Base Key: F2957B149DAE0AF5CD7D4ECBC8AC163D552EF4FD8AB9F54AC3DBF93B9EDA91F8
Number of CPU thread: 2

But nothing is written to file.



*edit* Still can't find a VanitySearch.sln file.
jr. member
Activity: 41
Merit: 1
Hey
@Jean_Luc
and

I've updated to version 10.2 of the Nvidia Cuda and tried running the program. It works for a few seconds - hangs - then crashes.  Other parts of NVidia are now asking to be updated, so am just working on them too.

yep 10.2 is the problem.. when I tried 10.0 it worked I think.. though I didn't have time jet to run it more than a few minutes.. I did not test 10.1

sr. member
Activity: 462
Merit: 701
I've updated to version 10.2 of the Nvidia Cuda and tried running the program. It works for a few seconds - hangs - then crashes.  Other parts of NVidia are now asking to be updated, so am just working on them too.

It seems that there is some problems with recent release of CUDA. I will also try to have a look at this. Thanks for you report.
legendary
Activity: 3696
Merit: 2219
💲🏎️💨🚓
Alright, where can I find a VanitySearch.sln and where can I get a Visual C++ 2017 ?

The sln file is included in the repository.
Start by cloning the repository (you need git to be installed)
git clone https://github.com/JeanLucPons/VanitySearch.git
Visual Studio community edition is freely available from the Microsoft Website (I don't know if 2017 can still be download but it should work also with 2019, if it is not working with 2019 then I'll try to make a path).
Then launch visual studio and open the sln file.

I've updated to version 10.2 of the Nvidia Cuda and tried running the program. It works for a few seconds - hangs - then crashes.  Other parts of NVidia are now asking to be updated, so am just working on them too.
sr. member
Activity: 462
Merit: 701
Alright, where can I find a VanitySearch.sln and where can I get a Visual C++ 2017 ?

The sln file is included in the repository.
Start by cloning the repository (you need git to be installed)
git clone https://github.com/JeanLucPons/VanitySearch.git
Visual Studio community edition is freely available from the Microsoft Website (I don't know if 2017 can still be download but it should work also with 2019, if it is not working with 2019 then I'll try to make a path).
Then launch visual studio and open the sln file.
legendary
Activity: 3696
Merit: 2219
💲🏎️💨🚓
Is there a windows walk through please?

The only informations available are there:
https://github.com/JeanLucPons/VanitySearch/blob/master/README.md
If you need furthers details, you can ask here.


Alright, where can I find a VanitySearch.sln and where can I get a Visual C++ 2017 ?
sr. member
Activity: 462
Merit: 701
Is there a windows walk through please?

The only informations available are there:
https://github.com/JeanLucPons/VanitySearch/blob/master/README.md
If you need furthers details, you can ask here.
legendary
Activity: 3696
Merit: 2219
💲🏎️💨🚓
Is there a windows walk through please?
sr. member
Activity: 462
Merit: 701
Hi,

What was the main reason for performance increase?

I optimized a bit the GPU code for compressed key, GPU/GPUHash.h and GPU/GPUCompute.h.
More or less, I factored a bit the HASH calculation of symmetric keys and I added some _synchthreads() in order to try to keep a best synchronization between threads. This gives me a ~5% performance increase on my hardware.

please tell me how to run on radeon rx 570?

VanitySearch supports only CUDA.

Something does not suit me here...
In the original version - four GPU's gave me a score of 6800-7000Mkeys/s.
Current version - keeping the same settings (I only replaced the .exe file) shows 42000-43000Mkeys/s.

This is not possible, especially since the prefix discovery speed has not changed and the GPUs in NVIDIA-SMI themselves show power consumption instead of 240-250W, now 190-200W.

You mean 1.16 gives  6800-7000Mkeys/s and 1.17  42000-43000Mkeys/s ?
Did you wait a bit in order to stabilize the key rate measurement ?
Could you give me your grid size(s) ?
full member
Activity: 282
Merit: 114
Something does not suit me here...
In the original version - four GPU's gave me a score of 6800-7000Mkeys/s.
Current version - keeping the same settings (I only replaced the .exe file) shows 42000-43000Mkeys/s.

This is not possible, especially since the prefix discovery speed has not changed and the GPUs in NVIDIA-SMI themselves show power consumption instead of 240-250W, now 190-200W.
Pages:
Jump to: