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

[zahid888]

16jY7qLJnN4eqD1eArr9vRVABixvcbLyXY   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYxZTMH89fVdXM613vVD   0x0000000000000000000000000000000000000000000000009A97E3E4A6A15391
16jY7qLJNSJnur5KVhoaKC25ZVyP2LpGuj   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYxjHeA2YwWZZiCikjox   0x0000000000000000000000000000000000000000000000009CA0EFE4DC9C4B72
16jY7qLJuZ4WrwBbbAoHSsd9tf74x55oCG   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYy9JuVALp1tNJbnhQVd   0x000000000000000000000000000000000000000000000000A199E4EEF9FABBB7
16jY7qLJpeQTfzX1SYgoNWDmqwsq9kCeJ1   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYyKK7FsNCnLPFCCpKSm   0x000000000000000000000000000000000000000000000000A3ABFF4956D1E3CF
16jY7qLJzxMfbfrxVjdzKVcMYuABMT3JUg   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYyNFkpdHpb3bM1xmV85   0x000000000000000000000000000000000000000000000000A447E8DC181F71AF
16jY7qLJFMG4uGLQ6p2NK71KSMn1ZsHnR1   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYyeAPpAzvbmnqon6doc   0x000000000000000000000000000000000000000000000000A792E0E2AB63BC53
16jY7qLJ1itzy2eqPDW3EnDrFAMi94pkRw   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYyqiXyjT9qpmin7Wfab   0x000000000000000000000000000000000000000000000000A9F727369AB8A72C
16jY7qLJ48zRMcRFt25ZgMwaLGUS4xnGp9   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYzW18Fk1gFEgovFKQWQ   0x000000000000000000000000000000000000000000000000B1E3FF83D3C2CADA
16jY7qLJ2aBYPJHvYZCexMtX9As7YXKTXa   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYzXJp12kbfHSjKebd37   0x000000000000000000000000000000000000000000000000B22925E55D30526E
16jY7qLJf5WRNQsr4M7PHw3CcdUkjjiTcD   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYzXmDzNVaBWbZEZXh6m   0x000000000000000000000000000000000000000000000000B24147E4FA620801
16jY7qLJyE4Cspx2xJZimnKFDu1mA5v8q4   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ1Pbx2U9Tue4XUYG6U8   0x000000000000000000000000000000000000000000000000BC9264E45AB665AF
16jY7qLJfn6u2bhsqryEBfJrUqmyYtwvMw   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ1Q86Vo5P6JRQATdKzD   0x000000000000000000000000000000000000000000000000BCADEFE466EB45B3
16jY7qLJD6fvZebckbnmBCqyu2uDwRqii6   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ1Wnxrwi3h1eXSM9aB2   0x000000000000000000000000000000000000000000000000BE0F6652B041E9C5
16jY7qLJwdUDparg4Y3EgFpAhZNHTSkPFt   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ1iEDTRv1GsFNzVs66u   0x000000000000000000000000000000000000000000000000C06D61514D867204
16jY7QLjn6MEodyvdGc1w1oiKSBoC4beMa   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ1o4f3LMgdGZzo54fHU   0x000000000000000000000000000000000000000000000000C16D9AFCE49A235B
16jY7qLJSYVeyhvHbEC7LwgFQnVgPai56w   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ22qhJ8bCdjGhFnYUod   0x000000000000000000000000000000000000000000000000C447A5E4210BCE22
16jY7qLJ8BQQDJJjRUop7FEiEyJJCR2ZE9   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ22raskEkhrsbbtiqYe   0x000000000000000000000000000000000000000000000000C44875E4EF637660
16jY7qLJn19vvyctGxbtBuJrrpRCt5er9H   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ22uzGCyMtBtxdx98zV   0x000000000000000000000000000000000000000000000000C44B91E42375905B
16jY7qLJpG8FVrMLbk6NBtWMiejrKgEd5q   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ2CjKM4KjebcpYVfcU3   0x000000000000000000000000000000000000000000000000C653BCE4B4967446
16jY7qLJxw7aXRjDTLutu7BC5Wp1LqKBPc   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ2P29A3A3m6TTASwgt7   0x000000000000000000000000000000000000000000000000C87506E4F8BA10EC
16jY7qLJzqL7qGrCz9joUf3qkTqUwygnez   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ2RAXicvkEm6k2nYjED   0x000000000000000000000000000000000000000000000000C8E6ACD0039891A4
16jY7qLJiGvJJajVN5anM8wbkW2x6JDsbx   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ2VRiL5f4Nb9VPd78i8   0x000000000000000000000000000000000000000000000000C9C883940AF8DF68
16jY7qLJUV3uavsiC9F69PtoCvXzcnrQpw   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ2isc1KbNBrvkfGqq4k   0x000000000000000000000000000000000000000000000000CC910FE39C32DC0B
16jY7qLJSabEVThGZ58M6KmuKvaYKbkJqJ   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ2iuqhQb2AUazGirsp5   0x000000000000000000000000000000000000000000000000CC931AE3E13C6F30
16jY7qLJavMWDu8C9AGuH9LXHFyJVZHSMy   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ2ix5PSGoVFJuerbVCU   0x000000000000000000000000000000000000000000000000CC9525E3226024A4
16jY7qLJpBTbteT7BCKPPrdtgwRbd2g6xe   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ2iyELmr8hZLwmyG6Bb   0x000000000000000000000000000000000000000000000000CC9633E407F8086A
16jY7qLJsaainy7EAxWCmsDGg934UdQujU   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ2j2CSDwWMBXosn6FTt   0x000000000000000000000000000000000000000000000000CC98E9E362CC4542
16jY7qLJbYbK2DTYqDih9d1fhui4eELaBr   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ2nWi1sYqmLw8eZ7ohb   0x000000000000000000000000000000000000000000000000CD51EFE3E898CE22
16jY7qLJjWKajipMwHwgFd7R5gYWDRVxvX   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ2u6kZLu4EQB7Zp82FN   0x000000000000000000000000000000000000000000000000CEAEFDE46E720BA0
16jY7qLJHmJ1N3frmsNRJhXYwXk4pz9dBP   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ3XwL2Ag8NRqPYJ1oz4   0x000000000000000000000000000000000000000000000000D64F13C3A8A5A56C
16jY7qLJrGLxGSzddR5KcJHe8wMXPKvoZ5   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ3afDStwDrUmNkWmrFS   0x000000000000000000000000000000000000000000000000D6DF549B417D5F5F
16jY7qLJeBU1dWv6Gw7cNFdpEfssB6nM6p   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ3expLEfFYjBUcemQYZ   0x000000000000000000000000000000000000000000000000D7C3610CACD10E2F
16jY7qLJ3ueYvr33g8f3WMxMUKubDfyTYt   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ3z3yNuKWVYBBPRb2Ym   0x000000000000000000000000000000000000000000000000DBB6EEE24AF250E0
16jY7qLJySCNV747Z89CXnYnhC8sBETpAq   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ43jvecenYSdMxCdzy1   0x000000000000000000000000000000000000000000000000DC7A6954459982B4
16jY7qLJtSouCs3cVpeZFMynfCZcUYhBJL   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ4aBj9y1zAwu3namRZa   0x000000000000000000000000000000000000000000000000E2C7BCE4D98A1CEF
16jY7qLJg8UVMsNVgmDkU5LYfnUvcHFgHE   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ4xkGrkun2gUoJjr1V3   0x000000000000000000000000000000000000000000000000E7734AEB1A2C68A4
16jY7qLJbpczaisuZfaGAwGtmyYgpyikCa   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ536g3o62iNJ2T5hgEa   0x000000000000000000000000000000000000000000000000E859E5E2400E0E2D
16jY7qLJZRNXy8sYPcy8icoaHTszZzrmxY   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ59VkXvMn6dvfS8YYdx   0x000000000000000000000000000000000000000000000000E9ACEEE0A95849D1
16jY7qLJceFLCRJ3W5VDvFfBagQVpde5Pj   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ5PmCrhWDnqirjjwLzP   0x000000000000000000000000000000000000000000000000ECA0EFE42AB81E7D
16jY7qLJceFLCRJ3W5VDvFfBagQVpde5Pj   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ5PmCrhWDnqirjjwLzP   0x000000000000000000000000000000000000000000000000ECA0EFE42AB81E7D
16jY7qLJTeYW5FumLwXdjQVG9siirnups8   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ5PtsEEWxLgtrFYxbGD   0x000000000000000000000000000000000000000000000000ECA7EFE46C1094D9
16jY7qLJ6AkxWNMXHHiWL6nQS8sAfijdjm   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ5hVMEM5EJTZ3zqqw5V   0x000000000000000000000000000000000000000000000000F04C4D5648DC1F94
16jY7qLJmHoEkEbsaw8rMXUKT6VxJ6tCV1   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ5iMqa6avpCADgbdQb9   0x000000000000000000000000000000000000000000000000F07A6E5B3C4671AA
16jY7qLJZTyb8ammZufMPy1gTktDm6tKSx   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ5sNSQmoMGCSyqtMYvA   0x000000000000000000000000000000000000000000000000F257E7D91DC58530
16jY7qLJ7xMpwdjzoW3zsaESTwy9tekRxA   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ5sZpx9n6TA4SG4yFTh   0x000000000000000000000000000000000000000000000000F2624F96E4B0F443
16jY7qLJnNtLkE51fgNsMqYAZ5i6LqURJm   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ5saUxBsBRwmkYPwMbG   0x000000000000000000000000000000000000000000000000F262E8D54F236F43
16jY7qLJBSqbwDwVa11q4HFr4237sEypfZ   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ5ubd5DpcWtDGBQVB18   0x000000000000000000000000000000000000000000000000F2CDEF415A50F2BC
16jY7qLJJa2D8Q7aNSt818G47epM2rwsou   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ6BWFUCw13Z5sqc16Bs   0x000000000000000000000000000000000000000000000000F618E4E0BEFB65C1
16jY7qLJevsjxqTvRGUfjEhSKjnceRew5h   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ6dMBrd19uS9D1AWkXf   0x000000000000000000000000000000000000000000000000FB72665B09D2E273
16jY7qLJWQnhf9uUKSyAW1WbgGVYvBmLgy   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ6tSnkkQ9t8ASzbj7Pb   0x000000000000000000000000000000000000000000000000FE9264E43F208CCF
16jY7qLJeSKNp2iZDStRSn4Vq9Qp9N76cR   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ6y2epucpykooTArMLt   0x000000000000000000000000000000000000000000000000FF854CE413430A01
16jY7qLJeSKNp2iZDStRSn4Vq9Qp9N76cR   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ6y2epucpykooTArMLt   0x000000000000000000000000000000000000000000000000FF854CE413430A01
16jY7qLJxeuWjZKR25E4v8ZBnEPvxwg3hu   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ6z68xSU8ar8sakZhhM   0x000000000000000000000000000000000000000000000000FFBD79E6D341D584
16jY7qLJnSfxcXN9Bj478PByYsySKe19Lu   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qcwwBbFjMbsoa44FVZuR   0x00000000000000000000000000000000000000000000000B7476CDE460B9B174
16jY7qLJAi1LdLnfSX6BPkntA4NypEXnZr   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ5gusyFnCfWohqXPYDH   0x000000000000000000000000000000000000000000000000F02DB8E20CFB42B0
16jY7qLJQimSZRpMiQmLRtxbhWbxWu6WFi   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYzycTBmmA1DDUjk5uab   0x000000000000000000000000000000000000000000000000B79B0D2964C7B242
16jY7qLJkK8afETqL39xFSkJ2AvgCf1oJr   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ4L1ops3yX974K33we5   0x000000000000000000000000000000000000000000000000DFD8CA57EEAED15E
16jY7qLJSnXS4m79oHNixgRhHoonunT1q2   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYzTZBWJXvRmdW1xk8bc   0x000000000000000000000000000000000000000000000000B1624F968214874A
16jY7qLJ7xMpwdjzoW3zsaESTwy9tekRxA   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ5sZpx9n6TA4SG4yFTh   0x000000000000000000000000000000000000000000000000F2624F96E4B0F443
16jY7qLJDnq54cdpm6RSrj1QPocvQkTeii   KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qZ55RfbNgUCsLt7ZBzXj   0x000000000000000000000000000000000000000000000000E8D53BD260ED66E5

may be this will help someone to solve P 64

[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.