BitCrack - A tool for brute-forcing private keys

[bob123]

Greetings to All! If there are people who can help me? My task is to use the “BitCrack” program to find one private key from 10,000,000 Bitcoin Addresses. This is my scientific work. I created a theme and described:
https://bitcointalk.org/index.php?topic=5060735.msg47651430#msg47651430

Did you even read this thread ?

What you are trying is NOT POSSIBLE. You won't be able to achieve what you are trying.

I don't know how often you need to hear it until you finally accept it. It already has been mentioned in your thread.


Your only option would be to try out every single possible private key (2^256) and check whether it resolves to your address.
But since the number is way too high to just test a fraction of the keyspace, you should just give up.

Your 'scientific work' is crap.

[1714815751]

1714815751

[1714815751]

1714815751

[1714815751]

1714815751

[arulbero]

Greetings to All! If there are people who can help me? My task is to use the “BitCrack” program to find one private key from 10,000,000 Bitcoin Addresses. This is my scientific work. I created a theme and described:
https://bitcointalk.org/index.php?topic=5060735.msg47651430#msg47651430

This doesn't make any sense.
It is very simple to do what TrumenPack says, in this way:

1) I generate a random public key P1 (P1 is a point of secp256k1 curve)
    

2) Then I generate 10,000,000 consecutive public keys in this way:

    P2 = P1 + G
    P3 = P2 + G (= P1 + 2*G)
    P4 = P3 + G (= P1 + 3*G)
    ....
    P27589 = P1 + 27588*G
    ….
    P10000000 = P1 + 9999999*G

3) I get from each public key the address:

   address1 = hash160 (P1)
   address2 = hash160 (P2)
   address3 = hash160 (P3)
   ....
   address10000000 = hash160 (P10000000)


Let's say now that address27589 = "18HPzD22qaUvJL69yjF3vUXx7Kfg7o5q7F". If (it is a very big if) you find out that the private key is "100A" (hex format, try to put this value here --> http://gobittest.appspot.com/Address, i. e. private key = 1*2^12 +10 = 4106), then it would be very simple to get the private keys of all the other addresses*** too:


private key of address1 = (private key of address27589 - 27588)  mod n
.....
private key of address27588 = private key of address27589 - 1 = 4105
private key of address27589 = 4106
private key of address27590 = private key of address27589 + 1 = 4107
private key of address27591 = private key of address27589 + 2 = 4108
.....
private key of address10000000 = private key of address27589 + 9.972.411 = 9.976.517


***this is true only if you find the private key to the public key P27589. There are about 2^96 different valid private keys for the address27589!

[Thirdspace]

Yes, I generated these Bitcoin Addresses through certain numerical coordinates.

2) Then I generate 10,000,000 consecutive public keys in this way:

he said his method of generation is "through certain numerical coordinates"
but he doesn't explain how he produced these numerical coordinates or its origin
his 10,000,000 addresses are not generated sequentially as you thought

[arulbero]

his 10,000,000 addresses are not generated sequentially as you thought

I didn't say that, I said that is simple to get the private keys for 10000000 addresses if you know one private key and if that addresses are related in some way. "Consecutive keys" are only an example.

[stalker00075]

who hacked 15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz

[Thirdspace]

who hacked 15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz

this one is part of bitcoin puzzle
but the last recent three addresses looked like moved by the puzzle maker rather than cracked
1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa - (Spent) 0.055 BTC
17aPYR1m6pVAacXg1PTDDU7XafvK1dxvhi - (Spent) 0.056 BTC
15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz - (Spent) 0.057 BTC
fund on these three addresses moved to 1AqEgLuT4V2XL2yQ3cCzjMtu1mXtJLVvww

[timisis]

I am not surprised the OP did a much better job than me with this What does surprise me is that the donation address is a 1x, I expected a Segwit address from such a sophisticated user. Or is it a case of his 1x address really being a Segwit or script of some kind, last year I remember researching you could translate a 3x to a 1x, but I cannot remember how

I am also not surprised  I cannot compile out of the box on my VS 2017, all kinds of errors. What does surprise me though is that some code in there, perhaps from the Cuda Toolkit, even tells me "this code will only work in VS 2010.... 2017", so it does not recognize my VS version, WTF!

[DevilOper]

this one is part of bitcoin puzzle
but the last recent three addresses looked like moved by the puzzle maker rather than cracked

Nope, look at the other transactions from those addresses, all are to the vanity addresses, quite long vanity... Someone must be found really fast way to brute-force the BC PBKs.

[digitalcitizen]

Has anyone tried to build this on Linux?

I have CUDA devices, and looked at the Makefile.  CUDA 9.2.  Installed that, but I'm not getting anything.  No errors, just no binaries.  The libraries seem to get built.  By default they go in CUR_DIR/bin CUR_DIR/lib.

Does anyone know what I can do to try and build the project on Linux?  As far as I know, there shouldn't be any real issues with differing CUDA versions 8 to 9.2.

Thanks,  looks interesting.  Nice rewards for trying the puzzles.  I wonder if there's a better method than just brute-forcing more and more?  Unless there is no point; they're just there to be claimed later as a measurement of compute power over the years and how quickly the BTC gets moved.  In that sense, not a real puzzle.  Just, how long until this gets cracked?

Interestingly, larger amounts have been claimed.  Ones in the middle not claimed yet.  Perhaps not worth the effort to figure out if there is a real method to the madness, or not enough reward for compute effort.

Thanks, if you've managed to compile on Ubuntu, and what did you have to tweak to get it working...

[Thirdspace]

Nope, look at the other transactions from those addresses, all are to the vanity addresses, quite long vanity... Someone must be found really fast way to brute-force the BC PBKs.

those vanity addresses are most likely burn addresses
such addresses can be generated without knowing their private keys
to proof my point, I just created these using a tool 
1Va1idAddressesCanBeCreatedupoTas
1WithoutKnowingPrivateKeyst2H8dDk

[Elliptic23]

I am not surprised the OP did a much better job than me with this What does surprise me is that the donation address is a 1x, I expected a Segwit address from such a sophisticated user. Or is it a case of his 1x address really being a Segwit or script of some kind, last year I remember researching you could translate a 3x to a 1x, but I cannot remember how

I am also not surprised  I cannot compile out of the box on my VS 2017, all kinds of errors. What does surprise me though is that some code in there, perhaps from the Cuda Toolkit, even tells me "this code will only work in VS 2010.... 2017", so it does not recognize my VS version, WTF!

This is a bug in CUDA. It doesn't know what the latest version of Visual Studio is. Edit <Your CUDA toolkit path>/9.2/include/crc/host_config.h so that the header matches your Visual Studio version. e.g.:

Code:

#if _MSC_VER < 1600 || _MSC_VER > 1911

becomes:

Code:

#if _MSC_VER < 1600 || _MSC_VER > 1915

[mechanikalk]

How hard would it be to be able to brute force find a private key from a seed phrase given some number of words?

I was on twitter recently and Jameson Lopp inadvertently revealed 17 of 24 words of a seed phrase by posting a picture of the back of his recovery phrases which he was burning.

https://twitter.com/mechanikalk/status/1062388232804069376

It is likely possible to intuit some information for the remaining 6 words that would drastically decrease the space. Jameson has stated that this is a 3 of 5 seed, so if that is true the money behind the account is safe.  However, finding the address would potentially dox Jameson's account which could be interesting.

[Elliptic23]

If it's a 2048 word list, then 6 words is 2048^6 = 2^66 possible combinations. Not impossible. That is just over 1 year at 2 trillion keys per second.

[almightyruler]

If it's a 2048 word list, then 6 words is 2048^6 = 2^66 possible combinations. Not impossible. That is just over 1 year at 2 trillion keys per second.

2 trillion keys per second?

Okay, so which state funded supercomputer shall we use to embarrass this guy?

[almightyruler]

If it's a 2048 word list, then 6 words is 2048^6 = 2^66 possible combinations. Not impossible. That is just over 1 year at 2 trillion keys per second.

Now, give us example of wallet which uses 6 words as seed mnemonic since AFAIK most wallet uses either 12, 18 or 24 words which means time required is far longer.

An earlier post states that 17 of the 24 words were revealed, so only 6 words need to be brute forced.

If the positions of the revealed words are known then you could recover up to 187 bits of the 256 bit key, and instead you would brute force the unknown bits.

[DevilOper]

Nope, look at the other transactions from those addresses, all are to the vanity addresses, quite long vanity... Someone must be found really fast way to brute-force the BC PBKs.

those vanity addresses are most likely burn addresses

Yes probably you are right but it's still highly doubtful the puzzle maker would do such transactions.

[almightyruler]

An earlier post states that 17 of the 24 words were revealed, so only 6 words need to be brute forced.

If the positions of the revealed words are known then you could recover up to 187 bits of the 256 bit key, and instead you would brute force the unknown bits.

Should've read the thread carefully, but there are 6 7 words need to be brute-forced.

Even if the position of 7 unknown words is known, it's still impossible as there's 1.25^44 possible combination if my calculation is right. (2048^7) * (17^17).
Jameson Lopp trying to make people understand why brute-force is impossible.

Oops, it is 7 unknown, not 6.

I agree that even when knowing the majority of the words, the chance of brute forcing the remaining bits to recover the complete key is infinitesimal.

Assuming 11 bits per word (2^11=2048), 17 known words means you have 187 bits of a 256 bit key already. That leaves 69 bits (2^69) to brute force.

If you were able to test 2^32 keys per second (an incredibly optimistic rate which assumes massive scale) it would still take 2^37 seconds to cover the entire search space... which is about 4358 years.

Things would be more complicated if you didn't know the positions of the words, as you would have to try the known 17 binary sequences in various locations, as well as brute forcing the remaining bits.

And if there's any key stretching involved the time taken to test each key, and therefore search the whole space, goes up by a significant amount.

Kind of cool that even if you know nearly 75% of a 256 bit private key, the chances of cracking it are still virtually zero.

[mechanikalk]

An earlier post states that 17 of the 24 words were revealed, so only 6 words need to be brute forced.

If the positions of the revealed words are known then you could recover up to 187 bits of the 256 bit key, and instead you would brute force the unknown bits.

Should've read the thread carefully, but there are 6 7 words need to be brute-forced.

Even if the position of 7 unknown words is known, it's still impossible as there's 1.25^44 possible combination if my calculation is right. (2048^7) * (17^17).
Jameson Lopp trying to make people understand why brute-force is impossible.

Oops, it is 7 unknown, not 6.

I agree that even when knowing the majority of the words, the chance of brute forcing the remaining bits to recover the complete key is infinitesimal.

Assuming 11 bits per word (2^11=2048), 17 known words means you have 187 bits of a 256 bit key already. That leaves 69 bits (2^69) to brute force.

If you were able to test 2^32 keys per second (an incredibly optimistic rate which assumes massive scale) it would still take 2^37 seconds to cover the entire search space... which is about 4358 years.

Things would be more complicated if you didn't know the positions of the words, as you would have to try the known 17 binary sequences in various locations, as well as brute forcing the remaining bits.

And if there's any key stretching involved the time taken to test each key, and therefore search the whole space, goes up by a significant amount.

Kind of cool that even if you know nearly 75% of a 256 bit private key, the chances of cracking it are still virtually zero.

From the https://github.com/bitcoin/bips/blob/71586487532d832ae4a3b0deae797d86ddebe3fc/bip-0039.mediawikiBIP39 github

This checksum is appended to the end of the initial entropy. Next, these concatenated bits are split into groups of 11 bits, each encoding a number from 0-2047, serving as an index into a wordlist. Finally, we convert these numbers into words and use the joined words as a mnemonic sentence.

It is indeed 6 words not 7.  Also, if any other information can be recovered on the additional 6 words, 1 letter, approximate length, etc. the 2048 list becomes much much smaller very quickly.  For example, if we know a word is 3 letters it goes to 100 options.  If we know it is 4-5 letters it turns into 1000 options. If we know it has a "w" it turns into 166. Therefore, the partial information should also be accounted for when calculating the difficulty.

[digitalcitizen]

Hi all,

I've been working on a tool for brute-forcing Bitcoin private keys.

.....

The performance is good, but can likely be improved. On my hardware (GeForce GT 640) it gets 9.4 million keys per second compressed, 7.3 million uncompressed.

....

Thoughts?


Thanks!

I tried to do this once, but never found anything. I tried those terms like "wallet" "bitcoin". I found some addresses which used to have balances, but not anymore. But I was doing manually, like 1 address/3 minutes lol

Haha! Yeah, I have tried very manual methods.  It's super hard now even when you have the "chainstate" i.e. addresses with balances, guaranteed at that point in time.  So you have to be quick.  It would be pure luck starting at some point and trying for a year and wrecking some GPUs to find a key I think.

Good grief, Bitcoin is plummeting right now.  Just checked my balance.  Oh well.  I hope it goes back up later... back to topic.

If you could somehow at the same time check if any of those 9.4 million keys/sec have any balance in btc/bch/btg etc...

It's coming (sort of).  It will be slow, so it will queue up a few to check over a few hours, a long time after brute-forcing, but only until some code to keep up with the chainstate is there.  It will still be slow, but it will work a lot better than thumping on a non-local API to get a balance.

And that entirely depends on a pull request later...

[timisis]

Can someone "donate" the address at some seed, eg the 0000.. seed? Since I could not compile, I could not extract with my own mod to the code.