Bitcoin puzzle transaction ~32 BTC prize to who solves it

[farou9]

so those large Xs wont show when we calculate a point that is 5th by point addition or scalar multiplication under the curve rules , but will they show when we calculate without applying mod p?

With mod p (Bitcoin's actual usage):
All coordinates wrap around p
NO large x-coordinates appear
Example (real secp256k1 point):
5G = (0x5ecbe4..., 0x769cf5...)

Without mod p (raw curve over ℝ):
Coordinates grow exponentially
 Every 5th point (5G,10G,...) has massive x-values
 Example pattern:
  5G.x = 21
  10G.x = 514
  15G.x = 26867
  20G.x = 863317

You can verify this in Python :

Code:

from ecdsa import SECP256k1
from ecdsa.ellipticcurve import Point
import matplotlib.pyplot as plt
import numpy as np

# Secp256k1 parameters
p = SECP256k1.curve.p()  
G = SECP256k1.generator  # Base point

# Over FINITE FIELD (actual Bitcoin)
def finite_scalar_mul(k):
    """ECC operation with mod p"""
    point = k * G
    return point.x()

def simulated_real_x(k):
    """real numbers"""
    return 21 * (10 ** (k//5))

# Test for multiples of 5
print("Comparison for multiples of 5G:")
for k in range(5, 26, 5):

    x_simulated = simulated_real_x(k)

    x_finite = finite_scalar_mul(k)
    
    print(f"\n{k}G:")
    print(f"Simulated real nums (no mod p): x ≈ {x_simulated:.1e}")
    print(f"Finite field (mod p): x = {x_finite}")

k_values = list(range(5, 101, 5))
x_simulated = [simulated_real_x(k) for k in k_values]

plt.figure(figsize=(10, 5))
plt.plot(k_values, x_simulated, 'ro-')
plt.yscale('log')
plt.title("Simulated Growth Pattern of x-coordinates for 5G, 10G,... (no mod p)")
plt.xlabel("Multiples of G (k)")
plt.ylabel("log(simulated x-coordinate)")
plt.grid(True)
plt.show()

 
Comparison for multiples of 5G:

5G:
Real nums (no mod p): x = 21505829891763648114329055987619236494102133314575206970830385799158076338148
Finite field (mod p): x = 21505829891763648114329055987619236494102133314575206970830385799158076338148

10G:
Real nums (no mod p): x = 72488970228380509287422715226575535698893157273063074627791787432852706183111
Finite field (mod p): x = 72488970228380509287422715226575535698893157273063074627791787432852706183111

15G:
Real nums (no mod p): x = 97505755694356382817881959832717013755620551362654128955029190924747025549326
Finite field (mod p): x = 97505755694356382817881959832717013755620551362654128955029190924747025549326

20G:
Real nums (no mod p): x = 34773495056115281091786765947597603724784643419904767525769502836017890139287
Finite field (mod p): x = 34773495056115281091786765947597603724784643419904767525769502836017890139287

25G:
Real nums (no mod p): x = 66165162229742397718677620062386824252848999675912518712054484685772795754260
Finite field (mod p): x = 66165162229742397718677620062386824252848999675912518712054484685772795754260 , ?

[nomachine]

?

Code:

from ecdsa import SECP256k1
import matplotlib.pyplot as plt

# Secp256k1 parameters
p = SECP256k1.curve.p()
G = SECP256k1.generator

def finite_mul(k):
    """ECC with mod p"""
    return (k * G).x()

def real_mul_simulation(k):
    """real number growth"""
    base = 21505829891763648114329055987619236494102133314575206970830385799158076338148
    return int(base * (2.5 ** (k//5 - 1)))

print("Comparison for multiples of 5G:")
for k in range(5, 26, 5):
    print(f"\n{k}G:")
    print(f"Simulated real nums (no mod p): x ≈ {real_mul_simulation(k)}")
    print(f"Finite field (mod p): x = {finite_mul(k)}")

k_values = list(range(5, 101, 5))
plt.figure(figsize=(10,5))
plt.plot(k_values, [real_mul_simulation(k) for k in k_values], 'ro-')
plt.yscale('log')
plt.title("Simulated Exponential Growth of x-coordinates (No Mod p)")
plt.xlabel("Multiples of G (k)")
plt.ylabel("log(x-coordinate)")
plt.grid(True)
plt.show()

[farou9]

?

Code:

from ecdsa import SECP256k1
import matplotlib.pyplot as plt

# Secp256k1 parameters
p = SECP256k1.curve.p()
G = SECP256k1.generator

def finite_mul(k):
    """ECC with mod p"""
    return (k * G).x()

def real_mul_simulation(k):
    """real number growth"""
    base = 21505829891763648114329055987619236494102133314575206970830385799158076338148
    return int(base * (2.5 ** (k//5 - 1)))

print("Comparison for multiples of 5G:")
for k in range(5, 26, 5):
    print(f"\n{k}G:")
    print(f"Simulated real nums (no mod p): x ≈ {real_mul_simulation(k)}")
    print(f"Finite field (mod p): x = {finite_mul(k)}")

k_values = list(range(5, 101, 5))
plt.figure(figsize=(10,5))
plt.plot(k_values, [real_mul_simulation(k) for k in k_values], 'ro-')
plt.yscale('log')
plt.title("Simulated Exponential Growth of x-coordinates (No Mod p)")
plt.xlabel("Multiples of G (k)")
plt.ylabel("log(x-coordinate)")
plt.grid(True)
plt.show()

Comparison for multiples of 5G:

5G:
Simulated real nums (no mod p): x ≈ 21505829891763647189493603839112105714930174046003373679412332908031823052800
Finite field (mod p): x = 21505829891763648114329055987619236494102133314575206970830385799158076338148

10G:
Simulated real nums (no mod p): x ≈ 53764574729409117973734009597780264287325435115008434198530832270079557632000
Finite field (mod p): x = 72488970228380509287422715226575535698893157273063074627791787432852706183111

15G:
Simulated real nums (no mod p): x ≈ 134411436823522782078830669922528456382616849058220265318703130412856211668992
Finite field (mod p): x = 97505755694356382817881959832717013755620551362654128955029190924747025549326

20G:
Simulated real nums (no mod p): x ≈ 336028592058807006619094091094009958299329077562753944007253627081511258816512
Finite field (mod p): x = 34773495056115281091786765947597603724784643419904767525769502836017890139287

25G:
Simulated real nums (no mod p): x ≈ 840071480147017439414709103303491669734142261531079938952390366129722052575232
Finite field (mod p): x = 66165162229742397718677620062386824252848999675912518712054484685772795754260 

Yup it's definitely exponential, but does happens to all point when no modulo p applied or is it specific for the 5th points

[nomachine]

but does happens to all point when no modulo p applied or is it specific for the 5th points

No, because Bitcoin always uses mod p, which prevents coordinate explosion.

There is NO way out of here. There is NO pattern. Bitcoin’s ECC is secure even in this puzzle.

 

[Akito S. M. Hosana]

but does happens to all point when no modulo p applied or is it specific for the 5th points

No, because Bitcoin always uses mod p, which prevents coordinate explosion.

There is NO way out of here. There is NO pattern. Bitcoin’s ECC is secure even in this puzzle.

 

Now I'm also thinking about fishing. Or it will be a brain explosion.   

[farou9]

but does happens to all point when no modulo p applied or is it specific for the 5th points

No, because Bitcoin always uses mod p, which prevents coordinate explosion.

There is NO way out of here. There is NO pattern. Bitcoin’s ECC is secure even in this puzzle.

 

so in order to detect the 5ths points pattern we need to analyze all of the n/2 points

[farou9]

I am curious why the curve parameters where chosen with different order for the scalars n and order for the coordinates p

[zahid888]

Right now I am doing GPU Cyclone version, it has hashing and comparing to target hash160, on rtx 4060 it has 4.3 Ghash/s, that faster than bitcrack, vanity, etc.

Hey, I’ve got the SHA-256 part nailed down in sha256_gpu.cu, but I’m hitting a wall with RIPEMD-160 in ripemd160_gpu.cu.

Right now, my RIPEMD-160 code outputs 499d42dd5724b7522a1c4bd895876e1232957cbe for SHA-256("abc"), but it should be 8eb208f7e05d987a9b044a8e98c6b087f15a0bfc. I’ve been digging into BitCrack’s ripemd160.cuh for clues—tweaking byte orders and round functions—but I’m still stuck.

Would you be willing to share how you’ve implemented RIPEMD-160 in CUDA? I’d love to see a working ripemd160_gpu.cu

[kTimesG]

Right now I am doing GPU Cyclone version, it has hashing and comparing to target hash160, on rtx 4060 it has 4.3 Ghash/s, that faster than bitcrack, vanity, etc.

Hey, I’ve got the SHA-256 part nailed down in sha256_gpu.cu, but I’m hitting a wall with RIPEMD-160 in ripemd160_gpu.cu.

Right now, my RIPEMD-160 code outputs 499d42dd5724b7522a1c4bd895876e1232957cbe for SHA-256("abc"), but it should be 8eb208f7e05d987a9b044a8e98c6b087f15a0bfc. I’ve been digging into BitCrack’s ripemd160.cuh for clues—tweaking byte orders and round functions—but I’m still stuck.

Would you be willing to share how you’ve implemented RIPEMD-160 in CUDA? I’d love to see a working ripemd160_gpu.cu

Both of those hashes are incorrect. Why don't you simply print the inputs to debug where the problem is?
For example to check if the SHA output is correct (I assume it's not):

Code:

if (!(threadIdx.x || blockIdx.x)) printf("%08lx %08lx %08lx %08lx\n", buf[0], buf[1], buf[2], buf[3]);

RIPEMD-160 has a 64 byte input (16 uint32) but you need to change the endianness of the four ints that form the SHA.

[Desyationer]

I'm not a programmer at all — the AI writes all the code for me. But it still couldn't give me a clear answer to my question: is it possible to iterate through private keys within a given range while instantly filtering out "unreliable" keys, without affecting the speed of the iteration itself? Or does the CUDA architecture require a strictly linear brute-force approach with no filtering, in order to maintain high performance — making any real-time filtering too resource-heavy due to the sheer size of the keyspace? I couldn't even implement this in Python with the help of the AI: writing a basic key iterator is easy, but as soon as I add even the simplest filter, the script stops working properly. Despite many attempts, I couldn’t get anywhere with the AI's help.

For example, if we start scanning a range from 0x10000000000 to 0x1FFFFFFFF, it's obvious that many keys like 0x100000001, 0x10001002, and so on are extremely unlikely to be "golden" keys. So applying a filter to aggressively exclude clearly implausible keys could potentially reduce the effective range by up to 30%.

[AlanJohnson]

I'm not a programmer at all — the AI writes all the code for me. But it still couldn't give me a clear answer to my question: is it possible to iterate through private keys within a given range while instantly filtering out "unreliable" keys, without affecting the speed of the iteration itself? Or does the CUDA architecture require a strictly linear brute-force approach with no filtering, in order to maintain high performance — making any real-time filtering too resource-heavy due to the sheer size of the keyspace? I couldn't even implement this in Python with the help of the AI: writing a basic key iterator is easy, but as soon as I add even the simplest filter, the script stops working properly. Despite many attempts, I couldn’t get anywhere with the AI's help.

For example, if we start scanning a range from 0x10000000000 to 0x1FFFFFFFF, it's obvious that many keys like 0x100000001, 0x10001002, and so on are extremely unlikely to be "golden" keys. So applying a filter to aggressively exclude clearly implausible keys could potentially reduce the effective range by up to 30%.

I was thiniking about it too.  But after some checking it turned out it won't help you much. The range still remains enormous.

[Bram24732]

I'm not a programmer at all — the AI writes all the code for me. But it still couldn't give me a clear answer to my question: is it possible to iterate through private keys within a given range while instantly filtering out "unreliable" keys, without affecting the speed of the iteration itself? Or does the CUDA architecture require a strictly linear brute-force approach with no filtering, in order to maintain high performance — making any real-time filtering too resource-heavy due to the sheer size of the keyspace? I couldn't even implement this in Python with the help of the AI: writing a basic key iterator is easy, but as soon as I add even the simplest filter, the script stops working properly. Despite many attempts, I couldn’t get anywhere with the AI's help.

For example, if we start scanning a range from 0x10000000000 to 0x1FFFFFFFF, it's obvious that many keys like 0x100000001, 0x10001002, and so on are extremely unlikely to be "golden" keys. So applying a filter to aggressively exclude clearly implausible keys could potentially reduce the effective range by up to 30%.

I will try to answer in a non programmer friendly way. Let me know if I go too technical.
CUDA is designed to work with GPUs in blocks of 32. So if you don’t need one of those 32 keys, you still need to wait for the “legit” keys to be processed before starting the next batch of 32. You might as well use this time to do the actual calculation instead of leaving the core idle.

That’s not to say you can’t code your idea efficiently in CUDA though. But you need to think a little about it.
You would need to order keys in a way that all the “bad” keys are at the end of the range, and all “good” keys are up front. This way you only have “good” and “dense” 32 keys blocks which are executed in full without losing speed.

[nomachine]

is it possible to iterate through private keys within a given range while instantly filtering out "unreliable" keys, without affecting the speed of the iteration itself?

NO. No, it’s not possible to pre-filter or skip private keys in a meaningful way that speeds up Bitcoin private key brute-forcing.

Every integer in the range [1, n–1] (where n is the SECP256K1 curve order) is a valid private key. There’s no cryptographic method to predict whether a key will generate a used or empty address without fully computing its public key and address.

There is no "magic circle" or remote viewer who can predict this. Even if you were God the Father, you couldn’t bypass the mathematics.

There’s no mathematical shortcut to determine which keys will map to specific address patterns without performing the full computation.

All operations must be performed modulo n (where n is the curve order). The mod p operation (for SECP256K1) must be applied to every candidate—this is non-negotiable for valid elliptic curve cryptography (ECC) operations.

The relationship between input numbers and their reduced forms is non-linear.

The real computational bottleneck isn’t in checking keys but in the elliptic curve multiplication (ModMulK) required to derive public keys from private keys.

Even with highly optimized libraries like SECP256K1, you’re limited to roughly 6 million keys per second per CPU core (e.g., using Cyclone) on high-end hardware

[Akito S. M. Hosana]

is it possible to iterate through private keys within a given range while instantly filtering out "unreliable" keys, without affecting the speed of the iteration itself?

NO.....

Even if you were God the Father, you couldn’t bypass the mathematics.

The real computational bottleneck isn’t in checking keys but in the elliptic curve multiplication (ModMulK) required to derive public keys from private keys.

So it’s futile for me to pray to God to guess the puzzle. Without an accelerated ModMulK, is there really nothing that can be done? 

[nomachine]

So it’s futile for me to pray to God to guess the puzzle. Without an accelerated ModMulK, is there really nothing that can be done? 

To speed up ModMulK, you generally have a few options. There is no new math available that could solve this.

If the algorithm is already near-optimal (e.g., using Montgomery reduction), then hardware is the only way to go faster.

Rewriting ModMulK in assembly can improve performance, but only if the compiler’s output is suboptimal (e.g., missed register allocations, unnecessary spills, bugs).

Example:

Code:

modMulK:  
    mov rax, rdi        ; x  
    mul rsi             ; x * K (rdx:rax = full product)  
    mov rcx, rdx        ; high bits  
    shld rdx, rax, 64   ; prepare for reduction  
    ; ... Montgomery steps ...  
    ret  

Replacing div with Montgomery/Barrett Can Give a 5–10x Speedup. These methods replace division with multiplications, shifts, and additions, which are much faster (often 1-5 cycles per operation).

However, if the compiler already used Montgomery or Barrett reduction, the improvement might be smaller—perhaps just 10–20% from fine-tuning.

You can also exploit CPU-specific features like AVX-256/AVX-512, carry-less multiplication, or fused operations—similar to techniques used in Cyclone.

Alternatively, 3,000 GPUs would indeed speed things up—assuming you have enough money to throw it out the window with a shovel. Therefore, you should already be rich enough to participate in this puzzle.

This is the "brute-force" approach—scaling horizontally with hardware and a lot of cash.

[JackMazzoni]

How to compile https://github.com/RetiredC/RCKangaroo for windows?

[Akito S. M. Hosana]

you should already be rich enough to participate in this puzzle.

So, honestly speaking, this puzzle was made by a rich person for rich people—the rich will get richer, and the poor will get poorer. Right?   

[nomachine]

you should already be rich enough to participate in this puzzle.

So, honestly speaking, this puzzle was made by a rich person for rich people—the rich will get richer, and the poor will get poorer. Right?   

Yep... Or maybe you manage to use vast.ai for free by hacking their system—exploiting 3,000 GPUs, stolen credit cards, or even the puzzle creator himself, as you’ve already written somewhere. The problem is, you could end up in prison. It’s better to just go fishing.

[Akito S. M. Hosana]

you should already be rich enough to participate in this puzzle.

So, honestly speaking, this puzzle was made by a rich person for rich people—the rich will get richer, and the poor will get poorer. Right?   

Yep... Or maybe you manage to use vast.ai for free by hacking their system—exploiting 3,000 GPUs, stolen credit cards, or even the puzzle creator himself, as you’ve already written somewhere. The problem is, you could end up in prison. It’s better to just go fishing.

Do you really think these puzzles are solved fairly? With savings? Who even has that much in savings? Come on! 

[nomachine]

you should already be rich enough to participate in this puzzle.

So, honestly speaking, this puzzle was made by a rich person for rich people—the rich will get richer, and the poor will get poorer. Right?   

Yep... Or maybe you manage to use vast.ai for free by hacking their system—exploiting 3,000 GPUs, stolen credit cards, or even the puzzle creator himself, as you’ve already written somewhere. The problem is, you could end up in prison. It’s better to just go fishing.

Do you really think these puzzles are solved fairly? With savings? Who even has that much in savings? Come on! 

Here at my place, you can borrow plenty of money from the mafia. The problem is, if you don't pay it back, you'll end up missing some body parts or family members. It’s better to just go fishing.