I already gave up on this I'm mining ethereum classic  I suppose that you have either cheap or free electricity  I have a generator mounted on a waterfall here on my property free and clean energy post your address, maybe during solo travling, i visit you  |
|
|
|
6 march to 22 march no post, no idea sharing, no comments, all busy to find or all of you go for mining where some coins could be made  ?? |
|
|
|
Rx480 has a limit ... You can't have -t higher than 256.
Oh ... it changes the form of things :-) well ... I wanted better :-) --- Is there someone here who would be able to convert the counting number of scanned keys in BitCrack into a counter showing the number of REMOTE keys to be scanned along with the estimated remaining time to complete? It would be more interesting information than the amount that was scanned. Unfortunately, I do not know the programming language completely, and my knowledge ends at the stage of compiling a ready solution with possible code change in the sources. I would be grateful for such a small addition. Please checkout the branch "remaining" at https://github.com/pikachunakapika/BitCrack. It also includes my changes for random starting points. With -r you get no ETA and remaining count. Hello all i notice, this random called update just start with random starting points instead of series starting points after 1st generates random starting points, each starting point start searching series, Random should be every second each every string random if you understand, its ok, if you need to understand more in details with example, feel free to ask your random version of bitcrack working like [2019-03-04.21:09:12] [Info] Starting point sample: 5B60A7D6CAC10CEF8FF0CD0F7D3D4D7E72265EA3564F3A7C4CEC060DD434BD5E (255 bit range) [2019-03-04.21:09:12] [Info] Starting point sample: 507B5ACCB577F908D97155CD7A8F2827D7FF6752051D42D70AF33F6A80D4573F (255 bit range) [2019-03-04.21:09:12] [Info] Starting point sample: 5C45836A0BFB1EAE9FE807030A511FAF5AE30E1708E6E9AC4CEEEEEF0D85883E (255 bit range) each starting point key once random, next it starting working in series starting point key : 5B60A7D6CAC10CEF8FF0CD0F7D3D4D7E72265EA3564F3A7C4CEC060DD434BD5E next working : 5B60A7D6CAC10CEF8FF0CD0F7D3D4D7E72265EA3564F3A7C4CEC060DD434BD5f, ...60, ....61, .....62, ....63 starting point key : 507B5ACCB577F908D97155CD7A8F2827D7FF6752051D42D70AF33F6A80D4573F next working : 507B5ACCB577F908D97155CD7A8F2827D7FF6752051D42D70AF33F6A80D4573F ,... 40, ... 41, ...42 each starting point working in series what should be random, every second new starting point as random key should be in search pool have you all tested pinka... BitCrack ? have you seen this random style You must precise your individual range to scan by --keyspace command (eg. start:end ) and add -r before all. Try this: cuBitCrack.exe -r 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB -c -o FOUND.txt --keyspace 01000000000000000:01FFFFFFFFFFFFFFF ... and you have random range only for #61 address you did not follow each starting point is random, onword from starting point series generating for process example you searching from 100:1ff 7 starting point created, like 1 8 20 35 37 60 80 when process start from 1 point to 8 close in sequence same 35 to 37 close , but all in sequence first is starting point 1 2 3 4 5 6 7 8 9 10 8 9 10 11 12 13 14 20 21 22 23 24 25 26 27 in this sanrio, main brichard master branch is better continue sequence Random should be not only starting point, after each next step should be random key for process |
|
|
|
Rx480 has a limit ... You can't have -t higher than 256.
Oh ... it changes the form of things :-) well ... I wanted better :-) --- Is there someone here who would be able to convert the counting number of scanned keys in BitCrack into a counter showing the number of REMOTE keys to be scanned along with the estimated remaining time to complete? It would be more interesting information than the amount that was scanned. Unfortunately, I do not know the programming language completely, and my knowledge ends at the stage of compiling a ready solution with possible code change in the sources. I would be grateful for such a small addition. Please checkout the branch "remaining" at https://github.com/pikachunakapika/BitCrack. It also includes my changes for random starting points. With -r you get no ETA and remaining count. Hello all i notice, this random called update just start with random starting points instead of series starting points after 1st generates random starting points, each starting point start searching series, Random should be every second each every string random if you understand, its ok, if you need to understand more in details with example, feel free to ask your random version of bitcrack working like [2019-03-04.21:09:12] [Info] Starting point sample: 5B60A7D6CAC10CEF8FF0CD0F7D3D4D7E72265EA3564F3A7C4CEC060DD434BD5E (255 bit range) [2019-03-04.21:09:12] [Info] Starting point sample: 507B5ACCB577F908D97155CD7A8F2827D7FF6752051D42D70AF33F6A80D4573F (255 bit range) [2019-03-04.21:09:12] [Info] Starting point sample: 5C45836A0BFB1EAE9FE807030A511FAF5AE30E1708E6E9AC4CEEEEEF0D85883E (255 bit range) each starting point key once random, next it starting working in series starting point key : 5B60A7D6CAC10CEF8FF0CD0F7D3D4D7E72265EA3564F3A7C4CEC060DD434BD5E next working : 5B60A7D6CAC10CEF8FF0CD0F7D3D4D7E72265EA3564F3A7C4CEC060DD434BD5f, ...60, ....61, .....62, ....63 starting point key : 507B5ACCB577F908D97155CD7A8F2827D7FF6752051D42D70AF33F6A80D4573F next working : 507B5ACCB577F908D97155CD7A8F2827D7FF6752051D42D70AF33F6A80D4573F ,... 40, ... 41, ...42 each starting point working in series what should be random, every second new starting point as random key should be in search pool have you all tested pinka... BitCrack ? have you seen this random style |
|
|
|
Rx480 has a limit ... You can't have -t higher than 256.
Oh ... it changes the form of things :-) well ... I wanted better :-) --- Is there someone here who would be able to convert the counting number of scanned keys in BitCrack into a counter showing the number of REMOTE keys to be scanned along with the estimated remaining time to complete? It would be more interesting information than the amount that was scanned. Unfortunately, I do not know the programming language completely, and my knowledge ends at the stage of compiling a ready solution with possible code change in the sources. I would be grateful for such a small addition. Please checkout the branch "remaining" at https://github.com/pikachunakapika/BitCrack. It also includes my changes for random starting points. With -r you get no ETA and remaining count. Hello all i notice, this random called update just start with random starting points instead of series starting points after 1st generates random starting points, each starting point start searching series, Random should be every second each every string random if you understand, its ok, if you need to understand more in details with example, feel free to ask |
|
|
|
There are many posts lately. It is a pity that none of them makes sense [luckily, at this time, regardless of it - I effectively scan 288000000000Mkey/s which may allow me and this time to win with all the conjectures and ideas that appear here]. Conclusions and questions are born in the same way ... I'll start with the conclusions: - torments of smallies donors are unnecessary with the idea that they will discover the public key and use 2step to get the private key ... This sum goes to the wallet and will not come back alone ... this will not result in the 33bit RAW PUBKEY that is necessary for the operation this method. - I will not agree with the fact that the version of BitCracka presented with the "-r" option in any way contributes to speeding up or facilitating (reading, increasing the chance) to obtain a key. The same functionality is obtained using the --share x / x command in the original version, which only differs from the aforementioned version in the way of searching various ranges (which are still dependent on luck and strength used to search and in the same large scope). It scans at the same speed, so the chances do not increase at all with the use of this option as someone has previously written. Now questions: - Birthdayparadox: what are you striving for? what message does this mass of data show you ... a lot of general data that is based on ... nothing. Show these scripts you used to generate these reports / what they are based on? - 2Step Giant: as part of curiosity in discovering the potential of this interesting feature I have recently delved into - I've found for training purposes three addresses from the TOP1000 largest BTC wallets, which have no more than five outgoing transactions and at the latest 5 years ago. I introduced RAWPUBKEYS to the Step 2 Giant script and using the possibility of using 1TB RAM I compiled the script to run on HASHTABLE (1ULL >> 33). To my surprise after two days when I looked to see what's going on in effect - I saw three private keys. My heart softened and I shivered. The amazement dropped when I converted the results to WIF and it turned out that the addresses for them were never used and have no transactions. My puzzle is that where did these keys come from if they do not belong to these 33bit RAWPUBKEYS? I started the script a second time and the result was identical. And as for the next versions you plan to implement: instead of focusing on something that an application already has - implement something that actually makes it better than the original. For example, an example of what I would like to IMPROVE would be to show the time remaining until the end of scanning of a given interval (based on the scanning speed and knowledge which scope is scanned) - simple and better, because the original does not exist 2step gaint i run under original script 1<<25 5 million used pubkeys found 2 keys when checked those 2 keys never used and never in my 5m pubkeys list repeat run same identical keys repeat with 1 <<26 , no result i think something wrong inside script, i mention compelete script only filtered 2 pubkeys which output privkey but never used in my above posts You are getting false positives which is normal with this version of the code and your big hashtable. Read recent posts of arulbero in this thread to understand why. Simplified said there are collisions in the hashtable. typedef struct hashtable_entry {
uint32_t x;
uint32_t exponent;
} hashtable_entry;
Here uint32_t x; is to small too prevent collisions. If you make it bigger you will also require more system memory. So you have to find a smart way or just verify each found match if it is a true positive. i have tested it with higher values too, need to of optimization i created issues inside your pull of bitcrack and modified for random, check that too |
|
|
|
There are many posts lately. It is a pity that none of them makes sense [luckily, at this time, regardless of it - I effectively scan 288000000000Mkey/s which may allow me and this time to win with all the conjectures and ideas that appear here]. Conclusions and questions are born in the same way ... I'll start with the conclusions: - torments of smallies donors are unnecessary with the idea that they will discover the public key and use 2step to get the private key ... This sum goes to the wallet and will not come back alone ... this will not result in the 33bit RAW PUBKEY that is necessary for the operation this method. - I will not agree with the fact that the version of BitCracka presented with the "-r" option in any way contributes to speeding up or facilitating (reading, increasing the chance) to obtain a key. The same functionality is obtained using the --share x / x command in the original version, which only differs from the aforementioned version in the way of searching various ranges (which are still dependent on luck and strength used to search and in the same large scope). It scans at the same speed, so the chances do not increase at all with the use of this option as someone has previously written. Now questions: - Birthdayparadox: what are you striving for? what message does this mass of data show you ... a lot of general data that is based on ... nothing. Show these scripts you used to generate these reports / what they are based on? - 2Step Giant: as part of curiosity in discovering the potential of this interesting feature I have recently delved into - I've found for training purposes three addresses from the TOP1000 largest BTC wallets, which have no more than five outgoing transactions and at the latest 5 years ago. I introduced RAWPUBKEYS to the Step 2 Giant script and using the possibility of using 1TB RAM I compiled the script to run on HASHTABLE (1ULL >> 33). To my surprise after two days when I looked to see what's going on in effect - I saw three private keys. My heart softened and I shivered. The amazement dropped when I converted the results to WIF and it turned out that the addresses for them were never used and have no transactions. My puzzle is that where did these keys come from if they do not belong to these 33bit RAWPUBKEYS? I started the script a second time and the result was identical. And as for the next versions you plan to implement: instead of focusing on something that an application already has - implement something that actually makes it better than the original. For example, an example of what I would like to IMPROVE would be to show the time remaining until the end of scanning of a given interval (based on the scanning speed and knowledge which scope is scanned) - simple and better, because the original does not exist 2step gaint i run under original script 1<<25 5 million used pubkeys found 2 keys when checked those 2 keys never used and never in my 5m pubkeys list repeat run same identical keys repeat with 1 <<26 , no result i think something wrong inside script, i mention compelete script only filtered 2 pubkeys which output privkey but never used in my above posts |
|
|
|
https://gist.github.com/jhoenicke/2e39b3c6c49b1d7b216b8626197e4b89In practice, you will not compile an executable script for this task (where you also need to change #define GSTEP (1 << 25)) to #define GSTEP (1UL << 60) In the original version of the script it looks like this: 2 ^ 25 * 2 * 8/1024/1024 = 512 MB #Required RAM memory
* 2 * 8/1024/1024 = 17592186044416 MB (seventeen trillion five hundred ninety-two billion one hundred eighty-six million forty-four thousand four hundred sixteen megabytes) #Required RAMSo ... if you do not have this amount of RAM - you will not use this method. Look at the original code: https://gist.github.com/jhoenicke/2e39b3c6c49b1d7b216b8626197e4b89/* giant steps are 2^25 */
#define GSTEP (1<<25)
#define NUMPUBKEYS 51
unsigned char rawpubkeys[NUMPUBKEYS][33] ...
As you can see, to search the key #51 (from 2^50 to 2^51) you need a number of giant steps (and baby steps) equal to 2^25 (not to 2^51!) if you look at the hash table: typedef struct hashtable_entry {
uint32_t x;
uint32_t exponent;
} hashtable_entry;
#define HASH_SIZE (2*GSTEP)
hashtable_entry table[HASH_SIZE];
each entry size is 32 bit + 32 bit = 64 bit = 8 byte. The size of the hash table is 2*GSTEP, 2^26 entries. So for the original script: 8 byte * 2^26 = 2^29 bytes, 512 MB. If you change GSTEP from 2^25 to 2^26, you can find the keys #51 and #52 too (if you have more than 1 GB). It is not correct at all saying that at the current level we need 2^60 giant steps / 2^60 baby steps!I did many other modifications to the code. I can have a max number of giant steps (for my RAM) equal to 2^30, if I need to search in a bigger space than 2^60 I have to split then the baby step lists ( I generate first a hash table with a part of the list, then I delete it and I create another one, and so on). This way the program becomes very slow, I can retrieve a key in a 2^60 space in a very short time, but not over the 2^70 (unless I accept to wait days to have the result). #include "libsecp256k1-config.h" #include <stdio.h> #include <stdlib.h> #include <string.h> #include <time.h> #include "include/secp256k1.h" #include "secp256k1.c" /* giant steps are 2^25 */ #define GSTEP (1<<25) #define NUMPUBKEYS 2 unsigned char rawpubkeys[NUMPUBKEYS][33] = { { 0x02,0xb5,0x46,0x83,0x8d,0xac,0xee,0xeb,0x60,0x80,0x37,0xb8,0x9b,0xec,0x2f,0xf7,0xa5,0x96,0x6e,0x8d,0x91,0xd9,0xab,0x0d,0xc6,0xd1,0x28,0x04,0xee,0xde,0x9b,0xfc,0x50 }, { 0x02,0x7e,0x2a,0x3d,0x1b,0x2f,0x70,0xc0,0x74,0x45,0xb9,0xbe,0x04,0x8b,0xae,0xdd,0xc9,0xa7,0xcb,0xfd,0x9f,0xb9,0x96,0xc9,0x1b,0x12,0xc5,0xa1,0x84,0x76,0x30,0x77,0x3e }, }; typedef struct hashtable_entry { uint32_t x; uint32_t exponent; } hashtable_entry; #define HASH_SIZE (2*GSTEP) hashtable_entry table[HASH_SIZE]; secp256k1_ge pubkeys[NUMPUBKEYS]; int main(int argc, char **argv) { secp256k1_context *ctx = secp256k1_context_create(SECP256K1_CONTEXT_NONE); int next = 0; for (int i = 0; i < NUMPUBKEYS; i++) { if (!secp256k1_eckey_pubkey_parse(&pubkeys , rawpubkeys, 33)) {
printf("Unparsable pubkey %2d\n", i);
return -1;
}
}
printf("Build Hash\n");
secp256k1_gej pt;
secp256k1_gej_set_ge(&pt, &secp256k1_ge_const_g);
for (size_t i = 1; i < GSTEP; i++) {
secp256k1_fe x,zinv;
secp256k1_fe_storage xst;
secp256k1_fe_inv_var(&zinv, &pt.z);
secp256k1_fe_sqr(&zinv, &zinv);
secp256k1_fe_mul(&x, &pt.x, &zinv);
secp256k1_fe_to_storage(&xst, &x);
uint32_t entry = xst.n[0] & (HASH_SIZE-1);
while (table[entry].exponent != 0) {
entry = (entry + (xst.n[1] | 1)) & (HASH_SIZE - 1);
}
table[entry].exponent = i;
table[entry].x = xst.n[2];
secp256k1_gej_add_ge_var(&pt, &pt, &secp256k1_ge_const_g, NULL);
}
printf("Search Keys\n");
secp256k1_ge ptgstep;
secp256k1_gej_neg(&pt, &pt);
secp256k1_gej_double_var(&pt, &pt, NULL);
secp256k1_ge_set_gej(&ptgstep, &pt);
secp256k1_gej_set_infinity(&pt);
for (size_t i = 0; i < 2*GSTEP; i++) {
for (int j = next; j < NUMPUBKEYS; j++) {
secp256k1_gej diff;
secp256k1_fe x,zinv;
secp256k1_fe_storage xst;
secp256k1_gej_add_ge_var(&diff, &pt, &pubkeys[j], NULL);
secp256k1_fe_inv_var(&zinv, &diff.z);
secp256k1_fe_sqr(&zinv, &zinv);
secp256k1_fe_mul(&x, &diff.x, &zinv);
secp256k1_fe_to_storage(&xst, &x);
uint32_t entry = xst.n[0] & (HASH_SIZE-1);
while (table[entry].exponent != 0) {
if (table[entry].x == (uint32_t) xst.n[2]) {
uint64_t key = (uint64_t) i * (uint64_t) (2 * GSTEP);
printf("Found private key %2d: %16lx or %16lx\n", j + 1,
key - table[entry].exponent,
key + table[entry].exponent);
next++;
if (next == NUMPUBKEYS)
return 0;
}
entry = (entry + (xst.n[1] | 1)) & (HASH_SIZE - 1);
}
if (j == next)
break;
}
secp256k1_gej_add_ge_var(&pt, &pt, &ptgstep, NULL);
}
return 0;
}
|
|
|
|
@zielar: it is possible, I used the baby step giant step algorithm to retrieve the key #60 in about 80 seconds. And I have 32 GB ram. space search for each key of the puzzle transaction: key #1 : from 1 to 1 (2^0 -> 2^1 - 1) key #2 : from 2 to 3 (2^1 -> 2^2 - 1) key #3 : from 4 to 7 (2^2 -> 2^3 - 1) key #4 : from 8 to 15 (2^3 -> 2^4 - 1) .... key #60: from 2^59 to 2^60 - 1 Let's say for semplicity that our space search in this case is 2^60 (actually is only half, 2^59). P is the public key, we want to find the private key k. If G is the generator of the curve, the private key k is the number : k*G = P baby-step-giant-step (--> http://andrea.corbellini.name/2015/06/08/elliptic-curve-cryptography-breaking-security-and-a-comparison-with-rsa/): you create two lists, the first one (the baby steps list) in a hash table stored in the Ram and the second one (the giant steps list) dynamic: a) ( baby steps list): each baby step is equal to 1 (the distance between 2 consecutive elements is 1*G) and we store all these public keys: (0G), 1*G, 2*G, 3*G, 4*G, 5*G, ..., 2^30*G (because sqrt(2^60) = 2^30) in a hash table b) ( giant steps list): each giant step is equal to the sqrt(space size), in our case sqrt(2^60) = 2^30, namely the distance between 2 elements is 2^30*G . We generate on fly this list: P, P - 2^30*G, P - 2*2^30*G, P - 3*2^30*G, P - 4*2^30*G, P - 5*2^30*G, ....., P - (2^30 - 1)*2^30*G and we check if there is a element in the giant-steps list equal to an element in the baby-steps list. If for example P - 5*2^30*G = 1000*G, then P = 5*2^30*G + 1000*G --> P = (5*2^30 + 1000) * G --> private key k = (5*2^30 + 1000)2 lists, 2^30 elements * 2^30 elements = 2^60 comparisons without doing 2^60 operations, this is the trick. Hash table: 2^30 entries, each entry has the coordinate x of the public key (256 bit) + the number of the private key (max 32 bit). I'm using only the first 32 bits of the x instead of 256 bits (there are only few false collisions looking at the first 32 bits and I check these collisions), then I need to store (32 + 32) * 2^30 bit, 2^36 bit, 8 GByte. The hash table actually has to have the double of the number of the keys in the baby steps list (to avoid collisions between two different "x" that share the same 32 bits), so I need at least 16 GByte. With some other optimizations (the search space is actually 2^59 and not 2^60 + other properties of the secp256k1 curve), I can run the program. When the search space is greater than 60 bit, let's say 62 bit, I can't store all the 2^31 public keys of the baby steps list at once in the Ram, then I split 2^31 in 2 lists of 2^30 elements, A e B, then first I check the entire giant steps list against the list A, and if there is no match, I generate the list B and I generate again the giant steps list. in this script, pubkeys, where from you get pubkeys ? |
|
|
|
Is that correct?
add 61
from: dec:1152921504606846976- hex:1000000000000000
to: dec:2305843009213693953- hex:2000000000000001
add62
from: dec:2305843009213693953 - hex:2000000000000001
to: dec:4611686018427387904 - hex:4000000000000000
addr63
from: dec:4611686018427387904- hex:4000000000000000
to: dec:9223372036854775808 - hex:8000000000000000
addr64
from: dec:9223372036854775808 - hex: 8000000000000000
to: dec:18446744073709551616 - hex:010000000000000000
addr65
from: dec:18446744073709551616 - hex:010000000000000000
to: dec:36893488147419103232 - hex: 020000000000000000
Addr61Range 0x1000000000000000:0x1FFFFFFFFFFFFFFF Addr62Range 0x2000000000000000:0x2FFFFFFFFFFFFFFF Etc Tks How do you share works among your cards? We can PM if you wish. Hello I created the addrdata.txt file with 45,000 abandoned addresses, including those of the puzzle I am currently scanning address 61 bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096 All help and tips are welcome! :-D Hi Netlakes in you command: bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096 with -d 1 you use one card. I understand you have 36 rx480, right? (newbies can't PM you lol ) Yes, i have 6 rigs with 6 rx480 each for each rig i run multiple instances like that: bc.exe -c -u -d 1 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096 bc.exe -c -u -d 2 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096 bc.exe -c -u -d 3 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096 bc.exe -c -u -d 4 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096 bc.exe -c -u -d 5 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096 bc.exe -c -u -d 6 --keyspace 1000000000000000:1FFFFFFFFFFFFFFF -i addrdata.txt -o ohmygodimrich.txt -b 36 -t 256 -p 4096 This way you are scanning the same range 1000000000000000:1FFFFFFFFFFFFFFF for all cards !!!! that's no good. the range 1000000000000000:1FFFFFFFFFFFFFFF should be split equally, you could do it manually or using the command --share M/N for each rig. for sure! I'm setting it up again! I'll add also added --continue last.txt OK I suppose you are getting around 100Mkeys/sec search rate per GPU? So with 36*100 Mkeys/sec and if we assume that the private key for puzzle #61 is at mid range between 0x10000000000000 and 0x1FFFFFFFFFFFFFFF, you should expect to find this key in 5 years. 5 years pass quickly :-D LOL i have 40Mkeys per gpu(Is there any way to improve?) use b 36 t 512 p 2304 |
|
|
|
|
some one write about monday, and then delete post, why ?
|
|
|
|
What has this to do with this Puzzle transaction we discuss in this thread?
Dear Sir i apologies if my question is not related to thread, i like to explain why i ask these question comes in my mind related to this thread, 1. every one posting here about random search scripts, some post about brute force techniques, some trying to explain logics for find 32 BTC PUZZLE 2. above my posted link, when explorer, you will find some services used by website, who offer protection for btc coins, what technique used is split btc into pieces and transfers to new series generated accounts, then more splits into new series generated accounts, all generated accounts are same time in seconds, (mean no manual transaction one by one), 3 same in 32 BTC PUZZLE series of satochi transferd to newly generated accounts same time with sequence of each satoshi plus in series of bit space 4 in 59 and 60 bit space, peoples need to explorer by brute force or random etc equal to total hardware used for btc minning in Ph/s, 5 for this reason people must think an other ways to definatly in formula by math, by brainwallet, logics will help 6 for path and ref , i post links for other to think and find solutions deeply by explorer links 7 for deep leaning inside for solve PUZZLE, IN MY VIEW , above and this link could change thinking, and aproch to solve puzzle 8 https://www.blockchain.com/btc/tx/1d6580dcd979951bd600252b741c22a3ea8e605e43168f8452c68915c3ea2bf3 RETURN PUSHDATA(60)[424553544d495845522e494f207c204d495820594f555220424954434f494e5320544f2053544159205341464520414e442050524f54454354454421] (decoded) BESTMIXER.IO | MIX YOUR BITCOINS TO STAY SAFE AND PROTECTED! 9 bestmixer.io workstyle happen in 32 BTC PUZZLE and recenet transaction of https://www.blockchain.com/btc/address/1Ko8t47Mkvq8vyT2XgqLmdouVxM8tTryc10 IN MY VIEW, brainwallet char series by formula \ calculation of series by formula, could generate address in all Bit Space, etc, and work arund this may fruitfull instead of brute force by series or random Sir if you feel Good about my refrence of research related to Solve PUZZLE, encourage me with thumb up, in other just update me, i will remove my post, like to say apologies again |
|
|
|
just want to know main 66000 btc picked up by key finder, or owner moving itself after long time ? Correct. So? what is your point? |
|
|
|
174176B015F4D
22BD43C2E9354
75070A1A009D4
EFAE164CB9E3C
180788E47E326C
236FB6D5AD1F44
6ABE1F9B67E114
9D18B63AC4FFDF
1EB25C90795D61C
2C675B852189A21
9?...................... <=== next key trophy
but not good I have not studied the address space you are talking about because I daresay that even more people are doing it now than I can imagine, so I walked to the indicated threshold. I do not see the point that 100 people would check the same range. I think that as someone wrote earlier here - we could open up a little with each other and somehow cooperate. Sorry but you are not on the right path; look at the binary pattern: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0011 1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0111 19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1000 1EhqbyUMvvs7BfL8goY6qcPbD6YKfPqb7e 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0101 1E6NuFjCi27W5zoXg8TRdcSRq84zJeBW3k 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0011 0001 1PitScNLyp2HCygzadCh7FveTnfmpPbfp8 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0100 1100 1McVt1vMtCC7yn5b9wgX1833yCcLXzueeC 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1110 0000 1M92tSqNmQLYw33fuBvjmeadirh1ysMBxK 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 1101 0011 1CQFwcjw1dwhtkVWBttNLDtqL7ivBonGPV 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0010 0000 0010 1LeBZP5QCwwgXRtmVUvTVrraqPUokyLHqe 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0100 1000 0011 1PgQVLmst3Z314JrQn5TNiys8Hc38TcXJu 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1010 0111 1011 1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0100 0110 0000 1Pie8JkxBT6MGPz9Nvi3fsPkr2D8q3GBc1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0010 1001 0011 0000 1ErZWg5cFCe4Vw5BzgfzB74VNLaXEiEkhk 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0110 1000 1111 0011 1QCbW9HWnwQWiQqVo5exhAnmfqKRrCRsvW 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1100 1001 0011 0110 1BDyrQ6WoF8VN3g9SAS1iKZcPzFfnDVieY 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0111 0110 0100 1111 1HduPEXZRdG26SUT5Yk83mLkPyjnZuJ7Bm 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0011 0000 1000 0000 1101 1GnNTmTVLZiqQfLbAdp9DVdicEnB5GoERE 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0101 0111 0100 1001 1111 1NWmZRpHH4XSPwsW6dsS3nrNWfL1yrJj4w 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1101 0010 1100 0101 0101 1HsMJxNiV7TLxmoF6uJNkydxPFDog4NQum 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 1011 1010 0101 0011 0100 14oFNXucftsHiUMY8uctg6N487riuyXs4h 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0010 1101 1110 0100 0000 1111 1CfZWK1QTQE3eS9qn61dQjV89KDjZzfNcv 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0101 0101 0110 1110 0101 0010 1L2GM8eE7mJWLdo3HZS6su1832NX2txaac 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1101 1100 0010 1010 0000 0100 1rSnXMr63jdCuegJFuidJqWxUPV7AtUf7 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 1111 1010 0101 1110 1110 0101 15JhYXn6Mx3oF4Y7PcTAv2wVVAuCFFQNiP 0000 0000 0000 0000 0000 0000 0000 0000 0000 0011 0100 0000 0011 0010 0110 1110 1JVnST957hGztonaWK6FougdtjxzHzRMMg 0000 0000 0000 0000 0000 0000 0000 0000 0000 0110 1010 1100 0011 1000 0111 0101 128z5d7nN7PkCuX5qoA4Ys6pmxUYnEy86k 0000 0000 0000 0000 0000 0000 0000 0000 0000 1101 1001 0001 0110 1100 1110 1000 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY 0000 0000 0000 0000 0000 0000 0000 0000 0001 0111 1110 0010 0101 0101 0001 1110 19EEC52krRUK1RkUAEZmQdjTyHT7Gp1TYT 0000 0000 0000 0000 0000 0000 0000 0000 0011 1101 1001 0100 1100 1101 0110 0100 1LHtnpd8nU5VHEMkG2TMYYNUjjLc992bps 0000 0000 0000 0000 0000 0000 0000 0000 0111 1101 0100 1111 1110 0111 0100 0111 1LhE6sCTuGae42Axu1L1ZB7L96yi9irEBE 0000 0000 0000 0000 0000 0000 0000 0000 1011 1000 0110 0010 1010 0110 0010 1110 1FRoHA9xewq7DjrZ1psWJVeTer8gHRqEvR 0000 0000 0000 0000 0000 0000 0000 0001 1010 1001 0110 1100 1010 1000 1101 1000 187swFMjz1G54ycVU56B7jZFHFTNVQFDiu 0000 0000 0000 0000 0000 0000 0000 0011 0100 1010 0110 0101 1001 0001 0001 1101 1PWABE7oUahG2AFFQhhvViQovnCr4rEv7Q 0000 0000 0000 0000 0000 0000 0000 0100 1010 1110 1101 0010 0001 0001 0111 0000 1PWCx5fovoEaoBowAvF5k91m2Xat9bMgwb 0000 0000 0000 0000 0000 0000 0000 1001 1101 1110 1000 0010 0000 1010 0111 1100 1Be2UF9NLfyLFbtm3TCbmuocc9N1Kduci1 0000 0000 0000 0000 0000 0000 0001 0111 0101 0111 0111 0101 0110 1010 1001 0011 14iXhn8bGajVWegZHJ18vJLHhntcpL4dex 0000 0000 0000 0000 0000 0000 0010 0010 0011 1000 0010 1111 1010 1100 1101 0000 1HBtApAFA9B2YZw3G2YKSMCtb3dVnjuNe2 0000 0000 0000 0000 0000 0000 0100 1011 0101 1111 1000 0011 0000 0011 1110 1001 122AJhKLEfkFBaGAd84pLp1kfE7xK3GdT8 0000 0000 0000 0000 0000 0000 1110 1001 1010 1110 0100 1001 0011 0011 1101 0110 1EeAxcprB2PpCnr34VfZdFrkUWuxyiNEFv 0000 0000 0000 0000 0000 0001 0101 0011 1000 0110 1001 1010 1100 1100 0101 1011 1L5sU9qvJeuwQUdt4y1eiLmquFxKjtHr3E 0000 0000 0000 0000 0000 0010 1010 0010 0010 0001 1100 0101 1000 1101 1000 1111 1E32GPWgDyeyQac4aJxm9HVoLrrEYPnM4N 0000 0000 0000 0000 0000 0110 1011 1101 0011 1011 0010 0111 1100 0101 1001 0001 1PiFuqGpG8yGM5v6rNHWS3TjsG6awgEGA1 0000 0000 0000 0000 0000 1110 0000 0010 1011 0011 0101 1010 0011 0101 1000 1111 1CkR2uS7LmFwc3T2jV8C1BhWb5mQaoxedF 0000 0000 0000 0000 0001 0010 0010 1111 1100 1010 0001 0100 0011 1100 0000 0101 1NtiLNGegHWE3Mp9g2JPkgx6wUg4TW7bbk 0000 0000 0000 0000 0010 1110 1100 0001 1000 0011 1000 1000 1101 0101 0100 0100 1F3JRMWudBaj48EhwcHDdpeuy2jwACNxjP 0000 0000 0000 0000 0110 1100 1101 0110 0001 0000 1011 0101 0011 1100 1011 1010 1Pd8VvT49sHKsmqrQiP61RsVwmXCZ6ay7Z 0000 0000 0000 0000 1010 1101 1110 0110 1101 0111 1100 1110 0011 1011 1001 1011 1DFYhaB2J9q1LLZJWKTnscPWos9VBqDHzv 0000 0000 0000 0001 0111 0100 0001 0111 0110 1011 0000 0001 0101 1111 0100 1101 12CiUhYVTTH33w3SPUBqcpMoqnApAV4WCF 0000 0000 0000 0010 0010 1011 1101 0100 0011 1100 0010 1110 1001 0011 0101 0100 1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk 0000 0000 0000 0111 0101 0000 0111 0000 1010 0001 1010 0000 0000 1001 1101 0100 1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS 0000 0000 0000 1110 1111 1010 1110 0001 0110 0100 1100 1011 1001 1110 0011 1100 15z9c9sVpu6fwNiK7dMAFgMYSK4GqsGZim 0000 0000 0001 1000 0000 0111 1000 1000 1110 0100 0111 1110 0011 0010 0110 1100 15K1YKJMiJ4fpesTVUcByoz334rHmknxmT 0000 0000 0010 0011 0110 1111 1011 0110 1101 0101 1010 1101 0001 1111 0100 0110 19LeLQDmSR8nxFa4v7UdX9SC41mdxP6Rx9 0000 0000 0110 1010 1011 1110 0001 1111 1001 1011 0110 0111 1110 0001 0001 0100 1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa 0000 0000 1001 1101 0001 1000 1011 0110 0011 1010 1100 0100 1111 1111 1101 1111 17aPYR1m6pVAacXg1PTDDU7XafvK1dxvhi 0000 0001 1110 1011 0010 0101 1100 1001 0000 0111 1001 0101 1101 0110 0001 1100 15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz 0000 0010 1100 0110 0111 0101 1011 1000 0101 0010 0001 1000 1001 1010 0010 0001 1Dn8NF8qDyyfHMktmuoQLGyjWmZXgvosXf 0000 01xx 1HAX2n9Uruu9YDt4cqRgYcvtGvZj1rbUyt 0000 1xxx 1Kn5h2qpgw9mWE5jKpk8PP4qvvJ1QVy8su Each key has one higher bit (equal to 1) than the previous key. You cannot have a key starting with 9 for case #59. case #59 starts with either a 4,5,6 or 7 case #60 starts with either 8,9,A,B,C,D,E or F So if you are right, you scanned 1/8th the range of case #60 ... how long did it take you and how many and what kind of GPU's do you run? 0000 0001 1110 1011 0010 0101 1100 1001 0000 0111 1001 0101 1101 0110 0001 1100 15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz 0000 0010 1100 0110 0111 0101 1011 1000 0101 0010 0001 1000 1001 1010 0010 0001 1Dn8NF8qDyyfHMktmuoQLGyjWmZXgvosXf were 2c67 next will be 58ce why 58CE ? GeForce GTX 460 516/964MB | 1 target 44.96 MKey/s (1,250,763,931,648 total) [07:43:44] working with low hardware, if any one found with 58ce, 58c3, send me i need better system and hardware, thankx |
|
|
|
174176B015F4D
22BD43C2E9354
75070A1A009D4
EFAE164CB9E3C
180788E47E326C
236FB6D5AD1F44
6ABE1F9B67E114
9D18B63AC4FFDF
1EB25C90795D61C
2C675B852189A21
9?...................... <=== next key trophy
but not good I have not studied the address space you are talking about because I daresay that even more people are doing it now than I can imagine, so I walked to the indicated threshold. I do not see the point that 100 people would check the same range. I think that as someone wrote earlier here - we could open up a little with each other and somehow cooperate. Sorry but you are not on the right path; look at the binary pattern: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 1BgGZ9tcN4rm9KBzDn7KprQz87SZ26SAMH 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0011 1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0111 19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1000 1EhqbyUMvvs7BfL8goY6qcPbD6YKfPqb7e 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0101 1E6NuFjCi27W5zoXg8TRdcSRq84zJeBW3k 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0011 0001 1PitScNLyp2HCygzadCh7FveTnfmpPbfp8 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0100 1100 1McVt1vMtCC7yn5b9wgX1833yCcLXzueeC 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1110 0000 1M92tSqNmQLYw33fuBvjmeadirh1ysMBxK 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 1101 0011 1CQFwcjw1dwhtkVWBttNLDtqL7ivBonGPV 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0010 0000 0010 1LeBZP5QCwwgXRtmVUvTVrraqPUokyLHqe 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0100 1000 0011 1PgQVLmst3Z314JrQn5TNiys8Hc38TcXJu 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1010 0111 1011 1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0100 0110 0000 1Pie8JkxBT6MGPz9Nvi3fsPkr2D8q3GBc1 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0010 1001 0011 0000 1ErZWg5cFCe4Vw5BzgfzB74VNLaXEiEkhk 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0110 1000 1111 0011 1QCbW9HWnwQWiQqVo5exhAnmfqKRrCRsvW 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1100 1001 0011 0110 1BDyrQ6WoF8VN3g9SAS1iKZcPzFfnDVieY 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 0111 0110 0100 1111 1HduPEXZRdG26SUT5Yk83mLkPyjnZuJ7Bm 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0011 0000 1000 0000 1101 1GnNTmTVLZiqQfLbAdp9DVdicEnB5GoERE 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0101 0111 0100 1001 1111 1NWmZRpHH4XSPwsW6dsS3nrNWfL1yrJj4w 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1101 0010 1100 0101 0101 1HsMJxNiV7TLxmoF6uJNkydxPFDog4NQum 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 1011 1010 0101 0011 0100 14oFNXucftsHiUMY8uctg6N487riuyXs4h 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0010 1101 1110 0100 0000 1111 1CfZWK1QTQE3eS9qn61dQjV89KDjZzfNcv 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0101 0101 0110 1110 0101 0010 1L2GM8eE7mJWLdo3HZS6su1832NX2txaac 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 1101 1100 0010 1010 0000 0100 1rSnXMr63jdCuegJFuidJqWxUPV7AtUf7 0000 0000 0000 0000 0000 0000 0000 0000 0000 0001 1111 1010 0101 1110 1110 0101 15JhYXn6Mx3oF4Y7PcTAv2wVVAuCFFQNiP 0000 0000 0000 0000 0000 0000 0000 0000 0000 0011 0100 0000 0011 0010 0110 1110 1JVnST957hGztonaWK6FougdtjxzHzRMMg 0000 0000 0000 0000 0000 0000 0000 0000 0000 0110 1010 1100 0011 1000 0111 0101 128z5d7nN7PkCuX5qoA4Ys6pmxUYnEy86k 0000 0000 0000 0000 0000 0000 0000 0000 0000 1101 1001 0001 0110 1100 1110 1000 12jbtzBb54r97TCwW3G1gCFoumpckRAPdY 0000 0000 0000 0000 0000 0000 0000 0000 0001 0111 1110 0010 0101 0101 0001 1110 19EEC52krRUK1RkUAEZmQdjTyHT7Gp1TYT 0000 0000 0000 0000 0000 0000 0000 0000 0011 1101 1001 0100 1100 1101 0110 0100 1LHtnpd8nU5VHEMkG2TMYYNUjjLc992bps 0000 0000 0000 0000 0000 0000 0000 0000 0111 1101 0100 1111 1110 0111 0100 0111 1LhE6sCTuGae42Axu1L1ZB7L96yi9irEBE 0000 0000 0000 0000 0000 0000 0000 0000 1011 1000 0110 0010 1010 0110 0010 1110 1FRoHA9xewq7DjrZ1psWJVeTer8gHRqEvR 0000 0000 0000 0000 0000 0000 0000 0001 1010 1001 0110 1100 1010 1000 1101 1000 187swFMjz1G54ycVU56B7jZFHFTNVQFDiu 0000 0000 0000 0000 0000 0000 0000 0011 0100 1010 0110 0101 1001 0001 0001 1101 1PWABE7oUahG2AFFQhhvViQovnCr4rEv7Q 0000 0000 0000 0000 0000 0000 0000 0100 1010 1110 1101 0010 0001 0001 0111 0000 1PWCx5fovoEaoBowAvF5k91m2Xat9bMgwb 0000 0000 0000 0000 0000 0000 0000 1001 1101 1110 1000 0010 0000 1010 0111 1100 1Be2UF9NLfyLFbtm3TCbmuocc9N1Kduci1 0000 0000 0000 0000 0000 0000 0001 0111 0101 0111 0111 0101 0110 1010 1001 0011 14iXhn8bGajVWegZHJ18vJLHhntcpL4dex 0000 0000 0000 0000 0000 0000 0010 0010 0011 1000 0010 1111 1010 1100 1101 0000 1HBtApAFA9B2YZw3G2YKSMCtb3dVnjuNe2 0000 0000 0000 0000 0000 0000 0100 1011 0101 1111 1000 0011 0000 0011 1110 1001 122AJhKLEfkFBaGAd84pLp1kfE7xK3GdT8 0000 0000 0000 0000 0000 0000 1110 1001 1010 1110 0100 1001 0011 0011 1101 0110 1EeAxcprB2PpCnr34VfZdFrkUWuxyiNEFv 0000 0000 0000 0000 0000 0001 0101 0011 1000 0110 1001 1010 1100 1100 0101 1011 1L5sU9qvJeuwQUdt4y1eiLmquFxKjtHr3E 0000 0000 0000 0000 0000 0010 1010 0010 0010 0001 1100 0101 1000 1101 1000 1111 1E32GPWgDyeyQac4aJxm9HVoLrrEYPnM4N 0000 0000 0000 0000 0000 0110 1011 1101 0011 1011 0010 0111 1100 0101 1001 0001 1PiFuqGpG8yGM5v6rNHWS3TjsG6awgEGA1 0000 0000 0000 0000 0000 1110 0000 0010 1011 0011 0101 1010 0011 0101 1000 1111 1CkR2uS7LmFwc3T2jV8C1BhWb5mQaoxedF 0000 0000 0000 0000 0001 0010 0010 1111 1100 1010 0001 0100 0011 1100 0000 0101 1NtiLNGegHWE3Mp9g2JPkgx6wUg4TW7bbk 0000 0000 0000 0000 0010 1110 1100 0001 1000 0011 1000 1000 1101 0101 0100 0100 1F3JRMWudBaj48EhwcHDdpeuy2jwACNxjP 0000 0000 0000 0000 0110 1100 1101 0110 0001 0000 1011 0101 0011 1100 1011 1010 1Pd8VvT49sHKsmqrQiP61RsVwmXCZ6ay7Z 0000 0000 0000 0000 1010 1101 1110 0110 1101 0111 1100 1110 0011 1011 1001 1011 1DFYhaB2J9q1LLZJWKTnscPWos9VBqDHzv 0000 0000 0000 0001 0111 0100 0001 0111 0110 1011 0000 0001 0101 1111 0100 1101 12CiUhYVTTH33w3SPUBqcpMoqnApAV4WCF 0000 0000 0000 0010 0010 1011 1101 0100 0011 1100 0010 1110 1001 0011 0101 0100 1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk 0000 0000 0000 0111 0101 0000 0111 0000 1010 0001 1010 0000 0000 1001 1101 0100 1NpnQyZ7x24ud82b7WiRNvPm6N8bqGQnaS 0000 0000 0000 1110 1111 1010 1110 0001 0110 0100 1100 1011 1001 1110 0011 1100 15z9c9sVpu6fwNiK7dMAFgMYSK4GqsGZim 0000 0000 0001 1000 0000 0111 1000 1000 1110 0100 0111 1110 0011 0010 0110 1100 15K1YKJMiJ4fpesTVUcByoz334rHmknxmT 0000 0000 0010 0011 0110 1111 1011 0110 1101 0101 1010 1101 0001 1111 0100 0110 19LeLQDmSR8nxFa4v7UdX9SC41mdxP6Rx9 0000 0000 0110 1010 1011 1110 0001 1111 1001 1011 0110 0111 1110 0001 0001 0100 1LzhS3k3e9Ub8i2W1V8xQFdB8n2MYCHPCa 0000 0000 1001 1101 0001 1000 1011 0110 0011 1010 1100 0100 1111 1111 1101 1111 17aPYR1m6pVAacXg1PTDDU7XafvK1dxvhi 0000 0001 1110 1011 0010 0101 1100 1001 0000 0111 1001 0101 1101 0110 0001 1100 15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz 0000 0010 1100 0110 0111 0101 1011 1000 0101 0010 0001 1000 1001 1010 0010 0001 1Dn8NF8qDyyfHMktmuoQLGyjWmZXgvosXf 0000 01xx 1HAX2n9Uruu9YDt4cqRgYcvtGvZj1rbUyt 0000 1xxx 1Kn5h2qpgw9mWE5jKpk8PP4qvvJ1QVy8su Each key has one higher bit (equal to 1) than the previous key. You cannot have a key starting with 9 for case #59. case #59 starts with either a 4,5,6 or 7 case #60 starts with either 8,9,A,B,C,D,E or F So if you are right, you scanned 1/8th the range of case #60 ... how long did it take you and how many and what kind of GPU's do you run? 0000 0001 1110 1011 0010 0101 1100 1001 0000 0111 1001 0101 1101 0110 0001 1100 15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz 0000 0010 1100 0110 0111 0101 1011 1000 0101 0010 0001 1000 1001 1010 0010 0001 1Dn8NF8qDyyfHMktmuoQLGyjWmZXgvosXf were 2c67 next will be 58ce |
|
|
|
|
Show Posts
