Repository navigation
dev call 20260928
Jitsi: Recording is on.
Ryan: Why does it take 10 clicks? Okay. The old man found the button. Welcome back, everybody. Another bi-weekly Mujina Dev Call. As you just heard, we record these and transcribe them. So if that's a problem, be aware. And... Welcome, Skot.
Skot: Hello, hello.
Ryan: We're just getting started. Right. Oh, hey, the gang's all here. Perfect timing. So, the point of these calls is to just go over what happened the last two weeks since the last call, keep everybody informed, have live discussions that are easier to have live than online. But we try to transcribe everything and go back and make comments on the appropriate GitHub items, et cetera, because we don't want, this isn't really a replacement for our other communication channels. So we will start with host choice topics and then go through PRs and issues and such. So I want to get to talking about BZM2 support on the back half of the call here after we get through the easy stuff, which is... Especially glad to have Ronald here and Skot and Johnny and everybody who knows the status of BZM2 hardware and software. And we'll get to that in a little bit. Let's see. I just wanted to point out, again, following up from last week, that I had merged some changes to the cooldown dependency checking features and invited anybody to take a look at those. They're already merged, but you're welcome to look at that and comment. That's our defense against supply chain attacks. Also following up from last week's call, I went ahead and merged over in our MIPs repo. I went ahead and merged that configuration spec and Just because it was sort of hanging out in a PR before and was making it hard for people to find. And we didn't really have any major revisions. So now it's right there. If you visit that repo, it's staring at you in the file tree. I also, following up from last week or a couple weeks before this, I created a new 256 Foundation repo for the RHAP protocol, R-H-A-P, because I wanted a place to repoint some stuff. So this repository is meant to be... Here, let me just click through. It's really just sort of a placeholder at the moment. But this is going to hold the specification. And if we come up with any generic library implementations of this, like I warned about before, maybe there's room for having a Rust or Python library with a CLI client or something. Maybe if those are generic enough, they can go in here. Because what I did was sort of repoint all of the documents in Mujina that previously talked about bitaxe-raw over towards the RHAP page. Bitaxe firmware that we talked about two weeks ago because I had not changed the documentation. And so we got an issue or two, someone was asking like, someone was obviously trying to use the old stuff and either, which didn't have some of the cool off, don't burn your fingers features that I had added to the new version. And there was also some build issues with the old one. So it was just obvious that people were still using that bitaxe-raw repo for the Bitaxe Gamma stuff. And so I repointed everything I could find, also on the website, to point at this new version. And then, Skot, you may have seen I put a PR in the bitaxe-raw repo, which is... Either under your organization or under Bitaxe, I forget which. Just proposing that maybe you put one of your other hardware branches as the main branch or something. And I also put like a readme in there along the Bitaxe Gamma branch that that version was sort of obsolete and not maintained anymore. I don't know if you saw that, but...
Skot: Yeah, I did. Yeah, I can do that.
Ryan: Do you have any thoughts? Okay, yeah, whatever you think. The basic idea is, as everyone here probably knows, we sort of moved the Bitaxe Gamma version of bitaxe-raw over to its own repository. But there are still other boards using bitaxe-raw firmware that were on other branches in that other repository. And we're not moving those.
Skot: So RHAP-D Bitaxe Gamma is totally working for Bitaxe Gamma. Yes. So it's no big deal to just point the whole thing there, right? Do we need the bitaxeorg bitaxe-raw for anything?
Ryan: Well, there were still branches... On that repo for BIRDS and Bonanza. Okay. So I think, I assumed that you guys were still using that firmware on those boards in those branches. So I, and I didn't take those branches over with into the rhapd-bitaxe-gamma repo.
Skot: Okay. Johnny and I can take a look at that. We just don't want to have too many
Ryan: Repos with essentially the same thing. If you're talking, Johnny, you're muted.
Johnny: Oh, okay.
Ryan: Sorry. And I already mentioned this. Yeah, I changed our website too. PRs. So this repeats what I just talked about. These are the PRs to repoint documentation. I guess I didn't merge this one yet. And you can review that if you want. There's not much to review. It's just documentation change. So I'll probably merge that later today.
Ryan: Schnitzel, I finally got around to some of the other red team PRs that you submitted recently. I fixed a couple urgent ones right when you submitted them, and then the rest I was sort of wanting to reinterpret as more generic bugs to be fixed sort of later. So I finally got around to taking a look at some of those. Let's see. Is this one of them that I moved? Let me check the comments. This might be the one that survived that I haven't done yet, but it stayed in the list. These ones below it, number 90 and number 98, I rolled up into issues 113 and 114, which are discussed below. So anyway, I'm still working through those PRs, either taking them or changing them into issues because they represent something larger.
Schnitzel: Cool. Yeah, I mean, let me know when you feel like I should do a retest, but just to make sure that it's all closed. But yeah, sounds good.
Ryan: Also not listed here, but the official Bitcoin Red team sent a list of things also that I signed up in their system and got access to and downloaded. And a lot of them are duplicates of stuff we already have here. But I'm still working through those, doing the same thing with them, sort of turning them into issues if they need to be. Next, number 65 here. I don't see Jayr on the call, but this is his SV2 PR. I finally have a review for you, Jayr, when you're reading this in the transcript. I will try to get it all posted by the end of the day. Also, he rebased this a couple weeks ago and asked for testing. So if anybody wants something to do, they could run that branch against a SV2 pool. I will also be doing that.
Schnitzel: Do we have an open source SV2 pool?
Ryan: Do we?
Schnitzel: I mean, is there one? Because Hydrapool doesn't have support for it yet.
Ryan: Hydrapool doesn't have support for it yet. Open source, if you want to run your own, yes, the SRI group has their own distribution. I think they call it SV2 UI or something, which is sort of a front end that will run a pool. And then if you don't want to run your own pool, of course, I think CK pool has a SV2 endpoint now. Ocean Demand might have an SV2 pool. I don't know. There are several out there.
Skot: I don't think Demand is open access, but I think Public Pool has one now too.
Ryan: Oh yeah, Public Pool. That's what I was thinking of.
Schnitzel: Okay, right, because I have my whole lab, so I shouldn't be very hard to install that Mujina version and point to it. So I will try as well if I find time to test the SV2 pool stuff. Okay.
Brett: I'm finding the link for it. It's under stratum-mining/sv2-apps. Oh, apps. Yeah, I'll link it here.
Ryan: There's also a fan speed control for the Bitaxe Gamma PR that is probably ready to go if we could get a little bit of testing on it. So that's something that someone could do if they had a Bitaxe Gamma and wanted to try out the RHAP firmware.
Ryan: On to the issues list. These are the new ones. These are the ones I made out of a couple of your Red Team PRs, Schnitzel.
Schnitzel: Yeah, they look familiar, yeah.
Ryan: Yeah. So I sort of generalized a couple of them into this general problem where... We don't really have a good way to report errors and manage faults that happen sort of asynchronously. So like the miner's running, the pool starts, one of the pools it's connected to starts misbehaving or sending garbage in the case that Schnitzel was testing. We logged some of those errors. Some of them we missed, but some of them we just kind of logged and quietly stopped mining, let's say. So this issue sort of generalizes this problem and talks about how we sort of want to handle that, handle errors like this asynchronously. And I guess the bottom line is just we need to make sure that these become visible in the API tree so let me go into one of these because I think oh I thought I drew a little tree here but I didn't this issue sort of talks about the problem it's not terribly prescriptive about how to fix it but I sort of get at the idea of like you know underneath the part of the tree that's talking about a particular pool, you know, we'd have some status flags that shows if it's healthy or not or if there's a fault. And then we could also have, if there's a fault, have some conditions attached to it that would be like a readable thing that a UI could put in its display next to that pool or something like that. Anyway, it needs to get surfaced in the API in addition to showing up in logs perhaps. And that was sort of a missing feature at the moment. So that's what that issue gets at. Any comments on that? Maybe Brett, is that consistent with what you see other miners do?
Brett: Say again? Sorry, I was half paying attention.
Ryan: Oh, that's okay. We're just talking here about how we report asynchronous errors. Like, for example, with the pool, maybe a pool connection drops.
Brett: Okay, yeah.
Ryan: Or for some reason goes bad, we're basically proposing to just have fields in the API underneath the pool that sort of give a health status and perhaps messages that would be user visible
Brett: Yes, there's a couple things here right there's logs, which is like historical errors and then there's like real time quote unquote statuses so if the pool is currently failing we can't get any shares out something is actively wrong, we should have an API endpoint for that specifically. Because that's what the user wants to see. They want to see something is currently wrong with my miner right now. So there should be something for that. But then, oh, it's like a transient pool failure that happened half an hour ago. That's something we want in logs. And we probably want to be able to access those logs at some point and log those at an error level. But yeah, I think we really only care about instantaneous. At this point in time, there is this error going on or this set of errors. Not necessarily consistent with what other people do, but also what a lot of other firmwares do is kind of bad.
Schnitzel: Yeah, I just wanted to say, I ran this fuzzer against all the firmwares, and they are just rebooting. They're pretending nothing bad is happening, but suddenly the share, the terahash is at zero. So yeah, I think what you're describing, Ryan, makes a lot of sense, is to have an API level to saying, is it currently working? And then very descriptive logs. If you want, I mean, I'm happy to create a report on what all the other miners are doing, because I have all that data still, if it's in any way interesting. But from a high level, I think doing what you're proposing would basically bring Mujina way, way, way ahead of everybody else.
Brett: And one of the other things that you kind of mentioned there, Schnitzel, is like a lot of the other firmwares, and this depends on the case, like Watts Miners, I've seen this a lot. They'll get into an error state and then they'll just like instantaneously reboot. So for some errors, they just instantly reboot. For other ones, they'll lock up and go to zero. It's sort of error dependent, but that might be the type of thing where we wanna have like a quote unquote watchdog that the user can enable or disable. And what that watchdog just does is if the miner gets into a state where it's an error and it's an error that we think we can actually recover from, we just reboot the miner to try to get it working again. Things like that. Or reboot the miner up to n times or whatever. I like the idea of being able to report the errors, like current errors at an API endpoint. It's really useful. I don't know how you want to structure that. Like if you want to have error codes and those error codes are mapped to error messages and maybe you send both. Me personally, I would like to see at the very least messages and levels. So you might want to have an info message for like, I don't know, I'm trying to think of what you would have an info level message for, but it's essentially the same as having a log of things happening instantaneously. So we have a critical, like, oh, this miner, the voltage is showing way too high on this one board, and we don't know why, or whatever, right? Things like that. That's just my thoughts.
Ryan: Yeah, good. That's pretty consistent. I think we're pretty well set up for the logging part of this, and... That's a lot of what already happens, although the log is not easily accessible over the API. That needs to change.
Brett: Yeah, that's easy enough. You just add a slash logs endpoint somewhere.
Ryan: But yeah, it's more the sort of real-time reporting and handling within the software. So I was looking through the issue to see if I sort of broke down somewhere some thoughts about how some errors are... Like connections errors are things that it ought to just sit there and retry on its own. Some things are sort of permanent, right? Like your credentials aren't working. That should be retried every second, you know, obviously. So some errors are more permanent than others and may be handled a little differently because of that.
Brett: Yeah. And a lot of those errors that you'll, you'll want to report on, like looking at this, this issue. Yeah. You don't really care about the transient errors. They end up in a log. The per message errors are also kind of transient. So like you might as well just throw that in the logs. The deterministic errors are the ones that you want to display to a user along with anything hardware related, right? Like if it's a hardware issue and we can tell it's a hardware issue, like chips are failing to initialize or whatever, that type of stuff. Those are, sort of what I would consider deterministic errors, and those are probably what we want to report. Right.
Ryan: Okay. So, yeah. I mean, a lot of these red team findings are things that come from like malformed fields coming from the pool or otherwise bad behavior. And obviously all the little, we need to handle all the little cases, but we sort of didn't have a way to handle a lot of the things in general. So that's what this issue represents.
Ryan: And then another one coming from the red teaming was, there was this weird case where if, so in Stratum V1 at least, the pool can pick how much extranonce space there is. Typically gives you something like eight bytes, but it can, in theory, give you something smaller, like only one byte of extranonce space. And the way Mujina was splitting jobs up among multiple hash threads, it actually panicked if it had more hash thread, like if you were... It would only be a weird case where you were CPU mining, and so the scheduler was trying to spread out the job over more than 126 different threads, and was only given one byte by the pool to do that in the extranonce space, and it would panic. So that's a filed bug for that. Sort of a weird case, but we shouldn't have any panics.
Schnitzel: This was me telling my agents, go as long as you have until you find a kernel panic. Because every other miner, they immediately panicked, even if you just sent them something weird through the stratum protocol. And here I really had to find one really long. So here we go.
Ryan: Yeah. I mean, it's quite the corner case, but I don't like panics anywhere. So we'll get that fixed. Jeremiah, I think is his real name, already sought out and offered to work on it. So he also did a number of reviews on PRs. So I just wanted to point out, thank you. And it's always valuable when someone reviews stuff. That's all the happenings, the simple happenings I had over the last two weeks.
Ryan: So right on the 30-minute mark here, let's go into feature discussion for this week. BZM2 support. So Ronald joined the call last week and was asking some questions about just what the status was all around on BZM2 drivers. Who was working on what, where, kind of what state was it in? Because he's been doing some stuff on his end and was interested eventually in getting that urged into Mujina. And I said... Yeah, we should have a discussion because it would be nice if we can sort of funnel all the work into one sort of mergeable stream and get everybody cooperating. So maybe we should start with Ronald because I know he's got a lot of, he's been doing a lot of work lately. So I'm interested in seeing what he's got going and what he's working on and we'll start there. And you're muted, I think. Or is it me? Did I lose my microphone?
Schnitzel: No, I can't hear you. No, you're good.
Ryan: Oh, okay. I can hear your minor now, Ronald. I think you're back. He's got a minor fan whining in the background.
Ronald: There you go. I blame Jitsi.
Ryan: Yes. Always fair.
Ronald: It said it was unmuted, but it wasn't.
Brett: We could hear your minor. Was it noise canceling your voice instead of the minor?
Ronald: That'd be hilarious.
Brett: That would be funny.
Ronald: Yes what you hear is actually downstairs one of two Intel RDSs mining right now so I try to get this stupid PR fully functional also I lost my voice at the Midwestern Bitcoin Summit so apologize for being raspy it's not much different if you know me it's just actually a lot deeper so that's ironic I don't know. So I am superseding, requesting to supersede the PRs as submitted. Can I share my screen, Ryan?
Ryan: Yeah, absolutely.
Ronald: All right.
Jitsi: Recording is on.
Ronald: All right. Switch tabs here. All right, can you see that? Yes okay so we got the E6 I had ai draft up a really lousy ai slop set of PRs caught a bunch of years when I switched to feeble revise those PRs, which is unnecessary thrash on the Mujina side. I apologize to you guys for that. And during last month's call, I had the realization, well, I've got all these RDSs, and I have the source code to rebuild their whole firmware. Why not dogfood my PRs on actual 300 ASIC rigs? So this is... The result of that, off and on for about a month, whatever the last call was, we already had a BZM2 hardware reference that we had gotten approval from Intel legal to publish.
Brett: Sorry.
Ronald: I built up a website. Why do I build a website? It's not searchable. You can go through the entire thing. Everything you should need. It's been revised for the last week with results from actually mining. And escapes documentation that we had omitted and missed or had inaccurate. As far as I can tell, this is fully accurate and almost completely comprehensive now. And it looks way better than just a GitHub repo. It's still backed by the GitHub repo. It's nothing new. This is just a pretty boilerplate. Second part, right, is that so we got this timeline. And I've written up, I've had a working, a running log notebook as we try to get the Mujina software to mine on the RDS. So I'll post this link. You guys can read it if you want. It's a lot of AI slop. The end result, and I didn't have, I didn't want to reuse the Intel interface. So I wrote one. This is the RDS you're listening to right now. So this is 100 terahash, 106.68, mining on Ocean for the last hour and 25 minutes. All three hash boards, 100% on Mujina.
Skot: Very cool. Nice.
Ronald: And then the actual logs. So there's some flakiness, of course. I am still using the Intel software to run the calibration. Mujina could not calibrate 300 ASICs. It can now. That's actually what it's currently testing. So I've broken up what it's building right now into three sets of PRs. One is just BZM2 enablement. One is just RDS enablement. Obviously, it's gated by the BZM2 enablement PR. And then the third one actually touches on some of the issues you mentioned earlier, where upstream Mujina bugs that were gotchas and blocked our work. And so I have a separate set of fixes that are your request to evaluate for upstream Mujina. It's working it's working at high hash rate on a real production box I've got 24 of so I would love to get this finished and so remaining steps we have to get I have to this current test if we can get Mujina to calibrate the asics then I have another session that's building a clean room image that has no dependencies on any code don't know the OpenWrt that Intel shipped so this is just a clean rds image with Mujina some telemetry so I could do this kind of high level debugging obviously not everyone's going to want all the details So right now it's generating for a two hour test, 187 megabytes of log output, but the actual production is like 0.8 megabytes. Right. So during a lot of log output telemetry, we'll have that gated by a debug flag. But, I need the new firmware image complete and I need, Calibration. And there were some issues with how Mujina was managing the tach on the fans. So I've kind of forked off some of how we manage cooling to do the PID that I need. And that'll be an upstream Mujina PR separately. That's it.
Ryan: Well, very cool.
Brett: Excellent work. That's awesome. That UI isn't in Mujina, is it?
Ronald: No this I built from scratch because I needed something actually this is a Start9 plugin that I'm running standalone so the goal is you'll have your Start9 launch this and the miner itself has just a bare bones interface with a heavy API stream that your Start9 or Umbrel will pick up on and then the heavy lifting because this is going to have these graphs are actually live they're just not working correctly So all the heavy lifting and large amounts of data are on your Start9 rather than on a, you know, minor with minimal CPU and RAM constraints.
Brett: Sweet. It sounds like we need to get some support for this into ASIC-RS at this point. It looks like it's getting about that point. So it'll be easier to build those types of dashboards. But out of curiosity, is this, would we want some sort of dashboard like this in Mujina, Ryan, at this point, or is it kind of too early for that? Even just something simplistic.
Ryan: We're getting close. When we publish the S19 and S21 images soon, we'll want a dashboard in there out of the box. Yes.
Ronald: Well, my plan is to contribute this separately, right? It's a separate Git project entirely. And it's not public because I didn't want to... I've got too much. That's the other request I have for you guys. AI workflows are noisy. So I have everything running from local Git repositories because it generates like 100 issues a day and closes them. And some are stupid verbose, like some of the comments are longer than the commit itself. And it's inefficient. And I don't think humans want to review that. But the end products, as you snapshot them, and I don't know what the right workflow is for that. This is a cool dashboard. I think it's got legs, and it could actually be durable across a wide variety of things, not just RDS test. But I don't know what the best way is, like if you guys wanted this, I'm happy to contribute it, but I don't know how to get it to you without it being noisy as the AI continuously develops it until I hit a wall of running out of tokens and that starts up again in five days.
Ryan: I don't know, probably just start by if you publish it somewhere public and send us pointers to look at it.
Schnitzel: Yeah, I think that was my suggestion as well. I also build Mujina UI just for myself for usage, and I think it's on my GitHub repo. So yeah, just publish it into your own GitHub repo, point to it, and then whoever on our side takes over the responsibility to build a UI maybe can look at these different ideas and come up with a combination of them.
Ronald: Yeah. Yeah, that makes sense. I'll make it public.
Brett: Sorry, just to make a comment on your AI writing stupid long issues that are impossible to understand, I heard a tip on that, which is that you should have it, just tell it to write all the issues in ASD-STE100, Simplified Technical English, and it'll make them a lot less sloppy, at least, and they'll be easier to read.
Ronald: Yeah, I'll try that.
Brett: Yep.
Ronald: But it's working.
Ryan: Yeah, no, that's super cool. I would love to see... Yeah, if you publish branches for this in your own repos, even before you massage them into PRs for Mujina, I'd love to see it if you drop a link in there. Discussion or PRs or somewhere
Ryan: Stepping back big picture so you've you're doing this for rds which is cool how does Satoshi Starter fit into this like what are your other projects
Ronald: Yeah so the next steps now that we have this more or less functional is to get the Satoshi Starter prototypes hashing using Mujina. My goal, since that's a USB miner essentially, right, is that you'll be running Mujina on either a desktop or on like a Start9, or I'm hoping to be able to have it working on like an APK. So you could actually expose the serial console through that and power it. And then the hash bed, right, that Proof of Print is working on, that's the other primary consumer of this is their nine to 16 ASIC hash board heating beds for their 3D printers. And they are gated by software as well, although their hardware is not quite done yet. So those are two first consumers other than the RDS. I also have a few of the Bitaxe Protos that I'll be testing on as well. And I guess Bitaxe Bonanzas, right? I haven't even tried looking at those yet.
Ryan: Cool. Well, maybe that's a good segue over to Skot and Johnny then.
Ronald: Yeah, and that EmberOne, Skot?
Ryan: I've sort of lost track of what all the efforts are with the BZM2 chips and how that differs from proto chips and all the other things, so... Yeah, over to you guys. That's in the works.
Skot: Yeah, so we haven't made any progress on EmberOne with the BZM2 chips. That's a future thing that would be nice to have, but it's not actively underway at the moment. What is actively underway is Bitaxe Bonanza. So that's a Bitaxe with four BZM2 chips. And, you know, on the hardware side of things, I'm working on a new revision right now. We have a released hardware revision 1002 that's out and working. And there's... Going to be some nice things added in 1003. Am I right with those numbers? I think I'm right with those numbers. That I'm working on now. Johnny's been doing a ton of work on the firmware for that. But basically pulling it into the same, on the hardware side, pulling into the same form factor as the Bitaxe Proto, which is also working. And this is all posted in the bitaxeorg GitHub organization. So yeah, I mean, the Bitaxe BIRDS was just designed to be a hardware test device for people to get hardware that they could start working on with BZM2 chips, but that wasn't really designed to be a product or anything from my side, at least. But Bitaxe bonanza is that's going to be the that's going to be the Bitaxe with the bzm2 chips and that that is definitely under current development and coming along well I know Johnny you have something you want to say about the firmware on this side of things
Johnny: Yeah yeah yeah I'll I can give an update on where I'm at with this so for me I don't really have a compelling target for Mujina but it sounds like, Ronald, you do. So, I mean, especially with, early in the year, my thought was I thought, EmberOne Bonanza would probably happen this year, but, that's been de-prioritized. So, my focus is entirely on, the Bitaxe side of it, ESP-Miner. But what I can say is that, early in the summer, I had Mujina working well enough against BIRDS as well as the bonanza so we have variation of bitaxe-raw that is Mujina compatible now I need to look at you know your new protocol on bitaxe-raw and adapt what I have to that but Certainly don't mind signing up to help with getting Bitaxe Bonanza compatible if that helps with development of the BZM2. So yeah, if... You know, with a couple of revisions to go, it probably doesn't totally make sense to try to pull requests that in just yet. But certainly in the next month or two, Bonanza Bitaxe will probably be close to finalized. And I can put effort into making sure there's a compatible bitaxe-raw for that. And yeah, over the summer, I closed my BZM2 pull requests because I don't actually have a compelling target for Mujina. Likely won't myself, so I'm not going to be the one championing those pull requests, but can certainly help Ronald with supporting things where I can, especially when Bitaxe Bonanza is settled. I don't mind adding board support for that in the same way that there is Bitaxe Gamma support. But I don't imagine signing up for anything beyond that for the BZM2. That's clear.
Ryan: Okay. Cool. That clarifies things for me.
Ronald: Yeah. So, Ryan, would my new pull request go to you or just tag you and Johnny or what?
Ryan: Yeah, if you submit them in the Mujina repository, I will see them.
Ronald: Okay.
Ryan: I'm sort of automatically tagged on everything, I guess you'd say.
Schnitzel: Can I ask Ronald about these RDSs? How many of these exist in the world, and can we buy them anywhere? What's the status of these?
Ronald: I think we built maybe 30,000 or 40,000 of them. There's a lot.
Johnny: Is there any way we can get our hands on some of them?
Ronald: Well, so I have 24 of them and obviously I can't run them all. So I was going to see if I could, if he gets some in the hands of the 256 Foundation. And then some of the maybe grant recipients, I can at least make them available to them to buy at cost or something. I mean, they're not super valuable today as miners, but they're extremely valuable as a development platform because it'll be like the only 100 terahash shoebox miner that I'm aware of where you can completely recompile the firmware on a stock control board. To run whatever you want with documentation. And if that's not enough and something like that does exist, you're going to get one with documentation for the ASICs and every PIN and every register documented for that ASIC.
Schnitzel: Yeah, that would be awesome. If you are willing to part some of them and donate or yeah, for cost, I think there will be a couple of people that would love just to have something to work against specifically, right? Because as soon as the Bitaxe Bonanza is going to be out, I think the BZM2 chips are going to be more widely adapted. And so if we as the engineers can already start to supporting them from the other side would always be really cool.
Ronald: Right absolutely yeah that is my goal right like I said last month I want BZM2 I know it's old I want to be a reference to teach current ASIC manufacturers what can be done if they also release a little bit of that control to developers to expand their market
Schnitzel: Yeah that's freaking awesome thank you
Ryan: Yeah, that sounds like the right vision. Yeah, we'd love to have a couple of those for 256.
Ronald: And it would help with the grant program too, right? If a grant recipient maybe got an RDS or at least access to one. That helped bootstrap their efforts a lot. Then you're not debugging whether it's my silicon issue, right, and I made my board wrong, or if it's, you know, the hard, the software side, because they'll already have a reference. They can play with their software changes on a system they know works.
Ryan: Yeah. So I'd like to see this shape up. You know, the same way, Bitaxe Gamma and S21, et cetera, shape up. Right. So like in Mujina, I've got one driver for BM13xx family of chips and then there are different board implementations that put that driver onto the system. So that's how Bitaxe Gamma works and S21 works with the same driver. So hopefully we can, I would love to do the same thing with Bitaxe Bonanza as sort of the lowest level, smallest board. And then have board support for RDS, for the stuff for Satoshi Starter, and for Andy's stuff, you know, all being able to reuse the same underlying driver, chip driver.
Ronald: Yeah, I know there's existing unaware, right, paths to getting BZM2 implemented. And I don't need mine to be the one that wins, right? But I do need at least a lot of this. I want the winner to be the one that implements all the functionality that chips expose. So whatever gets merged, I'll at least be adding PRs to extend it so that every register is documented and exercisable through Mujina and every pin, right? Like a, DTS, I really need voltage and temperature sensing to be fully functional. Precise.
Ryan: Well, it sounds like one of the conclusions we're coming to here is your effort is the main line, the only effort. So you're going to win by default at the moment. So, you know, maybe you're leading the way and we all contribute to yours as it shows up is what it sounded like here.
Johnny: Yeah. And actually, that's more compelling than I would have thought in my head. There was only like half a dozen of those boxes. Oh, no.
Ronald: They were shipped commercially.
Johnny: Yeah. No, I didn't realize that and that they were accessible. So that's cool.
Schnitzel: You're saying there's some warehouses in the world where they're laying around? Yes.
Ronald: Yes. And we know who they are, right? At least I think the foundation at some level should be aware of which companies have those. And we might want to have them at scale.
Schnitzel: Yeah. Does anybody know how to drive an 18 wheeler? We could do like a visit.
Ronald: I handled the send off of our last three pallets of them. I think I sent 100 of them. They're in my hallway at work on my last two weeks at Intel trying to get three pallets parted and sent to their destinations because we sent them as a thank you gifts essentially because they were scrap to all the employees that worked on the team. We had them sign up if they were interested, and they could request up to three. And then we sent a whole bunch to, we tried to send a bunch to My First Bitcoin, but they had moved out of El Salvador and couldn't mine anymore.
Johnny: Well, before we hit the top of the hour, I'll just say I will commit to digging up what I have for the Bitaxe Bonanza, the bitaxe-raw implementation of that for the next meeting. Maybe I'll throw it in a discussion or in the forum where it's at and all the pieces to get it to work. Yeah, I don't, as I said, I likely won't have time to sort of champion a BZM2 Mujina PR, but I can get the information needed to get Bitaxe Bonanza. And I'll do the work as well to review whatever the implementation is on Bitaxe Bonanza. Yeah, so I'll at least dig up the information I have in the current state of it for the next meeting
Ronald: All right it just published it's been running since like seven o'clock this morning that's absurd anyway
Skot: I have an RDS. If anyone nearby wants access to it, I can certainly do that. It is a big, loud, hot 220-volt miner. So you just have to be able to support that. But I can get one to someone if they're interested in checking out and reviewing Ronald's Mujina work on that platform.
Ryan: Cool. I would love to eventually figure out how to get my hands on one and also a Bitaxe Bonanza so that I can help vet and support these drivers.
Skot: Yeah, the Bonanza is going to be quite a bit easier. It's a lot smaller. Does he need 400 volts instead of 220? Exactly. So yeah, that is the plan is to get a bunch of those made up of this version that I'm working on now and get them out to folks. So I guess paired up with Johnny's not bitaxe-raw, but RHAP implementation that can hopefully be useful for people.
Ronald: My PR is marked as draft. Claude says until 12:10 p.m. Pacific. That's an hour and 10 minutes because it's running the test right now on the code that it changed. And that test finishes. That's what you're listening to at 12:10. So another hour.
Ryan: Great. We'll take a look at those then. Okay, well, this has been helpful to understand what the field of play looks like. And I think, yeah, I think you paint a compelling vision, Ronald, for these chips, even though they're old. I think there's a lot of usefulness here. So we're certainly excited to get support for all this into Mujina eventually.
Skot: And there are technically a lot of these BZM2 chips brand new on the reel in the carton in a warehouse somewhere too. So I think if we make a compelling case.
Ronald: More than a million.
Skot: What's that?
Ronald: Like more than a million of them.
Skot: Yeah, I think quite a bit more than a million from what I've heard. But yeah, it's just a matter of overcoming the inertia to get those out of the warehouses. And I think having a compelling case for what we want to build and lots of different people working on them, I think can make that case. So this is important on a number of fronts.
Ryan: Yeah. Yeah, it illustrates the things we say at 256 well, right? Because... If there's a good hardware, sounds like there are going to be a couple of good hardware reference designs and solid support for it in Mujina out of the box. You have such a head start if you're trying to do anything with these chips. Be great for heat pump devices and other prototypes.
Ronald: Yeah, I would love to see that hot tub mining on BZM2 ASICs, right? Because the heat is the output and the ability to control them with like a true PID. It'll be revolutionary, I think, to how you create heat capture systems.
Ryan: Yeah. Sorry. Thank you for pushing through with your voice. Yeah, and it'll be full circle. I mean, 256 sort of our early days started with, you know, hey, we have all these chips. Let's do something with them. So it'd be great to follow through on that. All right, well, we've hit the hour mark. Does anyone have anything else they wanted to add before we close?
Johnny: Oh, Ronald, I don't know if you could see my video, but I have your doorstop holding my office door. Awesome.
Ronald: Love it. Love to see my doorstops in use.
Ryan: All right, well, I appreciate everyone showing up this week. This has been good discussion, and we will see you next time.
Ronald: Awesome.
Skot: Later, everyone.
Schnitzel: Thanks, Ryan.
Dev-call summaries and transcripts live in the Dev Calls discussion category. Transcript pages here are linked from their discussion threads.