Bitcoin Forum
June 27, 2026, 06:54:20 PM *
News: Latest Bitcoin Core release: 31.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 [677]
  Print  
Author Topic: Bitcoin puzzle transaction ~32 BTC prize to who solves it  (Read 394654 times)
Ihsotas.Otomakan
Newbie
*
Offline

Activity: 2
Merit: 0


View Profile
June 24, 2026, 10:00:27 PM
 #13521

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
Member
**
Offline

Activity: 493
Merit: 35


View Profile
June 25, 2026, 03:43:55 AM
 #13522

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

13sXkWqtivcMtNGQpskD78iqsgVy9hcHLF
Niekko
Member
**
Offline

Activity: 124
Merit: 42


View Profile
June 25, 2026, 10:11:29 PM
 #13523

Yes it's related


related to what ?  Roll Eyes

Ihsotas.Otomakan
Newbie
*
Offline

Activity: 2
Merit: 0


View Profile
June 25, 2026, 11:23:27 PM
 #13524

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
Legendary
*
Offline

Activity: 1540
Merit: 4119



View Profile
June 26, 2026, 08:28:24 PM
Merited by NotFuzzyWarm (1)
 #13525

...
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.  Roll Eyes

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

███████████████████████████
███████▄████████████▄██████
████████▄████████▄████████
███▀█████▀▄███▄▀█████▀███
█████▀█▀▄██▀▀▀██▄▀█▀█████
███████▄███████████▄███████
███████████████████████████
███████▀███████████▀███████
████▄██▄▀██▄▄▄██▀▄██▄████
████▄████▄▀███▀▄████▄████
██▄███▀▀█▀██████▀█▀███▄███
██▀█▀████████████████▀█▀███
███████████████████████████
.
.Duelbits PREDICT..
█████████████████████████
█████████████████████████
███████████▀▀░░░░▀▀██████
██████████░░▄████▄░░████
█████████░░████████░░████
█████████░░████████░░████
█████████▄▀██████▀▄████
████████▀▀░░░▀▀▀▀░░▄█████
██████▀░░░░██▄▄▄▄████████
████▀░░░░▄███████████████
█████▄▄█████████████████
█████████████████████████
█████████████████████████
.
.WHERE EVERYTHING IS A MARKET..
█████
██
██







██
██
██████
Will Bitcoin hit $200,000
before January 1st 2027?

    No @1.15         Yes @6.00    
█████
██
██







██
██
██████

  CHECK MORE > 
Grzegorz2022
Newbie
*
Offline

Activity: 45
Merit: 0


View Profile
Today at 02:24:01 PM
 #13526

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
Newbie
*
Offline

Activity: 27
Merit: 2


View Profile
Today at 03:54:46 PM
 #13527

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
Newbie
*
Offline

Activity: 45
Merit: 0


View Profile
Today at 04:52:03 PM
Last edit: Today at 05:14:01 PM by Grzegorz2022
 #13528

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.
Pages: « 1 ... 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 [677]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!