Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it - page 39. (Read 245388 times)

good luck with TX

Important info stored in here, related to the wallet challenges / puzzles :50BA1F083DE4F022B32996C8070B71F7D27A73E439AE20E5B87B85F3064835EDDB98AFF04FA09B4 D66EA70436C44D927B48408D85D4AB69E57CD466CF922E9A7

More to come...

Your "point" makes sense only in the context of the code you provided.

The code you provided has no resemblance, structure, or respect to the Kangaroo algorithm.

It also has no correlation to the birthday paradox. You are the only one who actually knows what exactly your point was about in there. And even if you actually explained what that code is trying to do (which you hadn't), then the second code is still observably faster (and hence more efficient) when it finds the same amount of matches as the first one does. But again, I cannot understand what your code was attempting to prove. However you stated that they both solve the same problem (whatever that is), so the comparison is fair, if the comparing factor was "how many matches does it find". Again, in lack of a concrete statement of what problem it's trying to solve. Maybe if you come up with something that actually has to do with the Kangaroo algorithm (or of course, with the birthday paradox, though that would be something that has nothing to do with Kangaroo) maybe someone will bother to check it. I can promise it won't be me. And one last thing I have to address to you, since it's my last one: I am not and was not ever either digaran or any other user on this forum. Good luck mate.

Rather, people that don't understand the meaning of what they are expressing.

Some examples (yeah, I'm bored)

Statement: "BSGS must improve its DB"
Fact 1: You cannot improve something below the known optimal complexity, unless you discover something of a lower complexity. However in information theory there are informational bounds that cannot be overcome, so how exactly would one improve on something that is proven to be already optimal?

Fact 2: BSGS does not use a database, it uses what is referred to as "fast memory", which is ideally a data structure that has the lowest possible access time, with seek and search complexity of O(1) (a single fundamental operation at the information implementation layer).

So any attempt to optimize something that is already as fast as possible, and beyond what the information-based paradigm allows, seems unlikely.

Fact 3: There are limiting factors in the actual physical representation resources, we are talking here about the real implementation of facts 1 & 2 above, of which the most known one is RAM (random address memory). RAM allows the usage of the information theory principle of "fast memory".

So, any attempt to optimize on Fact 3 is limited by the technological constraints available. If we analyze the requirements of solving a specific problem, we are going to be quickly slapped in the face by the realization that one cannot simply add up many magnitudes of RAM to some computer system (or even a super-computer system) due to a lack of tehcnological availabality.

Statement: "Kangaroo must improve its computing power to be more efficient."

Fact 1: Kangaroo is an algorithm, it does not have "computing power", which is something in the realm of practical concrete implementation.

Fact 2: Efficiency is also something that correlates to a practical implementation.

Fact 3: We can always add up more computing power. In contrast to "we cannot always add up more and more RAM for our fast-memory-based algorithm".

So, these facts make this statement pretty blake. Why? Because, we can always add up the computing power, it is not a "must improve", it is rather "this is something that already can be done and profit from in our implementation". In contrast, can we arbitrarily add up more computing power to BSGS? No, because the fast-memory real-life implementation (RAM) is only fast because it's physically connected to a singular computing system, not many. Can we arbitrarily add up more fast-memory to BSGS? No, because we have techology limitations. Can we fit more data in the same fast-memory RAM in BSGS? Well, sure we can, buddy, but the information theory bounds will again hit you very hard in the face, because now you need some form of processing.

These problems are not something that you can simply cheat on and call it revolutionary or miraculous. These are well-defined problems rooted in the information field itself, before any kind of other talk on opinions.


If I were you, I would delete that code you posted, and which I proved you it is running 10x more slower than what you were bragging about as being 10x more efficient. If 10x slower means "10x more efficient" for you, than yeah, my bad.

Flat-earthers, who can beat their madness.

This is my king. Digaran. 

Dude, you come here, post some junk code, junk ideas, and junk principles of thought, and you expect us to take precious time from our life to prove you are just raving complete non-sense. After you have all the answers on the table (there were no questions in my last post, only direct answers for you) you still insist on the same non-sense, and do not even address, or forget completely the whatever problems and questions that you got the answers to! I am personally done with dealing with you, it is of no use for either of us, or the rest or this forum.

How many GPU needs to find a key in range 119 with kangaroo and how much time it takes? Is there any calculator.

Yes, let's talk about math and resources!

Can you replace this line:


with


and then maybe you understand why the first program is 10x less efficient than the second.

Also, it is hard to figure out what problem the scripts are trying to solve, but it definitely is not a benchmark to prove the birthday paradox, since you shrink down the remaining options after every loop.

Also, kangaroos don't stop after going past the end of the interval. They continue their walk indefinitely. It is not the same thing as the birthday paradox.

BS. Pollard Rho is preferred for general-purpose large-scale GPU ECDLP solvers, especially for SECP256K1.

The Pollard Kangaroo algorithm, also known as Pollard's Lambda method, does not rely on the birthday paradox. The birthday paradox is relevant to the Rho method because it depends on finding a collision (i.e., two identical function evaluations).

Gaudry and Schost's algorithm is a hybrid approach for solving the discrete logarithm problem. It combines elements of both the Pollard Rho method—utilizing random walks and the birthday paradox—and the Pohlig-Hellman algorithm, which leverages the factorization of the group order.

I prefer the Pollard Lambda method due to its methodical nature, low memory requirements, and efficiency in cases where the range of possible solutions is known and bounded.

TTD #1 for 64, TTD #1 for 66, yet 'someone else' has found the key both times. Have you ever wondered why?
Fastest client? How?
Secure Server? Has it been audited?
Startup scripts. Nice!

What do you understand by "efficiency"? It's not the same thing as "speed" or "complexity", rather a more overall indicator that accounts for a multitude of factors, of which one is the practical techniques that are being used; another one is what problem you are trying to solve.

Why is it wrong to increase the jump (I guess you meant average jump size)? You're pretty much dismissing all existing research with this statement, and the math looks pretty legit IMHO (with well defined proofs for why it's optimal to use a specific average jump size to minimize the expected number of operations, etc.). By your (assumed) logic, and continuing it in reverse, we should basically run a brute-force search, one point after the other, right? So as not to mess with the damn birthday paradox, losing efficiency... am I wrong? But the joke's on you: messing around with the way you intend to use some theory, only ends up to decrease the efficiency. If you want better "birthday paradox" results, then you lose efficiency, because you do more operations. It does not matter the way you split the interval, or whether you make the jump sizes smaller or larger, or if you increase the DP to abnormal magnitude, or if you decide to go with storing trillions of points in the cloud, or if you decide to randomize starting points instead of having a central database of working state, the end result is the same: sub-optimal. And this is an objective measurable metric, not some personal opinion.

Maybe, enlighten us about your exact science. Let's talk theory, not "you'll never find 135 using this or that", this is not the main point here anymore. Let's have some fun on the realm of exact science!

You have lost your mind coming on this forum and spreading lies lol. Just stop.

Yeah, TTD is the fastest in skipping keys, generating wrong private keys, and losing your money. Yes, I agree, it is the fastest in those things. So please don't come on here trying to advertise for them and spread half truths.

I know, the owner does not take testing seriously at all, I've got receipts, so don't come at me with some BS.


This actually makes no sense. The modified kangaroo programs out there that increased the search range to 254/256 bits, did not do anything to increase speed / efficiency. Unless you have ran both and extracted the data in the workfiles, do not comment on it and spread false info.
I have not seen one modified JLP program, for increased bit range search size, that had speed increases. All they did was make the workfiles, double the size. Instead of only increasing the distance entries, they increased the points and distance entries; so now the workfiles are double the size.
You can run all of your tests you want to, but math is math, it doesn't lie. If I have a kangaroo program that is 3 times faster than yours, I will find the number of average DPs needed to solve, 3 times faster than yours. Efficiency does not equate to being able to search higher bit ranges, you dig?

Well, papers are about theory mostly.
Again, in practical implementation you have to use random start points because you don't know exact number of GPUs you will use during solving (because it's a long process and some GPUs can be turned on and off, or added/removed), also sometimes some GPUs will start new kangs.

ttdpool and ttdclient already have this. Fastest client, secure server and startup scripts.

Are you not tired of this yet? Let me help you. I am @RetiredCoder, you catched me again. I am also the guy with the magic circle that everyone (except you) seems to know about. Oh and I'm also @mcdouglasx, just to annoy everyone who reads this. I'm also your mom, please come downstairs, your school lunchbox is ready.


There isn't a single paper that says to use random starting points when we have multiple kangaroos per herd; on the contrary, they start from well-defined positions. To use random start points is an arbitrary decision: first of all, on average, it degrades the expected runtime; second, it's used for spin-off strategies, like in Bernstein's pre-computation paper "Computing discrete logs faster".

It's debatable if walking forward and hitting a collision is the same as the birthday paradox, which requires all the balls are in the same urn. The common factor is conceptual only: probability of success.


That statement, just like JLP's entire kangaroo implementation in general, is not reviewed or confirmed by any real expert, and it might be a very contextual statement relative to his implementation and personal opinions at that time, influenced by whatever he was reading or thinking. Also, I don't understand, now you defend Kangaroo or what are you doing?

Correct.
But in practice, nobody implements original kangaroo with only few kangs. Practical implementation always contains a lot of kangs with random start points and they don't go far, so it's exact or similar to Gaudry-Schost and it does use birthday paradox.

Very easy... Confirming a tx on btc blockchain takes some time to process (sometimes quite long time).
Sending btc from address exposes  their public key. Normally it's not a problem - but with artifically reduced private keys to lower bit range (like 67 bit) it's a matter of seconds to crack the private key from the exposed public key (with kangaroo or BSGS method)

Cracking the private key gives the attacker the opportunity to use RBF (replace by fee) to redirect the transaction to another address.

Nobody know how many bots constantly monitoring mempool and waiting to one of those public keys show up - then they will start to crack the private keys and use RBF to steal btc (some of them probably can constantly monitoring even the replaced transaction to replace it again with higher fee in case other bot is trying to steal it to --- that all leads to some sort of bot wars).

So if you somehow manage to crack the puzzle with low bit range think twice before moving it cause for sure someone will try to steal it from you. If you simply transfer it  they will be stolen for 100% and all your effort will bring you nothing but frustration...  Puzzle 66 was already stole (at least it looks so).

 

1.72 * sqrt(2**134) = 2^67.78

I did not include the DP overhead, because it depends on a lot of factors.

For all the haters and frustrated multiple-account-owners pretending I'm Digaran and that I have multiple accounts and so on (even though any mod can confirm the contrary): get a life.

Also, as I stated a lot of times, there are so many ways to improve on efficiency than what is already out there publicly, that only a limited mind can think there's nothing to drastically improve on.

Here's a basic kicker: JLP doesn't use the 3-kangaroo method. So there's 15% increase in efficiency basically for free just by implementing this detail alone. But guys still attack that check.cpp shows some fake speed., and hence the entire algo is broken. Nevermind the absurdidities around "birthday paradox". I'll grab my popcorn and be silent whenever I read again such a wonderful exposition like the earlier one.

Here's another kicker: Kangaroo doesn't rely on the birthday paradox. That would be Gaudry-Schost. Seriously, it is stated in the paper itself that this is the difference between Kangaroo and that one, they have totally different analysis methods. But what can I ask from someone who doesn't understand the principles, and copy pastes whatever bogus shit ChatGPT spills out? Do they think I can't tell the style of GPT output, while they accuse me of using it? Ugly as hell.

In other news, congrats if you really do have 8+ Gk/s on a single 4090. You must have really found some method to speed up the CUDA code, I have some hunches you used Montgomery or something to achieve this. I feel that there still a lot of juice left to squeeze out of those teraflops, but it's not exactly like spinning a magic circle, when we also have a job or life to attend to.