VanitySearch (Yet another address prefix finder)

[shlomogold]

OFFTOP

l
now to my question. I'm bad with large numbers. could anyone tell me the probability of randomly finding a private key wallet with transaction given the fact that that 'database' supposed to have 10e +77 private keys and there was only 1 billion transactions and I happen to find one?
or to rephrase it - there are less than 100,000,000 wallets in use and I've randomly found one. what are the chances of that?

Ummmmm, buy a lottery ticket today

I am not sure on the numbers but you finding a random page with a used wallet has to be pretty high/astronomical.

I thought somebody would say something about the lottery ))

At first it didn't even shock me, but then I started calculating, so it must be a ratio: 1,000,000,000 (a number of all transactions) to 10 e+77 or 100,000,000 (a number of all the wallets) to 10 e+77. I'm lost with all the zeros so I can't figure out the accurate probability.

P.S.

there's still one logical explanation though:

the numbers on a page I've found are identical to the full number of pages minus a few from the end which I've deleted. so I didn't add or mix any numbers yet, I just deleted a few digits when I found that particular address. what if somebody did the same and created a transaction on purpose? maybe they deleted a few digits, picked up a key, used it, now it's there. the domain was registered in 2017, the transaction was made in 2018, so it's possible.

[1714795242]

1714795242

[1714795242]

1714795242

[1714795242]

1714795242

[1714795242]

1714795242

[shlomogold]

For one thing, "human" randomness is not random enough since we just replace numbers with more predictable ones, unlike a computer. And I'd be hard-pressed to find a private key that happens to have what I call "human randomness" entropy/bits in it.

I typed what I typed, was blindly hitting the keypad, deleting, adding, without thinking. Hard to call it a real randomness but still..
BTW, one might think there's a trick, lets say, I used one of my old private keys which I entered into their search. But the thing is that that website doesn't show you the page the key is on when you enter one. You can enter your old private key, it will show you calculated public key and other stuff, but it doesn't say which page it is on. So as strange as it is, looks like I did the impossible?

though there's still one logical explanation, I mentioned it in my previous post

[bigvito19]

Can you search for an address with vanitygen with a public key? I was thinking would that be able to shorten the search space like kangaroo.

[WanderingPhilospher]

Can you search for an address with vanitygen with a public key? I was thinking would that be able to shorten the search space like kangaroo.

Not 100% sure with vanitygen but vanity search takes inputted address and converts it to its RIPEMD160, then searches for a match for the RIPEMD160. One could tweak code to search for a pubkey which would save one sha256 and the one RIPEMD160 function.

Priv key
Pub key
sha256
ripemd160

so you would save two functions but I am not sure on the speed gained since normally, the most time consuming part. whether its CPU or GPU. is doing the math from priv key to pub key.

[sam00]

(SOLUTION BELOW)
Hey there, I have a question:
I created an address with vanity search.
I used the bc1q prefix and vanity search gave me a Priv(WIF) Key and a Priv(HEX) Key. I can't load either of those into my Wallet (using BlueWallet on iOS).
Do I have to do anything with those keys or can I only import them to certain wallets ?

I never used Electrum before but I decided to download the standalone .exe and imported the whole private key "p2wpkh:..." and electrum seems to get it and also shows the correct receiving address. Can anyone tell me if there's an ios wallet capable of importing these keys ?

EDIT: On another thread I started, o_e_l_e_o was kind enough to help me fix this problem. You need to load a few sats onto the correct wallet so the app (BlueWallet in my case) will be able to determine the right address you want to import.

If I remember correctly, when you import a private key in to BlueWallet it scans all the relevant addresses looking for which one has been used, and then imports that one. If it finds none of them have been used, it defaults to the nested segwit (P2SH-P2WPKH) address, which will start with a 3.

Have you ever used this vanity address? It might be that you need to send some funds to it before you can import it to BlueWallet.

Edit: Just had a look through the code and it looks like I'm right, except it will default to a legacy address beginning with a 1 if it finds no used addresses. You can see the code here if you are interested: https://github.com/BlueWallet/BlueWallet/blob/master/class/wallet-import.js#L250-L268

[Refresko]

Hello Guys, I write this message to ask something.
putting the VanitySearch to the test, I get the following message:

vanitysearch.exe -b -gpu -o general9.txt -i baseAdd6.txt
[Loading input file 100.0%]
VanitySearch v1.19
[Building lookup16 99.8%]
[Building lookup32 100.0%]
Search: 202467 prefixes (Lookup size 60223) [Compressed or Uncompressed]
Start Mon Sep 6 15:14:52 2021
Base Key: 45F1AF1EFE0B031DDAD00BF1E7D68B9A38CFA0C8B649B09CBCC70349976725B0
Number of CPU thread: 3
GPU: GPU #0 NVIDIA GeForce 930MX (3x128 cores) Grid(24x128)

Warning, 34623463 items lost
Hint: Search with less prefixes, less threads (-g) or increase maxFound (-m)
[15.83 Mkey/s][GPU 15.58 Mkey/s][Total 2^30.87][Prob 0.2%][50% in 10:46:14][Found 14]

Can you do me a favor and guide me a bit about the following:

1. (Warning, 34623463 items lost) How to avoid these losses?
2. the input -m is not clear to me, because, for example, if I put -m 10, it gives me a better performance, something like [25.39 Mkey / s], but if I leave that field empty, it throws me, like you can see, around [15.8 Mkey / s]. which should be then, the correct -m?

Thank you

[Andre_25]

Hi friends,
I wish you a nice day

I recently started testing vanitySearch, and I am realizing that the 3060 TI card is not getting enough values ​​that I would unknowingly expect.
 I have seen, in this message (https://bitcointalk.org/index.php?topic=5112311.msg57116410#msg57116410), that the 2080 TI reaches 2500 MK / s (approximately) and the 2080 super reaches 2000 MK / s. in my case, and testing the 3060 TI, it doesn't even reach 2000.
because it can be?

Code:

VanitySearch.exe -gpu -t 0 1testme1
VanitySearch v1.19
Difficulty: 51529903411245
Search: 1testme1 [Compressed]
Start Sun Sep 12 20:40:48 2021
Base Key: 2CAF27F4DBD746225EBC883505540087E7CF680E05B35CEF9253A6C1D4603E65
Number of CPU thread: 0
GPU: GPU # 0 NVIDIA GeForce RTX 3060 Ti (38x0 cores) Grid (304x128)
[1791.73 Mkey / s] [GPU 1791.73 Mkey / s] [Total 2 ^ 33.36] [Prob 0.0%] [50% in 05:31:45] [Found 0]

Why does appear (38X0 cores) ?
help me please understand a little.
Thank you

[WanderingPhilospher]

Why does appear (38X0 cores) ?
help me please understand a little.

The code was built before the new cards came out. If you want to adjust, go into GPUEngine.cu and change the code to this:

Code:

sSMtoCores nGpuArchCoresPerSM[] = {
      {0x20, 32}, // Fermi Generation (SM 2.0) GF100 class
      {0x21, 48}, // Fermi Generation (SM 2.1) GF10x class
      {0x30, 192},
      {0x32, 192},
      {0x35, 192},
      {0x37, 192},
      {0x50, 128},
      {0x52, 128},
      {0x53, 128},
      {0x60,  64},
      {0x61, 128},
      {0x62, 128},
      {0x70,  64},
      {0x72,  64},
      {0x75,  64},
      {0x86,  128},
      {-1, -1} };

The {0x86,  128}, part is what will update and show you the proper grid size for your newer graphics card.

[Andre_25]

Why does appear (38X0 cores) ?
help me please understand a little.

The code was built before the new cards came out. If you want to adjust, go into GPUEngine.cu and change the code to this:

Code:

sSMtoCores nGpuArchCoresPerSM[] = {
      {0x20, 32}, // Fermi Generation (SM 2.0) GF100 class
      {0x21, 48}, // Fermi Generation (SM 2.1) GF10x class
      {0x30, 192},
      {0x32, 192},
      {0x35, 192},
      {0x37, 192},
      {0x50, 128},
      {0x52, 128},
      {0x53, 128},
      {0x60,  64},
      {0x61, 128},
      {0x62, 128},
      {0x70,  64},
      {0x72,  64},
      {0x75,  64},
      {0x86,  128},
      {-1, -1} };

The {0x86,  128}, part is what will update and show you the proper grid size for your newer graphics card.

Ok, thank you very much for answering.
With that, as I understand it, I will allow to show the correct number of cores, but then the current results, with the 3060 ti are less than the 2080, for example? or do I still need to correct something in it to get better results?

Thanks again!

[WanderingPhilospher]

Why does appear (38X0 cores) ?
help me please understand a little.

The code was built before the new cards came out. If you want to adjust, go into GPUEngine.cu and change the code to this:

Code:

sSMtoCores nGpuArchCoresPerSM[] = {
      {0x20, 32}, // Fermi Generation (SM 2.0) GF100 class
      {0x21, 48}, // Fermi Generation (SM 2.1) GF10x class
      {0x30, 192},
      {0x32, 192},
      {0x35, 192},
      {0x37, 192},
      {0x50, 128},
      {0x52, 128},
      {0x53, 128},
      {0x60,  64},
      {0x61, 128},
      {0x62, 128},
      {0x70,  64},
      {0x72,  64},
      {0x75,  64},
      {0x86,  128},
      {-1, -1} };

The {0x86,  128}, part is what will update and show you the proper grid size for your newer graphics card.

Ok, thank you very much for answering.
With that, as I understand it, I will allow to show the correct number of cores, but then the current results, with the 3060 ti are less than the 2080, for example? or do I still need to correct something in it to get better results?

Thanks again!

You can play around with the grid size to see if you can tweak out more MKey/s, but here's the deal, IMO, most of these programs were releases prior to 30xx cards so the programs probably do not best optimize the use of the cards GPU structure. I have only used one program that did and that was an OpenCL program versus Cuda.

[Andre_25]

You can play around with the grid size to see if you can tweak out more MKey/s, but here's the deal, IMO, most of these programs were releases prior to 30xx cards so the programs probably do not best optimize the use of the cards GPU structure. I have only used one program that did and that was an OpenCL program versus Cuda.

thanks again friend.

[Andre_25]

Hello again guys
I leave a new question, please help me to understand.

I am trying multiple options when I launch the vanitysearch, and I realize that if I "execute" it with -t 0 (which is the same as using it without a processor, and therefore, it would only be with a video card) it does not find anything, even after 10 minutes

Testing with a list of 1,000,000 prefixes, each with a size of 9 letters.

on the contrary, if I try with -t 6, there if I find values. (an average of 1 every 10 seconds)

Could it be that in the end only my processor works and not the gpu?
Shouldn't I find something with GPU alone?
thanks

[WanderingPhilospher]

Hello again guys
I leave a new question, please help me to understand.

I am trying multiple options when I launch the vanitysearch, and I realize that if I "execute" it with -t 0 (which is the same as using it without a processor, and therefore, it would only be with a video card) it does not find anything, even after 10 minutes

Testing with a list of 1,000,000 prefixes, each with a size of 9 letters.

on the contrary, if I try with -t 6, there if I find values. (an average of 1 every 10 seconds)

Could it be that in the end only my processor works and not the gpu?
Shouldn't I find something with GPU alone?
thanks

The short answer, yes, you should find something with GPU, especially if you are finding it with CPU.
Long answer, we would need to see your full command line/batch script flags that you are using.

[Andre_25]

Thanks for helping @WanderingPhilospher

I relate the data:
 with CPU and GPU

Code:

vanitysearch.exe -b -gpu -t 8 -o results.txt -g 2424,128 -i input.txt
Ignoring prefix "33ETnbLHH" (P2PKH, P2SH or BECH32 allowed at once)
Ignoring prefix "34X4htRFX" (P2PKH, P2SH or BECH32 allowed at once)
Ignoring prefix "3C8jo9mjw" (P2PKH, P2SH or BECH32 allowed at once)
Ignoring prefix "3GwoqxGsY" (P2PKH, P2SH or BECH32 allowed at once)
Ignoring prefix "38dz18J41" (P2PKH, P2SH or BECH32 allowed at once)
Ignoring prefix "3QWY3TyAs" (P2PKH, P2SH or BECH32 allowed at once)
Ignoring prefix "3KcxxV9z6" (P2PKH, P2SH or BECH32 allowed at once)
Ignoring prefix "3QdXcHSgH" (P2PKH, P2SH or BECH32 allowed at once)
Ignoring prefix "3KJgr9Eof" (P2PKH, P2SH or BECH32 allowed at once)
....
..........
..........
............
..............
[Building lookup16 100.0%]
[Building lookup32 100.0%]
Search: 1100540 prefixes (Lookup size 62937) [Compressed or Uncompressed]
Start Fri Sep 17 12:03:01 2021
Base Key: E7F12B7FED9FBE430CA759D3004F54C6319EB8B7D28933B11CB2AF9F07762248
Number of CPU thread: 8
GPU: GPU #0 NVIDIA GeForce RTX 3060 Ti (38x0 cores) Grid(2424x128)
[4.63 Mkey/s][GPU 0.00 Mkey/s][Total 2^23.18][Prob 0.0%][50% in 1.9d][Found 0]
Warning, -633598779 items lost
Hint: Search with less prefixes, less threads (-g) or increase maxFound (-m)
[611.66 Mkey/s][GPU 610.23 Mkey/s][Total 2^40.29][Prob 70.5%][80% in 00:10:02][Found 113] 

Results after 35 Min





and NOW, without CPU:
(it is the same query, Except -t)

Code:

vanitysearch.exe -b -gpu -t 0 -o results.txt -g 2424,128 -i input.txt
Ignoring prefix "33ETnbLHH" (P2PKH, P2SH or BECH32 allowed at once)
Ignoring prefix "34X4htRFX" (P2PKH, P2SH or BECH32 allowed at once)
Ignoring prefix "3C8jo9mjw" (P2PKH, P2SH or BECH32 allowed at once)
Ignoring prefix "3GwoqxGsY" (P2PKH, P2SH or BECH32 allowed at once)
Ignoring prefix "38dz18J41" (P2PKH, P2SH or BECH32 allowed at once)
Ignoring prefix "3QWY3TyAs" (P2PKH, P2SH or BECH32 allowed at once)
Ignoring prefix "3KcxxV9z6" (P2PKH, P2SH or BECH32 allowed at once)
Ignoring prefix "3QdXcHSgH" (P2PKH, P2SH or BECH32 allowed at once)
Ignoring prefix "3KJgr9Eof" (P2PKH, P2SH or BECH32 allowed at once)
....
..........
..........
............
..............
[Building lookup16 100.0%]
[Building lookup32 100.0%]
Search: 1100540 prefixes (Lookup size 62937) [Compressed or Uncompressed]
Start Fri Sep 17 13:08:00 2021
Base Key: 926BA4B1C940344A84ACE6BBEFA0CA0898D8A0A03CFC7BE172661EEDA509175
Number of CPU thread: 0
GPU: GPU #0 NVIDIA GeForce RTX 3060 Ti (38x0 cores) Grid(2424x128)
[0.00 Mkey/s][GPU 0.00 Mkey/s][Total 2^-inf][Prob 0.0%][50% in infy][Found 0]
Warning, -633612519 items lost
Hint: Search with less prefixes, less threads (-g) or increase maxFound (-m)
[585.86 Mkey/s][GPU 585.86 Mkey/s][Total 2^40.11][Prob 66.0%][70% in 00:03:52][Found 0]

Results after 30 Min

I think it's weird, and that it should give "almost" the same results.

[WanderingPhilospher]

I think it's weird, and that it should give "almost" the same results.

That is odd, only difference I see right away is -t 8 versus -t 0

What you should do, try searching for say 1 prefix, a short one 1KLmA, or something of the sort. Does your GPU find one or no?
Have you found any addresses with just your GPU, before?

[Andre_25]

Ok, I have done a couple of tests (repeated so as not to be left with a single result and but with it I can average)

I reduced the list of prefixes to 59 (before they were more than a million) and also shortened the prefixes, to 7 letters (before they were 9 letters) and with this if I can get results only with the GPU and i test it only, for 10 minutes

the query was this: (Without CPU)

Code:

vanitysearch.exe -b -gpu -t 0 -o results2.txt -g 2424,128 -i testShort.txt and the results were: 65

with CPU, the query was:

Code:

vanitysearch.exe -b -gpu -t 8 -o results2.txt -g 2424,128 -i testShort.txt and the results were: 126

I do not know what to think,
Perhaps as you said, it is not yet well Optimized for generation 30 cards and therefore, it "depends" a lot on the cpu for a long list and / or Long prefixes.

[WanderingPhilospher]

Ok, I have done a couple of tests (repeated so as not to be left with a single result and but with it I can average)

I reduced the list of prefixes to 59 (before they were more than a million) and also shortened the prefixes, to 7 letters (before they were 9 letters) and with this if I can get results only with the GPU and i test it only, for 10 minutes

the query was this: (Without CPU)

Code:

vanitysearch.exe -b -gpu -t 0 -o results2.txt -g 2424,128 -i testShort.txt and the results were: 65

with CPU, the query was:

Code:

vanitysearch.exe -b -gpu -t 8 -o results2.txt -g 2424,128 -i testShort.txt and the results were: 126

I do not know what to think,
Perhaps as you said, it is not yet well Optimized for generation 30 cards and therefore, it "depends" a lot on the cpu for a long list and / or Long prefixes.

Either that or your grid size is crazy. Normally it's like 128,256 or 256,512 where the y is normally larger or double the x. you have 2424,128; I've never seen those kind of settings before.

[Andre_25]

 

Ok, I have done a couple of tests (repeated so as not to be left with a single result and but with it I can average)

I reduced the list of prefixes to 59 (before they were more than a million) and also shortened the prefixes, to 7 letters (before they were 9 letters) and with this if I can get results only with the GPU and i test it only, for 10 minutes

the query was this: (Without CPU)

Code:

vanitysearch.exe -b -gpu -t 0 -o results2.txt -g 2424,128 -i testShort.txt and the results were: 65

with CPU, the query was:

Code:

vanitysearch.exe -b -gpu -t 8 -o results2.txt -g 2424,128 -i testShort.txt and the results were: 126

I do not know what to think,
Perhaps as you said, it is not yet well Optimized for generation 30 cards and therefore, it "depends" a lot on the cpu for a long list and / or Long prefixes.

Either that or your grid size is crazy. Normally it's like 128,256 or 256,512 where the y is normally larger or double the x. you have 2424,128; I've never seen those kind of settings before.

It is the one that, doing many tests, gave me the best results, it is very near to half the cores that the card has.
although, I don't trust that much anymore.

[WanderingPhilospher]

Ok, I have done a couple of tests (repeated so as not to be left with a single result and but with it I can average)

I reduced the list of prefixes to 59 (before they were more than a million) and also shortened the prefixes, to 7 letters (before they were 9 letters) and with this if I can get results only with the GPU and i test it only, for 10 minutes

the query was this: (Without CPU)

Code:

vanitysearch.exe -b -gpu -t 0 -o results2.txt -g 2424,128 -i testShort.txt and the results were: 65

with CPU, the query was:

Code:

vanitysearch.exe -b -gpu -t 8 -o results2.txt -g 2424,128 -i testShort.txt and the results were: 126

I do not know what to think,
Perhaps as you said, it is not yet well Optimized for generation 30 cards and therefore, it "depends" a lot on the cpu for a long list and / or Long prefixes.

Either that or your grid size is crazy. Normally it's like 128,256 or 256,512 where the y is normally larger or double the x. you have 2424,128; I've never seen those kind of settings before.

It is the one that, doing many tests, gave me the best results, it is very near to half the cores that the card has.
although, I don't trust that much anymore.

is your card an LHR model/version?

[Andre_25]

is your card an LHR model/version?

Yes, I just saw that.  

But I understand that all of the 30 series are.