Topic: VanitySearch (Yet another address prefix finder) - page 14. (Read 32072 times)
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?
How do I add fields to the structure? Something in this moment I am at a loss, what needs to be added?
~snip
~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?
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
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
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.
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.
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.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!
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 ?
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]
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.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!
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 ?
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.
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.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!
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 ?
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.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!
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!
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!
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)
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
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)
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
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
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.
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.
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.
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)
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
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.
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.
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.
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.
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
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.
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.
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.
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
What faster to found address want VanitySearch program?
VanitySearch 1.19
Vanitygen 0.21
oclvanitygen
VanitySearch-1.15.4_bitcrack
I have following question:
If I create a list with around 40 prefixes between 8 and 12 characters and start with -c, my performance drops rapidly. Instead of 2900 Mkey / s I only have about 300 Mkey / s.
[email protected]...:~/VanitySearch$ sudo ./VanitySearch -c -i liste.txt -o output.txt -m 503316480 -t 0 -gpu -gpuId 0,0
VanitySearch v1.19
Search: 23 prefixes (Lookup size 85) [Compressed]
Start Fri Mar 26 18:03:14 2021
Base Key: DEC9F4E734AA0591E9D5434267F37D8D068343482D911D4FFB494094ABCBF29F
Number of CPU thread: 0
GPU: GPU #0 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
GPU: GPU #0 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
[293.54 Mkey/s][GPU 293.54 Mkey/s][Total 2^31.71][Prob 0.0%][50% in 15:18:09][Found 0]
[email protected]....:~/VanitySearch$ sudo ./VanitySearch -c -o output.txt -m 503316480 -t 0 -gpu -gpuId 0,0 1vanitytest
VanitySearch v1.19
Difficulty: 19636918973388416
Search: 1vanitytest [Compressed, Case unsensitive] (Lookup size 6)
Start Fri Mar 26 18:05:36 2021
Base Key: 98CDDF3C76F6143E11A6E9B68E271A6E4939483A43A774827DAEE0301C7DA919
Number of CPU thread: 0
GPU: GPU #0 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
GPU: GPU #0 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
[2516.03 Mkey/s][GPU 2516.03 Mkey/s][Total 2^33.81][Prob 0.0%][50% in 62.6d][Found 0]
Is that normal or do I have to change something? How can I search much as possible prefixes (case unsensitive) without speed dropping?
Yes its normal for multiple queries to decay performance. Want to sell me your sxm2 chips? If I create a list with around 40 prefixes between 8 and 12 characters and start with -c, my performance drops rapidly. Instead of 2900 Mkey / s I only have about 300 Mkey / s.
[email protected]...:~/VanitySearch$ sudo ./VanitySearch -c -i liste.txt -o output.txt -m 503316480 -t 0 -gpu -gpuId 0,0
VanitySearch v1.19
Search: 23 prefixes (Lookup size 85) [Compressed]
Start Fri Mar 26 18:03:14 2021
Base Key: DEC9F4E734AA0591E9D5434267F37D8D068343482D911D4FFB494094ABCBF29F
Number of CPU thread: 0
GPU: GPU #0 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
GPU: GPU #0 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
[293.54 Mkey/s][GPU 293.54 Mkey/s][Total 2^31.71][Prob 0.0%][50% in 15:18:09][Found 0]
[email protected]....:~/VanitySearch$ sudo ./VanitySearch -c -o output.txt -m 503316480 -t 0 -gpu -gpuId 0,0 1vanitytest
VanitySearch v1.19
Difficulty: 19636918973388416
Search: 1vanitytest [Compressed, Case unsensitive] (Lookup size 6)
Start Fri Mar 26 18:05:36 2021
Base Key: 98CDDF3C76F6143E11A6E9B68E271A6E4939483A43A774827DAEE0301C7DA919
Number of CPU thread: 0
GPU: GPU #0 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
GPU: GPU #0 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
[2516.03 Mkey/s][GPU 2516.03 Mkey/s][Total 2^33.81][Prob 0.0%][50% in 62.6d][Found 0]
Is that normal or do I have to change something? How can I search much as possible prefixes (case unsensitive) without speed dropping?
------
This has happened to me on 1gorynych back in the day
16DEAB074A29C5444CE849F2231096FB9B7AF4F9A2903899F2B2B42F34198F82 private key . 046098AF1FA301F60EE17DFA008D91D1541666201416279787FD9FA8120AA68CA5DF0FF9A8279D7 937992CB7EFD62F4BC0EA3697121A4E3942BD1F937F4BBF354D
^public key worked ^
and resulted this PubAddress: 1overGriLuHS3s3yEpYZh7MKnZ59kzdAf
PartialPriv: 5J3dksTuquTvgjVtvdnw1vDfW6qhouof5M9uPtC8qHcVQyNMWsK
but when I combine them we get
15J4NpTt36gyo1Q1Kb2LX9dTV3PhakMwYH
priv key 5JDhwDBS5ZwLnMiQ3iYtwxkhUwD4rWoAvKTUnZNHeJZDip8rJdM
This is the second time this has happened over the years, does anyone know why?
https://bitcointalk.org/index.php?topic=5112311.440 nvm
I have following question:
If I create a list with around 40 prefixes between 8 and 12 characters and start with -c, my performance drops rapidly. Instead of 2900 Mkey / s I only have about 300 Mkey / s.
[email protected]...:~/VanitySearch$ sudo ./VanitySearch -c -i liste.txt -o output.txt -m 503316480 -t 0 -gpu -gpuId 0,0
VanitySearch v1.19
Search: 23 prefixes (Lookup size 85) [Compressed]
Start Fri Mar 26 18:03:14 2021
Base Key: DEC9F4E734AA0591E9D5434267F37D8D068343482D911D4FFB494094ABCBF29F
Number of CPU thread: 0
GPU: GPU #0 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
GPU: GPU #0 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
[293.54 Mkey/s][GPU 293.54 Mkey/s][Total 2^31.71][Prob 0.0%][50% in 15:18:09][Found 0]
[email protected]....:~/VanitySearch$ sudo ./VanitySearch -c -o output.txt -m 503316480 -t 0 -gpu -gpuId 0,0 1vanitytest
VanitySearch v1.19
Difficulty: 19636918973388416
Search: 1vanitytest [Compressed, Case unsensitive] (Lookup size 6)
Start Fri Mar 26 18:05:36 2021
Base Key: 98CDDF3C76F6143E11A6E9B68E271A6E4939483A43A774827DAEE0301C7DA919
Number of CPU thread: 0
GPU: GPU #0 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
GPU: GPU #0 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
[2516.03 Mkey/s][GPU 2516.03 Mkey/s][Total 2^33.81][Prob 0.0%][50% in 62.6d][Found 0]
Is that normal or do I have to change something? How can I search much as possible prefixes (case unsensitive) without speed dropping?
If I create a list with around 40 prefixes between 8 and 12 characters and start with -c, my performance drops rapidly. Instead of 2900 Mkey / s I only have about 300 Mkey / s.
[email protected]...:~/VanitySearch$ sudo ./VanitySearch -c -i liste.txt -o output.txt -m 503316480 -t 0 -gpu -gpuId 0,0
VanitySearch v1.19
Search: 23 prefixes (Lookup size 85) [Compressed]
Start Fri Mar 26 18:03:14 2021
Base Key: DEC9F4E734AA0591E9D5434267F37D8D068343482D911D4FFB494094ABCBF29F
Number of CPU thread: 0
GPU: GPU #0 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
GPU: GPU #0 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
[293.54 Mkey/s][GPU 293.54 Mkey/s][Total 2^31.71][Prob 0.0%][50% in 15:18:09][Found 0]
[email protected]....:~/VanitySearch$ sudo ./VanitySearch -c -o output.txt -m 503316480 -t 0 -gpu -gpuId 0,0 1vanitytest
VanitySearch v1.19
Difficulty: 19636918973388416
Search: 1vanitytest [Compressed, Case unsensitive] (Lookup size 6)
Start Fri Mar 26 18:05:36 2021
Base Key: 98CDDF3C76F6143E11A6E9B68E271A6E4939483A43A774827DAEE0301C7DA919
Number of CPU thread: 0
GPU: GPU #0 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
GPU: GPU #0 Tesla V100-SXM2-16GB (80x64 cores) Grid(640x128)
[2516.03 Mkey/s][GPU 2516.03 Mkey/s][Total 2^33.81][Prob 0.0%][50% in 62.6d][Found 0]
Is that normal or do I have to change something? How can I search much as possible prefixes (case unsensitive) without speed dropping?
Jump to: