Bitcoin Forum
December 14, 2019, 11:21:18 AM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 [27] 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 »
  Print  
Author Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it  (Read 81599 times)
kucritt
Full Member
***
Offline Offline

Activity: 588
Merit: 100



View Profile
November 14, 2018, 02:32:34 PM
 #521

since 2014 i see there are many quiz right that, but until right now i dont know how to solve this problem, how to solve this puzzle? can anyone tell me how, so i can try to solve it by myself

1576322478
Hero Member
*
Offline Offline

Posts: 1576322478

View Profile Personal Message (Offline)

Ignore
1576322478
Reply with quote  #2

1576322478
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
arulbero
Legendary
*
Offline Offline

Activity: 1300
Merit: 1363


View Profile
November 14, 2018, 03:02:12 PM
 #522

@arulbero

If you have the public key and the search space is 2^160 how fast can you find the private key?


Infeasible. More than universe age.
Elliptic23
Newbie
*
Offline Offline

Activity: 17
Merit: 0


View Profile
November 16, 2018, 01:15:41 AM
 #523

@arulbero

If you have the public key and the search space is 2^160 how fast can you find the private key?


It would require 2^80 work. That is just beyond what is currently feasible today. But not impossible.
arulbero
Legendary
*
Offline Offline

Activity: 1300
Merit: 1363


View Profile
November 16, 2018, 03:08:38 PM
Last edit: November 16, 2018, 03:26:01 PM by arulbero
 #524

@arulbero

If you have the public key and the search space is 2^160 how fast can you find the private key?


It would require 2^80 work. That is just beyond what is currently feasible today. But not impossible.

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.
natedawg469
Newbie
*
Offline Offline

Activity: 15
Merit: 0


View Profile
November 16, 2018, 11:48:26 PM
 #525

Quote from: maianh09
This is a game for geniuses with great minds.

The most funny thing - the guy who took 3 puzzles in a row just bought 3 gtx1080ti.

The next megagenius is the one, who will step in with 5 1080ti's  Grin


That will not happen. I have (6) super powerful EVGA GTX 1080 FTW 3.0 gpus and using bitcrack, I cannot come anywhere close to solving the higher number keys like 59, 60, etc.

https://www.evga.com/products/specs/gpu.aspx?pn=ced0347b-30fe-45fe-808c-a64df6a5218a
Marbelli
Jr. Member
*
Offline Offline

Activity: 182
Merit: 1

EndChain - Complete Logistical Solution


View Profile
November 17, 2018, 12:45:02 AM
 #526

because before that, if I am not mistaken, all the tasks have been solved and it seems to me that this one will also be solved

EndChain - Complete logistical solution for all markets and supply chains
ICO Start: Dec 1, 2018 (https://endchain.io/)
digitalcitizen
Copper Member
Jr. Member
*
Offline Offline

Activity: 115
Merit: 4


View Profile
November 18, 2018, 03:52:01 AM
 #527

Hi. I probably misunderstood something.

In your example #57 (first 200 bit + last 56 bit) =

0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000011101011001001011100100100000111100101 011101011000011100

HEX: 00000000000000000000000000000000000000000000000000eb25c90795d61c => 1J9zB6p4dRgyinst2eCVsyXvgYXtNhw2Y2

This is not a private key for #57

What did I miss?

I forgot '1' at the beginning of the number:

last 56 bit of the private key#57:
Code:
1101011001001011100100100000111100101011101011000011100
but there are only 55 bits

Correct-->

last 56 bit of the private key#57:
Code:
11101011001001011100100100000111100101011101011000011100

0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000011110101100100101110010010000011110010 1011101011000011100

HEX  00000000000000000000000000000000000000000000000001eb25c90795d61c

Thank you

Yes, that was the correct hex key for #57.  I hope you got to spend it!  Smiley
digitalcitizen
Copper Member
Jr. Member
*
Offline Offline

Activity: 115
Merit: 4


View Profile
November 18, 2018, 04:28:10 AM
 #528


here are the other pvk decimal values I was able to find:

Address 15: 26867
Address 16: 51510
Address 17: 95823
Address 18: 198669
Address 19: 357535
Address 20: ?

I think these are correct, but I haven't had time to verify yet.

Address 15: (I missed that one for some reason), I'm not entirely sure what the keys for these are just yet.  I'll check them out this evening.

List of priv keys in hex, then decimal:

3
7
8
15
31
4c
e0
1d3
202
483
a7b
1460
2930
c936
1764f
3080d
5749f
d2c55
1ba534
2de40f
556e52
dc2a04
1fa5ee5
340326e
6ac3875
d916ce8
17e2551e
3d94cd64
7d4fe747
b862a62e
1a96ca8d8
34a65911d
4aed21170
9de820a7c
1757756a93
22382facd0
4b5f8303e9   <= Address 39 122AJhKLEfkFBaGAd84pLp1kfE7xK3GdT8

3
7
8
21
49
76
224
467
514
1155
2683
5216
10544
51510
95823
198669
357535
863317
1811764
3007503
5598802
14428676
33185509
54538862
111949941
227634408
400708894
1033162084
2102388551
3093472814
7137437912
14133072157
20112871792
42387769980
100251560595
146971536592
323724968937   <= Address 39 122AJhKLEfkFBaGAd84pLp1kfE7xK3GdT8

Very interesting.  Took me less than a day to get all these, but cracking up much higher for unclaimed is going to be really hard, unless I can do something more intelligent than just a brute force.  Which is what I'm working on of course, there may be something there to find.
j2002ba2
Newbie
*
Offline Offline

Activity: 12
Merit: 13


View Profile
November 18, 2018, 10:24:15 AM
 #529

@arulbero

If you have the public key and the search space is 2^160 how fast can you find the private key?


It would require 2^80 work. That is just beyond what is currently feasible today. But not impossible.

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.

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.
arulbero
Legendary
*
Offline Offline

Activity: 1300
Merit: 1363


View Profile
November 18, 2018, 10:49:13 AM
 #530

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.
ZafotheNinja
Newbie
*
Offline Offline

Activity: 29
Merit: 1


View Profile
November 18, 2018, 09:00:26 PM
 #531

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.
Teawhalee
Copper Member
Jr. Member
*
Offline Offline

Activity: 371
Merit: 1

I-CHAIN - The Revolution of Digital Advertising


View Profile WWW
November 18, 2018, 09:31:35 PM
 #532

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. 

Elliptic23
Newbie
*
Offline Offline

Activity: 17
Merit: 0


View Profile
November 18, 2018, 09:34:17 PM
 #533

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.
arulbero
Legendary
*
Offline Offline

Activity: 1300
Merit: 1363


View Profile
November 18, 2018, 09:37:22 PM
Last edit: November 18, 2018, 09:47:55 PM by arulbero
 #534

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.
digitalcitizen
Copper Member
Jr. Member
*
Offline Offline

Activity: 115
Merit: 4


View Profile
November 20, 2018, 04:39:58 AM
 #535

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.
digitalcitizen
Copper Member
Jr. Member
*
Offline Offline

Activity: 115
Merit: 4


View Profile
November 20, 2018, 04:44:36 AM
 #536

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. Smiley
digitalcitizen
Copper Member
Jr. Member
*
Offline Offline

Activity: 115
Merit: 4


View Profile
November 20, 2018, 04:50:30 AM
 #537

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:~$
Bajula
Member
**
Offline Offline

Activity: 165
Merit: 16


View Profile
November 21, 2018, 09:46:31 PM
 #538


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.
arulbero
Legendary
*
Offline Offline

Activity: 1300
Merit: 1363


View Profile
November 21, 2018, 11:57:20 PM
Last edit: November 22, 2018, 12:14:47 AM by arulbero
 #539


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
**
Offline Offline

Activity: 165
Merit: 16


View Profile
November 22, 2018, 03:14:05 AM
 #540


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. Smiley
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 [27] 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!