Bitcoin Forum
April 26, 2024, 02:40:50 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 [28] 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 »
  Print  
Author Topic: VanitySearch (Yet another address prefix finder)  (Read 31051 times)
Jean_Luc (OP)
Sr. Member
****
Offline Offline

Activity: 462
Merit: 696


View Profile
February 05, 2020, 06:09:35 AM
 #541

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

Posts: 1714099250

View Profile Personal Message (Offline)

Ignore
1714099250
Reply with quote  #2

1714099250
Report to moderator
1714099250
Hero Member
*
Offline Offline

Posts: 1714099250

View Profile Personal Message (Offline)

Ignore
1714099250
Reply with quote  #2

1714099250
Report to moderator
1714099250
Hero Member
*
Offline Offline

Posts: 1714099250

View Profile Personal Message (Offline)

Ignore
1714099250
Reply with quote  #2

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

Posts: 1714099250

View Profile Personal Message (Offline)

Ignore
1714099250
Reply with quote  #2

1714099250
Report to moderator
1714099250
Hero Member
*
Offline Offline

Posts: 1714099250

View Profile Personal Message (Offline)

Ignore
1714099250
Reply with quote  #2

1714099250
Report to moderator
1714099250
Hero Member
*
Offline Offline

Posts: 1714099250

View Profile Personal Message (Offline)

Ignore
1714099250
Reply with quote  #2

1714099250
Report to moderator
Timelord2o67
Member
**
Offline Offline

Activity: 372
Merit: 39

Ditty! £ $ ₹ € ¥ ¢ ≠ ÷ ™


View Profile
February 05, 2020, 06:39:15 AM
 #542

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)

.★☆★ UNPAID ADVERTISEMENTS: ★☆★ ❖ Get Paid in BitCoin .
.CoinPlaza Exchange (IT)  ★☆★ .
.❖ Win Free Bitcoins every hour! - www.freebitco.in   .
bangbumbang
Jr. Member
*
Offline Offline

Activity: 41
Merit: 1


View Profile
February 05, 2020, 09:50:48 AM
 #543

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?
Jean_Luc (OP)
Sr. Member
****
Offline Offline

Activity: 462
Merit: 696


View Profile
February 05, 2020, 10:44:30 AM
 #544


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).

Timelord2067
Legendary
*
Offline Offline

Activity: 3654
Merit: 2216


💲🏎️💨🚓


View Profile
February 06, 2020, 12:18:41 AM
 #545

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.

bangbumbang
Jr. Member
*
Offline Offline

Activity: 41
Merit: 1


View Profile
February 06, 2020, 11:57:18 AM
Last edit: February 06, 2020, 12:24:23 PM by bangbumbang
 #546

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<std::string> &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<std::string> &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<std::string> &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..

}
Jean_Luc (OP)
Sr. Member
****
Offline Offline

Activity: 462
Merit: 696


View Profile
February 06, 2020, 12:30:33 PM
 #547

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
bangbumbang
Jr. Member
*
Offline Offline

Activity: 41
Merit: 1


View Profile
February 06, 2020, 12:33:20 PM
 #548

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]


bangbumbang
Jr. Member
*
Offline Offline

Activity: 41
Merit: 1


View Profile
February 06, 2020, 12:44:26 PM
 #549

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?

Jean_Luc (OP)
Sr. Member
****
Offline Offline

Activity: 462
Merit: 696


View Profile
February 06, 2020, 01:10:56 PM
 #550

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.
bangbumbang
Jr. Member
*
Offline Offline

Activity: 41
Merit: 1


View Profile
February 06, 2020, 05:20:11 PM
 #551

Quote
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.

OK I'll add this.

2x thx

Quote
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.


maybe the Prob and the third could go in there own line and extend the information a little bit like

GPU: GPU #0 GeForce RTX 2080 Ti (68x64 cores) Grid(544x512)
[Prob 0.000000000000000000000000000000000000000001%]
[50% in 0040 years 124 days 33 minutes 50 seconds]
[719.57 Mkey/s][GPU 719.57 Mkey/s][Total 2^40.88][Found 0]

where prob is the entire keyspace divided by number of addresses or prexifes currently used ?!?! that would be a good "indicator" i think
and the time to find something just a little more readable or something along that line..

at the moment
[Prob 0.0%][50% in 4.46424e+31y]
Prob always stays the same when searching for addresses and 4.xxx+31y is also not that informative.
Timelord2067
Legendary
*
Offline Offline

Activity: 3654
Merit: 2216


💲🏎️💨🚓


View Profile
February 07, 2020, 06:50:56 AM
 #552

Sorry if this has been asked already, but is it possible to update the search text file with new prefix options while the program is running, or will it require a restart? (is that part of the base key creation?)

bangbumbang
Jr. Member
*
Offline Offline

Activity: 41
Merit: 1


View Profile
February 07, 2020, 08:48:36 AM
Merited by nc50lc (1)
 #553

as far as i can see it is only loaded b4 the calculation and then not used again... so a restart would be required
Dabs
Legendary
*
Offline Offline

Activity: 3416
Merit: 1912


The Concierge of Crypto


View Profile
February 07, 2020, 01:28:57 PM
 #554

Restart or no restart, it wouldn't matter all that much anyway since generating millions of keys per second and finding a matching prefix (or postfix, or middle fix or whatever) is a probability.

Stop. Add. Start. It will then start finding from a random spot. I believe it randomizes the search after every few million, or at least that's what the original vanitygen did.

nc50lc
Legendary
*
Offline Offline

Activity: 2394
Merit: 5535


Self-proclaimed Genius


View Profile
February 07, 2020, 01:38:26 PM
 #555

Restart or no restart, it wouldn't matter all that much anyway since generating millions of keys per second and finding a matching prefix (or postfix, or middle fix or whatever) is a probability.
He must be talking about the -i argument that specifies a text file with a list of prefixes.

If that's the case, bangbumbang is correct because
during my test, it didn't changed the queue once I've edited my text file while vanityseach is running.

.
.HUGE.
▄██████████▄▄
▄█████████████████▄
▄█████████████████████▄
▄███████████████████████▄
▄█████████████████████████▄
███████▌██▌▐██▐██▐████▄███
████▐██▐████▌██▌██▌██▌██
█████▀███▀███▀▐██▐██▐█████

▀█████████████████████████▀

▀███████████████████████▀

▀█████████████████████▀

▀█████████████████▀

▀██████████▀▀
█▀▀▀▀











█▄▄▄▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
.
CASINSPORTSBOOK
▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
▀▀▀▀█











▄▄▄▄█
bangbumbang
Jr. Member
*
Offline Offline

Activity: 41
Merit: 1


View Profile
February 15, 2020, 08:40:15 AM
 #556



I have more items lost than prefixes
Search: 2367367 prefixes
Warning, 68214971 items lost
... and still found something in late

you could still use -m 64000000 or is your performance tanking ?
Jean_Luc (OP)
Sr. Member
****
Offline Offline

Activity: 462
Merit: 696


View Profile
February 15, 2020, 04:52:38 PM
 #557

"Items lost" refers to items found by the GPU that match the lookup table. It is not only  link to the number of prefixes your search, but also to the number of threads.
When you have a lookup size of 65536, each GPU thread will return 6*1024 items.
With -g 88,128 and a lookup size of 64660, the number of items found by the GPU is (in average) 6*1024*88*128*64660/65536 = 68 280 960‬ and cannot exceed 6*1024*88*128*65536.
This has to be improved.
Firebox
Jr. Member
*
Offline Offline

Activity: 59
Merit: 3


View Profile
February 15, 2020, 10:00:28 PM
 #558

in this tests i found interesting address 1111111111111111111114oLvT2
its shorter than typical P2PKH  1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2
and is not random generated
This is very well known address with Public Key hash 0000000000000000000000000000000000000000.
Project BULK
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
February 28, 2020, 06:10:15 PM
 #559

Please tell me! What system is needed for your program to work (Vanity Search) 32 bit or 64 bit?
shlomogold
Jr. Member
*
Offline Offline

Activity: 75
Merit: 2


View Profile
March 02, 2020, 12:32:09 PM
Last edit: March 02, 2020, 10:15:19 PM by shlomogold
 #560

Bonjour Jean Luc,

after reading the description it is still not clear for me if you can do multiple addresses search at once, when you set certain prefix i.e. 1xxxxxx and then have all of them found filled in your list of addresses?
1xxxxx1, 1xxxxx2, 1xxxxx3, …, 1xxxxx99 and so on? I mean when it is done automatically and not manual each time after only one address had been found?
figured out


Another question: can't specify path for my txt file. I put it in the same folder as vanitysearch.exe but none of two commands work, not o- outputfile:test.txt, nor o-output:C/desktop/Vanity/test.txt  resolved, did it wrong before

now the problem is with gpu
-gpu didn't work, something about CUDA, -g Invalid grid size GPU ID argument

Merci
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 [28] 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!