BitCrack - A tool for brute-forcing private keys

[NotATether]

Maybe this fork is working for you

https://github.com/ZenulAbidin/BitCrack-3000

But you would need to compile it yourself. I am Linux-User, so I cant help you there with compiling it. THere is also a sp version precompiled for windows fork, it is somewhere linked. I did not save the link as it was uninteresting for me.

For faster speed on Windows use the fork by richieburns which has a compiled exe here:

https://github.com/richieburns/BitCrack_AMP/releases/download/v1.0.0_AMP/BitCrack_AMP.zip

Bitcrack CUDA 11.2 Compute 8.6 Win10

Would appreciate some benchmarks for RTX 30 series cards.....

Cheers

sp-mod does not work with RTX 30xx as far as I know.

[1714505057]

1714505057

[1714505057]

1714505057

[1714505057]

1714505057

[zahid888]

Instead of using random numbers i am using some logical numbers where i take only 8 character of keys and the other 8 are my computation.

https://imgur.com/Sd93EOt

for example: I chose address which starts from 16 and ends from QN something like this - addr : 16FhwWS4QRadRp77Tuwd1K4ofggQb9uRQN pvk : B2BDE4B3FF60553F here i take the 8 characters of key from beginning and the other 8 is my computation. --keyspace b2bde4b300000000:b2bde4b3ffffffff...  hope this trick will do something or maybe not

today or tomorrow i will scan the whole range from a5a46bed to ffffffff and i am adding only 1 in begin numbers so those numbers are also running in sequence.

[PawGo]

Tbh, If i would try to crack the puzzle I would fix the OpenCL Bug and implement the various optimizations from different forks of BitCrack. Then I would modify the code and instead of incrementing the key, i would decrement the key. I mean... there are alot of people scanning the whole 2^63 - 2^64 Range and they already scanned about 10-20% of it from the beginning already. So scanning it again makes no sense. But I did not see a modification of BitCrack which implements decrementing the keys.

Check: http://ttdsales.com/64bit/login.php
That project splits the work and sends the region to check. They will probably not tell you which parts were already checked, but at least they show the progress in subsets.

Instead of using random numbers i am using some logical numbers where i take only 8 character of keys and the other 8 are my computation.

https://imgur.com/Sd93EOt

for example: I chose address which starts from 16 and ends from QN something like this - addr : 16FhwWS4QRadRp77Tuwd1K4ofggQb9uRQN pvk : B2BDE4B3FF60553F here i take the 8 characters of key from beginning and the other 8 is my computation. --keyspace b2bde4b300000000:b2bde4b3ffffffff...  hope this trick will do something or maybe not

If you assume that address has any correlation with private key (like alphabetical order or so), then you are wrong. Address is created from hash functions, which completely destroy any order or correlation. The fact that your example address comes from known private key means completely nothing and cannot be any proof or base to assume that other address is somewhere 'near'.

[AuorFedelmid]

Maybe this fork is working for you

https://github.com/ZenulAbidin/BitCrack-3000

But you would need to compile it yourself. I am Linux-User, so I cant help you there with compiling it. THere is also a sp version precompiled for windows fork, it is somewhere linked. I did not save the link as it was uninteresting for me.

For faster speed on Windows use the fork by richieburns which has a compiled exe here:

https://github.com/richieburns/BitCrack_AMP/releases/download/v1.0.0_AMP/BitCrack_AMP.zip

Bitcrack CUDA 11.2 Compute 8.6 Win10

Would appreciate some benchmarks for RTX 30 series cards.....

Cheers

sp-mod does not work with RTX 30xx as far as I know.

Already noticed a difference, similar speeds but scanned over double the number of keys in a single keyrange. It was scanning around 700,000,000,000 with clBitrack, currently on 1,481,528,836,096 and still going.id say that is now capturing the keys it was not before and makes sense that clBitCrack was not working correctly.

[zahid888]

If you assume that address has any correlation with private key (like alphabetical order or so), then you are wrong. Address is created from hash functions, which completely destroy any order or correlation. The fact that your example address comes from known private key means completely nothing and cannot be any proof or base to assume that other address is somewhere 'near'.

And what about this --

16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN - 
16jY7qLJnxLQQRYPX5BLuCtcBs6tvXz8BE - 3AD3536AEA8CEB2B0
16jY7qLJnx2EZZumnYFke3GutCrRnHKs1M - 7013536A91A6441B0

That is why I have a little hope that it might work I know hash function is totally different what I thought but for me it maybe a ray of hope in despair...

[a.a]

No, the puzzle is between 2^63 and 2^64 BUT:

https://github.com/brichard19/BitCrack/issues/223

(uint64_t)_points * _threads * _blocks;


So instead of checking all keys you are basically ignoring alot of keys. If you have e.g. 512 blocks and 1024 threads (doesnt matter if those are valid inputs) you would basically jump over 512*1025 = 2^19 keys.

So thats why you are faster finished.

Yeah not sure where you get your info from.  Bitcrack doesn't ignore keys. Unless you are speaking of a bug with the CL version, but the program does not skip/ignore keys unless you use the stride option, on purpose.

Please reread what I wrote: The buggy line results in skipping keys.

[AuorFedelmid]

Anyway, there certainly is some issues with the openCL version as cuBitcrack found nearly 3 times as many keys in the same range.

I have joined the TTD pool anyway, I didn't realize there was one, better to share my hash and we all get something out of it.

[fxsniper]

Anyway, there certainly is some issues with the openCL version as cuBitcrack found nearly 3 times as many keys in the same range.

I have joined the TTD pool anyway, I didn't realize there was one, better to share my hash and we all get something out of it.

openCL  clBitcrack latest version 0.31 some person use have problem

try use  release 0.30 it is no problem for every one
https://github.com/brichard19/BitCrack/releases/download/0.30/clBitCrack.exe

[fxsniper]

How long time for bitcrack calculate form RIPEMD-160 and double sha256 then Base58

if use long time

Can possible add function bitcrack to have option --ripemd for search as RIPEMD-160 replace address?

if time from private key to address using time 100%
and time from RIPEMD-160 to address using over 30%

if can search at RIPEMD-160 maybe help search key up to 30%

just idea

[a.a]

BitCrack is already transforming compressed and uncompressed BitCoin Addresses to RIPEMD-160 when loading the addresses. SegWit and MultiHash Addresses are not transformed and result in an invalid Argument Error in BitCrack. BitCrack is then putting the RIPEMD-160 hashes into a Bloom Filter and does not make a string based comparison. Because compressed and uncompressed RIPEMD-160 addresses are generated from the compressed or uncompressed EC-PubKey you can not optimize it at an earlier stage.

The only improvements/optimization you could do is:
- Implement SegWit and MultiHash-Addresses to RIPEMD-160 transformation.
- Implement a Public-Key only search (Write a Programm which searches the Blockchain for public-keys and modify BitCrack to use it as an input), then you could potentially speed up the process but keys without known pubKey will not be searched (tradeoff).

[WanderingPhilospher]

BitCrack is already transforming compressed and uncompressed BitCoin Addresses to RIPEMD-160 when loading the addresses. SegWit and MultiHash Addresses are not transformed and result in an invalid Argument Error in BitCrack. BitCrack is then putting the RIPEMD-160 hashes into a Bloom Filter and does not make a string based comparison. Because compressed and uncompressed RIPEMD-160 addresses are generated from the compressed or uncompressed EC-PubKey you can not optimize it at an earlier stage.

The only improvements/optimization you could do is:
- Implement SegWit and MultiHash-Addresses to RIPEMD-160 transformation.
- Implement a Public-Key only search (Write a Programm which searches the Blockchain for public-keys and modify BitCrack to use it as an input), then you could potentially speed up the process but keys without known pubKey will not be searched (tradeoff).

If you know the pubkey then just use Kangaroo program. No need to tweak anything in bitcrack.  Kangaroo is much faster than a bitcrack sequential search.

[fxsniper]

this idea is help to accelerate spped of bitcrack for scan to high

for use bitcrack solve puzzle #64
address still legacy address and all puzzle is compress address

refer my post with RIPEMD-160

now, we try to optimize bitcrack to can scan address faster and high number right

idea is just cut off process of bitcrack to

I not yet read bitcrack souce code, Did bitcrack convert publickey to RIPEMD-160 and double sha256 or not?
bitcrack convert key to address and check compare gen address and target address right?

reference this app
http://gobittest.appspot.com/Address

you can see we can convert address to roll back to RIPEMD-160
put address to box 9 - Base58 encoding of 8 and click send
web app will convert back to RIPEMD-160
idea it is just convert address to RIPEMD-160 and cut out work process to short

hope this method help to can scan bitcrack faster up to 30%   (if 30% is process from RIPEMD-160 to address)

just idea please ignore

[a.a]

What you propose is already implemented in bitcrack.

[fxsniper]

What you propose is already implemented in bitcrack.

propose make BitCrack scan key faster?
I know already bitcrack have all process convert key to address on bitcrack include RIPEMD-160 inside

I not sure you not yet understand
bitcrack bruteforce address right?
this idea just bruteforce to RIPEMD-160

however if this method not difference
if you bitcrack work on GPU can scan 1000Mkey/s
and if process use time to do 30% second if do this idea will help to make GPU scan at 1300 Key/s

[a.a]

You what propose?

You ask "How long time for bitcrack calculate form RIPEMD-160 and double sha256 then Base58"

Answer is 0

Because bitcrack not do calculate from RIPEMD-160 and double sha256 then base58

Bitcrack convert address legacy compress address to RIPEMD-160 and calculate till step 3 of http://gobittest.appspot.com/Address

bitcrack then compare calculated RIPEMD-160 with RIPEMD-160 address in bloom filter

you understand?

[NotATether]

And what about this --

16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN - 
16jY7qLJnxLQQRYPX5BLuCtcBs6tvXz8BE - 3AD3536AEA8CEB2B0
16jY7qLJnx2EZZumnYFke3GutCrRnHKs1M - 7013536A91A6441B0

That is why I have a little hope that it might work I know hash function is totally different what I thought but for me it maybe a ray of hope in despair...

Any correlation is just a coincidence as the probability of finding a private key for that address which has those green characters is astronomically small.

[a.a]

Well... there are "only" 16^10 permutations to check empirically if there is a correlation. Have fun

counter-evidence:

3bd3536aea8ceb2b => 1DB6to5oCUJ3mLELL7M9JsMdhHQxfVLVHK 

[a.a]

Is there a reason why BitCrack is not under maintenance any more?

Should we create a new Fork, where we combine all the good patches?

I would be happy to take this job (and be the benevolent dictator it needs ).

[WanderingPhilospher]

Is there a reason why BitCrack is not under maintenance any more?

Should we create a new Fork, where we combine all the good patches?

I would be happy to take this job (and be the benevolent dictator it needs ).

Because most see it as a waste of time/next to impossible, especially since everyone is trying to attack #64 solo.  #64 requires many resources to crack, and the next one, #66 will be 4  times as hard, and will get harder and harder as you go up.

EDIT: also, because there are other programs that can run multi gpu's on one instance, bitcrack is sort of archaic.  Maybe make it multi gpu and you can gain some new interest.

[Blackhawktom]

Can someone please help me. The cubitcrack hangs after loading address and does nothing.
Thank you.