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

I wouldn't say that when 1000 people gather at a puzzle, unlike in the past, the chances of cracking the address beforehand skyrocket, the problem see is  the prize will take before you

Nice, now we have 15 more unknown digits. What do we go from there? Nowhere!

I'm going back to random starting point generation. And i think I've got one more thing under my sleeve that i wanna share but I'll have to try first.

Now ppl can stop complaining about electricity cost, lack of intensive or lack of resources. No actually you can still complain about that last one. But the point is, the creator is opening up even more doors. Let's be grateful.

The value of unsolving puzzles goes up 10X today😇

I'm curious to see now if the X10 financial bounty can accelerate or not as saatoshi_rising said "of the cracking strength of the community." if the resistance is due to the bounty or the network strength .... anyway I highly doubt that beyond 135 bit nothing will be solved no matter the bounty it will take something other than brute force

Congratulations, all puzzle prizes increased 10 folds.

Even puzzle #1 received 0.09 BTC but the bots stole them instantly.

Yes...   publickey(x,y) - G(x,y)

     

It's superb it becomes really very motivating there will be people on it
#66 at 6.6 BTC is superb

the address that issued the transactions contained 872 btc the person behind is not out of BTC at all.....  I've been on this puzzle since the beginning and the day I saw the one and only intervention of the creator of this puzzle I said to myself it's satoshi himself who is behind (but I could be wrong) just a feeling

https://bitcointalksearch.org/topic/m.18765941    (message from creator saatoshi_rising)

https://www.blockchain.com/explorer/addresses/BTC/bc1quksn4yxlxp80tn929gqnh8xpnngqj0fqr99q4z

I would absolutely like to understand who is the one behind this puzzle and why he should spend this huge sum only for prove that Bitcoin network is really resistant and hard to break. This absolutely make me crazy !

I will start to look with much interest to this thread and try also to find something, now find a piece of puzzle could be a life change chance !

I use the library, how can I find out, I looked in the Process Hacker 2 application to see if the library is connected to a remote server, but there were so many descriptions that I couldn't find anything

it's interesting now someone must have gone crazy it's a great motivation to come up with better code i think we haven't used the full potential yet i think there is a way to maximize the chance of a crack it works in python if someone did it for 1000x faster gpu i think it could be a game changer

Amazing! Now it's getting interesting again tryting to beat those puzzles. Thanks for the information and thanks to the puzzle creator who is among us

Well, all the remaining addresses received a total of 872.2 BTC, so this challenge is getting damn huge. 

https://blockchair.com/bitcoin/transaction/12f34b58b04dfb0233ce889f674781c0e0c7ba95482cca469125af41a78d13b3

WOW!
Somebody (maybe the owner) increased the unsolved puzzles prizes again by x10 😱
Now the puzzle #66 prize is 6.6 BTC, #67 is 6.7 BTC... and so on .... puzzle # 160 prize is 16 BTC now
👍🏼🥳

Really?  

---

you mean point multiplication x,y for g in the elliptic curve?

you can DM me!

There's the math comes again,

66 Bit puzzle  


the total number of keys in this range can be calculated by taking 16 to the power of 17 (i.e., 16^17), which is equal to 295,147,905,179,352,825,856.

So, there are a total of 295,147,905,179,352,825,856 keys in the given range.

If you have a speed of 343 million keys per second (Mkeys/s), the result's,

Total number of keys = 295,147,905,179,352,825,856
Time = Total number of keys / Speed

Substituting the values, we get:

Time = 295,147,905,179,352,825,856 / 343,000,000
Time = 859,488,566,568 seconds

Therefore, it would take approximately 859,488,566,568 seconds (or about 27,247 years) to generate all the possible keys in the given range at a speed of 343 million keys per second. This is a very long time and may not be practically feasible.

what if i have 5000 mkeys to scan those number of key ?
it would take approximately 59,029,581,036 seconds (or about 1,872 years) to generate all the possible keys in the given range at a speed of 5000 million keys per second, still lame haha  

---

and there's other scenario to win the ticket haha

For a 66-bit puzzle, the key range would be from 0 to 2^66 - 1, which is:

0 to 7,922,816,251,426,433

The number of keys in this range is:

2^66 = 73,786,976,294,838,206,464

At a scanning speed of 343 Mkey/s, the time it would take to scan this entire range would be:

Time = Number of Keys / Keys per Second

Time = (2^66) / 343000000 = 215625224 seconds
= 3593754 minutes
= 59896 hours
= 2495 days
≈ 6.84 years

So, it would take approximately 6.84 years to scan the entire key range of a 66-bit puzzle at the given scanning speed.

If we were to randomly hit the private key in the middle of the range, then we would only need to scan half of the key range, which is:

2^65 = 36,893,488,147,419,103,232

Using the same formula as above, the time it would take to scan half of the key range would be:

Time = (2^65) / 343000000 = 107812612 seconds
= 1796877 minutes
= 29948 hours
= 1248 days
≈ 3.42 years

So, if we randomly hit the private key in the middle of the key range, it would take approximately 3.42 years to scan half of the key range at the given speed of 343 Mkey/s.


btw, my close friend is neat, he's building something on ASICs L3+ to give a proof to scan the puzzle for mean time haha.
let's see..

I just do some math with #66 Puzzle.

You just need bigA$$ Mkeys. (e.g 5000 Mkeys)

time = (range size) / (speed * 10^6)

Where range size is the number of keys in the range (3ffffffffffffffff - 20000000000000000 + 1 = 3ffffffffffffffe1), speed is the speed of the search in millions of keys per second, and 10^6 is used to convert from millions to individual keys per second.

Time = (3ffffffffffffffe1) / (5000 * 10^6) = 7671.29 seconds

Therefore, it would take approximately 7671.29 seconds (or about 2.13 hours) to search the given range at a speed of 5000 Mkeys per second.

Device i use was 1650Ti and give 343 Mkeys speed with Keyhunt Albertobsd, 15X GPUs needed..

Time to win the lottery haha  

this method only Kangaroo and hash160.

sorry for not mention about the 66 bit range haha, i already double check on reply below

but i feelin weird about the keybit range about 66 itself. its maybe arround 20000000000000000:4ffffffffffffffff not 3.  

this just IMO , consider to bullyin my opinion you better skip to read this.
#CMIIW

If you guys try to skip non-random keys (like those containing repeating patterns like 111) then you can also try to skip ranges when some prefixing characters of the address were found.
Example: You found a prefix 1XXXXX of target 1XXXXX... so you can skip ahead like nBits because it is unlikely 1XXXXX will appear in nBits again. The skipped offset nBits should be very conservative/pessimistic.

Or when doing it multithreaded you can mark nBits around the found prefix 1XXXXX as "unlikely" and continue the search only in the "possible" ranges. You could decrease the unlikely nBits as you progress to eventually realize this does not work too.

You can try, but don't expect miracles, almost all public keys have 256 bit private keys, which is a different universe, simply put, a waste of time

I'm writing an algorithm for all addresses with pubkey exposed. This is impossible with your method.