VanitySearch (Yet another address prefix finder) - page 15.

jacky19790729

jr. member

Activity: 82

Merit: 8

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

fxsniper

member

Activity: 406

Merit: 47

Quote from: NotATether on April 12, 2021, 04:52:16 AM

Quote from: fxsniper on April 12, 2021, 04:14:45 AM

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

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: fxsniper on April 12, 2021, 04:14:45 AM

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

member

Activity: 406

Merit: 47

Quote from: NotATether on April 12, 2021, 01:01:14 AM

Quote from: fxsniper on April 11, 2021, 07:04:29 AM

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

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: fxsniper on April 11, 2021, 07:04:29 AM

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

member

Activity: 406

Merit: 47

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?

fxsniper

member

Activity: 406

Merit: 47

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?

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: MisterCooper on April 06, 2021, 07:30:09 AM

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?

MisterCooper

newbie

Activity: 30

Merit: 0

Quote from: NotATether on April 06, 2021, 05:53:31 AM

Quote from: MisterCooper on April 05, 2021, 04:27:29 PM

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 *items;
  bool found;

} PREFIX_TABLE_ITEM;

...
...

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

NotATether

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: WhyFhy on April 06, 2021, 06:08:13 AM

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 Embarrassed

EDIT: Check your PMs

WhyFhy

hero member

Activity: 1443

Merit: 513

Quote from: NotATether on April 06, 2021, 05:53:31 AM

Quote from: MisterCooper on April 05, 2021, 04:27:29 PM

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

legendary

Activity: 1568

Merit: 6660

bitcoincleanup.com / bitmixlist.org

Quote from: MisterCooper on April 05, 2021, 04:27:29 PM

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.

MisterCooper

newbie

Activity: 30

Merit: 0

Quote from: WanderingPhilospher on April 06, 2021, 02:53:09 AM

Quote from: MisterCooper on April 06, 2021, 01:51:30 AM

Quote from: WanderingPhilospher on April 05, 2021, 06:54:56 PM

Quote from: MisterCooper on April 05, 2021, 04:27:29 PM

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]

WanderingPhilospher

full member

Activity: 1232

Merit: 242

Shooters Shoot...

Quote from: MisterCooper on April 06, 2021, 01:51:30 AM

Quote from: WanderingPhilospher on April 05, 2021, 06:54:56 PM

Quote from: MisterCooper on April 05, 2021, 04:27:29 PM

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

newbie

Activity: 30

Merit: 0

Quote from: WanderingPhilospher on April 05, 2021, 06:54:56 PM

Quote from: MisterCooper on April 05, 2021, 04:27:29 PM

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 ?

WanderingPhilospher

full member

Activity: 1232

Merit: 242

Shooters Shoot...

Quote from: MisterCooper on April 05, 2021, 04:27:29 PM

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

MisterCooper

newbie

Activity: 30

Merit: 0

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!

fxsniper

member

Activity: 406

Merit: 47

Quote from: WanderingPhilospher on March 31, 2021, 09:26:45 PM

Quote

Thank you every body
I ask because speed of calculate some find message to search in same length some find found fast some slow to found

VanitySearch work by random full 256 bit key right (for can use in real)

VanitySearch-Bitcrack not random it is run from 123 .789 but good for use keyspace and Vanity

Vanity is only from fist part on address right?

Don have any program can search part of address like some part on address or reverse search by search end of address
( mean search "w1seQz" on 1Fgx98A3CMs97w1seQzA85CqExvpZkBGTD or search "ZkBGTD" end of address)

Yes, use Vanity Search. Use 1*w1seQz* or 1*ZkBGTD

Thank you very much. WanderingPhilospher
I just know program can search pattern like this
very good to have this feature to can search

WanderingPhilospher

full member

Activity: 1232

Merit: 242

Shooters Shoot...

Quote

Thank you every body
I ask because speed of calculate some find message to search in same length some find found fast some slow to found

VanitySearch work by random full 256 bit key right (for can use in real)

VanitySearch-Bitcrack not random it is run from 123 .789 but good for use keyspace and Vanity

Vanity is only from fist part on address right?

Don have any program can search part of address like some part on address or reverse search by search end of address
( mean search "w1seQz" on 1Fgx98A3CMs97w1seQzA85CqExvpZkBGTD or search "ZkBGTD" end of address)

Yes, use Vanity Search. Use 1*w1seQz* or 1*ZkBGTD

fxsniper

member

Activity: 406

Merit: 47

Quote from: WanderingPhilospher on March 31, 2021, 01:06:05 PM

Quote from: NotATether on March 31, 2021, 11:59:39 AM

Quote from: fxsniper on March 30, 2021, 02:44:57 AM

Could I ask some thing off topic?

What faster to found address want VanitySearch program?

VanitySearch 1.19
Vanitygen 0.21
oclvanitygen
VanitySearch-1.15.4_bitcrack

Have you tried running a benchmark yourself? The very first post of this thread has some speed comparisons and tells you you can search for some uncompressed key as a test.

Quote from: Jean_Luc on February 20, 2019, 09:31:36 AM

On my Intel Core i7-4770, VanitySearch runs ~4 times faster than vanitygen64. (1.32 Mkey/s -> 5.27 MK/s)
On my GeForce GTX 645, VanitySearch runs ~1.5 times faster than oclvanitygen. (9.26 Mkey/s -> 14.548 MK/s)
If you want to compare VanitySearch and Vanitygen result, use the -u option for searching uncompressed address.

My gut feeling is VanitySearch-Bitcrack may be slightly slower than VanitySearch but I never used that program.

For a pure vanity address finder, VanitySearch is hands down faster because of the symmetry and endo features PLUS you can look for compressed uncompressed, and the bc, 3, and 1 addresses.

VS Bitcrack is more about specific ranges although, you can search for Vanity addresses with it. VS bitcrack and VS are different animals, intended to do different things, but still have common features.

Thank you every body
I ask because speed of calculate some find message to search in same length some find found fast some slow to found

VanitySearch work by random full 256 bit key right (for can use in real)

VanitySearch-Bitcrack not random it is run from 123 .789 but good for use keyspace and Vanity

Vanity is only from fist part on address right?

Don have any program can search part of address like some part on address or reverse search by search end of address
( mean search "w1seQz" on 1Fgx98A3CMs97w1seQzA85CqExvpZkBGTD or search "ZkBGTD" end of address)

Topic: VanitySearch (Yet another address prefix finder) - page 15. (Read 33086 times)