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

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

sad we cannot see the diff to JLP's original kangaroo tool. Anyone dived into mikorists' code and can share some thoughts about the changes and implementation routines ?

How to speedup sha or ripemd ?


https://github.com/mikorist/Kangaroo-256-bit

non-functional abandoned tool. Any other Kangaroo version known that is known to be usable for >128bit ranges ?

I have almost the same speed in Rust or using vanity search SECP256K1 in random mode. Even with the fastest random SmallRng, BTC hashing is a bottleneck.

https://github.com/ZenulAbidin/Kangaroo-256

That would be cool... at least some fun here cause it's obvious we're not gonna find anything.

As for using Kangaroo method for 130bit ... as far as i know none of the publicly available software was able to do it cause they were limited to 125 or 128 bit (i don't remember).

BTW How is vanity search "better" than normal brute force ?  Isn't it like you still just randomly generate private keys and check if they match given address ?  If so ... then all you do is saving addresses that starts with the same characters but it doesn't increase your chances. Correct me please if i'm wrong.