Bitcoin puzzle transaction ~32 BTC prize to who solves it

[Torin Keepler]

The point of this challenge is not the $200 itself, but the approach behind it.
I want to demonstrate what I believe is currently the most effective publicly available method for working on Puzzle #135. The reward is simply a way to motivate participation, while the real goal is to showcase the efficiency of the technique.

Post some numbers, otherwise for $200 no one (serious) cares.

A faster speed with a higher complexity is not always better than a lower speed with lower complexity. Pollard Rho is not adequate for solving an IDLP, so usually one would stop reading when this gets mentioned as "efficient". Because it's not.

This will be a modified version of the RCKangaroo program with several efficiency improvements, including saving the traversal path and checkpoint data for further analysis. I have also developed a separate tool, KeyAuditor, which analyzes these checkpoint files and calculates the private key if a collision is detected.

Later we will test my version; I will announce the public key and the range a bit later — the range will not be too difficult, so we can properly test my fork within this challenge. I would also like to warn that using other programs will not allow you to claim the prize. I will explain the reason for that later.

In this way, we can significantly increase the probability of finding the private key by detecting collisions between different participants. Moreover, the collision analysis can be performed in a decentralized manner by any participant. All that is required is to maintain a parallel database of checkpoint files.
I would also like to note that the search range for the private key is not very large, so the search process will not take long.

The DP value will be set to 30, which means the size of the checkpoint database will not be too large.

https://www.blockchain.com/explorer/addresses/btc/1NYgvjFGSCZvb7RELypgEocYRLGCa7LyHy
https://t.me/puzzle135/14976

[brainless]

The point of this challenge is not the $200 itself, but the approach behind it.
I want to demonstrate what I believe is currently the most effective publicly available method for working on Puzzle #135. The reward is simply a way to motivate participation, while the real goal is to showcase the efficiency of the technique.

Post some numbers, otherwise for $200 no one (serious) cares.

A faster speed with a higher complexity is not always better than a lower speed with lower complexity. Pollard Rho is not adequate for solving an IDLP, so usually one would stop reading when this gets mentioned as "efficient". Because it's not.

This will be a modified version of the RCKangaroo program with several efficiency improvements, including saving the traversal path and checkpoint data for further analysis. I have also developed a separate tool, KeyAuditor, which analyzes these checkpoint files and calculates the private key if a collision is detected.

Later we will test my version; I will announce the public key and the range a bit later — the range will not be too difficult, so we can properly test my fork within this challenge. I would also like to warn that using other programs will not allow you to claim the prize. I will explain the reason for that later.

In this way, we can significantly increase the probability of finding the private key by detecting collisions between different participants. Moreover, the collision analysis can be performed in a decentralized manner by any participant. All that is required is to maintain a parallel database of checkpoint files.
I would also like to note that the search range for the private key is not very large, so the search process will not take long.

The DP value will be set to 30, which means the size of the checkpoint database will not be too large.

https://www.blockchain.com/explorer/addresses/btc/1NYgvjFGSCZvb7RELypgEocYRLGCa7LyHy
https://t.me/puzzle135/14976

In short words
You are trying to collect from 100s gpu holder, work of dp for your database, where you check privatekey for 135 puzzle and try to win 13.5 btc against 200 $
May I right ?

[Torin Keepler]

The point of this challenge is not the $200 itself, but the approach behind it.
I want to demonstrate what I believe is currently the most effective publicly available method for working on Puzzle #135. The reward is simply a way to motivate participation, while the real goal is to showcase the efficiency of the technique.

Post some numbers, otherwise for $200 no one (serious) cares.

A faster speed with a higher complexity is not always better than a lower speed with lower complexity. Pollard Rho is not adequate for solving an IDLP, so usually one would stop reading when this gets mentioned as "efficient". Because it's not.

This will be a modified version of the RCKangaroo program with several efficiency improvements, including saving the traversal path and checkpoint data for further analysis. I have also developed a separate tool, KeyAuditor, which analyzes these checkpoint files and calculates the private key if a collision is detected.

Later we will test my version; I will announce the public key and the range a bit later — the range will not be too difficult, so we can properly test my fork within this challenge. I would also like to warn that using other programs will not allow you to claim the prize. I will explain the reason for that later.

In this way, we can significantly increase the probability of finding the private key by detecting collisions between different participants. Moreover, the collision analysis can be performed in a decentralized manner by any participant. All that is required is to maintain a parallel database of checkpoint files.
I would also like to note that the search range for the private key is not very large, so the search process will not take long.

The DP value will be set to 30, which means the size of the checkpoint database will not be too large.

https://www.blockchain.com/explorer/addresses/btc/1NYgvjFGSCZvb7RELypgEocYRLGCa7LyHy
https://t.me/puzzle135/14976

In short words
You are trying to collect from 100s gpu holder, work of dp for your database, where you check privatekey for 135 puzzle and try to win 13.5 btc against 200 $
May I right ?

You understood the general idea, but not entirely correctly. I am only aiming for a small fraction of the 135-puzzle reward. The main share will go to the participants whose checkpoints collide, as well as to those who contribute a large amount of work even if they are not part of the final collision.

And to answer your next question in advance: yes, the large pool for Puzzle 135 already exists, and the database is substantial. However, this does not affect your ability to win the $200 challenge, which—according to my estimates—will take around seven days.

I would also like to emphasize that the core idea is decentralization. There is no central server and no central authority controlling the process. Anyone can maintain their own copy of the challenge database and independently check it for collisions in parallel.

Yes, there are certain mechanisms in place to protect all participants from the risk of someone attempting to steal the private key the moment it is discovered. But that is a separate topic for discussion.

[BlackAKAAngel]

To all puzzle hunters of Puzzle 71: It starts with the number 7 and consists of 4 letters and 5 numbers—2 small numbers and 3 larger numbers. If you have strong equipment, you have the key for a couple of days.Don't ask how i know that just try and don't forget me if this help you just say Hallo.....

[Torin Keepler]

To all puzzle hunters of Puzzle 71: It starts with the number 7 and consists of 4 letters and 5 numbers—2 small numbers and 3 larger numbers. If you have strong equipment, you have the key for a couple of days.Don't ask how i know that just try and don't forget me if this help you just say Hallo.....

Puzzle #71 is at least four times more difficult than Puzzle #135.
Because of that, there is no practical reason to focus on solving #71, especially considering that its reward is much smaller.
It makes far more sense to work on Puzzle #135 first.

[kTimesG]

This will be a modified version of the RCKangaroo program with several efficiency improvements, including saving the traversal path and checkpoint data for further analysis. I have also developed a separate tool, KeyAuditor, which analyzes these checkpoint files and calculates the private key if a collision is detected.

Already smelling a few red flags:

- first you said PollardRho, now it's RCKang - do you know the difference?

- why is it a challenge but you want people to share work files? This is a total contradiction.

- you mangle centralized vs decentralized issues from one post to the next.

Now, here's the main issue though: you added some funds to some address. If you want people to trust that it's a challenge, you should probably prove that you actually know the private key of that address yourself. Otherwise, its trivial to derive such an address off from the real Puzzle 135 pubKey and piggy back on the rest of the planet to solve it for you without them even knowing.

[Torin Keepler]

This will be a modified version of the RCKangaroo program with several efficiency improvements, including saving the traversal path and checkpoint data for further analysis. I have also developed a separate tool, KeyAuditor, which analyzes these checkpoint files and calculates the private key if a collision is detected.

Already smelling a few red flags:

- first you said PollardRho, now it's RCKang - do you know the difference?

- why is it a challenge but you want people to share work files? This is a total contradiction.

- you mangle centralized vs decentralized issues from one post to the next.

Now, here's the main issue though: you added some funds to some address. If you want people to trust that it's a challenge, you should probably prove that you actually know the private key of that address yourself. Otherwise, its trivial to derive such an address off from the real Puzzle 135 pubKey and piggy back on the rest of the planet to solve it for you without them even knowing.

Before addressing your points, let me note one thing:
any criticism should be supported by clear arguments. Otherwise, it becomes simple “bla-bla-bla” without substance.

Now I will respond to each of your statements:

1. “First you said PollardRho, now it’s RCKang - do you know the difference?”

RCKangaroo is a modified high-efficiency implementation based on the general principles of Pollard’s method for collision search.
The program uses a number of practical optimizations and improvements in performance, but the underlying mathematical idea still follows the Pollard-style random-walk collision search approach.

Regarding your claim that RCKangaroo and Pollard’s algorithm are “different things” - does it not concern you that the term Kangaroo Algorithm was originally proposed by John M. Pollard himself?
Now answer this simple question: why do you think the program RCKangaroo is called “Kangaroo” in the first place?

From a scientific standpoint, RCKangaroo inherits:

the same collision-search principle,

the same √range complexity class,

but with highly optimized step functions and checkpoint mechanics.

So your claim that Pollard and Kangaroo contradict each other is simply incorrect.

2. “Why is it a challenge but you want people to share work files? Contradiction.”

There is no contradiction here at all.

Participants share checkpoint files voluntarily.
Anyone can verify them independently using KeyAuditor.
In the event a collision occurs, no single participant can quietly hide the private key, because anyone can process the shared data.

This is not centralization - this is transparent, independent verification by anyone who chooses to participate.

3. “You mangle centralized vs decentralized issues.”

Again - you provide no arguments, only an accusation.

Decentralization here means:

there is no central server that receives all checkpoints

there is no single point of trust

every participant can maintain their own copy of the database

every participant can run KeyAuditor locally and check for collisions

if a private key is discovered, everyone will know, because verification is open to all

So your statement is baseless. If you believe otherwise, please present actual reasoning.

4. “You should prove that the challenge address belongs to you.”

I will not send an outgoing transaction from the challenge address itself, because that would reveal the public key prematurely.

However, I can easily send a small test amount from the address that funded the challenge address back to the challenge address.
This fully proves that the funding was made by me, without exposing the challenge pubkey earlier than intended.

This is a standard, safe proof-of-ownership.

5. Final remark

Please, in the future, provide arguments when you make accusations.
Otherwise, you risk appearing like someone who cannot stand behind their own words.
I will always answer your points clearly - I simply expect the same level of reasoning in return.

[coinableS]

Has anyone else attempted to quantify the actual keys per second on some of the popular puzzle solving scripts (ie fixedpaul)?

The fixedpaul vanitysearch reports a much higher keys per second than other scripts yet when I attempt to quantify those checks via expected prefix matches per m/keys checked it fails horribly, suggesting in reality it's running at 1% or less than the reported keys per second.

EDITED 12/5/25: Posted an update, likely an isolated issue on my end and not a "fixedpaul" issue.

[E36cat]

Has anyone else attempted to quantify the actual keys per second on some of the popular puzzle solving scripts (ie fixedpaul)?

The fixedpaul vanitysearch reports a much higher keys per second than other scripts yet when I attempt to quantify those checks via expected prefix matches per m/keys checked it fails horribly, suggesting in reality it's running at 1% or less than the reported keys per second.

I'm reliably hitting one 1PWo3Je prefix hit approx every 5 billion keys checked on "slower" scripts.
Fixedpaul on the other hand is only hitting one 1PWo3J every 80 billion keys, and zero 1PWo3Je's.

I've tested these for weeks on multiple machines getting the same results: Fixedpaul is the fastest if you trust it's keys per second output; and if going by average prefix matches per m/keys checked the fixedpaul produces the least amount of prefix matches.

Prefix matches don't really matter but based on simple probability and averages it's a decent way to benchmark the actual keys checked.

  

does your fixedpaul find any prefixes after lets say 5 hours of running? mine it does not , in 3-4 hours i find prefixes, after that it can run for days and get no prefixes...

[kTimesG]

RCKangaroo is a modified high-efficiency implementation based on the general principles of Pollard’s method for collision search.

No its not. Pollard Rho, Pollard Kangaroo, and RC's "kangaroo" (based on Gaudry-Schost, not Pollard) are three totally different algorithms, that run on totally different principles, with totally different parameters, totally different setups, and having totally different complexities.

This is easily provable by reading some basic papers on each of the three methods. Confusing them in such a gross manner is a clear sign that you have no idea what you're doing.

Anyone can verify them independently using KeyAuditor.
This is not centralization — this is transparent, independent verification by anyone who chooses to participate.

No idea what your KeyAuditor does, or why it is needed. How is it different than "hey, guys, please everyone upload your work files so I can process them myself"? Encouraging (or forcing) people to share is equivalent to piggy-backing on their work. In fact, forcing people to use tool X or Y is not a challenge, but an invitation for attracting idiots.

I will not send an outgoing transaction from the challenge address itself, because that would reveal the public key prematurely.

Jesus Christ! You can simply provide the SHA256(pubKey) without having to expose any public key.

[Niekko]

Participants share checkpoint files voluntarily.

… I don’t understand why I’m supposed to hand over my dp for maybe 200 dollars. If you really want the community’s help, create a pool and split the reward fairly.

[Torin Keepler]

RCKangaroo is a modified high-efficiency implementation based on the general principles of Pollard’s method for collision search.

No its not. Pollard Rho, Pollard Kangaroo, and RC's "kangaroo" (based on Gaudry-Schost, not Pollard) are three totally different algorithms, that run on totally different principles, with totally different parameters, totally different setups, and having totally different complexities.

This is easily provable by reading some basic papers on each of the three methods. Confusing them in such a gross manner is a clear sign that you have no idea what you're doing.

Anyone can verify them independently using KeyAuditor.
This is not centralization — this is transparent, independent verification by anyone who chooses to participate.

No idea what your KeyAuditor does, or why it is needed. How is it different than "hey, guys, please everyone upload your work files so I can process them myself"? Encouraging (or forcing) people to share is equivalent to piggy-backing on their work. In fact, forcing people to use tool X or Y is not a challenge, but an invitation for attracting idiots.

I will not send an outgoing transaction from the challenge address itself, because that would reveal the public key prematurely.

Jesus Christ! You can simply provide the SHA256(pubKey) without having to expose any public key.

You still haven’t answered my question. Why does the program use the word “Kangaroo” in its name, and who developed the Kangaroo algorithm? Since the program is based on the Kangaroo algorithm originally proposed by John M. Pollard, stating that RCKangaroo is a modified implementation built on the basis of Pollard’s method is entirely correct.

SHA256(pubKey) = fb6bb8132a0ca0c7c93fe4c29a6d4af241edf50622710673825edcefea351a7a

Here are some concrete, code level reasons why RCKangaroo is a Pollard-kangaroo implementation, not a Gaudry–Schost scheme:

Code:

HalfRange.Set(1);
HalfRange.ShiftLeft(Range - 1);      // 2^(Range-1)
PntHalfRange = ec.MultiplyG(HalfRange);
PntA = ec.AddPoints(PntToSolve, NegPntHalfRange);
PntB = PntA; PntB.y.NegModP();

This is exactly the classical Pollard’s Kangaroo scheme on an interval: the tame and wild herds run within ±Half Range around the target point. The Gaudry–Schost method does not use this one-dimensional interval construction at all.

A jump function together with a distance counter is the textbook Pollard walk:

Code:

jmp_ind = x[0] % JMP_CNT;
jmp_table = ((L1S2 >> group) & 1) ? jmp2_table : jmp1_table;

[coinableS]

Has anyone else attempted to quantify the actual keys per second on some of the popular puzzle solving scripts (ie fixedpaul)?

The fixedpaul vanitysearch reports a much higher keys per second than other scripts yet when I attempt to quantify those checks via expected prefix matches per m/keys checked it fails horribly, suggesting in reality it's running at 1% or less than the reported keys per second.

I'm reliably hitting one 1PWo3Je prefix hit approx every 5 billion keys checked on "slower" scripts.
Fixedpaul on the other hand is only hitting one 1PWo3J every 80 billion keys, and zero 1PWo3Je's.

I've tested these for weeks on multiple machines getting the same results: Fixedpaul is the fastest if you trust it's keys per second output; and if going by average prefix matches per m/keys checked the fixedpaul produces the least amount of prefix matches.

Prefix matches don't really matter but based on simple probability and averages it's a decent way to benchmark the actual keys checked.

  

does your fixedpaul find any prefixes after lets say 5 hours of running? mine it does not , in 3-4 hours i find prefixes, after that it can run for days and get no prefixes...

I wasn't checking for that and don't have concrete data but I do believe I noticed most prefixes were found during the first hour or two.

[kTimesG]

You still haven’t answered my question. Why does the program use the word “Kangaroo” in its name, and who developed the Kangaroo algorithm? Since the program is based on the Kangaroo algorithm originally proposed by John M. Pollard, stating that RCKangaroo is a modified implementation built on the basis of Pollard’s method is entirely correct.

SHA256(pubKey) = fb6bb8132a0ca0c7c93fe4c29a6d4af241edf50622710673825edcefea351a7a

Great, so now we went from Rho (which isn't even an interval DLP algo) to Kangaroo to Pollard to why some guy chose to name his proof of concept in some way, even though it technically does something using totally different principles. Cool. I don't have an answer. But I do know one thing for sure: the Kangaroo algorithm does not have side-ways jumps. What if it was called RCbsgs, but it was checking keys one by one? By your logic, that would have made it an BSGS program, not a brute-force, because it was in the name, and brute-force is technically a BSGS with a baby step of size 1. Correct?

That SHA converts to address 1KJGAauQRAkRtuuLxLQTvjz3vHvTiKqaom but honestly I stopped caring anyway, as it seems you're not expecting people to actually sweep anything by themselves.

[Torin Keepler]

You still haven’t answered my question. Why does the program use the word “Kangaroo” in its name, and who developed the Kangaroo algorithm? Since the program is based on the Kangaroo algorithm originally proposed by John M. Pollard, stating that RCKangaroo is a modified implementation built on the basis of Pollard’s method is entirely correct.

SHA256(pubKey) = fb6bb8132a0ca0c7c93fe4c29a6d4af241edf50622710673825edcefea351a7a

Great, so now we went from Rho (which isn't even an interval DLP algo) to Kangaroo to Pollard to why some guy chose to name his proof of concept in some way, even though it technically does something using totally different principles. Cool. I don't have an answer. But I do know one thing for sure: the Kangaroo algorithm does not have side-ways jumps. What if it was called RCbsgs, but it was checking keys one by one? By your logic, that would have made it an BSGS program, not a brute-force, because it was in the name, and brute-force is technically a BSGS with a baby step of size 1. Correct?

That SHA converts to address 1KJGAauQRAkRtuuLxLQTvjz3vHvTiKqaom but honestly I stopped caring anyway, as it seems you're not expecting people to actually sweep anything by themselves.

I answered all of your points, but you still haven’t replied to any of my questions.
I have a request so that you don’t come across as presumptuous in my eyes. Please send me a link to the code where the algorithm you mentioned - based on Gaudry–Schost — is explicitly implemented.

There is no need to prove that I control this address right now, because when the challenge starts, I will reveal the public key anyway.

[kTimesG]

Please send me a link to the code where the algorithm you mentioned - based on Gaudry–Schost — is explicitly implemented.

The code is right there, in RCKang, what code do you want?

I think that you don't understand the differences between Kangaroo and Gaudry-Schost.

For your reference, it is John M. Pollard himself that explicitly states the differences in his 2011 paper "Computing discrete logarithms in an interval faster".

Kangaroos do NOT jump side-ways. GS does so happily.

Kangaroos use a well established jump table, not random distances with a whatever jump table size.
GS use an arbitrary jump table with arbitrary jump distances.

Kangaroos use well-established starting points (for example, a van Oorschot strategy if you have more than 2 walks), The probability is analyzed according to these starting distances.
GS uses random starting points and uses the birthday paradox as its basis.

Gaudry-Schost is NOT the same thing as Kangaroo. Only the matching strategy is the same, but then again, this matching strategy is the same one as, for example, BSGS (distance arithmetic, duh).

RCKang + SOTA are 100% a Gaudry-Schost implementation (by looking at the code), not a Kangaroo implementation.

But, then again, you are confusing these with Rho, which has nothing to do whatsoever with either Kangaroo nor Gaudry-Schost.

Do your reading.

[bibilgin]

You’ve probably overdosed on ChatGPT. Again, you’ve mixed everything together with no specifics, just the same blah-blah-blah. I explicitly asked you to include in your reply a fragment of the program’s code where, in your opinion, the Gaudry–Schost algorithm is actually used. And for now you’re just flapping around like a horseradish root in a box, and nothing more.

Should I be happy that you met k-AI-G? Should I be sad? I don't know, man.

[kTimesG]

You’ve probably overdosed on ChatGPT. Again, you’ve mixed everything together with no specifics, just the same blah-blah-blah. I explicitly asked you to include in your reply a fragment of the program’s code where, in your opinion, the Gaudry–Schost algorithm is actually used. And for now you’re just flapping around like a horseradish root in a box, and nothing more.

Are you blind, or stupid?

Jump table: 1024 points or whatever = CHECKED. Kangaroo for #135 would need only 85 points.
Arbitrary jump distances? CHECKED. Kangaroo uses exact distances of powers of two.
Side-ways jumps? CHECKED. Kangaroos only jump in one direction, to avoid cycles.
Random start distances? CHECKED. Kangaroo uses mid-point starts to minimize expected tame-wild distances.

Now, did you actually bother to search and read Pollard's PDF I mentioned? It EXPLICTLY explains the difference between what a Kangaroo algorithm is, and what the Gaudry-Schost philosophy is.

Even RetiredCoder explicitly mentioned that his algo is a tweak on the Galbraith paper about EC DLP using a negation map (which in itself is an implementation of Gaudry-Schost).

Good luck with your "challenge" or whatever. You're covered by so many red flags at this point that I doubt anyone can take you for real anyway (what's the deal with not even providing the correct SHA256 of that address, since it doesn't expose the pubKey anyway? What are you actually hiding?).

[Torin Keepler]

You’ve probably overdosed on ChatGPT. Again, you’ve mixed everything together with no specifics, just the same blah-blah-blah. I explicitly asked you to include in your reply a fragment of the program’s code where, in your opinion, the Gaudry–Schost algorithm is actually used. And for now you’re just flapping around like a horseradish root in a box, and nothing more.

Should I be happy that you met k-AI-G? Should I be sad? I don't know, man.

kTimesG throws around mathematical terms and algorithmic jargon without really examining them in sufficient depth. Yet he still claims that the Pollard-Kangaroo algorithm is not used in the RCKangaroo program, even though its very name is an explicit reference to that algorithm.

Yes, the RCKangaroo program includes numerous innovations and improvements, such as the SOTA kangaroo being closer to the Galbraith–Pollard–Rupray approach rather than the original Gaudry–Schost, and it is indeed more efficient than the classical algorithm. However, it is still fundamentally based on the classical Pollard Kangaroo method.

[kTimesG]

kTimesG throws around mathematical terms and algorithmic jargon without any real depth or understanding, trying to present himself as some kind of mathematics expert. Yet he claims that the Pollard-Kangaroo algorithm is not used in the RCKangaroo program, even though its very name is an explicit reference to that algorithm.

Yes, the RCKangaroo program includes many innovations and improvements, and it is indeed more efficient than the classic algorithm. But its foundation still lies in the Pollard–Kangaroo method.

Here you go, bib:

https://eprint.iacr.org/2010/617.pdf

Section 4, from the Pollard man himself.

Gaudry and Schost [6] developed a different approach to algorithms for solving the DLP. Their method
involves pseudorandom walks of different types (typically, “tame” walks and “wild” walks) in subsets of the
group. One applies a version of the birthday paradox in the regions of overlap of the subsets. A collision
between walks of two different types leads to a solution to the DLP. Galbraith and Ruprai [3, 4] have shown
that the Gaudry-Schost method can have some advantages over the Pollard kangaroo method. In particular,
it can be used to efficiently solve the DLP in an interval when using equivalence classes under inversion

Also: https://scispace.com/pdf/using-equivalence-classes-to-accelerate-solving-the-discrete-uzjbi3yc92.pdf

It seems to be impossible to combine the standard kangaroo method with
equivalence classes in general (Section 19.6.3 of [5] claims it can be done but
gives no details, and this seems to be an error). Hence, it is necessary to consider
other algorithms.

The main difference between the Gaudry-Schost algorithm and the kangaroo
algorithm is that when a distinguished point is hit, Gaudry and Schost restart
the walk from a random starting point in a certain range, whereas the kangaroos
keep on running. The theoretical analysis is different too: Gaudry and Schost
use a variant of the birthday paradox whereas Pollard and van Oorschot and
Wiener use a different probabilistic argument (see Appendix A).

A step to the right for one representative of the equivalence class corresponds to a step to the left for the other.
Hence, when using equivalence classes there is no way to avoid having side-toside walks. This is essentially the reason why the standard kangaroo method cannot be used with equivalence classes.