Open Telariust opened 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]
but with -i manyadr.csv
on 6xNvidia 1060 3gb th256gr/th512gr crushed
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.
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
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.
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)
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
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.
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
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.
@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
we would all be very grateful to you
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.
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,
You are discussing issues off topic. But well, I will answer.
question
could you make random mode better?
short answerits 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
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.
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 :)
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
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.
@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.
GPU/GPUEngine.h
try increase it to 256 or 512..
hashrate diff: 664/549 = x1,20 710/549 = x1,29
how about -g argv? 120x512=61440 480x128=64440 but it not equal:
-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)