Show Posts

Pages: [1] 2 3 4 5 6 7 »

Puzzle 66 was found  13zb1hQbWVsc2S7ZTZnP2G4undNNpdh5so
congratulations to the winner! so, now 6.7 at fire.



what computational power does the puzzles 130 needed to be solved
if you have 56core/256GB server, you'll check about 12 exakeys per sec 2^129 / 11344588059320129643 / 3600*24 = ? after 1_902_338_144_733 years AT MOST you'll become rich, but with this probability 1/680564733841876926926749214863536422912 you'll find PK in first second. Feel lucky? (haha) p.s. if you pay $200 per month for server, you'll pay 1902338144733*200*12 = ? 4_565_611_547_359_200 dollars so, it's only reasonable if you do not pay for server this is true if you go through all the values without taking into account entropy. Of course, if you try to generate a random number of 10 bits a billion times, you can get the number 0. But if you try to generate a random number of 66 bits, it becomes impossible to get the number 0. In this way, you need to ignore values that with the maximum probability could not be a private key.



Again target is to break pubkey hash, not privkey
I remember there was information about how the keys were generated. If anyone remembers where it is in the topics, please write link here. It is important to understand whether a 256bit key was generated and “cut off”, or whether private keys of the required bit size were initially generated for each address. This is important for estimating entropy.



can you please explain
NO. excusema



If you can do that, congratulations because you just partially broke elliptic curve.
No, i mean I can reduce a generator range to skip not random values, so time to bruteforce reduced too. For example, 23 bit key to test (python 3.11 + ice_secp256k1.dll). with secret algo: GOT: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rVkthFNsQ6i7 10.363348245620728 s
with usual range (2^22 ... 2^231) GOT: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rVkthFNsQ6i7 16.832353353500366 swith big values, like 66 bit, a lot of values just skiped as NOT random binary values, because cant be randomly generated by author (by wallet software). for example, first value for 66bit range is 100000100100100101010011001011000111000111001011000111000111001011, all values less is fail. this value give generator as first value applyed with random's rules anyway, pure python not a good instrument to get result. wanna use numba cuda.jit, but still learning how to.



unfortunately, there is a possibility of missing the desired value.
That said all no? The possibility of missing the target value with bigger keys is great. many test was. real steps to find was different. 22bit at this test is: 1011011110010000001111 777854but anyway its better vs range(2**21, 2**221)



found a way to reduce 1/6 total range. python proto give a nice result for all known PK.
That is only passible when you know the private key, but WITHOUT the private key all those reductions aren't possible. it's wrong. for example 7bit key can be found at 4 step (direct search from 2^6 to (2^7)1 will find only at step 12, reduce 3 times). 1001001 11001010 21001011 31001100 4result: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rF U7hDgvu64y17bit at 17318 (direct at 30287 step, reduce ~2 times) 10111011001001111 17318result: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rF iHkRsp99uC 22bit (direct 910351) 1011011110010000001111 607024result: KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7r P9Ja2dhtxoh and so on... tested with known PK. but still at researching. 8bit key skiped by this method, therefore, unfortunately, there is a possibility of missing the desired value. i was wrong about 1/6 (error with calculation was), anyway reduce are possible, but with chance to skip needed value =( and we must take into account that by skipping some values when generating numbers, we save time on generating the address and checking it with the required one (speedup).



found a way to reduce 1/6 total range. python proto give a nice result for all known PK.
hope CUDA version will be a nice with 66..70 profit.
good luck!



Zero chance that these random numbers have a weakness on PRNG side.
no, i search not a weakness. each generator produce different randoms. for example, python's randint create 256 bit with about 50/50 +/10% zeros and ones. but mt19937_64 in cpp produce only 32 bit, i generate pair (32+32=64) to test and got ~70/30% zeros and ones. at 2013 bitcoin core used openssl to generate random keys. question is author are used this openssl generator or something else. if yes, openssl compile different code for win, mac and *nix. compile flags also give different result. if get statistic for exactly used generator, so possible make a faster bruteforcer to skip values wich have low score and probably cant be generated at 2013.



He just generated a series of normal fulllength private keys with good PRNG, and then manually masked (XORed) them to required length one by one.
i know. i wanna know a env where this process was doing.



is OP still here? can you explain your env used to create tx? win, mac, nix, python, btc core, other wallet? what a flags was used to compile openssl1.0.1c?



is OP still here? can you explain your env used to create tx? win, mac, nix, python, btc core, other wallet? what a flags was used to compile openssl1.0.1c?



whoever finds #64 must pay high trans fee to get in into a block before someone else attacks it with kangaroo.
use Electrum and disable ReplaceByFee to avoid double spending.



Hello! Any news? Coin is delisting everywhere. Price is too low :(
yobit, +1598% last day.



seems "The Puzzle Level 6" is unsolvable. needs to check 121 645 100 408 832 000 combinations to get a 11$.. letter matrix have 25 words, but needed only 24. 18 words have unknown order  its very hard to bruteforce right order, but we have 19 finded words so problem bigger.



Still can't understand why she's comb have 21 teeth... not 22 nor 20. Solution is not an answer for puzzle question. Solution describes a method to choose a teeth count, but not why is 21.



