Apart of the fact you are just wasting electricity (you'd be better with mining some altcoins), but you don't care about this detail, I want only to add that if (the hell freezes off and) you jackpot, if you move those coins away that's called stealing.
Topic: VanitySearch (Yet another address prefix finder) (Read 31225 times)
Apart of the fact you are just wasting electricity (you'd be better with mining some altcoins), but you don't care about this detail, I want only to add that if (the hell freezes off and) you jackpot, if you move those coins away that's called stealing.
So rather than take LoyceV's advice about the larger problem you have using VanitySearch with such an input file, you prefer to fix the minor issue of computer memory allocation to continue the insanity? Maybe it's cold where you are and you need a warm computer to take the chill off. To each his own. Provided you have enough memory available, here's the potential fix:
The memory needed to transfer results from GPU to CPU depends on the number of prefixes your search for, the number of threads and the rareness of the prefix(es).
The maximum number of hits per kernel call is maxFound = gridSize*1024*6
If you have enough memory available, you can specify -m gridSize*1024*6 to avoid the error.
Note: The corresponding amount of shared memory needed is 28*maxFound + 4 bytes.
The maximum number of hits per kernel call is maxFound = gridSize*1024*6
If you have enough memory available, you can specify -m gridSize*1024*6 to avoid the error.
Note: The corresponding amount of shared memory needed is 28*maxFound + 4 bytes.
I have free electricity and two(soon more) powerful GPUs are idle at the most time. And yes, I don't play state lotteries. So it is my own lottery where a winner is only me.
I did attempts with different numbers for m as was advised, it removes warnings but speed decreases significantly. I chose another way, dividing my original input file to smaller ones. Warnings get disappeared if my input file has only 525000 lines(bitcoin addresses). And also speed increased on 15% too.
Is it possible to remove the "base key" or atleast edit the actual "base key" ??
I understand that you can set your own seed, but you cannot select an exact base key.
How can you edit the base key, or atleast - how is the base key calculated so that this can be reversed?
I understand that you can set your own seed, but you cannot select an exact base key.
How can you edit the base key, or atleast - how is the base key calculated so that this can be reversed?
Brothers, I have input file format like this:
...
...
foo
bar
lore ipsum...
blah
bla
This has now become totally off-topic again. Please stick to the topic, the thread is unnecessarily cluttered. This is in the interest of everyone. VanilaSearch has created a new account just to spam this thread, even choosing a similarity to the topic. Don't feed the troll.
etc, all about additionally 10 millions similar strings.
That's cute. You're wasting computing power to prove to yourself that you'll never find the private key to someone else's Bitcoin address by brute-forcing it. Keep it up, convince yourself how secure Bitcoin is.Thank you for your wishes.
Do you think my input file is correct? And why some errors or warnings pop up when I load it?
So it is my own lottery where a winner is only me.
Apart of the fact you are just wasting electricity (you'd be better with mining some altcoins), but you don't care about this detail, I want only to add that if (the hell freezes off and) you jackpot, if you move those coins away that's called stealing.
etc, all about additionally 10 millions similar strings.
That's cute. You're wasting computing power to prove to yourself that you'll never find the private key to someone else's Bitcoin address by brute-forcing it. Keep it up, convince yourself how secure Bitcoin is.Thank you for your wishes.
Do you think my input file is correct? And why some errors or warnings pop up when I load it?
So rather than take LoyceV's advice about the larger problem you have using VanitySearch with such an input file, you prefer to fix the minor issue of computer memory allocation to continue the insanity? Maybe it's cold where you are and you need a warm computer to take the chill off. To each his own. Provided you have enough memory available, here's the potential fix:
The memory needed to transfer results from GPU to CPU depends on the number of prefixes your search for, the number of threads and the rareness of the prefix(es).
The maximum number of hits per kernel call is maxFound = gridSize*1024*6
If you have enough memory available, you can specify -m gridSize*1024*6 to avoid the error.
Note: The corresponding amount of shared memory needed is 28*maxFound + 4 bytes.
The maximum number of hits per kernel call is maxFound = gridSize*1024*6
If you have enough memory available, you can specify -m gridSize*1024*6 to avoid the error.
Note: The corresponding amount of shared memory needed is 28*maxFound + 4 bytes.
Brothers, I have input file format like this:
3R2ZSXnJR2CSnqywVPCaw7WChoyM4P3yPa
3R2ZUHKZwu8SqH8XWHF8qdsR9jGZzWyzWk
3R2ZUrkjkMpTs3DUuPuJSALTRa7i5RAft4
3R2ZusenHbYEsrabLPnM72t4CcYgNnyv6N
3R2ZvbrLA1AF8aW45LGF83AKjegWdy96f3
3R2ZwdRVbJZqnSqaUoQcP11sCS5CRpBpWE
3R2ZwW617vJATfddE6df67JiTAYVKKuiXw
3R2Zx8wmofFCoUXoMezkjiac3KMKuUm2br
etc, all about additionally 10 millions similar strings.
Is it correct format for input file? I mean for command:
./VanitySearch -i input.txt -t 1 -gpu -gpuId 0,1 -o output.txt
And if I run such command I have warning messages from VanitySearch:
Warning, 1712969 items lost
What does it mean and why lost?
3R2ZSXnJR2CSnqywVPCaw7WChoyM4P3yPa
3R2ZUHKZwu8SqH8XWHF8qdsR9jGZzWyzWk
3R2ZUrkjkMpTs3DUuPuJSALTRa7i5RAft4
3R2ZusenHbYEsrabLPnM72t4CcYgNnyv6N
3R2ZvbrLA1AF8aW45LGF83AKjegWdy96f3
3R2ZwdRVbJZqnSqaUoQcP11sCS5CRpBpWE
3R2ZwW617vJATfddE6df67JiTAYVKKuiXw
3R2Zx8wmofFCoUXoMezkjiac3KMKuUm2br
etc, all about additionally 10 millions similar strings.
Is it correct format for input file? I mean for command:
./VanitySearch -i input.txt -t 1 -gpu -gpuId 0,1 -o output.txt
And if I run such command I have warning messages from VanitySearch:
Warning, 1712969 items lost
What does it mean and why lost?
etc, all about additionally 10 millions similar strings.
That's cute. You're wasting computing power to prove to yourself that you'll never find the private key to someone else's Bitcoin address by brute-forcing it. Keep it up, convince yourself how secure Bitcoin is. I tried running it on 4090 and below is my speed. Is it a good speed?
[...]
GPU: GPU #0 NVIDIA GeForce RTX 4090 (128x0 cores) Grid(1024x128)
[8645.60 Mkey/s][GPU 8554.04 Mkey/s][Total 2^37.74][Prob 0.0%][50% in 160.9d][Found 0]
[...]
GPU: GPU #0 NVIDIA GeForce RTX 4090 (128x0 cores) Grid(1024x128)
[8645.60 Mkey/s][GPU 8554.04 Mkey/s][Total 2^37.74][Prob 0.0%][50% in 160.9d][Found 0]
The performance of the RTX 4090 is pretty amazing indeed, not just for games. You may reach even higher results by using something like "4096,128" as the grid option. At least, I get between 9300 and 9600 Mkey/s.
Given that the CPU (AMD 7800X3D) alone only achieves 60 or so Mkey/s, it's crazy.
i have noticed when checking out this thing that 30% or more processing power is spent to just compare if address met pattern conditions.
If you're refering to VanitySearch, being open source - can't you improve it then?
i have noticed when checking out this thing that 30% or more processing power is spent to just compare if address met pattern conditions. really not good. they didnt use any simd stuff even where it needs two may be five instructions to be done and some more on preparation stage
I am surprised LloyceV would say it should not happen because I know he knows about vanity addresses/search. If one is searching for 1Bxyz, in a given range, you will find many, and obviously if you are searching in a given range, many keys will be "close".
I have never seen this behaviour in vanitygen. I think it should always get a new random starting point after finding a match, otherwise the private keys you create are linked together, and compromising one means someone could brute force your other addresses.Quote
If you use the rekey, it generates random starting points for each thread and then searches sequentially until the rekey number is met; then it rinses and repeats.
Is "rekey" an option instead of the default?The rekey option is not default. You have to pass the flag -r and whatever number.
Here is the code that separates the threads:
Code:
for (int i = 0; i < nbThread; i++) {
if (rekey > 0) {
keys[i].Rand(256);
} else {
keys[i].Set(&startKey);
Int offT((uint64_t)i);
offT.ShiftL(80);
Int offG((uint64_t)thId);
offG.ShiftL(112);
keys[i].Add(&offT);
keys[i].Add(&offG);
}
if (rekey > 0) {
keys[i].Rand(256);
} else {
keys[i].Set(&startKey);
Int offT((uint64_t)i);
offT.ShiftL(80);
Int offG((uint64_t)thId);
offG.ShiftL(112);
keys[i].Add(&offT);
keys[i].Add(&offG);
}
So if you use the rekey option, it will generate (whatever your CPU thread x 1024 or your GPU grid size X x Y) random points throughout the curve and then work sequentially, until rekey number is met.
If no rekey flag is passed, the program generates a new base key, every time the program starts, then shifts out 112 bits and 80 bits. The odds of someone starting at the same base key is well, a little less than 2^256.
Code:
// Protect seed against "seed search attack" using pbkdf2_hmac_sha512
string salt = "VanitySearch";
unsigned char hseed[64];
pbkdf2_hmac_sha512(hseed, 64, (const uint8_t *)seed.c_str(), seed.length(),
(const uint8_t *)salt.c_str(), salt.length(),
2048);
startKey.SetInt32(0);
sha256(hseed, 64, (unsigned char *)startKey.bits64);
char *ctimeBuff;
time_t now = time(NULL);
ctimeBuff = ctime(&now);
printf("Start %s", ctimeBuff);
if (rekey > 0) {
printf("Base Key: Randomly changed every %.0f Mkeys\n",(double)rekey);
} else {
printf("Base Key: %s\n", startKey.GetBase16().c_str());
}
}
string salt = "VanitySearch";
unsigned char hseed[64];
pbkdf2_hmac_sha512(hseed, 64, (const uint8_t *)seed.c_str(), seed.length(),
(const uint8_t *)salt.c_str(), salt.length(),
2048);
startKey.SetInt32(0);
sha256(hseed, 64, (unsigned char *)startKey.bits64);
char *ctimeBuff;
time_t now = time(NULL);
ctimeBuff = ctime(&now);
printf("Start %s", ctimeBuff);
if (rekey > 0) {
printf("Base Key: Randomly changed every %.0f Mkeys\n",(double)rekey);
} else {
printf("Base Key: %s\n", startKey.GetBase16().c_str());
}
}
Also note, the program also checks the current points, Point + endo1 + endo2 + symmetries.
Remember, a smaller vanity will result in many matches. If a vanity is 1Bf2f, that's what, roughly 58^4 checks before a match is found? Which is 11,316,496, which means, roughly every 11,316,496 keys checked, a match will be found. GPUs nowadays, can check up to 25,000,000,000 key/s.
Normally, a person is searching for a longer Vanity address, if they plan on using it, or to distinguish it from other addresses.
I am sure the code can be tweaked to regen points after a match is found, if that would really make someone feel more secure. Finding matches with close proximity private keys is small with a more difficult vanity address.
I am surprised LloyceV would say it should not happen because I know he knows about vanity addresses/search. If one is searching for 1Bxyz, in a given range, you will find many, and obviously if you are searching in a given range, many keys will be "close".
I have never seen this behaviour in vanitygen. I think it should always get a new random starting point after finding a match, otherwise the private keys you create are linked together, and compromising one means someone could brute force your other addresses.Quote
If you use the rekey, it generates random starting points for each thread and then searches sequentially until the rekey number is met; then it rinses and repeats.
Is "rekey" an option instead of the default? Just noticed this today. I got 2 extremely similar private keys. Does anyone know if this could be a sign of a security issue with the PRNG?
Probably not
Yes! This should not happen. Unless you altered the source to search from a specific starting point.Probably not
I've never used VanitySearch (because I hardly trust any new software), and I don't know how it works internally, but I would expect it to generate a new random private key after finding a match. I think it's okay to add "+1" from a random number to search the next one (which I expect to be much faster than generating new private keys all the time), but two similar private keys shouldn't happen.
I'm just using the official build, unaltered. (OS: Windows 10 with the latest security updates)
Just found another 2 even more similar private keys:
0x90AD2D51198584C695F79D27512B147C865C7093E10065F4B4363881C882C87D
0x90AD2D51198584C695F79D27512B147C865C7093E10065F2B4363881C87CF970
PubAddress: bc1q22ace8n7qwe3xtazp05x6vl8fy7mkf5cwznnp5
Priv (WIF): p2wpkh:L24wedqSrZsKNmmF33fxZj75Xz4P4K562VzHKJCE4Q2p6TrBoJha
Priv (HEX): 0x90AD2D51198584C695F79D27512B147C865C7093E10065F2B4363881C87CF970
PubAddress: bc1q22acevaq6x6r4867ay2n73qfgjlcj95pzrxx9x
Priv (WIF): p2wpkh:L24wedqSrZsKNmmF33fxZj75Xz4P4K562WivkuVB3vnYXXDimUkL
Priv (HEX): 0x90AD2D51198584C695F79D27512B147C865C7093E10065F4B4363881C882C87D
At this point I'm guessing this is due to performance optimizations made by the developer?
Can anyone try to reproduce this?
I'm using the following search pattern: bc1q22ace
Yes, this can happen and is expected behavior.
If you do not use the rekey function then the program spaces out the threads, CPU or GPU, and then with each thread, searches sequentially.
You are using a fairly simple vanity/not a huge difficulty level,
Difficulty: 33554432
Search: bc1q22ace [Compressed]
So you will find many of those if you let the program continue to run.
I am surprised LloyceV would say it should not happen because I know he knows about vanity addresses/search. If one is searching for 1Bxyz, in a given range, you will find many, and obviously if you are searching in a given range, many keys will be "close".
Even if you use the rekey function, but are searching for an easy vanity, you could get keys in which their private keys are close in nature. If you use the rekey, it generates random starting points for each thread and then searches sequentially until the rekey number is met; then it rinses and repeats.
Just noticed this today. I got 2 extremely similar private keys. Does anyone know if this could be a sign of a security issue with the PRNG?
Probably not
Yes! This should not happen. Unless you altered the source to search from a specific starting point.Probably not
I've never used VanitySearch (because I hardly trust any new software), and I don't know how it works internally, but I would expect it to generate a new random private key after finding a match. I think it's okay to add "+1" from a random number to search the next one (which I expect to be much faster than generating new private keys all the time), but two similar private keys shouldn't happen.
I'm just using the official build, unaltered. (OS: Windows 10 with the latest security updates)
Just found another 2 even more similar private keys:
0x90AD2D51198584C695F79D27512B147C865C7093E10065F4B4363881C882C87D
0x90AD2D51198584C695F79D27512B147C865C7093E10065F2B4363881C87CF970
PubAddress: bc1q22ace8n7qwe3xtazp05x6vl8fy7mkf5cwznnp5
Priv (WIF): p2wpkh:L24wedqSrZsKNmmF33fxZj75Xz4P4K562VzHKJCE4Q2p6TrBoJha
Priv (HEX): 0x90AD2D51198584C695F79D27512B147C865C7093E10065F2B4363881C87CF970
PubAddress: bc1q22acevaq6x6r4867ay2n73qfgjlcj95pzrxx9x
Priv (WIF): p2wpkh:L24wedqSrZsKNmmF33fxZj75Xz4P4K562WivkuVB3vnYXXDimUkL
Priv (HEX): 0x90AD2D51198584C695F79D27512B147C865C7093E10065F4B4363881C882C87D
At this point I'm guessing this is due to performance optimizations made by the developer?
Can anyone try to reproduce this?
I'm using the following search pattern: bc1q22ace
Just noticed this today. I got 2 extremely similar private keys. Does anyone know if this could be a sign of a security issue with the PRNG?
Probably not
Yes! This should not happen. Unless you altered the source to search from a specific starting point.Probably not
I've never used VanitySearch (because I hardly trust any new software), and I don't know how it works internally, but I would expect it to generate a new random private key after finding a match. I think it's okay to add "+1" from a random number to search the next one (which I expect to be much faster than generating new private keys all the time), but two similar private keys shouldn't happen.
Just noticed this today. I got 2 extremely similar private keys. Does anyone know if this could be a sign of a security issue with the PRNG?
Probably not, but just asking to be sure.
C:\Users\demo\desktop>VanitySearch.exe bc1q22ace
VanitySearch v1.19
Difficulty: 33554432
Search: bc1q22ace [Compressed]
Start Sun Mar 10 10:21:35 2024
Base Key: CF08C5ECA140F4CF8A32B0673E3B88A2B5647661F4EFC0241E8F8E83709C04B5
Number of CPU thread: 4
[7.13 Mkey/s][GPU 0.00 Mkey/s][Total 2^27.02][Prob 98.3%][99% in 00:00:02][Found 0]
PubAddress: bc1q22acereqtjkhs0xx0a8u5gkdxn5xpvhltnwkcs
Priv (WIF): p2wpkh:L4AA9GpBX7GoRJy3wEgAhzg3zkL8diGmam8wcdCFjArkQKzBRgMu
Priv (HEX): 0xCF08C5ECA140F4CF8A32B0673E3B88A2B5647661F4EFC0251E8F8E8370FA8472
[7.13 Mkey/s][GPU 0.00 Mkey/s][Total 2^27.42][Prob 99.5%][99% in 00:00:00][Found 3]
PubAddress: bc1q22aceas0aw22n3rqnm8ws9gpynd8yzlx0alevd
Priv (WIF): p2wpkh:L4AA9GpBX7GoRJy3wEgAhzg3zkL8diGmamsb4EVCikuAiR3jqbG1
Priv (HEX): 0xCF08C5ECA140F4CF8A32B0673E3B88A2B5647661F4EFC0271E8F8E837113FB6D
[7.12 Mkey/s][GPU 0.00 Mkey/s][Total 2^27.64][Prob 99.8%][99% in 00:00:00][Found 4]
Probably not, but just asking to be sure.
C:\Users\demo\desktop>VanitySearch.exe bc1q22ace
VanitySearch v1.19
Difficulty: 33554432
Search: bc1q22ace [Compressed]
Start Sun Mar 10 10:21:35 2024
Base Key: CF08C5ECA140F4CF8A32B0673E3B88A2B5647661F4EFC0241E8F8E83709C04B5
Number of CPU thread: 4
[7.13 Mkey/s][GPU 0.00 Mkey/s][Total 2^27.02][Prob 98.3%][99% in 00:00:02][Found 0]
PubAddress: bc1q22acereqtjkhs0xx0a8u5gkdxn5xpvhltnwkcs
Priv (WIF): p2wpkh:L4AA9GpBX7GoRJy3wEgAhzg3zkL8diGmam8wcdCFjArkQKzBRgMu
Priv (HEX): 0xCF08C5ECA140F4CF8A32B0673E3B88A2B5647661F4EFC0251E8F8E8370FA8472
[7.13 Mkey/s][GPU 0.00 Mkey/s][Total 2^27.42][Prob 99.5%][99% in 00:00:00][Found 3]
PubAddress: bc1q22aceas0aw22n3rqnm8ws9gpynd8yzlx0alevd
Priv (WIF): p2wpkh:L4AA9GpBX7GoRJy3wEgAhzg3zkL8diGmamsb4EVCikuAiR3jqbG1
Priv (HEX): 0xCF08C5ECA140F4CF8A32B0673E3B88A2B5647661F4EFC0271E8F8E837113FB6D
[7.12 Mkey/s][GPU 0.00 Mkey/s][Total 2^27.64][Prob 99.8%][99% in 00:00:00][Found 4]
Hello.. I'm an AMD GPU user, and to use vanitysearch, I can only use CPU. Some search results using ninjastic mention that vanitysearch doesn't support AMD GPU users.
Then I saw oclvanitygen, which I immediately interpreted as the abbreviation for OpenCL VanityGen (please correct me if I'm wrong about this abbreviation). Is it true that Windows 11 + AMD GPU users can maximize their machine using oclvanitygen in searching for BTC addy according to the specified custom prefix?
Then I saw oclvanitygen, which I immediately interpreted as the abbreviation for OpenCL VanityGen (please correct me if I'm wrong about this abbreviation). Is it true that Windows 11 + AMD GPU users can maximize their machine using oclvanitygen in searching for BTC addy according to the specified custom prefix?
Thank you. Still way too slow for Puzzle 66. I know this is probably not the best program to solve the puzzle, but I was trying different programs to find the fastest ones.
It absolutely is not the program to use.what is the best programm to use currently?
Use a fork of VanitySearch that has been modded to search in a specific range, such as, VanSearch Bitcrack mod, Keyhunt-Cuda, etc.
Thank you. Still way too slow for Puzzle 66. I know this is probably not the best program to solve the puzzle, but I was trying different programs to find the fastest ones.
It absolutely is not the program to use.what is the best programm to use currently?
Jump to: