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

Your CUDA drivers might be wrong, which version do you use?

I have opened my box for newbies
I usually get 160-220Mkeys per second depending on the size of addresses to check. Has been doing 100lists
[/quote]

I send PM to you

You need clBitCrack, but the setup principle is the same as for cuBitCrack.

I so have understood, that cuBitCrack and CUDA for processors Intel witch a video cards NVIDA
Mine laptop - AMD A6-3420M APU with AMD Radeon HD 6520G
Therefore I use OpenCL and clBitCrack
Unless cuBitCrack and CUDA will work with such configuration?

bartekjagoda  

How to send you PM if you have "closed"?
[/quote]

I have opened my box for newbies
I usually get 160-220Mkeys per second depending on the size of addresses to check. Has been doing 100lists

Hi, read the link https://bitcointalksearch.org/topic/m.52255756

Probably at I have very weak laptop there is no large difference on speed from change of parameters - t - p (in clBitCrack.exe)
The quantity Generating starting points depends on parameters - t - p
Than meanings of parameters - t - p by that more will be more generated Generating starting points
I think, probably, than will be more generated Generating starting points - the better?
Who knows precisely - explain.

Hi, how to use cuBitCrack.exe on multiple gpu?

Is anyone else having issues running multiple instances?  I have a 7 card gpu rig, if initiate 2+ instances I get a computer crash. Windows 10, cl initiate.

I have a GPU brainflayer, 1 billion hashes /sec on 8 x RX570

You can send me PM if interested
[/quote]

bartekjagoda  

How to send you PM if you have "closed"?

Hi all, im currently getting only around 3 MKey/s using a GTX 1080 8GB, ive seen others getting 300 MKey/s, i have tried the card on two different PC's with a fresh install(win10), yet both give the same rate.

This is my config,

I have tried to play with the numbers but crash the card if i go too high, could anyone suggest a soloution.

C:\Users\Mashine-5\source\repos\BitCrack2\x64\Debug>cuBitCrack.exe -i key.txt -o key1.txt
[2019-09-15.17:02:27] [Info] Compression: compressed
[2019-09-15.17:02:27] [Info] Starting at: 0000000000000000000000000000000000000000000000000000000000000001
[2019-09-15.17:02:27] [Info] Ending at:   FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140
[2019-09-15.17:02:27] [Info] Counting by: 0000000000000000000000000000000000000000000000000000000000000001
[2019-09-15.17:02:27] [Info] Initializing GeForce GTX 1060 6GB
[2019-09-15.17:02:27] [Info] Generating 262,144 starting points (10.0MB)
[2019-09-15.17:02:30] [Info] 10.0%
[2019-09-15.17:02:32] [Info] 20.0%
[2019-09-15.17:02:35] [Info] 30.0%
[2019-09-15.17:02:37] [Info] 40.0%
[2019-09-15.17:02:39] [Info] 50.0%
[2019-09-15.17:02:41] [Info] 60.0%
[2019-09-15.17:02:43] [Info] 70.0%
[2019-09-15.17:02:46] [Info] 80.0%
[2019-09-15.17:02:48] [Info] 90.0%
[2019-09-15.17:02:50] [Info] 100.0%
[2019-09-15.17:02:50] [Info] Done
[2019-09-15.17:02:50] [Info] Loading addresses from 'key.txt'
[2019-09-15.17:02:50] [Info] 1 addresses loaded (0.0MB)
GeForce GTX 1060 1083 / 6144MB | 1 target 1.25 MKey/s (11,796,480 total) [00:00:07]




Hello!

Why such a low rate?
There is a detailed setting, please tell me)
Maybe something is installed incorrectly

How to prevent brute-forcing private keys?

I also thought so for a long time.
not really if the size does not exceed 49152
VanitySearch restarts the kernel about 1000 times per second (!!!), and it works fine.
opencl unknow

..and this is one of the main technical reasons why gpu BF do not.
cpu BF checks huge dictionaries in a few hours. loading such volumes into gpu is problematic.
therefore gpu BF should work using the built-in generator, e.g. brute force seed.

You'd probably need to perform string mangling on the GPU to keep the cores working as much as possible, because the transfer of each and every candidate phrase from CPU/system memory to the GPU could end up being a severe bottleneck. Perhaps a deliberately slower algorithm like warp may work better, since the GPU will spend most of its time calculating rather than transferring to/from the host... but how common are non SHA256 brainwallets? As you state, any passphrase based search (which is essentially a set of random keys) will be slower than a sequential search.

Thanks, nice info. What about pollard-rho versions of this people talk in other threads, but there is no publicly available tool to try it (to my knowledge)?

True, according to my knowledge after 1 year of research.

In fact, you want a gpu BrainFlayer. Everyone wants it)
Ryan refuses to write it because he is a WhiteHat.

If successful, it will be slower than sequentially calculating points.

##########################
heuristic calculate the hashrate for BrainFlayer cuda/opencl

BrainFlayer cpu sse
0,1 Mk/s - 1core i7-6820
8core - 4core real, 4core hyper-threading, so x6 instead x8
0,6 Mk/s - 8core i7-6820

VanityGen x64 opencl
60.7 Mk/s - gtx980
0,52 Mk/s - 8core i7-6820

60.7/0,52 = x116,7 (vg opencl gpu/cpu)

VanityGen x64 cpu sse
1,38 Mk/s - 8core i7-6820

1,38/0,52 = x2,6 (vg sse/opencl)

now if imagine
BrainFlayer opencl
0,6x(1/2,6) = 0,23 Mk/s - 8core i7-6820
0,23x116,7 = 26,8 Mk/s - gtx980

if
clBitCrack opencl
67.7 Mk/s - gtx980
cuBitCrack cuda
153.5 Mk/s - gtx980
241.3 Mk/s - gtx1070

153.5/67.7 = x2,26 (bc cuda/opencl)

then
BrainFlayer cuda
26,8x2,26 = 60,5 Mk/s  - gtx980
60,5x(241.3/153.5) = 94,9 Mk/s  - gtx1070

Ty for your explanation, I can't pm u back because of messaging limits. So basically there is no way to combine really fast random hex generator to work with the calculation process? So all we can do is randomly get starting points and from there work in increments.

The Engine of these programs is divided into two types:

1) optimized point addition (for quick calculation of sequential keys)
 sample programs: vanitygen, bitcrack, vanitysearch, break_short;
 methods:
 - calc only X coordinates (for compressed keys);
 - use of functions without protection against side channel attacks (openssl/secp256k1);
main problem - inversion calculation is very expensive, ~20mult per 1 point;
can use batch inversion (Simultaneous algorithm, 1 inversion per 1000 keys) + Affines coordinates + symmetry(only full range) + endomorphism(only full range);

2) optimized point multiplication (for quick calculation of random keys)
 sample programs: brainflayer;
 methods:
 - secp256k1 library with pre-calculated mult table in ram;
 - Jacobian coordinates;
main problem random mult - inversion need too, but can not use batch inversion because each key is random.

BitCrack is optimized for sequentially calculating points in a limited range using addition.
VanitySearch is optimized for sequentially calculating points in the full range using addition (and 4 multiplication algorithms that work only for the full range).
BrainFlayer (cpu only) is optimized for random calculating points in a full range using multiplication.
You want to get random points in a limited range using multiplication.
These are fundamentally different tasks.

If you delve into the study of random generators, you will find that they have top speed.
Typically, the problem is that the overhead of generating random numbers is greater than the useful calculation itself.

PS:
about multiplication
At start BitCrack, pre-computes the starting points using multiplication.
It is so slow that starting from version 0.15 the author transferred the procedure to gpu.

see 1post - v0.0.6...  the author does not come here for more than a year

Can some1 fork latest version of bitcrack so it does -r random on every point across selected keyspace. So every jump/try is random. Not like in pikachunakapika version where it chooses random staring points and then starts doing them in 1 increment at a time. Kinda like generating random hex key on each try within selected keyspace.