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 ?

[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.

[NUCLEAR7.1]

I saw everyone talking again about Adam Back. Do you think he is the creator?   

[NotFuzzyWarm]

I saw everyone talking again about Adam Back. Do you think he is the creator?  

That is off topic.
Any particular reason you did not post in the correct thread here?

[XGiftGodX]

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.

Can you help me setup and tweak my laptop to use your program?


+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 595.58.02              Driver Version: 595.97         CUDA Version: 13.2     |
+-----------------------------------------+------------------------+----------------------+
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA GeForce RTX 3050 ...    On  |   00000000:01:00.0 Off |                  N/A |
| N/A   35C    P0             14W /   60W |       0MiB /   4096MiB |      0%      Default |
|                                         |                        |                  N/A |
+-----------------------------------------+------------------------+----------------------+

+-----------------------------------------------------------------------------------------+
| Processes:                                                                              |
|  GPU   GI   CI              PID   Type   Process name                        GPU Memory |
|        ID   ID                                                               Usage      |
|=========================================================================================|
|  No running processes found                                                             |
+-----------------------------------------------------------------------------------------+

GPU 0

   AMD Radeon(TM) Graphics

   Driver version:   31.0.21921.13001
   Driver date:   7/7/2025
   DirectX version:   12 (FL 12.1)
   Physical location:   PCI bus 5, device 0, function 0

   Utilization   2%
   Dedicated GPU memory   0.4/2.0 GB
   Shared GPU memory   0.2/6.9 GB
   GPU Memory   0.5/8.9 GB

GPU 1

   NVIDIA GeForce RTX 3050 Laptop GPU

   Driver version:   32.0.15.9597
   Driver date:   3/17/2026
   DirectX version:   12 (FL 12.2)
   Physical location:   PCI bus 1, device 0, function 0

   Utilization   0%
   Dedicated GPU memory   0.0/4.0 GB
   Shared GPU memory   0.0/6.9 GB
   GPU Memory   0.0/10.9 GB

[icqcointokenwallet]

I use different GPU rentals.  Will the latest Cuda 13.0 work with all Cuda capabilities, even legacy?

[SecretAdmirere]

I use different GPU rentals.  Will the latest Cuda 13.0 work with all Cuda capabilities, even legacy?

CUDA 13.x supports all Turing and newer (from 16, 20-series and above), while CUDA 12.9 is the last CUDA version that supported Maxwell, Volta and Pascal. The support mainly affects the build process (offline compiling), you can't directly compile for compute capability < 7.5 using CUDA 13.x, but your program might still run on compute capability < 7.5 thanks to the driver Just-In-Time (JIT) even tho you didn't compile for legacy compute capability but most likely it won't. I would recomend you to go with CUDA 12.x version if you are worried about compability

Edit: No it won't run, if you compile for eg. 8.6 it's not going to run on 6.1, it's forward compatable not backward. My mistake

[blankx4729]

================================================================================

 🦘 PSCKangaroo  — GPU-accelerated Pollard's Kangaroo for secp256k1 ECDLP

  Fork of RCKangaroo by RetiredCoder (RC)
  Original: https://github.com/RetiredC/RCKangaroo
  Special thanks to RC for SOTA!
  License:  GPLv3

================================================================================

  Core algorithm:  SOTA (Equivalence Classes + Negation Map, K~1.15)
  Optimizations:   SOTA+ | ALL-TAME mode | 16-byte compact entries | Async BSGS
                   Ultra-compact 16-byte DPs | Async BSGS resolver
                   Dual hash table | Table freeze | Uniform jumps
  Modes:           ALL-TAME (recommended 130+ bits) | ALL-WILD | TRAP/HUNT
  Checkpoint:      Auto-save + Ctrl+C safe exit (format RCKDT5C)

  Platform: Linux

CUDA devices: 1, CUDA driver/runtime: 13.0/12.5
GPU 0: NVIDIA GeForce GTX 1060 6GB, 6.00 GB, 10 CUs, cap 6.1, PCI 1, L2 size: 1536 KB
GroupCnt: 24, Kangaroos per GPU: 294912 (1.0x default)
Total GPUs for work: 1
Target:
X: 145D2611C823A396EF6712CE0F712F09B9B4F3135E3E0AA3230FB9B6D08D1E16
Y: 667A05E9A1BDD6F70142B66558BD12CE2C0F9CBC7001B20C8A6A109C80DC5330
Offset: 0000000000000000000000000000004000000000000000000000000000000000

========================================================================
TameStore v58 ALL-TAME + W-W BUFFER (SOTA HYBRID)
========================================================================
  Config: Occupancy=1, GroupCnt=24
  RAM limit: 18.0 GB
  TAME table: 1115553792 entries (16.6 GB) [16 bytes/entry]
  W-W buffer: 58712064 entries (0.87 GB) [5% of RAM]
  Strategy: T-W from TAME table + W1-W2 from W-W buffer (SOTA hybrid)
  Expected K improvement: ~2.0 → ~1.5 (25% fewer ops needed)
  NOTE: Uses BSGS (~400ms) to resolve truncated distances on collision.
  Spatial buckets: 65536
========================================================================
  W-W buffer: allocated OK (58712064 entries)
TameStore ALL-TAME + W-W BUFFER: Ready!
Table freeze: ENABLED (tables become read-only when full, no FP explosion)

*** LOADING CHECKPOINT: wild_checkpoint.dat ***
*** CHECKPOINT LOADED (tables_present: 1) ***
    W1/TAMEs: 194792080 entries
    W2: not saved (ALL-TAME mode)
Checkpoint loaded! Table[0]: 194M / 1115M (17.5%)
  TRAP will resume from 17.5% (need 93% to switch to HUNT)

Auto-checkpoint enabled: Every 1 hours to 'wild_checkpoint.dat'
Press Ctrl+C to save checkpoint and exit safely (works in TRAP and HUNT).


Solving point: Range 134 bits, DP 13

Strategy: CONCURRENT (v59 — RC-style t² growth)
  GPU split: 33% TAME + 33% WILD1 + 33% WILD2 from second 1
  TAMEs stored → table grows while WILDs hunt simultaneously
  Collision probability grows with t² (quadratic) until table full
  Est. table fill: 0.1 days (then switch to 100% WILDs)
  W-W buffer: 5% RAM (T-W + W1-W2 collisions)
  Advantage: t² growth + ramlimit + checkpoint + 16-byte entries

GPU 0: allocated 1010 MB, 327680 kangaroos. OldGpuMode: Yes
CONCURRENT MODE (v59): Starting with 33% TAME + 67% WILDs...
  TAMEs build table while WILDs hunt — t² collision growth!
GPUs ready for CONCURRENT operation!

Started 12 worker threads for LOCK-FREE processing
Precomputing BSGS baby table (131072 entries)...
BSGS baby table ready: 131072 entries, giant range +/-2^32, built in 587 ms
BSGS async resolver: STARTED (4 threads, queue max=262144, precomputed baby table)

CONC: Speed: 0.19 GKeys/s | Time: 0d 00h 58m
  TAMEs: 219M / 1115M (19.6%) | +7609 TAMEs/s
  WILDs: 48M checks | T-W: 7 | W-W: 10 | FP: 34 | 13.8K/s
  W-W buffer: 48M stored, 10 W1-W2 hits
  BSGS [4 thr]: 0 pending, 17 processed, 0 dropped                i dont know what i am doing but for p80 on a gtx 1060 it took ~6Hours to fiind key not 2 minutes , just curios here after this .dat file completes what are chances of me fiinding the priv key with 1.1B "traps" in a timeframe of a year for p135 ? less than 5% ?

[SecretAdmirere]

i dont know what i am doing but for p80 on a gtx 1060 it took ~6Hours to fiind key not 2 minutes , just curios here after this .dat file completes what are chances of me fiinding the priv key with 1.1B "traps" in a timeframe of a year for p135 ? less than 5% ?

You are correct, chance is indeed less then 5%, but i would highly reccomend you unsubscribe from ChatGPT and use that money towards something more productive. Also you can research a little bit on the "coin fliping" method recently discovered at MIT that would be much more effective to what ever that program is. It requires few basic components to run and does not incrise your electrical bill, the requirement is as follows: pen, paper, coin, strong enough hand to flip the coin 135 times. Heads = 1, tails = 0, flip it 135 times, write down the bits after each flip, then calculate privkey -> pubkey -> sha256 -> ripemd160. Joke aside, don't, just don't waste SSD lifetime on this, what ever it even is.

[blankx4729]

  thank you for reply , and you are right feels like a waste of hardware and time but is also a great way of learning more about how things work and all of that , even if i won't find the key to puzzle as a tech enthusiast i find this interesting