Bounty - 1 BTC + 100 Grin for a MacOS M1 C32 Open Source Miner with ≥0.5 Gps

Bounties
41

May you tweak it for Mac Studio M4 base model? I’d like to test how fast it is.

1 Like
42

I hearby invoke the council to buy tromp an m1 ultra to verify this project.

43

I’ll make sure it can be tuned for the M4 and other current Mac variants. For now, I’m staying on the M1 since that’s the AWS instance I already have in place.

I’m also testing another design that appears to be faster on the M1. Once that work is finished, I’ll likely pause development until my financial situation improves, as AWS costs are starting to add up and my budget is limited at the moment.

This is my first attempt to monetize a project by pursuing a bounty, and the first project where I’ve had meaningful expenses directly tied to development. I had been experimenting with my own CUDA-based miner design and was seeing promising results, so I decided to take a shot at the bounty. Most of the last several years have been spent self-learning and building, making this the first time I’ve tried to turn that work into something more.

4 Likes
45

I released the full repo with source code

1 Like
46

Would you mind linking to the source code repo?

There seems to be a misunderstanding here. I said

That means a bounty of 1 BTC for reaching 0.5 gps and 2 BTC for reaching 1 gps. I didn’t offer fractional bounties. (did anyone else interpret my offer as such?)

I do think that continued work on improving the miners for more up-to-date hardware, namely the M3 Max/Ultra, and M4/M5 Max would be quite worthwhile and I would support a grin council decision to financially support such an endeavour.

I’ll allow for a further 2 weeks of evaluation of the code to see if any problems come to light, and if not, I will proceed to pay out the 1 BTC bounty.

Btw, use of AI is not a problem, but it would be nice if it were acknowledged.

Your METHODS.md file says

Cuckatoo-32 is a bipartite graph on 2^31 u-nodes and 2^31 v-nodes with 2^32 edges.

which is incorrect. As stated on [1]

Set N = 2^32
Define a bipartite graph [1] G_K=(V,E) with N edges on N + N nodes as follows:

[1] cuckoo/doc/mathspec at master · tromp/cuckoo · GitHub

5 Likes
47

John.

I read the doubling comment as if it implied a fractional multiple, but that was my assumption, not what you actually said. I should have asked instead of stating it that way. I appreciate the clarification.

On AI: yes, I do use AI at different points in my workflow. That said, I want to be careful not to let “AI-assisted workflow” get conflated with “AI did the work.” I used AI at during some points of development but the code, claims, measurements, and errors is mine.

Thanks for catching my error in METHODS.md too. I see the issue. I compressed the distinction between the base graph K_G and the node-pair graph G’_K and the sentence is wrong as written.

The math spec defines K_G with N = 2^32 , N edges, and N + N nodes. Then K_G is obtained by identifying nodes that differ only in the last bit. A Cuckatoo32 solution is a 42-cycle in G’_K that is also a matching in G_K. My wording made the halved node-pair graph sound like the base graph.

Thanks for taking the time to review it carefully. Let me know if you would like me to address anything else that comes up during the evaluation window.

48

Have you posted the link to your source repo yet?

49

I thought I had. In all the excitement, I missed the most important part. Here it is https://github.com/3k3r1l4rz/m1_grin_miner_fastest_public_source

4 Likes
50

This turns out not be be cheap at all, since the graph must first be almost fully trimmed, which takes over 99% of the processing time. What you call the solve phase here is just the brute force exploration of the trimmed graph.

51

John,

I think the wording issue is the scope of “cheap” and “solve phase.” I did not mean cheap relative to the raw C32 graph from start. You are right that D2 is not a pre-trim raw-graph score. By the time distance-two edge adjacency verdict, or D2 runs, the miner has already paid the seed and trim prefix: seed L1, seed L2, and trim rounds 0..64. Those are 154 ms + 180 ms + 985 ms = 1.319 s before the D2 verdict even runs.

What I meant is that D2 is cheap relative to completing the remaining post-cut solve path. D2 costs about 80 ms, bringing the summed path to 1.399 s; with about 13 ms of dispatch/sync overhead, the abort path totals about 1.412 s, matching the measured wall of roughly 1.414 s. The full-trim baseline was 1.799 s/graph, while the current D2 stack is 1.421 s/graph, so the measured stack improvement is about 0.378 s/graph. That is the sense in which D2 is cheap: not cheap before the graph is processed, but cheap compared with finishing the tail.

Mechanically, D2 is a cutoff certificate over the round-64 survivor set. It builds a distance-two edge-adjacency graph whose vertices are surviving edges. One D2 arc represents a two-edge move through paired Cuckatoo endpoints using id ^ 1. Therefore, any full 42-cycle must leave behind a closed 21-step walk in this D2 shadow graph. The implementation emits survivor endpoints, builds U/V hash multimaps, joins on paired keys, writes the D2 adjacency, and runs a bounded depth-21 DFS for existence.

If that DFS finds zero candidates, the absence is a proof: the necessary shadow of a 42-cycle is not present, so the original graph cannot contain a valid 42-cycle. The miner can then abort safely and skip the remaining trim, gather, peel, and recover path. So I agree the phrase “cheap score before the full solve” can be misleading. More precise wording would be: D2 is an exact mid-solve abort path that cheaply decides the post-cut continuation, not a cheap raw-graph predictor.

Ethan

4 Likes
52

Congratulations for winning the bounty!

7 Likes