Bitcoin Forum
October 11, 2024, 10:22:04 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 [321]
  Print  
Author Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it  (Read 217025 times)
mcdouglasx
Member
**
Offline Offline

Activity: 332
Merit: 89

New ideas will be criticized and then admired.


View Profile WWW
Today at 04:58:58 PM
 #6401

That's what I preach, you can't mess with the birthday paradox without losing efficiency, if your software doesn't do this right for you, at least you're not looking for a fish in the sky. My comments are directed towards @ktimesg's crazy proposals. If you read the context you'll understand.
In fact, it is wrong to increase the jumps, you only lose efficiency, it is an exact science, I demonstrate it in my previous script.

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!

ok, explain to me why here the first script is more efficient than the second, and we will talk about math.
1- same resources.
2- same range
only difference x10 in jumps.


BTC bc1qxs47ttydl8tmdv8vtygp7dy76lvayz3r6rdahu
Akito S. M. Hosana
Jr. Member
*
Offline Offline

Activity: 85
Merit: 2


View Profile
Today at 05:29:50 PM
 #6402

Here's another kicker: Kangaroo doesn't rely on the birthday paradox.

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.
nomachine
Member
**
Online Online

Activity: 462
Merit: 31


View Profile
Today at 05:46:01 PM
 #6403

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.

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

bc1qdwnxr7s08xwelpjy3cc52rrxg63xsmagv50fa8
Pages: « 1 ... 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 [321]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!