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

Also to note you need the specific Purebasic v.5.31 other versions to my knowledge do not work

This has been answered 10 thousand times in this same thread some pages back.

The only public available Kangaroo that works beyond 125 bits is Etar's.

It's based on JLP's but it can go up to 192 bits.

It has an edge on the speed too, yielding +-1Gk/s more than JLP's (at least on my setup).

https://github.com/Etayson/Etarkangaroo

Note that its Windows only and if you want to compile it yourself you need PureBasic, which is paid.

python scans 50,000 addresses per second
The GPU scans +- 5,000,000,000 addresses per second
GPU scans +- 100,000 times faster than python
so you can forget about python, you have to make codes for gpu
you don't have eternity to solve it with python

I am using Rotor-Cuda with relatively small blocks driven by my python script.

bro can i talk about 1000 Btc puzzle i am using python but can't use my gpu i have rtx 4070 plz help

A LOT BETTER, if this was your question. And every time I benchmark to test for a new solution, I tame the found wild DPs, so results improve themselves. I also trim periodically DPs that are outside of some range, since almost 99% of the solutions are found via a DP which is an specific median range. I almost never find a key by hitting a DP which is below 50% of the interval, for example, even though there were a lot of them in that region. Don't ask for why that happens, I can only speculate it has to do with average travel size, who knows.

Currently I have a 80-bits solver DP database that can solve any key in under 6 seconds on a GPU, and under a minute if using the CPU.

You try use saved files from kangaro of JLP ?

Lol, I stopped reading when I realized you didn't understand what I said and what I asked.

I will try to clarify:

You run a 65 bit range searching for pubkey Z, solve in expected time, and accumulate x amount of DPs to solve (whatever number you want to use, it is irrelevant)
Now, you tamed the wilds from the previous 65 bit run.
Lastly, you run a 65 bit range searching for pubkey W, on average, how much quicker will you solve pubkey W versus pubkey Z?

Better?

I have ran 1000s of these tests. I was counting on the fact that you had too, since you talk about "pre compiling" a work file to use with a bot for the 66 key.

It's not as easy at it sounds. If the jump rules stay the same (so the DPs can actually work between different intervals) then the DPs are valid and usable, but unfortunately the interval doubles in size for every bit increase. So where are the DPs that should cover the newly added other half? Nowhere.

To get the optimal runtime, the Tames start somewhere around the middle of the interval + some common offset (so they are all, on average, to a minimum closest distance to the Wild/private key).

But what we have, are DPs of kangaroos started from the middle point of the first half of the new interval (around half of them passing into the second half of the new interval). And also the DPs converted from Wild distances after a solve (all these DPs will start from where the private key was in the old interval, so we don't know what they cover).

So now we should run new Tames to cover the second added half (traveling a double distance than what Tames did over the previous interval). And we also need Wilds that need to cover the entire new interval (since they can be in the first or the second half of the new interval).

Since jumps are the same, the jumps need to be more of them! Usually, if the interval increases, we do longer jumps, but this breaks DP re-usage.

In short, existing DPs would help, but only if the private key is in the first half, not the second. And only if the jump rules are kept and don't affect too much the expected runtime.

Repeat for every new bit added... for 5 added bits the interval is 32 times larger, So I guess my math is wrong, it will take sqrt(32) more operations to solve, but the DP coverage of re-using the previous DPs is very low, not 17%, if I'm not mistaken... I think my fallacy was that I was assuming that if you solved an interval, and you increase by 5 bits, than 17% of the work needed was already performed, but my fault was that 97% of the DPs required for this to be valid are missing, since all of the known ones are sitting in a very tight corner.

It depends on how you plan to reuse them.

You are looking at it from one perspective, to run the original pub, in its original range, with the DPs generated from a lower range.

There are 9 million ways to skin a cat.

I am sure you have done this kind of test and analysis, so answer me this, if you reuse DPs found during a 66 or 65 or 70 bit range, to find a key in the same exact range, how much search time did it take, was it less, if so, how much less, on average?

this is zelar and jlp, they use kangaroo, they try unsuccessful first time sollvec125 but. And cangaroo accept use previous calculated cangaroos for nex ranges,- files from 125 to solve 2^130 etc. Biut they get 13 btc furst time, previously they get 1,2 1,25 btc.difference is big, so they get now more gpu and solve. bye bye puzzles

You mean 0.035 BTC per month? You need 30 years to spend Puzzle 130 like that. 

For every 5 bits range increase about 17% of previous range covers it, but to reuse DPs means using same jumps, so more jumps on average per kangaroo = more total operations than optimal.

If you start searching in 135 bits, then it will take the same amount of time to find private key 0x1 or private key 2**134 - 1 or private key 2**89. So if we adapt the jumps needed to go through 135 bits and solve a lower interval than that (as if we would try to jump through 135), that means longer jumps on average per kangaroo = more total operations needed than optimal.

I think it's pretty obvious what the 120 / 125 / 130 solver has done. You won't find the software publicly, you should all forget about that ever happening. Learn to code, this is what this competition is about first and foremost, not the prize.

Why directly in EUR? Is there a swap from BTC to XMR?
And then you slowly spend XMR through the volet card....
I would milk the BTC amount for years.

because from the moment they convert the BTC into EUR, their identity is revealed and they are no longer anonymous. If things go wrong, the “lucky winner” then has a problem on their hands when they are forced to account for their actions or make a statement. Thanks to KYC

EDIT: As I just realized, you post was deleted. Thanks to the quote I made everyone knows what I replied to.

guess why - backdoored? hope you didn't run it on your own computer where you also run btc wallet applications, right?

relax, just kidding ...   RTFM and look into detect cuda script, if required manually assign your correct sms and also the gpu size

and don't be disappointed if the program doesn't work as you had hoped. You can also try -t 0, which should disable CPU and use only the GPU. However, you will notice that the GPU is not working at all, use a program of your choice to determine whether the GPU is utilized. For example, if you have an nvidia GPU, simply start the nVidia X Server (Linux) or nVidia control panel (Windows) and be amazed that the program will show 0% GPU load. Puzzled? If you use -t 0, you think that the CPU is switched off, at least that's what this ominous kangaroo-256 is telling you. But there will only be one CPU core running and no GPU at all besides of the weird and wrong performance meters that is related to the gpu core settings you choose. So this program is crap

SolveKeyCPU Thread 254: 1024 kangaroos
SolveKeyCPU Thread 251: 1024 kangaroos
GPU: GPU #0 NVIDIA GeForce RTX 3060 (28x128 cores) Grid(56x256) (147.0 MB used)
SolveKeyGPU Thread GPU#0: creating kangaroos...
 

someone please help me, why it took so long ?, i'm stuck on this like 5 minutes.

---

then "Segmentation fault (core dumped)"

120 solved by jeanlyckpons, developer if kangaroo in thread Technical develepment

---

He is a partner with 200 TESLA GPU what solve 2^120 provkey

For the one which does not have public key and small I am using this just for fun. If it does not have public key, and you brute force between 2^66 and 2^67, and if you check 1B records per second, your chance will be 1B * 60 * 60 * 24 / 2^66 per day. Currently 10 vanity instances find 300-400 unique records per day, and as I explained there are approximately 10B addresses starts with "1BY8G" between 2^66 and 2^67. However most probably vanity will stuck when the count reaches big numbers because it will hit same addresses most probably and the find rate will decrease. I did not say it is better than brute forcing, I just enjoy this way of doing the search. It will be around 100K vanity records per year, if I am lucky it will hit that address, if not who cares