Topic: Pollard's kangaroo ECDLP solver - page 29. (Read 60381 times)

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.

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.

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:
didn't seem accurate to me but I understood what was meant.

As for 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...

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)

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  )

---

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


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

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.

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: 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 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, 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

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.

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.

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'm already explained that all ranges will be X (X - divisor) times smaller than original range

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).

ya aint wrong lol my b

@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

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

No, as they are different principles.

BitCrack gets a list of addresses and brute forces the privatekey. This means that if we have public keys, we can convert them to addresses and then bruteforce them in BitCrack, but we have the overhead of privatekey to public key to sha256 to ripemd160.
VanitySearch can as far as I know use directly the public keys so there is not that overhead, what we have in bitcrack to do the extra work of transforming the public key to the ripemd160
Kangaroo is not really bruteforcing the publickey but using a mathematical process to crack it.

So no, you can not mix them.

Would it be possible to combine Kangaroo algorithms with other programs such at Vanity or BitCrack. Currently running a VanitySearch
Number of CPU thread: 32
GPU: GPU #0 NVIDIA GeForce RTX 3050 Ti Laptop GPU (20x0 cores) Grid(160x128)
[952.00 Mkey/s][GPU 910.98 Mkey/s][Total 2^39.19][Prob 50.7%][60% in 00:03:15]
on BitCrack Roughly 600 Mkeys/s
Kangaroo is [563.76 MK/s][GPU 451.75 MK/s][Count 2^32.43][Dead 0][10s (Avg 33.6656y)

You will find 2 pubs in each range, regardless of how many times you divide or with what number you divide with, because yes, I am searching for xpoints only. But if you search for pub key, you will find at least one in every range.

Look at it like this, if you divide by 33, you will have 33 new pubkeys and 33 ranges. Each range will contain a pubkey; 33 = 33; 33/33=1

Please elaborate.

After you did the division twice?

Or because you only search for the xPub and thats why there are two?

Counselor, our methods are close...same concept/principle.

Note: There will be at least 2 keys that will solve original pub key's private key, in every range.

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

and if you search all 33 ranges, one of it will contains the key which you got when divided target key by 33.

Soooo

3  x 45d1745d1745d1745d1745d1745d1745d1745d1745d1745d1745d1741745d06a = beginning of the range
then ffffffff divided by 33 + begin of the range marks the end of the range?