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 ?

[pscamillo]

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 ?

Quick math:

Puzzle 125 (124-bit range): ~1.15 × 2^62 = ~5.3 × 10^18 ops expected
Puzzle 130 (129-bit range): ~1.15 × 2^64.5 = ~2.6 × 10^19 ops expected

At 8 GK/s per RTX 4090:

Code:

Puzzle   Expected time (1 GPU)   GPUs needed for 3 months
  125         ~21 years                ~84 GPUs
  130        ~106 years               ~424 GPUs

But that's at K=1.15 (average luck). Pollard's Kangaroo is probabilistic — you can solve it at any moment. RC's actual K values could have been much lower:

Code:

  K       Luck factor    130 in 3 months
 1.15     average             ~424 GPUs
 0.50     lucky (2.3x)        ~184 GPUs
 0.20     very lucky (5.75x)   ~74 GPUs
 0.05     extreme luck (23x)   ~18 GPUs

From RC's own benchmark mode on Puzzle 78, he got K=0.47 and K=0.59 in two consecutive runs — both well below 1.15. That's normal variance.

Actual timeline (from blockchain):
- Puzzle 125 (124-bit): solved July 2023, ~4 months after #120
- Puzzle 130 (129-bit): solved Sept 2024, ~14 months after #125

Community estimates suggest >100 GPUs. RC never gave a precise count, but reportedly kept the same farm and shifted DPs between puzzles.

That's also why some of us keep running with a single GPU. Every kangaroo hop is a lottery ticket.

[Realman121]

Found some interesting things  

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

Hi

and if it can help

0.001 pubkey  02 79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 (1) 1 dec
0.004 pubkey  03 f28773c2d975288bc7d1d205c3748651b075fbc6610e58cddeeddf8f19405aa8 (d) 13 dec
0.005 pubkey  02 9248279b09b4d68dab21a9b066edda83263c3d84e09572e269ca0cd7f5453714 (19) 25 dec
0.006 pubkey  03 d30199d74fb5a22d47b6e054e2f378cedacffcb89904a61d75d0dbd407143e65 (20) 32 dec
0.007 pubkey  02 078c9407544ac132692ee1910a02439958ae04877151342ea96c4b6b35a49f51 (77) 119 dec

0.002 pubkey  02 f9308a019258c31049344f85f89d5229b531c845836f99b08601f113bce036f9 (3) 3 dec

0.003 pubkey  03 fff97bd5755eeea420453a14355235d382f6472f8568a18b2f057a1460297556 (6) 6 dec
0.008 pubkey  02 ee163026e9fd6fe017c38f06a5be6fc125424b371ce2708e7bf4491691e5764a (c5) 197 dec

as I say in another topic about "the Secp256k1 elliptic curve"
Maybe we have "reversed" the measurement systems in the code and got the G-point (just maybe)
Or just the 'code'
So...
2 -10-A-16 or 10 (dec) or 10-1 or 10-1010
3 -11-B-17 11 (dec) 11-2 11-1011 or 11 (dec) 11*11-121 (G)? 1111-BB (BB hex or binary?) 1111-1717  1111-2731-6f1-1273-16f-4369-457-f-10001010111 1111-33-71-17 1111-4-22-112
4-100-A0-160-256 100 (dec) 100-64 100-20 100-1 100-1100100
5-101-A1-161-257 101 (dec) 101-65 101-21 101-2 101-1100101
6-110-B0-170-272 110 (dec) 110-6e 110-30 110-12 110-2 110-1101110    110-116
7-111-B1-171-273 111 (dec) 111-6f 111-31 111-13 111-3 111-1101111    111-117 111-1B
8-1000-A00-1600-4096 1000 (dec) 1000-3e8 1000-200 1000-40 1000-2560 1000-640 1000-1111101000 1000-1
9-1001-A01-1601-4097 1001 (dec) 1001-3e9 1001-201 1001-41 1001-2561 1001-641 1001-1111101001  1001-2


2-10 10-1001
3-11 11-1111
4-100 100-100001
5-101 101-101101
6-110 110-110011
7-111 111-111111

and so on...
may be it can be in another way


and how
1-1
2-10
3-11
7-111

can help

I'm sorry again for my English, it's hard to find the words I mean.
I want to understand this 'puzzle'
And 'masking idea'.
and want try to see is the eleptic curve Real or Fake and we have only the code.
Or maybe we have combined system.
Maybe it's just FACE.
I haven't decided what to think yet 50/50.
Cause I need to do some experiment with the curve and numbers.
But maybe I mistake in my thoughts.
And A not rA
like 1001

[r3cruit]

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.

Why are you doing such tests? Why not take the path of developing new software? At the moment, my kangaroo solves 61 puzzles in 1250 seconds. Only I have a very budget 1050ti mobile video card. Testing data

  Performance:
    Time:       1275.0s
    Positions:  85683339264
    Keys:       359381972608352256
    renameParam compares:2741866856448
    Speed:      67.2 Mpos/s
    Speed:      281864955.5 Mkeys/s equiv

P.S. The source code will not be published anywhere. If you think that speed is deceptive, I can offer a bet.

[0xastraeus]

If you're not going to post your project...don't talk about it.

pscamillo posted his and asked for feedback. He never claimed to be better than another project or the most complex project out there.
He accepted criticism from others and updated his project accordingly.

It's real tiring hearing how you people claim to have developed this wonder project, yet have nothing to back it.

Why are you doing such tests? Why not take the path of developing new software? At the moment, my kangaroo solves 61 puzzles in 1250 seconds. Only I have a very budget 1050ti mobile video card. Testing data

  Performance:
    Time:       1275.0s
    Positions:  85683339264
    Keys:       359381972608352256
    renameParam compares:2741866856448
    Speed:      67.2 Mpos/s
    Speed:      281864955.5 Mkeys/s equiv

P.S. The source code will not be published anywhere. If you think that speed is deceptive, I can offer a bet.