Topic: BitCrack - A tool for brute-forcing private keys - page 36. (Read 75623 times)

How long have you used bitcrack or actually scanned ranges with it?

It is simple to track the subranges checked. Nothing to do with vram; when you run a random range, you save that range to a text file. Then you can sort it after a period and see which ranges you have checked. Or you could use one of the programs that tracks it for you.  The program breaks the 64 bit range into however many subranges you want and then assigns a subrange and keeps track of what you have checked. Or one could use a simple python script to generate random ranges and print ranges checked to a file.

Random or sequential, doesn't matter how you use bitcrack as long as you keep track of random ranges searched.

Yeah not sure where you get your info from.  Bitcrack doesn't ignore keys. Unless you are speaking of a bug with the CL version, but the program does not skip/ignore keys unless you use the stride option, on purpose.

Thank You, I will take a look.

If you take care of the chunking I guess it will work fine.

I think if you combine following Forks you get a good head start

ByLamacq has implemented the Vectorization Patch
https://github.com/ByLamacq/BitCrack/commits/master

BoGnY and his OpenCL Fix
https://github.com/BoGnY/BitCrack/commits/master

Fishpeppers Base58 Patch
https://github.com/fishpepper/BitCrack/commit/af2aa3e2df798453338b71f619f2596620a600a5

And you would just have to apply the changes manually without knowing that much of c++.

I have actually made a program in python that splits the keyspace into chunks and I can either start at a set place or randomly choose chunks until they are all complete. To run through the first I split the range into 200 chunks which takes about 12 - 15 minutes to run each chunk.

But yeah, I wish I knew C++/C more and I would try and make any optimizations.

Tbh, If i would try to crack the puzzle I would fix the OpenCL Bug and implement the various optimizations from different forks of BitCrack. Then I would modify the code and instead of incrementing the key, i would decrement the key. I mean... there are alot of people scanning the whole 2^63 - 2^64 Range and they already scanned about 10-20% of it from the beginning already. So scanning it again makes no sense. But I did not see a modification of BitCrack which implements decrementing the keys. So you would have a better chance to find the solution if you begin from the middle and increment the key or from the end and decrementing the key. Picking some random ranges in the big range as some people mentioned gives imho no actual benefit. In contrary: The Key could be in any subrange. And if you do it randomly, you would have to store the information which ranges you already scanned in your statusfile (--continue FILENAME). This file would just consume more of your VRAM and depending on the amount of subranges could reduce your speed. But if you would decrement the key you could still use the statusfile-logic as it would only store the information about where you stopped the last time and you could pick up from there very fast and continue decrementing the key. Especially because you mentioned you like to hold the search now and then for gaming and watching TV.

------------------

Regarding Code Optimizations:

I tried the whole night to understand how i can get more performance.

I have a Vega 56 and a Quadro P620 in my PC.

Under Linux my Vega56 has about 45 MKeys/s (with buggy clBitCrack) and my P620 has about 26 MKeys/s with cuBitCrack

Under Windows I have about 54 MKeys with cuBitCrack and clBitCrack did not really run...

So... I dont know why I have poor performance under Linux. I am not interested to further investigate this. So Windows it is.

On the other hand, It seems, that NVidia is also suggesting that lto is improving the performance

https://developer.nvidia.com/blog/improving-gpu-app-performance-with-cuda-11-2-device-lto/

I tried alot to get it compiled in Linux, but I guess I would need to further investigate into this as I was getting compilation errors. But as I said, I will use Windows... So maybe there I can improve it.

So how would you go about brute-forcing the whole range between 2^63 and 2^64 even if it does take much longer? or do I just re-scan the whole range again, will it skip different keys?

No, the puzzle is between 2^63 and 2^64 BUT:

https://github.com/brichard19/BitCrack/issues/223

(uint64_t)_points * _threads * _blocks;


So instead of checking all keys you are basically ignoring alot of keys. If you have e.g. 512 blocks and 1024 threads (doesnt matter if those are valid inputs) you would basically jump over 512*1025 = 2^19 keys.

So thats why you are faster finished.

Not disagreeing with you, but the hex ranges I showed above are correct right? Why would clBitcrack state "[Info] Reached end of keyspace" unless there is some bug or those are not the correct ranges. maybe I missed a 0 or two?

Appreciate the explanation.

edit: I see 2^64 = 18,446,744,073,709,551,616 in decimal. Whereas the difference between the two hex ranges is 9,223,372,036,854,775,808 so I am guessing the 64 bit range that the puzzle is in is anywhere from 2^1 -> 2^64? Whereas I have just scanned 2^63 -> 2^64 which is just a single segment of the whole range?

Ok, when I said entire range I meant the one you were referring to...2^64, 64 bit range.

No, you did not search the entire 64 bit range. At 1100 Mkey/s it would take you around 1,448,907,898,153,186 days to search the entire 64 bit range.

You can try it but I would not recommend it.

I would recommend to use the --continue FILE option and just switch the OS if you want to play or continue with cracking. Maybe using the CudoOS and instead of mining using bitcrack can also improve performance if you are not a native linux user.

I wonder if the cuBitcrack would work well under Windows Subsystem for Linux with Linux binary. I might try that, I am more comfortable in Linux, The only reason I started this on Windows is so that I could stop it if I wanted to watch TV or play games on my PC.

Maybe this fork is working for you

https://github.com/ZenulAbidin/BitCrack-3000

But you would need to compile it yourself. I am Linux-User, so I cant help you there with compiling it. THere is also a sp version precompiled for windows fork, it is somewhere linked. I did not save the link as it was uninteresting for me.

D
Thanks,

Do you know if anyone has compiled a Cuda version of Bitcrack for Windows that will work with the 3070 and Cuda 11.2? I have tried compiling myself by changing the props files but I am having no luck, I never really worked with C++ or VS.

According to the github-repo the openCL version is buggy and does not find all keys.

Test it by checking the already known keys. If you dont find all keys (e.g. you find keys but you are missing some in between) then you can assume that you are effected by the openCL-Bug and you wasted your time.

Edit:
Also this
https://bitcointalksearch.org/topic/m.56053911

Not the entire, just the 64-bit range.
 
If that is the case then why does clBitcrack on my RTX 3070 say the range has been completed. from decimal 18446744073709551615 to 9223372036854775808? Using clBitcrack as cuBitcrack dont work on my 3070, I'm doing around 1100MKey/s?

I have inputted the hex ranges:

0000000000000000000000000000000000000000000000008000000000000000
000000000000000000000000000000000000000000000000ffffffffffffffff

Altogether it has taken around 2 days (~42 hours) to search non-stop.

Hahaha....another one claiming to have searched the entire range.

Absolutely no way you ran the entire range.

If you had GPUs that could search 10,000,000,000,000,000,000,000 keys a second, it would take you 159 days to search the entire range.

Does BitCrack always find keys or can it miss?

I have searched the whole of the puzzle 64 range and not been able to find the key 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN

0x0000000000000000000000000000000000000000000000008000000000000000
0x000000000000000000000000000000000000000000000000ffffffffffffffff

https://privatekeys.pw/puzzles/bitcoin-puzzle-tx

Yes, provided that instructions that were previously being executed were trimmed down. Which is usually the case when the optimization is done on entire functions as this is doing.

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