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), Ronald, Skot, Johnny, Schnitzel, Brett, Dylan, Tyler, Susan, and Eco. Referenced but absent: Jayr, Jeremiah, Andy.
Summary
Cooldown review, MIP-0001, RHAP, and retiring bitaxe-raw (00:00)
Ryan said BZM2 support would take the second half of the call. He followed up on two items from the last call. The cooldown PRs, #104 and #109, are merged and still open to retroactive review. MIP-0001, 256foundation/mujina-mips#1, is now merged, so it sits in the file tree of the mujina-mips repository instead of in a PR.
Ryan created 256foundation/rhap to hold the RHAP specification and any generic client libraries. He repointed the Mujina documentation and the website (see Set up a Bitaxe Gamma) from bitaxe-raw to the RHAP-D firmware for the Bitaxe Gamma, rhapd-bitaxe-gamma, after an issue or two showed that people were still building the old firmware, which lacks the new safety features and had build problems. His PR on bitaxe-raw, bitaxeorg/bitaxe-raw#19, marks the Gamma branch as unmaintained and proposes another hardware branch as the default. Skot agreed. Skot asked whether bitaxe-raw is needed at all; Ryan said the BIRDS and Bonanza branches still live there and did not move. Skot and Johnny will look at the repository so there are not too many copies of the same thing.
Red-team PRs and testing SV2 (08:18)
The docs PR, #112, will be merged later today. Ryan is working through Schnitzel's red-team PRs: he fixed the urgent ones right away and is turning the rest into issues where they point at a larger problem. #90 and #98 became issues 113 and 114, and #99 is still open. Schnitzel offered to retest once the fixes are in. The official Bitcoin red team also sent Ryan a list of findings, many of them duplicates, which he is handling the same way.
Ryan has a review ready for Jayr's SV2 PR, #65, and will post it by the end of the day. Jayr asked for testing against an SV2 pool. Hydrapool does not support SV2 yet, but the SRI project ships its own pool (Brett linked stratum-mining/sv2-apps in the chat), and CKPool and Public Pool offer SV2 endpoints. Schnitzel will try it in his lab. Jayr's fan speed controller for the Bitaxe Gamma, #33, also needs someone to test it with the RHAP-D firmware.
Reporting upstream errors through the API (13:29)
#113 generalizes several red-team findings. When a pool misbehaves, Mujina sometimes logs the error and quietly stops mining. The issue proposes health status and readable fault conditions in the API tree under each pool, in addition to the log.
Brett separated logs, which hold history, from current status, which is what a user wants to see. Transient and per-message errors belong in the log; deterministic errors and hardware faults, such as chips failing to initialize, belong in the status. He would like at least a message and a level for each, and a logs endpoint in the API. Many firmwares, Whatsminers among them, reboot or silently drop to zero on an error. A user-controlled watchdog that reboots up to some number of times on a recoverable error could be worth having. Schnitzel said his fuzzer found the same pattern in every firmware he tested: they reboot or pretend nothing is wrong while the hashrate falls to zero. He offered a report on how the other miners behave and said the proposal would put Mujina well ahead of them.
A scheduler panic from a small extranonce2 space (22:34)
A pool can give a Stratum v1 client as little as one byte of extranonce2 space. If the scheduler then splits the job across more hash threads than the space allows, it panics. That takes CPU mining with many threads, but Ryan does not want any panics, so he filed #114. Schnitzel said his agents had to search a long time to find it, where other miners panicked on the first odd message. Jeremiah offered to fix it. Ryan thanked Jeremiah for his reviews.
Mujina mining on Ronald's Intel RDS (24:38)
Ronald is superseding his four stacked PRs. After the last call he decided to test them on his Intel RDS machines, 300 ASICs each, for which he has the full firmware source. He published the BZM2 hardware reference as a website, revised with what mining taught him. The RDS on his screen had mined on Ocean for an hour and 25 minutes at about 106 TH/s, all three hash boards on Mujina.
He is splitting the work into three sets: BZM2 support, RDS support on top of it, and fixes to upstream Mujina that his work ran into. Three things remain. Mujina must calibrate the ASICs itself (he still uses Intel's software, and a test of Mujina's was running during the call). He needs a clean RDS image free of Intel's OpenWrt code. And fan control needed a PID on the tachometer, which he will send upstream separately. The debug telemetry, 187 MB of logs in two hours, will sit behind a flag.
A dashboard, and sharing noisy AI work (32:52)
Ronald's dashboard is not part of Mujina. It is a Start9 plugin: the miner exposes a lean API stream, and the Start9 or Umbrel box does the heavy lifting. Brett said ASIC-RS should support it and asked whether Mujina wants a dashboard. Ryan said yes, out of the box, once the S19 and S21 images are published.
Ronald asked how to share work that his AI workflow develops in local repositories, since it opens and closes a hundred issues a day. Ryan and Schnitzel said to publish it in his own repository and send a link. Schnitzel has his own Mujina UI on GitHub, and whoever takes on the UI can combine ideas. Brett suggested telling the AI to write in ASD-STE100 Simplified Technical English.
Satoshi Starter and the hash bed (36:40)
Next for Ronald is getting the Satoshi Starter prototypes hashing on Mujina. It is a USB miner, run from a desktop, a Start9, or perhaps an Android device. The other first consumer is the hash bed from Proof of Print, 9 to 16 ASIC boards that heat 3D printer beds, whose hardware is not quite done. He also has some Bitaxe boards to test on.
Bitaxe Bonanza and EmberOne (38:11)
Skot said nobody is working on BZM2 for EmberOne. The active effort is the Bitaxe Bonanza, a Bitaxe with four BZM2 chips in the form factor of the Bitaxe Proto. Revision 1002 is out and working, and Skot is building 1003. BIRDS was only a test board for early BZM2 work.
Johnny's focus is ESP-Miner on the Bonanza. Early in the summer he had Mujina working against BIRDS and the Bonanza through a Mujina-compatible bitaxe-raw variant, which he now needs to adapt to RHAP. He has no target of his own for Mujina, so he closed his BZM2 PR, #41, and will not champion one. He will help Ronald, add Bonanza board support the way the Bitaxe Gamma is supported once the hardware settles in a month or two, and review the Bonanza implementation. Ronald asked where to send his PRs; Ryan said the Mujina repository.
RDS units for developers (43:37)
Intel built perhaps 30,000 to 40,000 RDS machines, and they shipped commercially. Ronald has 24 and wants to get some to the 256 Foundation and make others available to grant recipients at cost. As a miner the RDS is not worth much today, but it is a 100 TH/s machine whose firmware can be rebuilt on the stock control board, with the ASIC's pins and registers documented. A grant recipient with one can test software against a system known to work, instead of wondering whether the fault is in their own board. Ryan would like a couple for 256. Ronald knows which companies hold them.
One chip driver, many boards (46:26)
Ryan wants BZM2 to follow the BM13xx pattern, where one chip driver serves the Bitaxe Gamma and the S21 through separate board implementations. The Bitaxe Bonanza would be the smallest board, with board support for the RDS, the Satoshi Starter, and Andy's hash bed on the same driver. Ronald does not need his code to win, but whatever is merged should expose every register and pin, and he needs voltage and temperature sensing to work. Ryan said Ronald's effort is now the only one, so it is the main line and the others will contribute to it.
Next steps and a million chips on reels (50:19)
Before the next call, Johnny will post what he has for the Bitaxe Bonanza (the bitaxe-raw implementation and how to make it work) in a discussion or on the forum. Skot has an RDS and can lend it to someone nearby who can run a loud 220 V miner, to review Ronald's work. Ryan would like an RDS and a Bitaxe Bonanza to help vet the drivers. Skot plans to build a batch of the Bonanza revision he is working on and get it out to people, paired with Johnny's firmware.
Skot said more than a million new BZM2 chips sit on reels in a warehouse. A compelling case, with many people building on them, could get them out. Ryan said this shows what the 256 Foundation is about. Good reference hardware and Mujina support out of the box give anyone a head start, for heat reuse and other prototypes. Ronald wants BZM2 with a true PID to change how heat capture systems are built.
Action items
Transcript
Full transcript on the wiki: https://github.com/256foundation/mujina/wiki/dev-call-20260928
Agenda (as planned)
Agenda
Meeting: Monday 2026-09-28 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
Retires bitaxe-raw for the Bitaxe Gamma: replaces the tree on
mainwith a notice pointing Gamma users to rhapd-bitaxe-gamma. Skot: renamemaintobitaxe-gammaand makebitaxeProtoorbonanzathe default?PRs
Points the README, the Bitaxe Gamma board guide, and the architecture doc at rhapd-bitaxe-gamma.
Schnitzel's retry on a rejected authorize, a red-team finding from hostile-pool fuzzing. Jeremiah's review found a test gap. Bears on issue 113 below.
Schnitzel's validation fixes, also red-team findings, closed in favor of issues 113 and 114, which take on the general problem.
Jayr's Stratum v2 support. Jayr asks for someone to run it against an SV2 pool.
Jayr's PI fan controller, rebased and waiting on review.
Jeremiah's h2 update, which exposed the broken cooldown tooling.
Replaces the tooling with cargo's own minimum publish age.
The plan for when cargo 1.100 stabilizes the setting.
MIP-0001, the configuration and REST API design, is merged, so it is easy to find in the MIPs repository. (follow-up from the last call)
Issues
How a job source should report upstream errors through the API and latch faults, instead of only logging them. It grew out of Schnitzel's red-team PRs 90, 98, and 99, which came from a review of pool-facing input and from hostile-pool fuzzing.
Scheduler panic when the extranonce2 space is too small to split among the hash threads. Jeremiah offered to take it.
BZM2 support
Where each effort stands and how to get one series upstream. Ronald (RDS port, PRs 68 through 71, Satoshi Starter), Andy, Aadhi, Skot, and Johnny9 invited.
Board infrastructure: per-board command channel, power-rail primitives, thread telemetry types.
BZM2 chip layer: protocol, UART, clock, hash thread.
BZM2 board driver with calibration and runtime tuning.
BZM2 diagnostic endpoints and the port notes.
Johnny9's BIRDS board and BZM2 modules, closed to be redone on the Bitaxe Bonanza and bonanza-bridge.
Ronald's earlier attempts, replaced by the series above.
Open floor
All reactions