⭐ Merited by studyroom1 (1)
This makes actually no sense, because the underlying principle is different.
~snip
So we are halving the public key 5 times. This means, that when we do this on key 11, we get 32 keys, from where one of them has the correct endsequence of the private key. So we have to check all keys if they are in the range of 2^6. If we get one, than we know how the first 6 bits of the privatekey are. We can from here determine the last 5 bits easily. I am not interested in the other ranges, as i have now a total valid privatekey
~snip
So we are halving the public key 5 times. This means, that when we do this on key 11, we get 32 keys, from where one of them has the correct endsequence of the private key. So we have to check all keys if they are in the range of 2^6. If we get one, than we know how the first 6 bits of the privatekey are. We can from here determine the last 5 bits easily. I am not interested in the other ranges, as i have now a total valid privatekey
Had a freak day today, so my brain's not very attentive right now. Will need multiple drinks of jolt cola before I can go over what you did.
I recently did a little research on private key generation via /dev/urandom. More than 100 million keys were used for the test. The bit allocation was about the same = 0.5
Maybe the old versions of OpenSSL, which were probably used in the puzzle creation, had some vulnerabilities and gave some deviation?
Maybe the old versions of OpenSSL, which were probably used in the puzzle creation, had some vulnerabilities and gave some deviation?
It's possible, but also remember a) OpenSSL uses multiple entropy sources - one of which is urandom (another is the entropy it stores in a file somewhere) and 2) the real-life sample size is very small - there were at least 256 256-bit random numbers generated in the process of making the puzzle, and possibly more as several of the numbers were probably not in the appropriate range.
now talk about NotATether script,
the script he posted is doing mod inverses and it is just multiplying value until reach 5 uper bit. (no one can get 120 how can they will get 125 lolololo)
the script he posted is doing mod inverses and it is just multiplying value until reach 5 uper bit. (no one can get 120 how can they will get 125 lolololo)
Well all I did is reverse engineer the algorithm until it completely matched the examples that brainless provided so congratulations on explaining in simple terms why the algorithm is so absurd.
now talk about brainless theory -
NotATether and brainless are misunderstanding each other brainless maybe joked that he reduced keys 720 by doing multiplication , addition and subtraction bla bla bla until 90 or 100 bit but NotATether is insisting what he explained inside his posts is not a way & there is also no way to achieve that and perhaps he never achieved that one and just keep lying.
now what i think is brainless have to explain this to community
NotATether and brainless are misunderstanding each other brainless maybe joked that he reduced keys 720 by doing multiplication , addition and subtraction bla bla bla until 90 or 100 bit but NotATether is insisting what he explained inside his posts is not a way & there is also no way to achieve that and perhaps he never achieved that one and just keep lying.
now what i think is brainless have to explain this to community
Code:
" I got it down to 104 bits today, but with 32,000 pubkeys; better than the normal 2^16 normally required, but I can't figure out a way to shrink it down to one key... "
for 10 bit down = 1024 pubkeys
for 20 bit down = 1024*1024 = 1048576 pubkeys
for 30 bit down = 1024*1024*1024 = 1073741824 pubkeys
1048576 and 1073741824 pubkeys with each other addition and mutiplication will return you 260 pubkeys apear where 16 pubkeys sure inside 10 bit down from main pubkey
these 260 pubkeys again played for get 30 bit down for 1/720 pubkeys
now you can start to find with above tip
for 10 bit down = 1024 pubkeys
for 20 bit down = 1024*1024 = 1048576 pubkeys
for 30 bit down = 1024*1024*1024 = 1073741824 pubkeys
1048576 and 1073741824 pubkeys with each other addition and mutiplication will return you 260 pubkeys apear where 16 pubkeys sure inside 10 bit down from main pubkey
these 260 pubkeys again played for get 30 bit down for 1/720 pubkeys
now you can start to find with above tip
720 keys means you've only reduced it by some factor between 2^109 and 2^110, how do you even begin shifting a key down that far while not making the number of group ops explode as well?
Guys fyi 1024 is not div point in ecc, posting here, divideable magic digits for ecc, these will help you to decide bitrange to divide, use these magic ecc div numbers, for pollard kanagroo or other manual div
2 447 7572 564114
3 596 9536 752152
4 631 10096 1128228
6 894 14304 1504304
8 1192 15144 2256456
12 1262 20192 3008608
16 1788 28608 4512912
24 1893 30288 6017216
32 2384 40384 9025824
48 2524 60576 18051648
64 3576 94019
96 3786 121152
149 4768 188038
192 5048 282057
298 7152 376076
2 447 7572 564114
3 596 9536 752152
4 631 10096 1128228
6 894 14304 1504304
8 1192 15144 2256456
12 1262 20192 3008608
16 1788 28608 4512912
24 1893 30288 6017216
32 2384 40384 9025824
48 2524 60576 18051648
64 3576 94019
96 3786 121152
149 4768 188038
192 5048 282057
298 7152 376076
What the hell is a div point?
This is just a dump of x-points that are on the secp256k1 curve (x=5 is not on the curve IIRC). Again though, I could pick any x-point on the curve to divide by, so this dump doesn't answer the question - How is creating multiple zones supposed to shift the range down, when all it's doing is shifting it up?
