Topic: VanitySearch (Yet another address prefix finder) - page 44. (Read 33086 times)

Does anyone have any basic steps on getting this to run on a debian based Linux OS?

Linux
Intall CUDA SDK.
Depenging on the CUDA SDK version and on your Linux distribution you may need to install an older g++ (just for the CUDA SDK).
Edit the makefile and set up the good CUDA SDK path and appropriate compiler for nvcc.

CUDA       = /usr/local/cuda-8.0
CXXCUDA    = /usr/bin/g++-4.8
You can enter a list of architectrure (refer to nvcc documentation) if you have several GPU with different architecture. Compute capability 2.0 (Fermi) is deprecated for recent CUDA SDK. VanitySearch need to be compiled and linked with a recent gcc (>=7). The current release has been compiled with gcc 7.3.0.
Go to the VanitySearch directory. ccap is the desired compute capability.

$ g++ -v
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)
$ make all (for build without CUDA support)
or
$ make gpu=1 ccap=20 all

No just unlucky. keep trying!


edit just noticed the keypsec count somethings off

This is an error right? lol

Hi,

Here is the results with GeForce RTX 2060 SUPER!

why Uncompressed speed is lower then Compressed with vanitysearch?
oclvanitygen can make both compressions in same speed.
any tricks/help to improve Uncompressed speeds as compressed?
because i need Uncompressed only.

oclvanitygen:
[compressed]
[164.75 Mkey/s][total 1336934400][Prob 0.0%][50% in 2.5d]
[Uncompressed]
[151.58 Mkey/s][total 1880621056][Prob 0.0%][50% in 2.7d]

vanitysearch:
[Compressed]
GPU: GPU #0 GeForce RTX 2060 SUPER (34x64 cores) Grid(272x256)
[1361.71 Mkey/s][GPU 1361.71 Mkey/s][Total 24.39 Bkeys][Prob 2.7%][50% in 00:07:14][Found 0]
[Uncompressed]
GPU: GPU #0 GeForce RTX 2060 SUPER (34x64 cores) Grid(272x256)
[827.71 Mkey/s][GPU 827.71 Mkey/s][Total 20.96 Bkeys][Prob 2.3%][50% in 00:11:58][Found 0]
[Compressed or Uncompressed]
GPU: GPU #0 GeForce RTX 2060 SUPER (34x64 cores) Grid(272x256)
[519.94 Mkey/s][GPU 519.94 Mkey/s][Total 13.26 Bkeys][Prob 1.5%][50% in 00:19:18][Found 0]

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)

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

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

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..)