I think we are slowly sinking into conspiracy theories.  

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

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.

How to speedup sha or ripemd ?


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

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

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)"

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.

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.

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

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.