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

So now that we know that gmaxwell created this puzzle. How should we continue? I think he should stop it.

He can go on with his kangaroos but it won't help him.
Some people here think they are smarter than professors in computer science that never found something better than kangaroo.
You cannot approach this without thousands of modern GPUs. This is no longer a puzzle (never has been). It is an arms race.

By the way: There aŕe 319 pages and there is NOT A SINGLE NEW APPROACH to tackle this "puzzle" beside pools that backstab you.

---

My post, that was not really useful, has been deleted without any good reason so I will post it again without any quotes.
Really no idea why these overzealous moderators (or dissatisfied people like gmaxwell, the creator of this puzzle) would delete these three lines. But here we are.
With quotes there would be more context but well I don't care. I will post this until it won't get deleted anymore.

110 and 115 were solved with his software so it "works". I can imagine 125 and 130 were also solved with JLP base.
He worked for CERN so he should be used to good coding practices.
I myself, as an amateur coder, have a harder time to read JLP code compared to brichards bitcrack code.

Yes. I am sure gmaxwell is the creator of this "puzzle". He will dispute this of course .
I don't think this will get deleted now because it would give more weight to this post.

Hi there Elon. I'm glad you checked the check.cpp file and corrected your own previous error, there is no header file indeed. But I guess you're wrong on the math there, no matter how many check.cpp files you review.

Honestly, I think you are correct, and you uncovered a pretty deep conspiracy. I guess NVidia should come forward at this point and redact their specs on the RTX 4090 teraflops performance, it was always a very well hidden hallucination number off of their marketing team. They simply typed their stock price as the teraflops as it was at launch day, because why not.

Oh and all the 4K video games with ray tracing were always rendered at VGA resolution lol. I guess the joke was always on us. I mean, seriously, did anyone actually opened a card up and counted the number of logic gates in their chips, to see if they're actually capable of what's written on the shiny box? I guess we need some real Digaran to come forward and tell us the truth! Otherwise we'll be stuck in this "speed is totally fake" problem for years to come. Who cares about ground truth tests.

Last time I checked, this digaran character hasn't posted since January this year...? Why are people still riding him nonstop lol

Every time someone smarter than me posts, it must be Digaran using AI! How else could anyone know more than me? Guess I need to start checking under my bed for him too! 😂

the check.h file is part of kangaroo, it is public, it is not fake information, anyone can review it.

What's the check.h file? Is it part of the Kangaroo algorithm?

RTX 4090 specs: FP32 (float) 82.58 TFLOPS

That's 82580 billion raw operations/s on floating-point numbers.

Once you divide by the number of instructions needed to do a single kangaroo jump (e.g. point addition under the EC modular field, P + Q = R), you're left with a few good N billion keys/s (where N is 4 or larger depending on the implementation).

You can do 5600000000 (that's 5.6 billion keys/s) on a RTX 4090, just to add that 4000 is slower than what the hardware can accomplish.

Stop spreading false information.

PM me

I saw the kangaroo code and it uses the length of the jumps as a reference for speed, this is not true, nor exact.
see check.h file.

You are confusing the exakeys/s shown by some BSGS programs with the real speed (4000+ Mkeys/s) actually computed and analyzed by any real Kangaroo program.

That is, there are indeed 4 billion keys (public keys, and hence by induction private keys) computed per second, and each of them is a complete key (256 bits) which is processed, checked, and then jumped further.

No statistical BS there. Just a direct metric.

Current algorithms like Kangaroo don`t give u real keys/s information, hence your surprise, the speed of these algorithms is often related more to statistical performance than direct metrics like keys per second.

Hello Shelby,

I have some ideas and tools that could help us collaborate to solve the puzzle. Puzzle 67 is smaller and easier than 135. I've coded a tool that can split the 67-bit space into 900 parts, allowing you to run 900 processes simultaneously, each working on a different part using keyhunt-cuda.

Let me know if you're interested in working together!

DM me.

Ok than i have miss nothing, i was shocked to read it, also 900 x 4 b seems slow today.

I wish I had, it was Shelby0901 who said he could access 900x RTX4090!

No 4billion per second is slow but that is the best a GPU can do for brute force as far as I know.

Hmm only for my understanding is a search of 4 billion 4.000.000.000 keys/s fast ? Sry if i have miss something.

Do you really have 900 RTX 4090 GPUs?

you realy have 900 pcs of 4090 ?

900x RTX4090 if you had honest access to that:
I could provide this data it would take 32hours to search each iteration using 900 x RTX4090 at 4billion keys per second each
#66:2832ED74F2B5E35EE
66 time: 37182835143040325629 (Hex: 20403f78f3ad457fd) (Max Hex: 209b6db1432852513)
...
80 time: 44727178505396333728 (Hex: 26cb6dbe03ba2aca0) (Max Hex: 27269bf65335379b6)
81 time: 45266060174136048592 (Hex: 2743159e604d5fbd0) (Max Hex: 279e43d6afc86c8e6)
82 time: 45804941842875763457 (Hex: 27babd7ebce094b01) (Max Hex: 2815ebb70c5ba1817)
83 time: 46343823511615478321 (Hex: 2832655f1973c9a31) (Max Hex: 288d939768eed6747)
84 time: 46882705180355193185 (Hex: 28aa0d3f7606fe961) (Max Hex: 29053b77c5820b677)
85 time: 47421586849094908049 (Hex: 2921b51fd29a33891) (Max Hex: 297ce3582215405a7)
86 time: 47960468517834622913 (Hex: 29995d002f2d687c1) (Max Hex: 29f48b387ea8754d7)
87 time: 48499350186574337778 (Hex: 2a1104e08bc09d6f2) (Max Hex: 2a6c3318db3baa408)
88 time: 49038231855314052642 (Hex: 2a88acc0e853d2622) (Max Hex: 2ae3daf937cedf338)
89 time: 49577113524053767506 (Hex: 2b0054a144e707552) (Max Hex: 2b5b82d9946214268)
90 time: 50115995192793482370 (Hex: 2b77fc81a17a3c482) (Max Hex: 2bd32ab9f0f549198)
...
133 time: 73287906948601221531 (Hex: 3f912f312e342119b) (Max Hex: 3fec5d697daf2deb1)

#66 has 68 iterations would of been a 2176 hours without pubkey for all but it would of been found after 544 hours
#67 has 60 iterations 1920 hours
#68 has 62 iterations 1984 hours
#69 has 73 iterations 2336 hours
so Im saying max 6240 hours or 260 days to find #67 ,#68 and #69 if I had 900x RTX4090s

#70:349B84B6431A6C4EF1  has 98 iterations 3136 hours without pubkey but it would of been found at 2048hours
158 time: 970026333328748806619 (Hex: 3495d1d2be22bb81db) (Max Hex: 349b84b6431a6c4ef1)
Currently it would take me 2970days just to search 1 iteration so 900x RTX4090 is insane amount

Hey @kTimesG I would like work with you.. I think if you can help me with the math I'm stuck  in I think we can crack this puzzle 135 message me a mode that I stay in touch with you.. Please

Really? That's a lot of keys. So let me formulate the question another way: once you reduce 135 to 120 bits, is that equivalent or not to having 32768 public keys, of which one of them corresponds to a 120-bit key, while the rest of 32767 correspond to 256-bit keys?

If so, how do you pick the one public key to search for, to have a good reason of calling this as a "reduction" and not an "expansion"?


Using 900 RTX 4090, it will take 583 days to break 135, using my software (~ 5.6 Gk/s on a single 4090). It was worth it for 130, but 135, not so much, costs are higher than the reward. We need either much higher computing power, or some advancements in EC math (some fast parallel XGCD would help, since this is the current bottleneck - all threads except one are idle, waiting for a batched inversion to finish). Doing multiple XGCD in parallel (like what JLP version does) is actually a lot slower than doing one "master" batched inversion. Ehm...