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

No one can help you transfer the BTC. You are an idiot for telling everyone that you have found the privkey. Now everybody will be watching for you to make the transfer so they can rob you.

Prove that you have the 66 private key by sharing the SHA-256 of the public key. This way we can verify if the address is correct

No one will be able to derive the public key, but we can verify that you have it

Wait a moment! the total amount is not correct. This is probably fake.... 

Aaaaaand 66 points go to Poland!

If this is really true and not a nice fake image generation then....Congrats!!

Waiting for someone to help me move the balance without losing it.

Cool, can you explain this? https://imgur.com/a/oZGoCHU
The pubkey seems belong to puzzle 64 lol

Those fuckers believe that they can scam us

You have to change to qr code as well it's still showing puzzle 64's address.

Guys learn to quote properly without unnecesary sub-quotes


I can try it, i only wan the 10% y send you the 90% share

I am reporting to be the first one to use your service.

Only I can help to withdrawal, you need share PK with me, I will withdraw and send you 50% share,

No, none of them help

How about
4. Sprinkle some fairy dust over unicorn poop?
Just kidding...

Simple answer, no, that won't solve the problem of having to reveal the public key of the puzzle's P2PKH-UTXOs while spending them. You have to move aka spend the UTXOs first and if you send the spending transaction publicly, not undercover as presumably e.g. slipstream.mara.com appears to offer, any bots lurking and observing public mempools will see the public key and can and likely will try to find the private key in the time until the next block is found.

If you're unlucky the next block can take minutes while your spending transaction sits in public mempools, dozens of minutes if you're really unlucky. Plenty of time to find the private key and replace your transaction with another one with higher fee. In the end the stealing bots will turn all 66-puzzle's coins into transaction fees and some mining pool will benefit from it.

Hey guys, can

1. Pay-to-Taproot (P2TR)
2. CoinJoin
3. Blind Signatures

help with p66 withdrawal?

About 11,000 satoshis per hour.

It's not worth it. You can buy 200 Antminers T21 for the same amount of GPUs.

How much can be mined with 500 RTX 4090 GPUs if you have your own power station?

I don't think so much about this topic anymore. I don't have enough number of GPU cards. Some 500-600 pieces are beyond my reach.

The goal was to find the best parameters to reduce the complexity, as in, the minimum average number of group operations, which does not depend on the problem size. In no way should anyone attempt to use the script as a production executable, even if built in Cython. It is still a naive approach, done in RAM.

So what do you think about the 3-walks kangaroos, what should the correct parameters be to reach 1.7 or 1.8 sqrt(b) ops? The script is broken for that strategy, after some fiddling with the intervals and the way tames and wilds are sampled sometimes it goes at about 1.9 sqrt(b) but it should in theory be a lot lower than that.

I think the wilds and anti-wilds colliding between them is the trick, but they don't do that as often as a tame/wild collision... so it must depend on where they start from.

For DP = 0 the script can solve on average in 1.36 or 1.46 sqrt(N) using the appropriate strategies, but obviously that only makes sense up to a point. We need something that is sub-2 sqrt(b) and also works with DP > 0. And not using 3 kangaroos, but many tens of thousands.

This can be converted to a .so file using Cython. I achieved an acceleration of over 150K hops per second, so it should reach around 550K hops per second.

Here’s an example of what your setup.py might look like:

copy/paste code to puzzle.pyx

setup.py

Build the .so File


This command compiles the .pyx file into a .so file. The --inplace flag tells the compiler to place the resulting .so file in the same directory as your source file.


puzzle.py



Private Key: 0xade6d7ce3b9b
Ops: 11631360 Stored: 11631276
Speed: 449407 ops/s

Optimization flags like -O3, -march=native, -flto will generally improve performance.But it can be worse or it can be buggy.

However, the problem is that the kangaroo algorithm needs to attack Puzzle 130 right away, which is beyond Python's capabilities.

These are such large numbers that you can only get depression from them.

New version of Python Kangaroo!

Using gmpy2 to accelerate a little bit the field math yields around 400k ops/s so please do not use this to search for high-bit puzzles.

I added some different strategies for sampling tames and wilds from the search interval which affects the theoretical complexity. My goal was to validate the following strategies:
- interval [0, b) using van Oorschot parameters for parallel collision should average 2* sqrt(b) ops
- interval [-b/2, b/2] using equivalence classes and birthday paradox should average 1.36 * sqrt(b) ops
- the 3-kangaroo method using negation symmetry should have resulted in 1.72 ... 1.81 * sqrt(b) ops

So what's the catch? After doing around 1000 test runs using random private keys with misc. strategies the average solving complexity (the sqrt(b) factor excluding the DP overhead) doesn't really match expectations:

- when DP = 0 (all points are DP) and we use the negation symmetry we can converge to almost 1.36 * sqrt(b) ops on average, which I think it is close to the minimal possible complexity conjectured by Pollard, e.g. 1.25 sqrt(b)
- when DP > 0, if we only jump forward, symmetry fails for walks, and complexity seems to go back to 2.0 sqrt(b) or worse.

How to fix? Jump side-by-side in deterministic way, so use Y sign to determine if jump goes forward or backward. Now we can end up with cycles in the jump travel. Most of them are 2-cycles (next jump goes to the same element as previous jump) which can easily be detected, and if so, jump again with the previous distance instead of jumping back to the previous point...

THREE kangaroos!

The papers analyse how we can use a third walk and solve the key whenever ANY two of the three walks collide, when only traveling forward. The trick is that we also start with a wild kangaroo that starts from -P plus some offset. Then we have three types of collision:

T / W1: solve for k = tameDist - wildDist
T / W2: solve for k = tameDist + wildDist (e.g. P traveled "backward" since -P walked forward)
W1/W2: if offsets don't sum up to 0, then k = (w1 - w2) * 2**-1

Because we hash DP by X we can easily solve the 4 different cases of each type of collision and check if it's the solution.

Tames should start at around -b/2 + b*8/10 == b*3/10  -this makes average distance to P or -P less than 0.2*b and means we would have to travel shorter walks on average.

Pollard's paper for 3 and 4 kangaroos suggest that the complexity should be 1.81 sqrt(b) or even 1.71 sqrt(b) for 4 kangaroos. I wasn't able to reach this complexity by using the suggested mean jump size (0.375*sqrt(b)). This strategy should in theory keep the same complexity when using DP > 0 and be parallelizable with same van Oorschot methodology. Both of these statements are in the paper, but I didn't manage to have success with them. So if anyone knows more about this 3 or 4 kangaroos, please explain:

- what is the maximum expected/allowed walk distance for a tame and for a wild_1 and wild_2?
- does the parallelization using van Oorschot (e.g. start = idx * v + z) apply or not? has anyone ever actually studied this?

Again - do not search for puzzles using this script. It is 100% just of theoretical interest.

CODE: https://pastebin.com/8Z69sRcU

Couldn't embed in post as it was too long...