Bitcoin puzzle transaction ~32 BTC prize to who solves it

[WanderingPhilospher]

Maybe he/she is just a brilliant mind...and that person knows a way to reuse the DPs from 120,125 to find 130 and the rest.

I would like to know how he/she did it !

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.

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?

[kTimesG]

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?

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.

[WanderingPhilospher]

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?

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.

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.

[COBRAS]

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?

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.

You try use saved files from kangaro of JLP ?

[kTimesG]

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?

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.

[NowshadKhan]

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

[gygy]

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

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

[Feron]

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

[CY4NiDE]

Any other Kangaroo version known that is known to be usable for >128bit ranges ?

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.

[Tepan]

[madogss]

Any other Kangaroo version known that is known to be usable for >128bit ranges ?

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

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

[CY4NiDE]

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

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.

 

[kTimesG]

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.

[Tepan]

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.

% 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.

[CY4NiDE]

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.

[COBRAS]

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:

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

[CY4NiDE]

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.

[tetra098v]

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

[Tepan]

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.

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

[Tepan]

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.