Collision Protocol: 1000 BTC Challenge Pool (#135, 13.5 BTC)

[hevnsnt]

Quick background if you have not run into it: the 1000 BTC Challenge is an on-chain puzzle from 2015. Someone funded 160 addresses whose private keys sit in deliberately increasing ranges (key N is between 2^(N-1) and 2^N), and in 2023 the prizes were bumped 10x. The low ones have been picked off over the years; the unsolved ones still hold real coins. #135 is the current target and holds 13.5 BTC. Tracker: https://privatekeys.pw/puzzles/bitcoin-puzzle-tx

Collision Protocol is a distributed Pollard's Kangaroo pool that points a fleet of GPUs at one unsolved key at a time. It's on #135 right now and stays on it until it's solved. When that happens the pool doesn't stop: it automatically rolls the whole fleet to the next key most likely to fall (the lowest unsolved range whose public key is exposed, which is what Kangaroo needs). Nothing for you to reconfigure, your worker just follows the pool.

Each worker only runs one side of the walk, tame or wild, and sends its distinguished points (DPs) to the server. That split is the anti-cheat: no single machine ever has both halves, so nobody can quietly hit the collision, recover the key, and sweep the coins before the pool does. The upside for you is the payout. Since the solve can only land at the pool, every DP you commit counts toward your share. If the pool cracks the key, the prize is split by contribution: a 5% pool fee, and everything left over distributed in proportion to the verified DPs each worker submitted.

Rough scale: RCKangaroo's own estimate for a 2^134 range is 1.15 * 2^67 operations, which at dp_bits 28 is about 6 * 10^11 DPs to expect a solve. That is an expectation: a real solve can land anywhere from about half to double that, and DP/GPU overhead pushes the true count up somewhat. Expected time against the pool's aggregate rate:

Code:

   pool DP/s      expected solve time, #135
       100        ~200 years
     1,000        ~20 years
    10,000        ~2 years
   100,000        ~2.5 months
 1,000,000        ~7 days

We are at single digits per second today on a couple of test rigs, and the bottom rows of that table are a serious amount of hardware, so this is mostly a question of how many GPUs show up. Rate scales linearly with workers.

Open to testers who get that it's early and rough in places, and who will open a GitHub issue when something breaks instead of just walking away. Mainly after Linux and Apple Silicon right now.

Client (collider) is open, GPLv3, built on JeanLucPons' RCKangaroo: https://github.com/hevnsnt/collider
Issues: https://github.com/hevnsnt/collider/issues
Live coverage/stats: https://collisionprotocol.com/pool

Code:

collider --pool pool.collisionprotocol.com:17403 --worker <btc-payout-address>

Worker name is the payout address (So get it right!). The pool tells the client which target, range, and DP size to work, so the same client follows whatever key is active. CUDA on Win/Linux, Metal on Apple Silicon, CPU fallback.

What's useful to report: whether it builds and runs on your platform, the rates you get, and anything that breaks or drops the connection. Source is there if you want to pull it apart.

collider-pro is a separate paid build for solo and brainwallet work. Not needed for the pool.

[NotATether]

I almost forgot about this puzzle.

OK so the rewards were 10X'ed? Cool.

One thing I wanted to ask though, is if this will run on H100 gpus that are normally used for AI.

The benchmark for this will be interesting because it will show whether Nvidia nerfed general purpose CUDA work in favor of training.

[hevnsnt]

Yeah, the reward bump is real, makes the whole thing a lot more interesting.

On the H100: it will run, you just have to tell the build about it. The stock build targets consumer cards (Turing, Ampere, Ada, and desktop Blackwell), and Hopper is not in that list, so you add it at configure time:

cmake -B build -DCMAKE_CUDA_ARCHITECTURES=90 -DCMAKE_BUILD_TYPE=Release

then build as normal. That gives you a native sm_90 kernel for the card instead of leaning on a JIT fallback.

It should scale to the whole GPU, but again I have never tested it on a H100 . The kangaroo engine sizes its herd to the device it sees, so it spreads across every SM and fills occupancy the same way it does on a 4090, just with a lot more of them. An H100 will light up the entire chip.

The honest caveat is that this workload is secp256k1 integer and elliptic curve math, not matmul, so it never touches the tensor cores that make the H100 a beast for training. You are leaning on its plain CUDA integer throughput and memory bandwidth, which is exactly the part that does not get the AI uplift. That is what makes your benchmark idea fun.

A 4090 tends to be the price to performance sweet spot for this, and an H100 will be quick in absolute terms but you are paying for a pile of silicon that this job never uses. If you do run it, I would genuinely like to see the GKeys/s side by side with a 4090, that comparison is the interesting question.