Bitcoin puzzle transaction ~32 BTC prize to who solves it

[Grzegorz2022]

The question is simple. My answer – 2.9W/EOS – is correct and based on real measurements. What about yours?

When it comes to BSGS and "space covering", a decent CPU + shitloads of RAM will leave any GPU far away. Including your setup, or any other setup that involves running BSGS on a GPU (any GPU).

BSGS does not run well on a GPU, its speed is scales of magnitude LOWER than maximum possible because IT NEEDS TO READ MEMORY AT EVERY STEP.

You are simply wasting energy running BSGS on a GPU.

Buy a CPU and shitloads of RAM if you want to run BSGS. Do not run BSGS on any GPU. Those exas/s do not exist, in reality in runs magnitudes of order SLOWER than any Kangaroo ever will. As in: the solution will be found orders of magnitudes later than Kangaroo.

It is a dumb idea to run BSGS on a GPU. GPUs are meant to compute, not to access DRAM. Reading and writing DRAM is a GPU's "kill switch" bottleneck.

And this is ofcourse futile anyway since BSGS cannot solve anything above 80 or so bits unless you go the supercomputer way.

If you want real comparisons: RC stated he reached around 14.8 Gk/s on a RTX 4090 stock clock card. First, transform your "EOS" into Gk/s (the real speed), compare the expected number of ops (which is similar) and you will see why BSGS runs orders of magnitudes slower.

I simply wanted to know how much power others are drawing on their machines at their speeds – nothing more, kTimesG. I don't feel like explaining myself anymore; I've already said a lot. If you remember, I've been writing my own algorithm for almost a year now, and I know what I have and what I'm talking about. I'm not going to argue. I also understand that I'm not providing proof, but I'm not trying to convince anyone of anything – I just wanted to know how much power you're using on your machines, calculated against your speed. I gave mine.
Regardless of the puzzle difficulty, my speed is constant. As I mentioned, a $1500 computer. From what I can see, everyone else is behind, except for Kangaroo, which rules. But as I mentioned, I have a trick – though it's based on luck, it shortens my normal search time relative to my speed. My speed is constant – every puzzle takes the same amount of time to solve. Combined with the trick, the maximum time stays the same, but I gain the ability to find the key faster, in a range from 10 seconds up to my standard time.
My question was about energy efficiency, but you took it in other directions! That's why I'm not writing more in this thread. I also asked you something before, and you avoided the topic then too. I'm not asking you for your code – I'm asking normal questions, and this was only my second question here on the forum.
I'll take this opportunity – I'm curious if your puzzle is in the 110-bit range. You put it together in an interesting way.
As for my algorithm – it finds keys above 80 bits in a reasonable time. My goal is to keep developing the algorithm and to solve Puzzle 135.
Can you tell me the time it took to find a key and for which puzzle in the configuration you mentioned here? Also, is the time always constant?: If you want real comparisons: RC stated he reached around 14.8 Gk/s on a RTX 4090 stock clock card. First, transform your "EOS" into Gk/s (the real speed), compare the expected number of ops (which is similar) and you will see why BSGS runs orders of magnitudes slower. You're forgetting that I don't use standard BSGS. I have my own implementation, my own methods, and various optimizations. What you're suggesting – doing the same as RC – would reduce me to exactly what he does. I already know I wouldn't reach that speed because I have an older GPU, but he doesn't have the same effective speed that I do – unless you're talking about Kangaroo, which you didn't specify.
If you look through my posts from the last few months, you'll see I've made progress. I'm still thinking about how to decompose problems. I also wrote kernels in assembly, plus lots of testing – because CUDA compiles nicely, but not perfectly, if you know what I mean. I focused on every aspect, and now I'm focusing on tricks that I come up with and apply.
Right now, I want to learn about power consumption relative to speed – as you know, there's practically no information about this. I know my own stats and I know it's a very good result relative to speed, but I'd like to confirm it by hearing how much power others are using.

[SecretAdmirere]

My question was about energy efficiency, but you took it in other directions!

It was alredy explained by me (altho poorly) and much better from kTimesG, it isnt a simple "A vs. B" comparison, different worlds of computing and requirements:

You cannot compare BSGS with Kangaroo since they have different requirements and different guarantees.

There is a reason why RC used couple of 4090 to solve 120, 125, 130, running his version of kangaroo and not bsgs.

You alredy compared apples to apples:

nearly 2× faster than Etayson's BSGS-cuda on RTX 5090 (60-65 Exa key/sec)
4× more energy-efficient (2.9 W/EOS vs 11.6 W/EOS for the entire system)
6× cheaper ($1500 vs $10,000)

If you want real comparisons: RC stated he reached around 14.8 Gk/s on a RTX 4090 stock clock card. First, transform your "EOS" into Gk/s (the real speed), compare the expected number of ops (which is similar) and you will see why BSGS runs orders of magnitudes slower.

If you want to compare it, you need to "transform" what bsgs does and what kangaroo does into something similar that you can compare, idk what but you cant "my draws 2 watts for 1 eos and his idk what". Fire up RC kangaroo, one publicly avaliable (not "optimised" that reaches 15 Gk/s but far less) and search for an 80bit(private key) public key, it will find it in few secconds on 4090. 3070 Ti on a 71bit(private key) public key using as is RC kangaroo from github, finds it faster then it was for me to enter search parameters.

How can you quantify that? And turn it into this is 1 eos here and 1 eos there? What would be 1 eos in kangaroo that you could compare it to? What wattage you pick, the 3070 Ti or 4090? What range, 71bit or 80bit? But that doesnt tell you anything even after you do it, once you scale it up to 135 or 140 challenge address everything changes.

And kangaroo doesnt squentially check points from start - end, it finds collissions between two points, so that alredy throws out any "how many total watts does your whole machine draw to securely cover 1 Exa of the sequence? That's the only metric that matters here." and puts your bsgs against a pure sequential brute force which does make bsgs much more efficient there then the per point checks my public key kernel does which was never even designed to do anything except comparing its truoghput vs. hashing the public keys.

I understand what you are trying to see, but you cant really compare it like that.

[Grzegorz2022]

My question was about energy efficiency, but you took it in other directions!

It was alredy explained by me (altho poorly) and much better from kTimesG, it isnt a simple "A vs. B" comparison, different worlds of computing and requirements:

You cannot compare BSGS with Kangaroo since they have different requirements and different guarantees.

There is a reason why RC used couple of 4090 to solve 120, 125, 130, running his version of kangaroo and not bsgs.

You alredy compared apples to apples:

nearly 2× faster than Etayson's BSGS-cuda on RTX 5090 (60-65 Exa key/sec)
4× more energy-efficient (2.9 W/EOS vs 11.6 W/EOS for the entire system)
6× cheaper ($1500 vs $10,000)

If you want real comparisons: RC stated he reached around 14.8 Gk/s on a RTX 4090 stock clock card. First, transform your "EOS" into Gk/s (the real speed), compare the expected number of ops (which is similar) and you will see why BSGS runs orders of magnitudes slower.

If you want to compare it, you need to "transform" what bsgs does and what kangaroo does into something similar that you can compare, idk what but you cant "my draws 2 watts for 1 eos and his idk what". Fire up RC kangaroo, one publicly avaliable (not "optimised" that reaches 15 Gk/s but far less) and search for an 80bit(private key) public key, it will find it in few secconds on 4090. 3070 Ti on a 71bit(private key) public key using as is RC kangaroo from github, finds it faster then it was for me to enter search parameters.

How can you quantify that? And turn it into this is 1 eos here and 1 eos there? What would be 1 eos in kangaroo that you could compare it to? What wattage you pick, the 3070 Ti or 4090? What range, 71bit or 80bit? But that doesnt tell you anything even after you do it, once you scale it up to 135 or 140 challenge address everything changes.

And kangaroo doesnt squentially check points from start - end, it finds collissions between two points, so that alredy throws out any "how many total watts does your whole machine draw to securely cover 1 Exa of the sequence? That's the only metric that matters here." and puts your bsgs against a pure sequential brute force which does make bsgs much more efficient there then the per point checks my public key kernel does which was never even designed to do anything except comparing its truoghput vs. hashing the public keys.

I understand what you are trying to see, but you cant really compare it like that.

Honestly, I'm dropping this topic now. I knew perfectly well that it would be hard to compare, but as I mentioned, I don't have standard BSGS – I have my own implementation. kTimesG kept shifting my question in other directions, but I continued with my question while responding – yet it changed course. So many posts with kTimesG, and zero answers to the specific question.
I said from the beginning: the condition is a constant search time!! Kangaroo is not constant – it's probabilistic. As for the rest, which finds keys again in constant time – it can be calculated, and it doesn't matter what algorithm it is, whether standard or not. I gave you my consumption, and it's true. You also can't force me to switch to another algorithm and test it, because each one differs in everything – just like mine, except mine isn't available anywhere.
I'm letting go of this topic. Based on my calculations and the information I gathered – and there's really almost zero information on the topic of power consumption for the entire machine relative to speed – if it exists, it's given as theoretical, not effective. But you know that an algorithm can be written with different methods, functions, etc., and computational speed translates into effective speed!
I also have computational speed – has anyone thought about that? But I have nothing to compare that speed to, because it's not the final effective speed. It's like counting Gk/s of point addition without accounting for hashing, or just plain addition. What matters is the effective speed, as well as power consumption and hardware cost.
I wanted to expand on the topic of energy efficiency, but it's not possible. I understand that for you it's not important, but for me it would be useful information. I'm dropping this topic. Maybe someone will respond after reading what's already been said.
I'm simply asking about power relative to machine speed, and I'm getting answers like memory, Y, "it's impossible", Gk/s without giving effective speed and power draw, pushing Kangaroo – even though I said constant time. In short – not an answer to the question asked.

[SecretAdmirere]

For 135, running only 4090 at the speed RC said he achived 15 Gk/s (14.8 Gk/s, but i rounded up to simplify calculation) you would need 312 4090 gpu-s, running 24/7, to mathematicly guarantee you will find a collision within 12 months.

For gpu default power draw 450w * (365 days * 24h) = 1230000 kWh plus what ever other system components require if you were to run "home farm".

312 * 2000$ = 624000$ for gpu-s only if you were to run a "home farm".

Idk if math is mathing, i did it on top of my head now, but when you compare it like that to 2.9w per 1 eos you achive, its 10billion times less "power efficient". But that 2.9w eos has to check 2¹³⁵ at max values before finding the private key while RC has to check 2⁶⁷ at max values before finding a private key.

Also i dont know how much ram it would require, but my guess is significantly less then bsgs requires.

And comparing "naive" check 1 key at the time from start - end doing point addition over and over again until the range is exausted, pure brute force, well... Aint anything out there that is "power efficient" to do it, which then falls far behind bsgs, thus making your implementation king of efficiency when comparing "check every key without skiping anything". But i alredy mentioned it to you:

My "naive" implementation for public key checks is just that, naive. Purely there for measuring elliptic curve operations per point checks, it would run for 4 years to cover 2⁶⁰ public keys. Using 3070 Ti only.

At that speed, 8.6b coordinate compares / second, 2⁶⁰ search space exploration, checking each one at the time, would run for 4 years, consuming 0.0000000360w per coordinate checked, total power required 2⁶⁰ * 0.0000000360w = a lot. But again, its not apples to apples compare of anything mentioned above, but it is when you constrain it to "every key checked, no gaps", which automaticly puts your bsgs the most efficient one for brute forcing every public key within a defined private key range. Which is an algorithmic adventage for the given problem, just implemented to be more efficient then other bsgs out there.

[kTimesG]

I'm simply asking about power relative to machine speed, and I'm getting answers like memory, Y, "it's impossible", Gk/s without giving effective speed and power draw, pushing Kangaroo – even though I said constant time. In short – not an answer to the question asked.

You won't get an answer because your EOS is undefined, as it's relative to the memory size. This is like the 4th time I'm saying this.

Your 1 EOS = baby steps table size * actual ops/s.

If you want comparisons, express your real speed (divide your fantasy exa/s speed to the baby steps table size). You already have your answer after that: compare it to the 14.8 Gop/s on a RTX 4090 (450 W), which is a speed that is constant, problem-agnostic, and memory-agnostic.

However, if your baby step table size is less than sqrt(keyspace), this comparison is useless, since you'll end up with the "10 billion times slower to actually solve anything" conclusion already mentioned.

[ECC_Lemma]

Sorry guys. Why exactly did Mara block the open usage of the slipstream?
 it couldn't be a coincidence that the puzzle gains traction with the slipstream as the lifeline and then suddenly they block open usage of the platform and aren't issuing any client codes per se. How does the traction hurt them, I can't tell.


Most importantly, how can the unsolved addresses beneath #130 be withdrawn then if one cannot arrange for solo mining by any means??

[bankeroft]

ECC lemma

Mara's restriction is about managing limited resources, and the ability to withdraw the puzzle funds now depends on either obtaining access through their approval process or possessing the hardware to mine a block solo

[SecretAdmirere]

Sorry guys. Why exactly did Mara block the open usage of the slipstream?
 it couldn't be a coincidence that the puzzle gains traction with the slipstream as the lifeline and then suddenly they block open usage of the platform and aren't issuing any client codes per se. How does the traction hurt them, I can't tell.

Most importantly, how can the unsolved addresses beneath #130 be withdrawn then if one cannot arrange for solo mining by any means??

For special kind of transactions requiring special care, not in any shape, form or what ever else related to the "32 bitcoin puzzle transaction challenge addresses", with a little common sense, ask the question "why would multi million business care about 32 bitcoins locked behind private keys that have variable length (later when someone incrised the pool by factor of 10, still nowhere even close to Mara holdings btc account balance)".

Quick google search:

MARA Holdings launched Slipstream to help users bypass the default restrictions of standard Bitcoin nodes, which routinely exclude large or "non-standard" transactions (such as complex Ordinals and inscriptions) from their mempools. The service allows users to submit complex transactions directly to the MARA Pool for faster confirmation.

And noone forbids the withdrawal, noone blocks it, noone in the world cares to do anything to the any address related in this "32 bitcoin puzzle transaction challenge thingy". What happens is: you find the private key for eg. puzzle address 71, you enter it in for eg. bitcoin core, you initialize the transaction to the binance wallet so you could exchange btc for $$, then the public key is broadcasted to the mempool for every miner out there to go "hmm i have space, ill try to include transaction in the next block i mine", but, someone scanning 24/7 the mempool sees the 1...VzXU address initialised the transaction and sees the public key belonging to that address, and with a potato PC can quickly find the private key as well, and initialise a new transaction with higher fee which miners would see and say "oh boy look at this juicy fee" and your initial transaction will be replaced by the one who intercepted it and replaced it with another with higher fee. Beacuse these addresses here, are known to be withing specific part of the private key space, and once public key is exposed, anyone here can see it, find quickly private key, and replace initial transaction with another one that has higher fee attached to it.

Any address below like 100bit-110bit-120bit range, can be quickly solved once the public key is exposed, faster then the original transaction would enter in some block to be mined thus making it as high chance of replacing it by higher fee transaction.

[bankeroft]

ECC lemma

ask about rebar labs shield service

[ECC_Lemma]

Sorry guys. Why exactly did Mara block the open usage of the slipstream?
 it couldn't be a coincidence that the puzzle gains traction with the slipstream as the lifeline and then suddenly they block open usage of the platform and aren't issuing any client codes per se. How does the traction hurt them, I can't tell.

Most importantly, how can the unsolved addresses beneath #130 be withdrawn then if one cannot arrange for solo mining by any means??

For special kind of transactions requiring special care, not in any shape, form or what ever else related to the "32 bitcoin puzzle transaction challenge addresses", with a little common sense, ask the question "why would multi million business care about 32 bitcoins locked behind private keys that have variable length (later when someone incrised the pool by factor of 10, still nowhere even close to Mara holdings btc account balance)".

Quick google search:

MARA Holdings launched Slipstream to help users bypass the default restrictions of standard Bitcoin nodes, which routinely exclude large or "non-standard" transactions (such as complex Ordinals and inscriptions) from their mempools. The service allows users to submit complex transactions directly to the MARA Pool for faster confirmation.

And noone forbids the withdrawal, noone blocks it, noone in the world cares to do anything to the any address related in this "32 bitcoin puzzle transaction challenge thingy". What happens is: you find the private key for eg. puzzle address 71, you enter it in for eg. bitcoin core, you initialize the transaction to the binance wallet so you could exchange btc for $$, then the public key is broadcasted to the mempool for every miner out there to go "hmm i have space, ill try to include transaction in the next block i mine", but, someone scanning 24/7 the mempool sees the 1...VzXU address initialised the transaction and sees the public key belonging to that address, and with a potato PC can quickly find the private key as well, and initialise a new transaction with higher fee which miners would see and say "oh boy look at this juicy fee" and your initial transaction will be replaced by the one who intercepted it and replaced it with another with higher fee. Beacuse these addresses here, are known to be withing specific part of the private key space, and once public key is exposed, anyone here can see it, find quickly private key, and replace initial transaction with another one that has higher fee attached to it.

Any address below like 100bit-110bit-120bit range, can be quickly solved once the public key is exposed, faster then the original transaction would enter in some block to be mined thus making it as high chance of replacing it by higher fee transaction.

I am unsure if u read my post fully because I can't correlate your response to my inquiry. I know exactly why a service like mara is pertinent for the withdrawal. I mean, I would probably be one of the best folks to explain it as I hold an MSc in cryptography and understanding this is a prerequisite.

 Ultimately, I wasn't inquiring why we are using mara, I was asking for the solution for those who cannot get the transaction solo-mined or included in a private block, boycotting the public mempool against a possible ~RBF. That is number one.

Second, I was curious if others find it outlandish that the slipstream is no longer within reach as it's always been ever since the puzzle became known. I see u made some points suggesting that the Slipstream is supposed to be for "strictly complex" transactions. My point to that will be does that mean that non-complex TXs are suddenly bad or unwanted?? Doesn't seem so to me since they accepted them long before the puzzle amplified it and what actually will matter is the FEE u are willing to pay. It is even your loss if u were to submit a standard transaction meaning a non-complex one and pay a premium as the fee. They should be happy. It means less energy usage and low cost to make more on their end. The standard transactions are a lot easier than the complex ones to resolve. Eventually, u will pay a premium to have them included in a block on the slipstream so there is no harm or loss on their end that is pure common financial sense.

[ECC_Lemma]

ECC lemma

ask about rebar labs shield service

Tnx, I"ll DMOR and due diligence on them. Hopefully, they're legit and can solve the problem. 

[kTimesG]

Second, I was curious if others find it outlandish that the slipstream is no longer within reach as it's always been ever since the puzzle became known.

Slipstream went live in 2024, 9 (nine) years after this challenge became known. So WTF are you talking about?

What's outlandish is why the f**k people are worried about some 3rd party service, when in fact it costs several times more to solve a puzzle, than the amount of the reward. Let me guess: you're in the club of the select few that solved 71 and are now on the mercy of a private mining company who doesn't give 2 shits on the pathetic worries of people who try to solve some stupid low entropy key.

Worried about bots and RBF? The advice is simple: don't try to solve low-entropy keys in the first place unless you are also the one to mine the block with the TX (and even so, have you ever heard of orphaned blocks? A determined miner might try to "invest" in replacing your block given they may get an extra 7.1 BTC for themselves).