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.