JeanLucPons / VanitySearch

Bitcoin Address Prefix Finder
GNU General Public License v3.0
423 stars 206 forks source link

speed-up x1.25, NB_TRHEAD_PER_GROUP=128, increase it to 256 or 512 #39

Open Telariust opened 5 years ago

Telariust commented 5 years ago

GPU/GPUEngine.h

// Number of thread per block
#define NB_TRHEAD_PER_GROUP 128

try increase it to 256 or 512..

>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:

>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

VanitySearch-1.1.5_th128gr(orig).zip VanitySearch-1.1.5_th256gr.zip VanitySearch-1.1.5_th512gr.zip recompiled, non-official build from me (while Jean_Luc thinks what to do)

Axeleron commented 5 years ago

Win 10 x64, Nvidia 1080 Ti:

Orig:

>VanitySearch.exe -gpu -t 0 1Vanity
VanitySearch v1.15
Difficulty: 888446610539
Search: 1Vanity [Compressed]
Start Tue Sep  3 14:22:33 2019
Base Key: 7428956C08A013025A8050C25F1ACD542F84118E11716E82D5694D63AD14BE09
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 1080 Ti (28x128 cores) Grid(224x128)
780.749 MK/s (GPU 780.749 MK/s) (2^35.40) [P 4.99%][50.00% in 00:12:10][0]

VanitySearch-1.1.5_th512gr:

>VanitySearch-1.1.5_th512gr.exe -gpu -t 0 1Vanity
VanitySearch v1.15
Difficulty: 888446610539
Search: 1Vanity [Compressed]
Start Tue Sep  3 14:24:38 2019
Base Key: 445790CC1232F5C35D3EEAAF316DA3F6DB9E9A2C5F6580F04DED541480F595C1
Number of CPU thread: 0
GPU: GPU #0 GeForce GTX 1080 Ti (28x128 cores) Grid(224x512)
967.778 MK/s (GPU 967.778 MK/s) (2^35.44) [P 5.10%][50.00% in 00:09:48][0]
Axeleron commented 5 years ago

but with -i manyadr.csv on 6xNvidia 1060 3gb th256gr/th512gr crushed

ghost commented 5 years ago

Can some1 add keyspace and a random option to this? So we can choose in which keyspace to search and maybe also to be able to do random searches around the selected keyspace for each jump point.

Axeleron commented 5 years ago

Can some1 add keyspace and a random option to this? So we can choose in which keyspace to search and maybe also to be able to do random searches around the selected keyspace for each jump point.

-r rekey: Rekey interval in MegaKey, default is disabled

ghost commented 5 years ago

Can some1 add keyspace and a random option to this? So we can choose in which keyspace to search and maybe also to be able to do random searches around the selected keyspace for each jump point.

-r rekey: Rekey interval in MegaKey, default is disabled

That just randomize base key but it still starts from the beginning of the keyspace, in my case around 27bit space. I want to be able to choose keyspace myself, like from 255-256 bit range etc (like you can do in bitcrack,), so like this --keyspace 889388d14c89665ca5fdb806900b52b6a5d74be536fdb5c0dbf06add612f057d:a100db364a65d4bd32417a1850c90c91bc53e023db5e4709dba9f4ccb077e13f and maybe also add real -r option to jump randomly around that. Would love if some1 can do it.

Axeleron commented 5 years ago

Can some1 add keyspace and a random option to this? So we can choose in which keyspace to search and maybe also to be able to do random searches around the selected keyspace for each jump point.

-r rekey: Rekey interval in MegaKey, default is disabled

That just randomize base key but it still starts from the beginning of the keyspace, in my case around 27bit space. I want to be able to choose keyspace myself, like from 255-256 bit range etc (like you can do in bitcrack), and maybe also add real -r option to jump all around whole keyspace. Would love if some1 can do it.

Something like that: https://bitcointalk.org/index.php?topic=5112311.msg52105858#msg52105858 (https://github.com/brichard19/BitCrack/files/3514377/VanitySearch-1.15.2_bitcrack_prototype.zip)

ghost commented 5 years ago

Can some1 add keyspace and a random option to this? So we can choose in which keyspace to search and maybe also to be able to do random searches around the selected keyspace for each jump point.

-r rekey: Rekey interval in MegaKey, default is disabled

That just randomize base key but it still starts from the beginning of the keyspace, in my case around 27bit space. I want to be able to choose keyspace myself, like from 255-256 bit range etc (like you can do in bitcrack), and maybe also add real -r option to jump all around whole keyspace. Would love if some1 can do it.

Something like that: https://bitcointalk.org/index.php?topic=5112311.msg52105858#msg52105858 (https://github.com/brichard19/BitCrack/files/3514377/VanitySearch-1.15.2_bitcrack_prototype.zip)

Ah how did I missed that lol. Will test it now, ty mate

ghost commented 5 years ago

Can some1 add keyspace and a random option to this? So we can choose in which keyspace to search and maybe also to be able to do random searches around the selected keyspace for each jump point.

-r rekey: Rekey interval in MegaKey, default is disabled

That just randomize base key but it still starts from the beginning of the keyspace, in my case around 27bit space. I want to be able to choose keyspace myself, like from 255-256 bit range etc (like you can do in bitcrack), and maybe also add real -r option to jump all around whole keyspace. Would love if some1 can do it.

Something like that: https://bitcointalk.org/index.php?topic=5112311.msg52105858#msg52105858 (https://github.com/brichard19/BitCrack/files/3514377/VanitySearch-1.15.2_bitcrack_prototype.zip)

Ah how did I missed that lol. Will test it now, ty mate

Hm I can only set starting point using the -s flag but when you try to add ending point it doesn't work: -s 11111:FFFFF. Any other way we can add the ending point? Also this version of vanity search (VanitySearch-1.15.2_bitcrack_prototype) is 40% slower for me then official JeanLuc version.

Axeleron commented 5 years ago

Hm I can only set starting point using the -s flag but when you try to add ending point it doesn't work: -s 11111:FFFFF. Any other way we can add the ending point? Also this version of vanity search (VanitySearch-1.15.2_bitcrack_prototype) is 40% slower for me then official JeanLuc version.

Yeap, only starting point. Try to "connect" with his author

ghost commented 5 years ago

Hm I can only set starting point using the -s flag but when you try to add ending point it doesn't work: -s 11111:FFFFF. Any other way we can add the ending point? Also this version of vanity search (VanitySearch-1.15.2_bitcrack_prototype) is 40% slower for me then official JeanLuc version.

Yeap, only starting point. Try to "connect" with his author

Will do tnx. But yea it doesn't have endpoint + it's slower then bitcrack for me.

drk77 commented 5 years ago

@Telariust if it is not hard for you. could you make random mode better? at your discretion maybe you can implement the pollard script the one in the next branch here? modify the program for brute force + random

drk77 commented 5 years ago

we would all be very grateful to you

ghost commented 5 years ago

If we use -r flag like this: -r 1, does this means it will use random base key every 1M tries? I just tested this and it slower my speed by 20-30%, I guess that is because of calculation time. Can some1 confirm this is working ok? If yes this is pretty good random mode.

Telariust commented 5 years ago

You are discussing issues off topic. But well, I will answer.

question could you make random mode better? short answer

its impossible, because need principial different engine.
its not profitable, because multiplication of points more slower than sequentially addition of points.
multiplication of points is very expensive, more expensive than the slowest addition of points.

extended answer bitcointalk.org/index.php?topic=4453897.msg52372437#msg52372437

i duplicate question ..random on every point across selected keyspace. So every jump/try is random. Not like in pikachunakapika version where it chooses random staring points and then starts doing them in 1 increment at a time..

answer

The Engine of these programs is divided into two types:

1) optimized point addition (for quick calculation of sequential keys)
 sample programs: vanitygen, bitcrack, vanitysearch, break_short;
 methods:
 - calc only X coordinates (for compressed keys);
 - use of functions without protection against side channel attacks (openssl/secp256k1);
main problem - inversion calculation is very expensive, ~20mult per 1 point;
can use batch inversion (Simultaneous algorithm, 1 inversion per 1000 keys) + Affines coordinates + symmetry(only full range) + endomorphism(only full range);

2) optimized point multiplication (for quick calculation of random keys)
 sample programs: brainflayer;
 methods:
 - secp256k1 library with pre-calculated mult table in RAM;
 - Jacobian coordinates;
main problem random mult - inversion need too, but can not use batch inversion because each key is random.

BitCrack is optimized for sequentially calculating points in a limited range using addition.
VanitySearch is optimized for sequentially calculating points in the full range using addition (and 5 multiplication algorithms that work only for the full range).
BrainFlayer (cpu only) is optimized for random calculating points in a full range using multiplication.
You want to get random points in a limited range using multiplication.
These are fundamentally different tasks.

If you delve into the study of random generators, you will find that they have top speed.
Typically, the problem is that the overhead of generating random numbers is greater than the useful calculation itself.

PS:
about multiplication
At start BitCrack, pre-computes the starting points using multiplication.
It is so slow that starting from version 0.15 the author transferred the procedure to gpu.

So basically there is no way to combine really fast random hex generator to work with the calculation process? So all we can do is randomly get starting points and from there work in increments. Right

maybe you can implement the pollard script the one in the next branch here? Pollard just is probablistic nature. Its random default. it's faster squared. But need a publickey instead publickeyhash of bitcrack,

ghost commented 5 years ago

You are discussing issues off topic. But well, I will answer.

question could you make random mode better? short answer

its impossible, because need principial different engine.
its not profitable, because multiplication of points more slower than sequentially addition of points.
multiplication of points is very expensive, more expensive than the slowest addition of points.

extended answer bitcointalk.org/index.php?topic=4453897.msg52372437#msg52372437

i duplicate question ..random on every point across selected keyspace. So every jump/try is random. Not like in pikachunakapika version where it chooses random staring points and then starts doing them in 1 increment at a time..

answer

The Engine of these programs is divided into two types:

1) optimized point addition (for quick calculation of sequential keys)
 sample programs: vanitygen, bitcrack, vanitysearch, break_short;
 methods:
 - calc only X coordinates (for compressed keys);
 - use of functions without protection against side channel attacks (openssl/secp256k1);
main problem - inversion calculation is very expensive, ~20mult per 1 point;
can use batch inversion (Simultaneous algorithm, 1 inversion per 1000 keys) + Affines coordinates + symmetry(only full range) + endomorphism(only full range);

2) optimized point multiplication (for quick calculation of random keys)
 sample programs: brainflayer;
 methods:
 - secp256k1 library with pre-calculated mult table in RAM;
 - Jacobian coordinates;
main problem random mult - inversion need too, but can not use batch inversion because each key is random.

BitCrack is optimized for sequentially calculating points in a limited range using addition.
VanitySearch is optimized for sequentially calculating points in the full range using addition (and 5 multiplication algorithms that work only for the full range).
BrainFlayer (cpu only) is optimized for random calculating points in a full range using multiplication.
You want to get random points in a limited range using multiplication.
These are fundamentally different tasks.

If you delve into the study of random generators, you will find that they have top speed.
Typically, the problem is that the overhead of generating random numbers is greater than the useful calculation itself.

PS:
about multiplication
At start BitCrack, pre-computes the starting points using multiplication.
It is so slow that starting from version 0.15 the author transferred the procedure to gpu.

So basically there is no way to combine really fast random hex generator to work with the calculation process? So all we can do is randomly get starting points and from there work in increments. Right

maybe you can implement the pollard script the one in the next branch here? Pollard just is probablistic nature. Its random default. it's faster squared. But need a publickey instead publickeyhash of bitcrack,

Ty for your answer. I am playing a bit with vanitysearch atm beside bitcrack. Can you look at this please:

D:\VanitySearch-1.15>VanitySearch.exe -u -gpu -r 1 -i addr.txt -o pkey.txt VanitySearch v1.15 Search: 7 addresses (Lookup size 7,[1,1]) [Uncompressed] Start Thu Sep 12 21:33:26 2019 Base Key: Randomly changed every 1 Mkeys Number of CPU thread: 3 GPU: GPU #0 GeForce 840M (3x128 cores) Grid(24x128) 31.722 MK/s (GPU 28.468 MK/s) (2^29.37) [P 0.00%][50.00% in 1.01265e+33y][0]

Does this means that every 1M keys I get new base key randomly generated and then it adds +1M in increments per every base key, so at this speed I get 31 random keys per second + 1M in increments on each of them? Tnx

Telariust commented 5 years ago

Does this means that every 1M keys I get new base key randomly generated and then it adds +1M in increments per every base key, so at this speed I get 31 random keys per second + 1M in increments on each of them? Tnx

I agree with Axeleron that -r is the only and best thing you can do. Yes, with -r every 1M a new random point will be generated, keys will be added to it sequentially until the difference exceeds 1M. and again. I didn’t look at code bitcrack by pikachunakapika, but I’m sure that it works absolutely the same, because it’s better just not possible without changing the engine. But random is better here, because to ensure the security of vanity address search, each stream (each core of cpu, each th of gpu) gets an offset from the base point, so you are looking very randomly I will notice that in my VanitySearch-1.15.2_bitcrack_prototype the search is only sequential, and the key is used only to indicate the size of the pack without random.

ghost commented 5 years ago

Does this means that every 1M keys I get new base key randomly generated and then it adds +1M in increments per every base key, so at this speed I get 31 random keys per second + 1M in increments on each of them? Tnx

I agree with Axeleron that -r is the only and best thing you can do. Yes, with -r every 1M a new random point will be generated, keys will be added to it sequentially until the difference exceeds 1M. and again. I didn’t look at code bitcrack by pikachunakapika, but I’m sure that it works absolutely the same, because it’s better just not possible without changing the engine. But random is better here, because to ensure the security of vanity address search, each stream (each core of cpu, each th of gpu) gets an offset from the base point, so you are looking very randomly I will notice that in my VanitySearch-1.15.2_bitcrack_prototype the search is only sequential, and the key is used only to indicate the size of the pack without random.

Tnx mate very helpful. I really like to play around with random on both vanityseach and pikachunakapika version, it's fun. VanitySearch is better because it does random all the time when you turn it on and for pikachunakapika you have to restart it all the time to get new random points. Any idea how we cound restart pikachunakapika bitcrack version automatically like every 1 minute using some script or something similar? Anyway if you find out about some new tools we can try please let me know :)

OSoup commented 5 years ago

You can use something like this, a bat file: @echo off :loop start cuBitCrackp.exe -i list.txt -r -u -d 0 -b 36 -t 256 -p 2048 -o xlist.txt timeout /t 3600 taskkill /f /im cuBitCrackp.exe timeout /t 10 goto loop

ghost commented 5 years ago

You can use something like this, a bat file: @echo off :loop start cuBitCrackp.exe -i list.txt -r -u -d 0 -b 36 -t 256 -p 2048 -o xlist.txt timeout /t 3600 taskkill /f /im cuBitCrackp.exe timeout /t 10 goto loop

Damn nice, tnx this works amazing. With this loop feature I like pikachunakapika version better because it can generate so much more random keys then vanitysearch in same timeline.

With VanitySearch we are limited by 1M re-key which in my case ends up to 40 base random keys per second which is 144k random keys per h; while with pikachunakapika bitcrack version on loop I can get 40M random keys every 2 minutes.

ghost commented 5 years ago

@su314ka can we use start /B cuBitCrackp.exe for the program to run in background all the time? It seams it is running properly like that.