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

Just to add... Rust is about 10-15 times faster than python, depending on which Crates are used on which hardware and how it is compiled. So for those who don't have a GPU, they also have a solution together with standard C++ scripts.

120, 125 and 130.
captured by hacker ? because this address is 1DiegoU6ETJXK9hNWVTeuK4Y8fkksPnEnK seem fishy with 3Emiwzxme7Mrj4d89uqohXNncnRM15YESs
and he's announce this "https://www.blockchain.com/explorer/transactions/btc/69888f5e55d414b8de65f3a9307a1f414d7035cf9142239045300ce018984bd4"

the next target to take and spend.

    {
      "address": "1BY8GQbnueYofwSuFAT3USAhGjPrkxDdW9",
      "pkscript": "76a914739437bb3dd6d1983e66629c5f08c70e5276937188ac",
      "value": 1231,
      "spent": false,
      "spender": null
    },

it's 67, anyone who can find even 67, the transactions will be attacked by this person.

ngl, this guy very smart and genius build the transaction and from the number of transactions increasing slowly and rhythmically.

for real, i forgot who's make that wheel of fortune HAHAHAH.

Maybe bitcoin key generation cypher technique  use to genrate these address still searching the method to solve this problem.

No, I don't have enough XP to meddle with the Wheel of Fortune. This thing is just too powerful.

Just by making this simple edit it took me so much mana and HP that will take me weeks to recover.

Can you round your circle more ? to 160 ))) This is you try to sell python scrypt for brute 130 puzzle some posts ago ?)))

Holy snappers, guys! How could we forget about this?

We did not write #66 off our bingo cards. Here, let me sort this out real quick:



Now we can officially transition to #67.

% is basicly following from web privatekeys, and for the rest is just for description what the lines do on that box graph.
okay bro, thankyou for sharing your thoughts.

Let me fix that graph for you



Before judging, note that all your % and etc. are inside the red line and even if it weren't it would need a very high amount of zoom-in in to actually be noticeable.

That's right. But once you buy it you gain access to any version, I think.

I'm not going to tell you guys that you could get it from some torrent cause it might be against forum rules/country laws.

And since I'm not telling anyone that, I don't even need to say to be careful with potentially backdoored software provenient from torrents.

 

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.