BitCrack - A tool for brute-forcing private keys

[GBT_User]

I have a question. Recently there was a flood and a notebook containing a offline wallet was damage and it destroyed part of a WIF private key, so now I basically have:

Kw**********(I have the next 40 characters, just not posting for obvious reasons), so I am missing 10 characters in all.

I also have the public key. Is it possible to use this software to start a search at Kw... and iterate over the missing 10 characters with the known 40 characters also in the key.

For example : 1GuqEWwH5iRZ89oo5xw26FqmyZFMWZrtPi - is the public address

and for the WIF private key I'd have Kw**********JzXaqU2rcFSoaLaehAQHqoQX1cWCo92tAA3ihLJ7

Any advice is appreciated and examples are even more appreciated

Thank you,
S.

It's a good thing that you have end of WIF format data where the checksum is. You have to first Base58 decode the string (with corrupted part, or you can replace the corrupted part with zeros). Since you are doing it only once you can use this online tool:
https://www.browserling.com/tools/base58-decode

Once you have decoded number you can use the checksum to quickly check the possible missing values, if the checksum does not match you do not need the other calculations to get public key and check against it.
This is enormous speed-up, this is doable even on CPU, no need for GPU.

I doubt that you have some ready made tool for this second step, have to do some work yourself to code checking the missing values against the checksum. Good luck!


Edit:
Just tried it with some test values, you have to do Base58 Decode for all possible versions of missing values, not only once, string before corrupted characters stays the same but Base58 Encode changes all values after the corrupted place.

However, this is still much, much faster then generating Public key, doable on CPU for sure.

I believe I tried this with CPU and it was going to take a crazy amount of years to go through all combos. So perhaps I am doing something wrong. I am willing to pay a bounty for any help and code examples provided.

Thanks,
S.

Sure you need  58^10  combinations, which is quite a lot. There is no other way that I see.
So you need a fast algorithm.
I could probably write something in Javascript or Python but they will not be fast enough I fear.

Is there no way to read one of the 10 missing characters even slightly ?
sometimes you can try to see where the paper is slightly pressed by the pen?
What kind of reward did you have in mind ?

[NotATether]

Sure you need  58^10  combinations, which is quite a lot. There is no other way that I see.
So you need a fast algorithm.
I could probably write something in Javascript or Python but they will not be fast enough I fear.

Is there no way to read one of the 10 missing characters even slightly ?
sometimes you can try to see where the paper is slightly pressed by the pen?
What kind of reward did you have in mind ?

You're a bit late. We managed to get something running for him a few days ago here: https://bitcointalk.org/index.php?topic=5379131.msg58891921#msg58891921

[zahid888]

Is any version of Bitcrack available that searches for repidme 120 instead of addresses? maybe it will increase the speed

[PawGo]

Is any version of Bitcrack available that searches for repidme 120 instead of addresses? maybe it will increase the speed

I may be wrong, but I have a feeling it is already in place. The difference between RIPEMD160 and final address is that address is base58 encoded (+checksum +flag). And you are right, encoding candidate just to compare it with expected address makes no sense if you may compare pure RIPEMD160 values of both.

[NotATether]

I may be wrong, but I have a feeling it is already in place. The difference between RIPEMD160 and final address is that address is base58 encoded (+checksum +flag). And you are right, encoding candidate just to compare it with expected address makes no sense if you may compare pure RIPEMD160 values of both.

I would still generate both types of address if they have been cracked by the program.

It would suck for someone to find a key after so many months only for them to not know how to derive the correct type themselves. Script rules let you interchange private keys for those addys (because they are one and the same) but I don't think it would be obvious that you had an uncompressed addr instead of the compressed one you were using all along, because tx history is not shared between them.

[sp_]

Ethereum will probobly move to POS in 3 months. Millions of GPU's can be obsolete overnight...
I propose a Bitcrack + Ethereum classic dualmininer. Mine ethereum classic and crack bitcoin in the background without reduction in
ethash speed.

The dying ethereum network has 12.9091Petahash.

Or equivalent to around 650 000 000 gtx 1060 6gb.

They hash 100million keys per second each with the bitcrack sp-mod

[NotATether]

Millions of GPU's can be obsolete overnight...

If they can just switch to ETC then how do they get obsolete in 3 months?

I propose a Bitcrack + Ethereum classic dualmininer. Mine ethereum classic and crack bitcoin in the background without reduction in ethash speed.

That's just wasting the GPUs since almost no one has found a decent amount of BTC using Bitcrack (I am not counting the puzzle transactions which were intentionally designed to be cracked). Just point them all to an ETC pool at that point.

[COBRAS]

Hello everybody. The question arose.
How to determine between the two public keys which is bigger? In addition to the subtraction function.
Example.
123456789 private key is not known to us.
His public key.
025004d7d9c2a3b2d675ada618d9ceda55d1f6a9fdf263e24daa8cbea586af2b2b

And accordingly his rival.
12345678a private key is not known to us
His public key.
02fde2347f83e21198fc48b918f5657c188ffcdd8611b39b987230addb91d05d80

Thanks for the answer.

02fde.... > 02500, so 02fde bigger

[PawGo]

Hello everybody. The question arose.
How to determine between the two public keys which is bigger? In addition to the subtraction function.
Example.
123456789 private key is not known to us.
His public key.
025004d7d9c2a3b2d675ada618d9ceda55d1f6a9fdf263e24daa8cbea586af2b2b

And accordingly his rival.
12345678a private key is not known to us
His public key.
02fde2347f83e21198fc48b918f5657c188ffcdd8611b39b987230addb91d05d80

Thanks for the answer.

02fde.... > 02500, so 02fde bigger

If you have 2 points, in 2 dimensions, (1,3) and (3,1), which one would be „bigger”?
I am afraid you have wrong understanding what point is, and it comes from lack of knowledge.

[albert0bsd]

You only can determine if some publickey is bigger than another publickey if they are NEAR to each other.

Example:  Let to suppose  that there are two private keys A and B and  A > B

If P(A) > P(B) then P(A) - P(B) = P(C) Then P(C) is a positive Value if the value of C is under some low bit range lets to say less than 2^70 (70 bits) you can determine the value of P(C) with some tool like kangaroo of BSGS easily with no effort

So ONLY if the Difference P(A) - P(B)  or P(B) - P(A) is under some value easy to find you can know which one of those publickeys are bigger.

If the difference is bigger than 90 bits or something other high value then you CAN NOT know it. Unless you have some GPU farm to calculate those values.

Example:

Code:

P(A) = 025004d7d9c2a3b2d675ada618d9ceda55d1f6a9fdf263e24daa8cbea586af2b2b
P(B) = 02fde2347f83e21198fc48b918f5657c188ffcdd8611b39b987230addb91d05d80

Differences:

P(A) - P(B) = 0379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
P(B) - P(A) = 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798

Solve it with keyhunt:

Code:

$ cat input.txt
0379be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
$ ./keyhunt -m bsgs -f input.txt  -k 128 -t 4 -S -r 1:100000000000000
[+] Version 0.2.211117 SSE Trick or treat ¡Beta!, developed by AlbertoBSD
[+] K factor 128
[+] Threads : 4
[+] Mode BSGS secuential
[+] Opening file input.txt
[+] Added 2 points from file
[+] Range
[+] -- from : 0x1
[+] -- to   : 0x100000000000000
[+] N = 0x100000000000
[+] Bloom filter for 536870912 elements : 1840.33 MB
[+] Bloom filter for 16777216 elements : 57.51 MB
[+] Bloom filter for 524288 elements : 1.80 MB
[+] Allocating 8.00 MB for 524288 bP Points
[+] Reading bloom filter from file keyhunt_bsgs_4_536870912.blm .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_6_16777216.blm .... Done!
[+] Reading bP Table from file keyhunt_bsgs_2_524288.tbl .... Done!
[+] Reading bloom filter from file keyhunt_bsgs_7_524288.blm .... Done!
[+] Thread Key found privkey 1
[+] Publickey 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
[+] Thread 0xfff00000000001
End

The value of 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 is 1 Positive then if the result of the subtraction P(B) - P(A) is positive, hence P(B) > P(A) for this example.


@PawGo sorry to divert your topic, but i want to reply that question.

[COBRAS]

You only can determine if some publickey is bigger than another publickey if they are NEAR to each other.

Example:  Let to suppose  that there are two private keys A and B and  A > B

If P(A) > P(B) then P(A) - P(B) = P(C) Then P(C) is a positive Value if the value of C is under some low bit range lets to say less than 2^70 (70 bits) you can determine the value of P(C) with some tool like kangaroo of BSGS easily with no effort

So ONLY if the Difference P(A) - P(B)  or P(B) - P(A) is under some value easy to find you can know which one of those publickeys are bigger.

If the difference is bigger than 90 bits or something other high value then you CAN NOT know it. Unless you have some GPU farm to calculate those differences.

Hi Bro.

This is good idea I think, but real hard. Then  substract from 120 but 119 bit result = 119.5 bit ... 119.5 is very big too... And interesting question, if substract from 120 key, key 119.8 , it real or not get key for 119.2, in range like a119:119.2, or n-(0.2*120):n

Rang n-x:n need because if substracted too mach range will not be in 1:x..

[albert0bsd]

This is good idea I think, but real hard.

It is what the BSGS algorithm internally do.

[COBRAS]

This is good idea I think, but real hard.

It is what the BSGS algorithm internally do.

Thanks boss, I will try this. Yes, then B > A, so range in positive this good thing, and C = B - A, I think mast be < B too

[fxsniper]

Did I understand correct?
before puzzle 120 address. it is one of 119 bit address and then next bit double or add will be puzzle 120 address right?

[kknd]

GeForce RTX 3060 Laptop GPU


cuBitCrack.exe

-b 64 -t 512 -p 1024
564.09 MKey/s [00:00:32]

-b 96 -t 128 -p 1024
605.41 MKey/s [00:00:30]

-b 128 -t 256 -p 1024
666.64 MKey/s [00:00:27]

-b 82 -t 256 -p 2096
704.18 MKey/s [00:00:25]

clBitCrack.exe

-b 128 -t 256 -p 1024
613.69 MKey/s [00:00:29]

-b 128 -t 256 -p 756
609.83 MKey/s [00:00:29]

-b 128 -t 256 -p 1024
618.68 MKey/s [00:00:29]

-b 82 -t 256 -p 2096
620.38 MKey/s [00:00:29]

[coolindark]

qq= Which version of Cubitcrack are you using for 3xxx Nvidia?

GeForce RTX 3060 Laptop GPU


cuBitCrack.exe

-b 64 -t 512 -p 1024
564.09 MKey/s [00:00:32]

-b 96 -t 128 -p 1024
605.41 MKey/s [00:00:30]

-b 128 -t 256 -p 1024
666.64 MKey/s [00:00:27]

-b 82 -t 256 -p 2096
704.18 MKey/s [00:00:25]

clBitCrack.exe

-b 128 -t 256 -p 1024
613.69 MKey/s [00:00:29]

-b 128 -t 256 -p 756
609.83 MKey/s [00:00:29]

-b 128 -t 256 -p 1024
618.68 MKey/s [00:00:29]

-b 82 -t 256 -p 2096
620.38 MKey/s [00:00:29]

[PawGo]

GeForce RTX 3060 Laptop GPU


cuBitCrack.exe

-b 82 -t 256 -p 2096
704.18 MKey/s [00:00:25]

Do you mean build-in card or eGPU?

I have eGPU RTX 3060 and with these settings I have 800Mkey in peak, stable 780-790:


I use https://github.com/PawelGorny/BitCrack-3000 (forked from NotATether)

[NotATether]

Do you mean build-in card or eGPU?

I have eGPU RTX 3060 and with these settings I have 800Mkey in peak, stable 780-790:

I use https://github.com/PawelGorny/BitCrack-3000 (forked from NotATether)

On a related note: I'm assuming that my "workaround" for misaligned address bug on 2xxx and 3xxx series cards is working for you? (I never had thes cards, so I couldn't check myself). I'm assuming it's working for you because you published speed specs, but I just want to make sure it doesn't crash mid-computation.

[PawGo]

Do you mean build-in card or eGPU?

I have eGPU RTX 3060 and with these settings I have 800Mkey in peak, stable 780-790:

I use https://github.com/PawelGorny/BitCrack-3000 (forked from NotATether)

On a related note: I'm assuming that my "workaround" for misaligned address bug on 2xxx and 3xxx series cards is working for you? (I never had thes cards, so I couldn't check myself). I'm assuming it's working for you because you published speed specs, but I just want to make sure it doesn't crash mid-computation.

Honestly speaking I did not launch very long computations, so I cannot say if it crashes after one or seven hours, but for a few minutes it works smoothly
I think I just wanted to have a ready solution to be build with newer cuda and for the higher ccap.

[WanderingPhilospher]

Do you mean build-in card or eGPU?

I have eGPU RTX 3060 and with these settings I have 800Mkey in peak, stable 780-790:

I use https://github.com/PawelGorny/BitCrack-3000 (forked from NotATether)

On a related note: I'm assuming that my "workaround" for misaligned address bug on 2xxx and 3xxx series cards is working for you? (I never had thes cards, so I couldn't check myself). I'm assuming it's working for you because you published speed specs, but I just want to make sure it doesn't crash mid-computation.

Honestly speaking I did not launch very long computations, so I cannot say if it crashes after one or seven hours, but for a few minutes it works smoothly
I think I just wanted to have a ready solution to be build with newer cuda and for the higher ccap.

Honest question, why are people still using bitcrack with rtx 30xx or 20xx cards? Performance is "horrible" compared to software that does same thing...unless it's for the "stride" function, which is hit and miss if searching for an actual private key.