VanitySearch (Yet another address prefix finder)

[BitMaxz]

I tried running it on 4090 and below is my speed. Is it a good speed?


.\VanitySearch.exe -stop -gpu 1Testx232f
VanitySearch v1.19
Difficulty: 173346595075428800
Search: 1Testx232f [Compressed]
Start Sat Feb 17 17:40:57 2024
Base Key: DA5A15FF6EE38ABBC1D0F21D881998D19D0009F88479FBF0D83000D59697C316
Number of CPU thread: 31
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]

That's actually a pretty good speed it is 6 times faster than GTX 2070.

If you are looking for a list of benchmark speeds for other GPUs and CPUs there is an old post posted by Dave you can check this link below.

- https://bitcointalk.org/index.php?topic=5112311.msg50823897#msg50823897

For CPU check this https://en.bitcoin.it/wiki/Vanitygen

[LoyceV]

Is it a good speed?

I remember the days of running oclvanitygen on my GeForce 840M with 9 Mkey/s. You're 1000 times faster.

Tip: search for more than one prefix at a time. It large increases the chance of finding one of them.

[stilichovandal]

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.

[WanderingPhilospher]

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.

The speed you see, takes on an x amount of speed-up for:

Code:

counters[thId] += 6ULL * STEP_SIZE * nbThread; // Point +  endo1 + endo2 + symetrics

It's not a true 6 x speed up, but if you were searching, just in a given range, the speed you see now, would drop.

Also, 5 out of the 6 are not looking in a given range. And with the original VanitySearch, you cannot search in the 66 bit range. You will have to do modifications, or use a fork that has already been modified or use Keyhunt-Cuda.

But yes, the RTX 4090 is the big bad bawse on all GPU programs. I've ran them against A and H100s, 4090 wins. And the crazy thing is, I do not think all of the cards' features are being unlocked/used. Most codes were written when the RTX 20xx series were out.

[Gjors]

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?

[WanderingPhilospher]

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.

[bayu7adi]

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?

[RoxxR]

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]  

[LoyceV]

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.

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.

[RoxxR]

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.

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

[WanderingPhilospher]

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.

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.

[LoyceV]

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.

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?

[WanderingPhilospher]

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.

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);
    }

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());
  }

}

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.

[alexeyneu]

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

[little-endian]

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]

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?

[LoyceV]

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.

[xhomerx10]

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.

[NeuroticFish]

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.

[citb0in]

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.

[DecipherBTC]

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?