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

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

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:


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

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.

Does your speed improve if you replace

with


?

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

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)