Bitcoin puzzle transaction ~32 BTC prize to who solves it

[nomachine]

Where is the bottleneck in this script, essentially? How can we speed it up further? 

Hello, two days ago, you had a speed of 55 keys/s, and now it's 75 keys/s. And you're still not satisfied? 

The bottleneck is SECP256K1 itself, and of course, hashing.

[pbies]

Because we are searching for puzzle 68 it would be better to use failing or known randomness from the past (or the same seed), than using good randomness which will not guide us towards salvation which here is hitting the same randomness used in the past while creating puzzles.

We need bad randomness, not a good one!

[nomachine]

We need bad randomness, not a good one!

While Xoshiro256 is fast, it is not optimized for the secure task of generating Bitcoin private keys. Brute-forcing requires the use of GPUs or ASICs, which would far outperform Xoshiro256. I am using it here experimentally, with a line of thinking similar to yours. 

[Akito S. M. Hosana]

I am using it here experimentally, with a line of thinking similar to yours. 

What does this mean? Are the keys generated in a completely different way compared to other scripts?

[nomachine]

I am using it here experimentally, with a line of thinking similar to yours. 

What does this mean? Are the keys generated in a completely different way compared to other scripts?

Not necessarily in a completely different way. The goal here is to guess private keys that are already in use. The rule is that there are no rules about what you should use as a random generator. You can use a lottery drum if that method is fast enough for your needs. I have even used UUID Version 4 in some key generation scripts. This is fine as long as the keys are not used for real funds or transactions.

[Akito S. M. Hosana]

The goal here is to guess private keys that are already in use. The rule is that there are no rules about what you should use as a random generator.

RTX 4090 is capable of doing 7.0 - 7.1 GK/s to scan a given range, not 4 or 5. Yes, just the keys in a given interval, not the ones with symmetry or endo (in that case, it can surpass 10 GK/s).

What do you guys even use as a random generator if the speed needs to be 10 GK/s?

[nomachine]

What do you guys even use as a random generator if the speed needs to be 10 GK/s?

Don't worry. You'll be fine with the Xoshiro256plus PRNG, which can handle up to 8 GB/s running on one core of a CPU.

If you manage to exceed 8 GB/s, PM me.  

[Akito S. M. Hosana]

What do you guys even use as a random generator if the speed needs to be 10 GK/s?

Don't worry. You'll be fine with the Xoshiro256plus PRNG, which can handle up to 8 GB/s running on one core of a CPU.

If you manage to exceed 8 GB/s, PM me.  

I'm totally confused now. What's the difference between 10 GK/s vs 10 GB/s?

[nomachine]

I'm totally confused now. What's the difference between 10 GK/s vs 10 GB/s?

10 GB/s refers to the throughput or the rate at which the PRNG can produce random data.
A Bitcoin private key is a 256-bit (32-byte) number. This is the size of the data required to generate one Bitcoin key.

You would need a PRNG or hardware setup that can generate random data at 320 GB/s to achieve 10 GK/s.

P.S. Xoshiro256plus could achieve the required throughput of 320 GB/s with 128 cores.

[saeedxxx]

10 GB/s refers to the throughput or the rate at which the PRNG can produce random data.
A Bitcoin private key is a 256-bit (32-byte) number. This is the size of the data required to generate one Bitcoin key.

You would need a PRNG or hardware setup that can generate random data at 320 GB/s to achieve 10 GK/s.

P.S. Xoshiro256plus could achieve the required throughput of 320 GB/s with 128 cores.

Do you consider generating an address to be the same as generating a random number? What about the other parts? Hashing, Elliptic curve ,...?

[kTimesG]

The goal here is to guess private keys that are already in use. The rule is that there are no rules about what you should use as a random generator.

RTX 4090 is capable of doing 7.0 - 7.1 GK/s to scan a given range, not 4 or 5. Yes, just the keys in a given interval, not the ones with symmetry or endo (in that case, it can surpass 10 GK/s).

What do you guys even use as a random generator if the speed needs to be 10 GK/s?

Zero PRNG. The keys are in sequence, the only difference between hashing keys at random positions, and keys that are in sequence, is that it's much faster to do them in sequence. And there is no risk to hash the same keys twice, because the birthday paradox cannot occur.

Take a sequence of 2**N keys. You need to have a large N.
Split it evenly by number of threads (let's say, for CUDA, we have 16384 blocks * 256 threads each, and each thread does 2048 point additions at every launch).
Compute the first starting key and delta key (that's only two EC point multiplications).
Compute starting keys for all threads, evenly (that's 16384 * 256 EC group additions - very fast).
Run kernel a required amount of times, to scan full range (it only does EC group additions, and hashing of each key).
For symmetry/endo: also compute hashes of X*beta, X*beta2, combined with -Y. No EC math involved. Also, Y does not even need to be computed at all (except once, for the delta jump) - just check both parities for compressed pubKey!

So: only two point multiplications, and a shitload of group additions. This is how one gets to 10 GK/s using just 450 watts.

[tmar777]

The goal here is to guess private keys that are already in use. The rule is that there are no rules about what you should use as a random generator.

RTX 4090 is capable of doing 7.0 - 7.1 GK/s to scan a given range, not 4 or 5. Yes, just the keys in a given interval, not the ones with symmetry or endo (in that case, it can surpass 10 GK/s).

What do you guys even use as a random generator if the speed needs to be 10 GK/s?

Zero PRNG. The keys are in sequence, the only difference between hashing keys at random positions, and keys that are in sequence, is that it's much faster to do them in sequence. And there is no risk to hash the same keys twice, because the birthday paradox cannot occur.

Take a sequence of 2**N keys. You need to have a large N.
Split it evenly by number of threads (let's say, for CUDA, we have 16384 blocks * 256 threads each, and each thread does 2048 point additions at every launch).
Compute the first starting key and delta key (that's only two EC point multiplications).
Compute starting keys for all threads, evenly (that's 16384 * 256 EC group additions - very fast).
Run kernel a required amount of times, to scan full range (it only does EC group additions, and hashing of each key).
For symmetry/endo: also compute hashes of X*beta, X*beta2, combined with -Y. No EC math involved. Also, Y does not even need to be computed at all (except once, for the delta jump) - just check both parities for compressed pubKey!

So: only two point multiplications, and a shitload of group additions. This is how one gets to 10 GK/s using just 450 watts.

Very clever approach! Is this code somewhere available?
I am not an experienced programmer.
Thanks

[nomachine]

10 GB/s refers to the throughput or the rate at which the PRNG can produce random data.
A Bitcoin private key is a 256-bit (32-byte) number. This is the size of the data required to generate one Bitcoin key.

You would need a PRNG or hardware setup that can generate random data at 320 GB/s to achieve 10 GK/s.

P.S. Xoshiro256plus could achieve the required throughput of 320 GB/s with 128 cores.

Do you consider generating an address to be the same as generating a random number? What about the other parts? Hashing, Elliptic curve ,...?

In the code, the Xoshiro256plus PRNG is used to generate random numbers, but it is adjusted to ensure they fall within the valid range using modulo arithmetic.

I tested this with 128 CPU cores. The speed is approximately 936 Mkeys/s with hashing to HASH160.

Without hashing, just capturing the public key, the speed is around 1380 Mkeys/s.

Now, imagine adapting this to the GPU and using AVX2—combining both CPU and GPU power.

An RTX 3060 achieves around 2300 Mkeys/s, and so on.

But yeah, all this is a waste of time on any single GPU. Without 2000 GPUs, none of this can be solved. So, I'm going fishing....

[nomachine]

Honestly, you'll get rich faster selling fish than trying to find the key without some new software created by a genius. 

I wish I were a genius. But I'm not. Maybe someone else here is.   

[kTimesG]

Now, imagine adapting this to the GPU and using AVX2—combining both CPU and GPU power.

An RTX 3060 achieves around 2300 Mkeys/s, and so on.

You are making a wrong assumption here: that you can simply combine GPU output with CPU calculations, or something. The calculations performed by a GPU are internal to the device (no memory transfers between host and device).

If we remove hashing step from the CUDA code, then the speed is like a few times higher. For example, around 25 GK/s just to produce public keys of a sequential range. Even more if we add the sym/endo (but these are derived from a single public key anyway, there is no point doing it on a GPU).

But in in no way you could ever transfer the huge amounts of results back to the CPU world, in order to hash it. You are limited by the memory clock of the GPU, the total memory of the GPU, and the bus width of the PCIe lanes. So the end result is a very lousy speed, grabbing all the actual results a GPU can produce is something that is totally unmanageable by a CPU, no matter how many cores you have.

Or did I understand something wrong?

[Akito S. M. Hosana]

Wait a minute. If he just said that the 3060 achieves around 2300 Mkeys/s, how much does the 4090 achieve? Does it reach 8000 Mkeys/s on the RTX 4090? 8 GK/s ?  In Cyclone GPU ?

Why won't anyone share the fastest GPU code here? Are you hiding the best code for yourselves?  It's all just empty talk and blah blah blah..

[kruk01]

Did anyone check speed of RTX 4070 on KeyHunt??

[Denevron]

Wait a minute. If he just said that the 3060 achieves around 2300 Mkeys/s, how much does the 4090 achieve? Does it reach 8000 Mkeys/s on the RTX 4090? 8 GK/s ?  In Cyclone GPU ?

Why won't anyone share the fastest GPU code here? Are you hiding the best code for yourselves?  It's all just empty talk and blah blah blah..

Because no one is obliged to put their work in the public domain for everyone to see. They spend their time and energy on it.

[Akito S. M. Hosana]

The x-coordinate for puzzle 135 is 76 digits and the y-coordinate is 77 digits?
This may help with searching a sub-range of keys. My terminal process killed running 1E32 but I only have 4GB of RAM.
Try 1E21 and be sure to check the length of the x_values on output they range from 75-77.
Good Luck!

Why are you even saving it to a file? You can do the matching right away.
  

Code:

from ecdsa import SigningKey, SECP256k1
import ecdsa

# Define Puzzle #135 coordinates
x_given = 9210836494447108270027136741376870869791784014198948301625976867708124077590
y_given = 69440582532487379038177105219556131878098716909078780397935812212458092996863

# Define the target x-coordinate to match exactly
target_x = x_given  # You can set this to any specific value

# Define private key search range
k_lower = 21778071482940061661655974875633165533184  # + 10**26
k_upper = 43556142965880123323311949751266331066367  # - 10**26

def private_key_to_public_xy(private_key):
    """Computes the x and y coordinates of the public key from a given private key."""
    sk = SigningKey.from_secret_exponent(private_key, curve=SECP256k1)
    vk = sk.verifying_key
    # Extract x and y coordinates
    x_coord = int.from_bytes(vk.to_string()[:32], 'big')  # First 32 bytes are x
    y_coord = int.from_bytes(vk.to_string()[32:], 'big')  # Next 32 bytes are y
    return x_coord, y_coord

# Reduce step size to scan more precisely
step_size = int(1e35)  # Smaller step size for finer detail

print("Scanning for private keys that generate x and y values close to the given coordinates...")

for k in range(k_lower, k_upper, step_size):
    x_value, y_value = private_key_to_public_xy(k)
  
    # Check if x_value matches the target_x exactly
    if x_value == target_x:
        print(f"Exact match found! Private Key = {k}, x = {x_value}, y = {y_value}")
        break  # Stop searching after finding the exact match

You will quickly realize that this is useless. Without a kangaroo, you have no chance of finding a match.

[dastic]

Code:

--- Final Best Candidate ---
Private Key: 27465881482940061352098229436045164806144 (hex: 00000000000000000000000000000050b7085c1533b415567000000000000000)
x-coordinate: 9210790008149297258455471224225729038493158517165492613256687428790137027105 (hex: 145d1f5582595ead4268d635071da2f683076ec96fee811b878a424f599e7a21)
Difference: 46486297811011571665517151141831298625497033455688369289438917987050485

Still pretty useless