Whoever got address 61: AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB
is hittng on address 160: 1NBC8uXJy1GiJ6drkiZa1WuKn51ps7EPTv
it is 1LuckyTJHcLLTnmeDZFbc1E18ZW87k36tk
Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 226. (Read 192829 times)
address 61: AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB
Spent just now
https://www.blockchain.com/fr/btc/tx/cdae2da8fe4b18dc264e568a29e804f2b32529b8018a9d28e271ac7e9077c718
Spent just now
https://www.blockchain.com/fr/btc/tx/cdae2da8fe4b18dc264e568a29e804f2b32529b8018a9d28e271ac7e9077c718
What prevents solve 61 puzzle puzzles with a little trick and baby step giant step?
The trick will be as follows...we know the approximate closed keys at the edges of the puzzle ,we also can compute and plot of 2^60-2^61 divide them into equal shares ,and then send to these addresses small Satoshi ,since Satoshi come we do the reverse translation with the new address back ,thus we learn from these addresses, public keys ,and all of it will be possible to calculate the private key 61 of the puzzle.
The trick will be as follows...we know the approximate closed keys at the edges of the puzzle ,we also can compute and plot of 2^60-2^61 divide them into equal shares ,and then send to these addresses small Satoshi ,since Satoshi come we do the reverse translation with the new address back ,thus we learn from these addresses, public keys ,and all of it will be possible to calculate the private key 61 of the puzzle.
I think that sending anything to these addresses won't get you what you want.
Getting Spending scripts from these addresses is the only way baby step or giant step trick will work.
So, if you get the pvk, spend everything at once ... whatever you leave can be swept very quickly afterwards
In fact, the code in this puzzle, I think, is the 310 bitcoin private keys, and these private keys are scattered and hidden in the picture, like playing a puzzle game, to find them and put them together correctly! Sounds simple, but a little bit of cryptography knows how to work out the combination of private keys by manpower, and it is estimated that it will not be worked out by the day of entering the coffin. The last thing Lao Shi regrets in his life is that he didn't study hard at the beginning. If he could study hard at the beginning, he would develop towards cryptography experts or mathematicians. It's not a piece of cake to crack such puzzles. It's hard to knock on keyboards every day like now. Therefore, the folks who have become parents must educate their children to listen from an early age. Ha-ha.
Hidden in what picture?? I never saw a picture lol just the string of data. Is that what you mean?I think this guy just woke up
and is talking about some other puzzle solved a while ago : https://www.chepicap.com/en/news/4306/somebody-just-won-310-btc-bitcoin-challenge-solved-within-8-days.html
Ok.
I have made other tests you may want to look into. I suppose it is better to open issues on github rather than here?
Yes that would be great. I have enabled issues for the repository.
In fact, the code in this puzzle, I think, is the 310 bitcoin private keys, and these private keys are scattered and hidden in the picture, like playing a puzzle game, to find them and put them together correctly! Sounds simple, but a little bit of cryptography knows how to work out the combination of private keys by manpower, and it is estimated that it will not be worked out by the day of entering the coffin. The last thing Lao Shi regrets in his life is that he didn't study hard at the beginning. If he could study hard at the beginning, he would develop towards cryptography experts or mathematicians. It's not a piece of cake to crack such puzzles. It's hard to knock on keyboards every day like now. Therefore, the folks who have become parents must educate their children to listen from an early age. Ha-ha.
Hidden in what picture?? I never saw a picture lol just the string of data. Is that what you mean? OK thanks.
The integer read after the -r option seems to be a signed byte, can't go beyond 127 (you get a negative range)
Thanks! Fixed in current version.
Nice
)./clBitCrack -r 61 -d 1 -b 72 -t 256 -p 2048 --continue hup.txt -o res.txt 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB
And this is what I get in my continue file hup.txt
start=0000000000000000000000000000000000000000000000000000000000000001
next=00000000000000000000000000000000000000000000000000000004A4000001
end=FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140
blocks=72
threads=256
points=2048
compression=compressed
device=1
elapsed=344463
stride=0000000000000000000000000000000000000000000000000000000000000001
I suppose that in this context, continue file just tell me how many cases I ran .. right?
Yes you are right. This is not covered yet. I forgot continuation-file was a thing so this will get fixed with next update too.
Ok.
I have made other tests you may want to look into. I suppose it is better to open issues on github rather than here?
OK thanks.
The integer read after the -r option seems to be a signed byte, can't go beyond 127 (you get a negative range)
Thanks! Fixed in current version.
Nice
)./clBitCrack -r 61 -d 1 -b 72 -t 256 -p 2048 --continue hup.txt -o res.txt 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB
And this is what I get in my continue file hup.txt
start=0000000000000000000000000000000000000000000000000000000000000001
next=00000000000000000000000000000000000000000000000000000004A4000001
end=FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140
blocks=72
threads=256
points=2048
compression=compressed
device=1
elapsed=344463
stride=0000000000000000000000000000000000000000000000000000000000000001
I suppose that in this context, continue file just tell me how many cases I ran .. right?
Yes you are right. This is not covered yet. I forgot continuation-file was a thing so this will get fixed with next update too.
OK thanks.
The integer read after the -r option seems to be a signed byte, can't go beyond 127 (you get a negative range)
Thanks! Fixed in current version.
Nice
)./clBitCrack -r 61 -d 1 -b 72 -t 256 -p 2048 --continue hup.txt -o res.txt 1AVJKwzs9AskraJLGHAZPiaZcrpDr1U6AB
And this is what I get in my continue file hup.txt
start=0000000000000000000000000000000000000000000000000000000000000001
next=00000000000000000000000000000000000000000000000000000004A4000001
end=FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140
blocks=72
threads=256
points=2048
compression=compressed
device=1
elapsed=344463
stride=0000000000000000000000000000000000000000000000000000000000000001
I suppose that in this context, continue file just tell me how many cases I ran .. right?
OK thanks.
The integer read after the -r option seems to be a signed byte, can't go beyond 127 (you get a negative range)
Thanks! Fixed in current version.
Nice
Next update will get rid of the
This will also optimize key initializing hopefully so it will start faster.
OK thanks.
The integer read after the -r option seems to be a signed byte, can't go beyond 127 (you get a negative range)
Thanks! Fixed in current version.
Nice
What prevents solve 61 puzzle puzzles with a little trick and baby step giant step?
The trick will be as follows...we know the approximate closed keys at the edges of the puzzle ,we also can compute and plot of 2^60-2^61 divide them into equal shares ,and then send to these addresses small Satoshi ,since Satoshi come we do the reverse translation with the new address back ,thus we learn from these addresses, public keys ,and all of it will be possible to calculate the private key 61 of the puzzle.
The trick will be as follows...we know the approximate closed keys at the edges of the puzzle ,we also can compute and plot of 2^60-2^61 divide them into equal shares ,and then send to these addresses small Satoshi ,since Satoshi come we do the reverse translation with the new address back ,thus we learn from these addresses, public keys ,and all of it will be possible to calculate the private key 61 of the puzzle.
https://gist.github.com/jhoenicke/2e39b3c6c49b1d7b216b8626197e4b89
In 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 ^ 60 * 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 RAM
So ... if you do not have this amount of RAM - you will not use this method.
In 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:
Code:
2 ^ 25 * 2 * 8/1024/1024 = 512 MB #Required RAM memory
For the current level:2 ^ 60 * 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 RAM
So ... 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
Code:
/* giant steps are 2^25 */
#define GSTEP (1<<25)
#define NUMPUBKEYS 51
unsigned char rawpubkeys[NUMPUBKEYS][33] ...
#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:
Code:
typedef struct hashtable_entry {
uint32_t x;
uint32_t exponent;
} hashtable_entry;
#define HASH_SIZE (2*GSTEP)
hashtable_entry table[HASH_SIZE];
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
#include
#include
#include
#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;
}
OK thanks.
The integer read after the -r option seems to be a signed byte, can't go beyond 127 (you get a negative range)
Thanks! Fixed in current version.
Hi guys,
In continuation to this thread: https://bitcointalksearch.org/topic/brute-force-on-bitcoin-addresses-video-of-the-action-1305887
While playing around with my bot, I found out this mysterious transaction:
https://blockchain.info/tx/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15
those 32.896 BTC were sent to multiple addresses, all the private keys of those addresses seem to be generated by some kind of formula.
For example:
Address 2:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU74sHUHy8S
1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb
Biginteger PVK value: 3
Hex PVK value: 3
Address 3:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU76rnZwVdz
19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA
Biginteger PVK value: 7
Hex PVK value: 7
Address 4:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU77MfhviY5
1EhqbyUMvvs7BfL8goY6qcPbD6YKfPqb7e
Biginteger PVK value: 8
Hex PVK value: 8
Address 5:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Dq8Au4Pv
1E6NuFjCi27W5zoXg8TRdcSRq84zJeBW3k
Biginteger PVK value: 21
Hex PVK value: 15
Address 6:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Tmu6qHxS
1PitScNLyp2HCygzadCh7FveTnfmpPbfp8
Biginteger PVK value: 49
Hex PVK value: 31
Address 7:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7hDgvu64y
1McVt1vMtCC7yn5b9wgX1833yCcLXzueeC
Biginteger PVK value: 76
Hex PVK value: 4C
Address 8:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU8xvGK1zpm
1M92tSqNmQLYw33fuBvjmeadirh1ysMBxK
Biginteger PVK value: 224
Hex PVK value: E0
Address 9:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUB3vfDKcxZ
1CQFwcjw1dwhtkVWBttNLDtqL7ivBonGPV
Biginteger PVK value: 467
Hex PVK value: 1d3
Address 10:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUBTL67V6dE
1LeBZP5QCwwgXRtmVUvTVrraqPUokyLHqe
Biginteger PVK value: 514
Hex PVK value: 202
Address 11:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUGxXgtm63M
1PgQVLmst3Z314JrQn5TNiys8Hc38TcXJu
Biginteger PVK value: 1155
Hex PVK value: 483
Address 12:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUW5RtS2JN1
1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot
Biginteger PVK value: 2683
Hex PVK value: a7b
Address 13:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUspniiQZds
1Pie8JkxBT6MGPz9Nvi3fsPkr2D8q3GBc1
Biginteger PVK value: 5216
Hex PVK value: 1460
Address 14:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFVfZyiN5iEG
1ErZWg5cFCe4Vw5BzgfzB74VNLaXEiEkhk
Biginteger PVK value: 10544
Hex PVK value: 2930
and so on...
until the addresses 50 (1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk) it was already cracked by someone.
Any ideas what's the formula behind the generation of these addresses?
Address 2, pvk decimal value: 3
Address 3, pvk decimal value: 7
Address 4, pvk decimal value: 8
Address 5, pvk decimal value: 21
Address 6, pvk decimal value: 49
Address 7, pvk decimal value: 76
Address 8, pvk decimal value: 224
Address 9, pvk decimal value: 467
Address 10, pvk decimal value: 514
Address 11, pvk decimal value: 1155
Address 12, pvk decimal value: 2683
Address 13, pvk decimal value: 5216
Address 14, pvk decimal value: 10544
Address 15 and after, pvk decimal value: ?
The prize would be ~32 BTC
EDIT: If you find the solution feel free to leave a tip 1DPUhjHvd2K4ZkycVHEJiN6wba79j5V1u3
Did anyone ever have any luck cracking these? In continuation to this thread: https://bitcointalksearch.org/topic/brute-force-on-bitcoin-addresses-video-of-the-action-1305887
While playing around with my bot, I found out this mysterious transaction:
https://blockchain.info/tx/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15
those 32.896 BTC were sent to multiple addresses, all the private keys of those addresses seem to be generated by some kind of formula.
For example:
Address 2:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU74sHUHy8S
1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb
Biginteger PVK value: 3
Hex PVK value: 3
Address 3:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU76rnZwVdz
19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA
Biginteger PVK value: 7
Hex PVK value: 7
Address 4:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU77MfhviY5
1EhqbyUMvvs7BfL8goY6qcPbD6YKfPqb7e
Biginteger PVK value: 8
Hex PVK value: 8
Address 5:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Dq8Au4Pv
1E6NuFjCi27W5zoXg8TRdcSRq84zJeBW3k
Biginteger PVK value: 21
Hex PVK value: 15
Address 6:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Tmu6qHxS
1PitScNLyp2HCygzadCh7FveTnfmpPbfp8
Biginteger PVK value: 49
Hex PVK value: 31
Address 7:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7hDgvu64y
1McVt1vMtCC7yn5b9wgX1833yCcLXzueeC
Biginteger PVK value: 76
Hex PVK value: 4C
Address 8:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU8xvGK1zpm
1M92tSqNmQLYw33fuBvjmeadirh1ysMBxK
Biginteger PVK value: 224
Hex PVK value: E0
Address 9:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUB3vfDKcxZ
1CQFwcjw1dwhtkVWBttNLDtqL7ivBonGPV
Biginteger PVK value: 467
Hex PVK value: 1d3
Address 10:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUBTL67V6dE
1LeBZP5QCwwgXRtmVUvTVrraqPUokyLHqe
Biginteger PVK value: 514
Hex PVK value: 202
Address 11:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUGxXgtm63M
1PgQVLmst3Z314JrQn5TNiys8Hc38TcXJu
Biginteger PVK value: 1155
Hex PVK value: 483
Address 12:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUW5RtS2JN1
1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot
Biginteger PVK value: 2683
Hex PVK value: a7b
Address 13:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUspniiQZds
1Pie8JkxBT6MGPz9Nvi3fsPkr2D8q3GBc1
Biginteger PVK value: 5216
Hex PVK value: 1460
Address 14:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFVfZyiN5iEG
1ErZWg5cFCe4Vw5BzgfzB74VNLaXEiEkhk
Biginteger PVK value: 10544
Hex PVK value: 2930
and so on...
until the addresses 50 (1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk) it was already cracked by someone.
Any ideas what's the formula behind the generation of these addresses?
Address 2, pvk decimal value: 3
Address 3, pvk decimal value: 7
Address 4, pvk decimal value: 8
Address 5, pvk decimal value: 21
Address 6, pvk decimal value: 49
Address 7, pvk decimal value: 76
Address 8, pvk decimal value: 224
Address 9, pvk decimal value: 467
Address 10, pvk decimal value: 514
Address 11, pvk decimal value: 1155
Address 12, pvk decimal value: 2683
Address 13, pvk decimal value: 5216
Address 14, pvk decimal value: 10544
Address 15 and after, pvk decimal value: ?
The prize would be ~32 BTC
EDIT: If you find the solution feel free to leave a tip
1DPUhjHvd2K4ZkycVHEJiN6wba79j5V1u3Read earlier posts .. We know all pvk's up to Address 60... Man, where were you?
Please explain more what " -r
"-r 61" will make all points start at a random offset in 61 bit range.
The 3 sample starting points are just for information/confirmation the correct range is used.
If your BitCrack is generating 37,748,736 starting points then each point starts at a random offset in 61 bit range.
It is easy to adjust the code now. Simply adjust in generateStartingPoints() function.
You can combine -r with --keyspace if you need to additional control.
Please "git pull" to get the latest version that also contains fixes.
OK thanks.
The integer read after the -r option seems to be a signed byte, can't go beyond 127 (you get a negative range)
In fact, the code in this puzzle, I think, is the 310 bitcoin private keys, and these private keys are scattered and hidden in the picture, like playing a puzzle game, to find them and put them together correctly! Sounds simple, but a little bit of cryptography knows how to work out the combination of private keys by manpower, and it is estimated that it will not be worked out by the day of entering the coffin. The last thing Lao Shi regrets in his life is that he didn't study hard at the beginning. If he could study hard at the beginning, he would develop towards cryptography experts or mathematicians. It's not a piece of cake to crack such puzzles. It's hard to knock on keyboards every day like now. Therefore, the folks who have become parents must educate their children to listen from an early age. Ha-ha.
Hi guys,
In continuation to this thread: https://bitcointalksearch.org/topic/brute-force-on-bitcoin-addresses-video-of-the-action-1305887
While playing around with my bot, I found out this mysterious transaction:
https://blockchain.info/tx/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15
those 32.896 BTC were sent to multiple addresses, all the private keys of those addresses seem to be generated by some kind of formula.
For example:
Address 2:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU74sHUHy8S
1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb
Biginteger PVK value: 3
Hex PVK value: 3
Address 3:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU76rnZwVdz
19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA
Biginteger PVK value: 7
Hex PVK value: 7
Address 4:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU77MfhviY5
1EhqbyUMvvs7BfL8goY6qcPbD6YKfPqb7e
Biginteger PVK value: 8
Hex PVK value: 8
Address 5:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Dq8Au4Pv
1E6NuFjCi27W5zoXg8TRdcSRq84zJeBW3k
Biginteger PVK value: 21
Hex PVK value: 15
Address 6:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Tmu6qHxS
1PitScNLyp2HCygzadCh7FveTnfmpPbfp8
Biginteger PVK value: 49
Hex PVK value: 31
Address 7:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7hDgvu64y
1McVt1vMtCC7yn5b9wgX1833yCcLXzueeC
Biginteger PVK value: 76
Hex PVK value: 4C
Address 8:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU8xvGK1zpm
1M92tSqNmQLYw33fuBvjmeadirh1ysMBxK
Biginteger PVK value: 224
Hex PVK value: E0
Address 9:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUB3vfDKcxZ
1CQFwcjw1dwhtkVWBttNLDtqL7ivBonGPV
Biginteger PVK value: 467
Hex PVK value: 1d3
Address 10:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUBTL67V6dE
1LeBZP5QCwwgXRtmVUvTVrraqPUokyLHqe
Biginteger PVK value: 514
Hex PVK value: 202
Address 11:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUGxXgtm63M
1PgQVLmst3Z314JrQn5TNiys8Hc38TcXJu
Biginteger PVK value: 1155
Hex PVK value: 483
Address 12:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUW5RtS2JN1
1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot
Biginteger PVK value: 2683
Hex PVK value: a7b
Address 13:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUspniiQZds
1Pie8JkxBT6MGPz9Nvi3fsPkr2D8q3GBc1
Biginteger PVK value: 5216
Hex PVK value: 1460
Address 14:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFVfZyiN5iEG
1ErZWg5cFCe4Vw5BzgfzB74VNLaXEiEkhk
Biginteger PVK value: 10544
Hex PVK value: 2930
and so on...
until the addresses 50 (1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk) it was already cracked by someone.
Any ideas what's the formula behind the generation of these addresses?
Address 2, pvk decimal value: 3
Address 3, pvk decimal value: 7
Address 4, pvk decimal value: 8
Address 5, pvk decimal value: 21
Address 6, pvk decimal value: 49
Address 7, pvk decimal value: 76
Address 8, pvk decimal value: 224
Address 9, pvk decimal value: 467
Address 10, pvk decimal value: 514
Address 11, pvk decimal value: 1155
Address 12, pvk decimal value: 2683
Address 13, pvk decimal value: 5216
Address 14, pvk decimal value: 10544
Address 15 and after, pvk decimal value: ?
The prize would be ~32 BTC
EDIT: If you find the solution feel free to leave a tip 1DPUhjHvd2K4ZkycVHEJiN6wba79j5V1u3
Did anyone ever have any luck cracking these? In continuation to this thread: https://bitcointalksearch.org/topic/brute-force-on-bitcoin-addresses-video-of-the-action-1305887
While playing around with my bot, I found out this mysterious transaction:
https://blockchain.info/tx/08389f34c98c606322740c0be6a7125d9860bb8d5cb182c02f98461e5fa6cd15
those 32.896 BTC were sent to multiple addresses, all the private keys of those addresses seem to be generated by some kind of formula.
For example:
Address 2:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU74sHUHy8S
1CUNEBjYrCn2y1SdiUMohaKUi4wpP326Lb
Biginteger PVK value: 3
Hex PVK value: 3
Address 3:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU76rnZwVdz
19ZewH8Kk1PDbSNdJ97FP4EiCjTRaZMZQA
Biginteger PVK value: 7
Hex PVK value: 7
Address 4:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU77MfhviY5
1EhqbyUMvvs7BfL8goY6qcPbD6YKfPqb7e
Biginteger PVK value: 8
Hex PVK value: 8
Address 5:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Dq8Au4Pv
1E6NuFjCi27W5zoXg8TRdcSRq84zJeBW3k
Biginteger PVK value: 21
Hex PVK value: 15
Address 6:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7Tmu6qHxS
1PitScNLyp2HCygzadCh7FveTnfmpPbfp8
Biginteger PVK value: 49
Hex PVK value: 31
Address 7:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU7hDgvu64y
1McVt1vMtCC7yn5b9wgX1833yCcLXzueeC
Biginteger PVK value: 76
Hex PVK value: 4C
Address 8:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU8xvGK1zpm
1M92tSqNmQLYw33fuBvjmeadirh1ysMBxK
Biginteger PVK value: 224
Hex PVK value: E0
Address 9:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUB3vfDKcxZ
1CQFwcjw1dwhtkVWBttNLDtqL7ivBonGPV
Biginteger PVK value: 467
Hex PVK value: 1d3
Address 10:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUBTL67V6dE
1LeBZP5QCwwgXRtmVUvTVrraqPUokyLHqe
Biginteger PVK value: 514
Hex PVK value: 202
Address 11:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUGxXgtm63M
1PgQVLmst3Z314JrQn5TNiys8Hc38TcXJu
Biginteger PVK value: 1155
Hex PVK value: 483
Address 12:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUW5RtS2JN1
1DBaumZxUkM4qMQRt2LVWyFJq5kDtSZQot
Biginteger PVK value: 2683
Hex PVK value: a7b
Address 13:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFUspniiQZds
1Pie8JkxBT6MGPz9Nvi3fsPkr2D8q3GBc1
Biginteger PVK value: 5216
Hex PVK value: 1460
Address 14:
KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFVfZyiN5iEG
1ErZWg5cFCe4Vw5BzgfzB74VNLaXEiEkhk
Biginteger PVK value: 10544
Hex PVK value: 2930
and so on...
until the addresses 50 (1MEzite4ReNuWaL5Ds17ePKt2dCxWEofwk) it was already cracked by someone.
Any ideas what's the formula behind the generation of these addresses?
Address 2, pvk decimal value: 3
Address 3, pvk decimal value: 7
Address 4, pvk decimal value: 8
Address 5, pvk decimal value: 21
Address 6, pvk decimal value: 49
Address 7, pvk decimal value: 76
Address 8, pvk decimal value: 224
Address 9, pvk decimal value: 467
Address 10, pvk decimal value: 514
Address 11, pvk decimal value: 1155
Address 12, pvk decimal value: 2683
Address 13, pvk decimal value: 5216
Address 14, pvk decimal value: 10544
Address 15 and after, pvk decimal value: ?
The prize would be ~32 BTC
EDIT: If you find the solution feel free to leave a tip
1DPUhjHvd2K4ZkycVHEJiN6wba79j5V1u3Please explain more what " -r
"-r 61" will make all points start at a random offset in 61 bit range.
The 3 sample starting points are just for information/confirmation the correct range is used.
If your BitCrack is generating 37,748,736 starting points then each point starts at a random offset in 61 bit range.
It is easy to adjust the code now. Simply adjust in generateStartingPoints() function.
You can combine -r with --keyspace if you need to additional control.
Please "git pull" to get the latest version that also contains fixes.
Yes ... still a OpenCL novice lol (I am too old now, maybe not you lol)
I've asked brichard19 about it ... he does not seem to be interested.
I am no youngling too but I like code. I can make adjustments to Cuda but have no experience with OpenCL yet so lets see.
Ok, let us know
Initial version
https://github.com/pikachunakapika/BitCrack
use -r
Please notice:
The total movement relative to each random starting point is defined by total processed keys / number of starting points.
E.g. if BitCrack generated 200,000 starting points and your total processed keys is 4,000,000. Each point moved by (only) 20 steps.
This is by original design and the only way to benefit from the huge parallel processing power of GPUs.
Tested OpenCL and Cuda with Nvidia Device on Linux.
Not tested on Windows. Please give feedback!
Please explain more what " -r
Jump to: