Repository navigation
Replies: 1 comment
|
Summary and transcript are now in the top post. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Summary generated by AI from the meeting recording.
Post-Meeting Summary and Transcript
Attendees: Ryan (host), Skot, Schnitzel, Brett, Tyler, Dylan, and Susan. Referenced but absent: Jayr, Ronald, Johnny, Sean (ixtech.xyz), Aadhi, The1Anubis.
Summary
Call time after daylight saving (00:00)
US daylight saving time ends on Nov 1. The call stays at noon US Central, so from the next call on Nov 9 it starts at 1800 UTC instead of 1700 UTC. Nobody objected.
Rust Bitcoin Summit (02:00)
Ryan attended the Rust Bitcoin Summit in Nashville. The rust-bitcoin team hosts it, with BDK, LDK, and their users. Mujina uses rust-bitcoin, but Ryan went mainly to put open source mining back into the open source Bitcoin conversation, and he presented Mujina to the group several times.
The projects there all deal with AI contributions and security scans. Unlike the parts of the wider open source world that ban AI contributions, the Bitcoin projects treat AI as a productivity tool. Some accept AI-written code more quickly than Ryan expected. Schnitzel asked what surprised the other side. Ryan said that even very experienced Bitcoin developers did not know how closed mining is, for example that miners phone home and hash part of their work for a dev fee to another pool. All were enthusiastic once they heard how open source can fix it. Skot noted that many people have not paid attention to mining in a while.
Mujina OS image (09:26)
Most of Ryan's time has gone into the Mujina OS image that the installer puts on the S19 J Pro, which left less time for PR reviews. He plans to take part of a future call to show block diagrams of how the pieces fit together. The image is a full Linux system that takes over the control board, so it brings far more security surface than the miner process itself. Images in the field fall out of date, so the OS must ship security updates. The recent SSL certificate vulnerability is an example: when libraries bake in their own roots of trust instead of using the system's, a fix means updates to the system and to several libraries.
Brett asked whether the image uses Yocto or Buildroot, and offered an introduction to James Hilliard, a Buildroot maintainer. Ryan is building a stripped-down Debian derivative instead. Debian already builds and packages most of what Mujina needs, maintains its security updates, and supplies package management that Mujina can use to compose images and to update them over the network. Brett raised the BeagleBone control board in some S19s as a hard target; Ryan knows of no problem there. Skot said a Debian base makes the system easy to change with SSH and apt, as on a Raspberry Pi.
Two more design goals came up. Others should be able to derive their own images from Mujina's, for products or for tinkering, such as Schnitzel's RY3T. And the same image, with different hardware drivers, should install on the S19 J Pro's stock control board and on the LibreBoard.
RHAP framing and sessions (23:03)
Skot has been promoting the RHAP protocol for other projects, so Ryan wants to publish the spec in 256foundation/rhap soon. He will first commit the document that describes the protocol as it is. Before RHAP spreads, he wants to add frame delimiters, because today the protocol does not recover when the two sides get out of sync, such as when a USB cable is unplugged and plugged back in, or when Mujina restarts while the board stays powered. He is also considering optional sessions. When a session ends, the board puts itself in a safe state, and a host that connects later knows the starting state of the hardware instead of querying all of it. Ryan will write this up this week.
Skot said there is broad support for replacing the Bitaxe self-test mode with a RHAP mode, so RHAP would ship on all Bitaxes and Mujina could use one without a separate firmware install. That firmware will be reimplemented in C, so it can wait for the revised spec.
Stratum V2 and timeouts in the spec (28:14)
Ryan merged #125 after Jayr reviewed it. It adjusts the Stratum client code that V1 and V2 share so V2 fits in. Jayr rebased #65 onto it and continues the review cleanups.
The SV2 spec often says to time out after a "reasonable" period without giving a number. SV1 has the same gap, but its servers send jobs often enough to show they are alive; SV2 is less chatty. A client must choose a number either way, so Ryan raised it with the spec authors, who now track it in stratum-mining/sv2-spec#245. If the spec sets the numbers, implementations agree, rather than settling on whatever became popular, as happened with SV1. Mujina's place in the SV2 working group gives it a voice in the spec.
Reviews waiting, and Windows support (31:51)
Several small bug fixes wait on Ryan's review, as does Susan's #118. Ryan has read Sean's Windows support, #76, but has not yet written his feedback. Enough people want Mujina on Windows that he will keep merging that work.
Dependency advisories, BM1370 measurements, and hot removal (33:30)
A bot in the repository opens an issue when a RustSec advisory names a crate Mujina depends on. Ryan checks whether Mujina uses the affected part. If not, Mujina takes the fixed version in the normal course of updates, after the cooldown period that guards against compromised releases. If it does, Mujina takes the update at once. Three of the recent advisories, #127, #128, and #129, do not affect Mujina. Ryan has not yet looked at the newest, #132.
The1Anubis posted BM1370 measurements from a NerdOCTAXE in #131. Nobody on the call knew who they are. One finding is that with fewer than four version bits, the sub-cores repeat each other's work. Nobody runs the chips that way, but Ryan will add the findings to the BM13xx reference doc.
Mujina handles hot plug well but not hot removal, which has a few bugs to fix, such as the one in #122.
RDS autotuning and S19 J Pro readiness (37:34)
Ronald continues to run Mujina on his Intel RDS units and is working on calibration and autotuning, which he says may apply to other miners (Telegram). Reed asked whether Mujina is ready for his S19 J Pros (Telegram). Ryan's answer is almost, pending the image and installer. Schnitzel's and Skot's experimental S19 J Pro builds, linked from the website, work for those willing to take the risk, but they differ from the official release, so Ryan would wait a couple of weeks.
An APW power supply adapter (39:05)
Sean asked whether the LibreBoard will talk to an APW12, the Antminer power supply with its own connector and interface (Telegram). Skot explained that the LibreBoard is a development board and a reference design for 256 Foundation projects such as the EmberOne, not a drop-in Antminer control board. Schnitzel confirmed that it has no manufacturer-specific connectors. The APW interface is I2C plus one GPIO, so a small adapter board or cable can connect it. Several people have asked for one PCB that does it all, so he may make a LibreBoard variant for Antminers, but nothing is decided.
Skot started the APWMeister, a USB adapter for the APW data connector, like the AditBoard is for hash board data. It will speak RHAP, so Mujina controls the supply the same way as a hash board, and Skot would like to put RHAP-D on it. Ryan said the cheap, common APWs are useful for many projects.
LibreBoard rev3 (43:39)
Schnitzel sent LibreBoard rev3 to JLCPCB for full assembly. It fixes the problems that Ryan and Schnitzel found in rev1 and some that AI review found. Per-port power control for the four USB-C ports would have needed too much rerouting, so rev3 adds a reset for the whole USB hub instead. Five assembled boards cost about $1,000, or $200 each, and much less in quantity. After testing all five, he will send one each to Ryan, Skot, and the Gridless team behind Jua Kali, an open source miner that runs hashboards on DC solar power. He is looking for a home for the fifth. He is writing documentation, including how to attach different miners, and wants Ryan's review of it.
Bitaxe Bonanza and the Nano 3S (47:44)
Skot has Bitaxe Bonanza 1.0.04 working. He had five built at JLCPCB, with the ASICs soldered by hand. Johnny has one and reports good progress on the firmware. When the new display board arrives, Skot will give boards to key developers, including Ryan. Each board has four BZM2 chips powered in series, which makes it a development platform for ramping frequency and voltage to keep the domains balanced. Ryan said it will help him merge Johnny's and Ronald's BZM2 work. Sean has also run Aadhi's build of Mujina on an Avalon Nano 3S (Telegram).
Digital voltage and temperature on BM1370 and BM1372 (50:14)
Skot found that the BM1373 in the S23, which is a relabeled BM1372, reports the voltage of each of its internal cores and its die temperature over the serial port, from what looks like a raw ADC in a set of registers. Further work showed the same on the BM1370: four core voltages and one temperature diode for the whole chip. He found the functions in the S23 firmware, which oversamples the temperature, but stock firmware does not seem to use them. After more testing, especially of the temperature readings, he will publish the feature in ESP-Miner for the Bitaxe Gamma and the Bitaxe Naja. Ryan plans to use it in Mujina.
Action items
Transcript
Full transcript on the wiki: https://github.com/256foundation/mujina/wiki/dev-call-20261026
Agenda (as planned)
Agenda
Meeting: Monday 2026-10-26 at 1700 UTC (noon US Central), https://meet.jit.si/mujina-dev-call
Note: These meetings are recorded and transcribed by AI.
Purpose: keep everyone aware of what's happening, roughly following the development workflow. Not a replacement for the other communication channels.
Announcements & host topics
PRs
Ryan's prep for PR 65, the extranonce types renamed to SV2's terms. Jayr approved it, and it is merged. PR 65 is to rebase onto it.
Jayr's SV2 support, still with changes requested. In review the question came up of how long the SV2 client waits for a share acknowledgement before it calls the server dead. The spec does not say, and the same gap shows up in several other places in the spec.
The places where the spec lets one side wait on the other and gives no time limit.
plebhash's proposal of 60 s as the limit on a share acknowledgement, and as the protocol's sign of life.
Jeremiah's fix for the scheduler panic in issue 114. Jeremiah idles the excess threads on a replacement job, and Jolade checked that the new tests cover it. Ready for a final review.
Jolade's job-gap watchdog fix from issue 113, so a connection that gets only unusable jobs is recycled. Review wanted.
Susan's removal of the bitvec dependency.
Wandia's Python 3.11 prerequisite in CONTRIBUTING.md.
Sean's native Windows support for the Bitaxe, rebased last week.
USB hotplug on Windows. asingizwe1, new to the project, offers to write it.
Issues
Three advisories in the zip crate, which Mujina uses only at build time, through utoipa-swagger-ui.
An advisory in tokio's
AsyncFd.The1Anubis's BM1370 measurements on an 8-chip NerdOCTAXE-Gamma, offered for the BM13xx reference. They show how sub-cores roll versions under a narrow version mask, among other findings.
Jolade's report that the backplane stops boards at startup when the only transport closes. Still to be converted into an issue. (follow-up from the last call)
Telegram channel
Open floor
All reactions