Bitcoin Forum
March 23, 2026, 01:53:38 AM *
News: Latest Bitcoin Core release: 30.2 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: How many CPUs/GPUs needed to crack Bitcoin Puzzle 71 and 135 in 1 day?  (Read 307 times)
mimi94 (OP)
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
July 08, 2025, 03:31:14 AM
 #1

# i asked then chatgpt provide this...

Hi all,

I want to better understand the realistic hardware requirements to brute-force Bitcoin Puzzle #71 (71-bit) and Puzzle #135 (135-bit) within 1 day using normal brute-force methods.

For Puzzle #71, the range is:

0x400000000000000000 : 0x7fffffffffffffffff
which is 2^70 keys (~1.18e21 keys).

I am currently testing with:

xxBitCrack.exe --keyspace 400000000000000000:7fffffffffffffffff -c 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU
on 1 CPU @ 3 million keys/sec, but it would take ~12.5 million years to complete the scan on a single CPU.

By rough calculation:

To finish in 1 year, it would need ~12.5 million CPUs at this speed.

To finish in 1 day, it would need ~4.55 billion CPUs at this speed.

For Puzzle #135 (135-bit), I understand the keyspace is:

2^135 ≈ 4.05e40 keys
which is vastly larger, making brute-force practically impossible, but I want to understand what theoretical hash rate would be required to complete this in 1 day for perspective.

My questions:
✅ How many CPUs (at ~3M keys/sec) would be needed to brute-force:

Puzzle #71 in 1 day

Puzzle #135 in 1 day

✅ Alternatively, how many GPUs (RTX 4090, RX 7900 XTX, etc.) would be needed assuming realistic speeds (~2-4 billion keys/sec per GPU)?

✅ Is there any realistic path with a large GPU cluster or pool to approach Puzzle 71, or is it still impractical?

✅ For Puzzle 135, is there any point in even estimating, or is it simply out of any feasible range even with worldwide resources?

I want to open this for discussion for anyone interested in puzzle cracking, keyspace math, and realistic limits in the Bitcoin puzzle space.

All insights are welcome, especially from those with GPU farm experience or who have worked on the lower puzzles.

Thank you!

If you want, I can also prepare:
✅ A calculation table comparing different GPUs and cluster sizes for your post.
✅ A signature-friendly short version if you want it as your footer on Bitcointalk.

Let me know if you would like these next for maximum engagement on your thread.

# this code was correct or not some one improve this calculation. cpu/gpu
Code:
# Example calculation for Puzzle 71

# Constants
keyspace = 2 ** 70  # total keys
speed_per_cpu = 3_000_000  # 3 million keys/sec
target_seconds = 86400  # 1 day

# Total time for 1 CPU
total_seconds = keyspace / speed_per_cpu
print("Total seconds for 1 CPU:", total_seconds)

# Convert to days
print("Total days for 1 CPU:", total_seconds / 86400)

# CPUs needed to finish in 1 day
num_cpus = total_seconds / target_seconds
print("CPUs needed for 1 day:", num_cpus)

I want real tested data for cracking Puzzle 71 and Puzzle 135 in 1 day.
What CPU/GPU hardware do you recommend based on your actual tests?


Hi, can you please suggest which high-speed cracking tool you recommend for this, including the name you use for your tests? Thanks!
Lolo54
Member
**
Offline Offline

Activity: 133
Merit: 32


View Profile
July 08, 2025, 08:34:50 AM
 #2

To keep things simple without going into technical details and exhausting calculations for
71
--> the range comprises 1180591620717411303423 addresses to be scanned.  It all depends on where the target address is located in this range, but if we assume that it's at the end, it would take almost 2 million 4090 GPUs to reach it in 24 hours. If the target is in the middle of the range, let's say that 1 million GPU 4090s would suffice
with GPU 5090s, let's say that this number would require around 20% fewer GPUs, i.e. 1M5 or 750K
This is using Bitcrack or Vanitysearch, perfectly optimized for the system used.

For the 135 it's different insofar as the pubkey is available, the tools and speed are also different, but the difficulty is just as great. RetiredCoder's RCKangaroo, which was perfectly optimized for its configuration (i.e. over 12GK/s for the 130é), took 2 months to achieve this using 400 GPU 3090s, with the target at 62% of the range. In 1 day, we would have needed almost 60 times as many 3090 GPUs, say at least 24,000 RTX 3090 GPUs.
For the 135th, the search space is more than 30 times larger, so we'd need at least 750k GPUs 3090 to get there in 24 hours, if the target is 60% of the range, using software perfectly optimized to run on such a configuration.

Whether it's the 71st or the 135th, the difficulty of getting there is roughly the same, even if the software or the way of doing it is different, since for one the pubkey is known. We wish you good luck. Grin
bigbroski
Newbie
*
Offline Offline

Activity: 1
Merit: 0


View Profile
March 22, 2026, 12:21:48 PM
Last edit: March 22, 2026, 12:47:45 PM by bigbroski
 #3

# i asked then chatgpt provide this...

Hi all,

I want to better understand the realistic hardware requirements to brute-force Bitcoin Puzzle #71 (71-bit) and Puzzle #135 (135-bit) within 1 day using normal brute-force methods.

For Puzzle #71, the range is:

0x400000000000000000 : 0x7fffffffffffffffff
which is 2^70 keys (~1.18e21 keys).

I am currently testing with:

xxBitCrack.exe --keyspace 400000000000000000:7fffffffffffffffff -c 1PWo3JeB9jrGwfHDNpdGK54CRas7fsVzXU
on 1 CPU @ 3 million keys/sec, but it would take ~12.5 million years to complete the scan on a single CPU.

By rough calculation:

To finish in 1 year, it would need ~12.5 million CPUs at this speed.

To finish in 1 day, it would need ~4.55 billion CPUs at this speed.

For Puzzle #135 (135-bit), I understand the keyspace is:

2^135 ≈ 4.05e40 keys
which is vastly larger, making brute-force practically impossible, but I want to understand what theoretical hash rate would be required to complete this in 1 day for perspective.

My questions:
✅ How many CPUs (at ~3M keys/sec) would be needed to brute-force:

Puzzle #71 in 1 day

Puzzle #135 in 1 day

✅ Alternatively, how many GPUs (RTX 4090, RX 7900 XTX, etc.) would be needed assuming realistic speeds (~2-4 billion keys/sec per GPU)?

✅ Is there any realistic path with a large GPU cluster or pool to approach Puzzle 71, or is it still impractical?

✅ For Puzzle 135, is there any point in even estimating, or is it simply out of any feasible range even with worldwide resources?

I want to open this for discussion for anyone interested in puzzle cracking, keyspace math, and realistic limits in the Bitcoin puzzle space.

All insights are welcome, especially from those with GPU farm experience or who have worked on the lower puzzles.

Thank you!

If you want, I can also prepare:
✅ A calculation table comparing different GPUs and cluster sizes for your post.
✅ A signature-friendly short version if you want it as your footer on Bitcointalk.

Let me know if you would like these next for maximum engagement on your thread.

# this code was correct or not some one improve this calculation. cpu/gpu
Code:
# Example calculation for Puzzle 71

# Constants
keyspace = 2 ** 70  # total keys
speed_per_cpu = 3_000_000  # 3 million keys/sec
target_seconds = 86400  # 1 day

# Total time for 1 CPU
total_seconds = keyspace / speed_per_cpu
print("Total seconds for 1 CPU:", total_seconds)

# Convert to days
print("Total days for 1 CPU:", total_seconds / 86400)

# CPUs needed to finish in 1 day
num_cpus = total_seconds / target_seconds
print("CPUs needed for 1 day:", num_cpus)

I want real tested data for cracking Puzzle 71 and Puzzle 135 in 1 day.
What CPU/GPU hardware do you recommend based on your actual tests?


Hi, can you please suggest which high-speed cracking tool you recommend for this, including the name you use for your tests? Thanks!

If your considering seriously to crack anyone of them, you should go for 135 because it's difficulty is much less then 71 but the reward is much higher . Pollards Kangaroo helps you reduce it from 135 to 67.5 while you cannot reduce the puzzle 71 because you don't know the public key and on that you have two hashing to do.

And as per the best of my knowledge, the most optimised approach for  cracking puzzle 71 is leveraging the fact that the first 185 bits are zero and the 186th bit is one. One can use that knowledge to specifically make a tool that does not do full 256 bit EC multiplication but saves a significant amount of the computation by using a 71 bit secret key input for each multiplication....this reduces the scalar size for EC multiplication, making each individual key generation and address hash calculation significantly faster.  This thing is implemented in a little different form in software like the BitcoinAddressFinder , which start with the assumption that first 96 bits of the private key are 0, and instead they brute force on the remaining 160 bit space. That reduces the search space by  large orders of magnitude. And specifically the number 160 because 160 is the number of bits in the HASH160 wallet format. BUT FOR THE CASE OF PUZZLE 71 OUR SPACE IS EVEN SMALLER. Those tools use the fact that effectively searching the 160 bit private key space can give you the private key for a given wallet, even if the original public key that was related to the wallet had 256 bit sk. Those effectively have 80 bits of security, which is still enormous if you are not a attacker with Nation state level resources.

Other  optimization by puzzle cracking software include for eg, probabilistic filters like the bloom filter,which makes the checks effectively O(1) if you are checking multiple pubkeys in any case.

If you want to have a realistic estimation, the RTX 5090 with  speed of about 9 G keys per second on optimised tools for secp256k1  would require about 692-696 yrs.
kTimesG
Full Member
***
Offline Offline

Activity: 784
Merit: 240


View Profile
March 22, 2026, 07:27:43 PM
 #4

Other  optimization by puzzle cracking software include for eg, probabilistic filters like the bloom filter,which makes the checks effectively O(1) if you are checking multiple pubkeys in any case.

BS. Bloom filters are useless for puzzles. unless someone wants that O(1) to mean having a painful slow kernel for no reason whatsoever. The only reason to ever use a bloom filter is when searching for more than one vanity address, but that's most often stupid in itself anyway, and has nothing to do with any single-target puzzles.

Off the grid, training pigeons to broadcast signed messages.
Pages: [1]
  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!