VanitySearch (Yet another address prefix finder)

[Jean_Luc]

Here is the way the final private key is reconstructed:

1) (privKey + partialKey) mod n
2) (lambda1 * privKey + partialKey) mod n
3) (lambda2 * privKey + partialKey) mod n
4) (-privKey + partialKey) mod n
5) (-lambda1 * privKey + partialKey) mod n
6) (-lambda2 * privKey + partialKey) mod n

As you don't know the privKey when mining , it is not possible to calculate an offset to add in order to reduce to case 1.
May be I also missed something...

[lol.ek]

Hello. First of all: great work!
TL;DR: Can this software guess what characters are missing in pair:

Code:

1DLLsqnKALAk9XDx2ugYNBHn6jfLLDiE1

L2vhmg**********3a3pkSrW986Cx2cUyAnj7x2pXvASqvHBkQb8

I really need it for some of my paper wallets...

Thanks!

[Jean_Luc]

Hello. First of all: great work!
TL;DR: Can this software guess what characters are missing in pair:

Code:

1DLLsqnKALAk9XDx2ugYNBHn6jfLLDiE1
L2vhmg**********3a3pkSrW986Cx2cUyAnj7x2pXvASqvHBkQb8

Hello,
As it is no, it is not optimized for that. However with few modifications of the code and a powerful hardware it can be done...

[Telariust]

Can this software guess what characters are missing in pair:

Code:

1DLLsqnKALAk9XDx2ugYNBHn6jfLLDiE1
L2vhmg**********3a3pkSrW986Cx2cUyAnj7x2pXvASqvHBkQb8

I really need it for some of my paper wallets...
Thanks!

VanitySearch is not intended for this, but you need the BitCrack program.

FAQ, How to recover a bitcoin PaperWallet using BitCrack.

to avoid offtopic:
post moved to bitcointalk.org/index.php?topic=4453897.msg52106273#msg52106273

[gaz1]

Hi All, you can add a command to save a list of 100 addresses in a text file and open the next file to save.

[feryjhie]

Hi All, you can add a command to save a list of 100 addresses in a text file and open the next file to save.

actually there is a command for you to save the generated address on a text file and you can use the command below

Code:

-o outputfile: Output results to the specified file

so the example will be like this VanitySearch.exe -o test.txt 3test and the output will be on text file named test.txt

[DaveF]

Just added the GTX 1650 to the list of cards:
https://bitcointalk.org/index.php?topic=5112311.msg50823897#msg50823897

You get over 500 MK/s on a $150 card from Amazon. Not to shabby. ( link to the actual card I am using: https://amzn.to/2yevV7i )

What is *VERY* nice is no PCIe plug is required on that card. So you can run it on systems that don't have PCIe coming off the power supply. The one I tested is now in an old Dell core i3 machine that has the crappy stock power supply that had no PCIe.

-Dave

[asche]

What is *VERY* nice is no PCIe plug is required on that card. So you can run it on systems that don't have PCIe coming off the power supply. The one I tested is now in an old Dell core i3 machine that has the crappy stock power supply that had no PCIe.

-Dave

I think PCIe port only provides 75W or so. What this means is the card will run, but only offer limited performance.
Maybe just pick a card with a lower tdp/performance/consumption/Price in that case?

In some cases also the pci-e is enough in theory but power from the PSU directly is preferred to avoid overheating of the MB/PCIe port.

[malevolent]

I think PCIe port only provides 75W or so. What this means is the card will run, but only offer limited performance.
Maybe just pick a card with a lower tdp/performance/consumption/Price in that case?

In some cases also the pci-e is enough in theory but power from the PSU directly is preferred to avoid overheating of the MB/PCIe port.

*75W if it follows PCI Express specifications

Which is a huge if:





PCIe slots in older/cheaper boards might die under 24/7 use if a card continuously exceeds this limit.

[DaveF]

It's at the 75W mark.
NVidia's own specs don't have the power connector:

From https://www.nvidia.com/en-us/geforce/graphics-cards/gtx-1650/

Maximum GPU Temperature (in C)     92
Graphics Card Power (W)    75
Recommended System Power (W)     300
Supplementary Power Connectors    None

With that being said, YES it's at the limit of the PCIe spec, but it's one of the best MK/s card at the moment.
Also, and this might be a local thing but, where I live (Long Island, NY) there are a lot of local PC shops that have these 2nd/3rd/4th gen i3 / i5 machines (4GB Ram / old small slow drive) for well under $100 many at the $49.99 price point.

So if you want a machine to run VanitySearch, that will do 500MK/s and not spend a lot you can get this done for ~$250. If you are worried about killing the PCIe slot or the fact that the power supply is old and might not stand up to it. You can get a spare PC and still be under $350.

That is why I made a separate post about it instead of just adding it to the list.

As with everything YMMV but still, I think it's a great deal.

-Dave

[malevolent]

It's at the 75W mark.
NVidia's own specs don't have the power connector:

From https://www.nvidia.com/en-us/geforce/graphics-cards/gtx-1650/

If you don't measure it yourself, you won't know if it doesn't pull more power from the PCIe slot. Reference GTX 750 Ti peaks at 140W as shown in the graph above, even thought nVidia claims it should pull no more than 60 watts: https://www.geforce.com/hardware/desktop-gpus/geforce-gtx-750-ti/specifications That said if it's not one of the cheapest boards it shouldn't be an issue.

[DaveF]

If you don't measure it yourself, you won't know if it doesn't pull more power from the PCIe slot. Reference GTX 750 Ti peaks at 140W as shown in the graph above, even thought nVidia claims it should pull no more than 60 watts: https://www.geforce.com/hardware/desktop-gpus/geforce-gtx-750-ti/specifications That said if it's not one of the cheapest boards it shouldn't be an issue.

Since I don't have a way of checking how much power is going through the PCIe port I will have to hack some numbers together from the pull though the UPS it's plugged into.
And the draw though the 12V rail of a power supply.
Don't know how accurate it will be, but it will show a big overage like the one you pointed out (60 vs 145) no way it will show 75 vs 81.

However, for now lets either table this or move it to a new / different thread because I do not want to derail this thread from what Jean_Luc is doing.

-Dave

[Telariust]

In my opinion, you need to apply sym/endomorph to the candidate and not apply to splitKey or the result of addition

As you don't know the privKey when mining , it is not possible to calculate an offset to add in order to reduce to case 1.
May be I also missed something...

Well of course it’s possible! Are you sure you're a jedidev?) Use Force, Luc!)
Oh, ok, explain, all simple.

I compared ver 1.12 vs 1.13 to understand how you added splitkey support.
You generate starting points from the seed, and add a splitkey to them. That is the whole problem.
With this implementation, it is necessary to apply symY/endomorph to the splitkey.
(what yourself do at the stage of indirect verification of the pair)
And you did not need to make changes to the code of cuda.
It’s convenient, a minimum of edits, everything works, yes. But not with appspot pool.

To make it compatible with the pool, you need to add a splitkey after applying symY/endomorph right before hash160.
It’s not very difficult there, but the performance will suffer, because the operations of adding points are added.

I have fixed a few functions for cpu -nosse only, a rough prototype demonstrating that this is possible.
Code is sloow, and problem not in sse. I think secp->AddDirect() is really tardy. I hope you find a quick solution.

Code:

C:\Users\User\source\repos\VanitySearch-1.15\x64\Release>VanitySearch -stop -t 4 -s "A Strong Password" -kp
Priv : L2JtWKgFrwzjyw4UQjaCMHu8Cq3e6yuq4Thdjd6H462XnTJz9ftE
Pub  : 0280C3E351A2F47F1A09A20F130B922C2BE2009F4CB4892901559AE09ABB357389

C:\Users\User\source\repos\VanitySearch-1.15\x64\Release>VanitySearch -stop -t 4 -sp 0280C3E351A2F47F1A09A20F130B922C2BE2009F4CB4892901559AE09ABB357389 -nosse -o __keyinfo.txt 12345
VanitySearch v1.15
Difficulty: 4553521
Search: 12345 [Compressed, with public key]
Start Sat Aug  3 03:39:07 2019
Base Key: A6CDE51DC26E832F9C7AB673FF6B5F8F9D0C7F121E9A115CAC45B7884671F757
Number of CPU thread: 4
0.995 MK/s (GPU 0.000 MK/s) (2^20.92) [P 35.41%][50.00% in 00:00:01][0]

C:\Users\User\source\repos\VanitySearch-1.15\x64\Release>type __keyinfo.txt
Pub Addr: 12345zpQiMCPgjrCHcGwZ6kUsPpiid79MK
PartialPriv: KzN1kLMYrhZfRiWM8RR4dgReCHJeZmeMuPnqKS3KNj7HSe4SUTXA

C:\Users\User\source\repos\VanitySearch-1.15\x64\Release>VanitySearch -rp L2JtWKgFrwzjyw4UQjaCMHu8Cq3e6yuq4Thdjd6H462XnTJz9ftE __keyinfo.txt

Pub Addr: 12345zpQiMCPgjrCHcGwZ6kUsPpiid79MK
Priv (WIF): p2pkh:L5TC4zufJyHogQsVkTTx5hDRYVdnpBr98JknRunUaZfiBieQTxv8
Priv (HEX): 0xF5A25AAD2AA36613D8B58511DBE851C9EBE893141C00AC90823008B942A8E6ED

Code:

void VanitySearch::getCPUStartingKey(int thId,Int& key,Point& startP) {

  if (rekey > 0) {
    key.Rand(256);
  } else {
    key.Set(&startKey);
    Int off((int64_t)thId);
    off.ShiftL(64);
    key.Add(&off);
  }
  Int km(&key);
  km.Add((uint64_t)CPU_GRP_SIZE / 2);
  startP = secp->ComputePublicKey(&km);
  //if(startPubKeySpecified)
  // startP = secp->AddDirect(startP,startPubKey);

}




void VanitySearch::checkAddresses(bool compressed, Int key, int i, Point p1) {

  unsigned char h0[20];
  Point pte1[1];
  Point pte2[1];
  
  Point ptmp;

  // classic


  if (startPubKeySpecified) {
	  ptmp = secp->AddDirect(p1, startPubKey);
  }
  else {
	  ptmp = p1;
  }

  secp->GetHash160(searchType,compressed, ptmp, h0);
  prefix_t pr0 = *(prefix_t *)h0;
  if (hasPattern || prefixes[pr0].items)
    checkAddr(pr0, h0, key, i, 0, compressed);

  // Endomorphism #1
  pte1[0].x.ModMulK1(&p1.x, &beta);
  pte1[0].y.Set(&p1.y);

  if (startPubKeySpecified) {
	  ptmp = secp->AddDirect(pte1[0], startPubKey);
  }
  else {
	  ptmp = pte1[0];
  }

  secp->GetHash160(searchType, compressed, ptmp, h0);

  pr0 = *(prefix_t *)h0;
  if (hasPattern || prefixes[pr0].items)
    checkAddr(pr0, h0, key, i, 1, compressed);

  // Endomorphism #2
  pte2[0].x.ModMulK1(&p1.x, &beta2);
  pte2[0].y.Set(&p1.y);

  if (startPubKeySpecified) {
	  ptmp = secp->AddDirect(pte2[0], startPubKey);
  }
  else {
	  ptmp = pte2[0];
  }

  secp->GetHash160(searchType, compressed, ptmp, h0);

  pr0 = *(prefix_t *)h0;
  if (hasPattern || prefixes[pr0].items)
    checkAddr(pr0, h0, key, i, 2, compressed);


  // Curve symetrie
  // if (x,y) = k*G, then (x, -y) is -k*G

  p1.y.ModNeg();

  if (startPubKeySpecified) {
	  ptmp = secp->AddDirect(p1, startPubKey);
  }
  else {
	  ptmp = p1;
  }

  secp->GetHash160(searchType, compressed, ptmp, h0);
  pr0 = *(prefix_t *)h0;
  if (hasPattern || prefixes[pr0].items)
    checkAddr(pr0, h0, key, -i, 0, compressed);

  // Endomorphism #1
  pte1[0].y.ModNeg();

  if (startPubKeySpecified) {
	  ptmp = secp->AddDirect(pte1[0], startPubKey);
  }
  else {
	  ptmp = pte1[0];
  }

  secp->GetHash160(searchType, compressed, ptmp, h0);

  pr0 = *(prefix_t *)h0;
  if (hasPattern || prefixes[pr0].items)
    checkAddr(pr0, h0, key, -i, 1, compressed);

  // Endomorphism #2
  pte2[0].y.ModNeg();

  if (startPubKeySpecified) {
	  ptmp = secp->AddDirect(pte2[0], startPubKey);
  }
  else {
	  ptmp = pte2[0];
  }

  secp->GetHash160(searchType, compressed, ptmp, h0);

  pr0 = *(prefix_t *)h0;
  if (hasPattern || prefixes[pr0].items)
    checkAddr(pr0, h0, key, -i, 2, compressed);

}




bool VanitySearch::checkPrivKey(string addr, Int &key, int32_t incr, int endomorphism, bool mode) {


  Int k(&key);
  Point sp = startPubKey;

  if (incr < 0) {
    k.Add((uint64_t)(-incr));
    k.Neg();
    k.Add(&secp->order);
    //if (startPubKeySpecified) sp.y.ModNeg();
  } else {
    k.Add((uint64_t)incr);
  }

  // Endomorphisms
  switch (endomorphism) {
  case 1:
    k.ModMulK1order(&lambda);
    //if(startPubKeySpecified) sp.x.ModMulK1(&beta);
    break;
  case 2:
    k.ModMulK1order(&lambda2);
    //if (startPubKeySpecified) sp.x.ModMulK1(&beta2);
    break;
  }

  // Check addresses
  Point p = secp->ComputePublicKey(&k);
  if (startPubKeySpecified) p = secp->AddDirect(p, sp);

  string chkAddr = secp->GetAddress(searchType, mode, p);
  if (chkAddr != addr) {

    //Key may be the opposite one (negative zero or compressed key)
    k.Neg();
    k.Add(&secp->order);
    p = secp->ComputePublicKey(&k);
    if (startPubKeySpecified) {
      //sp.y.ModNeg();
      p = secp->AddDirect(p, sp);
    }
    string chkAddr = secp->GetAddress(searchType, mode, p);
    if (chkAddr != addr) {
      printf("\nWarning, wrong private key generated !\n");
      printf("  Addr :%s\n", addr.c_str());
      printf("  Check:%s\n", chkAddr.c_str());
      printf("  Endo:%d incr:%d comp:%d\n", endomorphism, incr, mode);
      return false;
    }

  }

  output(addr, secp->GetPrivAddress(mode ,k), k.GetBase16());

  return true;

}



void reconstructAdd(Secp256K1 *secp, string fileName, string outputFile, string privAddr) {

  bool compressed;
  int addrType;
  Int lambda;
  Int lambda2;
  lambda.SetBase16("5363ad4cc05c30e0a5261c028812645a122e22ea20816678df02967c1b23bd72");
  lambda2.SetBase16("ac9c52b33fa3cf1f5ad9e3fd77ed9ba4a880b9fc8ec739c2e0cfc810b51283ce");

  Int privKey = secp->DecodePrivateKey((char *)privAddr.c_str(),&compressed);
  if(privKey.IsNegative())
    exit(-1);

  vector<string> lines;
  parseFile(fileName,lines);

  for (int i = 0; i < (int)lines.size(); i+=2) {

    string addr;
    string partialPrivAddr;

    if (lines[i].substr(0, 10) == "Pub Addr: ") {

      addr = lines[i].substr(10);

      switch (addr.data()[0]) {
      case '1':
        addrType = P2PKH; break;
      case '3':
        addrType = P2SH; break;
      case 'b':
      case 'B':
        addrType = BECH32; break;
      default:
        printf("Invalid partialkey info file at line %d\n", i);
        printf("%s Address format not supported\n", addr.c_str());
        continue;
      }

    } else {
      printf("Invalid partialkey info file at line %d (\"Pub Addr: \" expected)\n",i);
      exit(-1);
    }

    if (lines[i+1].substr(0, 13) == "PartialPriv: ") {
      partialPrivAddr = lines[i+1].substr(13);
    } else {
      printf("Invalid partialkey info file at line %d (\"PartialPriv: \" expected)\n", i);
      exit(-1);
    }

    bool partialMode;
    Int partialPrivKey = secp->DecodePrivateKey((char *)partialPrivAddr.c_str(), &partialMode);
    if (privKey.IsNegative()) {
      printf("Invalid partialkey info file at line %d\n", i);
      exit(-1);
    }

    if (partialMode != compressed) {

      printf("Warning, Invalid partialkey at line %d (Wrong compression mode, ignoring key)\n", i);
      continue;

    } else {

      // Reconstruct the address
      Int fullPriv;
      Point p;
      Int e;
      string cAddr;
      bool found = false;

	  Int save_partialPrivKey = partialPrivKey;

      // No sym, no endo
      e.Set(&privKey);
      CHECK_ADDR();

      // No sym, endo 1
      e.Set(&privKey);
      //e.ModMulK1order(&lambda);
	  partialPrivKey.Set(&save_partialPrivKey);
	  partialPrivKey.ModMulK1order(&lambda);
      CHECK_ADDR();

      // No sym, endo 2
      e.Set(&privKey);
      //e.ModMulK1order(&lambda2);
	  partialPrivKey.Set(&save_partialPrivKey);
	  partialPrivKey.ModMulK1order(&lambda2);
      CHECK_ADDR();

      // sym, no endo
      e.Set(&privKey);
      //e.Neg();
      //e.Add(&secp->order);
	  partialPrivKey.Set(&save_partialPrivKey);
	  partialPrivKey.Neg();
	  partialPrivKey.Add(&secp->order);
      CHECK_ADDR();

      // sym, endo 1
      e.Set(&privKey);
      //e.ModMulK1order(&lambda);
      //e.Neg();
      //e.Add(&secp->order);
	  partialPrivKey.Set(&save_partialPrivKey);
	  partialPrivKey.ModMulK1order(&lambda);
	  partialPrivKey.Neg();
	  partialPrivKey.Add(&secp->order);
      CHECK_ADDR();

      // sym, endo 2
      e.Set(&privKey);
      //e.ModMulK1order(&lambda2);
      //e.Neg();
      //e.Add(&secp->order);
	  partialPrivKey.Set(&save_partialPrivKey);
	  partialPrivKey.ModMulK1order(&lambda2);
	  partialPrivKey.Neg();
	  partialPrivKey.Add(&secp->order);
      CHECK_ADDR();

      if (!found) {
        printf("Unable to reconstruct final key from partialkey line %d\n Addr: %s\n PartKey: %s\n", 
          i, addr.c_str(),partialPrivAddr.c_str());
      }

    }

  }

}

[Jean_Luc]

Hello,

I really don't have much free time at the moment to work on this program.
But by using AddDirect you loose all benefits of goup/sym/endo because AddDirect requires a modular inversion which costs hundreds of modular multiplications.  goup/sym/endo optimization is done to avoid slow modular inversions.

[Telariust]

..new 5 ecc algorithms uncompatible with split-key project vanitypool.appspot.com

To make it compatible with the pool, you need to add a splitkey after applying symY/endomorph right before hash160.
It’s not very difficult there, but the performance will suffer, because the operations of adding points are added.
..
I have fixed a few functions for cpu -nosse only, a rough prototype demonstrating that this is possible.
Code is sloow, and problem not in sse. I think secp->AddDirect() is really tardy. I hope you find a quick solution.

..AddDirect requires a modular inversion which costs hundreds of modular multiplications.  goup/sym/endo optimization is done to avoid slow modular inversions..

Yes, I figured it out, it’s impossible to fix it by saving 6 algo, so..

.. reduce it to only one is not obvious.

This is exactly what was required to be done!

I just commented out all the symY/endo; also excluded the use of the algo for compressed keys with negative zero.
You can to add a separate release how did you do it for cuda8 and sm30.
(by the way, why does release sm30 load sm60 cores, is there no error here?)

You need? You do!   (sry my obsession)

[VanitySearch v1.15 origin]

Code:

>VanitySearch-1.15 -nosse -stop -t 4 12345678
5.275 MK/s (GPU 0.000 MK/s) (2^25.92) [P 0.01%][50.00% in 1.4d][0]

>VanitySearch-1.15 -stop -t 4 12345678
11.221 MK/s (GPU 0.000 MK/s) (2^28.44) [P 0.04%][50.00% in 15:14:11][0]

>VanitySearch-1.15 -gpu -stop -t 0 12345678
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)
375.384 MK/s (GPU 375.384 MK/s) (2^32.96) [P 0.94%][50.00% in 00:26:58][0]

[VanitySearch v1.15.1, fix pool.appspot (without symY/endomorphism)]

Code:

C:\Users\User\source\repos\VanitySearch-1.15_appspot\x64\Release>VanitySearch -t 4 -nosse -o __keyinfo.txt -sp 03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd  12345
VanitySearch v1.15.1, fix pool.appspot (without symY/endomorphism)
Difficulty: 4553521
Search: 12345 [Compressed, with public key]
Start Thu Aug  8 12:11:09 2019
Base Key: 6B10396F80C062F2474865C76739A1D1C815F9B9EECFA46B328F90118FD0149E
Number of CPU thread: 4
4.464 MK/s (GPU 0.000 MK/s) (2^28.80) [P 100.00%][99.00% in 00:00:00][101]

C:\Users\User\source\repos\VanitySearch-1.15_appspot\x64\Release>VanitySearch -t 4 -o __keyinfo.txt -sp 03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd  12345
VanitySearch v1.15.1, fix pool.appspot (without symY/endomorphism)
Difficulty: 4553521
Search: 12345 [Compressed, with public key]
Start Thu Aug  8 12:13:13 2019
Base Key: D56EE34383C48B0D4194E834A7955021879BF3AB5444019168768D58BE4E3895
Number of CPU thread: 4
8.212 MK/s (GPU 0.000 MK/s) (2^28.63) [P 100.00%][99.00% in 00:00:00][105]

C:\Users\User\source\repos\VanitySearch-1.15_appspot\x64\Release>VanitySearch -t 4 -o __keyinfo.txt -sp 04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235  12345
VanitySearch v1.15.1, fix pool.appspot (without symY/endomorphism)
Difficulty: 4553521
Search: 12345 [Uncompressed, with public key]
Start Thu Aug  8 12:14:52 2019
Base Key: 3B08999D16D9E5AF4EE27B7F5D8748B63D62446FB54B2BD1B7A28E46FCF30570
Number of CPU thread: 4
5.963 MK/s (GPU 0.000 MK/s) (2^28.82) [P 100.00%][99.00% in 00:00:00][107]

C:\Users\User\source\repos\VanitySearch-1.15_appspot\x64\Release>VanitySearch -t 0 -gpu -o __keyinfo.txt -sp 03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd  123456
VanitySearch v1.15.1, fix pool.appspot (without symY/endomorphism)
Difficulty: 264104224
Search: 123456 [Compressed, with public key]
Start Thu Aug  8 12:16:56 2019
Base Key: ED70397FC554858B8F3D3A84C5B4A1B50E5B289315F4833BDFEA93806740B572
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)
197.134 MK/s (GPU 197.134 MK/s) (2^34.37) [P 100.00%][99.00% in 00:00:00][100]

C:\Users\User\source\repos\VanitySearch-1.15_appspot\x64\Release>VanitySearch -t 0 -gpu -o __keyinfo.txt -sp 04a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea235 123456
VanitySearch v1.15.1, fix pool.appspot (without symY/endomorphism)
Difficulty: 264104224
Search: 123456 [Uncompressed, with public key]
Start Thu Aug  8 12:19:26 2019
Base Key: 74317CCE4CC9525C7A6F276A82E13C7E325DA6B6DD04F673759D8497B524D6D0
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)
158.337 MK/s (GPU 158.337 MK/s) (2^34.64) [P 100.00%][99.00% in 00:00:00][100]

..with regard to..

Code:

[quote author=stivensons link=topic=5112311.msg50017516#msg50017516 date=1551710888]
Will there be settings like Bitcrack in the future?
 -i, --in FILE
Read addresses from FILE, one address per line. If FILE is "-" then stdin is read 

Yes, I'm thinking to add this. It will need an important refurbishment of the code however it goes in the same way as optimizing data transfer. So probably yes.

Code:

--keyspace KEYSPACE
    Specify the range of keys to search, where KEYSPACE is in the format,

	START:END start at key START, end at key END
	START:+COUNT start at key START and end at key START + COUNT
    :END start at key 1 and end at key END
	:+COUNT start at key 1 and end at key 1 + COUNT

No (if I understand well the purpose of this option).
VanitySearch is a prefix finder in order to generate usable addresses, you can specifie a seed to generate a base key ,it is even recommended. That's all. The seed is then passed into a pbkdf2_hmac_sha512 in order to protect against seed search attack. If you don't specifie the seed, the basekey is generated using timestamps (in us) plus the date and also passed into the pbkdf2_hmac_sha512.
The result of the pbkdf2_hmac_sha512 is then passed into a SHA256 wich is use as the base key.

[VanitySearch ver1.15.2, add BitCrack mode, startPrivKey from seed arg]

RANGE: 0xF00000000 - 0xA00000000 = 0x500000000 (21,474,836,480)

Code:

>powershell Get-Date && VanitySearch-1.15_bitcrack -stop -t 0 -gpu -r 10000 -s 0000000000000000000000000000000000000000000000000000000A00000000 1CABDYTie48wXV93XJ4Bdk7MFSTyshTXxg && powershell Get-Date

8 Aug 2019 y. 22:54:43

VanitySearch v1.15.2, add BitCrack mode, startPrivKey from seed arg
Difficulty: 1461501637330902918203684832716283019655932542976
Search: 1CABDYTie48wXV93XJ4Bdk7MFSTyshTXxg [Compressed]
Start Thu Aug  8 22:54:44 2019
Starting at PrivKey: 0x0000000000000000000000000000000000000000000000000000000A00000000
Save progress every 10000 Mkeys
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)

[save] 0x0000000000000000000000000000000000000000000000000000000A00000000
197.135 MK/s (GPU 197.135 MK/s) (2^33.26) [P 0.00%][50.00% in 1.6295e+32y][0]
[save] 0x0000000000000000000000000000000000000000000000000000000C540BE400
197.135 MK/s (GPU 197.135 MK/s) (2^34.26) [P 0.00%][50.00% in 1.6295e+32y][0]
[save] 0x0000000000000000000000000000000000000000000000000000000EA817C800
196.087 MK/s (GPU 196.087 MK/s) (2^34.48) [P 0.00%][50.00% in 1.63821e+32y][0]

Pub Addr: 1CABDYTie48wXV93XJ4Bdk7MFSTyshTXxg
Priv (WIF): p2pkh:KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9MxjBfWawjmiQu7
Priv (HEX): 0x0000000000000000000000000000000000000000000000000000000F00000000

8 Aug 2019 y. 22:56:48

RUNTIME: 22:56:48 - 22:54:43 = 00:02:05 (125sec)



[BitCrack v0.30]

Code:

>powershell Get-Date && cuBitCrack-0.30 -c -d 0 -b 32 -t 512 -p 64 --keyspace 0000000000000000000000000000000000000000000000000000000A00000000 1CABDYTie48wXV93XJ4Bdk7MFSTyshTXxg  && powershell Get-Date

8 Aug 2019 y. 23:06:32

[2019-08-08.23:06:33] [Info] Compression: compressed
[2019-08-08.23:06:33] [Info] Starting at: 0000000000000000000000000000000000000000000000000000000A00000000
[2019-08-08.23:06:33] [Info] Ending at:   FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140
[2019-08-08.23:06:33] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2019-08-08.23:06:33] [Info] Initializing GeForce GTX 980
[2019-08-08.23:06:33] [Info] Generating 1,048,576 starting points (40.0MB)
[2019-08-08.23:06:33] [Info] 10.0%
[2019-08-08.23:06:33] [Info] 20.0%
[2019-08-08.23:06:33] [Info] 30.0%
[2019-08-08.23:06:33] [Info] 40.0%
[2019-08-08.23:06:33] [Info] 50.0%
[2019-08-08.23:06:34] [Info] 60.0%
[2019-08-08.23:06:34] [Info] 70.0%
[2019-08-08.23:06:34] [Info] 80.0%
[2019-08-08.23:06:34] [Info] 90.0%
[2019-08-08.23:06:34] [Info] 100.0%
[2019-08-08.23:06:34] [Info] Done
GeForce GTX 980  490 / 8192MB | 1 target 107.17 MKey/s (21,418,213,376 total) [00:03:11][2019-08-08.23:09:48] [Info] Address:     1CABDYTie48wXV93XJ4Bdk7MFSTyshTXxg
                             Private key: 0000000000000000000000000000000000000000000000000000000F00000000
                             Compressed:  yes
                             Public key:
                             0382113A9377D0B8638231D9669811A7022B31F5805B0AE2C4E0C0A6B7C3C934B3

[2019-08-08.23:09:48] [Info] No targets remaining

8 Aug 2019 y. 23:09:48

RUNTIME: 23:09:48 - 23:06:32 = 00:03:16 (196sec)


COMPARE
if runtime right:
196s / 125s = ~1,56
if hashrate right:
195MK/s / 105Mk/s = ~1,85

VanitySearch win!  
(issue created "need symmetry when calculating batch inversion" github.com/brichard19/BitCrack/issues/188, await..)

source and binary attached
i warn, only 1 gpu is supported!
i warn, on modern gpu (gtx1070) will get equal or decrease in speed (engine need some fix without 5algo)!
just to make sure that the numbers are real - the symmetrical inversion of the pack is really faster.
https://github.com/brichard19/BitCrack/files/3514377/VanitySearch-1.15.2_bitcrack_prototype.zip

##########################
updated

Need retest gtx980 for cuBitCrack (bad arg -p 64, -p 1024 more optimal, iam sry)

Code:

>VanitySearch-1.15 -t 0 -gpu ...
GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)
381.087 MK/s (GPU 381.087 MK/s) (2^32.31) [P 0.01%][50.00% in 1.1d][0]

>VanitySearch-1.15.2_bitcrack -t 0 -gpu ...
GPU: GPU #0 GeForce GTX 980 (16x128 cores) Grid(128x128)
199.652 MK/s (GPU 199.652 MK/s) (2^30.89) [P 0.00%][50.00% in 1.60896e+32y][0]

>cuBitCrack-0.30 -c -d 0 -b 16 -t 512 -p 1024 ...
GeForce GTX 980  1240 / 8192MB | 1 target 157.66 MKey/s (1,996,488,704 total)

and now
gtx980 hashrate VSBC/BC = 199/157 = x1.25

[Jean_Luc]

Yes, I figured it out, it’s impossible to fix it by saving 6 algo, so..

Yes, by using AddDirect you can effectively reduce the problem to case 1 but you loose all benefits, it is like generating random number, add it to the starting key and check the address.
IMHO, the best way is as you have done, keep only case 1 and can keep the group optimization.

(by the way, why does release sm30 load sm60 cores, is there no error here?)

Release SM30 is especially here for debugging purpose.

COMPARE
if runtime right:
196s / 125s = ~1,56
if hashrate right:
195MK/s / 105Mk/s = ~1,85

VanitySearch win!   
(issue created "need symmetry when calculating batch inversion" github.com/brichard19/BitCrack/issues/188, await..)

Thanks for the comparison

[Telariust]

Look to:

GPU/GPUEngine.h

Code:

// Number of thread per block
#define NB_TRHEAD_PER_GROUP 128

try increase it to 256 or 512..

Code:

>VanitySearch-1.1.5_th128gr -t 0 -gpu  12345689
GPU: GPU #0 GeForce GTX 1070 (15x128 cores) Grid(120x128)
549.958 MK/s (GPU 549.958 MK/s) (2^33.98) [P 1.88%][50.00% in 00:18:09][0]

>VanitySearch-1.1.5_th256gr -t 0 -gpu  12345689
GPU: GPU #0 GeForce GTX 1070 (15x128 cores) Grid(120x256)
664.534 MK/s (GPU 664.534 MK/s) (2^34.08) [P 2.02%][50.00% in 00:14:59][0]

>VanitySearch-1.1.5_th512gr -t 0 -gpu  12345689
GPU: GPU #0 GeForce GTX 1070 (15x128 cores) Grid(120x512)
710.364 MK/s (GPU 710.364 MK/s) (2^34.35) [P 2.43%][50.00% in 00:13:56][0]

hashrate diff:
664/549 = x1,20
710/549 = x1,29

how about -g argv?
120x512=61440
480x128=64440
but it not equal:

Code:

>VanitySearch-1.1.5_th128gr  -t 0 -gpu  -g 480  12345689
GPU: GPU #0 GeForce GTX 1070 (15x128 cores) Grid(480x128)
566.206 MK/s (GPU 566.206 MK/s) (2^32.40) [P 0.64%][50.00% in 00:17:57][0]

-g is useless for it, recompilation is necessary
https://github.com/JeanLucPons/VanitySearch/files/3568897/VanitySearch-1.1.5_th128gr.orig.zip
https://github.com/JeanLucPons/VanitySearch/files/3568900/VanitySearch-1.1.5_th256gr.zip
https://github.com/JeanLucPons/VanitySearch/files/3568904/VanitySearch-1.1.5_th512gr.zip
recompiled, non-official build from me (while Jean_Luc thinks what to do)

[Angelo1710]

Can we use this tool the same way as we use Bitcrack?

Will command like this work to search through txt file with addresses and trying random private keys on them and then if the key is found save it to another txt file:

Code:

VanitySearch.exe -u -i myaddresslist.txt -o privatekey.txt

Also, does every new session starts at random keyspace?

Tnx

[Smutsen]

Amazing job. I am experimenting with cpu only because I have only AMD gpus but still amazing. I would like to ask you to reconsider the output (-o) format. For example, when I want multiple addresses and I run:
c:\Vanity>VanitySearch.exe -u -o results.txt 1btc

Code:

VanitySearch v1.15
Difficulty: 4553521
Search: 1btc [Uncompressed]
Start Tue Aug 20 21:18:13 2019
Base Key: 391AF8A6A5BC85D20E312522FC3D8E33CF6D0425DB958F41C6778E3DEB4F1639
Number of CPU thread: 4
^C946 MK/s (GPU 0.000 MK/s) (2^24.87) [P 99.88%][99.00% in 00:00:00][5]

the results in my .txt looks like this:

Code:

Pub Addr: 1btcQnW3mtovfvuzHhmhL7BBrTqGgW72y
Priv (WIF): p2pkh:5J6rmbeTg5nSNTnpi4DXNq7ZiduMgsKX4JmEzBSeLweWdtgqTeX
Priv (HEX): 0x25A11558D36F1D8D8A033E68E122F71AE114AD0F8375387727830F598BB

Pub Addr: 1btcWchj3aTBbhcMGwv4LxKtx9mayu9dk
Priv (WIF): p2pkh:5JKitnrGwGfVtSGPYXjtEcRvHLEA4okRC2gY7nBWEpbQjFt49nN
Priv (HEX): 0x42D6C7EEF9B4A910AA1551D5F54EAAE554C9954562EE4A1C62BB26A7C77

Pub Addr: 1btcbcB4keekZp3oz3D1CKmdRpiFWcMcy
Priv (WIF): p2pkh:5Kj8BxUojbKmKRT5Uw691iB2Ji7Nh2ZoPe1yhXQF4TPGhrkKhiz
Priv (HEX): 0xFBABE112C14A5470D05DE995D5AB15C33CF47BE403051628A90533E3225

Pub Addr: 1btc9t2Jqp7XqejUE73K2pJLTLr76AAo3
Priv (WIF): p2pkh:5K32VbXoxodbpgST9ta4jz81bLkJo4G7y4x61ewLkETRx6tjYcq
Priv (HEX): 0xA09F9F3E3DC38B0BDA1475E124104EB52B10D00876F172D81AEC0D4F100

Pub Addr: 1btca7bYTBxK4AmMsDYyZ8gdCArgHp9Dd
Priv (WIF): p2pkh:5JKeqD95y5Sa4URnQCXhisKmDQckRxx79eaYvo2REbcKdtPHpA8
Priv (HEX): 0x42AE12EE5C55FF6C93B27C476B9A24B848C1C1F6F507F3273A70AAB68FA

If every solution was in 1 line with a "," or "space" to separate <pub. address> , <WIF> , <HEX> (like the bulk addresses on bitaddress.org) it would be more convenient for every user to move it on an .xls or .ods and pick a column to input on electrum wallet  for example(addresses for watch only or WIF).

Thank you
M.

[WhyFhy]

does it support only "add" algorithm for final private key reconstruction ?
Vanitypool supports only uncompressed addresses or both ?

see
gobittest.appspot.com/VanityAll
used add/mul with comp/uncomp = 4 total
(add + uncomp, add + comp, mul + comp, mul + uncomp)
"Solved work" confirms this in the "Solution type"
(most add + uncomp entries because this is vanitygen default)

mul we do not need. I guess this was a trick to get 2x keys for the price of 1M
(like symY/symXBatch/endomorph proposed by arulbero)

we need the splitKey and the addition candidateKey+splitKey not to change

your program gives the result and does not tell which of the 6algos now
when I tried to write the analyzer in python, I failed twice.
At first, I intuitively applied sym/endomorph to the result of the addition of the candidateKey and splitKey, but 5/6 addresses were not recognized.
Well, Of course, I thought, True choice if applied sym/endomorph to the candidateKey before adding with splitKey, but it all happened again.
There is a third option - you apply sym/endomorph to splitKey!
After which the analyzer determined all cases correctly.
I am surprised by this choice, because it makes your calculation incompatible with 5/6 with the pool.
I guess this is due to the late addition of the splitKey to your self-contained code with minimal edits.
In my opinion, you need to apply sym/endomorph to the candidate and not apply to splitKey or the result of addition
imho, after fix u program should also work fine.
(maybe it have some math depend; maybe, I am mistaken and do not take into account some subtlety or dependence)

your absolutely right , I got on 2x Tesla's for a few days, -sp (split key from vanitypool) doesn't work out or add up , I solved 1orgynych  all outputs ,com,uncom add multiply , nothing worked ....
 I went from 5 billion keys to 2.7 with -sp applied , and the solution not accepted . So I tried others from bittadd  , they didn't work either.     

My question is how did you get 1? (5/6) I got 0

@op you gone this far, but the number 1 use for profit on your application  is null please fix this so I can chew down vanitypool.appspot.com

Use vanitypool.appspot.com  and bitaddress.org for reference and testing .

If we get this worked out I'll tip you after I submit work/get paid.
I'll be coming at this from a v100 x4 deep learning rig after it's built
Just courious will this be based on -gpu or -t ? I honestly have no clue as this will be my first link build. 
 The DL rig should bench better