Topic: VanitySearch (Yet another address prefix finder) - page 37. (Read 31225 times)

Can't you read? It describes the essence of the problem. And pick up expressions when writing to strangers.

You must be crazy, man, to store your bitcoins on the vanity addresses generated by the tool the source code of which you are not able to read and understand.

Good! Is there a security audit of this program? I personally can't read the code, and neither can 99 percent of users. And what if the developer of this program has implemented in the code that the basic keys are repeated. It may be a large range, so users will not notice. Then, at the appropriate time, all addresses created with this program will be emptied. So the base key is a security threat.

The base key is a security risk because it narrows the search range. I would like to search for matches across the entire range of keys. This will be true randomization.

I have the opinion about this, may be not correct. I guess that the base key function is very important for securiyty reasons. Vanitysearch is a tool designed to generate desired vanity addresses. So these addresses also should be secured - for these purposes random base key is used. Without base key fuction 2 different persons could generate the same addresses if use the same prefix - let's say I generate the address starting with "1Dragon", so another person could generate the same address using vanitysearch without base key.

But anyway, if vanitysearch performance without base key is faster, it will be good be able to disable this function (only for advanced users, as it decreases the security).

PS. Without base key, by default users could use number 1 as teh starting private key. So, all different users will generate the same address if use similar prefix, because the tool increment priv key number by 1 searchig for the address.

I think that the function (Base Key) greatly reduces performance. Because the search range is too narrow. Now, if it as it to disconnect! We can say that this is a useless function, since one character in 160 changes Sha 256 cardinally.

I tested not for 3 characters, but 5 or 6 characters and VanitySearch is very long looking compared to vanitygen

Yes keyspace START:END+Count , but i don't knwo when I will do that.


VanitySearch may be less efficient for short prefixes (less than 3 char) than vanitygen. I presume it is because VanitySearch use a 16bit lookup on the hash160 to speedup the search not because keys are not random.

Hello! Is it possible to disable the function (Base Key). The fact is that The Base Key function reduces the search range. Despite the fact that your program is more productive than vanitygen. Vanitygen is able to find matches faster with a short prefix. How can I disable the function of the Base Key? or to configure that your program used constantly random keys for search?

Bro, you would probably need VanitySearch-1.15.2_bitcrack for this task.
Run it like:
-s    - start privkey

Hi, Do you have in plan to add :
-keyspace START:END+Count
-random keyspace between START:END+Count ?

Thx

In any case this program is not designed to do that, so this is just tricks and you need to modify the code.
You have to disable the 5 optimized points, to set the startKey to 0 and specify a pub key or add the appropriate option.
You have also to adjust the starting key of each thread in order to cover the desired range.
This is more or less planned but not for the moment.

If specify the corresponding public key using -sp option, the tool just adds some "unknown" number to the priv key. This is very useful for work delegation.

My question was about start search from the exact priv key. You have base key in your tool, but it is not determined as the exact 256bit number to start, it is determined by the seed. How do you receive the base key from the "-s seed" option as the starting point?

yeah I made a fresh copy yesterday and compiled it, its 1.16
1.15 had the same problem though

might have the chance to run it on windows next week..
im also trying to find someone that can lend me a gtx for a bit only found a friend with a Vega 64 but this is cuda only no openCL right?

I ran with your file a bit, even tried to specify your grid size on my old Quadro and it worked.


Your git is up to date ?

done...

thinking about it yeah there are 5 addresses in there that are 1 symbol shorter then full length .. and yeah they would be in the 22mil as well, also even shorter ones! an address can get down to 26 symbols.. I think

here is an additional strange thing.. I ran it against the list without the 5 addresses and instead of failing immediately it ran for 3 min. if I put the -t 0 AND the base key started with 7... on E or C or 2... it failed immediately so I startet several times .. always only when the base key starts with 7 it ran for a moment..

Just send me the 133 addresses files via pm. May a particular address inside causes the issue.

Can you upload this file somewhere and share the link?

./VanitySearch -gpu -gpuId 0 -i 5000.txt
VanitySearch v1.16
Search: 133 addresses (Lookup size 133,[1,1]) [Compressed]
Start Wed Jan  8 07:56:31 2020
Base Key: CAFFCF119BAE13EAA1F0C053F98BBA2D3982E39B40FB9A991A475F0B46BA4751
Number of CPU thread: 1
GPU: GPU #0 GeForce RTX 2080 Ti (68x64 cores) Grid(544x128)
[2196.82 Mkey/s][GPU 2192.28 Mkey/s][Total 2^37.02][Prob 0.0%][50% in 1.46226e+31y][Found 0]  GPUEngine: Launch: an illegal memory access was encountered

this happens with 133 addresses.. same thing after 3sec. but if it helps I can give you the 22 million file.. its about 750mb.. I was just courious about performance with big datasets so I dumped the p2pkh and the p2pk addresses from the chainstate of a full node and that's about 22mil at the moment...
(if you want to do the same I have a tool on my GitHub that can batch convert the pub keys compressed uncompressed and leveldb encoded to there corresponding addresses because they are only in utxo form in the chainstate.. search for pub2addr)
i haven't looked too hard in your code but r u using a hash table instead of a bloom filter.. right?
and at the moment its just research 4 me but im thinking about implementing a vanity searcher on a Xilinx u200 FPGA... MAYBEEEEEEEEEE.. as a bitstream.. and so im looking around at the moment..

./VanitySearch  -l
GPU #0 GeForce RTX 2080 Ti (68x64 cores) (Cap 7.5) (11016.3 MB) (Multiple host threads)
GPU #1 GeForce RTX 2080 Ti (68x64 cores) (Cap 7.5) (11019.4 MB) (Multiple host threads)

yes it states Cap 7.5 so compiling with ccap=75 seems right..

I never tried 21 million addresses as you, I have to generate such a list and see what will happen.


VanitySearch.exe -l
(it gives the ccap)