Mujina Dev Call 20260615

[rkuester]

Summary generated by AI from the meeting recording.

Post-Meeting Summary and Transcript

Attendees: Ryan (host), Brett, Jayr, Dylan, Tyler, Aadhi. Referenced but absent: Adam (nonce-space research, discussions/72), Ronald (BZM2 reference docs), Schnitzel (cross-compilation and CPU backend PRs), Jungly (pool operator hitting a CPU-miner regression), LabHash (advising Jayr on the SV2 implementation).

Summary

Recording format and Bitcoin TV (00:00)

• Ryan is still tuning the recording setup (screen share instead of face-cam) and is still trying to reach someone at Bitcoin TV about posting call recordings there; no contact yet beyond a cold email.
• The AI transcription and summary pipeline is working well enough that Ryan barely touches it up before publishing.

POD256: GridPool with AgentP (02:14)

• Tyler recapped POD256 episode 116, where AgentP discussed GridPool, a decentralized pool payout scheme that estimates payouts statistically from miners' highest difficulty shares rather than maintaining a share chain like P2Pool v1/v2. AgentP also reverse engineered the Datum client/server protocol.
• AgentP separately wrote up, in a GitHub discussion after last call, how he got Mujina running on an S19 by using an AI coding tool over SSH while LuxOS was running.

Configuration and REST API spec (05:05)

Continued discussion of Ryan's configuration and API proposal, introduced last call:

#57

• Jayr asked about the design's origin; Ryan traced it to two decades of Linux systems and packaging work, and to patterns like the Filesystem Hierarchy Spec and systemd's use of config.d-style drop-in directories.
• Jayr also asked about mixing computed/runtime values (set point vs. actual value) into the same configuration tree; Ryan compared it to how Kubernetes keeps desired and observed state close together.
• Brett suggested a --delete <path> option (a JSON-pointer (RFC 6901)-style path) to remove a single bad config value without wiping the whole config, distinct from the existing delete-saved-config-on-startup flag. Ryan agreed and asked Brett to leave a comment on the discussion.
• Brett proposed a read-only GraphQL layer on top of the branches/leaves config tree, so a client can request just the fields it needs (e.g. hash rate and temperature per board) instead of pulling an entire subtree, which could otherwise balloon once per-chip data is included. Mutations would stay as plain REST endpoints. Ryan agreed this had been cut from the document for length and is worth adding back.
• Brett asked for a status endpoint on port 4028 compatible with CGMiner (even just dev details/version) so tools like ASIC-RS can discover a Mujina instance by probing for a recognizable string. Ryan signed up to add it and asked Brett for an example payload to match.

Power allocation strategies (20:11)

Dylan walked through the allocation strategies discussion:

#64

• Today a power target is split evenly across boards of the same model, but a mixed fleet (e.g. more efficient S21 boards alongside less efficient S19s feeding a heating system) would benefit from strategy-aware allocation, and from an aggregate power/hash-rate target instead of having to set one per board.
• Ryan agreed an aggregate-target concept is missing from the current API tree and floated a new top-level collection for aggregate values, sitting above boards but below the daemon.
• On how much policy to bake into Mujina itself versus leaving to an external controller, Ryan's framing: Mujina should expose mechanisms and obvious baseline policies (like most-efficient allocation), but site-specific strategies (e.g. zone-based heat routing) belong in a controller built on top of Mujina's API.

Nonce-space configuration (26:50)

Jayr presented on Adam's behalf (Adam wasn't on the call):

#72

• Adam (working on ESP-Miner's Stratum V2 support) and Jayr independently noticed duplicate shares, traced to how the version rolling BM13xx chips slice the nonce space; default register values assume a particular chain size, so a different chain size, or overclocking, leaves part of the space uncovered or wastes time on space the chip already exhausted.
• Adam's math allows computing close to 100% nonce-space coverage for a given device and clock speed, generically enough to apply across Mujina's chip drivers. Ryan noted this fills a gap from when he first reverse engineered the BM13xx driver, when these registers weren't well understood, and plans to reply to the discussion and bring the approach into Mujina.

Issue triage: contributor-friendly fixes and Windows (34:35)

• Brett has a quick fix out for issue fix(bitaxe): replace expect() calls with proper error handling #52 (expect-statement updates).
• Aadhi has Mujina running on Windows and said he'd turn that into a PR.

CPU miner regression and difficulty suggestion (35:58)

Ryan has been fixing CPU-miner bugs surfaced by Jungly and by his own prep for the Nairobi workshop, tracked here (forced share rate wrong, never converging):

#59

• A branch with the fixes is close to mainline-ready; Ryan wants it in before the workshop so students can pull mainline instead of his branch.
• Jayr noted outside interest in the CPU miner: a Stratum V2 pool developer wanted to reuse it in place of an old, unmaintained implementation, and it was used in a workshop with 40-50 people at the Vinteum Bitcoin Dev Launchpad.
• Ryan also described recent changes to how Mujina suggests difficulty to pools on hot-plug events (boards added/removed changing total hash rate substantially), since most miners don't expect to suggest difficulty mid-connection. Brett couldn't think of a comparable existing miner behavior, since most ASIC rigs treat power wiring as fixed at boot; the group flagged this as worth checking with Jungly (as a pool operator) and watching for Stratum V2 proxy behavior. Jayr confirmed Stratum V2 has an analogous mechanism (VARDIFF, with an explicit message to update declared nominal hash rate), relevant to the CPU miner and beyond.

Stratum V2 pull request walkthrough (52:09)

Jayr walked through his third SV2 implementation attempt:

#65

• It's built heavily on the Stratum V2 reference crates (channels_sv2, codec, binary framing) with guidance from LabHash. Reusing those crates avoided having to hand-roll the noise handshake, frame encoding, and the protocol's binary (rather than JSON) framing.
• The PR is about 3,500 lines, a large share of which is integration tests that spin up a real pool and client communicating over the network, full black-box style, something the SV1 integration currently lacks. Jayr wants feedback on whether that test approach is the right one to carry forward.
• Ryan called it ready to start getting reviewed and merged once he's back from travel.

Wrap-up: docs, BZM2 reference material, and Nairobi (59:16)

• Jayr's contributing-docs PR reflects agreements from a prior call; Ryan still needs to review it, along with Schnitzel's two PRs and Jayr's fan-speed-controller PR:

#67 #55 #56 #33

• Ronald (not on the call) opened a PR turning his BZM2 behavior write-ups into markdown docs under docs/:

#66

Ryan doesn't want to lose the contribution but is wary of merging general reference documentation that doesn't describe code already in the tree; Dylan agreed unmaintained, possibly-stale reference material shouldn't live in the main tree. Tabled for a future call to figure out where this kind of material should live. (The rest of the BZM2 stack is actual driver/API code and wasn't part of this concern: #68, #69, #70, and #71.)

• Ryan plugged his upcoming Mujina mining workshop at Bitcoin++ Nairobi, walking attendees from CPU mining through ASIC mining on 15 Bitaxe Gamma boards donated by Solo Satoshi.
• Reminder: the Good Vibes category is for sharing vibe-coded branches and prototypes not meant for merging: Welcome to Good Vibes: the Brave New World of AI Coding #62
• Brett relayed a chat message from Aadhi: work in progress on getting Mujina running on a Braiins Mini Miner BMM 101 and a Canaan Avalon Nano 3S. Ryan wants Aadhi to share progress on a future call.

Action items

• Brett: post a comment proposing a --delete <path> CLI option for removing a single config value: Configuration system and REST API #57
• Ryan: add a CGMiner-compatible status endpoint on port 4028 for ASIC-RS discovery; Brett to send an example payload.
• Aadhi: open a PR with his Windows branch (done same day, see feat(transport): add native Windows support #75).
• Ryan: land the CPU-miner fix branch before the Nairobi workshop: bug(cpu_miner): forced share rate is wrong and never converges #59
• Ryan: reply to the nonce-space discussion and thank Adam for the research: Nonce space configuration #72
• Ryan: review and merge Jayr's SV2 PR after returning from travel: feat(stratum_v2): add SV2 support #65
• Ryan: review the backlog of open PRs: Jayr's contributing-docs update and fan-speed controller, and Schnitzel's cross-compilation and CPU-backend PRs:

#67 #33 #55 #56

• Group: decide where general reference documentation like Ronald's BZM2 write-up should live, since it shouldn't go straight into the main tree: docs: add BZM2 port engineering notes under docs/bzm2/ #66

Transcript

Full transcript on the wiki: https://github.com/256foundation/mujina/wiki/dev-call-20260615

Agenda (as planned)

Agenda

Note: These meetings are recorded and transcribed by AI.

Purpose: touch news and happenings to keep everyone aware of what's happening,
roughly follow development workflow, not replacement for the other communication
channels

Follow-up

• Last call
  • Summary and transcript now in the top post
• Action items covered by items below

Forum & Chat

• POD256 E116: Decentralizing Pool Payouts: Inside GridPool with Agent P

Discussions

• Configuration system and REST API #57
• Nonce space configuration #72
• Mujina Allocation Strategies #64
• Good Vibes category

Issues

• All issues
• bug(cpu_miner): forced share rate is wrong and never converges #59

PRs

• All PRs
• feat(stratum_v2): add SV2 support #65
• docs(contributing): reflect agreed contribution flow and channels #67
• cpu-miner: make the CPU backend a first-class citizen for API/tooling #56
• Make non-glibc Linux cross-compilation work #55
• feat(bitaxe): add PI-based fan speed controller #33
• BZM2 (Intel Bonanza Mine 2) stack:
  • docs: add BZM2 port engineering notes under docs/bzm2/ #66
  • feat(board): per-board command channel, power-rail primitives, thread telemetry types #68
  • feat(asic): Intel BZM2 (Bonanza Mine 2) ASIC family support #69
  • feat(board): BZM2 board driver with calibration and runtime tuning #70
  • feat(api): BZM2 diagnostic endpoints and hardware documentation #71

Other

• Mujina at bitcoin++ in Nairobi

Open floor

[rkuester]

Summary and transcript are now in the top post.

[recklessnode]

Following up on the #66 discussion (Ronald relayed the call notes). We think the tabled question - where should reference material live - has a natural answer for the BZM2: bzm2-hwref, the public CC-BY-SA BZM2 hardware reference Reckless Systems maintains (pinout/ball map + machine-readable CSV, electrical quick reference, UART/TDM protocol incl. the 9-bit physical layer, integration guide). It is maintained by the party with access to the original collateral, versioned independently of any miner implementation, and usable by every BZM2 project rather than bound to one tree.

We have already implemented it on our side:

1. feat(api): BZM2 diagnostic endpoints and hardware documentation #71 is slimmed (d9ab286): docs/bzm2/ now carries only the three documents that describe code in the tree (port architecture, tuning-planner notes, opcode grounding); the README links to bzm2-hwref for hardware reference. Net -1,326 lines.
2. docs: add BZM2 port engineering notes under docs/bzm2/ #66 closes - its driver-specific content rides feat(api): BZM2 diagnostic endpoints and hardware documentation #71 next to the code, and its general reference content has enriched, maintained versions in bzm2-hwref.

That gives exactly the property Ryan and Dylan asked for: nothing unmaintained or possibly-stale in the main tree, with a maintained external home one link away. No rush on the code series (#68 -> #71) - happy to rebase whenever review time opens up.