BitCrack - A tool for brute-forcing private keys

[NotATether]

about GPU using with bitcrack

reference from old news,  next time new GPU from NVIDIA will can not using for mining bitcoin

on this case it is effect with bitcrack calculate by GPU or not?
if buy next generation GPU from Nvidia  that lock for can not use mine bitcoin and use that GPU with   bitcrack it still high or get block to calculate and downgrade to low speed or not?

I dont think the rate-limiter is sophisticated enough to detect Bitcrack yet.

Also, some major news, Nvidia accidentally released beta driver 470.5 that UNLOCKS the RTX3060 for full-speed ethereum mining (but quickly disabled it in a newer driver version and removed the beta one from the site) so apparently the cards can be unlocked from the driver after all: https://www.theverge.com/2021/3/16/22333544/nvidia-rtx-3060-ethereum-mining-rate-limit-unlock-driver

It's too bad though that nearly everyone on the Internet sucks at reverse engineering drivers  

I wish I knew how to make Linux kernel nvidia drivers

[1714472698]

1714472698

[1714472698]

1714472698

[1714472698]

1714472698

[fxsniper]

I dont think the rate-limiter is sophisticated enough to detect Bitcrack yet.

Also, some major news, Nvidia accidentally released beta driver 470.5 that UNLOCKS the RTX3060 for full-speed ethereum mining (but quickly disabled it in a newer driver version and removed the beta one from the site) so apparently the cards can be unlocked from the driver after all: https://www.theverge.com/2021/3/16/22333544/nvidia-rtx-3060-ethereum-mining-rate-limit-unlock-driver

It's too bad though that nearly everyone on the Internet sucks at reverse engineering drivers  

I wish I knew how to make Linux kernel NVidia drivers

Thank, I can search found beta driver 470.5 still can download on internet
unfortunes my local  rtx 3060 and other out of stock

because bitcrack run nearly GPU 100% I just afraid new driver detect like mine Ethereum
good for now if not detect bitcrack

[fxsniper]

Can possible  Bitcrack-spmod5 do optimize for Blbitcrack (OpenCL) ?

[dextronomous]

Is there any way to guess any letters of key 64, As on the basis of similarities between these two keys ?

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

Theoretically we can replace the black characters with 1111 and zzzz so that we have two strings, then we convert them into numbers. Basic sequential counting is cheap compared to the cryptographic hashing done on each PK so with a fast Base58-to-hex converter, we can successively increment those black characters from 1 to z.

hello,

you mean to say something like that ??

Code:

from bit import *
from bitcoin import *
import random

list = ["16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN","13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so","1BY8GQbnueYofwSuFAT3USAhGjPrkxDdW9","1MVDYgVaSN6iKKEsbzRUAYFrYJadLYZvvZ"]
while 1==1:
   a = random.randrange(144,255)
   while a <= 4095:
       a+=1
       b = ("3536A")
       c = random.randrange(16777216,268435455)
       d = ("b0")
       myhexa = "%050x" % a
       myhexc = "%0x" % c
       j = (myhexa+b+myhexc+d)
       priv = j
       pub = privtopub(priv)
       pubkey1 = encode_pubkey(privtopub(priv), "bin_compressed")
       addr = pubtoaddr(pubkey1)#compressed
       s1 = j
       s2 = addr
       if addr in list:
            print ("...............FOUND.............")
            f=open(u"C:/found.txt","a")
            f.write(s2+" ")
            #f.write(s3+" ")
            f.write(s1+"\n")
            f.close()
            break
       if addr.startswith("16j")or addr.startswith("13z")or addr.startswith("1B8")or addr.startswith("1MV"):
           print(j,addr)

Here is few results..

000000000000000000000000000000000000000000000002813536A3855b0ab0 1MVBvZWijEX6jLHqvc62ycQmAwQF2MGtn1
000000000000000000000000000000000000000000000003323536A37ecc11b0 13z3UU2fSmoHFsnkc3PNVEtz5fGunJyxWk
000000000000000000000000000000000000000000000004163536Af36acf8b0 16jzjW8DghfsvE9s5oYVdQjdCL68KfQWCD
000000000000000000000000000000000000000000000004763536A4d3f7d8b0 16j4ZG3tQJdCNNB7FxAXEX2pddUbcVQurc
0000000000000000000000000000000000000000000000061f3536A3b9564bb0 16jKBfsPZpqTr3Wf68UpG9GXFzGy5tvMLD
0000000000000000000000000000000000000000000000062f3536Af43f269b0 1B8fpioKSuEHWh6GNXzKYT2FhnEcisi7TS
00000000000000000000000000000000000000000000000a883536A5c18381b0 1MVAj6xiQtR9aZMvoAvCXaKKapXx5mZAoj
00000000000000000000000000000000000000000000000df93536Ab136b68b0 1B886nbuaUaXYCtYxXVU4ykrhXDM5up71v
00000000000000000000000000000000000000000000000e4a3536A58eb38bb0 16jjxYEA2ccW8pTiSzozPCX7u4m6AwCWMc
00000000000000000000000000000000000000000000000e813536A42123d2b0 13zV6pBA4aZZzKGj8dJALiW7KAtiRq5SP7
00000000000000000000000000000000000000000000000f413536Aabe707bb0 13zQuhCczRWABxgXGw1WtDAK1e1z9PXJtk
000000000000000000000000000000000000000000000001563536A67fee37b0 1MV7GUZu4efY1hRbTJm4qEUWYtN42tKgdh
000000000000000000000000000000000000000000000004073536Ac381924b0 1B8ZsYYvyqjyndX8mg3QNb3NXnPX1FeK8B
000000000000000000000000000000000000000000000004853536Ade61185b0 1B8Q2s1hKF6B8GdymtfSVUrQGan1TEBd9a
000000000000000000000000000000000000000000000008db3536A6c40e08b0 1MVTW3PdbmkF57pruNJckLNFiz6cJyoyHn
00000000000000000000000000000000000000000000000e133536A4f412b7b0 13zs9rHG9A41ih8UNDZzrA4RcTAiqfSz15

hi there zahid,
wanted to ask, how is that code also searching for 64th puzzle address, or i am seeing something wrong, one 0 gonna shift bits up, so no more 64 bit,
and how to say all those addresses, in this range you set, thanks for explaining,

[fxsniper]

puzzle don't try search by pattern, it is not working
address pattern like random

puzzle is absolute like random

if do address pattern, you need to research whole address to know structure

[NotATether]

hi there zahid,
wanted to ask, how is that code also searching for 64th puzzle address, or i am seeing something wrong, one 0 gonna shift bits up, so no more 64 bit,
and how to say all those addresses, in this range you set, thanks for explaining,

It's not shifting any bits. It is simply generating a few random groups of digits and concatenating them to constant hex numbers.

[AuorFedelmid]

I am currently trying to split an address range for a puzzle (64) into different chunks, add to a python list and randomly choose the chunks until they are all complete without sequentially cracking the range. I have a problem with some keyspaces though where I get an error from bitcrack.

for example

--keyspace 00000000000000000000000000000000000000000000000085ffffffffffffff:000000000000000000000000000000000000000000000000857fffffffffffff

Which are the decimals:

Start: 9655717601082343423
End: 9619688804063379455

Bitcrack errors with:  [Error] Error --keyspace: Invalid argument

Any idea why?

[enfarktus]

I am currently trying to split an address range for a puzzle (64) into different chunks, add to a python list and randomly choose the chunks until they are all complete without sequentially cracking the range. I have a problem with some keyspaces though where I get an error from bitcrack.

for example

--keyspace 00000000000000000000000000000000000000000000000085ffffffffffffff:000000000000000000000000000000000000000000000000857fffffffffffff

Which are the decimals:

Start: 9655717601082343423
End: 9619688804063379455

Bitcrack errors with:  [Error] Error --keyspace: Invalid argument

Any idea why?

The correct line-up will be from small to large. Like this: 857fffffffffffff:85ffffffffffffff

[AuorFedelmid]

I am currently trying to split an address range for a puzzle (64) into different chunks, add to a python list and randomly choose the chunks until they are all complete without sequentially cracking the range. I have a problem with some keyspaces though where I get an error from bitcrack.

for example

--keyspace 00000000000000000000000000000000000000000000000085ffffffffffffff:000000000000000000000000000000000000000000000000857fffffffffffff

Which are the decimals:

Start: 9655717601082343423
End: 9619688804063379455

Bitcrack errors with:  [Error] Error --keyspace: Invalid argument

Any idea why?

The correct line-up will be from small to large. Like this: 857fffffffffffff:85ffffffffffffff

doh, Thank You!!

[Desyationer]

I only have 660 ti and this gives me a speed of 80 raw, 45 both addresses, 25 with tens of millions of addresses loaded. Can I count on anything or wasting my time? I see there are a lot of owners here for 4x3090, etc.

[NotATether]

I only have 660 ti and this gives me a speed of 80 raw, 45 both addresses, 25 with tens of millions of addresses loaded. Can I count on anything or wasting my time? I see there are a lot of owners here for 4x3090, etc.

You're probably not going to find an address with a large search range using a single 660Ti or even four GPUs.

[Desyationer]

Is it possible -r mode that would be updated for a specified time, for example, a cycle is every 5 minutes, but at the same time the loaded address base would not be loaded again every cycle?
And the random range will be automatically updated instantly on the fly, without waiting for a long load of a large database of addresses. For example the -r option with the 300 (5min) parameter, while this does not work, only the bare -r without any parameters.

Does it make sense to put -u at a lower speed, or the raw format of addresses is negligible compared to the compressed format and it is better to leave just -c without -u

[Desyationer]

What speed does 6700xt give? Has anyone tried searching on this model?

[NotATether]

Is it possible -r mode that would be updated for a specified time, for example, a cycle is every 5 minutes, but at the same time the loaded address base would not be loaded again every cycle?
And the random range will be automatically updated instantly on the fly, without waiting for a long load of a large database of addresses. For example the -r option with the 300 (5min) parameter, while this does not work, only the bare -r without any parameters.

pika's random mode (which is not in brichard19's bitcrack) is not using a random number generator, it turns out that it uses an iteration count and multiplies it with all the other normal stuff, which is then ADDED to some exponent to obtaining private key samples:

Code:

// https://github.com/ZenulAbidin/BitCrack-3000/blob/master/CudaKeySearchDevice/CudaKeySearchDevice.cpp line 112
    // Generate key pairs for k, k+1, k+2 ... k + <total points in parallel - 1>
    secp256k1::uint256 privKey = _startExponent;

    if(!_randomMode) {
        exponents.push_back(privKey);
    }
// ...
// Line 272
        if(!_randomMode) {
            offset = (secp256k1::uint256((uint64_t)_blocks * _threads * _pointsPerThread * _iterations) + privateKeyOffset) * _stride;
            privateKey = secp256k1::addModN(_startExponent, offset);
        } else {
            offset = secp256k1::uint256(_iterations) * _stride;
            privateKey = exponents[privateKeyOffset];
            privateKey = secp256k1::addModN(privateKey, offset);
        }

I guess a quick and dirty way to implement this is to use a timer that changes _startExponent using an RNG.

Does it make sense to put -u at a lower speed, or the raw format of addresses is negligible compared to the compressed format and it is better to leave just -c without -u

Running with -c and -u at the same time will make BitCrack a little slower but that's about all it does.

[bigvito19]

I only have 660 ti and this gives me a speed of 80 raw, 45 both addresses, 25 with tens of millions of addresses loaded. Can I count on anything or wasting my time? I see there are a lot of owners here for 4x3090, etc.

You're probably not going to find an address with a large search range using a single 660Ti or even four GPUs.

What's the ideal speed to find an address, small and large search range?

[fxsniper]

I only have 660 ti and this gives me a speed of 80 raw, 45 both addresses, 25 with tens of millions of addresses loaded. Can I count on anything or wasting my time? I see there are a lot of owners here for 4x3090, etc.

You're probably not going to find an address with a large search range using a single 660Ti or even four GPUs.

What's the ideal speed to find an address, small and large search range?

no idea for now
now speed up to you GPU or use multiple GPU

I still use gtx 1050 low end gpu same

try use function save work for continue work on large range
or split small range and works finish each small job

everything have cost (There is nothing free in the world )
try use GPU on cloud service. for now new GPU and second hand out of stock on market (include some low end GPU 4GB too)

[a.a]

Does your speed improve if you replace

Code:

CXXFLAGS=-O2 -std=c++11

with

Code:

CXXFLAGS=-O2 -std=c++11 -flto -fno-semantic-interposition
LDFLAGS="-Wl,--strip-all -fno-semantic-interposition -flto"

?

I usually compile python with these modifications to get about 30 % more performance from it. Maybe this helps you too?

[zahid888]

hi there zahid,
wanted to ask, how is that code also searching for 64th puzzle address, or i am seeing something wrong, one 0 gonna shift bits up, so no more 64 bit,
and how to say all those addresses, in this range you set, thanks for explaining,

Yes, there is a zero growing here, I have made the code like this. This code is trying to search from 64th bit to 69th bit. And looking for four addresses, maybe one of these addresses can be found. However, This code is doing full random counting, in addition to some Predicted words (you can use your own) Everything is a game of luck. Till we have no strength to count in sequence.

[NotATether]

Does your speed improve if you replace

Code:

CXXFLAGS=-O2 -std=c++11

with

Code:

CXXFLAGS=-O2 -std=c++11 -flto -fno-semantic-interposition
LDFLAGS="-Wl,--strip-all -fno-semantic-interposition -flto"

?

I usually compile python with these modifications to get about 30 % more performance from it. Maybe this helps you too?

I'm sure compiled Python code keeps around a bunch of symbols which would be otherwise unnecessary in C to enhance the coding experience, which is why -flto -fno-semantic-interposition and just removing these symbols in general make it so faster.

But in an already-C program I don't think it will make much of a difference. But since there is some arithmetic done on the C side of things, you might benefit by setting these in CXXFLAGS:

Code:

-ffast-math -funsafe-math-optimizations

But don't expect a modest increase in cracking speed.

[a.a]

I will test my proposed modifications tonight and I'll report. On my other PC at least the binary files are noticibly smaller (less bitcode = less instructions = faster?)