BitCrack - A tool for brute-forcing private keys

[klfklf]

Hi...

İ need to bitcrack random version

where can i find this random version? i cant find github

please help...

[iamfreshfish]

Hello,
Can anyone explain the relationship between -b -t and -p and GPU work groups? I tried doing some research to try and optimize this but couldnt figure out the relationship and I dont have the coding know how to code a simple benchmarking utility that would test the ranges.

My understanding is that GPUs have compute units and workgroups are distribute across these units...and each workgroup consists of blocks and I think threads.

I assumed that if I learned a little about workgroup sizing as well as knowing the compute units for my gpu (I have an RX 580 so it has 36 CU with 2304 SMs) I could better determine a good configuration.

Thanks

[GoVanza]

Hello,
Can anyone explain the relationship between -b -t and -p and GPU work groups? I tried doing some research to try and optimize this but couldnt figure out the relationship and I dont have the coding know how to code a simple benchmarking utility that would test the ranges.

My understanding is that GPUs have compute units and workgroups are distribute across these units...and each workgroup consists of blocks and I think threads.

I assumed that if I learned a little about workgroup sizing as well as knowing the compute units for my gpu (I have an RX 580 so it has 36 CU with 2304 SMs) I could better determine a good configuration.

Thanks

The best speed for you would be -b 64 -t 256 -p 2048. only the creator knows the intricacies of verification. But BitCrack no longer works fine, it does not show the correct digits for scanning.

[iamfreshfish]

 The best speed for you would be -b 64 -t 256 -p 2048. only the creator knows the intricacies of verification. But BitCrack no longer works fine, it does not show the correct digits for scanning.

Thanks, but I am trying to learn a little bit about how workloads are distributed to GPUs as well as optimizing my gpu...so could you explain how you decided on those values or was it trial and error with a similar gpu?

[GoVanza]

 The best speed for you would be -b 64 -t 256 -p 2048. only the creator knows the intricacies of verification. But BitCrack no longer works fine, it does not show the correct digits for scanning.

Thanks, but I am trying to learn a little bit about how workloads are distributed to GPUs as well as optimizing my gpu...so could you explain how you decided on those values or was it trial and error with a similar gpu?

I did a test of finding 40 keys from the puzzle32. Did many times different parameters. Conclusion is the best speed. My card is similar to yours RX 570 Nitro+ 8GB. The big minus of BitCrack is that it does not show the correct calculations. and conservation does on incorrect calculations. after restart you will start from the saved file. Thus, the key can be skipped.

[COBRAS]

Hi all. I think bast choise for crack btc use random search because too many calculation needed. Without random crack is full shet.

[GoVanza]

Hi all. I think bast choise for crack btc use random search because too many calculation needed. Without random crack is full shet.

I can not compile version files from Pikachypika/ And in this program BitCrack there is no such function random(

[COBRAS]

Hi all. I think bast choise for crack btc use random search because too many calculation needed. Without random crack is full shet.

I can not compile version files from Pikachypika/ And in this program BitCrack there is no such function random(

Dont waste time to no random bitcrack. This is full shet. Fined a programmist who compile for you Pikachypka version and work, no other variants with no random search bitcrack. With random search will be a chance, without random search no chances.

[bigvito19]

Everyone knows that bitcrack only goes by consecutive keys. You can make your own program it you want to go random but it will be much slower vs consecutive keys/incremental.

[PawGo]

Everyone knows that bitcrack only goes by consecutive keys.

Not really. You may specify your own 'distance' between key.
For example:

Code:

--stride F4240

will do 1000000 keys long 'jump' between tries.

[GoVanza]

Everyone knows that bitcrack only goes by consecutive keys.

Not really. You may specify your own 'distance' between key.
For example:

Code:

--stride F4240

will do 1000000 keys long 'jump' between tries.

After reaching the end of the program range, just stop (((

[bigvito19]

Everyone knows that bitcrack only goes by consecutive keys.

Not really. You may specify your own 'distance' between key.
For example:

Code:

--stride F4240

will do 1000000 keys long 'jump' between tries.

That's still consecutive not random

[WanderingPhilospher]

I'm pretty sure I've posted this or something similar, to use Bitcrack in a "random" way.

This particular GPU is on a system  running Windows 10 and Python 3.8.2.

The code:

Code:

import sys, time, random, os
from datetime import datetime
random.seed(datetime.now())
arq1 = open('randomrange.bat', 'w')
arq2 = open('randomrangeschecked.txt', 'a')

for x in range(1):
    low  = 0x800ffffff
    high = 0xfff000000
    randp = str(hex( random.randrange( low, high ) )).lstrip("0x")
    arq1.write("start /min /wait cuBitcrack -d 1 -b 64 -t 128 -p 256 --keyspace " + randp + "0000000:+FFFFFFF -i 64.txt -o YOUFOUNDTHEKEY.txt")
    arq2.write(randp + "0000000" '\n')
    arq2.write(randp + "FFFFFFF" '\n')
arq1.close()

This particular setting randomly checks a random 2^28 range, in a 2^64 range. You can adjust any of the code to meet your particular needs.

Then I have a CALL batch file that calls the python script and then the batch file that was created from the python script and it's an unlimited loop, checking an unlimited amount of random ranges until you stop the program.

The arq2 in this code saves all the ranges in a text file so you can check to see which ranges have been checked.

[BASE16]

While it is true that you can randomly just try private key's / numbers this is most likely the way with the least chance on success.

It was designed to withstand these types of attacks and the chances are extremely slim that you will accidentally land on a key that has some value to it.
This does not mean that it is impossible, i am just trying to say that you could try and swap the random key method with a more targeted approach.

In simple terms this means you analyze a system, and find it's weakest part, and start banging on that part for as long and as hard as you can in the hopes that it will give way.

By all means many private key's were not chosen randomly at all, many key's were calculated by using known algorithms, this leaves specific footprints, and some key types were even quenched further, by ruling out a rather large part of the possible solutions.
The designers assumed that it would be safer, but it actually makes things easier from a hackers perspective, by ruling out a large part of the key's you generate because they do not fit the lock type involved so they can be discarded before producing the heat and burning the way to the target key.

Of course this is not the case with a randomly chosen brute force attack, with or without jumps, like the thing in this thread, which could be anything, no footprint or target reduction involved, it will literally take forever.

When you carefully analyze the blockchain, you can discover clusters or 'vaults' which are very evidently present and they will show you that something is there and that it follows specific mechanisms, not random at all and if you are good in math, you can calculate the parameters of every one of these clusters and their strength so that you can point your computing power in more serious directions then just wasting it by shooting in the dark.

 

[WanderingPhilospher]

While it is true that you can randomly just try private key's / numbers this is most likely the way with the least chance on success.

It was designed to withstand these types of attacks and the chances are extremely slim that you will accidentally land on a key that has some value to it.
This does not mean that it is impossible, i am just trying to say that you could try and swap the random key method with a more targeted approach.

In simple terms this means you analyze a system, and find it's weakest part, and start banging on that part for as long and as hard as you can in the hopes that it will give way.

By all means many private key's were not chosen randomly at all, many key's were calculated by using known algorithms, this leaves specific footprints, and some key types were even quenched further, by ruling out a rather large part of the possible solutions.
The designers assumed that it would be safer, but it actually makes things easier from a hackers perspective, by ruling out a large part of the key's you generate because they do not fit the lock type involved so they can be discarded before producing the heat and burning the way to the target key.

Of course this is not the case with a randomly chosen brute force attack, with or without jumps, like the thing in this thread, which could be anything, no footprint or target reduction involved, it will literally take forever.

When you carefully analyze the blockchain, you can discover clusters or 'vaults' which are very evidently present and they will show you that something is there and that it follows specific mechanisms, not random at all and if you are good in math, you can calculate the parameters of every one of these clusters and their strength so that you can point your computing power in more serious directions then just wasting it by shooting in the dark.

 

show us the way ole wise one

[studyroom1]

Everyone knows that bitcrack only goes by consecutive keys.

Not really. You may specify your own 'distance' between key.
For example:

Code:

--stride F4240

will do 1000000 keys long 'jump' between tries.

That's still consecutive not random

how you are calculating --stride F4240 = 1m
how about for 1 billion or for 50billion? please tell me how to calculate any guide

[PawGo]

Everyone knows that bitcrack only goes by consecutive keys.

Not really. You may specify your own 'distance' between key.
For example:

Code:

--stride F4240

will do 1000000 keys long 'jump' between tries.

That's still consecutive not random

how you are calculating --stride F4240 = 1m
how about for 1 billion or for 50billion? please tell me how to calculate any guide

  http://jfgi.herokuapp.com/

https://www.google.com/search?q=decimal+to+hex+calculator

https://www.rapidtables.com/convert/number/decimal-to-hex.html

1000000000 = 3B9ACA00
50000000000 = BA43B7400

[studyroom1]

Everyone knows that bitcrack only goes by consecutive keys.

Not really. You may specify your own 'distance' between key.
For example:

Code:

--stride F4240

will do 1000000 keys long 'jump' between tries.

That's still consecutive not random

how you are calculating --stride F4240 = 1m
how about for 1 billion or for 50billion? please tell me how to calculate any guide

  http://jfgi.herokuapp.com/

https://www.google.com/search?q=decimal+to+hex+calculator

https://www.rapidtables.com/convert/number/decimal-to-hex.html

1000000000 = 3B9ACA00
50000000000 = BA43B7400

this one is very strange check this out

clBitCrack.exe --stride BA43B7400 -b 52 -t 512 -p 1024 --compression both --keyspace 0100000000000000000000000000000000000000000000000000000000000000:FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140 -i 1.txt -o 01.txt

i loaded these addresses to check this one is working or not and guess what if i load 6 or 8 address its working as i expect but if i load more than 6  addressess it is not working ,

1CTGjE4t65gvTzGRCP2rr1UmwYRHRwR2gB
1Bst22LeSjptwhSbAe4XXArjBpnnKDF42X
1FoWHbebHzAuNzg4sX8R2bxBDBCdFQejTv
1CTkWpdNYsM7u9zw3DTiJhEZFA1YJTzBcU
16MAA9YeMSp7VtnQsBSYXgEGg6f1dFdwR1
1B8XXy9YykVF1qk6qm9N3HZ5Bx55mmjDpW
14B12QMdUbtnpAVv7wkowQtG1B94GP2Sa9
1Ap9DW4YjtuGxxVR9hL3CLjMTM8z1kQZfE
1KDpXzUdjcxkbC7NhTL8T7DiVNh1ERAmEs

some addresses i chose as they are coming in stride range jump and some i chose right after or before  stride jump , so question is if GPU doing stride jump and than calculating million of addresses this should also show address right after stride jump or right before stride jump, but in all cases it is showing only ,exact jump address only nothing before or nothing after . and my guess is GPU is checking first only compress range and than non compress range , strange thing lol. and in my guess Gpu is only searching for one address when you will give stride range jump in command and will find key than this will start search for 2nd address , please clarify

[PawGo]

Of course, what did you expect?
By default stride = 1, which means you check numbers ...,3,4,5,6,7.....
but if you specify stride 5, program checks 5,10,15,20,25... Why you expect to have number 9 or 11 checked?
If your public key is generated from number 20, it will be found, if from 21 - not. It is obvious.

[studyroom1]

Of course, what did you expect?
By default stride = 1, which means you check numbers ...,3,4,5,6,7.....
but if you specify stride 5, program checks 5,10,15,20,25... Why you expect to have number 9 or 11 checked?
If your public key is generated from number 20, it will be found, if from 21 - not. It is obvious.

ok wait do you mean if my gpu is checking 20m keys /sec with 5 jump
so in normal this will be 1,2,3,4,5,6.......20000000
but with 5 Jump this will be 5,10,15,20,25,30........100000000

right?