BitCrack - A tool for brute-forcing private keys

[Grantrocks]

I made a Web Tool to scan for the keys. https://newbtcbruterandom.grantrocks.repl.co its a random btc key checker (this one is new and it uses all possible cores on your cpu-1 so that it can update the gui). It features a select tool so that all you have to do is choose a puzzle that is somewhat possible to get randomly and click start. I get about 100000 keys per thread on a AMD Ryzen 7 5700G running at 4.4Ghz. I use 14 threads. so thats about 1.4 Million keys every 20 seconds that are randomly checked. Its also focused on performance and im constantly updating it. Please leave some feedback for me so i know where and how to improve. Im currently trying to speed up the hashing so any help with that would be much appreciated!

I also made a non random scanner https://32btcbrute.grantrocks.repl.co to scan for specified btc puzzles. this one is quite fast and allows you to customize where to search.


EDIT
im hoping to use a lib like gpu.js in the future to greatly speed up the tool. However i have no idea how to do this and it will take me a while to figure out.

[Grantrocks]

Meanwhile, #66 is chilling out and waiting for someone to find it, or maybe it will be found so quickly just like the other two in rapid succession.

Someone is really throwing good hardware at this challenge.

this is totaly out of the blue btw but i agree with defending PoW. People are trying to use renewable enrgey so that they can earn more for not paying/paying as much for electricity

[digaran]

Make a new thread, note that CPU is useless for this purpose.

[brainless]

I made a Web Tool to scan for the keys. https://newbtcbruterandom.grantrocks.repl.co its a random btc key checker (this one is new and it uses all possible cores on your cpu-1 so that it can update the gui). It features a select tool so that all you have to do is choose a puzzle that is somewhat possible to get randomly and click start. I get about 100000 keys per thread on a AMD Ryzen 7 5700G running at 4.4Ghz. I use 14 threads. so thats about 1.4 Million keys every 20 seconds that are randomly checked. Its also focused on performance and im constantly updating it. Please leave some feedback for me so i know where and how to improve. Im currently trying to speed up the hashing so any help with that would be much appreciated!

I also made a non random scanner https://32btcbrute.grantrocks.repl.co to scan for specified btc puzzles. this one is quite fast and allows you to customize where to search.


EDIT
im hoping to use a lib like gpu.js in the future to greatly speed up the tool. However i have no idea how to do this and it will take me a while to figure out.

in your search scripts, you have mistakes, by mistake or you know why ?

value="0x20000000000000000:0x3ffffffffffffffff:D7F207850C19B7B763B10D0A1AB049CF466B8FAE">Puzzle #66
value="0x40000000000000000:0x7ffffffffffffffff:739437BB3DD6D1983E66629C5F08C70E52769371">Puzzle #67

for puzzle 66, you mention hash160 for search is about pre define privatekey is for 0x20000000000000000
for puzzle 67, hash160, OK, but have lot of other mistakes inside your scripts, so dont try to waste time your self and others
correct all mistakes and get proved by testing professionals, and then launch your subject
thankx

[NotATether]

Meanwhile, #66 is chilling out and waiting for someone to find it, or maybe it will be found so quickly just like the other two in rapid succession.

Someone is really throwing good hardware at this challenge.

this is totaly out of the blue btw but i agree with defending PoW. People are trying to use renewable enrgey so that they can earn more for not paying/paying as much for electricity

Actually you just gave me a idea haha. What if people plugged their GPUs into a renewable energy source while cracking the keys so that they save on electricity fees?

BTC being at $23,000 currently, the rewards gained recently were around $10K or two each, but I wonder how much electricity they had to pay to achieve this? Nevermind the initial hardware investment as it's a 1 time thing.

[cixegz]

https://www.blockchain.com/explorer/addresses/btc/17s2b9ksz5y7abUm92cHwG8jEPCzK3dLnT

120 puzzle solved....

so, send the private key
who solved ? which tools useing to crack keyhunt or BitCrack

[NotATether]

https://www.blockchain.com/explorer/addresses/btc/17s2b9ksz5y7abUm92cHwG8jEPCzK3dLnT

120 puzzle solved....

so, send the private key
who solved ? which tools useing to crack keyhunt or BitCrack

Nobody knows the private key except the guy who solved it. And there's nothing to force them to go to bitcointalk (or anywhere else) and post it here. What I do know, is that it wasn't someone from this forum.

[citb0in]

What I do know, is that it wasn't someone from this forum.

How can you know that ?

[NotATether]

What I do know, is that it wasn't someone from this forum.

How can you know that ?

Because I had my bets that they'd be celebrating about it on this thread by now if that were the case. Pretty safe educated guess to make if you ask me.

[citb0in]

I see it exactly the opposite way. There are numerous reasons why the true and happy finder would never want to disclose this information here in the forum, if this person is active here in the forum at all. I even claim that there are more logical reasons to hide it than to hang it on the big bell and supposedly brag about it.

This assumption can also be reflected analogously to a block find where a solo miner collects the reward but wants to remain anonymous. There are dozens of reasons for that.

[WanderingPhilospher]

What I do know, is that it wasn't someone from this forum.

How can you know that ?

Because I had my bets that they'd be celebrating about it on this thread by now if that were the case. Pretty safe educated guess to make if you ask me.

I would agree. If they are a regular in the discussion of this challenge, they'd at least let peeps know the priv key once all forks have been taken care of, especially if they follow on here and know people like to know the priv keys to try and "create" a pattern with the challenges.
Also, if it's somebody not on this forum, it seems like they would at least come forward (on some venue) as this is a new world record. Maybe sooner or later they will. Time will tell...

[GoldTiger69]

I see it exactly the opposite way. There are numerous reasons why the true and happy finder would never want to disclose this information here in the forum, if this person is active here in the forum at all. I even claim that there are more logical reasons to hide it than to hang it on the big bell and supposedly brag about it.

This assumption can also be reflected analogously to a block find where a solo miner collects the reward but wants to remain anonymous. There are dozens of reasons for that.

Maybe this person can tell us who found #120: https://bitcointalk.org/index.php?action=profile;u=1285555  (just a hunch)

[garlonicon]

I wonder if keys were generated by some deterministic wallet first, and then truncated to N bits. Because in that case, it could be possible to recover the master key, and then sweep coins from all of them, while it would not mean that ECDSA is broken (because HD keys could be non-hardened).

[digaran]

I wonder if keys were generated by some deterministic wallet first, and then truncated to N bits. Because in that case, it could be possible to recover the master key, and then sweep coins from all of them, while it would not mean that ECDSA is broken (because HD keys could be non-hardened).

Wonder no more big man, if you could find and sweep them all don't forget us, we're strongly outnumbered group of puzzle hunters with our primitive hardware licking the tip of the iceberg hoping to melt it down, lol.
"Care & share" you know? 😉

https://bitcointalk.org/index.php?topic=1306983.msg18765941#msg18765941

[Trancefan]

What does masked with leading 000...0001 to set difficulty mean? I mean how would someone add that to a program?

[WanderingPhilospher]

What does masked with leading 000...0001 to set difficulty mean? I mean how would someone add that to a program?

It means they were able to set the bit range "difficulty" by masking the leading characters of the private key.

JLPs Kangaroo program does it like this:

Code:

if(dpSize > 256) dpSize = 256;
    dMask = (1ULL << (256 - dpSize)) - 1;
    dMask = ~dMask;

Now that is for distinguished points, but the concept is the same.

So if you run a -dp of say 40, then the leading 10 characters (of the xpoint) would be 0s (zeros). I imagine it would be easy to implement something similar in wallet software or a script to generate private keys, and change the masking to mask the leading characters of the private key.

[garlonicon]

A few words about the puzzle.  There is no pattern.  It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty).  It is simply a crude measuring instrument, of the cracking strength of the community.

That changes a lot. Because using totally random key every time would be harder to crack than some deterministic wallet. Now, the big question is: which deterministic wallet was used? Because there are some of them, and they use different algorithms to derive keys.

To better illustrate, why cracking some deterministic wallet may be easier, consider this example: we start from the master private key, and then we use addition to derive keys. We use some hash that contains the master public key, and some nonce, representing the index of our child key. What does it mean in that case?

For example, a very simple, but unsafe method, is to use "childKey=masterKey+SHA-256(masterPubKey||index)", in practice something stronger is used in real implementations, but let's start from that. Then, by inspecting revealed private and public keys, it is possible to focus on that master key, instead of trying to crack child keys alone. Also note that all public keys from 160-256 range are revealed, we can assume that those keys also follow the pattern. And even if there are no coins, then still, we can use those public keys as an additional information in our algorithms.

Let's assume that our masterKey is equal to SHA-256("master"), just to have some deterministic-but-randomly-looking hash to work with:

Code:

SHA-256("master")=fc613b4dfd6736a7bd268c8a0e74ed0d1c04a959f59dd74ef2874983fd443fc9
masterPubKey=028B9C3A3CBE772731BAF46F35CF3F2A5E96F32725F7FC3F43165B5DB18EAEAA13
index=0x00000000
SHA-256(028B9C3A3CBE772731BAF46F35CF3F2A5E96F32725F7FC3F43165B5DB18EAEAA1300000000)=4723005bf4956bc7c135caa5c1bda0fd0cd6d37de2cfbfd66c0aed31ac32da3b
mask=(1<<0)=0000000000000000000000000000000000000000000000000000000000000001
firstKey=mask+(childKey%mask)
firstKey=0000000000000000000000000000000000000000000000000000000000000001

Then, we can go further and further, by trying to generate child keys, and checking how close we are to the keys from the puzzle. For example, the first 10 keys from this example, looks like that:

Code:

child0=4723005bf4956bc7c135caa5c1bda0fd0cd6d37de2cfbfd66c0aed31ac32da3b
mask0=0000000000000000000000000000000000000000000000000000000000000001
puzzle0=0000000000000000000000000000000000000000000000000000000000000001

child1=11077a18f7bcf2c2f572e07bcaa2e808157efc25dd80123000b1eb0612e4dd00
mask1=0000000000000000000000000000000000000000000000000000000000000002
puzzle1=0000000000000000000000000000000000000000000000000000000000000002

child2=70604aac4e4b6488567526d8c5ca59ef99d2e6a8cdb168be06b4413e3f96ebc4
mask2=0000000000000000000000000000000000000000000000000000000000000004
puzzle2=0000000000000000000000000000000000000000000000000000000000000004

child3=54195d0cb0683a71a007141d90a20bb4648c6aae075165cadb6742cb272e7f9a
mask3=0000000000000000000000000000000000000000000000000000000000000008
puzzle3=000000000000000000000000000000000000000000000000000000000000000a

child4=ec2c3fce8b21ffca469f5f5748141eb754fabe2640643c59b9a34512c3c33777
mask4=0000000000000000000000000000000000000000000000000000000000000010
puzzle4=0000000000000000000000000000000000000000000000000000000000000017

child5=48ef0d29d9416db21ba741074e816b6d8e6935a1de2c96d3dbf41012812c13d3
mask5=0000000000000000000000000000000000000000000000000000000000000020
puzzle5=0000000000000000000000000000000000000000000000000000000000000033

child6=563b062080afa9baf038b4fbb930660e8a255e99ef3c597368dc7df2a2adc0c6
mask6=0000000000000000000000000000000000000000000000000000000000000040
puzzle6=0000000000000000000000000000000000000000000000000000000000000046

child7=b9d4d7680493db643e3158e05899d10a8c878a385a297aac8e97cc5abcb7d4b9
mask7=0000000000000000000000000000000000000000000000000000000000000080
puzzle7=00000000000000000000000000000000000000000000000000000000000000b9

child8=bcd20822e9da2938100576f22c9ed21d9a70689cb691a61c567bd046f665fdfb
mask8=0000000000000000000000000000000000000000000000000000000000000100
puzzle8=00000000000000000000000000000000000000000000000000000000000001fb

child9=9b27d4fbbcc9f9359f2b82f9cc16b5d485a169f4ccdc93b07d837e40be7e8144
mask9=0000000000000000000000000000000000000000000000000000000000000200
puzzle9=0000000000000000000000000000000000000000000000000000000000000344

And then, we can compare our example with real keys:

Code:

real=0001, fake=0001
real=0003, fake=0002
real=0007, fake=0004
real=0008, fake=000a
real=0015, fake=0017
real=0031, fake=0033
real=004c, fake=0046
real=00e0, fake=00b9
real=01d3, fake=01fb
real=0202, fake=0344

And there is more: there is no need to brute force every combination here. If we assume some kind of algorithm, we can make optimizations just for that. So, if we assume that keys are added to the master key, and if mask is calculated with modulo and sum, then we can check selected keys, and create requirements for that master key.

For example, modulo addition, and modulo multiplication, has a nice property, that we can use any order. So, if we have "a+b", or "b+a", then "(a+b)%n" and "(b+a)%n" is also the same. We can also use those rules for multiplication. Then, we don't have to check every single master private key. We can simply assume that if keys are added, then the master key modulo N is in a given range. Then, we can create specific master keys, and skip many of them.

[digaran]

Also note that all public keys from 160-256 range are revealed,

Not only 160-256 but also 65-70-75-80-85-90-95-100-105-110-115-120 all have been solved, and up to 160 every 5 puzzles have their public keys revealed.

[zahid888]

A few words about the puzzle.  There is no pattern.  It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty).  It is simply a crude measuring instrument, of the cracking strength of the community.

That changes a lot. Because using totally random key every time would be harder to crack than some deterministic wallet. Now, the big question is: which deterministic wallet was used? Because there are some of them, and they use different algorithms to derive keys.

To better illustrate, why cracking some deterministic wallet may be easier, consider this example: we start from the master private key, and then we use addition to derive keys. We use some hash that contains the master public key, and some nonce, representing the index of our child key. What does it mean in that case?

For example, a very simple, but unsafe method, is to use "childKey=masterKey+SHA-256(masterPubKey||index)", in practice something stronger is used in real implementations, but let's start from that. Then, by inspecting revealed private and public keys, it is possible to focus on that master key, instead of trying to crack child keys alone. Also note that all public keys from 160-256 range are revealed, we can assume that those keys also follow the pattern. And even if there are no coins, then still, we can use those public keys as an additional information in our algorithms.

Let's assume that our masterKey is equal to SHA-256("master"), just to have some deterministic-but-randomly-looking hash to work with:

Code:

SHA-256("master")=fc613b4dfd6736a7bd268c8a0e74ed0d1c04a959f59dd74ef2874983fd443fc9
masterPubKey=028B9C3A3CBE772731BAF46F35CF3F2A5E96F32725F7FC3F43165B5DB18EAEAA13
index=0x00000000
SHA-256(028B9C3A3CBE772731BAF46F35CF3F2A5E96F32725F7FC3F43165B5DB18EAEAA1300000000)=4723005bf4956bc7c135caa5c1bda0fd0cd6d37de2cfbfd66c0aed31ac32da3b
mask=(1<<0)=0000000000000000000000000000000000000000000000000000000000000001
firstKey=mask+(childKey%mask)
firstKey=0000000000000000000000000000000000000000000000000000000000000001

Then, we can go further and further, by trying to generate child keys, and checking how close we are to the keys from the puzzle. For example, the first 10 keys from this example, looks like that:

Code:

child0=4723005bf4956bc7c135caa5c1bda0fd0cd6d37de2cfbfd66c0aed31ac32da3b
mask0=0000000000000000000000000000000000000000000000000000000000000001
puzzle0=0000000000000000000000000000000000000000000000000000000000000001

child1=11077a18f7bcf2c2f572e07bcaa2e808157efc25dd80123000b1eb0612e4dd00
mask1=0000000000000000000000000000000000000000000000000000000000000002
puzzle1=0000000000000000000000000000000000000000000000000000000000000002

child2=70604aac4e4b6488567526d8c5ca59ef99d2e6a8cdb168be06b4413e3f96ebc4
mask2=0000000000000000000000000000000000000000000000000000000000000004
puzzle2=0000000000000000000000000000000000000000000000000000000000000004

child3=54195d0cb0683a71a007141d90a20bb4648c6aae075165cadb6742cb272e7f9a
mask3=0000000000000000000000000000000000000000000000000000000000000008
puzzle3=000000000000000000000000000000000000000000000000000000000000000a

child4=ec2c3fce8b21ffca469f5f5748141eb754fabe2640643c59b9a34512c3c33777
mask4=0000000000000000000000000000000000000000000000000000000000000010
puzzle4=0000000000000000000000000000000000000000000000000000000000000017

child5=48ef0d29d9416db21ba741074e816b6d8e6935a1de2c96d3dbf41012812c13d3
mask5=0000000000000000000000000000000000000000000000000000000000000020
puzzle5=0000000000000000000000000000000000000000000000000000000000000033

child6=563b062080afa9baf038b4fbb930660e8a255e99ef3c597368dc7df2a2adc0c6
mask6=0000000000000000000000000000000000000000000000000000000000000040
puzzle6=0000000000000000000000000000000000000000000000000000000000000046

child7=b9d4d7680493db643e3158e05899d10a8c878a385a297aac8e97cc5abcb7d4b9
mask7=0000000000000000000000000000000000000000000000000000000000000080
puzzle7=00000000000000000000000000000000000000000000000000000000000000b9

child8=bcd20822e9da2938100576f22c9ed21d9a70689cb691a61c567bd046f665fdfb
mask8=0000000000000000000000000000000000000000000000000000000000000100
puzzle8=00000000000000000000000000000000000000000000000000000000000001fb

child9=9b27d4fbbcc9f9359f2b82f9cc16b5d485a169f4ccdc93b07d837e40be7e8144
mask9=0000000000000000000000000000000000000000000000000000000000000200
puzzle9=0000000000000000000000000000000000000000000000000000000000000344

And then, we can compare our example with real keys:

Code:

real=0001, fake=0001
real=0003, fake=0002
real=0007, fake=0004
real=0008, fake=000a
real=0015, fake=0017
real=0031, fake=0033
real=004c, fake=0046
real=00e0, fake=00b9
real=01d3, fake=01fb
real=0202, fake=0344

And there is more: there is no need to brute force every combination here. If we assume some kind of algorithm, we can make optimizations just for that. So, if we assume that keys are added to the master key, and if mask is calculated with modulo and sum, then we can check selected keys, and create requirements for that master key.

For example, modulo addition, and modulo multiplication, has a nice property, that we can use any order. So, if we have "a+b", or "b+a", then "(a+b)%n" and "(b+a)%n" is also the same. We can also use those rules for multiplication. Then, we don't have to check every single master private key. We can simply assume that if keys are added, then the master key modulo N is in a given range. Then, we can create specific master keys, and skip many of them.

This can be a significant step. All we need to know which wallets were trending at that time of the transaction and how they derived the private key.

[Robert_BIT]

I see it exactly the opposite way. There are numerous reasons why the true and happy finder would never want to disclose this information here in the forum, if this person is active here in the forum at all. I even claim that there are more logical reasons to hide it than to hang it on the big bell and supposedly brag about it.

This assumption can also be reflected analogously to a block find where a solo miner collects the reward but wants to remain anonymous. There are dozens of reasons for that.

I tend to agree. For quite some time I've been coming here every now and then to check on any progress and play around with Kangaroos and BitCracks

In the event that I could come up with a solution, I would prefer to keep a low profile. For a while, at least as I devote my attention to resolving the next problem in line - in this case, #125.

But more importantly than 'who did it?', let's not forget, are the fundamentals of this challenge (incorrectly referred to as a puzzle).

These principles should be the basis for all of our efforts, and for all of our discussions here. As stated in the creator's post: "It is simply a crude measuring instrument, of the cracking strength of the community. "

The reference to "community" was interesting in that it could be interpreted as an invitation for more minds to collaborate in order to solve whatever can be solved. This is also hinted at in this line:

"Finally, I wish to express appreciation of the efforts of all developers of new cracking tools and technology."

We could argue that this "community" spirit hinted at by the creator has faded. Not disappeared, but faded.

Almost everyone seems to be in it for their own benefit. This includes the undersigned...

Moreover, the recent resolution of #120 without sharing the good news only heightens a feeling of individualism instead of a sense of community.

Sorry if I offended anyone. This post is intended solely as a reminder of the importance of returning to the basics. For all of us to remember, why was this challenge even started in the first place?

I personally do not believe it was intended to test the overall strength of the blockchain or bitcoin encryption. There are scientists who use very powerful hardware in very advanced laboratories who have been testing encryption challenges for years. And they do not usually visit forums in order to share their findings, primarily due to security concerns.

Just my two cents...