BitCrack - A tool for brute-forcing private keys

[fxsniper]

Really? ...

Do you have the links to the faster ones?

The groundwork was laid a long time ago.

https://github.com/Telariust/VanitySearch-bitcrack

Faster, with multi gpu support. Take existing code and make the tweaks one wants/needs. Much easier to understand and tweak vs bitcrack, IMO. Pool operator can verify that it is faster as well. It also supports the newer cards, 30xx series.

yes, it faster


my test
VanitySearch is faster

I am not sure can compare or not with method search for bitcrack and vanitysearch


brichard19 BitCrack ==> 11 MK/s

Bitcrack-sp-mod1 ==> 50 MK/s  (full memory)
Bitcrack-spmod2 ==> 50 MK/s

VanitySearch-bitcrack ==> 70 MK/s

VanitySearch ==> 149 MK/s

command test
VanitySearch.exe -gpu 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN


VanitySearch-bitcrack
GPU: GPU #0 GeForce GTX 1050 (5x128 cores) Grid(40x512)
80.121 MK/s (GPU 70.098 MK/s) (2^29.91) [00:00:12 lost_TIME_left infinity][0]

VanitySearch
GPU: GPU #0 GeForce GTX 1050 (5x128 cores) Grid(40x128)
[169.91 Mkey/s][GPU 149.29 Mkey/s][Total 2^29.95][Prob 0.0%][50% in 1.89065e+32y][Found 0]


problem
VanitySearch fast but it search full key 265bits
can not search by keyspace for puzzle #64

[1714957367]

1714957367

[1714957367]

1714957367

[1714957367]

1714957367

[1714957367]

1714957367

[fxsniper]

and for puzzle # 120-#160 how can I change it to can use with puzzle #160

Okay, but it looks pointless for me.
This code is for arbitrary puzzle output number (n):

Code:

const Int32 n = 120;  // Output number of the puzzle tx

Byte[] rnd256 = new Byte[32];
var random = new Random();
random.NextBytes(rnd256); // Get 256-bit random sequence  

Int32 nBytes = (n - 1) / 8;
Int32 nBits = (n - 1) % 8;
Byte mask = (Byte)(0xFF >> (8 - nBits));

for (UInt32 i = 0; i < 32 - nBytes - 1; i++) rnd256[i] = 0; // Zeroing unused bytes
rnd256[32 - nBytes - 1] &= mask;                            // Zeroing unused bits                     
rnd256[32 - nBytes - 1] |= (Byte)(mask + 1);                // Most significant bit is always 1.

String rndHex = BitConverter.ToString(rnd256).Replace("-", String.Empty);

Console.WriteLine(rndHex);

Thank you A-Bolt

Just hobby do after works or free time (Only during this time interest not yet give up)

[_Counselor]

yes, it faster


my test
VanitySearch is faster

I am not sure can compare or not with method search for bitcrack and vanitysearch


brichard19 BitCrack ==> 11 MK/s

Bitcrack-sp-mod1 ==> 50 MK/s  (full memory)
Bitcrack-spmod2 ==> 50 MK/s

VanitySearch-bitcrack ==> 70 MK/s

VanitySearch ==> 149 MK/s

command test
VanitySearch.exe -gpu 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN


VanitySearch-bitcrack
GPU: GPU #0 GeForce GTX 1050 (5x128 cores) Grid(40x512)
80.121 MK/s (GPU 70.098 MK/s) (2^29.91) [00:00:12 lost_TIME_left infinity][0]

VanitySearch
GPU: GPU #0 GeForce GTX 1050 (5x128 cores) Grid(40x128)
[169.91 Mkey/s][GPU 149.29 Mkey/s][Total 2^29.95][Prob 0.0%][50% in 1.89065e+32y][Found 0]


problem
VanitySearch fast but it search full key 265bits
can not search by keyspace for puzzle #64

Original VanitySearch uses endomorphisms to perform fast additional checks for each key generated.
For each key it checks K, K*lambda, K*lambda*lambda, -K, -K*lambda, -K*lambda*lambda - total 6 possible addresses.
So, for original VanitySearch speed means addresses per second, not keys per second.
These checks are not needed to find addresses in the range. That is why BitCrack and Vanity with bitcrack mode is much slower.

[chrysophylax]

Oh No ...

Is this 'pool' Windows based only?

Is there a linux based version, as we mainly use CentOS7 CentOS8 for our servers, which we would gladly setup for the community.

Windows is a no go for us at CWI. Never will be. EVER.

#crysx

64 bit pool  have support both windows and Linux ( Ubuntu 64 bit 14.04.2 LTS and 18.04.3 LTS.)

support only bitcrack  no BSGS

How? ...

C/C++/Python and most of the other 'commonly' known languages are readily available in CentOS/Ubuntu. How is PureBasic one of those and how on earth do you compile this in a CentOS7/8 VPS.

I suppose it is one thing to say it works, another to make it work in such environments. Windows will never be an OS we use.

So if you can point to a link that shows how to compile this in CentOS/Ubuntu - I may be able to work it out without taking any of my developers off the projects they are already inundated with.

#crysx

[sp_]

my test
VanitySearch is faster
I am not sure can compare or not with method search for bitcrack and vanitysearch
VanitySearch-bitcrack ==> 70 MK/s

I tested Vanitysearch_bitcrack on the gtx 1070ti and the speed was: 287Mkey. The hashrate started better at around 300MKey, and then dropped after a few seconds down to 287..

bitcrack sp-mod#2 is 404Mkey. (+40%)

[sp_]

Bitcrack-spmod2 ==> 50 MK/s

On the gtx 1050 laptop try with the launch config -b 40 -t 512 in the bat file.

[fxsniper]

Bitcrack-spmod2 ==> 50 MK/s

On the gtx 1050 laptop try with the launch config -b 40 -t 512 in the bat file.

my memory is 32GB


cuBitCrack.exe -d 0 -b 40 -t 512 --keyspace 8000000000000000:+10000000000 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN

Bitcrack sp-mod #2 (https://github.com/sp-hash)


[2021-03-23.19:29:09] [Info] Compression: compressed
[2021-03-23.19:29:09] [Info] Starting at: 0000000000000000000000000000000000000000000000008000000000000000
[2021-03-23.19:29:09] [Info] Ending at:   0000000000000000000000000000000000000000000000008000010000000000
[2021-03-23.19:29:09] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2021-03-23.19:29:09] [Info] Initializing GeForce GTX 1050
[2021-03-23.19:29:10] [Info] Generating 83,886,080 starting points (3200.0MB)
[2021-03-23.19:29:13] [Info] Error: out of memory
Execution time = 4 seconds

[sp_]

You probobly need to reduce the number of points as well. Play with the settings. I am sure will run faster. The gtx 1050 laptop is not the target for the optimizations here.

[fxsniper]

You probobly need to reduce the number of points as well. Play with the settings. I am sure will run faster. The gtx 1050 laptop is not the target for the optimizations here.

Error: out of memory

I try change to -b 20 -t 256

it is works

cuBitCrack.exe -d 0 -b 20 -t 256 --keyspace 8000000000000000:+1000000000000000 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN

GeForce GTX 1050 2634 / 4096MB | 1 target 78.97 MKey/s (3,376,414,720 total) [00:00:40]

[renedx]

Even if he is able to 2x the openCL speed on the Ampere cards, it would take my spare -/+20 cards 74 days to crack 10% of the puzzle 64. Could be enough, but prob. still would take a lot of time.

Btw _sp
I can remote access you a RTX card if it helps

Ha...ha...ha...unless I am reading what you are saying wrong.  You have 20 cards, round about 20? And you think you would crack 10%?  The pool has been running pretty non stop for over a year. With Zielar's big push at times with 256 to 512 V100, and they are barely above 10%.  Yes. 256 up to 512 V100s at times...over a year running, and barely above 10%.

You're right, I didn't modify the suspected keyspace we ran. My bad. In that case, its gonna be a long bumpy ride 

[Markzuberg64]

2 min if speed of 15 billion achieved and if i write private key and corresponding public key

Are you looking for uncompressed or compressed?
Since I do not know your purpose in this, I can't help you to shorten the pubs.
Regardless, 20 million priv keys and corresponding pubkeys should only take up about 2.5Gb in storage space.

The purpose is to make precomputed tables , nothing else. 😁 . Uncompressed pubkeys are fine since i found that it would be beneficial to store them as hash only which eventually will save space too and private keys can be found later by index. No need to save them. I learned it from jean Bsgs Code. It uses 25 bits to save the baby steps. And i think its same as sequential pubkeys if the sole purpose is for making a hash table.

But still i didnt get any idea of how the 15 billion per min speed can be achieved.

[WanderingPhilospher]

problem
VanitySearch fast but it search full key 265bits
can not search by keyspace for puzzle #64

You are using wrong VanitySearch

[WanderingPhilospher]

C/C++/Python and most of the other 'commonly' known languages are readily available in CentOS/Ubuntu. How is PureBasic one of those and how on earth do you compile this in a CentOS7/8 VPS.

He was referring to the 64 bit pool, not the link I posted

[WanderingPhilospher]

my test
VanitySearch is faster
I am not sure can compare or not with method search for bitcrack and vanitysearch
VanitySearch-bitcrack ==> 70 MK/s

I tested Vanitysearch_bitcrack on the gtx 1070ti and the speed was: 287Mkey. The hashrate started better at around 300MKey, and then dropped after a few seconds down to 287..

bitcrack sp-mod#2 is 404Mkey. (+40%)

Here's the thing there _sp, yours is still stone age, single gpu and can't use with newer cards. Please update when yours can run multi gpu and 30xx cards.

[WanderingPhilospher]

2 min if speed of 15 billion achieved and if i write private key and corresponding public key

Are you looking for uncompressed or compressed?
Since I do not know your purpose in this, I can't help you to shorten the pubs.
Regardless, 20 million priv keys and corresponding pubkeys should only take up about 2.5Gb in storage space.

The purpose is to make precomputed tables , nothing else. 😁 . Uncompressed pubkeys are fine since i found that it would be beneficial to store them as hash only which eventually will save space too and private keys can be found later by index. No need to save them. I learned it from jean Bsgs Code. It uses 25 bits to save the baby steps. And i think its same as sequential pubkeys if the sole purpose is for making a hash table.

But still i didnt get any idea of how the 15 billion per min speed can be achieved.

I have no idea either...no way to write 15 billion in one minute, IMO, at least not on my hardware. Best I could do was about 200K a minute. Let me better explain. Normally when I do a search/look for keys, whether random or sequential, one of my GPUs will get 200MKey/s, but when I try to write the results, it drops to 0.1MKey/s because of the writing to file/RAM. So the bottleneck to me, is all in the CPU writing to file.

[NotATether]

How? ...

C/C++/Python and most of the other 'commonly' known languages are readily available in CentOS/Ubuntu. How is PureBasic one of those and how on earth do you compile this in a CentOS7/8 VPS.

I suppose it is one thing to say it works, another to make it work in such environments. Windows will never be an OS we use.

So if you can point to a link that shows how to compile this in CentOS/Ubuntu - I may be able to work it out without taking any of my developers off the projects they are already inundated with.

#crysx

If you're referring to Bitcrack itself and not a pool, it's pretty straight forward: make BUILD_CUDA=1

Memory usage during compilation is actually very light, should work on an entry-level VPS. I suspect this is not what you're asking though. I'm quite confused.

Original VanitySearch uses endomorphisms to perform fast additional checks for each key generated.
For each key it checks K, K*lambda, K*lambda*lambda, -K, -K*lambda, -K*lambda*lambda - total 6 possible addresses.

Now I know what an endomorphism is. By sheer coincidence, I was thinking about implementing something like:

Code:

x.bits64[0] == key.bits64[0] && ...
~x.bits64[0] == key.bits64[0] && ...
... 14 more lines

So I would've checked 15 other keys just by flipping each of the 4 64-bit words that make up the Int using NOT, but in the end I scrapped it because I didn't think any of those additional points have any special relationship with the target public key.

I have no idea either...no way to write 15 billion in one minute, IMO, at least not on my hardware. Best I could do was about 200K a minute. Let me better explain. Normally when I do a search/look for keys, whether random or sequential, one of my GPUs will get 200MKey/s, but when I try to write the results, it drops to 0.1MKey/s because of the writing to file/RAM. So the bottleneck to me, is all in the CPU writing to file.

Alternatively if you have a 10GBit Ethernet port lying around somewhere you can just send all the points across your local network to some other system that just writes the points in its own storage.

The idea scales too: While the other system is waiting on packets it can send some more points to other systems so that it doesn't have to write all the points on its own disk and fill it up quickly. There are some kernel options that tune the network drivers for uploading.

[WanderingPhilospher]

Alternatively if you have a 10GBit Ethernet port lying around somewhere you can just send all the points across your local network to some other system that just writes the points in its own storage.

How would you do this? Any code or snippets to look at? Or is it something you write on client side to send all output to another PC on local network?

[NotATether]

Alternatively if you have a 10GBit Ethernet port lying around somewhere you can just send all the points across your local network to some other system that just writes the points in its own storage.

How would you do this? Any code or snippets to look at? Or is it something you write on client side to send all output to another PC on local network?

It's better to use a network library like this one (https://github.com/Qihoo360/evpp, just a random link from the first page of Google search results) that lets you send packets asynchronously for the size of data you're trying to send, else the blocking nature of network I/O will make the whole program no faster than writing to a disk. And even that can be written to asynchronously using stuff like libevent but the results aren't much better: Instead of stalling the GPU you're now hammering the disk making it unavailable for all other programs.

So it's like you got to optimize for your network speed and only try to send that many packets per second. Since these are local networks we're talking about the speed should be predictable. Cloud platforms like Hetzner also let you network with their other servers since 99% of people reading this don't have 10GBit ports and spare boxes lying around somewhere.

[sp_]

Another +10%

https://github.com/sp-hash/Bitcrack/releases/tag/3

gtx 1070 375Mkeys
gtx 1070ti 445Mkeys
gtx 1080 480Mkeys
gtx 1080ti 650Mkeys
gtx titanx 610Mkeys

[sp_]

Please update when yours can run multi gpu and 30xx cards.

I have ordered new cards.  Will get them next month..