BitCrack - A tool for brute-forcing private keys

[digaran]

Were you in a cave for the last couple of years? I mean my old laptop with a low end GPU can eat 30MK/s, now you want us to chew 17 Mk in a day? Wasn't it enough that with trillions of keys per second we'd still be years from finding 66, now we have to keep searching till the sun dies off into darkness.🤣

Keep at it though, every person is an asset ( to share our desperation and despair). Sigh. Lol

[negate7o4]

Were you in a cave for the last couple of years? I mean my old laptop with a low end GPU can eat 30MK/s, now you want us to chew 17 Mk in a day? Wasn't it enough that with trillions of keys per second we'd still be years from finding 66, now we have to keep searching till the sun dies off into darkness.🤣

Keep at it though, every person is an asset ( to share our desperation and despair). Sigh. Lol

Buddy this is a cpu only script at the moment and building on it, as Bitcrack is not working on any improvement. Yeah it does 16 Mil per thread, at 8 thread rig it should do 128 Mil per day, my server does about 512 Mil per process, but only run 1 at time as I need server to do allot of other stuff to.
Running 5 X processes of above that peaks by cpu at 80% gives me 128 x 5 Mil per day

If you think you can optimize the code to check faster, then try.

And will update the code to use GPU and CPU hopefully soon, just ironing some cuda bugs.
I did tests with bitcrack where I gave it 1 Bil keys to check with a correct one in these large ranges. It missed to match it, thinking due to same bug i'm having with cudo cores splitting the decimal processing when working with these large decimals.

With what 800 quad quadrillions possibilities your talking 100 of thousands of years, that is if you check from bottom to top, randomly is another ball game, as random numbers can repeat, but at least you have a fat chance in hell as who has a few millions years to check from top to bottom?

My data in my sheet in github did however reveal an interesting pattern. The decimals of all the private keys of every puzzle are within 12% to 49% of the base decimal (range)
So if the pattern repeats with next puzzles you can only check this above decimal ranges

I have a script currently doing that, just get the decimal of the private key :
current_decimal = int.from_bytes(bytes.fromhex(key.private_hex), 'big')
Check if is in range 12 - 49%, if not, no need to waste processing and checking it against public key
this however just gives me a 11 500 X 1.2 boost per thread per second

When I get the gpu part working I will also work on a reversed engineered sha256 function, we know the public key is generated by the private key, and we know the public key. So maybe we can find a formula to exclude a large list of the private keys to check that will never resolve to certain characters in the public key

Lastly I was thinking of doing a database of checked keys to, but to check database will slow it down, but if multiple rigs update it, might lead to someone finding it faster. Seems bit unfair as only someone will get the spoils even if it is a team effort and concerned that this will lead to poeple raping my server that hosts the what 80 gig database in the end

Also in my sheet I was hoping their is a pattern in the decimal multiplier from one puzzle to the next :

y = base high / decimal
x > y
z = x - y
x = z + y
x = x

So if they had a method to determine the next puzzle, a solution could be to find the x multiplier, but so far, I've not been able to find it

[digaran]

It is important to note that brute-forcing Bitcoin private keys is not a legal activity and is also not ethical. The tool you have created can be used for illegal activities such as stealing funds from individuals or organizations, and it can also be used for unethical purposes such as compromising the security and privacy of individuals. Therefore, it is important to use your skills and knowledge for ethical and legal purposes only.

It's time to leave the basement and join the outside world, bitcoin is an open source technology using a publicly accessible elliptic curve, whole point of using EC is due to the difficulty of finding randomly generated big private keys.

However to demonstrate how difficult it actually is, allegedly @Satoshi himself organized a series of puzzles placing bitcoins in extremely easy bit ranges and after some times some people figured it out and started  to post     topics about the subject, it was originally around 32 bitcoins, then it was increased to 100, and  2 weeks ago he added around 900 more bitcoins totalling around 1000 BTC as a prize for solvers. It has been done with consent and is totally legal.

Do also note that brute forcing any large private key will take billions of years, and brute forcing a small key in a very very small range will take decades with many high end GPUs.

Further more, all the available "cracking" tools are inefficient as they are just not enough to pose any threat.

Ps, around these woods we operate by bit and x,y, we are alien to terms such as ethics. Lol.😉

[Flexystar]

I never thought bitcoin/blockchain technology will see a day where people are making efforts to brute force the only technology that we need to keep the way it is or just improve on the sides of network adoption, feasibility in terms of fees, p2p and KYC free adoption. This should be the development we need to have right now and not the other way around.

I see some negative implications of this idea. Irrespective of what others think I don’t like the idea of having brute force technology. It would be obvious that soon others will copy it and start misusing the same for their own benefit. Not sure if this is only for one time use but it’s bad idea.

By just reading it I’m frightened about my wallet security. Lolz.

[mohamadrp56]

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!

what I am going to say is purely theoretical, as I have never tried to brute force private keys.

I don´t think you will have any success doing this.
If you have enough hash power, you would probably make more money working as an honest node, mining.

Bitcoin protocol is secure enough. If it were brute force-able, bitcoin wouldn't be worth anything.

What i think you could do is to find a collision. If someone made an insecure private key, by just hashing some passphrase... maybe you could have some luck. 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

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

But I don't think any of that will work, and will be a waste of time and resources.

[digaran]

I never thought bitcoin/blockchain technology will see a day where people are making efforts to brute force the only technology that we need to keep the way it is or just improve on the sides of network adoption, feasibility in terms of fees, p2p and KYC free adoption. This should be the development we need to have right now and not the other way around.

I see some negative implications of this idea. Irrespective of what others think I don’t like the idea of having brute force technology. It would be obvious that soon others will copy it and start misusing the same for their own benefit. Not sure if this is only for one time use but it’s bad idea.

By just reading it I’m frightened about my wallet security. Lolz.

First off, Doing this publicly will warn everyone about possible vulnerabilities and weaknesses, demonstrating to the world how we can find the keys of low range and exposed public keys will send the signal to everyone that they need to use standard and secure wallets to generate keys with high entropy and also never use an address more than once.

On the other hand, there are hundreds of thousands of bitcoins on exposed keys for years, nobody has managed to touch them.
If you want to be 100% assured of the safety of your coins, just store them on an address and when you are spending, don't use the same address as the return address, done and safe for a few billion years.😉

[citb0in]

My data in my sheet in github did however reveal an interesting pattern. The decimals of all the private keys of every puzzle are within 12% to 49% of the base decimal (range)

how do you come up with this false claim? please show us the decimal value of the relative position for puzzles 38 and 60 as an example. And then... Well, what do you find ?

[User_EKB]

Needs too much effort more then guessing 256 bit key 
[/quote]

I read your posts on the forum.  If you take the last digits of any private key and go through the entire range, you will find the key
check this
-b 64 -t 512 -p 1600 --keyspace 7FFFFFFFFF9112D4:FFFFFFFFFFFFFFFF 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN --stride 1000000
-b 64 -t 512 -p 1600 --keyspace FFFFFFFFF5B26867:1FFFFFFFFFFFFFFFF 18ZMbwUFLMHoZBbfpCjUJQTCMCbktshgpe  --stride 10000000
zahid888 i think you are on the right track
you for 66 you need to find 7 digitsneed to look in the starting range 0-9  A-F = full brute force 16^7

I don't know how to speed it up



[2023-06-19.21:22:02] [Info] Compression : compressed
[2023-06-19.21:22:02] [Info] Starting at : 000000000000000000000000000000000000000000000001FFFFFFFFF0000A18 (65 bit)
[2023-06-19.21:22:02] [Info] Ending at   : 000000000000000000000000000000000000000000000003FFFFFFFFFFFFFFFF (66 bit)
[2023-06-19.21:22:02] [Info] Range       : 000000000000000000000000000000000000000000000002000000000FFFF5E7 (66 bit)
[2023-06-19.21:22:02] [Info] Initializing NVIDIA GeForce RTX 3080
[2023-06-19.21:22:02] [Info] Generating 52,428,800 starting points (2000.0MB)
[2023-06-19.21:22:05] [Info] 10.0%  20.0%  30.0%  40.0%  50.0%  60.0%  70.0%  80.0%  90.0%  100.0%
[2023-06-19.21:22:07] [Info] Done
[DEV: NVIDIA GeForce R 9156/10239MB] [0000000000000000000000000000000000000000000000036A7FFFFFF0000A18 (66 bit)] [INC: 0, 0] [TARGET: 1] [SPEED: 1663.50 MKey/s] [TOTAL: 6,081,740,800] [00:00:01][2023-06-19.21:22:12] [Info] Reached end of keyspace


[2023-06-19.21:22:13] [Info] Compression : compressed
[2023-06-19.21:22:13] [Info] Starting at : 000000000000000000000000000000000000000000000001FFFFFFFFF0000A19 (65 bit)
[2023-06-19.21:22:13] [Info] Ending at   : 000000000000000000000000000000000000000000000003FFFFFFFFFFFFFFFF (66 bit)
[2023-06-19.21:22:13] [Info] Range       : 000000000000000000000000000000000000000000000002000000000FFFF5E6 (66 bit)
[2023-06-19.21:22:13] [Info] Initializing NVIDIA GeForce RTX 3080
[2023-06-19.21:22:13] [Info] Generating 52,428,800 starting points (2000.0MB)
[2023-06-19.21:22:16] [Info] 10.0%  20.0%  30.0%  40.0%  50.0%  60.0%  70.0%  80.0%  90.0%  100.0%
[2023-06-19.21:22:18] [Info] Done
[DEV: NVIDIA GeForce R 9156/10239MB] [00000000000000000000000000000000000000000000000370BFFFFFF0000A19 (66 bit)] [INC: 0, 0] [TARGET: 1] [SPEED: 1691.25 MKey/s] [TOTAL: 6,186,598,400] [00:00:01][2023-06-19.21:22:23] [Info] Reached end of keyspace


[2023-06-19.21:22:23] [Info] Compression : compressed
[2023-06-19.21:22:23] [Info] Starting at : 000000000000000000000000000000000000000000000001FFFFFFFFF0000A1A (65 bit)
[2023-06-19.21:22:23] [Info] Ending at   : 000000000000000000000000000000000000000000000003FFFFFFFFFFFFFFFF (66 bit)
[2023-06-19.21:22:23] [Info] Range       : 000000000000000000000000000000000000000000000002000000000FFFF5E5 (66 bit)
[2023-06-19.21:22:23] [Info] Initializing NVIDIA GeForce RTX 3080
[2023-06-19.21:22:24] [Info] Generating 52,428,800 starting points (2000.0MB)
[2023-06-19.21:22:27] [Info] 10.0%  20.0%  30.0%  40.0%  50.0%  60.0%  70.0%  80.0%  90.0%  100.0%
[2023-06-19.21:22:29] [Info] Done
[DEV: NVIDIA GeForce R 9156/10239MB] [0000000000000000000000000000000000000000000000036D9FFFFFF0000A1A (66 bit)] [INC: 0, 0] [TARGET: 1] [SPEED: 1663.50 MKey/s] [TOTAL: 6,134,169,600] [00:00:01][2023-06-19.21:22:34] [Info] Reached end of keyspace

[holy_ship]

who solved ? which tools useing to crack keyhunt or BitCrack

Very unlikely that it was bitcrack. This magic kangaroo stuff is.

I wonder of RAM requirements for 120 puzzle. Who's next p66 or p125? )

[kewa07]

tell me, is it possible to use bitcrack for Ethereum?

[nc50lc]

tell me, is it possible to use bitcrack for Ethereum?

No.
It's mainly developed for the puzzle transaction which is Bitcoin-exclusive.
Example:

Code:

clbitcrack 0x0123

Result:

Code:

[Error] Invalid address '0x0123'

What's your goal anyways, depending on it, I may know an alternative that'll work in Ethereum.

[neirobobi]

tell me, is it possible to use bitcrack for Ethereum?

you need AltCrack

[neirobobi]

Hey people!
I'm using BitCrack/AltCrack to find 66, but it only searches consecutively through 1 or some other number. Tell me if there is a program that can search for 66 puzzles by sorting through all the range options by mask.

for example this mask (decimal): XXXXXX123456XXXXXXXX

Now I have to run Altcrack 368,935 times consecutively to check the range for this mask, but this is very long. Is there any other way?

[kewa07]

tell me, is it possible to use bitcrack for Ethereum?

you need AltCrack

does it work with ethereum? you need hash160, and the ether address is created differently

[NotATether]

tell me, is it possible to use bitcrack for Ethereum?

you need AltCrack

does it work with ethereum? you need hash160, and the ether address is created differently

No, it does not.

ETH addresses take the Keccak (often mistaken for SHA-3 - they are NOT the same!) hash of the SHA-256 hash of the public key, they don't use hash160 at all.

Hey people!
I'm using BitCrack/AltCrack to find 66, but it only searches consecutively through 1 or some other number. Tell me if there is a program that can search for 66 puzzles by sorting through all the range options by mask.

for example this mask (decimal): XXXXXX123456XXXXXXXX

Now I have to run Altcrack 368,935 times consecutively to check the range for this mask, but this is very long. Is there any other way?

Altcrack is for finding the private keys of Bitcoin-like addresses such as Namecoin, Litecoin, Doge, Dash etc. Frankly, you will be spending more time programming the calculation of the version bytes and stuff like that with Altcrack, so unless it has a massive speed optimization, it's better to just stick with Bitcrack.

[nomachine]

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

Interesting puzzle, I checked for patterns between binary values, decimal values, floor values. Just cant find anything

I updated an excel sheet puzzle bitcoin.xlsx with allot more data of each puzzle. Like decimal, binary, floor, and allot more data per puzzle. Even multipliers of the data to the next puzzle.

Since this range is just so huge, I think a random generator would maybe work best to try and find the needle.

I attached below my python script trying the next puzzle randomly if someone might benefit to

https://github.com/negate7o4/Bitcoin-Puzzle

On my rig, I7 if I run 5 X instances, it checks about 11 500 possibilities per second per thread, but eats 80% cpu. So the code chews threw 16.5 Mil random possibilities per day

If you want to try a different puzzle, just change these values in the script :

address = '1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF'

start_key = '0000000000000000000000000000000000000000000000040000000000000000' stop_key = '000000000000000000000000000000000000000000000007ffffffffffffffff'

Also take note of the cpu threads the code uses, update according to your threads.

Their is also a text file in my repository of the correct pip's you need to install for the code to work

We can utilize multiprocessing instead of threading. Multiprocessing allows us to take advantage of multiple CPU cores and achieve better parallelism. Also, we can optimize the search_for_key function by reducing unnecessary calculations within the loop.  There is a potential bottleneck that can be accelerated. The bottleneck lies in the line where a random integer is generated using os.urandom(32).  We can generate a batch of random numbers in advance and use these numbers in the search_for_key function instead of generating a new random number for each iteration.

Code:

import os
import multiprocessing as mp
from gmpy2 import mpz, powmod
from bitcoinlib.encoding import addr_to_pubkeyhash, to_hexstring
from bitcoinlib.keys import HDKey
from ecdsa import SigningKey, SECP256k1

def save_key_to_file(private_hex: str):
    with open(f"{private_hex}.txt", "w") as f:
        f.write(private_hex)

def generate_random_numbers(num_numbers):
    return [os.urandom(32) for _ in range(num_numbers)]

def search_for_key(start_key_int, stop_key_int, target_address, attempts_per_process, random_numbers):
    for i in range(attempts_per_process):
        current_key_int = mpz(powmod(int.from_bytes(random_numbers[i], 'big'), 1, stop_key_int - start_key_int)) + start_key_int
        ecdsa_private_key = SigningKey.from_secret_exponent(int(current_key_int), curve=SECP256k1)
        key = HDKey(key=ecdsa_private_key.to_string())

        if key.address() == target_address:
            save_key_to_file(key.private_hex)
            print(f"Private key found: {key.private_hex}")
            return key
    return None

def search_in_range(start_key_int, stop_key_int, target_address, attempts_per_process, random_numbers):
    process_start_key_int = mpz(powmod(int.from_bytes(random_numbers[0], 'big'), 1, stop_key_int - start_key_int)) + start_key_int
    process_stop_key_int = (process_start_key_int + attempts_per_process) % stop_key_int
    search_for_key(process_start_key_int, process_stop_key_int, target_address, attempts_per_process, random_numbers)

if __name__ == "__main__":
    address = '1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF'

    start_key = '0000000000000000000000000000000000000000000000040000000000000000'
    stop_key = '000000000000000000000000000000000000000000000007ffffffffffffffff'
    start_key_int = mpz(start_key, 16)
    stop_key_int = mpz(stop_key, 16)

    attempts_per_process = 2000000
    num_processes = 8

    random_numbers = generate_random_numbers(attempts_per_process * num_processes)

    processes = []
    for _ in range(num_processes):
        process = mp.Process(target=search_in_range, args=(start_key_int, stop_key_int, address, attempts_per_process, random_numbers))
        processes.append(process)
        process.start()

    for process in processes:
        process.join()

    print(f"Private key not found in the given range after {num_processes * attempts_per_process} attempts.")

But no matter how you turn it and perfect it, it takes a couple of million years to reach the result.

[ripemdhash]

why u use external library ?

it is your bottleneck.

you are comparing addres with address.

it means : additional you do:

Sha256 + sha256 for checksum.

?

better:
get target and change for decode base58 , delete 8 bytes (checksum)

and it is your target.


now :

get new public_key -> perform sha256 + ripemd and check it is your target.


now it is 3 or 4 times faster

[digaran]

why u use external library ?

it is your bottleneck.

you are comparing addres with address.

it means : additional you do:

Sha256 + sha256 for checksum.

?

better:
get target and change for decode base58 , delete 8 bytes (checksum)

and it is your target.


now :

get new public_key -> perform sha256 + ripemd and check it is your target.


now it is 3 or 4 times faster

Are you telling this based on the code, I mean did you check the code? If the code does the double hash for each key then you are right.

[ripemdhash]

my answer was to nomachine

his code:

Code:

mport os
import multiprocessing as mp
from gmpy2 import mpz, powmod
from bitcoinlib.encoding import addr_to_pubkeyhash, to_hexstring
from bitcoinlib.keys import HDKey
from ecdsa import SigningKey, SECP256k1

def save_key_to_file(private_hex: str):
    with open(f"{private_hex}.txt", "w") as f:
        f.write(private_hex)

def generate_random_numbers(num_numbers):
    return [os.urandom(32) for _ in range(num_numbers)]

def search_for_key(start_key_int, stop_key_int, target_address, attempts_per_process, random_numbers):
    for i in range(attempts_per_process):
        current_key_int = mpz(powmod(int.from_bytes(random_numbers[i], 'big'), 1, stop_key_int - start_key_int)) + start_key_int
        ecdsa_private_key = SigningKey.from_secret_exponent(int(current_key_int), curve=SECP256k1)
        key = HDKey(key=ecdsa_private_key.to_string())

        if key.address() == target_address:
            save_key_to_file(key.private_hex)
            print(f"Private key found: {key.private_hex}")
            return key
    return None

def search_in_range(start_key_int, stop_key_int, target_address, attempts_per_process, random_numbers):
    process_start_key_int = mpz(powmod(int.from_bytes(random_numbers[0], 'big'), 1, stop_key_int - start_key_int)) + start_key_int
    process_stop_key_int = (process_start_key_int + attempts_per_process) % stop_key_int
    search_for_key(process_start_key_int, process_stop_key_int, target_address, attempts_per_process, random_numbers)

if __name__ == "__main__":
    address = '1FeexV6bAHb8ybZjqQMjJrcCrHGW9sb6uF'

    start_key = '0000000000000000000000000000000000000000000000040000000000000000'
    stop_key = '000000000000000000000000000000000000000000000007ffffffffffffffff'
    start_key_int = mpz(start_key, 16)
    stop_key_int = mpz(stop_key, 16)

    attempts_per_process = 2000000
    num_processes = 8

    random_numbers = generate_random_numbers(attempts_per_process * num_processes)

    processes = []
    for _ in range(num_processes):
        process = mp.Process(target=search_in_range, args=(start_key_int, stop_key_int, address, attempts_per_process, random_numbers))
        processes.append(process)
        process.start()

    for process in processes:
        process.join()

    print(f"Private key not found in the given range after {num_processes * attempts_per_process} attempts.")

he import :

Code:

from bitcoinlib.encoding import addr_to_pubkeyhash, to_hexstring
from bitcoinlib.keys import HDKey
from ecdsa import SigningKey, SECP256k1

and he calculate:

Code:

def search_for_key(start_key_int, stop_key_int, target_address, attempts_per_process, random_numbers):
    for i in range(attempts_per_process):
        current_key_int = mpz(powmod(int.from_bytes(random_numbers[i], 'big'), 1, stop_key_int - start_key_int)) + start_key_int
        ecdsa_private_key = SigningKey.from_secret_exponent(int(current_key_int), curve=SECP256k1)
        key = HDKey(key=ecdsa_private_key.to_string())

        if key.address() == target_address:
            save_key_to_file(key.private_hex)
            print(f"Private key found: {key.private_hex}")
            return key
    return None

so first:
he calculate :

Code:

ecdsa_private_key = SigningKey.from_secret_exponent(int(current_key_int), curve=SECP256k1)
        key = HDKey(key=ecdsa_private_key.to_string())

        if key.address() == target_address:

which taking time.   

 

[tgfx]

Hello everyone, I recently purchased a video card, I want to try the search. Tell me, what other alternatives are there ButCrack on CUDA cores?