BitCrack - A tool for brute-forcing private keys

[elisacat]

I might be able to put Bitcrack on your Vast.ai servers, send me a PM.

I've sent you a DM. thanks

[NotATether]

The developer of this tool is offline but for anyone else who is having problems compiling this on newer NVIDIA gpus, the issue is in the makefile where the CUDA compute version is defined. It's hardcoded at sm_30. Removing those references should make the compilation succeed.

Code:

COMPUTE_CAP=30
NVCC=nvcc
NVCCFLAGS=-std=c++11 -gencode=arch=compute_${COMPUTE_CAP},code=\"sm_${COMPUTE_CAP}\" -Xptxas="-v" -Xcompiler "${CXXFLAGS}"

All references to COMPUTE_CAP have to be deleted.

EDIT: It looks like the OpenCL version is pegged to 1.1? Why? There are newer revisions available to use.

The BitCrack repo from brichard19 without any changes will only work on these GPUs:



That's why it's important to remove COMPUTE_CAP, because it doesn't support any newer GPUs (it wasn't very smart to add it in the first place).

[elisacat]

im making some modifications to bitcrack so that it can calculate random keys instead of incremental (i know the developer said he didn't see the point of random but it doesn't make sense if nearly everyone is using bitcrack the same way and generating the same results, everyone would just be following each others footsteps - randomization i think solves some of that)

It would have two elements
1) Randomization based on number of characters e.g. 30 characters should be random (so last 30 digits are randomized)
0000000000000000000000000000000000 HHSJSHDJSHHDD773737HSHSSHHSSJD
0000000000000000000000000000000000 73737373SGHDDGSHSHGDHSGSHDGSHD
0000000000000000000000000000000000 HSHSSJJDD74377448788SSHSHSSHHD

2) Randomization for the remaining variables. E.g. user inputs FFFFFFFFEDEFEDEDEFED (bitcrack will generate random results for the remaining digits in the 64 key sequence)
FFFFFFFFEDEFEDEDEFED JNMSXNMNBXBBDEHGHJMSDMS738738733837737337333
FFFFFFFFEDEFEDEDEFED JJKSJSJDJKDKJJK73873378738KJSJSKJSKDKDKKDDKD
FFFFFFFFEDEFEDEDEFED DHK477478484748747878487JKKJSJSSHJSHHDDKJDKD
FFFFFFFFEDEFEDEDEFED GSGSG74747484848383739339HDHDHDHFJFFHFFJJFHF

Sorting this code in the backend is fine, only problem is i dont understand how the frontend works i.e. examples from the github:
--keyspace 80000000:ffffffff
or
--keyspace 766519C977831678F0000000000

these values above are less than 64 characters so how are they used in the examples in the github? does it mean that by entering above the software already knows it has to add zeros to the beginning to reach 64 characters?

[NotATether]

Sorting this code in the backend is fine, only problem is i dont understand how the frontend works i.e. examples from the github:
--keyspace 80000000:ffffffff
or
--keyspace 766519C977831678F0000000000

these values above are less than 64 characters so how are they used in the examples in the github? does it mean that by entering above the software already knows it has to add zeros to the beginning to reach 64 characters?

Any value passed to the --keyspace argument is split to remove any colons, and is then converted into a homemade secp256k1::uint256 data type. This among other things pads the key with zeroes if it's less than 64 characters (which would imply a 256-bit number in hex).

[Bitconneeeeect]

im making some modifications to bitcrack so that it can calculate random keys instead of incremental (i know the developer said he didn't see the point of random but it doesn't make sense if nearly everyone is using bitcrack the same way and generating the same results, everyone would just be following each others footsteps - randomization i think solves some of that)

You're spending too much thought on this. Just create a launch script for bitcrack which generates an entirely random 64 character hex string each time you run it and use this string as the keyspace parameter. There's no point in having a different increment than 1. Besides, generating an entirely new random key for each iteration will add a huge overhead and significantly reduce search speed. With a random starting key, all subsequent keys will still be random enough for what you're trying to achieve.

[WinBitcoins.Casino]

CUDA is for Nvidia cards only 

Your efforts are really impressive dear but try to open it up for other GPUs as well. I wish I could have helped but I am not a hardware expert.

[NotATether]

CUDA is for Nvidia cards only 

Your efforts are really impressive dear but try to open it up for other GPUs as well. I wish I could have helped but I am not a hardware expert.

Besides CUDA there's also another graphics programming language called OpenCL that is supported by all GPU vendors but it's not as fast as CUDA because that one is optimized for NVIDIA hardware but OpenCL's got to be generic.

There is an experimental OpenCL release of Bitcrack you can build by passing BUILD_OPENCL=1 to the make command assuming you already have OpenCL libraries and header installed.

[elisacat]

Just trying to do some math gymnastics to understand how the previous solutions worked (e.g. puzzle 53, 54, 55) using only bitcrack (not kanagaroo or other methods) and a fast gpu e.g. RTX 2080
(assuming 1 Billion keys generated per second)
Is my maths correct:  

15 characters in 100,000 seconds (28 hours)
16 characters in 1,000,000 seconds (278 hours) 11 days
17 characters in 10,000,000 seconds (2777 hours) 115 days

Calculated by converting the hash to a long number (e.g. 15 characters = 15 digit long number) and dividing it by 1 Billion keys per second to see how long it would take to sequentially reach the final value.

However if the above is correct, then how come puzzle 64 hasn't been solved within 115 days? or faster assuming some users are using multi-gpu? i'm sure my calculation has gone wrong somewhere above but not sure how

[WanderingPhilospher]

Just trying to do some math gymnastics to understand how the previous solutions worked (e.g. puzzle 53, 54, 55) using only bitcrack (not kanagaroo or other methods) and a fast gpu e.g. RTX 2080
(assuming 1 Billion keys generated per second)
Is my maths correct:  

15 characters in 100,000 seconds (28 hours)
16 characters in 1,000,000 seconds (278 hours) 11 days
17 characters in 10,000,000 seconds (2777 hours) 115 days

Calculated by converting the hash to a long number (e.g. 15 characters = 15 digit long number) and dividing it by 1 Billion keys per second to see how long it would take to sequentially reach the final value.

However if the above is correct, then how come puzzle 64 hasn't been solved within 115 days? or faster assuming some users are using multi-gpu? i'm sure my calculation has gone wrong somewhere above but not sure how

for each range, do 2 to the power of the bit range. Example 2 ^64 = 18,446,744,073,709,551,616; now divide that by # of key/s. example; 2 ^ 64 / 1,000,000,000 (1 billion key/s) = 18,446,744,073 seconds = 307,445,734 minutes = 5,124,095 hours = 213,503 days = 584 years . I think that math is accurate. but basically 2^64 / 1000000000 / 86400 (seconds in a day) = 213,503 days / 365 (days in a year) = 584 years

[elisacat]

Just trying to do some math gymnastics to understand how the previous solutions worked (e.g. puzzle 53, 54, 55) using only bitcrack (not kanagaroo or other methods) and a fast gpu e.g. RTX 2080
(assuming 1 Billion keys generated per second)
Is my maths correct:  

15 characters in 100,000 seconds (28 hours)
16 characters in 1,000,000 seconds (278 hours) 11 days
17 characters in 10,000,000 seconds (2777 hours) 115 days

Calculated by converting the hash to a long number (e.g. 15 characters = 15 digit long number) and dividing it by 1 Billion keys per second to see how long it would take to sequentially reach the final value.

However if the above is correct, then how come puzzle 64 hasn't been solved within 115 days? or faster assuming some users are using multi-gpu? i'm sure my calculation has gone wrong somewhere above but not sure how

for each range, do 2 to the power of the bit range. Example 2 ^64 = 18,446,744,073,709,551,616; now divide that by # of key/s. example; 2 ^ 64 / 1,000,000,000 (1 billion key/s) = 18,446,744,073 seconds = 307,445,734 minutes = 5,124,095 hours = 213,503 days = 584 years . I think that math is accurate. but basically 2^64 / 1000000000 / 86400 (seconds in a day) = 213,503 days / 365 (days in a year) = 584 years

Thanks. But using the example of puzzle 64, most of the hex values are just zeroes so only 16 characters are used for calculation
so if i use your calculation:
2^16 / 1000000000 (per/second key rate of a fast bitcrack)  /86400 would be the correct formula right? but that produces a number in the sub decimal i.e. hours in total to calculate puzzle 64

[WanderingPhilospher]

Just trying to do some math gymnastics to understand how the previous solutions worked (e.g. puzzle 53, 54, 55) using only bitcrack (not kanagaroo or other methods) and a fast gpu e.g. RTX 2080
(assuming 1 Billion keys generated per second)
Is my maths correct:  

15 characters in 100,000 seconds (28 hours)
16 characters in 1,000,000 seconds (278 hours) 11 days
17 characters in 10,000,000 seconds (2777 hours) 115 days

Calculated by converting the hash to a long number (e.g. 15 characters = 15 digit long number) and dividing it by 1 Billion keys per second to see how long it would take to sequentially reach the final value.

However if the above is correct, then how come puzzle 64 hasn't been solved within 115 days? or faster assuming some users are using multi-gpu? i'm sure my calculation has gone wrong somewhere above but not sure how

for each range, do 2 to the power of the bit range. Example 2 ^64 = 18,446,744,073,709,551,616; now divide that by # of key/s. example; 2 ^ 64 / 1,000,000,000 (1 billion key/s) = 18,446,744,073 seconds = 307,445,734 minutes = 5,124,095 hours = 213,503 days = 584 years . I think that math is accurate. but basically 2^64 / 1000000000 / 86400 (seconds in a day) = 213,503 days / 365 (days in a year) = 584 years

Thanks. But using the example of puzzle 64, most of the hex values are just zeroes so only 16 characters are used for calculation
so if i use your calculation:
2^16 / 1000000000 (per/second key rate of a fast bitcrack)  /86400 would be the correct formula right? but that produces a number in the sub decimal i.e. hours in total to calculate puzzle 64

I don't understand what you mean by most hex values are just zeroes...for the 64 bit range, The leading hex character will be somewhere in the 8 through F range and the remaining 15 characters will be in the 0 through F range.

[PawGo]

Thanks. But using the example of puzzle 64, most of the hex values are just zeroes so only 16 characters are used for calculation
so if i use your calculation:
2^16 / 1000000000 (per/second key rate of a fast bitcrack)  /86400 would be the correct formula right? but that produces a number in the sub decimal i.e. hours in total to calculate puzzle 64

You mix binary and hex notation.

[WanderingPhilospher]

Just trying to do some math gymnastics to understand how the previous solutions worked (e.g. puzzle 53, 54, 55) using only bitcrack (not kanagaroo or other methods) and a fast gpu e.g. RTX 2080
(assuming 1 Billion keys generated per second)
Is my maths correct:  

15 characters in 100,000 seconds (28 hours)
16 characters in 1,000,000 seconds (278 hours) 11 days
17 characters in 10,000,000 seconds (2777 hours) 115 days

Calculated by converting the hash to a long number (e.g. 15 characters = 15 digit long number) and dividing it by 1 Billion keys per second to see how long it would take to sequentially reach the final value.

However if the above is correct, then how come puzzle 64 hasn't been solved within 115 days? or faster assuming some users are using multi-gpu? i'm sure my calculation has gone wrong somewhere above but not sure how

for each range, do 2 to the power of the bit range. Example 2 ^64 = 18,446,744,073,709,551,616; now divide that by # of key/s. example; 2 ^ 64 / 1,000,000,000 (1 billion key/s) = 18,446,744,073 seconds = 307,445,734 minutes = 5,124,095 hours = 213,503 days = 584 years . I think that math is accurate. but basically 2^64 / 1000000000 / 86400 (seconds in a day) = 213,503 days / 365 (days in a year) = 584 years

Thanks. But using the example of puzzle 64, most of the hex values are just zeroes so only 16 characters are used for calculation
so if i use your calculation:
2^16 / 1000000000 (per/second key rate of a fast bitcrack)  /86400 would be the correct formula right? but that produces a number in the sub decimal i.e. hours in total to calculate puzzle 64

I don't understand what you mean by most hex values are just zeroes...for the 64 bit range, The leading hex character will be somewhere in the 8 through F range and the remaining 15 characters will be in the 0 through F range.

Look at it like this; starting 64 bit range in hex, is 8000000000000000 and the last is FFFFFFFFFFFFFFFF; SO 8000000000000000 then 8000000000000001, then 8000000000000002, all the way to  FFFFFFFFFFFFFFFF

[elisacat]

Look at it like this; starting 64 bit range in hex, is 8000000000000000 and the last is FFFFFFFFFFFFFFFF; SO 8000000000000000 then 8000000000000001, then 8000000000000002, all the way to  FFFFFFFFFFFFFFFF

ok got it. makes sense now. thanks

[elisacat]

for each range, do 2 to the power of the bit range. Example 2 ^64 = 18,446,744,073,709,551,616; now divide that by # of key/s. example; 2 ^ 64 / 1,000,000,000 (1 billion key/s) = 18,446,744,073 seconds = 307,445,734 minutes = 5,124,095 hours = 213,503 days = 584 years . I think that math is accurate. but basically 2^64 / 1000000000 / 86400 (seconds in a day) = 213,503 days / 365 (days in a year) = 584 years

So, if by some chance i knew the first 2 characters for puzzle number 64 then it becomes a 50 bit password hash problem right? in which case it would take roughly 100 days to solve if i understood your formula correctly

[WanderingPhilospher]

for each range, do 2 to the power of the bit range. Example 2 ^64 = 18,446,744,073,709,551,616; now divide that by # of key/s. example; 2 ^ 64 / 1,000,000,000 (1 billion key/s) = 18,446,744,073 seconds = 307,445,734 minutes = 5,124,095 hours = 213,503 days = 584 years . I think that math is accurate. but basically 2^64 / 1000000000 / 86400 (seconds in a day) = 213,503 days / 365 (days in a year) = 584 years

So, if by some chance i knew the first 2 characters for puzzle number 64 then it becomes a 50 bit password hash problem right? in which case it would take roughly 100 days to solve if i understood your formula correctly

I calculate 834 days:

2^56 / 1000000000 / 86400 = 833.99

For each character you know, in your example, the first 2, so let's say the key is 81C3F8710B26AC39, and you know the first 2 characters are 81, then you would need to solve the last 14 characters which would be 2 ^56 (14 x 4)

[elisacat]

I calculate 834 days:

2^56 / 1000000000 / 86400 = 833.99

For each character you know, in your example, the first 2, so let's say the key is 81C3F8710B26AC39, and you know the first 2 characters are 81, then you would need to solve the last 14 characters which would be 2 ^56 (14 x 4)

Yes correct, I just recalculated and got the same now. cheers

[coin790]

the program no longer works. I double click on the bitcrack64 file but the program closes. I have an old gtx 1050ti that is gathering dust. I would like to reuse it.
I also can't run cudaInfo.exe. This program is not compatible with other cryptocurrencies. It would be interesting to test the security of many other algorithms. I would like to try btx coin or monero

[NotATether]

the program no longer works. I double click on the bitcrack64 file but the program closes. I have an old gtx 1050ti that is gathering dust. I would like to reuse it.
I also can't run cudaInfo.exe. This program is not compatible with other cryptocurrencies. It would be interesting to test the security of many other algorithms. I would like to try btx coin or monero

Please post any error messages that appear in the output of the BitCrack and CudaInfo programs.

Regarding cracking private keys of altcoin addresses, this is not possible because most of them have a different private key format than bitcoin addresses.

If the error is related to Nvidia drivers then the the issue is the binaries were compiled with an older compute capability inside NVCC, which means that you need to get CUDA toolkit and compile bitcrack yourself. You might also have to remove any references to COMPUTE_CAP as I said in my previous quote.

The developer of this tool is offline but for anyone else who is having problems compiling this on newer NVIDIA gpus, the issue is in the makefile where the CUDA compute version is defined. It's hardcoded at sm_30. Removing those references should make the compilation succeed.

Code:

COMPUTE_CAP=30
NVCC=nvcc
NVCCFLAGS=-std=c++11 -gencode=arch=compute_${COMPUTE_CAP},code=\"sm_${COMPUTE_CAP}\" -Xptxas="-v" -Xcompiler "${CXXFLAGS}"

All references to COMPUTE_CAP have to be deleted.

The above applies to the Linux version but you should look inside the .vcxproj files to see if there is one for Windows too.

[coin790]

i use windows 10 i don't have any usb memory to install linux.