 Show Posts
|
|
Pages: [1] 2 »
|
Don't worry. It is using a RNG. NotATether did not fully understand the sourcecode and jumped to quick conclusions. void CudaKeySearchDevice::generateStartingPoints()
{
...
if(!_randomMode) {
exponents.push_back(privKey);
}
for(uint64_t i = !_randomMode ? 1 : 0; i < totalPoints; i++) {
if(_randomMode) {
privKey = secp256k1::getRandomRange(_startExponent, _end);
} else {
privKey = privKey.add(_stride);
}
...
}
...
}
Thanks |
|
|
|
pika's random mode (which is not in brichard19's bitcrack) is not using a random number generator, it turns out that it uses an iteration count and multiplies it with all the other normal stuff, which is then ADDED to some exponent to obtaining private key samples: // https://github.com/ZenulAbidin/BitCrack-3000/blob/master/CudaKeySearchDevice/CudaKeySearchDevice.cpp line 112
// Generate key pairs for k, k+1, k+2 ... k + <total points in parallel - 1>
secp256k1::uint256 privKey = _startExponent;
if(!_randomMode) {
exponents.push_back(privKey);
}
// ...
// Line 272
if(!_randomMode) {
offset = (secp256k1::uint256((uint64_t)_blocks * _threads * _pointsPerThread * _iterations) + privateKeyOffset) * _stride;
privateKey = secp256k1::addModN(_startExponent, offset);
} else {
offset = secp256k1::uint256(_iterations) * _stride;
privateKey = exponents[privateKeyOffset];
privateKey = secp256k1::addModN(privateKey, offset);
} Can you please explain a bit more how's pika's random mode is working? I though it was using RNG. Can you explain how it gets starting points compared to original bitcrack? Tnx |
|
|
|
|
Tnx! I understand it all now after your in-depth explanation.
|
|
|
|
Btw any idea why program is not working when you try to search for both compressed and uncompressed addresses? Getting error when I try and program stops.
Can you show what commands you are using when receiving this error? Your batch file command or cmd line? Tnx, now I understand. Had no idea your -r feature does that, will use it from now on, that is exactly what I wanted. The Spread version does not do this, it is the Random version that does that. I was using -b command. Ok will try VBCRandom verson later today and let you know. Can you explain more how exactly it creates random points and how many of them does it creates. If my gpu runs lets say at 100mk/s, and I use -r 100, will it then run at 100mk/s and evey single key would be random from those 100m keys? I want it to run at 100mk/s for example and that every key is created randomly through whole keyspace I defined with --keyspace. Lets say I want it to search through --keyspace 1000000000000:FFFFFFFFFFFFF and that it runs through that whole keyspace completely randomly, every single point in that keyspace is generated randomly. Sorry idk how to explain this better. |
|
|
|
|
Btw any idea why program is not working when you try to search for both compressed and uncompressed addresses? Getting error when I try and program stops.
|
|
|
|
I can donate a few dollars in BTC for the random implementation, but sadly I don't have much.
I may have what you already want. I just need to make sure it is what it is. Please reexplain what you are wanting to do. Is it just to create random points over and over inside a defined keyspace? If it's something I have or can do, no need for donation, I do it to tinker, to actually get something to work. Tested program, it's nice. About 2x faster then pika's random version of bitcrack. I would love to have -r random feature here also. If possible that every point that is created is random in defined keyspace, not just starting points that are random like in bitcrack. So you define your keyspace and it goes randomly through whole keyspace it on each point, not just creating starting points and going in +1 increments. You say "...define a keyspace and it goes randomly through whole keyspace "it" (not sure what you meant by it) on each point, not just creating starting points and going in +1 increments." I do not understand how this is random. It sounds like you want it to go check each point in the keyspace or do random jumps through the keyspace. I get confused when you say through the whole keyspace. What I have does the following: top range/keyspace/beginning range you want to start with 800000 so that is a 24 bit top range You define if you want random keys generated in all of 24 bit range by selecting subrange of 23; now it will generate random points from 8000000 through FFFFFF if you wanted to search subrange of 16 bit you select subrange of 16; now it will generate random points from 8000000 through 80FFFF You control how often it generates random points using the -r (rekey) feature. But this program is designed to generate and regenerate random points in a given keyspace as often as you like. It will generate your GPU grid size random points and go sequentially from each random point. Once it rekeys, it generates new random points and goes sequentially. Let's say your GPU gets 100 MKey/s; you could put -r 100 and the program would generate new random points every 1 second. The difference is; bitcrack generates random starting points and goes sequentially until keyspace has been searched; the program eventually ends. My program just keeps generating random points and it will never end, until you close the program down. It will never start with random points and walk them sequentially until whole keyspace is searched. Tnx, now I understand. Had no idea your -r feature does that, will use it from now on, that is exactly what I wanted. |
|
|
|
I can donate a few dollars in BTC for the random implementation, but sadly I don't have much.
I may have what you already want. I just need to make sure it is what it is. Please reexplain what you are wanting to do. Is it just to create random points over and over inside a defined keyspace? If it's something I have or can do, no need for donation, I do it to tinker, to actually get something to work. Tested program, it's nice. About 2x faster then pika's random version of bitcrack. I would love to have -r random feature here also. If possible that every point that is created is random in defined keyspace, not just starting points that are random like in bitcrack. So you define your keyspace and it goes randomly through whole keyspace it on each point, not just creating starting points and going in +1 increments. |
|
|
|
|
Well it appears that 296 keys for each address are uniformly spread by ONE key in every 160 bit block up to FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140. But of course we can't prove that.
|
|
|
|
|
If we assume that there are ~296 private keys for EACH bitcoin address (2256-160) and we assume that in cryptography it is considered good property of every hash function if it evenly distributes the values in its co-domain (co-domain of the SHA256 function is the domain of the RIPEMD160).
Does that means that HALF of the ~296 private keys is in first 2159 and other HALF is in 2160 - 2256 space?
|
|
|
|
|
If we use -r flag for re-key and we set it to let's say 1M, does that mean program will use random base key every 1M keys? Would that work with higher speeds? When I try to use -r and I set it up to 1M then I get max speed of 35MK/s (uncompressed). Probably that is maximum that it can calculate when you use very low re-key number for base key.
|
|
|
|
..Ty for your explanation, I can't pm u back because of messaging limits. 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.
True, according to my knowledge after 1 year of research. In fact, you want a gpu BrainFlayer. Everyone wants it) Ryan refuses to write it because he is a WhiteHat. If successful, it will be slower than sequentially calculating points. ########################## heuristic calculate the hashrate for BrainFlayer cuda/opencl BrainFlayer cpu sse 0,1 Mk/s - 1core i7-6820 8core - 4core real, 4core hyper-threading, so x6 instead x8 0,6 Mk/s - 8core i7-6820 VanityGen x64 opencl 60.7 Mk/s - gtx980 0,52 Mk/s - 8core i7-6820 60.7/0,52 = x116,7 (vg opencl gpu/cpu) VanityGen x64 cpu sse 1,38 Mk/s - 8core i7-6820 1,38/0,52 = x2,6 (vg sse/opencl) now if imagine BrainFlayer opencl 0,6x(1/2,6) = 0,23 Mk/s - 8core i7-6820 0,23x116,7 = 26,8 Mk/s - gtx980 if clBitCrack opencl 67.7 Mk/s - gtx980 cuBitCrack cuda 153.5 Mk/s - gtx980 241.3 Mk/s - gtx1070 153.5/67.7 = x2,26 (bc cuda/opencl) then BrainFlayer cuda 26,8x2,26 = 60,5 Mk/s - gtx980 60,5x(241.3/153.5) = 94,9 Mk/s - gtx1070 Thanks, nice info. What about pollard-rho versions of this people talk in other threads, but there is no publicly available tool to try it (to my knowledge)? |
|
|
|
..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..
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 4 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. see 1post - v0.0.6... the author does not come here for more than a year Ty for your explanation, I can't pm u back because of messaging limits. 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. |
|
|
|
|
Can some1 fork latest version of bitcrack so it does -r 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. Kinda like generating random hex key on each try within selected keyspace.
|
|
|
|
|
Anyone can fork the latest version of Bitcrack to do random searches on each point?
|
|
|
|
|
How do you change keyspace in vanitysearch? Let's say I want to run in 160bit+ space.
Tnx
|
|
|
|
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: VanitySearch.exe -u -i myaddresslist.txt -o privatekey.txt Also, does every new session starts at random keyspace? Tnx |
|
|
|
Tnx man, that did the trick. It works |
|
|
|
Well I tried with -o file command and without and no file was saved when the key was found, then I tried the same in the latest version and it worked perfectly. When I tried on Windows to run the original bitcrack, it saved output file in windows/system32. Try naming the file non-standard way, run bc, and then searching for the file in system. Tried and no textfile was found in system32. I really wish someone can add -r to the latest version. Got it to work but it seems it just randomly searching in 252-256 space, so it is not 'really' random. |
|
|
|
Well I tried with -o file command and without and no file was saved when the key was found, then I tried the same in the latest version and it worked perfectly. When I tried on Windows to run the original bitcrack, it saved output file in windows/system32. Try naming the file non-standard way, run bc, and then searching for the file in system. Tried and no textfile was found in system32. I really wish someone can add -r to the latest version. |
|
|
|
This version does not save key text file at all, just tested it, it's broken.
Maybe bitcrack writing output file to the wrong directory where you're looking? Well I tried with -o file command and without and no file was saved when the key was found, then I tried the same in the latest version and it worked perfectly. |
|
|
|
|
