-
Notifications
You must be signed in to change notification settings - Fork 39
dev call 20260803
Schnitzel: Recording is on.
Ryan: Okay, the recording has started. Let me make sure it's actually recording because the last time I did this, I got rug pulled. Maybe I should stop it and see. Okay, I'm gonna stop it and restart it just to make sure it actually writes a file when I do this. I guess you can't stop it once you start it. Jitsi, I wanna love you, I really do, but come on. Am I the only one that can record it or can someone else record it as a backup? Plan B, can you try Tyler?
Tyler: I'm on Safari, so I know I can't, but Dylan might be able to. Recording is on. I'm on Brave. It only worked on Chrome.
Ryan: Okay.
Johnny: Someone else just... Yeah, I triggered a recording. Awesome. It worked for me last time.
Ryan: Okay, sweet. Thanks. I hope it works for me, but somehow I ended up with a zero-byte file one time, and now I'm nervous about that. Okay, thanks for joining everybody. We have a special guest. Eco is here, the project manager. The boss is here, guys. Careful.
Econoalchemist: Hey, everybody. I'm just going to be kind of quiet in the background because I got a lot of background noise, but I... Have been trying to get a regular schedule that I can kind of structure my life around. And it took me a few months, but I finally got there. And luckily, Mondays ended up being the day that I get to dedicate all things 256 Foundation. So I'm sorry I couldn't have been here for the earlier dev calls. I really wanted to be, especially as the project manager for this. But my schedule just didn't allow for it. So now it does, and I'm stoked to be here. So yeah, please carry on.
Ryan: Okay, well, what we usually do is record the meetings, just so you know. I have my screen share active and open to an agenda that's on our GitHub discussions. What we do is roughly go through, just activity of the last two weeks as a way to keep everybody up to date and to discuss things that fell through the cracks or need more discussion, We don't want this to replace the other communication channels. So anything important we decide or whatever, we try to take back into text discussions in their appropriate homes, just so people who aren't here can see it. And so there's more of a permanent record. Although I do, of course, transcribe and summarize these calls and put them on GitHub as well. So, the flow through the call has, has normally been according to, Average Gary's advice to kind of take the flow through that the project takes like an issue through the takes through the project. So that's sort of to arise as something maybe in chat or in the forum, and then it sort of turns into a discussion and then maybe an issue and then maybe a PR eventually. What we've been doing the last several calls I'm gonna try flipping that around and inverting it because I feel like we get sort of stuck sometimes in some of the earlier more nebulous topics and don't make it to the end I think if we switch it around that other stuff's a little easier to talk about because it's more well defined so I think we might get through it better if we sort of turn it on its head, we'll talk about PRs first all the way back down to the less defined forum or chat issues. And I'm also going to add a little section at the top where I can put things that I want to bring up that don't necessarily fit into the rest of the schedule.
Ryan: There's probably no need to do this for the people on this call, but since everyone in the Bitcoin community is doing this, I'll just begin with a public service announcement. If you have been living under a rock and haven't heard about the cold card entropy bug, you should log off this call and read about it and take action if you're affected. I'll leave it at that unless anyone has questions or shows me a shocked face. So yeah. So what can we say about that as our project? Obviously it's, a tragedy and sad that people lost money here. I guess maybe it's just a reminder as a project to be humble and to be professional and to think through and remember that people use our software and we sort of have a commitment to them. The developers so I tried to think through a little bit of what that might mean from Mujina obviously we're not storing private keys or holding people's money and stuff like that so like what lessons can we draw so I just came up with a short list maybe we turn this into a discussion in GitHub and think about it some more but It's sort of crystallized, something I bring up occasionally when we talk about testing or whatever. But maybe some of our more important responsibilities to our users and developers is, first of all, not to burn anybody's house down. I would hate for that to be something that gets attributed to us someday. So I think we need to always keep that in mind. I kind of went in importance order here. So, like, first of all, we obviously don't want to burn someone's house or business down. And that could even be life-threatening. Secondly, I would hate to be responsible for destroying someone's equipment. Maybe let's... Make sure that we don't waste people's electricity, or I probably got this in the wrong order here because maybe that's at the bottom. We could also have a responsibility perhaps to protect hash rate from being stolen. These two here, I think it works in our favor that people usually mine to a pool, even locally. And so there's usually a nice double check on our system by some external piece of software that know the hash rate is what it's expected to be and you can look to see you know what username is being given to the pool stuff like that so there's kind of a way for a user to double check that that we're not mining for ourselves or some you know someone hasn't hacked the software release or something like that so I like that maybe we keep that in mind architecturally I know one of our discussions this last couple weeks sort of about that direct to node thing that I vibed the other the other month where it kind of used the node directly as a pool source and that was mostly just for fun but it sparked a bit of a discussion and I guess one of the architectural things that might be nice about maintaining like a stance where we don't build a pool into Mujina, let's say, or build something that does that much template creation is that it's nice to have an external system kind of double checking our work. So maybe that's part of how we maintain this user promise. And then lastly, I suppose Rust projects have to be careful. Any project like this that pulls a lot of dependencies from the internet has to be careful about protecting dev machines from compromises. That's been a supply chain attack vector over the last couple months. And we don't do a good job of this yet. I don't think I have a lock file for our dependencies. So maybe that's something we need to do immediately in the short term. Is follow better Rust practices for like locking down our crate dependencies and then having some kind of rule like maybe automated maybe we put a recipe in our just file that updates dependencies to the current ones but implements some kind of rule like it will look at what's been changed but not take anything that's younger than seven days old or something You know, cause like if someone pushed a compromise package to a central rust repository, chances are that'll be discovered after a day or two for a popular thing we might be using. So one way to help protect even if we don't closely review everything is to just not create updates that are absolutely fresh. Give the communities a little bit of time to discover the obvious hacks and bugs and stuff. So maybe we automate that by building that into our updating tool or whatever. So that was something that came to mind. Anybody else want to say anything on that topic?
Schnitzel: I do. I like this a lot, I think, in the situation that we're in and just overall to have some of these guidance. I do have a question about the protect from being stolen. What we see, for example, with beta access, they have unprotected UIs. I vibe-coded a little thing that in any Wi-Fi that I'm going currently, I'm just checking, is there a Bitaxe? And I'm changing it to pool 256. So that's why the pubkey Bitaxes are now pointing out to us. It's more fun if you do this. But I think on a bigger scale, I'm I'm generally concerned that if there is some way that I, let's say, resell, or now that we've figured out how to install custom firmware on these control boards, that I buy an S19 or multiple of them, install custom firmware on it that sits next to a regular stock firmware. And then I will resell it again and hope whoever plugs it in, this firmware suddenly finds all the other devices, they're unprotected and just also installs like basically a minor worm that just points, whatever, 1% of the hash rate somewhere else. And people don't realize like there's so many things I could imagine. And it all gets connected back to the fact that these root passwords are defaults and standards. And right now, we have the same. We have an unprotected API. You can't do a lot. You can't configure it yet. But I guess the question for you, Ryan, would this mean that by default, the Mujina API is protected by a good enough password and, well, a password first overall?
Ryan: Oh yeah. It's always been my intention that we, that we add authentication and permissions to our API soon. I haven't thought through fully what that should look like you know what should that look like out of the box obviously someone should be able to configure it lock it down with keys or tokens or whatever else but like what does it look like in a default freshly installed setup I'm not entirely sure we talked a little bit last week I think about Mujina OS You know, the bigger idea of packaging whole images. One of the things I've been working on that a little bit here. And one of the things that's kind of cool that I might steal from like the way the Raspberry Pi loader works is like the Raspberry Pi loader, as you're using it, you can like put in your, you can put in some defaults, like an SSH key. Yeah. That might work for that kind of loader case, something that gets loaded more at scale. I don't know. We haven't built these loader tools yet. You know, maybe we solved the default problem by not really by it's, it's, it's relatively locked down until, until someone configures it with some kind of key or something.
Econoalchemist: So yeah. Yeah. We need to keep that in mind.
Ryan: I never, I never meant for it to stay open forever. It's just, there's nothing to protect really at the moment.
Johnny: And plus we're just in the image. Won't a lot of the protection fall on the OS more than, Mujina. I see Linux configurations, yada, yada.
Ryan: There are probably multiple topics here.
Johnny: Firewalls, all that. Secure boot, et cetera.
Ryan: Yeah. There are probably multiple concerns here. One is just how do we lock down access to the API? That's what I was addressing a moment ago. But yeah, you're right. We're also in control board with them.
Johnny: That might be a web server. But I would also add, probably worth auditing the stratum code for malicious stratum servers too, especially with all of these random pools popping up. Yeah, that would be one angle to throw Kimi at also.
Ryan: Yeah.
Johnny: Yeah. Certainly there's Bitaxe issues that need to be resolved. Yeah.
Ryan: Okay. So yeah, if I'm generalizing from that a little bit, you know, we are a network client. Yeah. You need to make sure that we can't. Yeah.
Johnny: Make sure strings are closed or references are managed properly, et cetera.
Ryan: Yeah. Okay. Well, I just wanted to get that discussion rolling. Yeah. Because while we think about all the features and machines we want to support, probably also have to keep front in mind stuff like this so we don't find ourselves surprised someday. So that can be an ongoing topic.
Ryan: Next you probably saw this already or heard about it on the podcast but sort of in response to last week's or sorry last two weeks dev call where we were talking about compatibility matrices and stuff like that sort of inspired me to give our website a refresh so If you haven't, oh man, I thought I had a link to it. If you haven't seen it yet, it looks like this. This comes from a repo that's adjacent Mujina in the 256 Foundation org so feel free to edit submit PRs for this it's just on a separate repo the idea is it's kind of like a landing page for people who are just hearing about Mujina but that it also eventually links you into user documentation. So I've got a few things up here that just came to mind, for example. So it's not very thorough yet, obviously, and there might be stuff that's wrong with it. So PR is welcome, but I just wanted to sort of stick the idea out of what I'm thinking this looks like. But... Also in the reference section here, I've got a hardware compatibility page. So we can start filling this in. But people were asking, where can I find? I saw someone post online it worked on an S19. What's the status of that? This is sort of where we can answer those questions or point people to. In fact, I linked a couple of your guys' forks just for the heck of it. Yeah, so don't miss, don't miss the webpage.
Ryan: And then also I wanted to point out that, so you might've seen, or we talked about on the podcast that, there are several people that have been running this mining workshop that I gave in Nairobi for themselves. Which is super cool. One of the things I did in the mining workshop was have a Bitcoin network in the classroom that had a heavily modified Hydrapool and bitcoind and a dashboard and all sorts of things. I think that might also be fun or useful for people testing at home like us. So I mentioned it here. It's called dev pool. It's just a repo in my, a public repo in my account on GitHub. It's basically just a Docker. It's all packaged up in Docker. It's got dashboard web servers, like I say, a modified Hydrapool, Bitcoin signet. It's very easy to run. And it's all like prebuilt Docker images. It also works, I use it in Podman, so it should work in Docker or Podman. It does fractional difficulty. So you should be able to use it with CPU miners, all the way up to whatever. And it retargets difficulty on the network very quickly. So if you move, if I found the same network and you go from having CPUs, your Bitaxes to S19, it's like. It will, the difficulty changes pretty quick. So it's sort of useful in its development context and educational teaching context, which is where, what I did it for initially. I just wanted to point that out. Cause it might be a sort of a useful dev tool. Especially if you're using CPU miner for some reason, and you want to see it in a dashboard. Because that's the one thing that doesn't work on something like public pool or the 256 Foundation pool fractional difficulty from cpu miners
Ryan: Okay to the PR section activity since our last call. So this morning I merged a pretty large change to the Bitmain chip documentation. We had a document called protocol.md for a while. And now I've turned that into reference.md because it's, well, it's huge. I did, as I'm working on my unified run on everything Bitmain chip driver, I've collected everything I've learned. Let me just link to this so you can see. Here's table of contents. I've tried to improve the documentation in areas where things seemed fuzzy before. This is a combination of everything I could find on the web, various things from ESP-Miner, things from reverse engineering that I've done, stuff from looking at captures from factory firmware from third-party firmware all sorts of stuff so this documents now about like three thousand two thousand lines and it represents like kind of the state of the art in terms of my knowledge of these chips collected from all this all these different sources so Anyone who's working on this kind of stuff or adjacent stuff, maybe even ESP-Miner. I'm going to share this link with other projects too, because I'd love to get more people's eyes on this and see, if there's anything in here, like they didn't know before, or they disagree with and could give us feedback on or anything like that. Like the. I think it's useful to have this in a document, sort of like a missing data sheet. Because it's sort of hard to glean from just reading the code. I mean, obviously these facts get encoded in the code, but it's easier to have all this in a reference document for starters. And it's also sort of like I tried to make it educational so like if you have never worked on a Bitmain or worked on any mining asic before like I think this is readable enough that you could jump in here and sort of understand oh this is how the chip works this is this is like what's this is what magine is actually doing this this is what's going on in the hardware I think this will be useful for people to get up to speed but Everybody's feedback on it here is quite welcome. You guys know a lot of this stuff already.
Schnitzel: I think that's great. One idea is that maybe I would actually push this even publicly visible on the Mujina website, because I've seen my agent trying to find something like this, and I had to help it a little bit, like to point it directly to Bitaxe repos and stuff. And I think the more we can make this publicly available or readable, the easier it's going to be for anybody, for a human or an agent, to find it. But yeah, I think this is awesome.
Ryan: Yeah, that's a great idea. At the very least, a link.
Schnitzel: Yeah.
Ryan: OK, that's a good idea. I'll do that. And as I've worked on this, I've thought, A lot of times people jump right into modifying Mujina and having forked versions, and that's awesome. But someone who doesn't know what they want to do yet or where can I get started or what would be helpful to the project, even just like starting in this document, reading it, and then there are parts in there that say, this is how we think this works, but we're not entirely sure. Or there's some areas that are fuzzy, like this register hasn't been explored yet or whatever, like someone with a machine and an agent and some time who really wanted to bang on some of those details. I mean, even doing some of that reverse engineering work and then bringing it back and capturing it in a document like this would be a great contribution to the project and to the mining space in general. So I just wanted to point contributors in that direction. And when I say some of these things, there's only a handful of us on the call, but I'm also saying it for the sake of the transcript and everything else that other people might see, more junior developers might see who want to know where to get started. So yeah, you'll see that again because I'll probably share this a little more widely and bring some attention to it.
Ryan: Other PRs so Ronald has pushed several BZM2 PRs that I haven't looked at closely I need to look at them to understand more what it is we talked before about how like some of his documentation probably doesn't belong in the Mujina tree yet so I Happy to see that he created his own reference tree of documentation and stuff under his Blockscale Solutions account. So I don't know, we may find that interesting. Some of, but he's also got some code contributions, which I think are more to like general types and stuff in Mujina than, than, it's not like it's, the start of an actual BZM2 implementation in Mujina. So I don't think it's in competition with anything you might be doing Johnny.
Johnny: Yeah, I'm not entirely sure. I know he asked me to trigger a CI run on what he has, so that might be worth doing if you have admin controls on that. I will say, so just to give an update on the BZM2. Yeah, please. We got the Bitaxe fully functional, like 100% functional now. So I have the fully working USB Miner, Bitaxe, Bonanza. That's awesome. The last thing I have to do is get Skot to fix the DisplayPort on mine, and then that's the last feature. But originally I thought I'd get Mujina working first, but Skot came through with the Bitaxe Bonanza, so went ahead and got that working. So now I'm going to go back and update my Mujina fork this week. So I'm actually working on that right now. I'm probably going to look at what Ronald has and try to incorporate that into whatever I have. Update the PR at that point when it looks ready. And your reference document is great. I'll see what I can do to recreate something similar with a combination of what I have and Ronald has. And maybe we can have something similar for the BZM2. So yeah, everything's in place like on the hardware side to now come back to the Mujina and actually make a proper Bitaxe Bonanza board implementation. So that's the status of that. Looking forward to updating that PR.
Ryan: Cool. Well, I'm excited to see that.
Johnny: Yeah, it's cool. Yeah, we have two devices in parallel going that I think the other one's going to be done soon too. So hopefully we get more chip implementations in.
Ryan: Yeah, I've heard about some of those. So this should be an interesting next.
Johnny: Yeah, it's crazy how fast we can do this Bitaxe work now.
Ryan: Right.
Johnny: From six months to just a weekend now. So that's exciting.
Ryan: Yeah, it would be great to have a reference document like this in every chip directory. That's sort of the idea.
Johnny: No, I like that idea. I'll see what comes up with.
Ryan: Awesome. Yeah, Aadhi, go ahead.
Aadhi: Do you want me to add like a reference doc that I made for the Canaan chip series, like 3197S?
Ryan: Yeah, absolutely.
Aadhi: Okay. Is there any template that you prefer or any general documentation would be fine?
Ryan: Well, take a look at this new reference doc I just talked about. I think that makes a good template probably. I spent a lot of time on it. So yeah, something like that. Okay. We'll do it. Awesome. Thank you.
Schnitzel: Should we also have a spec if Mujina wants to interact with a human to manually do SHA-256? I'm thinking about the pigeon carrier RFC that is a real RFC. So maybe we should do an Easter egg in there, like how Mujina could interact with a human.
Ryan: Sure. Pop up a dialogue.
Ryan: So sort of a general comment that applies widely and brought about by some of the type changes Ronald was submitting in these PRs, I think, and a conversation I had with Jayr about configuration stuff. I think it's gonna be most helpful and easiest for me to merge and work with if most of the stuff that gets submitted is sort of in the context of making a particular piece of hardware work. Like, it's sort of tough to know what to do with a PR that lands just like, hey, I modified this type. I need this type for my thing in my fork that's, you know, maybe that'll be coming or get merged in a month. I don't really know what to do with a PR for something that modifies something that the existing code sort of doesn't use. I don't really want to land those until they have a context they're running in. I guess I didn't think this through before. I don't know how to state this as sort of a general policy. Like with configuration stuff, which is probably the easiest example. It's like, I think the best way to attack a problem, like we talked about that. We have these big plans for configuration. We have this MIP document that describes the whole big thing. Probably the best way to attack implementation of something like that is to be like, okay, I want, I'm gonna implement one concrete feature. Like I wanna be able to set the pool URL over the API, like pools should be configurable. I'm gonna attack one thing. And then I will build myself a vertical slice through the stack of the pieces I need to get me there that are in coherence with our big plan. But like, I'm not trying to implement our big plan in the abstract. And with a lot of buildup to get there. Like I'm gonna go straight for the jugular as I can, like in one narrow slice through the stack and actually make something that works. Cause so much easier for me to review and merge something that I can, See the context. We can all test it. We can run it. It makes a useful feature at work. I'd much rather have something like that and then we just kind of grow from there. Anyway, so that's just general advice on contributions is try to have...
Johnny: I guess with regards to that, can I ask you how many of birds or bonanza bid acts?
Ryan: Sorry, I missed the first part of what you said.
Johnny: Just in relation to your comments there, do you have the hardware? I do not. I do not. Okay.
Ryan: I would love to have one.
Johnny: Yeah, I'll talk to him about that.
Ryan: Yeah so I can I can build up a PR that hopefully fits with what you're what the way I'm interpreting what you're saying at least okay yeah and it's obviously harder when you're landing the first version of something brand new like that that isn't small you know like obviously there's like a critical mass you need to get birds working so yeah but you know we can build the history and logical chunks so that you know yeah
Ryan: All right that covers the PR section not much happened in the issues section except that Jayr and I had some conversations about the stuff I just mentioned about beginning some implementation of the configuration ideas. And I said, hey, it'd be great to do something super concrete. And then I created a tracking issue for that. So that's one thing we want to do with issues for something that's going to be a long-running project. Idea is to make an issue that that can be referenced from other issues and other PRs and commits and whatever it's be like hey this is a part of this is a part of this feature just so there's some kind of tag or handle to pull on if you want to know what's going on with with configuration stuff there's sort of some issues for that anyone you know if you want a tracking issue like this for your work, let me know, I can do something like that too. Although sometimes it's too premature. Like I think we had a birds one for a while, but I don't know that it was particularly useful. So anyway, that's what this issue was.
Ryan: The only discussion activity was on this mining direct to node mining thing, but it sort of turned into more general discussion of Stratum V2 and some other things. I guess I mostly covered what I wanted to say about that already. You were in this discussion, right, Johnny?
Johnny: Yeah, but I don't remember it.
Ryan: Yeah.
Johnny: What's that?
Ryan: I don't know. Wasn't much to conclude I don't think except yeah obviously we're not going to build a mining pool into Mujina so and we if you if you want to know why having okay here's sort of where this landed I think it was interesting to talk about like what if you point in Mujina directly at a node to figure out jobs on its own. Why have a pool in the way or whatever? And I think that discussion sort of built the rationale for why you do want some software outside of Mujina creating block templates for Mujina to hash. Because it's a complicated problem in its own right. Because there are some implementation issues, like right now it's most efficient if that software lives directly on the same machine as the node is running. Because if you have multiple Mujinas, like now, are they all gonna make their own jobs? That doesn't make sense in most deployments. And then the stuff I said earlier about, boy, it's sure nice to have pool software or job creation software more generically. It doesn't have to be a pool, obviously. Maybe like a job declaration server, Stratum V2 kind of thing. It's awfully nice to have some other project verifying that Mujina is doing useful work. Because if Mujina is showing a hash rate in a dashboard of some other software, that means like the shares that are coming back are actually cryptographically correct. The hash rate is being estimated by that other device or by that other software, which should agree with what you expect. From what Mujina is saying. So there's lots of reasons that job creation is probably best left to some other project and not something we like deeply build into Mujina itself. That's sort of where that discussion ended up going, which was interesting.
Schnitzel: Would it make sense to actually write this out, like maybe on Mujina.org? Because recently, like in my Fiat job, what we started to do more and more is actually write down what things not are. But one of the things that now happens with AI, that code is written so fast that we now see a lot of pull requests of people adding code to repositories that shouldn't be part of it. And so maybe actually having a section either in the docs or somewhere that says, what is Mujina, but also what it is not. It would be very helpful. And that, for example, could be, I think you have very good arguments why you should not be able to talk to a node directly. I mean, basically take this transcript and tell it to update the website.
Ryan: Yeah. No, I like that idea. Negative requirements.
Johnny: That is a funny thing. I found the same thing. That's a great idea.
Ryan: Yeah, it's a great idea.
Johnny: People are rebuilding authentication schemes inside repos that should not be doing it, et cetera, things like that.
Ryan: And then our last session is stuff I've collected from the forum and from our chat room. The Heatpunk summit announced that the dates for the next Heatpunk Summit and published a wait list link. So if you're not aware or planning, the Mujina project highly recommends the Heatpunk summit. It's very high signal and directly, relevant to the stuff we're doing. In fact, we're probably going to have a bunch of 256 and Mujina, you know, workshops and talks and hacker space activity and everything else there. So, Aadhi, maybe we can get Jayr there. You know, we should, we should, we should try to get most, if not all of our contributors to show up there in Denver in February, if they can. I think, that'll be a good summit for us.
Tyler: Yeah. Tyler just got up. We are actively planning a lot of 256 demos and workshops. Like you mentioned, there's already, I think like 50 to 60 people signed up for the wait list. Wow. So if you haven't already, make sure you are on that because demand is there. So I want to make sure we get as much signal in there as possible.
Ryan: Sweet. So don't delay. And mention that you're a Mujina contributor. Maybe that'll help your spot on the list. Dylan knows us. We have an in.
Tyler: Yeah, you guys are good.
Ryan: Okay and then Mujina interesting things I found in the telegram chat the last couple weeks we had a bit of a discussion about power I guess what we would call in our terms like scheduling policies you know does Mujina aim for maximum efficiency or does it aim for a power target how would power targets be distributed across boards So I linked to that thread there. I don't know that we, I don't know that we invented anything new there and mostly just a new user sort of asked about it. And I think I sort of recast the vision that we've already talked about. But you can read that there. I don't know if anybody had any new thoughts we've never talked about in that realm.
Ryan: Skot talked about how someone should reverse engineer Bitmain power supply firmware so we could get some current readings out. That would be very cool.
Skot: I think it could happen. I think.
Ryan: Oh, he's here. Oh, you showed up late. I didn't even see you.
Skot: Oh, hey, sorry. I snuck in a little bit late. Sorry about that. Yeah. Good chat guys.
Schnitzel: But, so Skot, let me, let me understand that because that would actually like, I have a financial incentive on that in the Nova project. So you think there is a current measuring device on it. It's just not used at all.
Skot: This is this is a very hand wavy kind of thing but I could imagine that that is the case yes the there's a there's a PIC microcontroller inside the APW the APW12 and it is involved in like not just the I2C communications with the power supply but more in the operation of the power supply and you know getting getting the current feedback is pretty important for voltage regulation so I could imagine a case where it's there it's the pic has several ADCs on it and Yeah, it very well could be that one of them is hooked up to a shunt or something else that can measure current. Definitely needs more investigation, but could be a thing.
Schnitzel: And so in order to do this, right, so you would expect there's some kind of JTAG or UART somewhere on the device that we could try to talk to this, or would this be like unsoldering the chip, or how would you approach this?
Skot: It's a PIC microcontroller, and PIC microcontrollers use their own proprietary programming interface called ICSP, and there's definitely an ICSP header on the power supply control board right next to the PIC. So you could... You could potentially dump the firmware if they don't have readback security enabled, but you could definitely reprogram it using a PICkit 3, which is Microchip's PIC programmer tool. I do have a dump of the binary firmware from an APW3 that we could also throw into Ghidra and try and reverse engineer. But yeah, you could definitely, at the very least, you could reprogram the PIC on an APW12 power supply, and the header is there. It's covered in white goop, but it's there.
Schnitzel: Okay. I guess I have sleepless nights again.
Tyler: Sorry. That's okay.
Schnitzel: That was actually cool. I guess I didn't realize that. No, I mean, you're right. It has to know the current in some way or another in order to actually do power supply stuff. And if it's a microcontroller, why shouldn't it just send it through I2C as well?
Skot: Yeah, I mean, it might be the case that the existing firmware doesn't read. There is a current... You know, current measurement connected to the microcontrollers ADC and the firmware just isn't reading it. It might be the case that the firmware is reading it. We just don't know the I2C command to read it, or it could be the case that it's just not connected at all. And it's not really possible, but that'd be worth investigating. We do have actually, you know, we do have the schematic for this power supply. And I remember looking at, I should go back and look at this again, but I do actually think that the current measurement is hooked up to the PIC.
Ryan: Okay.
Skot: Yeah, we can chat about this more if you want this right out of the scope of the Mujina conversation. But, you know, the cool thing with Mujina is that we can, obviously communicate with the power supply, however we want and, you know, expose the API for, for adjusting these things. And then the real goal here, which is to get power, actual power measurements out of the power supply. So you can use that for tuning.
Schnitzel: Yep. Yep. Okay, cool. Thank you.
Ryan: Yeah, that'd be, that would be very cool. Yes. I brought this up. So it's kind of Mujina adjacent, but glad I did. I guess that would also be something, you know, the more sensors we have to monitor things like currents and temperatures and whatever, in addition to giving readings, people want to see, towards our safety conversation from earlier, it would also be nice to have something that was always making sure that temperatures and currents and whatever else were within safe ranges, expected ranges, stuff like that. We don't have a lot of ability for that kind of feedback right now.
Ryan: And then, Aadhi, you want to tell us again or point us to where we can look? I know at the beginning of the call, you said you had news that I guess this link doesn't even cover, but this is very exciting.
Aadhi: Yeah. BMM101. So the CEO of Braiins, he shared a documentation with me of how to communicate with the control boards and the hash boards and how to set up the watchdog and everything. So I'm still working on that. And yeah, the BMM101 is currently not running Mujina, which I need more time. Of course, I started focusing on the Nano 3S. So, and, the other thing is that the Nano 3S is currently hashing and it's running Mujina fully. So yeah, I'm just like going to clean up the code and like update everything and push it to the, get out and make it open source.
Ryan: Very cool. Can you explain one more time, I might have missed it at the beginning of the call, sort of architecturally between the two processors and the Nano 3, what you're talking to or what parts you have doing what at the moment?
Aadhi: So basically the Nano 3 uses the Canaan K230D processor, which is a dual core and one core runs at like 1.6 gigahertz and the other one runs at 800 megahertz. So the way that Canaan like did this was one core runs Linux that takes care of like all the stratum jobs and power control and everything. And the other part runs like a RTOS code that communicates with the ASIC and is like, It contributes towards job scheduling and everything and takes care of the target. So I found out that there's also like a telemetry thing from the ASIC. So there's an inbuilt temperature and watt sensor that you get ratings from. It also manages that. So what I basically did, I followed the same architecture. So I created my own RTOS code to communicate with the ASIC. So the RTOS code would talk to the ASIC and the Linux side would run a Mujina and both would communicate via an IPC, an inter-process communication mechanism that Canaan already built. And yeah, so they would share the jobs and our telemetry and that's how they work together.
Ryan: So how much of the chip management is being done on the RTOS versus in Mujina?
Aadhi: So Mujina does mostly the work job, you know, like sending out jobs to the chip, but the, you know, assigning job ID and all that, like the receiving telemetry is all done by RTOS, like, you know, adding the preamble, like checking CRC and everything is done by the RTOS side of the code. All Mujina does is like send the, you know, the mid state and everything and that's it.
Ryan: Cool. Well, I can't wait to see that closer to see how that's broken down between the two parts. What's, what's the tool chain for the non Linux core?
Aadhi: It's a RISC-V, but, I forgot the actual name for it. I can like send the tool chain for that. Canaan has like a whole documentation for this, processor, like in their website and they include like all the tool chain and stuff for everything.
Ryan: Well, sweet. Well, cool. Cool work. I'm sure we're all excited to see that.
Aadhi: Thanks Ryan.
Ryan: Yeah. Right. And then lastly, I saw that Sean had Mujina running, I think on a NerdQAxe++. In the chat room. He's not here to talk about it, but that's something to keep an eye on.
Ryan: And look at that. We have landed almost perfectly at our one hour mark. Open floor. Anything anybody want to talk about?
Schnitzel: Have anybody wondering? A human has 33 microhashes a second.
Ryan: Okay, that's a good one.
Schnitzel: I have a PR incoming, Ryan, for the Homo Sapiens 1 chip.
Ryan: This can be a good April Fool's Day PR.
Schnitzel: Maybe, yes.
Skot: This would be a good Mujina dashboard, right? It just presents on the screen everything you need and maybe even gives you a form to calculate the hash by hand.
Ryan: What happens when the pool refreshes the job before you get it done?
Skot: You got to start over. Sorry, buddy. You timed out. Time out. Start over.
Schnitzel: It's also interesting. I asked it like what telemetry you could get from a homo sapiens and obviously it gives you the temperature, but also the glucose level of millimole per liter. So, you know, like how, how, how continuously the human can work, can do your work.
Skot: Oh, yeah. You get one of those like glucose patches, right? And you pair that to your Bluetooth and you can get live telemetry.
Ryan: Joules per terahash. Calories per halit. Kilocalories per. This definitely needs to happen. This will be a great April Fool's Day.
Skot: Well, you don't want to trust someone else's implementation of random number generators. That's bad. So you should definitely roll your own hashes for maximum security.
Schnitzel: Too early, Skot. Way too early.
Ryan: Too early. Sorry. Well, it's good to see everyone. I think that concludes unless anybody has anything they want to add. Thanks Ryan all right thanks guys see you very cool have a good have a good summer all right bye bye recording has stopped okay I'm glad you got that I'm gonna I'll let you know if I need it how did you stop it where's
Johnny: There's a button at the top, I think. I don't actually know. I hit stop sharing. Yeah, I was just trying to make sure. Why is Jitsi so weird?
Ryan: If I press the record button,
Johnny: All right. I got it anyways. Okay. I'll just close. All right. Let me know if it looks like I have a copy.
Ryan: All right. Thanks, man. See you later.
Tyler: Yeah.
Ryan: See you, Eco.
Dev-call summaries and transcripts live in the Dev Calls discussion category. Transcript pages here are linked from their discussion threads.