Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 342.

holy_ship

jr. member

Activity: 115

Merit: 1

haha! puzzle 58 is cracked. some guys with superclusters got involved? Grin

Andzhig

jr. member

Activity: 184

Merit: 3

arulbero,thx.

(for reference)
1Dn8NF8qDyyfHMktmuoQLGyjWmZXgvosXf
bin 1011000110011101011011100001010010000110001001101000100001
hex 2C675B852189A21
dec 199976667976342049

1011000110011101011011100001010010000110001001101000100001 33 zeros,25 ones.

10110001 10011101 01101110 00010100 10000110 00100110 10001000 01 33-25
11110101 10010010 11100100 10000011 11001010 11101011 00001110 0 28-29
10011101 00011000 10110110 00111010 11000100 11111111 11011111 22-34
11010101 01111100 00111111 00110110 11001111 11000010 0010100 24-31
10001101 10111110 11011011 01010110 10110100 01111101 000100 23-31

1111111111111111111111111000000000000000000000000000000000
111111111111111111111111111110000000000000000000000000000
11111111111111111111111111111111110000000000000000000000
1111111111111111111111111111111000000000000000000000000
111111111111111111111111111111100000000000000000000000

79 1001111
86 1010110
71 1000111
81 1010001
86 1010110
104 1101000 (1+9+9+9+7+6+6+6+7+9+7+6+3+4+2+0+4+9)

7D4FE747
B862A62E
1A96CA8D8
34A65911D
4AED21170
9DE820A7C
1757756A93
22382FACD0
4B5F8303E9
E9AE4933D6
153869ACC5B
2A221C58D8F
6BD3B27C591
E02B35A358F
122FCA143C05
2EC18388D544
6CD610B53CBA
ADE6D7CE3B9B
174176B015F4D
22BD43C2E9354
75070A1A009D4
EFAE164CB9E3C
180788E47E326C
236FB6D5AD1F44
6ABE1F9B67E114
9D18B63AC4FFDF
1EB25C90795D61C
2C675B852189A21
5 or 6 or 7 ...

Well, what's next, 288230376151711744-576460752303423488 ,if 6 it's 430000000000000000-500000000000000000 if 7 500000000000000000-570000000000000000

arulbero

legendary

Activity: 1968

Merit: 2130

Quote from: j2002ba2 on November 25, 2018, 02:24:32 PM

Using Pollard Rho method, the expected work is 3*2^80 group operations with almost zero memory requirements.

Note that unlike BSGS this method is probabilistic, and might fail with very low probability (on the order of 2^-160).

One can improve the algorithm using Distinguished Points, bringing the expected work down to 1.253*2^80 group operations, using both less memory and less group operations (on average) than BSGS.

Pollard Rho can be modified for an interval shorter than the whole group, at the cost of more group operations, i.e. for range 1 to 2^160 a possible solution would take 10*3*2^80 group ops plus 10*2^16 group points additional memory.

There are other probabilistic algorithms when private key is in a range significantly smaller than the size of the whole group - Pollard Kangaroo, and Gaudry-Schost algorithms.

Pollard Kangaroo with four kangaroos (the optimal) and distinguished points (DP) has expected work 1.715*2^80.

Four set Gaudry-Schost algorithm with DP gives 1.661*2^80 group operations, and is easy to parallelise.

There might be additional memory requirements for both methods, negligible compared to the enormous cost of BSGS.

Thanks for the information, I will take a look at these algorithms.

arulbero

legendary

Activity: 1968

Merit: 2130

Quote from: stalker00075 on December 03, 2018, 04:14:52 AM

arulbero Help!
what key can there be 1Dn8NF8qDyyfHMktmuoQLGyjWmZXgvosXf
2..............
3..............

Code:

Private key : 00000000000000000000000000000000000000000000000002c675b852189a21
Public key : 11569442e870326ceec0de24eb5478c19e146ecd9d15e4666440f2f638875f42 524c08d882f868347f8b69d3330dc1913a159d8fb2b27864f197693a0eb39a23

PrKey WIF c.: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjv2kTamEYQT9BNC7o1
Address c. : 8c2a6071f89c90c4dab5ab295d7729d1b54ea60f
Address c. : 1Dn8NF8qDyyfHMktmuoQLGyjWmZXgvosXf

stalker00075

newbie

Activity: 54

Merit: 0

arulbero Help!
what key can there be 1Dn8NF8qDyyfHMktmuoQLGyjWmZXgvosXf
2..............
3..............

racminer

member

Activity: 245

Merit: 17

#58 1Dn8NF8qDyyfHMktmuoQLGyjWmZXgvosXf has been spent an hour ago

tx: 17d31de2bd300bc1bad430ec0db77ca27466bbb97bf03df6a3ff386d60e58996

jason589

newbie

Activity: 1

Merit: 0

Quote from: zielar on November 25, 2018, 06:35:40 AM

Bearing in mind the above scheme and the fact that yesterday a new version of BitCrack released allowing to set the initial value and the final part of the selected key part - what is the correct setting in order to find the next private key? Possibly someone has a schematic how will the command syntax look to find more keys? I have 5x GTX 1080ti so I would like to try it because I was interested in this topic

^

j2002ba2

full member

Activity: 206

Merit: 450

Quote from: arulbero on November 18, 2018, 05:49:13 AM

Quote from: j2002ba2 on November 18, 2018, 05:24:15 AM

This is correct only for BSGS (Baby-Step-Giant-Step).

Using Pollard Rho method, the expected work is 3*2^80 group operations with almost zero memory requirements.

Note that unlike BSGS this method is probabilistic, and might fail with very low probability (on the order of 2^-160).

One can improve the algorithm using Distinguished Points, bringing the expected work down to 1.253*2^80 group operations, using both less memory and less group operations (on average) than BSGS.

Pollard Rho can't exploit the fact that the private key is in the range from 1 to 2^160 for example, because it is probabilistic. It would need always 2^128 steps. Only BSGS is suitable for this task.

If you try to retrieve #57 with Pollard Rho, you won't retrieve the private key in a few seconds or in a few years.

With "space search is 2^160" in this context we mean a 2^160 points subset in the space of the 2^256 points of the secp256k1 curve.

Pollard Rho can be modified for an interval shorter than the whole group, at the cost of more group operations, i.e. for range 1 to 2^160 a possible solution would take 10*3*2^80 group ops plus 10*2^16 group points additional memory.

There are other probabilistic algorithms when private key is in a range significantly smaller than the size of the whole group - Pollard Kangaroo, and Gaudry-Schost algorithms.

Pollard Kangaroo with four kangaroos (the optimal) and distinguished points (DP) has expected work 1.715*2^80.

Four set Gaudry-Schost algorithm with DP gives 1.661*2^80 group operations, and is easy to parallelise.

There might be additional memory requirements for both methods, negligible compared to the enormous cost of BSGS.

zielar

full member

Activity: 282

Merit: 114

Quote from: digitalcitizen on November 19, 2018, 11:50:30 PM

Wow.

Code:

james@research:~$ time ./baby-step-giant-step.exe
Build Hash
Search Keys
Found private key 1: ffffffffffffffff or 1
Found private key 2: fffffffffffffffd or 3
Found private key 3: fffffffffffffff9 or 7
Found private key 4: fffffffffffffff8 or 8
Found private key 5: ffffffffffffffeb or 15
Found private key 6: ffffffffffffffcf or 31
Found private key 7: ffffffffffffffb4 or 4c
Found private key 8: ffffffffffffff20 or e0
Found private key 9: fffffffffffffe2d or 1d3
Found private key 10: fffffffffffffdfe or 202
Found private key 11: fffffffffffffb7d or 483
Found private key 12: fffffffffffff585 or a7b
Found private key 13: ffffffffffffeba0 or 1460
Found private key 14: ffffffffffffd6d0 or 2930
Found private key 15: ffffffffffff970d or 68f3
Found private key 16: ffffffffffff36ca or c936
Found private key 17: fffffffffffe89b1 or 1764f
Found private key 18: fffffffffffcf7f3 or 3080d
Found private key 19: fffffffffffa8b61 or 5749f
Found private key 20: fffffffffff2d3ab or d2c55
Found private key 21: ffffffffffe45acc or 1ba534
Found private key 22: ffffffffffd21bf1 or 2de40f
Found private key 23: ffffffffffaa91ae or 556e52
Found private key 24: ffffffffff23d5fc or dc2a04
Found private key 25: fffffffffe05a11b or 1fa5ee5
Found private key 26: 340326e or 4bfcd92
Found private key 27: 6ac3875 or 953c78b
Found private key 28: a6e9318 or d916ce8
Found private key 29: 17e2551e or 181daae2
Found private key 30: 3a6b329c or 3d94cd64
Found private key 31: 7ab018b9 or 7d4fe747
Found private key 32: b79d59d2 or b862a62e
Found private key 33: 1a6935728 or 1a96ca8d8
Found private key 34: 34a65911d or 34d9a6ee3
Found private key 35: 4aed21170 or 4b12dee90
Found private key 36: 9de820a7c or 9e17df584
Found private key 37: 1757756a93 or 17588a956d
Found private key 38: 2237d05330 or 22382facd0
Found private key 39: 4b5f8303e9 or 4b607cfc17
Found private key 40: e9ae4933d6 or e9b1b6cc2a
Found private key 41: 153869acc5b or 153896533a5
Found private key 42: 2a21e3a7271 or 2a221c58d8f
Found private key 43: 6bd3b27c591 or 6bd3cd83a6f
Found private key 44: e02b35a358f or e02b4a5ca71
Found private key 45: 122fca143c05 or 122fcdebc3fb
Found private key 46: 2ec18388d544 or 2ec184772abc
Found private key 47: 6cd60f4ac346 or 6cd610b53cba
Found private key 48: ade6d7ce3b9b or ade6d831c465
Found private key 49: 174176b015f4d or 174176cfea0b3
Found private key 50: 22bd43bd16cac or 22bd43c2e9354
Found private key 51: 750709e5ff62c or 75070a1a009d4

real 4m8.237s
user 4m7.784s
sys 0m0.432s
james@research:~$

Bearing in mind the above scheme and the fact that yesterday a new version of BitCrack released allowing to set the initial value and the final part of the selected key part - what is the correct setting in order to find the next private key? Possibly someone has a schematic how will the command syntax look to find more keys? I have 5x GTX 1080ti so I would like to try it because I was interested in this topic

Amnuazka

newbie

Activity: 15

Merit: 0

Quote from: saatoshi_rising on April 27, 2017, 01:41:08 AM

Quote from: sabbybibi on March 13, 2017, 11:17:30 AM

This puzzle is very strange. If it's for measuring the world's brute forcing capacity, 161-256 are just a waste (RIPEMD160 entropy is filled by 160, and by all of P2PKH Bitcoin). The puzzle creator could improve the puzzle's utility without bringing in any extra funds from outside - just spend 161-256 across to the unsolved portion 51-160, and roughly treble the puzzle's content density.

If on the other hand there's a pattern to find... well... that's awfully open-ended... can we have a hint or two? Cheesy

I am the creator.

You are quite right, 161-256 are silly. I honestly just did not think of this. What is especially embarrassing, is this did not occur to me once, in two years. By way of excuse, I was not really thinking much about the puzzle at all.

I will make up for two years of stupidity. I will spend from 161-256 to the unsolved parts, as you suggest. In addition, I intend to add further funds. My aim is to boost the density by a factor of 10, from 0.001*length(key) to 0.01*length(key). Probably in the next few weeks. At any rate, when I next have an extended period of quiet and calm, to construct the new transaction carefully.

A few words about the puzzle. There is no pattern. It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty). It is simply a crude measuring instrument, of the cracking strength of the community.

Finally, I wish to express appreciation of the efforts of all developers of new cracking tools and technology. The "large bitcoin collider" is especially innovative and interesting!

The pattern is 12 or 24 mnemonic ?

Bajula

member

Activity: 166

Merit: 16

Quote from: arulbero on November 21, 2018, 06:57:20 PM

Quote from: Bajula on November 21, 2018, 04:46:31 PM

Quote from: arulbero on November 16, 2018, 10:08:38 AM

For the #57 key instead:

Code:

#define GSTEP (1<<28)

typedef struct hashtable_entry {

uint64_t x;

uint32_t exponent;

} hashtable_entry;

#define HASH_SIZE (2*GSTEP)

hashtable_entry table[HASH_SIZE];

I use 32 bit for the exponent (32 > 28) and I store only the first 64 bit of the x coordinate (there is a low chance to have a partial collision in a list of 2^28 element, i.e. two different x with the same first 64 bit) --> (64 + 32 bit)

To avoid any collisions you should use always 256 bit for the x coordinate. And the size of the hash table should be at least two times the size of the list you want to store.

With the above in mind how does the other guy's program work for the first 51 with only uint32_t x; instead of 64?? Mostly curious.

Because I oversimplified my explanation to avoid technical details.

GSTEP 2^25
HASHSIZE 2^26

hash table is for one list of 2^25 public keys (baby steps)
the second list of 2^25 public keys (giant steps) is computed and compaired with the first one "on fly" (no memory)

Take the x coordinate of a public key: xst (256 bit)
and split it:

xst.n[0] 64 bit
xst.n[1] 64 bit
xst.n[2] 64 bit
xst.n[3] 64 bit

the index of the table (entry) is 26 bit of xst.n[0]
if that entry is already occupied, use xst.n[1] to modify the index (this way you avoid collisions between elements in the hash table)
instead of the entire x, x = 32 bit of xst.n[2]
exponent = i (which step it is, to retrieve the private key to that public key)

Code:

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);
   }

This program uses at least 26 + 32 bit = 58 bit of each public key that is in the hash table (but 26 bit are the position in the memory, so it stores effectively only 32 bit of the key in the table + 32 bit for the exponent, the private key) .

Then it generates the second list (giant steps). A wrong collision between an element of this list and a element in the table can occur only if 2 public keys share exactly 58 bit (let's say for semplicity the first 58 bit, but they are not adjacent). To find a 51 bit key then 32 bit for the x coordinate is enough.

If you need to retrieve a 60 bit private key or more, you should use more space.

Thank you! Honestly when I first looked at this thread it was because "whaaaat puzzle? free bitcoin?" *robble robble* but it has prompted me to learn, and re-invigorated this old fellas mind.

arulbero

legendary

Activity: 1968

Merit: 2130

Quote from: Bajula on November 21, 2018, 04:46:31 PM

Quote from: arulbero on November 16, 2018, 10:08:38 AM

For the #57 key instead:

Code:

#define GSTEP (1<<28)

typedef struct hashtable_entry {

uint64_t x;

uint32_t exponent;

} hashtable_entry;

#define HASH_SIZE (2*GSTEP)

hashtable_entry table[HASH_SIZE];

I use 32 bit for the exponent (32 > 28) and I store only the first 64 bit of the x coordinate (there is a low chance to have a partial collision in a list of 2^28 element, i.e. two different x with the same first 64 bit) --> (64 + 32 bit)

To avoid any collisions you should use always 256 bit for the x coordinate. And the size of the hash table should be at least two times the size of the list you want to store.

With the above in mind how does the other guy's program work for the first 51 with only uint32_t x; instead of 64?? Mostly curious.

Because I oversimplified my explanation to avoid technical details.

GSTEP 2^25
HASHSIZE 2^26

hash table is for one list of 2^25 public keys (baby steps)
the second list of 2^25 public keys (giant steps) is computed and compaired with the first one "on fly" (no memory)

Take the x coordinate of a public key: xst (256 bit)
and split it:

xst.n[0] 64 bit
xst.n[1] 64 bit
xst.n[2] 64 bit
xst.n[3] 64 bit

the index of the table (entry) is 26 bit of xst.n[0]
if that entry is already occupied, use xst.n[1] to modify the index (this way you avoid collisions between elements in the hash table)
instead of the entire x, x = 32 bit of xst.n[2]
exponent = i (which step it is, to retrieve the private key to that public key)

Code:

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);
   }

This program uses at least 26 + 32 bit = 58 bit of each public key that is in the hash table (but 26 bit are the position in the memory, so it stores effectively only 32 bit of the key in the table + 32 bit for the exponent, the private key) .

Then it generates the second list (giant steps). A wrong collision between an element of this list and a element in the table can occur only if 2 public keys share exactly 58 bit (let's say for semplicity the first 58 bit, but they are not adjacent). To find a 51 bit key then 32 bit for the x coordinate is enough.

If you need to retrieve a 60 bit private key or more, you should use more space.

Bajula

member

Activity: 166

Merit: 16

Quote from: arulbero on November 18, 2018, 04:37:22 PM

Quote from: ZafotheNinja on November 18, 2018, 04:00:26 PM

Quote from: arulbero on November 16, 2018, 10:08:38 AM

For the #57 key instead:

Code:

#define GSTEP (1<<28)

typedef struct hashtable_entry {

uint64_t x;

uint32_t exponent;

} hashtable_entry;

#define HASH_SIZE (2*GSTEP)

hashtable_entry table[HASH_SIZE];

I use 32 bit for the exponent (32 > 28) and I store only the first 64 bit of the x coordinate (there is a low chance to have a partial collision in a list of 2^28 element, i.e. two different x with the same first 64 bit) --> (64 + 32 bit)

To avoid any collisions you should use always 256 bit for the x coordinate. And the size of the hash table should be at least two times the size of the list you want to store.

With the above in mind how does the other guy's program work for the first 51 with only uint32_t x; instead of 64?? Mostly curious.

digitalcitizen

copper member

Activity: 115

Merit: 4

Wow.

Code:

james@research:~$ time ./baby-step-giant-step.exe
Build Hash
Search Keys
Found private key 1: ffffffffffffffff or 1
Found private key 2: fffffffffffffffd or 3
Found private key 3: fffffffffffffff9 or 7
Found private key 4: fffffffffffffff8 or 8
Found private key 5: ffffffffffffffeb or 15
Found private key 6: ffffffffffffffcf or 31
Found private key 7: ffffffffffffffb4 or 4c
Found private key 8: ffffffffffffff20 or e0
Found private key 9: fffffffffffffe2d or 1d3
Found private key 10: fffffffffffffdfe or 202
Found private key 11: fffffffffffffb7d or 483
Found private key 12: fffffffffffff585 or a7b
Found private key 13: ffffffffffffeba0 or 1460
Found private key 14: ffffffffffffd6d0 or 2930
Found private key 15: ffffffffffff970d or 68f3
Found private key 16: ffffffffffff36ca or c936
Found private key 17: fffffffffffe89b1 or 1764f
Found private key 18: fffffffffffcf7f3 or 3080d
Found private key 19: fffffffffffa8b61 or 5749f
Found private key 20: fffffffffff2d3ab or d2c55
Found private key 21: ffffffffffe45acc or 1ba534
Found private key 22: ffffffffffd21bf1 or 2de40f
Found private key 23: ffffffffffaa91ae or 556e52
Found private key 24: ffffffffff23d5fc or dc2a04
Found private key 25: fffffffffe05a11b or 1fa5ee5
Found private key 26: 340326e or 4bfcd92
Found private key 27: 6ac3875 or 953c78b
Found private key 28: a6e9318 or d916ce8
Found private key 29: 17e2551e or 181daae2
Found private key 30: 3a6b329c or 3d94cd64
Found private key 31: 7ab018b9 or 7d4fe747
Found private key 32: b79d59d2 or b862a62e
Found private key 33: 1a6935728 or 1a96ca8d8
Found private key 34: 34a65911d or 34d9a6ee3
Found private key 35: 4aed21170 or 4b12dee90
Found private key 36: 9de820a7c or 9e17df584
Found private key 37: 1757756a93 or 17588a956d
Found private key 38: 2237d05330 or 22382facd0
Found private key 39: 4b5f8303e9 or 4b607cfc17
Found private key 40: e9ae4933d6 or e9b1b6cc2a
Found private key 41: 153869acc5b or 153896533a5
Found private key 42: 2a21e3a7271 or 2a221c58d8f
Found private key 43: 6bd3b27c591 or 6bd3cd83a6f
Found private key 44: e02b35a358f or e02b4a5ca71
Found private key 45: 122fca143c05 or 122fcdebc3fb
Found private key 46: 2ec18388d544 or 2ec184772abc
Found private key 47: 6cd60f4ac346 or 6cd610b53cba
Found private key 48: ade6d7ce3b9b or ade6d831c465
Found private key 49: 174176b015f4d or 174176cfea0b3
Found private key 50: 22bd43bd16cac or 22bd43c2e9354
Found private key 51: 750709e5ff62c or 75070a1a009d4

real 4m8.237s
user 4m7.784s
sys 0m0.432s
james@research:~$

digitalcitizen

copper member

Activity: 115

Merit: 4

Quote from: arulbero on November 18, 2018, 04:37:22 PM

For the #57 key instead:

Code:

#define GSTEP (1<<28)

typedef struct hashtable_entry {

uint64_t x;

uint32_t exponent;

} hashtable_entry;

#define HASH_SIZE (2*GSTEP)

hashtable_entry table[HASH_SIZE];

I use 32 bit for the exponent (32 > 28) and I store only the first 64 bit of the x coordinate (there is a low chance to have a partial collision in a list of 2^28 element, i.e. two different x with the same first 64 bit) --> (64 + 32 bit)

To avoid any collisions you should use always 256 bit for the x coordinate. And the size of the hash table should be at least two times the size of the list you want to store.

Thanks again arulbero. Now I see why you're legendary.

digitalcitizen

copper member

Activity: 115

Merit: 4

Quote from: arulbero on November 10, 2018, 10:32:52 AM

With brute force I would need to use 2^56 different private keys to generate 2^56 public keys. Too much time. But If I knew only the address and not the public key, that would be the only way.

Could you briefly describe what this process would be like, if you can? In terms of possible time to generate, and space to save the results.

What I think you're saying, if I understand it, is that you would generate all 56-bit private keys, for unsigned integers that would be 2^56 - 1 private keys, or 72,057,594,037,927,935. Wow, 72 quadrillion, 57 trillion and so on. Then generate a public key for each of those 72 quadrillion+ private keys.

But, if you don't know what the private key is, to solve a puzzle, this would be a fairly insane process of using a lookup table perhaps. Suppose only compressed public keys are computed for each private key, then compute sha256(pubkey) -> ripemd160( sha256(pubkey) ) for the Hash160 of the address, or just go a step further and use the Base58Check address list from the public keys.

So in other words, the only method here is to have a huge lookup table, and if you have a massive RDBMS for it, then select privkey from lookup_table where (hash160 || base58check) = target_address, and hope you get a hit.

I suppose there would be a better way to implement a lookup table, like cutting some bits off the hash160 or base58check address, then do a lookup on priv_key where first 64 bits of hash160 = first 64 bits of target hash160, and maybe one will pop out. Still, a massive operation. Assuming billions of keys per second, that will still take a heck of a long time, not to mention the computation of the public key and other operations from each of the private keys, and the space needed to store the lookup table or database.

arulbero

legendary

Activity: 1968

Merit: 2130

Quote from: ZafotheNinja on November 18, 2018, 04:00:26 PM

Quote from: arulbero on November 16, 2018, 10:08:38 AM

No, it would require much more than 2^80 work. Or you would require 2^80 work + a storage capable of containing a hash table of 2^80 * (256 bit + 80 bit) = 336 * 2^80 bit = 2^88.4 bit = more than 2^38 PB.

The current max size of my hash table is now 2^28 * (64 bit + 32 bit) = 96 * 2^28 bit = 2^34.58 bit = 24 GB (to store 2^28 keys in ram). It is only 1/2^54 of 2^88.4!

It is not possible to get such amount of ram in the next 40 years.

Could you go a bit more into how you get the numbers in the parentheses? You lost me there.

Look at this code:

https://gist.github.com/jhoenicke/2e39b3c6c49b1d7b216b8626197e4b89

You need to store a list of 2^80 public keys in a hash table. For the sake of simplicity we suppose we have enough ram.

Then:

Code:

#define GSTEP (1<<80)

typedef struct hashtable_entry {

uint256_t x;

uint81_t exponent;

} hashtable_entry;

#define HASH_SIZE (2*GSTEP)

hashtable_entry table[HASH_SIZE];

each entry has the x coordinate (256 bit) of a public key + a exponent (a key to access faster to the entry). The exponent must be longer than the size of the list (to minimize collisions, see https://en.wikipedia.org/wiki/Hash_table), then if the list has 2^80 elements, it takes at least 81 bit for the exponent (HASH_SIZE is 2*GSTEP = 2^81). --> (81 + 256 bit)

For the #57 key instead:

Code:

#define GSTEP (1<<28)

typedef struct hashtable_entry {

uint64_t x;

uint32_t exponent;

} hashtable_entry;

#define HASH_SIZE (2*GSTEP)

hashtable_entry table[HASH_SIZE];

I use 32 bit for the exponent (32 > 28) and I store only the first 64 bit of the x coordinate (there is a low chance to have a partial collision in a list of 2^28 element, i.e. two different x with the same first 64 bit) --> (64 + 32 bit)

To avoid any collisions you should use always 256 bit for the x coordinate. And the size of the hash table should be at least two times the size of the list you want to store.

Elliptic23

newbie

Activity: 22

Merit: 3

Quote from: Teawhalee on November 18, 2018, 04:31:35 PM

This really sound interesting but it's going to be a very tedious task and it will take alot of time to solve it. I hope someone finds out and win the prize if truly there is price to be won.

People have been finding keys. The most recent one was on November 8th, 2018: https://www.blockchain.com/btc/address/15c9mPGLku1HuW9LRtBf4jcHVpBUt8txKz. A 57-bit puzzle.

Teawhalee

copper member

Activity: 482

Merit: 1

This really sound interesting but it's going to be a very tedious task and it will take alot of time to solve it. I hope someone finds out and win the prize if truly there is price to be won.

ZafotheNinja

jr. member

Activity: 30

Merit: 1

Quote from: arulbero on November 16, 2018, 10:08:38 AM

No, it would require much more than 2^80 work. Or you would require 2^80 work + a storage capable of containing a hash table of 2^80 * (256 bit + 80 bit) = 336 * 2^80 bit = 2^88.4 bit = more than 2^38 PB.

The current max size of my hash table is now 2^28 * (64 bit + 32 bit) = 96 * 2^28 bit = 2^34.58 bit = 24 GB (to store 2^28 keys in ram). It is only 1/2^54 of 2^88.4!

It is not possible to get such amount of ram in the next 40 years.

Could you go a bit more into how you get the numbers in the parentheses? You lost me there.

Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 342. (Read 253308 times)