Bitcoin puzzle transaction ~32 BTC prize to who solves it

[Ihsotas.Otomakan]

We had our first automatic adjustment of the proof-of-work difficulty on 30 Dec 2009.  

The minimum difficulty is 32 zero bits, so even if only one person was running a node, the difficulty doesn't get any easier than that.  For most of last year, we were hovering below the minimum.  On 30 Dec we broke above it and the algorithm adjusted to more difficulty.  It's been getting more difficult at each adjustment since then.

The adjustment on 04 Feb took it up from 1.34 times last year's difficulty to 1.82 times more difficult than last year.  That means you generate only 55% as many coins for the same amount of work.

The difficulty adjusts proportionally to the total effort across the network.  If the number of nodes doubles, the difficulty will also double, returning the total generated to the target rate.

For those technically inclined, the proof-of-work difficulty can be seen by searching on "target:" in debug.log.  It's a 256-bit unsigned hex number, which the SHA-256 value has to be less than to successfully generate a block.  It gets adjusted every 2016 blocks, typically two weeks.  That's when it prints "GetNextWorkRequired RETARGET" in debug.log.

minimum    00000000ffff0000000000000000000000000000000000000000000000000000
30/12/2009 00000000d86a0000000000000000000000000000000000000000000000000000
11/01/2010 00000000c4280000000000000000000000000000000000000000000000000000
25/01/2010 00000000be710000000000000000000000000000000000000000000000000000
04/02/2010 000000008cc30000000000000000000000000000000000000000000000000000
14/02/2010 0000000065465700000000000000000000000000000000000000000000000000
24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000
08/03/2010 00000000387f6f00000000000000000000000000000000000000000000000000
21/03/2010 0000000038137500000000000000000000000000000000000000000000000000
01/04/2010 000000002a111500000000000000000000000000000000000000000000000000
12/04/2010 0000000020bca700000000000000000000000000000000000000000000000000
21/04/2010 0000000016546f00000000000000000000000000000000000000000000000000
04/05/2010 0000000013ec5300000000000000000000000000000000000000000000000000
19/05/2010 00000000159c2400000000000000000000000000000000000000000000000000
29/05/2010 000000000f675c00000000000000000000000000000000000000000000000000
11/06/2010 000000000eba6400000000000000000000000000000000000000000000000000
24/06/2010 000000000d314200000000000000000000000000000000000000000000000000
06/07/2010 000000000ae49300000000000000000000000000000000000000000000000000
13/07/2010 0000000005a3f400000000000000000000000000000000000000000000000000
16/07/2010 000000000168fd00000000000000000000000000000000000000000000000000
27/07/2010 00000000010c5a00000000000000000000000000000000000000000000000000
05/08/2010 0000000000ba1800000000000000000000000000000000000000000000000000
15/08/2010 0000000000800e00000000000000000000000000000000000000000000000000
26/08/2010 0000000000692000000000000000000000000000000000000000000000000000

date, difficulty factor, % change
2009           1.00
30/12/2009     1.18   +18%
11/01/2010     1.31   +11%
25/01/2010     1.34    +2%
04/02/2010     1.82   +36%
14/02/2010     2.53   +39%
24/02/2010     3.78   +49%
08/03/2010     4.53   +20%
21/03/2010     4.57    +9%
01/04/2010     6.09   +33%
12/04/2010     7.82   +28%
21/04/2010    11.46   +47%
04/05/2010    12.85   +12%
19/05/2010    11.85    -8%
29/05/2010    16.62   +40%
11/06/2010    17.38    +5%
24/06/2010    19.41   +12%
06/07/2010    23.50   +21%
13/07/2010    45.38   +93%
16/07/2010   181.54  +300%
27/07/2010   244.21   +35%
05/08/2010   352.17   +44%
15/08/2010   511.77   +45%
26/08/2010   623.39   +22%

So I was digging in the past and found this!!

Could this be related?
And if it was related Don't forget me when you get to solve the puzzle ...

[brainless]

We had our first automatic adjustment of the proof-of-work difficulty on 30 Dec 2009.  

The minimum difficulty is 32 zero bits, so even if only one person was running a node, the difficulty doesn't get any easier than that.  For most of last year, we were hovering below the minimum.  On 30 Dec we broke above it and the algorithm adjusted to more difficulty.  It's been getting more difficult at each adjustment since then.

The adjustment on 04 Feb took it up from 1.34 times last year's difficulty to 1.82 times more difficult than last year.  That means you generate only 55% as many coins for the same amount of work.

The difficulty adjusts proportionally to the total effort across the network.  If the number of nodes doubles, the difficulty will also double, returning the total generated to the target rate.

For those technically inclined, the proof-of-work difficulty can be seen by searching on "target:" in debug.log.  It's a 256-bit unsigned hex number, which the SHA-256 value has to be less than to successfully generate a block.  It gets adjusted every 2016 blocks, typically two weeks.  That's when it prints "GetNextWorkRequired RETARGET" in debug.log.

minimum    00000000ffff0000000000000000000000000000000000000000000000000000
30/12/2009 00000000d86a0000000000000000000000000000000000000000000000000000
11/01/2010 00000000c4280000000000000000000000000000000000000000000000000000
25/01/2010 00000000be710000000000000000000000000000000000000000000000000000
04/02/2010 000000008cc30000000000000000000000000000000000000000000000000000
14/02/2010 0000000065465700000000000000000000000000000000000000000000000000
24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000
08/03/2010 00000000387f6f00000000000000000000000000000000000000000000000000
21/03/2010 0000000038137500000000000000000000000000000000000000000000000000
01/04/2010 000000002a111500000000000000000000000000000000000000000000000000
12/04/2010 0000000020bca700000000000000000000000000000000000000000000000000
21/04/2010 0000000016546f00000000000000000000000000000000000000000000000000
04/05/2010 0000000013ec5300000000000000000000000000000000000000000000000000
19/05/2010 00000000159c2400000000000000000000000000000000000000000000000000
29/05/2010 000000000f675c00000000000000000000000000000000000000000000000000
11/06/2010 000000000eba6400000000000000000000000000000000000000000000000000
24/06/2010 000000000d314200000000000000000000000000000000000000000000000000
06/07/2010 000000000ae49300000000000000000000000000000000000000000000000000
13/07/2010 0000000005a3f400000000000000000000000000000000000000000000000000
16/07/2010 000000000168fd00000000000000000000000000000000000000000000000000
27/07/2010 00000000010c5a00000000000000000000000000000000000000000000000000
05/08/2010 0000000000ba1800000000000000000000000000000000000000000000000000
15/08/2010 0000000000800e00000000000000000000000000000000000000000000000000
26/08/2010 0000000000692000000000000000000000000000000000000000000000000000

date, difficulty factor, % change
2009           1.00
30/12/2009     1.18   +18%
11/01/2010     1.31   +11%
25/01/2010     1.34    +2%
04/02/2010     1.82   +36%
14/02/2010     2.53   +39%
24/02/2010     3.78   +49%
08/03/2010     4.53   +20%
21/03/2010     4.57    +9%
01/04/2010     6.09   +33%
12/04/2010     7.82   +28%
21/04/2010    11.46   +47%
04/05/2010    12.85   +12%
19/05/2010    11.85    -8%
29/05/2010    16.62   +40%
11/06/2010    17.38    +5%
24/06/2010    19.41   +12%
06/07/2010    23.50   +21%
13/07/2010    45.38   +93%
16/07/2010   181.54  +300%
27/07/2010   244.21   +35%
05/08/2010   352.17   +44%
15/08/2010   511.77   +45%
26/08/2010   623.39   +22%

So I was digging in the past and found this!!

Could this be related?
And if it was related Don't forget me when you get to solve the puzzle ...

Yes it's related, consider word factor, in puzzle creator also mention factor .01 to .0001, now use brain to solve puzzle with factor adjustment

[Niekko]

Yes it's related

related to what ? 

[Ihsotas.Otomakan]

As BurtW also pointed out the transaction values increase from from 0.001 to 0.256, according to the address position.

Lets start by what we know:

The BTC values of the outputs (0.001 through 0.256) are obviously the sequence numbers and the private keys are the sequence values.

How many of the sequence values do we already know (have been found by brute force)?  

Is the list in this thread the entire list of known values from the sequence?

here are the other pvk decimal values I was able to find:

Address 15: 26867
Address 16: 51510
Address 17: 95823
Address 18: 198669
Address 19: 357535
Address 20: ?

Addrss 71+ ?
Are people getting bored?

[Cricktor]

...

What is your intention of quoting decade old posts?

One of Satoshi about proof of work auto-adjustment which has basically nothing related to the puzzle challenge of this topic. It's fundamental to how Bitcoin works, but doesn't help anyone to come closer to any solution of yet unsolved ones. And brainless... well, is literally brainless! Not really hot news.  

Another of Bulista which makes not much sense to quote in the current solution context of the Bitcoin challenge puzzle. Maybe I don't see or understand the point you want to make. Enlighten me/us what your thought process was, if there was any thought process, actually.

Do us a favour and stop shitposting here, please. If you don't understand why #71+ are hard to solve (just by the huge size of the search space and there're no shortcuts, really), take a break, read and learn, but don't pollute this topic with your nonsense. I guess nobody here, except maybe brain-dead morons, wants to spoon-feed you (with garbage).

[Grzegorz2022]

I would like to ask the community about your energy efficiency metrics. I think this is an important piece of information in this topic, which hasn't really been discussed yet.

Specifically, I'm interested in:

Pure sequential search speed (not random methods) – measured in EOS (Exa Operations per Second)
Total system power draw – measured in Watts (from the wall, under full load)
I'm looking for the ratio of search speed to power consumption.
For reference, my setup achieves ~2.90 W per 1 EOS.
Could you share your results?
Thanks !

[SecretAdmirere]

I would like to ask the community about your energy efficiency metrics. I think this is an important piece of information in this topic, which hasn't really been discussed yet.

Firstly, you need to scale down the "1 quantillion" to a way way lower number.. And measure what does it take to produce 1 point on the curve, not "i covered this much distance with 1 point". With that claim "2.9w per 1 EOS", the 135bit range of challenge address 135, that has roughly what, 22000 quantillions to check? Would be solved by 100 RTX 5090 GPU-s in couple of days while undervolted to save what ever space they occupy from burning down. But how much memory it requires? Few petabytes? Exabytes? You need to store roughly 2⁶⁷ bytes worth of baby steps?

And how would you compare your BSGS with for eg. Kangaroo? Kangaroo measures raw computation of per point compares, not how much it traveled across the elliptic curve space, but is far more efficient then bsgs regardless of the console display of the speed. Or bluntly, lets just compare what do we need to produce 1 point on the curve, and if we are hashing it then also account that?

My program currently, on 3070 Ti:

Accounting only gpu power draw, for the whole pipeline (private key -> public key -> sha256 -> ripemd160 -> check if its a match) form the program start, does 7.8m hash160 checks per 1watt (gpu draws 290w, stock settings).

Accounting only gpu power draw, for the whole pipeline (private key -> public key -> check if its a match) form the program start, does 27.8m coordinate checks per 1watt (gpu draws 310w, stock settings).

I divided 2.25b hash160 checks a second with 290w power draw, to get 0.0000001289w per hash160 check.
Same with 8.65b coordinates checks a second with 310w power draw, to get 0.0000000360w per coordinate check.

And also, the coordinate compare kernel only produces valid points on the curve and compares them to 1 target public key, kinda "useless regardless of the speed, but is purely there to see differences of what ripemd160 does to the gpu and how costly it is".

And also, efficiency is heavily tied to the gpu that is currently crunching numbers. 3070 Ti will never be as efficient as 4090, so its heavily dependent on the gpu it self. And perhaps 4090 isnt as efficient after all, perhaps some other gpu might be more efficient.

There are too many variables to account to say confidently "my setup is more efficient then yours", especially when everyone has their own metrics of efficiency.

Just my opinion, not nesessarly correct one, feel free to agree or disagree, i dont care, who knows, maybe from gazilion shit ideas one turns out to be acctually usefull.

[Grzegorz2022]

I would like to ask the community about your energy efficiency metrics. I think this is an important piece of information in this topic, which hasn't really been discussed yet.

Firstly, you need to scale down the "1 quantillion" to a way way lower number.. And measure what does it take to produce 1 point on the curve, not "i covered this much distance with 1 point". With that claim "2.9w per 1 EOS", the 135bit range of challenge address 135, that has roughly what, 22000 quantillions to check? Would be solved by 100 RTX 5090 GPU-s in couple of days while undervolted to save what ever space they occupy from burning down. But how much memory it requires? Few petabytes? Exabytes? You need to store roughly 2⁶⁷ bytes worth of baby steps?

And how would you compare your BSGS with for eg. Kangaroo? Kangaroo measures raw computation of per point compares, not how much it traveled across the elliptic curve space, but is far more efficient then bsgs regardless of the console display of the speed. Or bluntly, lets just compare what do we need to produce 1 point on the curve, and if we are hashing it then also account that?

My program currently, on 3070 Ti:

Accounting only gpu power draw, for the whole pipeline (private key -> public key -> sha256 -> ripemd160 -> check if its a match) form the program start, does 7.8m hash160 checks per 1watt (gpu draws 290w, stock settings).

Accounting only gpu power draw, for the whole pipeline (private key -> public key -> check if its a match) form the program start, does 27.8m coordinate checks per 1watt (gpu draws 310w, stock settings).

I divided 2.25b hash160 checks a second with 290w power draw, to get 0.0000001289w per hash160 check.
Same with 8.65b coordinates checks a second with 310w power draw, to get 0.0000000360w per coordinate check.

And also, the coordinate compare kernel only produces valid points on the curve and compares them to 1 target public key, kinda "useless regardless of the speed, but is purely there to see differences of what ripemd160 does to the gpu and how costly it is".

And also, efficiency is heavily tied to the gpu that is currently crunching numbers. 3070 Ti will never be as efficient as 4090, so its heavily dependent on the gpu it self. And perhaps 4090 isnt as efficient after all, perhaps some other gpu might be more efficient.

There are too many variables to account to say confidently "my setup is more efficient then yours", especially when everyone has their own metrics of efficiency.

Just my opinion, not nesessarly correct one, feel free to agree or disagree, i dont care, who knows, maybe from gazilion shit ideas one turns out to be acctually usefull.

Thank you for your response.

Let's simplify this to the bare minimum to keep it clear.
We cannot fairly compare individual hardware specs or private code, because everyone runs a different setup. However, the ultimate benchmark of this project is identical for everyone: covering the keyspace sequentially to find the target key without skipping a single possibility.
It is worth noting that my algorithm specifically targets puzzle challenges with a known public key (pubkey). Because of this, it doesn't matter how we do it or what we physically calculate. One person hashes RipeMD160 to target an address, while I work directly on the secp256k1 curve by subtracting mathematical steps from the pubkey. The internal mechanism is irrelevant as long as the search is fully sequential and mathematically tight (zero keys are skipped).
Since my algorithm covers the sequence with 100% completeness and leaves no gaps, 1 effective Exa is 1 Exa. Therefore, the only true economic metric is the total power draw of the entire machine from the wall. My full system achieves this tight sequence at ~2.9W per 1 EOS of covered secp256k1 space.
(I know that Kangaroo is currently the fastest algorithm, but for example, my algorithm doesn't completely outclass it. I have a certain trick that allows me to find the key as fast as 10 seconds up to the maximum for the puzzle relative to my program. In short, for the same key, my program always finds it in the same amount of time, but the trick I applied gives me the ability to find it anywhere from a minimum of 10 seconds up to the standard maximum time of the program. This way, I shorten the overall search time.Of course, I do not include this trick in the EOS/kWh measurement.)
At the end of the day, it's about search economics. So, to make this comparable: 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.

[SecretAdmirere]

At the end of the day, it's about search economics. So, to make this comparable: 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.

Ofc, its all about that, if its even feasable to do it, let alone profitable. But as an comparisment of "a vs. b" i disagree, different solutions = different requirements. How much hardware you need for 1 eos for the current lowest bit challenge address that isnt solved using bsgs? One thing is hardware and second is power consumption of the said hardware. And dont forget the time needed as well. It might be power efficient, but run for a decade.

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. 12 years if you hash the said public keys. Using 3070 Ti only. Not really a solution for the problem.

How much hardware you would need for 135 and roughly how much time til the private key would be found?

[kTimesG]

At the end of the day, it's about search economics. So, to make this comparable: 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.

Your question makes no sense, because the metric you're using ("covered space after X point additions and X hash table lookup / second") is linked to the problem space, not to the actual operational mode. So your one "exa" for #135 is different than one "exa" for #100, and so on. You will get different "exa/s" on the same machine that runs the same code, but on different sizes of the problem.

Go on, attack some Satoshi pubKey with the same code, you will reach maybe septillions of zettas of exas/second, but this doesn't make anything faster at all. So?

The only metric that matters is how efficient a program runs, which ultimately reduces to EC group operations / watt / time (factor in the cost as well here), not to the skewed concept you're trying to use.

[SecretAdmirere]

Unless some algorithmic discovery is found that reduces number of operations needed to find a private key of any of the higher bit addresses, no matter how you restructure existing solutions, its simply not feasable from any perspective other then the luck factor. But luck factor requires coin flips and a pen and a paper only.

Wanna search the 72 challenge address? Unless someone finds a way to make ripemd160 frendly on a consumer gpu, its not feasable to solve. And "prefix" range elimination is a luck factor, noone and nothing can guarantie this public key bits will hash to that simply beacuse these bits from before hashed to something. Its not a shortcut to the solution. Btw ripemd160 is the reason why for eg. 3070 Ti or 4090 can do 2.25b or 8b hash160 checks / second, the bottleneck.

Wanna search the 140 challenge address? Unless someone finds a way to reduce required operations from 2⁷⁰ to even just 2⁶⁰, not feasable. But for different reasons then the hashed public keys from those challenge addresses that dont have exposed public keys.

By feasable i mean the hardware and time required to find a private key.

[Grzegorz2022]

At the end of the day, it's about search economics. So, to make this comparable: 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.

Your question makes no sense, because the metric you're using ("covered space after X point additions and X hash table lookup / second") is linked to the problem space, not to the actual operational mode. So your one "exa" for #135 is different than one "exa" for #100, and so on. You will get different "exa/s" on the same machine that runs the same code, but on different sizes of the problem.

Go on, attack some Satoshi pubKey with the same code, you will reach maybe septillions of zettas of exas/second, but this doesn't make anything faster at all. So?

The only metric that matters is how efficient a program runs, which ultimately reduces to EC group operations / watt / time (factor in the cost as well here), not to the skewed concept you're trying to use.

Nice to see you again!
 I understand my question may raise some doubts, so let me clarify.

Every machine like mine (cost ~$1500) running my algorithm achieves exactly the same speed and power draw. This means that splitting the range into, say, 2 parts and running 2 machines gives a 2× speedup at a cost of ~5.8 W/EOS.
The scale of Puzzle 135 is enormous – that's obvious. I'm not asking whether it can be solved in a week. I'm asking about the energy cost of covering a unit of space – how much you pay per 1 EOS in your own setup.
I'm not trying to challenge anyone's results. I don't have access to your hardware or code, just as you don't have access to mine. I understand this makes verification difficult. My data comes from real measurements – from the wall, under full load, with no tricks.
I would simply like to know your energy costs.
I know different algorithms and hardware make comparisons difficult. But it can be calculated – under one condition: a fixed time to find the key. If the time varies, the metric breaks.
The best approach would be:
Measure the actual time to find a key
Measure the total power draw from the wall (entire machine, not just GPU)
Based on that, calculate how many watts 1 EOS costs you
For me that's the only fair metric that allows comparison of search economics regardless of hardware or algorithm.

Unless some algorithmic discovery is found that reduces number of operations needed to find a private key of any of the higher bit addresses, no matter how you restructure existing solutions, its simply not feasable from any perspective other then the luck factor. But luck factor requires coin flips and a pen and a paper only.

Wanna search the 72 challenge address? Unless someone finds a way to make ripemd160 frendly on a consumer gpu, its not feasable to solve. And "prefix" range elimination is a luck factor, noone and nothing can guarantie this public key bits will hash to that simply beacuse these bits from before hashed to something. Its not a shortcut to the solution. Btw ripemd160 is the reason why for eg. 3070 Ti or 4090 can do 2.25b or 8b hash160 checks / second, the bottleneck.

Wanna search the 140 challenge address? Unless someone finds a way to reduce required operations from 2⁷⁰ to even just 2⁶⁰, not feasable. But for different reasons then the hashed public keys from those challenge addresses that dont have exposed public keys.

By feasable i mean the hardware and time required to find a private key.

I agree with you, without an algorithmic breakthrough, the higher puzzles are out of reach.
However, my question was about something else: the energy cost of covering a unit of space.
I'm not asking whether Puzzle 135 can be solved. I'm asking how many watts 1 EOS costs you in your setups.
That's the only metric that allows a fair comparison of search economics – regardless of algorithm, hardware, or puzzle size.
Can anyone provide their result in this metric?

Hello
For Grzegorz2022
For puzzle 135 I use Collider bsgs cuda which provides me with a good scanning speed of 60-65 Exa key/sec.
I adapted the software for RTX5090 from the source: https://github.com/Etayson/BSGS-cuda.
​​The software is optimized, does not give errors and does not miss keys (in tests on valid addresses).
To generate the executable, PureBasic with a license is required. Below I put an example of scanning for Puzzle 135.

C:\Users\NN\Desktop\COLLIDER>bsgscudaHT_1_9_7file -t 256 -b 256 -p 914 -w 32 -htsz 31 -pk 6cf4feb12b75e8e00fffffffffffffffff -pke 6cf4feb12b75e8eFFFFFFFFFFFFFFFFFFF -infile Puzle135
Number of GPU threads set to #256
Number of GPU blocks set to #256
Number of pparam set to #914
Items number set to 2^32=4294967296
HT size set to 2^31
Range begin: 0x6cf4feb12b75e8e00fffffffffffffffff
Range end: 0x6cf4feb12b75e8efffffffffffffffffff
Will be used file: Puzle135
Found 1 Cuda device.
Cuda device:NVIDIA GeForce RTX 5090 (30840.000/32606MB)
Current config hash[]
GiantSUBvalue:0000000000000000000000000000000000000000000000000000000200000000
GiantSUBpubkey: 038c0989f2ceb5c771a8415dff2b4c4199d8d9c8f9237d08084b05284f1e4df706
*******************************
Total GPU Memory Need: 30060.000MB
*******************************
Both HT files exist
Load BIN file:256_256_914_4294967296_g2.BIN

• chunk:1073741824b
[1] chunk:1073741824b
[2] chunk:1073741824b
Last chunk:612368384b
[3] chunk:612368384b
Done in 00:00:00s
Gstep: e48000000000000
GPU count #1
GPU #0 launched
GPU #0 Free/Total/Need memory: 30838/32606/30060.002MB
_A size:120
GPU #0 copied giant array
Remove Giant array, freed memory: 3656.000 MB
Load BIN file:79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798_4294967296_214 7483648_htGPUv0.BIN

• chunk:1073741824b
[1] chunk:1073741824b
[2] chunk:1073741824b
.........................................................................
[23] chunk:1073741824b
Last chunk:4b
[24] chunk:4b
Done in 00:00:03s
GPU #0 copied hash table
Remove HT for GPU, freed memory: 24576.000 MB
Random verify packed HTCPU items in file...ok
START RANGE= 0000000000000000000000000000006cf4feb12b75e8e00fffffffffffffffff
  END RANGE= 0000000000000000000000000000006cf4feb12b75e8efffffffffffffffffff
WIDTH RANGE= 000000000000000000000000000000000000000000000ff00000000000000000 = 2^76
SUBpoint= (afaacd852045a0e036d93ee350283936b312b379f0f1e04bf35565897ecaa282, 8a334cf89c64444f69049c40d563f435209697a9a7b92b38bd59a02b44db2556)
Save work every 180 seconds
Checker thread started

Findpubkey  : 02145d2611c823a396ef6712ce0f712f09b9b4f3135e3e0aa3230fb9b6d08d1e16
Searchpubkey: 03235dada82c3477f7b249b6c7660b84b664d490465f98afd5efcc2b8c5c074c97
Cnt:fea5718000000000001 [1][ 7161 ] = 7161 MKeys/s x2^33.0=2^65.81 Jt:00:19:27
Reached end of space
GPU#0 job finished
GPU#0 thread finished
cuda finished ok
Press Enter to exit
............................................................................
Speed calculation
Total RANGE =  ff00000000000000000 (hex) => 75262715820734970593280 (decimal)
Working time = 00:19:27 = 1167 sec
Average working speed = 75262715820734970593280 : 1167 = 64,492,472,854,100,231,870 => ~ 64.49 Exa key/sec


Be careful when setting parameters : -t 256 -b 256 -p 914 -w 32 -htsz 31
Follow this line at the beginning of the program : GPU #0 Free/Total/Need memory: 30838/32606/30060.002MB
The required memory must not exceed the free memory.
If you have not met this condition, stop the program and adjust the parameters.
Otherwise, you will receive an error. You will waste your time.

To generate the bin files you need RAM, at least 128-256 Gb/5600Mhz, minimum 16 core processor, frequency ~5 Ghz, a fast Nvme SSD helps a lot.
Do not use disk storage units, generating the bin files will take a long, long time.
The motherboard should have PCie generation 5 slots and 64-128 lanes.
After generating the bin files, the processor and memory are no longer required in the scanning process, all the work moves to the video card.
The next launch of the program takes very little time, a few seconds.
Bin File 1 = 41943041 Kb. Bin File 2 = 25165825 Kb.
A more powerful video card (RTX 6000 Pro with 96 Gb GDDR 7, 512 bit bandwidth) can reach ~ 180 Exa key/sec.
Multiple cards result in incredible speed for Pub key scanning.
.........................................................
Device Name   DESKTOP-RAUCMTO
Mainboard       ASUS Pro WS WRX90E-Sage
Processor   AMD Ryzen Threadripper PRO 9955WX 16-Cores        4.50 GHz
Installed RAM   256 GB RDIMM (255 GB usable), 5600 MHz
Storage           3.64 TB SSD Samsung SSD 990 PRO 4TB
Graphics Card   NVIDIA GeForce RTX 5090 (32 GB)
System Type   64-bit operating system, x64-based processor
                Edition   Windows 10 Pro

Hello! Could you tell me what your power consumption cost is per 1 EXA/kWh, but for the entire machine (not just the GPU)? Thanks!

[kTimesG]

Based on that, calculate how many watts 1 EOS costs you
For me that's the only fair metric that allows comparison of search economics regardless of hardware or algorithm.

That's not how people estimate costs or compare things. You cannot compare BSGS with Kangaroo since they have different requirements and different guarantees. For example, BSGS doesn't need the "y" coordinate, while Kangaroo does. So this would make BSGS "faster" at computing, but slower overall because it needs to read memory at every step (assuming this is even feasible).

The algorithms also have different worst/best number of steps. Kangaroo has an upper bound of infinite amount of steps. BSGS guarantees an yes/no answer in a maximum amount of steps. You cannot compare things by how fast some key is found, it doesn't make sense.

So your entire metric is awkward.You can have a very slow machine that finds things faster because it uses a different algorithm, and you can have a very fast machine that never finds anything.

And, again, there is no such "EOS" metric, not between algos, let alone between different problem sizes of the same algo. The only metric is "how much will it cost me to solve something, on average" followed by different levels of certitude risk scenarios.

[Grzegorz2022]

Based on that, calculate how many watts 1 EOS costs you
For me that's the only fair metric that allows comparison of search economics regardless of hardware or algorithm.

That's not how people estimate costs or compare things. You cannot compare BSGS with Kangaroo since they have different requirements and different guarantees. For example, BSGS doesn't need the "y" coordinate, while Kangaroo does. So this would make BSGS "faster" at computing, but slower overall because it needs to read memory at every step (assuming this is even feasible).

The algorithms also have different worst/best number of steps. Kangaroo has an upper bound of infinite amount of steps. BSGS guarantees an yes/no answer in a maximum amount of steps. You cannot compare things by how fast some key is found, it doesn't make sense.

So your entire metric is awkward.You can have a very slow machine that finds things faster because it uses a different algorithm, and you can have a very fast machine that never finds anything.

And, again, there is no such "EOS" metric, not between algos, let alone between different problem sizes of the same algo. The only metric is "how much will it cost me to solve something, on average" followed by different levels of certitude risk scenarios.

To settle the debate on whether effective Exa is comparable, let's look at real public logs from optimized open-source tools.
For example, a high-end setup running Etayson's BSGS-cuda for a known pubkey challenge achieves around 64.49 EOS. This machine uses an NVIDIA RTX 5090 (600W TDP) on an AMD Threadripper PRO platform, with total system power draw from the wall reaching at least 750W.
When you run the math, this flagship $10,000 setup runs at roughly 9.3W per 1 EOS (GPU only) or 11.6W per 1 EOS (entire system).
My custom algorithm achieves ~2.9W per 1 EOS for the ENTIRE machine on a standard consumer-grade platform costing ~$1500.
This means my system is about 4× more energy-efficient and over 6× cheaper to purchase than that flagship setup.
This is precisely why my question about whole-system search economics matters. Even when comparing direct, non-hashed pubkey operations on the secp256k1 curve with zero key skipping, a highly optimized, custom linear step can be 3-6x more energy-efficient than a raw CUDA kernel running on a flagship RTX 5090.
I understand your concerns, and I agree that BSGS and Kangaroo are different algorithms with different requirements and guarantees. However, I'm not comparing algorithms – I'm comparing economics.
My W/EOS metric doesn't say which algorithm is better. It says: "How many watts does it cost me to cover a unit of space in my setup?"
If someone uses a different algorithm, let them provide their data: time, power draw, range. Then we can convert it to W/EOS and see who pays less per unit of space covered.
That's the only metric that allows comparison of real-world energy costs – regardless of whether you're using BSGS, Kangaroo, or anything else.
My question still stands: how many watts does 1 EOS cost you in your setup?, I already give my result – it's 2.9W/EOS.

[COBRAS]

with previous singular curve formula if we change the the y generator we can derive the real private key in secp256k1. But still cube root , modulo and inverse very though combination to transform singular to non singular or vice versa.

Gx = 55066263022277343669578718895168534326250603453777594175500187360389116729240
Gy = 32670510020758816978083085130507043184471273380659243275938904335757337482424

Example change Gy with
59823076176775181571204541928527100257995243906978864486811434808323840641867 will derive Pvkey 2
43876487655252862751108870209152448218695366102209763771099490322191083647380 will derive Pvkey 13

Good day.Have you any deno of this ?

[kTimesG]

My question still stands: how many watts does 1 EOS cost you in your setup?

This is the third and last time I'll say this: there is no such "EOS" metric. Space covering is fully dependent on the size of the baby table. The baby table size depends on the problem key-space (or on the maximum available memory). Usually it's simply the max memory, which is of course totally suboptimal for high ranges, which is the reason BSGS sucks at those levels anyway.

So each time you double up the baby table size, your "coverage speed" also doubles. Same goes with halving it.

Does this not ring any bells, or raise red flags, to you? You are trying to compute some efficiency score regarding COMPUTATION efficiency, based on something that depends on arbitrary MEMORY size depending on where you run it or what problem you are targeting.

Your reasoning is not rational. Again, someone with more memory can simply out-bench you simply because they have more RAM, no matter what other things you consider constant. And, again: increasing the problem size also exponentially increases the "coverage speed" because the square root also increases (this is just exactly the same thing as saying "the baby steps table will be bigger if memory allows"). So there is no way on Earth that anything you are trying to achieve makes sense.

[Grzegorz2022]

My question still stands: how many watts does 1 EOS cost you in your setup?

This is the third and last time I'll say this: there is no such "EOS" metric. Space covering is fully dependent on the size of the baby table. The baby table size depends on the problem key-space (or on the maximum available memory). Usually it's simply the max memory, which is of course totally suboptimal for high ranges, which is the reason BSGS sucks at those levels anyway.

So each time you double up the baby table size, your "coverage speed" also doubles. Same goes with halving it.

Does this not ring any bells, or raise red flags, to you? You are trying to compute some efficiency score regarding COMPUTATION efficiency, based on something that depends on arbitrary MEMORY size depending on where you run it or what problem you are targeting.

Your reasoning is not rational. Again, someone with more memory can simply out-bench you simply because they have more RAM, no matter what other things you consider constant. And, again: increasing the problem size also exponentially increases the "coverage speed" because the square root also increases (this is just exactly the same thing as saying "the baby steps table will be bigger if memory allows"). So there is no way on Earth that anything you are trying to achieve makes sense.

For full context – my ~$1500 system (working directly on the pubkey, not on an address):

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)

I'm not saying this to brag. I'm saying it to make it clear that I'm really not trying to compare algorithms or hardware.
Let me ask you a simple question: how much secp256k1 space can you cover at the cost of 1 kWh?
I don't care about the technique, the hardware, or the algorithm. I only care about power consumption per unit of space covered – unless your algorithm is based on luck rather than computational power. If that's the case, then the W/EOS (Exa Operations per Second) metric obviously doesn't apply.
Yes, I know – doubling the memory increases the baby table and boosts speed. But I assume everyone pushes their hardware to its maximum, right? So you're running at your limit.
Besides – as you can see above, I have 4× lower energy consumption, 6× lower hardware cost, and nearly 2× higher speed. You can easily calculate how many of my units I could get for the same budget and what total speed I'd achieve. It's not a small number.
My question is: with 1 kWh of power, how much of the curve can you sweep while searching for a key to a given puzzle?
The question is simple. My answer – 2.9W/EOS – is correct and based on real measurements. What about yours? I assume you know your hardware's power draw and the speeds you're getting, so you should be able to calculate it easily.

I should also add – in case you missed it earlier – I applied a certain trick to my program, an additional bonus that gives me the ability to find the key earlier, in a range from a minimum of 10 seconds up to the normal search time relative to my speed for EACH puzzle!!! Unfortunately, I can't show it. I know this doesn't mean much without proof, but that's how it is – I've tested it many times. So I also have an acceleration in finding the key, but I do not include this in the stated power consumption per 1 EOS/W because it is not constant.