Post
Topic
Board Development & Technical Discussion
Re: Mark1 - pollard rho implementation (38 minutes for 80 bits solving on CPU)
by
AlexanderCurl
on 21/06/2025, 03:30:09 UTC
It works fine the way I explained it on my PC and my implementation. I am not interested in Kangaroo and never refer to it.
Here is the TEMPLATE for you.

Thx for the template, but I already use that in my PointsBuilder demo.

I think you misunderstood my point though. This batch addition that computes both P + Q and P - Q has no usefulness outside BSGS or simply building that specific array of results (e.g. for brute-forcing the H160).

It simply slows down the processing, since there is nothing useful for having both of those points computed. Maybe you should read again what Akito was asking, but more carefully. The answer to his question is that having a DP obtained via P - Q will almost never be hit from another route then the current one, since the pseudo-random walk ends (the point is not used as a new base point). It's basically equivalent to  having a DP which is 1 bit lower, however the processing is slowed down. The probability of having it hit by another walk is so close to zero, that it's simply not worth computing it at all. RC does use it though, but not always, and it's for a different purpose anyway.

And for rho or Kangaroo, you always, always need the Y coordinate, because it's needed to actually do the next jump. So your "let's only compute X" is useless for this case.

Exacly my answer is for Akito and not for you. I guess he understood what I meant. And moreover I heard that fairytale from you before that something "will not work or should not work and only you know how". Let alone that explanation of mine is pretty simple to implement and see that it works. I have much complex ones that work as well when I implement them but it is a waste of time explaining something to you.