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, Dylan, Jayr, Schnitzel, and others. Referenced but absent: Jonathan, Susan, Tyler.
Summary
Mining Illustrated at Bitcoin Park (02:16)
Ryan and Skot called in from the podcast studio at Bitcoin Park in Nashville, where they ran the Mining Illustrated workshop that evening. It is the workshop Ryan first ran in Nairobi; people he taught there have since held it across Africa. The room mines on a private Bitcoin test network from Ryan's devpool stack: a Bitcoin node, a mempool.space instance, a dashboard, Hydrapool, and instruction pages, all in containers. Bitcoin Core and Hydrapool are patched for very low difficulty (Hydrapool accepts fractional difficulty), so CPUs and Bitaxes find a block about every 30 seconds and the network readjusts within a few blocks. The slides go to the repo after the workshop.
The Stratum V2 working group (05:09)
The 256 Foundation joined the Stratum V2 working group (post). Ryan and Tyler attended its monthly call, where the members, mostly large firms such as Braiins, Foundry, Mara, and Block plus the SRI developers, worked through security issues filed by AI red teams. None of it bears on Mujina yet, since the SV2 implementation is not in mainline. The foundation backs SV2 as the well-defined protocol that answers long-standing SV1 feature requests. Its optional job declaration is the open equivalent of Datum, letting a miner pick its own block template while mining to a pool. SV2 in Hydrapool is a wish, not work underway.
RHAP: Raw Hardware Access protocol (09:55)
Ryan forked bitaxe-raw into rhapd-bitaxe-gamma, a 256 Foundation repo holding only the pass-through firmware for the Bitaxe Gamma. The protocol that bitaxe-raw and the EmberOne firmware both speak now has a name, RHAP, the Raw Hardware Access Protocol. RHAP-D is the device role, so the repo is the RHAP-D implementation for that board. The protocol is unchanged. The fork gave Ryan room for board-specific behavior he had held back to avoid disturbing other users of bitaxe-raw, such as booting with the regulator off and showing a sign of life on the display. Each board's firmware stays its own repo under its own name; only this one has RHAP-D in its name because it exists solely to serve the protocol. Skot endorsed the split as a way to avoid the Stratum V1 fate of a protocol defined by its implementations. Ryan will pull the protocol definition out of the README into a standalone spec. The Bitaxe Gamma branch of bitaxe-raw is retired; its other hardware branches are untouched.
RHAP beyond the Bitaxe (17:45)
Skot wants RHAP ported to a Linux program on stock control boards, taking commands over the network, so Mujina on a development machine could drive an Antminer or Whatsminer without flashing its encrypted filesystem each time. He has written bespoke versions of that peek-and-poke tool half a dozen times. Dylan's agent had struggled to explore his K Pro and would welcome the same. Ryan may split the RHAP client out of Mujina into its own crate with a small CLI, a Rust library first and possibly a Python one later. Schnitzel raised fleet use: several boards running RHAP behind one Mujina instance, appearing as one device to the pool and to Home Assistant. Ryan sees no reason RHAP could not run over Ethernet, with latency the open question. Skot added that an Amlogic control board could serve as a Bitcrane, cheaper than the real thing given the e-waste supply.
The multi-chip BM13xx driver, first half merged (23:57)
Ryan merged #105, about 7,000 lines in 78 small commits. He reviews by commit, not by PR, so a PR is the point where a long-running branch joins the tree, and these commits show the granularity he wants in other people's PRs. The work rewrites the Bitmain chip driver from a Bitaxe prototype into one driver for every chip on every Bitmain miner, layered as a typed chip module, a hash thread that drives a chain of those chips, and board files that declare only what is unique to a board (chip model, chain lengths, voltage domains, other hardware). About half the work is in. The other half, mostly board files for the S19 and S21 and the common-code fixes they expose, is still in flight, so Schnitzel will hold off rebasing his branches on it.
RHAP-D support in Mujina (31:41)
#107 is small because the protocol did not change. The RHAP-D firmware reports the VID and PID allocated to Bitaxe and its own product string, so the Bitaxe board file gains one more USB descriptor to match on. The bitaxe-raw descriptor stays, so boards already flashed keep working. The modules named bitaxe-raw inside Mujina get renamed for the protocol later. USB discovery does not apply to native control boards, whose hash boards hang off the Bitmain IO mouth, but the same drivers serve either path, which is the point of the transport abstraction.
Susan's first contribution: inline CRCs (37:51)
#103, Susan's first PR, replaces the crc_all crate with about ten lines of CRC code in the Bitmain driver. It closes out one item of the dependency-reduction issue, #29, marked as a good first contribution for people without hardware. The crate was unmaintained, though not dangerous; dropping it is a small, clean win and the kind of change Ryan recommends for getting started.
Jonathan's h2 update, and cooldown versus advisories (39:50)
The nightly advisory scan filed #101 for RUSTSEC-2026-0258 in the transitive h2 crate, low severity. Jonathan, a first-time contributor, opened #104 to bump it, and the PR exposed a bug in cargo-cooldown: a targeted single-package update slipped through with a version younger than seven days. Ryan is working that out with him in the PR and will merge once the cooldown has passed. Jayr asked how the two mechanisms relate. The cooldown refuses any crate release under seven days old, since a poisoned upload is usually caught within hours or days. The advisory scan is separate: it checks the lock file against the RustSec database nightly and files an issue, taking no action. They meet when an advisory calls for an upgrade, and a person then decides whether the bug is serious enough to skip the cooldown or can wait it out.
SV2 series: channel type, SRI feedback, test dependencies (49:37)
#65 stays near the top of Ryan's list, half reviewed, and the working group membership adds urgency. Jayr raised three points. First, the series uses extended channels because industrial miners could exhaust the 16 version-rolling bits, but the BIP Jayr identified as BIP 323, expected with Bitcoin Core v32, widens the field to 24 bits and raises the ceiling to about 72 PH/s, so standard channels may suffice. Ryan's concern is work division: extended channels split cleanly across many hash boards through the extranonce, standard channels less obviously, and no current chip rolls the new bits in hardware, though the host could use them to divide work. Solvable, not trivial. Second, after a retreat with plebhash and another SRI developer, Jayr will drop two messages that are in the spec but unused. Third, the SRI integration-test framework brought heavy transitive dependencies and a large Cargo.lock change. Both find it heavy; Ryan has no final view on whether test-only dependencies earn a pass.
Security PRs become issues, and wrap (58:29)
Schnitzel's three red-team PRs (#90, #98, and #99) will become issues, since each points at a real defect that fits the code differently than the patch. Schnitzel is fine with that. No new reports arrived, his agent having found juicier targets elsewhere, but Ryan expects more of the same class, malformed pool input, in every miner. The call ended near the hour, with the recording stopped so newcomers could introduce themselves.
Action items
Transcript
Full transcript on the wiki: https://github.com/256foundation/mujina/wiki/dev-call-20260831
Agenda (as planned)
Agenda
Meeting: Monday 2026-08-31 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
crc_allfor inline CRCs. Part of refactor: reduce dependency count #29.h2update for RUSTSEC-2026-0258, waiting for cooldown.Issues
h2. PR 104 closes it.Discussions
Forum & Chat
Follow-up
Still open from the last call's action items:
Still open from 20260803:
Other
Open floor
All reactions