Pollard's kangaroo ECDLP solver

[apvl]

So in turn is there a way to maximize the load of VanityGenBitcrack? currently only getting 123Mkeys/s

[1714098565]

1714098565

[1714098565]

1714098565

[a.a]

@WP

What tool do you use for bruteforcing x point only search?

@apvl
You are kind of in the wrong thread if you ask about VanityBitCrack in the Kangaroo-Thread

[apvl]

@WP

What tool do you use for bruteforcing x point only search?

@apvl
You are kind of in the wrong thread if you ask about VanityBitCrack in the Kangaroo-Thread

ya aint wrong lol my b

[NotATether]

If we use 33 as divisor, than to determine beginning of each range you have to multiply numbers (1 .. 33) to inverse(33, secp256k1.p)
therefore you will get 33 possible ranges beginnings:

~snip

Size of the resulting ranges will be 33 times smaller than original, so you can calculate end of each range.
In our case WP searched this range:
3  45d1745d1745d1745d1745d1745d1745d1745d1745d1745d1745d1741745d06a

To be honest, I don't know how and what exactly WP calculates, but that is main idea of such key reduction.

There is still one problem with this though, all the range beginnings are still much larger than the range end (assuming you're not simply adding length of #120 to it, if you're just dividing it by 33 or something it's guaranteed to be much smaller).

[_Counselor]

There is still one problem with this though, all the range beginnings are still much larger than the range end (assuming you're not simply adding length of #120 to it, if you're just dividing it by 33 or something it's guaranteed to be much smaller).

I'm already explained that all ranges will be X (X - divisor) times smaller than original range

FFFFFFFF / 33 = 7C1F07D
(45d1745d1745d1745d1745d1745d1745d1745d1745d1745d1745d1741745d06a + 7C1F07D) = end of range

[NotATether]

I'm already explained that all ranges will be X (X - divisor) times smaller than original range

FFFFFFFF / 33 = 7C1F07D
(45d1745d1745d1745d1745d1745d1745d1745d1745d1745d1745d1741745d06a + 7C1F07D) = end of range

Thanks for explaining this in concise terms.

Amazing how I thought this whole conjuncture was BS until someone actually came along with a proper demonstration.

The question now is how much more effective will this be vs. just dividing the keys?

[_Counselor]

Thanks for explaining this in concise terms.

Amazing how I thought this whole conjuncture was BS until someone actually came along with a proper demonstration.

The question now is how much more effective will this be vs. just dividing the keys?

i think these methods won't speed up 120 and further solution with Kangaroo or BSGS, because mathematically this is the same as dividing the original range to X parts and check them all for orginal pubkey.

[a.a]

Ok, makes mathematically sense. But if we assume that we have a smaller range and 66 (33 original and 33 with changed y) more points to check, were we definitely know that we have two keys in there. So actually can speed up the cracking time atleast in BSGS because we dont need to check for all ranges but only one of those 33 ranges.

[WanderingPhilospher]

I'm already explained that all ranges will be X (X - divisor) times smaller than original range

FFFFFFFF / 33 = 7C1F07D
(45d1745d1745d1745d1745d1745d1745d1745d1745d1745d1745d1741745d06a + 7C1F07D) = end of range

Thanks for explaining this in concise terms.

Amazing how I thought this whole conjuncture was BS until someone actually came along with a proper demonstration.

The question now is how much more effective will this be vs. just dividing the keys?

See this is my issue with public forums (the bad) lol. NotA has 1 billion merit, signed up early on this site, so people take his word (most of the time) as the "Gospel". And I have no issues with NotA, we have worked together on the pool project. I do not expect everyone to know everything, that is what I do like about public forums, we can all learn from each other.

NotA, you did go on and on and call stuff "baloney" but I do not think you understood what all brainless was saying. You "assumed" you had what he is/was doing and did not really do any thing other than program some python and left it at that. I went back and read what brainless said and what some were calling BS:

my answer were no random, and exact in all 256bit range, and what is exact location, i explain about how to calc exact range

and he did, he gave an example. I took the example and actually tried applying what he said and I found his words/example to be true. So all of the posts you are claiming to be in "concise terms" and now a "proper demonstration" were there in front of you all along but you just saw with your eyes a larger range and said ahhhhhh "baloney". But I still think people are misreading what these last posts are really about. Especially with Counselor adding to what I was saying. I never said I was testing for a speed up in searches. But you ask the question

how much more effective will this be vs. just dividing the keys

which baffles me because this whole thing centers on dividing keys lol!  But again, no one said or talked about speed up, the questions answered were, could one find exact locations of where to search for all divided keys, when dividing a pub key...exactly as brainless had said. That was my intent and my tests. So no, there is no speed up looking in other ranges versus the original range (smaller) other than, as counselor has said,

all ranges will be X (X - divisor) times smaller than original range

but the shrinkage is applicable in all ranges. BUT again, it was about finding/calculating exact range of divided keys, to prove they are not just randomly thrown out on the curve.

I know brainless sometimes says some off the wall chit...part of that is English is not everyone's first or second language and part of that (IMO) is he does not want to share everything he has learned, because maybe one day he will have the equipment to run to find the keys based off of his "math" and methods and ways. He gives clues, hints, but just because he does not give the exact method to his madness, people say it's BS or something else. And it might all be, we may never know lol. I know we laughed at his "astro" (astronomers/astrology)  comment but as I sat and thought about it, I started to visualize how to use a number where there is no float, when dividing/multiplying by 1-10. I have some ideas that I need to test, but at least I will test them to come up with my own conclusion if what he says is crazy or not, and not just jump on a band wagon of others saying it is crazy lol.

I think back to when I was new on the site and reading a thread by Etar; where people were saying he was crazy and misleading, but what he was saying was true, it was all how one looked at things. Anywho, I have learned a lot from Etar; extremely smart with ec math and programming. He has always been helpful with explaining ec math or how/why he programmed something a certain way. The difference, Etar always shared code or explained things as to where brainless just leaves bread crumbs/clues. Point being, if I had jumped on the Etar is a liar/misleading/etc. I never would have had communication with him and learned "stuff" from him. So form your own opinions about people and their "craziness" lol. And for the love of everything that is good, actually READ posts and what is said in them and what is NOT said in them. WP

[wedom]

I'm already explained that all ranges will be X (X - divisor) times smaller than original range

FFFFFFFF / 33 = 7C1F07D
(45d1745d1745d1745d1745d1745d1745d1745d1745d1745d1745d1741745d06a + 7C1F07D) = end of range

Thanks for explaining this in concise terms.

Amazing how I thought this whole conjuncture was BS until someone actually came along with a proper demonstration.

The question now is how much more effective will this be vs. just dividing the keys?

See this is my issue with public forums (the bad) lol. NotA has 1 billion merit, signed up early on this site, so people take his word (most of the time) as the "Gospel". And I have no issues with NotA, we have worked together on the pool project. I do not expect everyone to know everything, that is what I do like about public forums, we can all learn from each other.

NotA, you did go on and on and call stuff "baloney" but I do not think you understood what all brainless was saying. You "assumed" you had what he is/was doing and did not really do any thing other than program some python and left it at that. I went back and read what brainless said and what some were calling BS:

my answer were no random, and exact in all 256bit range, and what is exact location, i explain about how to calc exact range

and he did, he gave an example. I took the example and actually tried applying what he said and I found his words/example to be true. So all of the posts you are claiming to be in "concise terms" and now a "proper demonstration" were there in front of you all along but you just saw with your eyes a larger range and said ahhhhhh "baloney". But I still think people are misreading what these last posts are really about. Especially with Counselor adding to what I was saying. I never said I was testing for a speed up in searches. But you ask the question

how much more effective will this be vs. just dividing the keys

which baffles me because this whole thing centers on dividing keys lol!  But again, no one said or talked about speed up, the questions answered were, could one find exact locations of where to search for all divided keys, when dividing a pub key...exactly as brainless had said. That was my intent and my tests. So no, there is no speed up looking in other ranges versus the original range (smaller) other than, as counselor has said,

all ranges will be X (X - divisor) times smaller than original range

but the shrinkage is applicable in all ranges. BUT again, it was about finding/calculating exact range of divided keys, to prove they are not just randomly thrown out on the curve.

I know brainless sometimes says some off the wall chit...part of that is English is not everyone's first or second language and part of that (IMO) is he does not want to share everything he has learned, because maybe one day he will have the equipment to run to find the keys based off of his "math" and methods and ways. He gives clues, hints, but just because he does not give the exact method to his madness, people say it's BS or something else. And it might all be, we may never know lol. I know we laughed at his "astro" (astronomers/astrology)  comment but as I sat and thought about it, I started to visualize how to use a number where there is no float, when dividing/multiplying by 1-10. I have some ideas that I need to test, but at least I will test them to come up with my own conclusion if what he says is crazy or not, and not just jump on a band wagon of others saying it is crazy lol.

I think back to when I was new on the site and reading a thread by Etar; where people were saying he was crazy and misleading, but what he was saying was true, it was all how one looked at things. Anywho, I have learned a lot from Etar; extremely smart with ec math and programming. He has always been helpful with explaining ec math or how/why he programmed something a certain way. The difference, Etar always shared code or explained things as to where brainless just leaves bread crumbs/clues. Point being, if I had jumped on the Etar is a liar/misleading/etc. I never would have had communication with him and learned "stuff" from him. So form your own opinions about people and their "craziness" lol. And for the love of everything that is good, actually READ posts and what is said in them and what is NOT said in them. WP

Perfect! I totally agree! Everyone is attacking Brainless for nothing without understanding his math. On the contrary, you have to listen carefully and understand. I've been working on this topic for several months now.
I can confirm what Brainless says about the key allocation. I have long since figured out how and where to look for which key when dividing, what the ranges will be and how to find them exactly. You write everything correctly in your last posts, the ranges are accurate and in the exact locations. I figured out how the keys are located if we are dividing by a "magic number" or not (believe me, there is a difference). How to distribute them in ascending or descending order anyway and many other things.
Does everyone think they know everything? No one knows anything. Don't stop learning and seeking new knowledge.
In fact the number 30240 has turned out to be very interesting to me. That one number opened up a horizon of different options for me. And how many Brainless knows these numbers. He knows the idea, he has an easier time with it. I am working on ways to use it. It is unlikely that I can come up with a Brainless solution, since there are millions of these ways and the idea of Brainless itself is unknown. I'm like a blind kitten. That's okay. I love math, I love to think and think and think. Maybe I will someday understand what Brainless meant and come up with a solution. Maybe I'll find another solution. I will think.
Brainless don't be offended by the ignorance of many.
Regards to all.

[NotATether]

In the 30+ minutes that I wasted hammering (and subsequently trashing) a reply to this, I just updated the pkarith script to spit out the correct end points... took me just two minutes and 2 lines of code change. https://gist.github.com/ZenulAbidin/e8687d9e16189c99d192e97d37e71dbe

See how more effectively and faster I can implement stuff when I have all the info I need, clearly (emphasis on that), beforehand?

I can only work with information I have at hand (without guessing random stuff). Nowhere was it said that you had to divide max value by 32 and add that to start value to get the end value... take a look back at them yourself.

Otherwise you get stuff like a broken Kangaroo-256 with a borked hashtable lookup function.

There wouldn't have even been a flamewar if I had that info. Instead I got "0.01325 to 0.0625" which I understood to mean that the zones themselves are the start and end points. With this info, making an assumption about division at that stage would've been a guess.

And none of this was resolved until Counselor explained this important point a few posts up.

(also, I'm not jesus, not sure why people would think that of me  )

But I still think people are misreading what these last posts are really about. Especially with Counselor adding to what I was saying. I never said I was testing for a speed up in searches. But you ask the question

how much more effective will this be vs. just dividing the keys

which baffles me because this whole thing centers on dividing keys lol!  But again, no one said or talked about speed up, the questions answered were, could one find exact locations of where to search for all divided keys, when dividing a pub key...exactly as brainless had said. That was my intent and my tests. So no, there is no speed up looking in other ranges versus the original range (smaller) other than, as counselor has said,

all ranges will be X (X - divisor) times smaller than original range

but the shrinkage is applicable in all ranges. BUT again, it was about finding/calculating exact range of divided keys, to prove they are not just randomly thrown out on the curve.

Misunderstanding people's posts is an epidemic however it can be drastically reduced by just being clear, which is that was someone's intention they would've done automatically.

P.S. By

how much more effective will this be vs. just dividing the keys

I was referring to the iceland "subtract then divide" method which I assumed that everyone here would've easily recognized.

[WanderingPhilospher]

I was referring to the iceland "subtract then divide" method which I assumed that everyone here would've easily recognized.

nahhhh, you know what they say about "assume" ass-u-me; I've never really paid attention to that script; I've used another "division" script for almost 2 years. You know what they say, if something ain't broke, don't try to fix it lol.

There wouldn't have even been a flamewar if I had that info. Instead I got "0.01325 to 0.0625" which I understood to mean that the zones themselves are the start and end points. With this info, making an assumption about division at that stage would've been a guess.

I have zero clues what this is about. If it's about something brainless said, then you should have known it was "off" or fat fingered or something. When it was said:

if you divide 1 by 32, you will get 0.3125

didn't seem accurate to me but I understood what was meant.

As for

And none of this was resolved until Counselor explained this important point a few posts up

His and I methods are different, but I do not understand what was so clear or even originally misunderstood. I mean if you are dividing by a number, then it should be obvious to everyone the range(s) are shrinking. I don't see how what he said shed light on anything, but I guess it did for/to you so that is good.
My "zones" are my start points and it should be obvious that my end range would not be larger than the original start/end range. If original was 40 bit then "zones" start to end cannot be larger than 40 bits...

See how more effectively and faster I can implement stuff when I have all the info I need, clearly (emphasis on that), beforehand?

That must be a difference between you and I. I am used to people/life not being 100% clear. Sometimes you have to read between the lines or actually, you know, do your own testing. If something isn't clear to you, ask questions, if those questions do not get answered well enough for you to still understand something, then do not try to work on it. If it was unclear, don't create something and then call something "baloney" because you did not understand what was being said. That's like someone telling you to use the pythagorean theorem to square up a corner and instead of you asking what the hell is that, you just assume they meant a python theorem and you go out and by a snake and learn how to program in python and then you try to square the corner up and it's off...then you say, your python theory is "baloney", my corner is crooked as a politician. lol

All good notA; last thing...you can't expect everyone on here to be 100% clear; language barriers, fat fingers, lack of knowledge, etc.

Well hell, I gotta run...I am putting up a garage wall and need a snake (lol)

[WanderingPhilospher]

In fact the number 30240 has turned out to be very interesting to me. That one number opened up a horizon of different options for me. And how many Brainless knows these numbers. He knows the idea, he has an easier time with it. I am working on ways to use it. It is unlikely that I can come up with a Brainless solution, since there are millions of these ways and the idea of Brainless itself is unknown. I'm like a blind kitten. That's okay. I love math, I love to think and think and think. Maybe I will someday understand what Brainless meant and come up with a solution. Maybe I'll find another solution. I will think.

Keep on learning and/or trying to learn...

I can openly admit that probably 99% of the people on here are smarter than me when it comes to ec math (but def not Cobras, lol). I do not claim to be an expert at it or programming. But like you, I like to learn and "tinker". I can follow examples and learn from my mistakes. And I have zero issues saying "I was wrong" and if someone calls me out for being wrong, I'm ok with that too, it's how I learn.

[COBRAS]

In fact the number 30240 has turned out to be very interesting to me. That one number opened up a horizon of different options for me. And how many Brainless knows these numbers. He knows the idea, he has an easier time with it. I am working on ways to use it. It is unlikely that I can come up with a Brainless solution, since there are millions of these ways and the idea of Brainless itself is unknown. I'm like a blind kitten. That's okay. I love math, I love to think and think and think. Maybe I will someday understand what Brainless meant and come up with a solution. Maybe I'll find another solution. I will think.

Keep on learning and/or trying to learn...

I can openly admit that probably 99% of the people on here are smarter than me when it comes to ec math (but def not Cobras, lol). I do not claim to be an expert at it or programming. But like you, I like to learn and "tinker". I can follow examples and learn from my mistakes. And I have zero issues saying "I was wrong" and if someone calls me out for being wrong, I'm ok with that too, it's how I learn.

If you so cool WP, yor script can find a privkey for 02dd4127ed0232dcf6919e1cbf40562eeb6f050e0cc8663a576482100a51c116fa



Range only from 1:2^84


??

If someone  find my privkey he get 500$ in btc

??

ASAP please.

[WanderingPhilospher]

If you so cool WP, yor script can find a privkey for 02dd4127ed0232dcf6919e1cbf40562eeb6f050e0cc8663a576482100a51c116fa

After a quick review and search, that pubkey is outside of the astro curve, if it could be represented in ecc terms it would be sitting in the 2^296 range (which doesn't exist) but we can reduce it down via qdm space reducer and get it down to around 2^246 without losing its location. We could probably then run lxsx diaphram slex to squeeze it down maybe another 10 bits...12 bits at most. If we do not care about losing keyspace range, we can use orien's reverse beltology (mult with cross division and addpt) and easily get it down to a more comfortable 2^200 range. That is the best that I could do. Maybe someone can shrink it more? How did you come up with 02dd4127ed0232dcf6919e1cbf40562eeb6f050e0cc8663a576482100a51c116fa? I can send away for master and all his slaves to carry back and search for many privets, but master has pinkeye and no bueno. Update: when giant b steps closed in on targeted range and passed range, it triggered the German index calc and estimated the 2^296 but to be honest it could be higher because the gic always works congruently with the Chinese remainder theory and it kicked in and eventually its red solo cup overfilleth and stopped. maybe RAM shortage?! I still honestly believe if mem manufacturers would use streamlined, fractal-shaped perimeters (like flux compression) RAM could be used to full potential...but until that happens (probably never) I will continue researching a binary/hash table function that uses a new matrix: x:= (1:0:1:0) which speeds up search via matrix multiplication and stretches the bounds of unitary transformation, but ultimately will need bigger red solo cup (given an orthonormal basis), IMO. But no one understands or can yet program, in order to hyperbole the keyspace, in pure states, the extremal points of the keyspace range, when dealing with rsc. Any way, find keys and proceed to party...

[wedom]

In fact the number 30240 has turned out to be very interesting to me. That one number opened up a horizon of different options for me. And how many Brainless knows these numbers. He knows the idea, he has an easier time with it. I am working on ways to use it. It is unlikely that I can come up with a Brainless solution, since there are millions of these ways and the idea of Brainless itself is unknown. I'm like a blind kitten. That's okay. I love math, I love to think and think and think. Maybe I will someday understand what Brainless meant and come up with a solution. Maybe I'll find another solution. I will think.

Keep on learning and/or trying to learn...

I can openly admit that probably 99% of the people on here are smarter than me when it comes to ec math (but def not Cobras, lol). I do not claim to be an expert at it or programming. But like you, I like to learn and "tinker". I can follow examples and learn from my mistakes. And I have zero issues saying "I was wrong" and if someone calls me out for being wrong, I'm ok with that too, it's how I learn.

If you so cool WP, yor script can find a privkey for 02dd4127ed0232dcf6919e1cbf40562eeb6f050e0cc8663a576482100a51c116fa



Range only from 1:2^84


??

If someone  find my privkey he get 500$ in btc

??

ASAP please.

If the key is integer, range 84 will be found in kangaroo in a small amount of time. And I think you would have found it a long time ago yourself. Or by the same logic, reduce it by another 15 bits and the kangaroo will find it in 1 second.
I think it is fractional, just like last time. Which means it is in a different range. You have to reduce it so that the result of the reduction is a whole. You can not divide by a number if the original key does not divide by it, I wrote to you about this in personal correspondence.
Not knowing the algorithm how it was obtained means you have to look in a 256 bit range, which is impossible.

[_Counselor]

If you so cool WP, yor script can find a privkey for 02dd4127ed0232dcf6919e1cbf40562eeb6f050e0cc8663a576482100a51c116fa



Range only from 1:2^84


??

If someone  find my privkey he get 500$ in btc

??

ASAP please.

There are many GPU renting services across the internet, you can rent power GPU for one hour and find this key spending just a few bucks.
If you're so sure you've found the correct key and the correct range this time, why would you ask anyone to find it?

[Etar]

Try to create bsgs with GPU support(cuda).
Now for me result is to slow due to use binary search, not bloom filter or hashtable but...
For test use pubkey in JeanLucPons BSGS example: 0459A3BFDAD718C9D3FAC7C187F1139F0815AC5D923910D516E186AFDA28B221DC994327554CED8 87AAE5D211A2407CDD025CFC3779ECB9C9D7F2F1A1DDF3E9FF8
start from 49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5e0000000000000000
in JeanLucPons BSGS with  Xeon X5647 2.93GHz with 12GB of RAM  result is 17:46
I use 6x1660super each give around 48Mop/s x134217728, so i found key in 329s this is around 2^ 55.186846572340194 keys/s

Code:

GPU #1 Key:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5eba34000000000000  48MKey/s x134217728
GPU #0 Key:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5ebca0000000000000  47MKey/s x134217728
GPU #2 Key:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5eb7b0000000000000  48MKey/s x134217728
GPU #5 Key:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5ec08c000000000000  50MKey/s x134217728
GPU #3 Key:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5eb82c000000000000  48MKey/s x134217728
GPU #4 Key:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5eb878000000000000  48MKey/s x134217728
***********GPU#1************
Total solutions: 1
Winnonce: 6189319
ArrayID: 97454637
GPU #0 Key:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5ebdc0000000000000  47MKey/s x134217728
SolutionID: 65509676
Yay!!>49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5ebb3ef3883c1866d4
****************************
Found in 329 seconds

Hashrate low due to use 134217728 baby items, when use 4194304 items hash is around 260Mop/s x4194304 per card.
In this example GPU memory usage is around 2Gb

[WanderingPhilospher]

Try to create bsgs with GPU support(cuda).
Now for me result is to slow due to use binary search, not bloom filter or hashtable but...
For test use pubkey in JeanLucPons BSGS example: 0459A3BFDAD718C9D3FAC7C187F1139F0815AC5D923910D516E186AFDA28B221DC994327554CED8 87AAE5D211A2407CDD025CFC3779ECB9C9D7F2F1A1DDF3E9FF8
start from 49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5e0000000000000000
in JeanLucPons BSGS with  Xeon X5647 2.93GHz with 12GB of RAM  result is 17:46
I use 6x1660super each give around 48Mop/s x134217728, so i found key in 329s this is around 2^ 55.186846572340194 keys/s

Code:

GPU #1 Key:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5eba34000000000000  48MKey/s x134217728
GPU #0 Key:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5ebca0000000000000  47MKey/s x134217728
GPU #2 Key:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5eb7b0000000000000  48MKey/s x134217728
GPU #5 Key:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5ec08c000000000000  50MKey/s x134217728
GPU #3 Key:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5eb82c000000000000  48MKey/s x134217728
GPU #4 Key:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5eb878000000000000  48MKey/s x134217728
***********GPU#1************
Total solutions: 1
Winnonce: 6189319
ArrayID: 97454637
GPU #0 Key:49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5ebdc0000000000000  47MKey/s x134217728
SolutionID: 65509676
Yay!!>49dccfd96dc5df56487436f5a1b18c4f5d34f65ddb48cb5ebb3ef3883c1866d4
****************************
Found in 329 seconds

Hashrate low due to use 134217728 baby items, when use 4194304 items hash is around 260Mop/s x4194304 per card.
In this example GPU memory usage is around 2Gb

welcome back welcome back welcome back!!

I thought of BSGS with GPU. But it would have a CPU/central server that would do the baby steps and then the GPUs would do the giant steps.

[NotATether]

Update: I now have a way to empirically guess some ofthe bits of private keys that are randomly generated:

https://gist.github.com/ZenulAbidin/ac00845048c36ceb81df6bc47cbcb4e5

Code:

# First, run this in shell:
# j=1000 # Sample size, feel free to change.
# for ((i=0; $i<$j; i++)); do openssl rand -hex 32 >> ~/Documents/randalysis.txt; echo -en "\n" >> ~/Documents/randalysis.txt; done
# sed -i '/^\s*$/d' ~/Documents/randalysis.txt
# pip install bitarray

import bitarray
import bitarray.util
from os.path import expanduser

sample=1000 # This is the number of example private keys you have generated above.
nkeys = 260 # This is the number of keys you want, change it accordingly.

home = expanduser("~")
with open(home+"/Documents/randalysis.txt", "r") as fp:
    s = fp.read()

l = s.split("\n")
l = l[:-1]   # Remove extraneous blank element
cl = [0]*256
delta = [0]*256

# Values closer to zero - more likely to be zero, values closer to one - more likely to be one
for i in l:                     
    ba = bitarray.util.hex2ba(i)
    ba.reverse()                
    for j in range(0, 256):     
        cl[j] += ba[j]              
        delta[j] = cl[j]/sample

# Values negative - more likely to be zero, values positive - more likely to be one
# Because values will be between -0.5 and 0.5, we must "explode" this
# (by two to get values from -1 to 1)
# to get percentages between 0% and 100% for likely zero and likely one.
deltat = [((delta[t] - 0.5)*2, t) for t in range(0,256)]
deltat = sorted(deltat, key=lambda x: abs(x[0]), reverse=True)
#deltat.sort(key=lambda x: x[0])
#deltatmin = [t for t in deltat if t[0] < 0.5]
#deltatmax = [t for t in deltat if t[0] > 0.5]
#deltatmax.sort(key=lambda x: x[0], reverse=True)
#deltateq = [t for t in deltat if t[0] == 0.5]
#delta = [d - 0.5 for d in delta]

import itertools
lz = []
# Adjust this value to return the combinations of probabilities for larger groups of bits.
# Warning: you should experiment with this setting, because setting this too high will
# make so many combinations, it will finish your RAM.
# Probability theory means that the probability of multiple bits having some specific values is
# __MUCH LESS__ than the probability of one bit having a aprticular value.
maxcomb = 2
for i in range(1,maxcomb+1):
    cdt = itertools.combinations(deltat, i)
    for c in cdt:
        total_prob = 1
        bit_configs = []
        for it in c:
            if it[0] < 0:
                # Zero
                bit_configs.append((it[1], 0))
            elif it[0] < 1:
                # One
                bit_configs.append((it[1], 1))
            else:
                # perfectly even, no bias here so skip to next one
                continue
            total_prob *= abs(it[0])
        lz.append((total_prob*100, bit_configs))

lz.sort(key = lambda x: x[0], reverse=True)

import pprint
print("========== TOP {} MOST LIKELY BIT CONFIGURATIONS (Highest probability first) ==========".format(nkeys))
print("Output format: <probability> [(<bit number between 0-255>, <0 or 1>), ...]")
pprint.pprint(lz[0:nkeys])

The probabilities are quite small though (as they should be), and the highest probabilities are still less than 10%. This could indicate some bias in OpenSSL RNG depending on what the user is doing on the mouse and keyboard...