Bitcoin puzzle transaction ~32 BTC prize to who solves it

[Cricktor]

...

Please, stop posting irrelevant stuff in a thread where you apparently don't quite understand what it's all about. Read and understand before posting! You contribute to noise here, see below why.

Currently we (shit)talk about puzzle #71 (unknown public key) or puzzle #135 (with disclosed public key) which are the next unsolved ones. Therefore the context is mostly about those.

Here's the post from someone who claims to be the puzzle creator where he confirms that puzzle's private keys are masked deterministic keys to produce increasing but defined size bit ranges (which previous solvers assumed). So lower number puzzles have low entropy keys and bit range and entropy increases with higher numbers.
(It's fair to assume that the unmasked deterministic private keys have a constant high entropy if the generating wallet software was properly implemented. I would simply assume it's in the end a standardized BIP32 deterministic key derivation. BIP39 uses BIP32, but we don't know if the wallet was a BIP39 HD one or not based on BIP39 like it would be the case for a Bitcoin Core HD wallet.)

...
A few words about the puzzle.  There is no pattern.  It is just consecutive keys from a deterministic wallet (masked with leading 000...0001 to set difficulty).  It is simply a crude measuring instrument, of the cracking strength of the community.
...

So the private key of public address 1PWo3JeB9jdvp56gzG8navJjUMFQxxb997 is properly in the range of puzzle #71
Start 400000000000000000
Key   649a3dd0486c96e70b
End   7fffffffffffffffff
and all you wrote about "real, full bit range" private keys doesn't apply here.

[kind_user]

Sorry, but if you do not come with some proof that i speak boolshit, what you way is not relevant.

I told earlier that in 48 bits there is only one B9j, this means that you can exclude some ranges. So id there are 65 milions ranges of 44 bits, f you find some deterministic rules to exclude some of them you can search exact between ranges and probability is very high. I didn't come with SF ideeas, this is probabilistic true.

Anyone can prove me that exist two B9j in a 48 bits?

[Pac_Man]

Why everybody is stuck on BTC formula? Think out of the box!!!

For me the prefixes are helping a lot because i developed something that is giving me B9 in 8 of 10 ranges. The output is very acurate because not all the ranges contain B or B9. And depends the number of data i enter, as much as the result is more acurate.
I do not generate 44 bits and i use 40 bits instead for ranges.
My challenge was the distribution of keys and that's why i need so many keys to be more acurate. Now i do not use a LLM or AI but in future i will implement for faster search. I do not expect someone to believe what i say because everybody is stuck on BTC formula and the ireversible method.

Just to give everybody a hint: in a 48 bits you will not find two B9j, so you will stop searching there because you waste time.(this is from my database distribution and i hope i am not wrong). If anyone found two of B9j in a 48 bits range please tell me i am wrong, if not do not come with aberations....

I said exactly the same thing a few days ago and was also rudely criticized by someone who's only here to criticize others and try to take advantage of their work and research without ever having actually done anything of value.

My advice to you is this: continue doing the work and research you're doing because you're doing the right thing. It's by thinking outside the box that new things are discovered and built, just like Satoshi Nakamoto did. If he hadn't thought outside the box, Bitcoin wouldn't exist today.

Can you share all the data you've already gathered?

[Cricktor]

[PSCKangaroo] Fork of RCKangaroo — optimized for high-RAM + single GPU setups

Hi everyone,

I've been working on modifying RCKangaroo to get the most out of my specific hardware: an RTX 5070 paired with 128 GB of RAM. The original RCKangaroo is a brilliant piece of software — all credit to RetiredCoder for the SOTA algorithm — but I wanted to squeeze every bit of performance from my particular setup, where RAM is abundant but GPU is a single mid-range card.
...

It seems your post got burried by all the other noise. Thanks for the spirit and sharing of your code! My immediate question is: have you compared your code's efficiency to original RCKangaroo, maybe not only for puzzle #80? Is there any significant advantage with your own setup (single GPU, decent RAM size)?

...

Stop posting nonsense of stuff you have no clue of.

[kTimesG]

Sorry, but if you do not come with some proof that i speak boolshit, what you way is not relevant.

I told earlier that in 48 bits there is only one B9j, this means that you can exclude some ranges. So id there are 65 milions ranges of 44 bits, f you find some deterministic rules to exclude some of them you can search exact between ranges and probability is very high. I didn't come with SF ideeas, this is probabilistic true.

Anyone can prove me that exist two B9j in a 48 bits?

p = 2**-51
n = 2**48

P(X≥2)=1−P(0)−P(1) ≈ 0.72%

What proof do you want more? Scan a couple hundred ranges and you'll have your first 51-bit match inside of some whatever 48-bit "range" (whatever that means to you - the concept of a range does not exist for uniform distributions, as all events are independent). Congrats, now that you found it, then you can also go look for the other (tens / hundreds of) thousands lucky ranges that have this same property (all inside the 71's range, yes!).

The chances of finding some hash H, at any given step, is always equal to 1 in 2**160 no matter if you just found it at during the very previous hashed key, or never found it, or found it 500 times in a row. Any given 51 bits of a hash (like some prefix bits) is still a hash. Everything else is just post-factum observation.

You prefix guys should really make your own idiocracy social group. There are already a couple of very "capable" users here who would bet on their life of these absurdities, instead of consulting a mental therapist.

[EccMath]

Anyone can prove me that exist two B9j in a 48 bits?

Here you go, both are within 45 bit.

1PWo3JeB9YFTPQ7kKXU96TzwYdphNJ1Un3 - 0x6FA8A9807D4991ED36
1PWo3JeB9YF44UAhh11ysMBbD6dcmgBNdu - 0x6FA8A99F384A800898

[WanderingPhilospher]

Why everybody is stuck on BTC formula? Think out of the box!!!

For me the prefixes are helping a lot because i developed something that is giving me B9 in 8 of 10 ranges. The output is very acurate because not all the ranges contain B or B9. And depends the number of data i enter, as much as the result is more acurate.
I do not generate 44 bits and i use 40 bits instead for ranges.
My challenge was the distribution of keys and that's why i need so many keys to be more acurate. Now i do not use a LLM or AI but in future i will implement for faster search. I do not expect someone to believe what i say because everybody is stuck on BTC formula and the ireversible method.

Just to give everybody a hint: in a 48 bits you will not find two B9j, so you will stop searching there because you waste time.(this is from my database distribution and i hope i am not wrong). If anyone found two of B9j in a 48 bits range please tell me i am wrong, if not do not come with aberations....

I will tell you that you are wrong. If you are searching for 48 bit matches, there will be many matches inside a 48 bit range, throughout the 71 bit range. You can shrink a search range, but not by the size bit match you are looking for. And the problem is, no one can 100% tell you what is a safe jump distance to start your next search.

You say, find a 48 bit match, stop the search because there will not be another match within that 48 bit range? Then we get into, how are the ranges divided up...but you will find many, 48 bit matches, within less than a 48 bit "range" or 2^48 keys of each other. A safer way, to lessen how many 48 bit matches you miss/skip, is to reduce the skipping of keys/range size, down to like 2^32, 2^36, 2^40 keys/range size. But even those are not 100%; meaning you could still skip some x bit match prefixes you are searching for.

And I am not just shooting from the hip here. I've collected a lot of prefixes as proof of work; and I do believe you can skip keys after finding a match, but not 1 for 1 as you say. I would not skip 2^48 after finding a 48 bit match; I would skip like 2^32; and even then, as I said, it's still not 100% that another 48 bit match, won't be skipped.

But, I do come, bearing fruit, so you can't say, that I may be wrong.

Examples:

Code:

0x7F92587DD9BD019205 1PWo3JeB9jrpyPqE6SjTbwjLYKxKYUoJp5
0x7F92595314F527DF12 1PWo3JeB9jczFkr7HLQ6LAvdxzFoakobF6
0x7F9260E2D8A7024AA7 1PWo3JeB9jY2Sb7LsUmH1cX2YAKQjeYMWF
0x7F92619AE8B7316D0A 1PWo3JeB9jZc2WoMUx46FkZ4NMBzaHxC9s

If one found, the prefix at 0x7F92587DD9BD019205 and skipped ahead by 2^48 keys, how many matches would they have skipped?

Here you go, both are within 45 bit.

1PWo3JeB9YFTPQ7kKXU96TzwYdphNJ1Un3 - 0x6FA8A9807D4991ED36
1PWo3JeB9YF44UAhh11ysMBbD6dcmgBNdu - 0x6FA8A99F384A800898

Lol, you replied to his quote, "Anyone can prove me that exist two B9j in a 48 bits?" and came in with 2 1PWo3JeB9YF prefixes lol. Point is taken, but at least use examples he stated.

 

[pscamillo]

It seems your post got buried by all the other noise. Thanks for the spirit and sharing of your code! My immediate question is: have you compared your code's efficiency to original RCKangaroo, maybe not only for puzzle #80? Is there any significant advantage with your own setup (single GPU, decent RAM size)?

Hi Cricktor, thanks for taking the time to look at it — I appreciate the question.
 
Short answer on benchmarks: I don't have a proper apples-to-apples wall-clock comparison yet on the same puzzle. I validated correctness by solving Puzzle #80 (79-bit range), but didn't run the original RCKangaroo side-by-side on the same hardware. That's a fair gap — I should do it and publish numbers. I'll prioritize that.
 
What I can describe are the algorithmic changes in the GPU kernel, since that's where performance actually matters:
 
1. Endomorphism 6x canonical form (GPU-side)
Before the DP check, each X coordinate is reduced to its canonical form — the smallest of three equivalent values:

Code:

canonical = min(x, β·x, β²·x)   mod p

This is done branchless inside the CUDA kernel. Three equivalent points now map to the same Distinguished Point, effectively multiplying useful DP coverage by up to √3. No CPU involvement.
 
2. Cheap Second Point
When computing P + J (the kangaroo hop), the modular inverse is already available from batch inversion, so P − J comes almost for free:

Code:

Cost: 1 Add + 1 Mul + 1 Sqr + 2 Sub   (per group)

This doesn't alter the kangaroo's trajectory but generates a second DP candidate per hop, roughly doubling the DP output rate.
 
3. XDP (Extended Distinguished Points)
Instead of the standard single-pattern DP check:

Code:

Original:  (x >> shift) == 0          → accepts 1 pattern
PSC:       (x >> shift) <  XDP_MULT   → accepts N patterns (default N=8)

The DP rate increases 8x. More DPs per hop means faster collision detection, at the cost of more CPU-side processing — which is where the abundant RAM and multi-threaded CPU come in.
 
These three compound inside the kernel — every hop produces significantly more useful DP candidates than the original, without modifying the hop arithmetic itself.
 
Architecture changes (motivated by single GPU + 128 GB RAM):
 
• ALL-TAME mode: During TRAP phase, 100% of GPU kangaroos are TAME, filling all available RAM exclusively with TAME entries. During HUNT, all kangaroos switch to WILD and check against the stored TAMEs. No WILD storage needed — just streaming collision checks. This maximizes the TAME table size compared to the original's split TAME/WILD1/WILD2 allocation.
 
• Ultra-compact 16-byte entries (vs 25 bytes in the original): distance is truncated by 32 bits to save space, giving +56% capacity in the same RAM. The lost precision is recovered on collision via a precomputed Baby-Step Giant-Step table (~400ms per resolution).
 
• Async BSGS resolution on dedicated CPU threads while the GPU keeps hopping. The GPU never stalls waiting for collision verification.
 
Honest summary: raw hop speed per GPU cycle is essentially the same — I didn't modify RetiredCoder's core EC arithmetic, which is already SOTA. The advantage comes from (a) extracting more useful work per hop via endomorphism + cheap point + XDP, and (b) an architecture that lets a single GPU with abundant RAM build and exploit a much larger TAME table than the original design allows.
 
Whether that translates into a meaningful wall-clock advantage on a specific puzzle — I owe you actual numbers. I'll run a controlled comparison and report back.
 
Code: github.com/pscamillo/PSCKangaroo — the kernel diff against the original RCGpuCore.cu should make the changes easy to inspect.

[kTimesG]

1. Endomorphism 6x canonical form (GPU-side)

That's great if the ECDLP sits in a 254-bit interval, and slows down computations for anything below 254 bits. The endo points will never get hit, so computing or storing them is totally useless.
Also instead of two extra FE mul you can simply pick min(Y, -Y); or even faster: the odd (or even) Y.

2. Cheap Second Point
This doesn't alter the kangaroo's trajectory but generates a second DP candidate per hop, roughly doubling the DP output rate.

This is only useful for very very very small DPs, like maybe below 4 (don't expect more than 1% faster collisions though, it goes to a 0% ROI exponentially, as DP increases).
The second (cheap) DP point is useless to be stored, it will never get hit. If a collision occurs, it will hit the normal (main candidate) DP first and always.

3. XDP (Extended Distinguished Points)
The DP rate increases 8x. More DPs per hop means faster collision detection

It won't be faster, you are simply lowering the constant overhead. You can simply decrease the DP and get rid of "extended" checks, with the same end effect.

These three compound inside the kernel — every hop produces significantly more useful DP candidates than the original, without modifying the hop arithmetic itself.
 

It sounds like you are checking, generating and storing a lot of DPs that will never be of any use, while making the computations several times slower.

Maybe next time start off with a Python proof of concept, and you will understand why those DPs will never, ever, be of any use at all, unless DP = 0 (in which case, there is no need of DPs at all).

[kind_user]

Here you go, both are within 45 bit.

1PWo3JeB9YFTPQ7kKXU96TzwYdphNJ1Un3 - 0x6FA8A9807D4991ED36
1PWo3JeB9YF44UAhh11ysMBbD6dcmgBNdu - 0x6FA8A99F384A800898
[/quote]

Lol, you replied to his quote, "Anyone can prove me that exist two B9j in a 48 bits?" and came in with 2 1PWo3JeB9YF prefixes lol. Point is taken, but at least use examples he stated.

[/quote]

Thank you for clarification. In my database of 100k i didn't had anything in 48 and that's why i had the conclusion. You prove me that i am wrong, and thank you for this.
You have my respect!

Since you responded. can you tell me why your version  VanBitCrackenRandom2 is double the numbers of power if you add more than 128 cores when you use GPU+CPU? That can't be real. For example on 8X4090 + 144 CPU the power shown is min 74000MK/s.
How can your code double the power on CPU?

@kTimesG the prefixes are helping me as i said to find the new addresses with minimum B9. I understand your opinion but this is really working for me. 8 of 10 times i receive a B9 on a 40 bits range.
If your statistics are saying again this is luck....
And to tell you how i did it: if you see that BTC is not in order and is not increasing, so sometimes is in order sometimes not. To prove this you put eliptic curve in a circle and apply the formula. When the decimal are increasing the circle is spinning and follow the eliptic curve from inside circle. In this way you will see when generate in order decimal or hexa, the BTC will be haotic. For me this formula is working.
Is just another thinking out of the box.

[pscamillo]

That's great if the ECDLP sits in a 254-bit interval, and slows down computations for anything below 254 bits. The endo points will never get hit, so computing or storing them is totally useless.

Thanks for the detailed feedback, kTimesG — genuinely appreciated.
 
You're right on all three points, and I want to acknowledge that honestly rather than defend bad reasoning.
 
On endomorphism: I see the problem now. The canonical X is used for DP detection and storage, but the jump selection still uses the raw X — so two kangaroos at endo-equivalent points won't follow the same trajectory and won't converge. The "collision" is just a coincidental DP match at a single point, not a path convergence. For ranges well below 254 bits, the endo-equivalent points aren't even in the search interval, so computing and storing them is pure overhead. Fair point.
 
On cheap second point: Same fundamental issue — P − J doesn't lie on any kangaroo's trajectory. No other kangaroo will ever converge toward it, so storing it as a DP is storing a random point that will almost never produce a useful collision. The "doubled DP rate" is an illusion if those DPs are dead weight.
 
On XDP: You're right that XDP_MULT=8 at DP=20 is functionally equivalent to just using DP=17. It adds complexity for the same end effect.
 
I oversold the kernel changes — lesson learned. The parts of PSCKangaroo that I believe still have genuine value are the architecture decisions for single-GPU + high-RAM setups: ALL-TAME mode (filling all RAM with TAMEs, hunting with 100% WILDs), ultra-compact 16-byte entries (+56% capacity), async BSGS resolution for truncated distances, table freeze, and checkpointing. Those are engineering choices, not algorithmic claims.
 
I'll take your advice on the Python proof of concept — validating ideas on small instances before scaling to CUDA would have caught these issues early.
 
Thanks again for taking the time to explain the reasoning. This kind of feedback is exactly what makes this forum valuable.


Repository updated based on kTimesG's feedback:
 
github.com/pscamillo/PSCKangaroo — commit 085b31f
 
Removed:
- Endomorphism canonical form (GPU kernel)
- Cheap second point (P−J)
- XDP extended DP check
- GPU-side Bloom filter
 
Kept: ALL-TAME mode, ultra-compact 16-byte entries, async BSGS resolver, table freeze, checkpoints — the architecture stuff that actually helps.
 
Validated: Puzzle #70 (69-bit) and #80 (79-bit) solved correctly. Kernel now runs cleaner at ~2.7-3.0 GKeys/s on RTX 5070.
 
 

[XGiftGodX]

649a3dd0486c96e70b       1PWo3JeB9jdvp56gzG8navJjUMFQxxb997   
649aa0a809fe13a924        1PWo3JeB9jgLYkm8cEj6yywPn3kk41BFaY 
649a103b78b3e74856       1PWo3JeB9jRLz2NjTHsZ8uTBnqcjnu66Ak 
649ade9933e47de861       1PWo3JeB9jSVntJs1FpYM2iTNAoADNv2YD 
649a737f258abb8058        1PWo3JeB9jeFuotNeYDrWkEhqyZ359abB2 
649af9e3471ed5c49b        1PWo3JeB9jgFbdXaZG1h8ng9hpYzg3CAPw 
649a05d73d20978e62       1PWo3JeB9jT926gmLys26TBwr6pwStgwLb


Donation my

bc1qurlzuk6v7pruzemjfyjdttjxymhckcml9sw0w8


thanx

ha-ha

Code:

0x649a05d73d20978e62	1PWo3JeB9jT926gmLys26TBwr6pwStgwLb	F6F5431D25BBEE131726CA1F86672474B6E4A3D5	1855772920885219397218	0302751DAA96290A083BDDCA8CD23AC319B8D95116F40C2A9AA8CF122022C0033C	KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3rBinmvSXpixVnKso3SZd
0x649a0ad2d9876795c4	1PWo3JeB9jS1ttWtFXgTCy2hnCYcW1dD6V	F6F5431D25BBED9B9A8F0E621784AC4752C869AA	1855774323434284619204	034F9223C37A4581C73C5F634221AC1D16453DFEF5EA3719930EBBBFAE3C846AA2	KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3rBinsNm4f2xk6MCfAEAi
0x649a103b78b3e74856	1PWo3JeB9jRLz2NjTHsZ8uTBnqcjnu66Ak	F6F5431D25BBED54360606F002AB373B8AC542C8	1855775845842023827542	0312E89B2E156E19CC496873335BCF6D80FB7328C6E2A227F9E40019B563F76D1D	KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3rBinyJ7SyJ1aHWsGeWtv
0x649A133876C6F063BE	1PWo3JeB9j6ffmBQZ4tTuWxaByxBvPKVbB	F6F5431D25BBE59099EE9B35FB4A89AC2576371A	1855776686960148505534	02A10ECB207E3E5335F44AB18A4F17CC90D55DBC975092AF85A2E978A97617E35F	KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3rBio2ZozDD88oDkSiZt8
0x649a137ea2f2eaff0b	1PWo3JeB9j2EU5JxsW28UfCTp5ZFVjNk3b	F6F5431D25BBE3B8B38C1F296849159383301AA7	1855776764115678854923	03139D1F9A29A3B1115D76A9EB92B7A5964A93FB3A4E46894FDFBF004598EA4981	KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3rBio2sDFH9PGjudKZJty
0x649a15cfc7095be9d9	1PWo3JeB9ju3Yq8s97QRtqE3U3p2YfdxxD	F6F5431D25BBF8D7DAA1C6A4B6CEDDC92A1366D3	1855777416281069447641	02EAE5E2B0781507F32419246878C4DE3E5595D1B094CCD310691EB9ADB3EEAAE2	KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3rBio5QJ87uHAZRbdU6pC
0x649a205b29228381cc	1PWo3JeB9jMaH65f34qnG3DbtatLXrrwBn	F6F5431D25BBEBC2F0E6939FA87374E4A5E14B66	1855780384284281635276	02574E65ACAAF97C225FF819319ED0C3FCBABDA823EEA39663AE6C6AA59F62F764	KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3rBioGwg87UGRobFd1ZB2
0x649a2f071642db50f8	1PWo3JeB9j3RLp4NNvVodUbn1movwwhSg7	F6F5431D25BBE43711B7EAE31900ECFBAC43EA7F	1855784513968893808888	03272F4AC555500472266F44CEC55E1D6B62DB8AD065E72C36CD1A44E75D9E43F1	KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3rBioZ13uEvPTv5eBa9LS
0x649a3dd0486c96e70b	1PWo3JeB9jdvp56gzG8navJjUMFQxxb997	F6F5431D25BBF28F431ED96532EBAFA65BF5931E	1855788675835853465355	02D93E9A0DC609B3AD8C3E080B1DD10C425C037C53CB8313A2031C1CDCAECBD907	KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3rBioqBgemYg4VSEkEFo5
0x649a737f258abb8058	1PWo3JeB9jeFuotNeYDrWkEhqyZ359abB2	F6F5431D25BBF2B24DCCBCDF87F2ABFEFFB4EEA8	1855803786274335850584	02ED65C797BFB5C842A9584ACC5F3713F86B5E3FDCC75ECB0B41E16E60B714DF72	KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3rBipqwa1JY7VeYq3zfDL
0x649aa0a809fe13a924	1PWo3JeB9jgLYkm8cEj6yywPn3kk41BFaY	F6F5431D25BBF38FA4743F51AF14BCD67463B7D0	1855816497609940642084	02B1CDB21A56CD4B92840C59534420B75751B3AFBE664FA2DE37F824D862071CA2	KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3rBiqhNP4PNciudJAoe6j
0x649ade9933e47de861	1PWo3JeB9jSVntJs1FpYM2iTNAoADNv2YD	F6F5431D25BBEDCEC969FFE21AD9F3D3648B48D3	1855833932745781667937	0353D262FA353A54E493CAA7E3C4104CB2824EAE9BB1C08BF513B6E02D479FD802	KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3rBirsAZRi1dmwLPdfAD8
0x649af9e3471ed5c49b	1PWo3JeB9jgFbdXaZG1h8ng9hpYzg3CAPw	F6F5431D25BBF3868F42E4B88C52FCF50D1773EE	1855841614016596526235	0200D5D2F9393034EDAA730B7665EA0127DFCCF3F796D46CA4C05CB7DD4C5C1457	KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3rBisP2vxweiiYwjdEHkj

Donation my 13sChartsJcYYxpMM4FPUArfp7StLiXBQC

thanx

How are where are you getting these?  Vanity Search?

[ayiphelmy]

Repository updated based on kTimesG's feedback:
 
github.com/pscamillo/PSCKangaroo — commit 085b31f
 
Removed:
- Endomorphism canonical form (GPU kernel)
- Cheap second point (P−J)
- XDP extended DP check
- GPU-side Bloom filter
 
Kept: ALL-TAME mode, ultra-compact 16-byte entries, async BSGS resolver, table freeze, checkpoints — the architecture stuff that actually helps.
 
Validated: Puzzle #70 (69-bit) and #80 (79-bit) solved correctly. Kernel now runs cleaner at ~2.7-3.0 GKeys/s on RTX 5070.
 

im windows user and have 6 gpu in 1 rig with 16 gb ram, can i use this?
Thanks

[pbies]

Repository updated based on kTimesG's feedback:
 
github.com/pscamillo/PSCKangaroo — commit 085b31f
 
...
 

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?

[pscamillo]

im windows user and have 6 gpu in 1 rig with 16 gb ram, can i use this? Thanks

Hi ayiphelmy, thanks for the interest!
 
Current status:
- Linux only for now — the Makefile and build system target Linux (Ubuntu 22.04+). Windows support would require a Visual Studio project, which I haven't set up yet.
- Single GPU — PSCKangaroo currently uses one GPU at a time (-gpu 0). Multi-GPU support was in the original RCKangaroo but I haven't tested it in my fork.
- 16 GB RAM — it will work, but the ALL-TAME mode shines with more RAM. With 16 GB you'll get a smaller TAME table. Use -ramlimit 12 to leave headroom for the OS.
 
For your setup (6 GPUs, Windows, 16 GB RAM), the original RCKangaroo might actually be a better fit right now — it has Windows support and multi-GPU out of the box.
 

[ayiphelmy]

im windows user and have 6 gpu in 1 rig with 16 gb ram, can i use this? Thanks

Hi ayiphelmy, thanks for the interest!
 
Current status:
- Linux only for now — the Makefile and build system target Linux (Ubuntu 22.04+). Windows support would require a Visual Studio project, which I haven't set up yet.
- Single GPU — PSCKangaroo currently uses one GPU at a time (-gpu 0). Multi-GPU support was in the original RCKangaroo but I haven't tested it in my fork.
- 16 GB RAM — it will work, but the ALL-TAME mode shines with more RAM. With 16 GB you'll get a smaller TAME table. Use -ramlimit 12 to leave headroom for the OS.
 
For your setup (6 GPUs, Windows, 16 GB RAM), the original RCKangaroo might actually be a better fit right now — it has Windows support and multi-GPU out of the box.
 

thanks for respons, i already tested original kangaroo, will be good if you can compile for windows, thanks..

[pscamillo]

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!

[pbies]

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.

[r3cruit]

I also decided to leave some screenshots for discussion. The testing was done on a 50 puzzle

https://ibb.co/6RJpYRrv
https://ibb.co/60vGpRTk
https://ibb.co/SwbDhNxB
https://ibb.co/Gvv8QRpM

[pscamillo]

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.