Bitcoin puzzle transaction ~32 BTC prize to who solves it

[kind_user]

pscamillo you killed the forum with your software. If you want to give assistance to the noobs, please make a thread on your github...

[BlackAKAAngel]

I have AMD 9950X and RTX 4090 and I am getting 0 Gkeys/s both plain and with -allwild 1, something is not right. I've put "89" instead of "120" in the right place. Can I solve this?

Hi pbies, thanks for trying it out.
 
0 GKeys/s usually means the CUDA kernel isn't launching. A few things to check:
 
1. Make sure you rebuilt after changing the arch. Clean build:

Code:

make clean && make GPU_ARCH="-gencode=arch=compute_89,code=sm_89"

2. Check that your CUDA toolkit version supports sm_89. You need CUDA 12.0+ for Ada Lovelace. Run:

Code:

nvcc --version

3. Verify the GPU is detected. The banner should show your RTX 4090 with "cap 8.9". If it shows a different capability, the arch is wrong.
 
4. Can you share the full output from startup? The banner + first few lines will help me diagnose what's happening.
 
If you were able to run the original RCKangaroo on the same machine, then it's likely just the arch setting. Let me know!

Yep, I did that. Clean build, CUDA 13.2, GPU is seen but "no kernel image is available for execution on the device".

Images (EDITED the post!):

https://ibb.co/7drY4DRm
https://ibb.co/LXFBB4L8
https://ibb.co/9m5xYKtQ

Commands:

pip install --upgrade torch --extra-index-url https://download.pytorch.org/whl/cu126

sudo apt install nvidia-cuda-toolkit

didn't help.

try with a small DP 16, 18 if not work 22, 25

[pbies]

Yep, I did that. Clean build, CUDA 13.2, GPU is seen but "no kernel image is available for execution on the device".

I can see the issue in your screenshots. Your GPU is detected correctly (RTX 4090, cap 8.9, CUDA 13.1/13.2), but the kernel binary was compiled for the wrong architecture.
 
The error cuSetGpuParams failed: no kernel image is available for execution on the device means the .cu file was compiled for sm_120 (Blackwell) but your GPU needs sm_89 (Ada Lovelace).
 
Please try this exact sequence — all on the command line, don't edit the Makefile:

Code:

make clean
make GPU_ARCH="-gencode=arch=compute_89,code=sm_89"

During compilation, look for this line in the output:

Code:

--gpu-architecture=compute_89

If you see compute_120 instead, the override isn't working. In that case, edit the Makefile directly — change line 24:

Code:

GPU_ARCH ?= -gencode=arch=compute_89,code=sm_89

Then:

Code:

make clean && make

The key thing is that all .o files must be deleted before recompiling. If even one old object file remains, the linker will use the wrong kernel image.

Make clean did the trick. I think there were .o files with 120. Now it is working with 7.56-7.71 Gkeys/s.

[Realman121]

Hi !
Can somebody tell me how got the 1 key with point G that is constant of ECDSA.
I read that it was brute force.
I've just started to think about this. And here's many interesting things in this numbers.
 
I'm sorry for my question, how you get 0.72%?
 
p = 2**-51
n = 2**48
 
P(X≥2)=1−P(0)−P(1) ≈ 0.72%
 
Sorry, I'm just starting to learn about this topic. And can do some mistake.
For example.
 
51 mod p = 0.627450980392156862745098
1/1.59375
1.59375
1 19/32     1 19/32 - 1 5/8
 
32/51  16/25.5   8/12.75  4/6.375  2/3.1875  
 
51/32 = 1.59375 (=1.98)
408/256 255/160 204/128 153/96 102/64 51/32
51/32 (1; 1,2,6)
 
51/32 25.5/16 12.75/8 6.375/4 3.1875/2 1.59375/1 0.796875/0.5 0.3984375/0.25 0.19921875/0.125 0.099609375/0.0625
1/16=0.0625 0.5^4 1/2^4 6.25%
 
0.0625 = 0.0625/1 0.125/2 0.25/4 0.5/8 1/16 2/32 3/48 4/64 8/128 16/256
1,59375/2=0.796875 (0.474250137805938720703125) (121.4080352783203125 79.6875 79.98 )
just 79.98......
 
121.74375=79.BE6
 
32.90/256=0.128515625 (0.20E6666666666666666666666 0.E6666666666666666666666 0.9)
32.9/255=0.12901960784313725490196078431373
 
32.896/256=0.1285 (0.20E5604189374BC6A7EF9DB23 0.E5604189374BC6A7EF9DB23 0.896)
32.896/255=0.12900392156862745098039215686275
 
1/255 = 0.0(0392156862745098)
 

16-10-22
32-20-50
64-40-100
128-80-296
256-100-598
10=2
100=4
1000=8
60-96-3C-150
60-96-69-45-2d
0.1=1/10=0.199999999999999999999999A=0.0625=1/16=0.5/8=0.25/4=0.125/2=0.0625


48 mod n = 0.9791 (6)
pub key = 032B9434EB24870CE4643966C2C976B6373C864E99EFBC87AD8B0586EE3180B643 (97.9166%)
 
145D08D23DFA2741D5 = 75/60 = 57/96 = 0.59375 (0.98) 0.34850025177001953125 1E3A42941509F0765
 
1/2=0.5 (50.0000%) 0.5*2=G
pubkey     0300000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63
                0200000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63
 
1/3=0.(3)  
3 mod n = 0.(6) 66.6666% (2/3)
we have
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA9D1C9E899CA306AD27FE1945DE0242B81 (0.(6)
pubkey     034c7ff4f2ba8603998339c8e42675ceac23ef2e9623fdb260b24b1c944a2ea1a9
2/3*0.5= 0.(3)    
55555555555555555555555555555554E8E4F44CE51835693FF0CA2EF01215C0 (0.(3) pubkey 024c7ff4f2ba8603998339c8e42675ceac23ef2e9623fdb260b24b1c944a2ea1a9 (33.3333%)


0.5/0.75*0.75 we get point 0.5
0.5/0.75*0.75*2=1
maybe it has many solution but I find just 1

what about 0.1378 0.0760498046875 4c 31 80=50=0.5=0.8=128 or just 8 468-0.75=467.25 1d3.4 or smthing else)

mod p
10 = 0.3 (4CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC7FFFFEDB) - 30.0000%
100 = 0.73 (BAE147AE147AE147AE147AE147AE147AE147AE147AE147AE147AE146F333306A) 73.0000%
1000 = 0.273 (45E353F7CED916872B020C49BA5E353F7CED916872B020C49BA5E353B1EB8414) 27.3000%
and so on)
 
I think we have mixed (combinated) measurement system.
 
key 65 1a838b13505b26867 30568377312064202855
 
mod p
650 = BA4A0B0716D7D3E3A4A0B0716D7D3E3A4A0B0716D7D3E3A4A0B0716CC2F42C7C
 
0.BA4A0B0716D7D3E3A4A0B0716D7D3E3A4A0B0716D7D3E3A4A0B0716CC2F42C7C
0.7276923076923076923076923
 
650 mod  p / 60 =1404350210493604113726899382284855908066582121714050943350344544506176379479.4
31AD584628398DD64E08B795B6CC109813BEAC8E9FF43CB46F1DFC1D00C9A57.666666666666666 6666666666
31AD584628398DD64E08B795B6CC109813BEAC8E9FF43CB46F1DFC1D00C9A57
1404350210493604113726899382284855908066582121714050943350344544506176379479
72,7692%
key ba4a0b0716d7d3e3a4a0b0716d7d3e3a4a0b0716d7d3e3a4a0b0716cc2f42c29 - ba4a0b0716d7d3e3a4a0b0716d7d3e3a4a0b0716d7d3e3a4a0b0716cc2f42c64
946/13=72.769230769230769230769230769231
1/13=0.07692307692307692307692307692308 0.13B13B13B13B13B13B13B85F7

and what about this key
0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
0.0044444444444444443866203

pubkey
034646ae5047316b4230d0086c8acec687f00b1cd9d1dc634f6cb358ac0a9a8fff
0.4444%
0.0044444444444444443866203=1/960=0.0010416666666666666666568=0.000248038768768310546875=0.0010416666666666666666666
0.0000000000000000003866203=0.0000000000000000000000467=1d3
 
I will try my research... I just want to understand idea )

[vneos]

Found some interesting things 

https://mempool.space/zh/testnet4/tx/91f8ed8de613e3f22dcb2047d443a509aa3aba9654741f62b4ff8d8e84dda904

[marmaria]

Found some interesting things 

https://mempool.space/zh/testnet4/tx/91f8ed8de613e3f22dcb2047d443a509aa3aba9654741f62b4ff8d8e84dda904

Care to explain? lol

[pscamillo]

Thanks Cricktor for the question — sorry for the late reply, I wanted to have real numbers before answering.

PSCKangaroo v59 — now with concurrent mode and real benchmarks.

First: kTimesG's feedback was correct. Endomorphism, cheap second point, and XDP were all removed in v57 — none of them helped. The current version focuses on what actually matters for long runs: memory management, crash resilience, and compact storage.

Benchmark: PSC v59 vs RCKangaroo v3.1
Hardware: RTX 5070 / Ryzen 9800X3D / 128 GB RAM / CUDA 12.9 / Linux
Puzzle 80 (79-bit range), 5 runs each:

Code:

Solver                         Median   Mean    Best    Worst   Solved
RCKangaroo DP=16                301s    299s    120s     514s    5/5
PSC v59 concurrent DP=12 8GB    320s    463s    236s     837s    5/5
PSC v59 concurrent DP=14 20GB   423s    536s    142s    1223s    5/5

RC wins by ~6% on median — expected, SOTA K=1.15 is mathematically optimal. Both run the same GPU kernel at ~3.1 GK/s.

So is there a significant advantage?

Not for Puzzle 80 — RC is slightly faster and has zero setup overhead. For short puzzles, use RCKangaroo.

The advantage shows up for long-running puzzles (135+):

1. -ramlimit: RC has no memory limit. On a 128 GB system it OOM-crashes in ~4h at DP=14, ~18h at DP=16, ~12 days at DP=20 (verified from RC source, line 328: (32+4+4) bytes/entry, malloc without NULL check). For safe multi-month runs, RC needs DP≥24.

2. Checkpoint/resume: PSC auto-saves every N hours + on Ctrl+C. RC's -tames feature saves pre-generated TAMEs but not solve progress — a crash during solving loses all WILDs and accumulated state.

3. 16-byte entries: 2.5× more DPs per GB vs RC's ~40 bytes/entry. This allows lower DP values within the same RAM budget.

4. Concurrent mode (v59): runs 33% TAME + 67% WILD from second 1 (same t² dynamics as RC), but with memory protection. Earlier versions had a slow TRAP phase — that’s gone now.

To be honest about the math: Puzzle 135 needs ~2^67 operations — roughly 1,740 years on a single RTX 5070. No solver changes that. We're all playing a probabilistic lottery. PSCKangaroo just makes sure no ticket is wasted by a crash or reboot.

Code: https://github.com/pscamillo/PSCKangaroo
README has the full analysis including OOM timings and mathematical reality of large puzzles.

Update: Windows support added — Visual Studio 2022 project files (.sln/.vcxproj) now included in the repo.

Questions, bug reports or suggestions → GitHub Issues: https://github.com/pscamillo/PSCKangaroo/issues
This way we keep the forum clean.

[brainless]

Thanks Cricktor for the question — sorry for the late reply, I wanted to have real numbers before answering.

PSCKangaroo v59 — now with concurrent mode and real benchmarks.

First: kTimesG's feedback was correct. Endomorphism, cheap second point, and XDP were all removed in v57 — none of them helped. The current version focuses on what actually matters for long runs: memory management, crash resilience, and compact storage.

Benchmark: PSC v59 vs RCKangaroo v3.1
Hardware: RTX 5070 / Ryzen 9800X3D / 128 GB RAM / CUDA 12.9 / Linux
Puzzle 80 (79-bit range), 5 runs each:

Code:

Solver                         Median   Mean    Best    Worst   Solved
RCKangaroo DP=16                301s    299s    120s     514s    5/5
PSC v59 concurrent DP=12 8GB    320s    463s    236s     837s    5/5
PSC v59 concurrent DP=14 20GB   423s    536s    142s    1223s    5/5

RC wins by ~6% on median — expected, SOTA K=1.15 is mathematically optimal. Both run the same GPU kernel at ~3.1 GK/s.

So is there a significant advantage?

Not for Puzzle 80 — RC is slightly faster and has zero setup overhead. For short puzzles, use RCKangaroo.

The advantage shows up for long-running puzzles (135+):

1. -ramlimit: RC has no memory limit. On a 128 GB system it OOM-crashes in ~4h at DP=14, ~18h at DP=16, ~12 days at DP=20 (verified from RC source, line 328: (32+4+4) bytes/entry, malloc without NULL check). For safe multi-month runs, RC needs DP≥24.

2. Checkpoint/resume: PSC auto-saves every N hours + on Ctrl+C. RC's -tames feature saves pre-generated TAMEs but not solve progress — a crash during solving loses all WILDs and accumulated state.

3. 16-byte entries: 2.5× more DPs per GB vs RC's ~40 bytes/entry. This allows lower DP values within the same RAM budget.

4. Concurrent mode (v59): runs 33% TAME + 67% WILD from second 1 (same t² dynamics as RC), but with memory protection. Earlier versions had a slow TRAP phase — that’s gone now.

To be honest about the math: Puzzle 135 needs ~2^67 operations — roughly 1,740 years on a single RTX 5070. No solver changes that. We're all playing a probabilistic lottery. PSCKangaroo just makes sure no ticket is wasted by a crash or reboot.

Code: https://github.com/pscamillo/PSCKangaroo
README has the full analysis including OOM timings and mathematical reality of large puzzles.

Questions, bug reports or suggestions → GitHub Issues: https://github.com/pscamillo/PSCKangaroo/issues
This way we keep the forum clean.

1740 years for 1 gpu 5090
Rc found 125 and 130 when 5090 not exist, maybe 4090 used
Could u calc how much gpu he used? Within 3month he claimed to solve ?