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

Yes, I read about it here on the forum! thanks for the answer! But there was a message on this branch with a division by 2. and there was an answer to it, but I don't remember which one and on which page these messages are also I don't remember. But the question is, if it were possible to divide public keys by 2? would it make it easier to find the private key? what I remember seems to be the answer to that message was "if we could divide the public key by 2, then finding the private key would be easy, and it seems to have given the formula", if I was wrong, please correct me!

Division by 2 just means to multiply by 1/2 mod N.
1/2 just means 2's inverse so that 2*x = 1 mod N.
Inverse of x mod N just means x^N-2 mod N (Fermat Little Theorem).

Let's take F = { y(x) = 2^x mod 11, 0 < x < 11 }

and some known y = 5: 2^x = 5 mod 11

"Divide" public key by 2: 2^x/2 = 5/2 mod 11

2^x-1 = 2^-1 * 5 mod 11
2^-1 = 2^11-2 mod 11 = 6

So: 2^x-1 = 5*6 mod 11 = 8

Great, now you have to find x - 1. Repeat? Sounds like nothing really changed.

Let's take F = { (x, y) = [k]G, 0 < k < N }

and some known (x, y) = Q: [k]G = Q

"Divide" public key by 2: [k/2]G = [1/2]Q

[k/2]G = [2^-1]Q
2^-1 = 2^N-2 mod N

So: [k/2 mod N]G = [2^N-2 mod N]Q

Great, now you have to find k / 2. Repeat? Sounds like nothing really changed.

If you fall into the trap that k is somehow half the size now, remember this:
1. Division of a field element means multiplying the element with the divisor's field inverse.
    k is not an integer in an infinite field, but a finite field. You can't just half it's value, that only makes sense in an
    infinite field, and only if such an inverse really exists.
2. Groups do not have multiplication operation, only addition. There's no such thing as multiplying or division of elliptic points, they form a group, not a field. "Point multiplication by k" just means adding the point to itself k times. "Division by k" means adding the same point to itself k^N-2 mod N times. You need to respect the definitions of what something can be called a "group" or "field", "finite" vs "infinite", not invent or borrow properties from different structures. It can't work.

Created this
https://github.com/Paper-Universe/Puzzle-Work
The code searches smaller ranges, saves the range, and tells you how much of the total range you have searched.
I also have the files of ranges that I've personally searched.
If you want to contribute your welcome too.
code is beginner level so might not be the best but from the tests I've done it functions properly.

Hello everyone, can you tell me if there has been a message here for a long time? where it says "if it would be possible to divide a point on the curve by 2, then find the private key, etc.." I've seen this message here before and it was answered by someone. I can't seem to find this page.

I am getting errors on Mac:


I solved that by adding:


to .toml file.

Also build command I used was:

More like a casino. Not only are the chances of winning not great, but it is also very difficult to collect the winnings))
Unless leaving half the winnings, if not more.

Of course, there is always a chance. In the end, it's more like a lottery than a puzzle.

So you're saying there is a chance! +5 for believing in me. -10 to the guy above for thinking my algorithms are useless. People are right though this puzzle is hypnotizing. I'd take even a .01 chance. My threshold for mockery is pretty high. So lay it on.

All kidding aside though this is not random data.

Your quantum machine? It's like a magic wand made from a unicorn's hair and a wizard's beard. Pretty powerful stuff, right?
But here's the kicker: every time you try to wave your wand at the fortress, a squad of time-traveling space wizards appear out of nowhere, performing counter-spells that neutralize your every move. And these aren't just any wizards – they're the grandmasters of the Quantum Realm, each with centuries of experience in thwarting exactly this kind of attack.

Even if you somehow manage to get past the force field, dodge the laser sharks, outsmart the cybernetic ninjas, and bypass the alien tech, you'd still have to crack the code hidden in a Rubik's Cube made of neutron stars, being juggled by a hyper-intelligent octopus from the 12th dimension.

In other words, the odds of your quantum machine breaking Bitcoin are about as likely as a three-legged unicorn winning the intergalactic hopscotch championship. While riding a unicycle. On a tightrope. Over a volcano. During a meteor shower.

Congrats on training a totally useless learning algorithm to find some matrix that correlates to a few hundred random bits.

You can find a perfect fit to any random pattern, until the point where reality slaps you in the face and the next random sample requires you do a complete retraining.

Cause right before I went to work this morning my quantum machine learning algorithm made a perfect run on the first 65 addresses. Then next step is to test on unseen data, which means converting the rest to quantum states, which is easy but time consuming.

Of course overfitting which is why I went to work this morning and didn't quit my job and stay home to claim prize, but I am like 75-80% confident that I got this thing licked.

How do you know that you are so close? )

I'm going to solve this in the next 48 hours. I'm so close.

    ⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣠⣴⣾⣿⣿⣿⣿⡿⠿⠿⠛⠻⠿⣷⣄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⢀⣴⣿⣿⣿⣿⡿⠟⠋⠁⠀⠀⠀⠀⠀⠀⠀⠙⢷⡄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣠⣾⣿⣿⣿⠟⠉⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣀⣀⣻⡄⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣴⣿⣿⣿⡿⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣴⠟⠉⠉⢳⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⣼⣿⣿⣿⣿⣷⠀⠀⠀⠀⠀⣠⡴⠶⠦⡄⠀⠀⠈⠃⡴⢻⣷⣾⣇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⢸⣿⣿⣿⣿⣿⣿⣆⠀⠀⠀⠞⠁⢀⣴⣶⠦⡄⠐⡆⠸⣟⠚⠋⠁⠈⣆⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⣿⣿⣿⣿⣿⣿⣿⣿⠀⠀⠀⠀⠀⢯⣸⣿⠟⠃⠀⢷⠀⠈⠣⠀⠀⠀⠈⡇⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⣿⣿⣿⣿⣿⣿⣿⣿⡆⠀⠀⠀⠀⠀⠀⠀⠀⠀⣰⠟⠀⠀⠀⢨⡷⣄⠀⢿⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠸⣿⣿⣿⣿⡟⠛⠿⢿⡄⠀⠀⠀⠀⠀⠀⠀⠀⠈⠀⠐⠛⠀⠀⠀⠙⠆⢸⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠹⣿⣿⣿⡹⣄⡶⠀⠀⠀⠀⠀⠀⠀⠀⢀⣦⠀⠀⠀⣀⡤⠴⣶⠀⠀⢸⣦⣤⣄⣀⡀⠀⠀⠀⠀⠀
⠀⠀⠀⠀⠀⠀⠀⢀⣀⣀⣤⣽⣿⣿⣧⡻⣷⣦⣀⡀⠀⠀⠀⠀⠀⠈⠙⠂⢶⣯⣥⣴⣾⠏⠀⠀⣼⣿⣿⣿⣿⣿⣿⣷⣦⣤⣀
⠀⠀⢀⣠⣤⣶⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣦⣤⡰⠃⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠉⠁⠀⠀⠀⢹⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿
⣴⣾⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣷⡄⠀⠘⢦⡀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠴⠆⠀⣸⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿
⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣯⠳⣄⠀⠉⠓⠶⠄⠀⠀⠀⠀⠀⠀⠀⠀⢠⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿⣿
⠙⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠀⠈⠓⠀⠀⠀⠀⠀⠀⠈⠓⠒⠒⠚⠙⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛⠛

Brute force? I heard someone above tried solving it by staring at the Moon intently, hoping it would feel awkward and reveal the pattern. Others have resorted to ancient puzzle rituals, sacrificing their free time and sanity on magic circles..Let's just keep randomly pressing buttons until the puzzle gets tired of us and solves itself.

Has everyone just straight given up on this puzzle? I see lots of talk of brute force but there is clearly a pattern at work here. Have people given up trying to discern it?

CUDA has nothing to do with the programming language in which you're expressing what stuff you want done.

There isn't a "best" programming language for CUDA simply because the only programming language is the binary code that gets built by the nvcc compiler, and actually executed by the device. Those instructions have nothing to do with C, Rust, or whatever "normal" languages which are inclined towards a totally different computing paradigm.

C/C++ is just a first-class option because it is the main one for which NVidia offers a compiler, and as such it can internally optimize the order and efficiency of actual binary instructions executed in the end by the hardware.

Not even PTX is a programming language, it just serves as a hint to the compiler.

So the GPU "code" may do totally different things in a seemingly random order than how your program looks like.
Loads/stores, order of operations, can all be changed depending on the dependency between variables.

So stuff like comparisons between C speed and Rust and whatever are completely non-sense in this context. Forget about the notion of pointers, fancy tricks to optimize memory usage, etc. Those do not exist in how CUDA operates and how the code ends up to be at SASS level.

I was not comparing C to Rust, I was comparing device class types. FWIW you can dump a CUDA kernel in a Python script and it's exactly as performant as if you called it by flipping a switch in the GPU. Host code is irrelevant except for management tasks (moving data in and out from GPU).

Writing a CUDA kernel in Rust has no advantages over writing it in whatever language for which an NVidia compiler exists, except ofcourse if there is official documented support that one language can be optimized much better than the other.

What are the limitations to creating a GPU version of Kangaroo using Rust? With the availability of crates like ocl for OpenCL, which operates on any hardware accelerator compatible with the standard, and Rust-CUDA for NVIDIA GPUs, the possibilities are vast. Rust-CUDA allows you to either compile CUDA C++ kernels and invoke them from Rust or write kernels directly in unsafe Rust using the cust library. However, if you're using CUDA 12, the current Rust-CUDA project encounters issues due to breaking changes in the NVVM IR library used for code generation. In terms of performance on NVIDIA GPUs, Rust-CUDA can rival or even surpass handwritten CUDA C++ kernels (such as SGEMM/DGEMM optimized with shared memory tiling and unrolling). Nonetheless, NVIDIA's cuBLAS kernels are still preferred, especially for FP32 operations.

Comparing C++ and Rust for CUDA development, C++ has been the traditional choice due to its long-standing integration with CUDA and mature ecosystem. C++ provides extensive libraries and tools specifically designed for GPU programming, which can simplify development and optimization processes. On the other hand, Rust offers advantages in terms of memory safety and concurrency, potentially leading to fewer bugs and more secure code. Rust's ownership model ensures that memory management issues, which are common in C++, are minimized. However, the Rust ecosystem for CUDA is still evolving, and developers might encounter compatibility issues, such as those seen with CUDA 12. Despite these challenges, Rust's potential for writing safer and potentially more efficient GPU code makes it an exciting option for future developments in GPU programming.

More than as a nice skill exercise to write a Rust program, there's zero benefit. It's like reducing the time needed to walk to the edge of the galaxy to the time needed to walk to Alpha Centauri. Less, but still totally unfeasible.

The bottleneck is still computing the scalar multiplication and hashing that stuff. RNG speed is a grain in the sand while the rest of the program is the entire beach.


Good luck. Even the fastest C implementation for the actual jumps is hundreds of times slower than CUDA. A lot more watts/jump price. I'm at 5500 M jumps/s on an RTX 6000 Ada, and planning on doubling the throughput soon by switching to floats. While on an i9 13700H I could never reach more than 12 M jumps/s on a single core (and this was using SIMD, carry-free instructions, batch inversion, etc).