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

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 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]

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.

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?

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?

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?

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


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

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

EDIT: Check your PMs

Hey I shot you a PM! @NotATether

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.

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]

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.

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


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 ?

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

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!

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

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

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)

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.

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.


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