Quote from: racminer on August 29, 2019, 05:33:43 PM

Quote from: Raj Lassi on August 29, 2019, 01:34:37 PM

Distributed Random Brute Force

I don't have the GPU power to make any progress with sequential brute force.
I also found, by experiment, that guessing random numbers can take much longer.

So, to maximize the fun, I am doing both.
I distribute the scan over the 20-3F keyspace, pick 3 random bytes, and brute force the rest.

My ranges look like this: (where XXXXXX is 3 random bytes)

[20-3F][XXXXXX]00000000 - [20-3F][XXXXXX]FFFFFFFF

My old card can try fifteen 3-byte randoms per scan, every 13 hours, at 44Mkey/s. Plus about 2 million really random randoms with the leftover starting points.

What does that get me?

15 random blocks of 4.3 billion keys in each of 32 sub-ranges [20-3F] per scan = 2 trillion. 4T/day. Pffft.

so, every 26-hour day, scanning the following:
128 B keys in 20XXXXXX00000000-20XXXXXXFFFFFFFF
128 B keys in 21XXXXXX00000000-21XXXXXXFFFFFFFF
128 B keys in 22XXXXXX00000000-22XXXXXXFFFFFFFF
.
.
.
128 B keys in 3DXXXXXX00000000-3DXXXXXXFFFFFFFF
128 B keys in 3EXXXXXX00000000-3EXXXXXXFFFFFFFF
128 B keys in 3FXXXXXX00000000-3FXXXXXXFFFFFFFF

i just need to get lucky with 3 bytes. how hard can that be? Huh

or, get lucky with 2 bytes, but wait a week to find out. that shouldn't take much more than 65535 weeks.

Quote from: racminer on February 22, 2019, 10:48:37 PM

Quote from: netlakes on February 22, 2019, 09:25:41 PM

Quote from: pikachunakapika on February 22, 2019, 09:23:45 PM

Quote from: netlakes on February 22, 2019, 09:00:08 PM

.................

................

................

So, speaking of case 61:

In my case, what I do is mix randomness with full range scan. I keep the range small enough to get reasonable waiting time (say 10 min) .
This is an example:

1) generate all possibles 5 bits number: 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F

2) pick a random 5 hex digit number (20bit) : for instance CADE9
we have now 16 possibles header for our key

10CADE9
11CADE9
12CADE9
13CADE9
14CADE9
15CADE9
16CADE9
17CADE9
18CADE9
19CADE9
1ACADE9
1BCADE9
1CCADE9
1DCADE9
1ECADE9
1FCADE9

3) call 16 instances of Bitcrack fully scanning following 16 ranges

10CADE9000000000:10CADE9FFFFFFFFF
11CADE9000000000:11CADE9FFFFFFFFF
12CADE9000000000:12CADE9FFFFFFFFF
13CADE9000000000:13CADE9FFFFFFFFF
14CADE9000000000:14CADE9FFFFFFFFF
15CADE9000000000:15CADE9FFFFFFFFF
16CADE9000000000:16CADE9FFFFFFFFF
17CADE9000000000:17CADE9FFFFFFFFF
18CADE9000000000:18CADE9FFFFFFFFF
19CADE9000000000:19CADE9FFFFFFFFF
1ACADE9000000000:1ACADE9FFFFFFFFF
1BCADE9000000000:1BCADE9FFFFFFFFF
1CCADE9000000000:1CCADE9FFFFFFFFF
1DCADE9000000000:1DCADE9FFFFFFFFF
1ECADE9000000000:1ECADE9FFFFFFFFF
1FCADE9000000000:1FCADE9FFFFFFFFF

goto step 2 and repeat.

each cycle will take 16*10min = 160 min if you have one GPU.

This trick will increase your likelihood in finding the key as times increases and not wait 180 years (1GPU) or 5 years (36GPUs). LOL

a random 5 hex digit is one of 1,048,575 if you get it right, you have the key in 160 min with only one GPU Wink

This looks like a suggestion I've made a while ago Wink

hahaha cool. i made some tweaks to BitCrack so i can set whatever starting points i want. I have it count to FFFF and restart with a new batch of points. it writes everything it has tried to a file. It has not picked the same random 3 bytes yet, nor has any scan overlapped any ranges posted here. i will be lazy and wait until it does before coding anything to prevent that. Tongue