yoyo; yeah take a look at ADAB's post.  You will quickly realize why it's not a fair and equitable pool idea and to make any money you probably have to buy some "sketchy" tokens and their main focus is on probable Satoshi mined coins.

If the kangaroo pool is kept private, meaning only those who ask to join/you trust, then you could use the built in server/client in JLPs original Kangaroo program. The only drawback to a pool for Kangaroo is the overhead that would be created, however, you could break the overall range into smaller chunks to minimize the overhead.

I think the overall idea for the kangaroo pool is a good one, it just needs thought out to minimize overhead. If one wanted to use CPU only, with a python script, that would be easier to help minimize the overhead. The pros: minimize overhead easier, most everyone has a CPU. The cons: it will be slower than GPU version but if enough people joined, that could close the gap in search time.

Exactly. Smaller ranges could work to help minimize the overhead. If running smaller ranges for x amount of time and not allow rejoins, would minimize the overhead.

You could also use the save kangaroos to server (if powerful enough server CPU/RAM) to eliminate overhead.

You could also run x amount of members on Tame only. I mean once you find one Wild DP, it's collision counterpart, the Tame, is in the range somewhere.

A BSGS pool might be better. I've always imagined a central server CPU to run the baby steps and multiple GPUs/CPUs running the giant steps. So the central server stores the baby steps and then the pool members run the giant steps with a GPU or CPU. And as you know, running BSGS you can run multiple keys and save time on having to rerun the baby steps; saving lots of time overall.

In my free time, I'm planning to build a PoW server + combined methods for searching from other projects, from scratch once I'm finished with my current (private, unrelated to private keys) project, given BitCrack is MIT licensed of course you can expect me to release the source. The GPU version needs some more tuning esp. the OpenCL version if we are to see any serious usage of these programs.

Also things that haven't been seen before like WIF character matching are very fascinating to see a working (as well as fast!) implementation for.

On the running side of things I am not actively brute-forcing right now, so no point in me actually running this program except maybe for debugging.

Well the good news about this is now that I finally have access to Vast.ai rigs I can finally do my testing without going around constantly knocking on people's doors to borrow their GPUs.

Also this project (well, a very similar variant at least that involves mining) is sponsored by my employer so I should have no problem getting funding for this project, they can also provide some of the bigger clusters to me for free if I need them for testing.

But yeah I'll be happy to let you know if I need anything from you, particularly source.

If they http://www.ttdsales.com/64bit/login.php are trying to solve #64 16jY7qLJnxb7CHZyqBP8qca9d51gAjyXQN: It is possible

Other addresses ~#256: It is impossible

This is what I was meaning. It's a fun idea. I have a couple of 3070's id be tempted to put towards a puzzletx

So why did you redirect me to use this then?

https://github.com/iceland2k14/Kangrand

I do not see a different (nor faster multiplication) that iceland has builtin/using in his code. All I see is a start stop and a random bit addition.