VanitySearch (Yet another address prefix finder)

[MisterCooper]

Please tell me how you can change the code in VanitySearch, instead of looking for an address, I need to replace it with a search public key? That is, set the Gx point search function.

Let's say the public key is 03609747D18DB797783F8DA35BD9D95AAF717C99923D85CCF79C5396F8B897A960

Remove perfis 03

leave only Gx point and run

./VanitySearch -s "609747D18DB797783F8DA35BD9D95AAF717C99923D85CCF79C5396F8B897A960" -kp

I don't really know programming. I would be grateful for your answer!

Why do you have the -kp? That will generate one keypair and the -s is the seed.

Are you searching for a specific pub key?  Do you know the range?  Best to just search for address as minimal time is added; pubkey -> sha256 -> RIPEMD160.

Tell us more exactly what you are trying to do

I have a list of compressed public keys, in this list I know approximately that 2-3 keys are in a certain range. But the list is huge and I don't know exactly which line these keys are in. If  manually iterate over these keys using Kangaroo, it will take many years.
I made sure that VanitySearch using CUDA works very quickly, but the question is, can the VanitySearch code be fixed so that the Public key (Gx point) prefix is ​​used as a search?

I do not understand the architecture of CUDA, but if  search for the Public key as an enumeration, only 16 HEX values ​​of the [0123456789ABCDEF] format are used, I think it will be faster?

I tested the perfix for Bech32 (P2WPKH) addresses in VanitySearch many times faster than in Base58 (P2SH) addresses. I suppose this is due to the fact that in Bech32 (P2WPKH) there are much less characters than in Base58 (P2SH).

I tried to use python scripts to find public keys in the desired range using the "searchfile" function

Code:

...
...
    searchfile = open ("PubList.txt", "r")

    for line in searchfile:
        if pub in line:
                
                print ("KEY =" + priv + "- PUB =" + pub + "\ n")
...
...

But the speed in Python is very slow and besides, there is a load on the CPU. From here, I conclude that VanitySearch using CUDA works very quickly, but unfortunately I do not know the C ++  to fix it myself, and because of this I have a question for you how to fix the code so that VanitySearch looks for the "Public key (Gx point)" prefix ?

[1715177614]

1715177614

[1715177614]

1715177614

[1715177614]

1715177614

[1715177614]

1715177614

[WanderingPhilospher]

Please tell me how you can change the code in VanitySearch, instead of looking for an address, I need to replace it with a search public key? That is, set the Gx point search function.

Let's say the public key is 03609747D18DB797783F8DA35BD9D95AAF717C99923D85CCF79C5396F8B897A960

Remove perfis 03

leave only Gx point and run

./VanitySearch -s "609747D18DB797783F8DA35BD9D95AAF717C99923D85CCF79C5396F8B897A960" -kp

I don't really know programming. I would be grateful for your answer!

Why do you have the -kp? That will generate one keypair and the -s is the seed.

Are you searching for a specific pub key?  Do you know the range?  Best to just search for address as minimal time is added; pubkey -> sha256 -> RIPEMD160.

Tell us more exactly what you are trying to do

I have a list of compressed public keys, in this list I know approximately that 2-3 keys are in a certain range. But the list is huge and I don't know exactly which line these keys are in. If  manually iterate over these keys using Kangaroo, it will take many years.
I made sure that VanitySearch using CUDA works very quickly, but the question is, can the VanitySearch code be fixed so that the Public key (Gx point) prefix is ​​used as a search?

I do not understand the architecture of CUDA, but if  search for the Public key as an enumeration, only 16 HEX values ​​of the [0123456789ABCDEF] format are used, I think it will be faster?

I tested the perfix for Bech32 (P2WPKH) addresses in VanitySearch many times faster than in Base58 (P2SH) addresses. I suppose this is due to the fact that in Bech32 (P2WPKH) there are much less characters than in Base58 (P2SH).

I tried to use python scripts to find public keys in the desired range using the "searchfile" function

Code:

...
...
    searchfile = open ("PubList.txt", "r")

    for line in searchfile:
        if pub in line:
                
                print ("KEY =" + priv + "- PUB =" + pub + "\ n")
...
...

But the speed in Python is very slow and besides, there is a load on the CPU. From here, I conclude that VanitySearch using CUDA works very quickly, but unfortunately I do not know the C ++  to fix it myself, and because of this I have a question for you how to fix the code so that VanitySearch looks for the "Public key (Gx point)" prefix ?

How many is "huge"?

Why not just process all the pubkeys out to their compressed address and use vanitysearch to search for the addresses? A lot easier than tinkering with code IMO.

[MisterCooper]

Please tell me how you can change the code in VanitySearch, instead of looking for an address, I need to replace it with a search public key? That is, set the Gx point search function.

Let's say the public key is 03609747D18DB797783F8DA35BD9D95AAF717C99923D85CCF79C5396F8B897A960

Remove perfis 03

leave only Gx point and run

./VanitySearch -s "609747D18DB797783F8DA35BD9D95AAF717C99923D85CCF79C5396F8B897A960" -kp

I don't really know programming. I would be grateful for your answer!

Why do you have the -kp? That will generate one keypair and the -s is the seed.

Are you searching for a specific pub key?  Do you know the range?  Best to just search for address as minimal time is added; pubkey -> sha256 -> RIPEMD160.

Tell us more exactly what you are trying to do

I have a list of compressed public keys, in this list I know approximately that 2-3 keys are in a certain range. But the list is huge and I don't know exactly which line these keys are in. If  manually iterate over these keys using Kangaroo, it will take many years.
I made sure that VanitySearch using CUDA works very quickly, but the question is, can the VanitySearch code be fixed so that the Public key (Gx point) prefix is ​​used as a search?

I do not understand the architecture of CUDA, but if  search for the Public key as an enumeration, only 16 HEX values ​​of the [0123456789ABCDEF] format are used, I think it will be faster?

I tested the perfix for Bech32 (P2WPKH) addresses in VanitySearch many times faster than in Base58 (P2SH) addresses. I suppose this is due to the fact that in Bech32 (P2WPKH) there are much less characters than in Base58 (P2SH).

I tried to use python scripts to find public keys in the desired range using the "searchfile" function

Code:

...
...
    searchfile = open ("PubList.txt", "r")

    for line in searchfile:
        if pub in line:
                
                print ("KEY =" + priv + "- PUB =" + pub + "\ n")
...
...

But the speed in Python is very slow and besides, there is a load on the CPU. From here, I conclude that VanitySearch using CUDA works very quickly, but unfortunately I do not know the C ++  to fix it myself, and because of this I have a question for you how to fix the code so that VanitySearch looks for the "Public key (Gx point)" prefix ?

How many is "huge"?

Why not just process all the pubkeys out to their compressed address and use vanitysearch to search for the addresses? A lot easier than tinkering with code IMO.

200 GB divided by text files

I also considered this option, but I could not write and find a script for creating Bech32 (P2WPKH) addresses [pub => addr]

[NotATether]

Please tell me how you can change the code in VanitySearch, instead of looking for an address, I need to replace it with a search public key? That is, set the Gx point search function.

You need to add another searchType called something like PUBLICKEY and then in VanitySearch::initPrefix() and other places the variable is used, you need to detect the new search type here by looking for "0x" or "0X" at the beginning and add fields to the PREFIX_ITEM structure for x point, y point and the private key number.

[WhyFhy]

Please tell me how you can change the code in VanitySearch, instead of looking for an address, I need to replace it with a search public key? That is, set the Gx point search function.

You need to add another searchType called something like PUBLICKEY and then in VanitySearch::initPrefix() and other places the variable is used, you need to detect the new search type here by looking for "0x" or "0X" at the beginning and add fields to the PREFIX_ITEM structure for x point, y point and the private key number.

Hey I shot you a PM! @NotATether

[NotATether]

Hey I shot you a PM! @NotATether

Yeah I forgot about that while I was busy at my new job the last few days, sorry about that  

EDIT: Check your PMs

[MisterCooper]

Please tell me how you can change the code in VanitySearch, instead of looking for an address, I need to replace it with a search public key? That is, set the Gx point search function.

You need to add another searchType called something like PUBLICKEY and then in VanitySearch::initPrefix() and other places the variable is used, you need to detect the new search type here by looking for "0x" or "0X" at the beginning and add fields to the PREFIX_ITEM structure for x point, y point and the private key number.

How do I add fields to the structure? Something in this moment I am at a loss, what needs to be added?

Code:

....
....

typedef struct {

  char *prefix;
  int prefixLength;
  prefix_t sPrefix;
  double difficulty;
  bool *found;

  // For dreamer ;)
  bool isFull;
  prefixl_t lPrefix;
  uint8_t hash160[20];

} PREFIX_ITEM;

typedef struct {

  std::vector<PREFIX_ITEM> *items;
  bool found;

} PREFIX_TABLE_ITEM;

...
...

https://github.com/JeanLucPons/VanitySearch/blob/1bc508a19e2066777f3fb1a020f68f8705daf0f4/Vanity.h#L47

[NotATether]

How do I add fields to the structure? Something in this moment I am at a loss, what needs to be added?
~snip

Not to discourage you or anything, but let me warn you that making patches for new features will not be a cakewalk, and will take several days to finish. It took me 2 weeks to extend Kangaroo to 256-bit range for example.

Anyway, it looks like in this file SECP256k1.h is where all the types are defined, we need to define a "fake address type" for public keys like #define PUBKEY   3 and then we don't have to worry about adding X, Y points or making a function to calculate points because as you can see in this file those functions are already there.

I said "fake address type" because we no longer store an address prefix in PREFIX_TABLE_ITEM->prefix if PREFIX_TABLE_ITEM->sPrefix==PUBKEY (I think that's what sPrefix is for I didn't study it hard enough), we store the entire public key.


So you're trying to use VanitySearch to find private keys that have the full specified public key, am I still following? Or just ones with the first few characters of a public key?

[fxsniper]

I would like to try modify VanitySearch output when using option -o output.txt
modify to display at one with with comma (make it like csv file)

Where can I try to change it What file and what line or what position code?

[fxsniper]

VanitySearch.exe -gpu -o output.txt -i input.txt
VanitySearch v1.19
[Building lookup16  86.1%]
[Building lookup32 100.0%]
Search: 2324 prefixes (Lookup size 882) [Compressed]
Start Sun Apr 11 11:18:50 2021
Base Key: D4E489F2971AA6A19F746EF91D24BBAC1D65E8B1EB9D847731AE0389CE1621BA
Number of CPU thread: 7
GPU: GPU #0 GeForce GTX 1050 (5x128 cores) Grid(40x128)

Warning, 356404 items lost
Hint: Search with less prefixes, less threads (-g) or increase maxFound (-m)
[69.96 Mkey/s][GPU 62.75 Mkey/s][Total 2^40.99][Prob 100.0%][99% in 00:00:00][Found 2533]


What about ==> Warning, 356404 items lost mean?
How I can fix it?

[NotATether]

What about ==> Warning, 356404 items lost mean?
How I can fix it?

You're overfilling VanitySearch's GPU buffers with starting keys, so it's dropping them after the maximum number it can fit in. You need to increase maxFound to something bigger than 65536 using the -m option.

[fxsniper]

What about ==> Warning, 356404 items lost mean?
How I can fix it?

You're overfilling VanitySearch's GPU buffers with starting keys, so it's dropping them after the maximum number it can fit in. You need to increase maxFound to something bigger than 65536 using the -m option.

Thank you

I test add  -m 1000000   then no message warning

What meaning -m option
yes, my input file have a lot of prefix search


VanitySearch.exe -gpu -m 1000000 -o output.txt -i input.txt
VanitySearch v1.19
[Building lookup16  86.1%]
[Building lookup32 100.0%]
Search: 2324 prefixes (Lookup size 882) [Compressed]
Start Mon Apr 12 16:12:17 2021
Base Key: 4707C5DCE134F392E4F90415A3C12C32C51463D2D12EE0F7C44F24959DA522C7
Number of CPU thread: 7
GPU: GPU #0 GeForce GTX 1050 (5x128 cores) Grid(40x128)
[21.75 Mkey/s][GPU 14.09 Mkey/s][Total 2^27.11][Prob 0.9%][50% in 00:08:01][Found 0]

[NotATether]

What meaning -m option
yes, my input file have a lot of prefix search

It's only used in GPU search.

It dictates the size of the array that stores the prefixes on GPU memory. It is not possible to search for more prefixes than this simultaneously, because you cannot write past the end of allocated memory or you will get a Segmentation Fault! Instead of hard failing like that, VanitySearch drops some prefixes to stay within the size limit.

Kangaroo also has this kind of concept, only with DPsize.

[fxsniper]

What meaning -m option
yes, my input file have a lot of prefix search

It's only used in GPU search.

It dictates the size of the array that stores the prefixes on GPU memory. It is not possible to search for more prefixes than this simultaneously, because you cannot write past the end of allocated memory or you will get a Segmentation Fault! Instead of hard failing like that, VanitySearch drops some prefixes to stay within the size limit.

Kangaroo also has this kind of concept, only with DPsize.

Thank you

I will try decrease input file with not have much prefix search may be help to faster and better n small GPU

[jacky19790729]

Code:

...
...
    searchfile = open ("PubList.txt", "r")

    for line in searchfile:
        if pub in line:
                
                print ("KEY =" + priv + "- PUB =" + pub + "\ n")
...
...

can you show  10  lines from PubList.txt .......
like my search result ....all 9 word match  "16jY7qLJn********"

Code:

000000000000000000000000000000000000000000000000EDEC070CF855EBA0,16jY7qLJnS3hrHQPC9An9K5ZNaZMd98bV4,2021-04-04 23:26:51,,,,,,,,,,
000000000000000000000000000000000000000000000000EDEC26E9C9E3F377,16jY7qLJnSwho77XBFFwY4rpN891YYWh3b,2021-04-06 04:44:36,,,,,,,,,,
000000000000000000000000000000000000000000000000EDEC34CFC668E668,16jY7qLJntTJt2NwVvCj5Y2eB8jY2G9TBx,2021-04-06 17:01:10,,,,,,,,,,
000000000000000000000000000000000000000000000000EDEC6CFD492F0A35,16jY7qLJnSgLpk82Ay6MQuVkxEFitwR3gK,2021-04-12 13:03:56,,,,,,,,,,
000000000000000000000000000000000000000000000000EDECAB37CBF22648,16jY7qLJnbq7VxfZpgXxCVHpBVZh8852tA,2021-04-13 18:36:51,,,,,,,,,,
000000000000000000000000000000000000000000000000EDECB750D404B88A,16jY7qLJnH2Yw5c8H97NERpKDBfmp2SE6q,2021-04-09 17:17:50,,,,,,,,,,
000000000000000000000000000000000000000000000000EDECF90D30C69B90,16jY7qLJn4y8JFFhZ2usCPFzUj4rbqU7Xy,2021-04-11 06:00:07,,,,,,,,,,

in range
000000000000000000000000000000000000000000000000EDEC000000000000
000000000000000000000000000000000000000000000000EDECFFFFFFFFFFFF

[NotATether]

can you show  10  lines from PubList.txt .......
like my search result ....all 9 word match  "16jY7qLJn********"

Code:

~snip

This looks like a generated file, what did you use to make it? (AFAIK VanitySearch cannot export CSV files)

Anyway, I doubt that seeing them would be useful. It's not private key output like yours, it's just a bunch of MisterCooper's public keys on each line. He was trying to make VanitySearch search for whole pubkeys instead of prefixes.

[jacky19790729]

can you show  10  lines from PubList.txt .......
like my search result ....all 9 word match  "16jY7qLJn********"

Code:

~snip

This looks like a generated file, what did you use to make it? (AFAIK VanitySearch cannot export CSV files)

Anyway, I doubt that seeing them would be useful. It's not private key output like yours, it's just a bunch of MisterCooper's public keys on each line. He was trying to make VanitySearch search for whole pubkeys instead of prefixes.

I just edit   VanitySearch-1.15.4_bitcrack
void VanitySearch::output(........)


download it https://gz.blockchair.com/bitcoin/addresses/
write a simple python code ..... read every public key  to output 5 BTC address
to check address BTC balance ~~ if he know all public key <=> private key range...
if address has BTC balance  , then use "Kangaroo" to find private key ......if sure private key range is small than 2^70 

Code:

Public Key: 0414bdd507894bcda6a0e4b715c50d440498927880e65e4cd389c9db3e44b4b29a49962e139b85ea7da073a32193ac5712c89f1d5d0ed55443249fd3048bd4be43
Public Key compressed: 0314bdd507894bcda6a0e4b715c50d440498927880e65e4cd389c9db3e44b4b29a
Public Address 1: 1C7jNLSUjiZ54xibeP9KmViH5TzwtAKLLu
Public Address 1 compressed: 16jY7qLJnx2ixrxCnTLSraerkgyB3YYAiT
Public Address 3: 3C9VPeUcNeiVMcJuFMzAf7UphvB9SBsrW6
Public Address bc1 P2WPKH: bc1q8mjpx0verazc0cwsg2pnvj2gt35fn9cmdredms
Public Address bc1 P2WSH: bc1qrq28078qctyfr9y8hc4zawlrrmkx4ud9qh69v69lpa30qk0p08fs4fen0t

[dextronomous]

  fprintf(f, "\n====<FOUND_KEY_Time1 >  %04d-%02d-%02d %02d:%02d:%02d =====\n", time.wYear, time.wMonth, time.wDay, time.wHour, time.wMinute, [Suspicious link removed]econd); this last part what should be written there,


thanks guys

[WanderingPhilospher]

can you show  10  lines from PubList.txt .......
like my search result ....all 9 word match  "16jY7qLJn********"

What is your question about matching 9 characters? I have 100,000s of them somewhere.

This code is not efficient if your list grows:

Code:

...
...
    searchfile = open ("PubList.txt", "r")

    for line in searchfile:
        if pub in line:
               
                print ("KEY =" + priv + "- PUB =" + pub + "\ n")
...
...

You will need to edit it.  Great thing about python, it seems like one of the few programming languages that I dabble with that does not lose MKey/s no matter how large or small a file is.

So are you randomly generating privs, pubs, addrs and checking the addrs against the list? I'm just trying to figure out what you are doing.

[jacky19790729]

can you show  10  lines from PubList.txt .......
like my search result ....all 9 word match  "16jY7qLJn********"

What is your question about matching 9 characters? I have 100,000s of them somewhere.

This code is not efficient if your list grows:

9 characters  "16jY7qLJn*" .....  100,000 ?
all in  8000000000000000:FFFFFFFFFFFFFFFF   ??

I am searching #64.......
I think if find 1  "9 characters match"  or  "10 characters match"
real #64 private key has a small Probability of appearing nearby
I will can Big Jump to Scan next range ....
now I still scan EDEC000000000000:EDECFFFFFFFFFFFF   (95% had checked, and only found 6  "9 characters" )