dev call 20260615

Dev Call 20260615 Transcript

Back to discussion

Transcript

Ryan: Recording is on there we go oh in gyre just in time okay okay welcome everyone I'm adjusting this I noticed in the last recording that it was my face the whole time which is not what I intended So I think I'm learning to click the screen share so that can be a feature of the video. For what it's worth, I did reach out to Bitcoin TV to ask if we can post our videos there, and I did not get a hold of anyone. So I need to keep trying. Does anybody know the process? Isn't that just Odell? I thought so. I mean, they had an email, so I emailed them. I think it was Odell and Rod, so we know these guys. I'm sure I'll be able to make it work. I just didn't this week. But that's sort of the idea is maybe we'll start posting them there. But the transcripts, are pretty good. I'm pretty pleased with the way AI post-processes everything with a little bit of guidance. So I don't know if anybody's take a look at these, but they're pretty correct. I don't have to touch them up much at all. And then I just tell it to add some things like timestamps and links where it can. What a time to be alive. So I don't have anything... From that last call to follow up on that isn't also on today's list. So we'll just keep rolling. It was sort of a quiet week on the chat and in the forum, from what I could tell. Anybody stop me if there was something we need to talk about, but I did want to point out that there was an excellent podcast. Tyler, actually, maybe just... I should pass this out to people who own these issues. Tyler, can you tell us what POD256 was this week?

Tyler: Yes. Iko and I had special guest AgentP, who is working on GridPool. For anyone who missed it, he reverse engineered the communication between the Datum client that is open source and the closed source Datum server. GridPool effectively aims to offer a decentralized payout structure, so a pool without a centralized pool authority. It's protocol-based. However, it does not use a side chain, a share chain like P2Pool v2 and v1 attempted to solve. I need it drawn out for me. It was a really good episode. Definitely go check it out. But my understanding is that it's doing some statistical estimates of paying people out based on their highest difficulty, which over a long enough time frame... Should theoretically pay out very similarly than actually counting shares. So it's not counting shares. That's the workaround, the simplification. It's pretty interesting. Definitely go check it out. All the documentation and code for his project is open source. If you're also curious how he reverse engineered taking the Datum client and talking to a server, he did that as well. So definitely check it out. Very cool.

Ryan: Cool. So AgentP was on our dev call last week talking about how he got Mujina running on his S19. Did he talk at all about that?

Tyler: Actually yes he at the end there I did prompt him because he he replied to my forum post where I asked for vibe coding tips I saw Aadhi chimed in there as well and he had a pretty extensive response with how he was able to get Mujina working on his s19 using an ai tool SSH kind of just intercepting a LuxOS while it was running and some, some good suggestions there. So if you're, if you want to start hacking with Mujina on a new device, he outlined pretty well how, how he was able to do that. Sweet.

Ryan: Cool. Yeah. He, he followed up after the call last week with a good discussion post, GitHub discussion post also where he like showed the prompts he was using and everything. So, Very cool. If he were here, I would have him talk about it. Okay, so on to the next. This is the configuration and REST API spec that I brought up for the first time last week. And brought it up kind of at the last minute, so I don't think anyone had a chance to review it before last week's meeting, really. So I'm curious if anyone has had a chance to look at it and wants to talk about it.

Brett: I've got a couple things, too.

Ryan: Sweet. Who would like to go first? I didn't see who the first... I was on the wrong screen to see who the first person was.

Brett: Yes, go ahead.

Ryan: Was that you, Jayr?

Jayr: Yeah, well, I did read it. I think it's pretty much like a consolidation of everything we have been discussing, right? Like from that call, I think like maybe two calls ago and then from there like different things that came from Jeff's poll request and then other observations that came from the discussion and it all kind of like consolidated into this proposal. I think it's it's pretty cool I just like I was as I read it I was like wondering if this came from like your experience Ryan maybe like working with like other like firmwares or some other like experience in your career and maybe if you could share a bit about that one thing that I was not really disagreeing, but just wondering was the reasoning behind having the things that are not necessarily configurations, but rather just computed values that you would be introducing in the same three because you always like describe this tree as a like central place where like both the configurations will end up but then you also mention things like for example you have the set point and then you have the value that the like let's say the board or the components they actually resulted in and then like they might differ from the set point because of like various reasons but then like I was just like okay then this seems that we are mixing a little bit of like stats or somehow like just like reporting on these things with the configuration and again it's not really in this agreement is more like a curious like what is like maybe you have some other like a vision or some inspiration that you know led you to this design and I just wanted to yeah to hear from you

Ryan: Okay. Well, yeah, quickly, I guess, I mean, it doesn't come explicitly from any one place, but I guess I've been at this a while and doing a lot of Linux system development for 20 plus years. So it does kind of probably represent the combination of a lot of experience and just things I liked and didn't like. I've also spent a lot of time doing packaging and OS-level packaging stuff in addition to writing system daemons and stuff. So some of that perspective comes from both of those directions, like the way the configuration files support dropping in configuration and layers. That's really helpful as a packager of... An operating system image when you're trying to ship site-specific configurations in a layer on top of the base program so you can ship that as a separate package. Stuff like that. I guess it also in some ways takes inspiration from just other things I've seen. The way Kubernetes or exposes its API, has some of those set point and actual values. Everybody does it in sort of a slightly different way, but a lot of times they are next to each other in one tree view, hand-wavy tree speaking. I see you raised your hand, go ahead.

Jayr: Yeah, I just didn't want to lose the opportunity to also comment on the choice of folders, because as you just gave this background, having worked with the packaging stuff for different Linux distros and whatnot, so these config.d and then like the var the slash far slash lib slash usr slash lib I was just like okay maybe this guy knows a lot more than about unix than I do and like I wanted to hear and to learn like what's the reasoning for these folders you know so yeah yeah not like I do you use linux for a long time but I was never like too deep into this stuff you know

Ryan: Yeah. Well, I don't blame you. Like I said, I've just been doing this stuff way too long. But yeah, all these paths do come... These are pretty standard operating system distribution rules. There's a whole open spec on what paths should be used for in a proper Linux distribution. And so this obeys many of those rules. Probably a good place that sort of consolidates a lot of that practice in one spot. It's also drawing from the same history, but if you look closely at how SystemD works and is documented, they do a lot of these same things. So, like... Packaging files will typically end up in user lib or user. Overwrites of the live system tend to live in var. These file paths have long Unix history of what they get used for. Like So that's where they all come from. I could talk about it more sometime. But also, if you looked a little bit at how systemd or the... I'll post in the chat, there's a spec called FHS, the file system hierarchy spec or whatever, that also talks a lot about what paths should be used for what. And these config.d directories, that's pretty standard for drop-in files. So yeah, all this... Pretty much none of this is made up out of thin air. Yeah, go ahead, Brett.

Brett: I had a couple small things and then some kind of general questions about the API. The first one is you have that delete flag, delete save config under UR8. Does it make sense to have just a dash dash delete option? Where you could pass in a JSON pointer or like dot separated config value to just delete one specific item. Say a user knows in some case that there's something wrong with just a specific item because it's logging something about it, but they don't want to nuke the whole config and redo it.

Ryan: That's a good point. I think... I should have read this before today, but I think you can do that via the API. Is that correct? Does that sound correct?

Brett: Yes, but delete dash dash delete save config is specifically for startup parameters. So you mentioned in here that on startup, if there's an issue with the config, that is like a panic shutdown, right? It stops the system from running and being able to single delete like one item from the CLI, I think makes sense if you have a configuration issue and you don't want to like go back in and manually edit it.

Ryan: Okay. Yeah, no, I like that. That's a good suggestion. All right. I command the AI to leave that for me.

Brett: I can post a comment or something, too.

Ryan: Yeah, a comment would be great, and I'm sure it'll pop up in the transcript as sort of an action item. But yeah, I think we should add that. That's good.

Brett: Okay. And then my other two things were sort of more general questions about like sort of the API design, but what are your thoughts on GraphQL? I know Braiins is not a fan of the way that they've implemented what they're doing, but I think GraphQL might make sense for a read-only API, especially because of the way that you're laying this out, right? You have these kind of branches and leaves and so graphql might allow you to query multiple of those leaves or multiple of those branches as a group it just kind of reduces the amount of requests that you have to make to say get a couple different items without grabbing everything yeah I'm on board with that in fact I'm surprised it's not in here I think

Ryan: It was in some of the implementation detail that I ended up stripping out of this document because it just got too big. But yeah, I think that's a good idea, especially because our tree is potentially gonna be huge. It's not generally the kind of thing you'd want to pull all at once. So being able to facilitate is important.

Brett: I'm concerned about certain things. Like for example, if you query the boards list, is that going to pass back all of the chip information? Because it's very likely that a user doesn't want all that, right? You're going from like a couple kilobytes of data at most if you're querying a large bit of data to like, megabytes, depending on how much chip information you're sending back and depending on the number of devices you have there, like it can get big fast. Yes, I think that like GraphQL is a good consideration for that. And then also just being really specific about the larger data types and the like things that can get wide really quick, like chips.

Ryan: Yeah. No, you're right. The way it's written now, it pretty much assumes that you will get everything underneath the path you asked for, which, as you say, could potentially be huge. Yeah.

Brett: Lesson learned from ASIC-RS, for sure.

Ryan: Yeah, yeah, right. Yeah, those are good points. We should look into that further. I wonder how GraphQL interacts with this whole... I'm in the wrong window. These JSON path specs.

Brett: I think each leaf just ends up being like GraphQL is structured very, very similar to what you're trying to do here. So I think it makes a lot of sense. I don't think it makes a lot of sense with mutations. I think mutations are kind of silly. Those make way more sense to have as traditional API endpoints. But since you're building out a really smart system here with like the branches and the leaves and stuff, your traditional API is going to be really simple. And then just implementing GraphQL as read-only will probably make a lot of sense. And then last thing, and I'll let you get back to it is there any chance we shove a CGMiner compatible endpoint on 4028 just for discovery? Because this is something that ASIC-RS would really like to see is like, even if it's just like dev details and version and just something that says, hey, this is Mujina, like go look here. I think that would be really, really useful just because like that's what everybody else is doing.

Ryan: Yeah, absolutely. And now that you mentioned it, I remember you telling me that early on and I said, yeah, of course we'll do that. And then I promptly forgot. So, okay, I'll take that as an action item too. Where's the best place to know exactly what data you want there?

Brett: Like you could just look at the actual cgminer spec. I could send you some example outputs too, but it's, you just follow the like cgminer status thing. So you go like, status and then you have a mapping or yeah, I think it's status list mapping, status success. And then you just shove some information in the like result message. It doesn't really matter what it is. But I'll find out what path ASIC-RS is checking for different information. I think it's literally just looking for strings. So if you put Mujina anywhere in that response, there's a good chance that we could discover it.

Ryan: Okay. I mean, yeah, we'll just do whatever you want to see there. So you're saying, like, if we pulled this from a live S19 running Braiins or something, that's essentially what you're looking for?

Brett: Braiins, stock firmware, whatever. I can send you a command to do it. It's basically just... You just send JSON and you pipe it to netcat on port 4028 for that. And the message is just like command colon dev details or command colon version.

Ryan: Okay. Sweet. Perfect. And I meant to ask you before, can you just briefly tell everyone what GraphQL is, who may not know?

Brett: Yeah, sure. So GraphQL is... It's kind of hard to explain, but think about it like being able to query a whole subset of paths all at once. So you might pass boards, and then for boards, I want a loop for each ID. And then for each ID, I want the hash rate, the temperature, maybe the chip count, and that's it. And it just returns those specific items structured exactly the same way as your request. It might almost be honestly be easier to like show an example of this, but, yeah, think about it like making a JSON query where your query is a mapping of all the items you want, and then it returns, each of those items, but it just fills in the values.

Ryan: Yeah.

Brett: Yeah, exactly as Jer said. It fills in the information that you're missing so you don't over-query stuff. If I was to query boards on a branch, so we're grabbing the whole boards branch, it might return way too much information that I don't want. Maybe I only want three or four items out of there. GraphQL lets me select which items out of there that I want.

Ryan: Yeah. Okay, perfect. That makes a lot of sense. Anybody else with comments? Dylan, I think you posted a discussion last week after the meeting that was sort of related to this, right?

Dylan: Yes, tangentially. So I was kind of waiting. Just because right now, let's say you have some sort of Braiins miner running. You have three boards on, let's say, a J-Pro. You want, let's say you call it 1,000 watts. It'll try to split up that allocation. Of the available power evenly across all three boards which works great you have the same model it's whatever but I was thinking in my mind's eye let's say you have a heating system that ties in you have two s21 boards whatever variant and then you have two s19s I was thinking it'd be beneficial if Mujina knew to utilize the two s19 the s21s first as they're more efficient And let's say you have something happens in your system, you have more power available, and then it can start using the S19 boards, or you need additional heat output. And so you can toggle on the S19s as needed once the S21s are maximized. And there's a couple other allocation strategies to talk about as well, but just trying to think in advance as Mojito development is happening is how, one or multiple strategies could be built towards and not just a naive, here's a kilowatt, split it out evenly.

Ryan: Yep. Yeah, so this was sort of like, what would Mujina do with a set point in the API like that? Was there anything that was missing API-wise? Oh, yeah. You mentioned there was sort of, in our examples at least, there was no like...

Dylan: Aggregate targets right because right now if you had multiple boards yeah you have to set it per board yeah so even like the naive just split it equally would be a great place to start and then from there we can work on different efficiency or allocation strategies yeah so I don't know if that would go like kind of how this mentions at the high level of the tree or somewhere

Ryan: Below the demon but above the boards I don't know where that would land in the tree yeah yeah so if anyone wants to take a look this is the discussion here number 64 I kind of answered back that again I think this is something I stripped from the document because I remember having this at one point but yeah I kind of picture there being a another top level collection that's for sort of aggregate values like this like where you could pull the aggregate hash rate power or set targets like power in this that you were talking about yeah and I kind of waver of like you know how smart does Mujina need to be

Dylan: Like, at what point is this system abstracted to a controller on top of Mujina or running in parallel and just tells Mujina to do X, Y, and Z? Or how much of this should be built into Mujina, giving the user a choice to pick different strategies for how to run the system? Right.

Ryan: Yeah, so leaving the API for a second and just talking about this. This discussion and the strategies. Yeah, I would encourage everybody to read the answer I gave because I think I tried to address that. I agree with you. Like, you know, we want to definitely, you know, there's an old Unixism about creating mechanisms and not necessarily policies. So like you want your program to expose a means to accomplish all sorts of things. But not necessarily layer on top of it restrictive rules that prevent the user from doing whatever they want with those mechanisms. So I sort of see the Mujina demon itself emerging the same way. We should cover the basic and obvious policies and strategies for scheduling work between boards. Whereas scheduling includes all the considerations of power consumption, how you're splitting among various pools, backup pool strategies, all that stuff. I feel like there are some things that are obviously going to be baked into Mujina, you know, like do the most efficient allocation. That seems like that should be baked in. I probably listed a couple others here, but yeah, once it gets to something that's like really complicated or maybe site specific, like let's say you know that on your sites, like three of the boards are, routing heated water to one zone of your system. And then there's other couple boards that are on a different zone and you want controlling temperatures in different zones differently or, you know, whatever. Like once it gets... More wild like that, then the architecture should shift a little bit to like, now you have another demon running alongside Mujina with knowledge of your system. And then at that point, we want to make sure that Mujina always has the right things in the API to let other demons manage it well. So making all the knobs and measurements that Mujina has visible. But we won't necessarily bake in wilder strategies into Mujina itself. But at the same time we don't want Mujina to show up without, without any batteries included. So we'll have basics.

Dylan: I guess this is more of a function to think through which knobs and levers and whistles do we need to bake in?

Ryan: Yeah. All right, I think we have the right strategy. And time will tell where we decide to put what. So yeah, no, that was a good discussion. Anybody else have any input on that one before I move on? All right. Other discussion. This is a good one. Jayr, you sort of kicked this off with one of your PRs, and then you've talked about this before. Since Adam's not here, do you want to talk about number 72 here? Yeah.

Jayr: Yeah, so this is one of the most interesting pull requests I read in a while. So to give the context, what happened is in the effort to introduce stratum v2 support to the ESP miner firmware, Adam basically identified that there was a lot of duplicate shares. And I also reported the same because I tested it with the GitHub. So basically we started like observing a lot of like duplicate shares. In ESP-Miner, right? So this is Bitaxe's native firmware. Yes thank you and I also like in my first implementation of the stratum v2 protocol in Mujina I also observed the same if you remember I even introduced this thing like to deduplicate like the shares so that we wouldn't be like submitting things that were already submitted And then what this research of his surfaced is that there is a very like subtle challenge with, you know, controlling the non-slicing so that, you know, How can I say? So it has different faces. So I'm going to just try to gloss over instead of diving super deep. And then if needed, we can do that as well. But basically, because we're not slicing the nose space too well, and because the jobs that we pass to the ASIC chips, they might be covered. Faster than the timeout is happening or maybe it's the opposite maybe the space is too big and then the chip would never actually cover that space so the whole like issue is around how we slice the nonce space and how we, handle that with the ASIC chip. So timing out jobs, you know, setting the proper register so that, you know, once we are about to like wrap the nonce space and start all over from the beginning, instead we would, you know, just have a new job take over. So he, he goes into very like a deep level. And basically, with the math that he learned and developed with this pull request of his allows, even if you are, for example, overclocking your mining devices, you would still be able to adjust the jobs and the no space that you allocate in your topology so that you would be almost like covering 100% of the space for that specific device. So you wouldn't be wasting or having too little nonce space for a specific board or chip and so on and so forth. So I think basically, he learned a lot, and the learnings are mostly, I would say, generic or agnostic, so that we can bring the learnings to Mujina, how we can calculate what are the registers that we need to write, how we can size the timeout, and all of these details, we can also bring the learnings, and then, especially since Mujina is meant to... To how to say like to work with bigger like operations big like devices that are more powerful than the taxes right so I think it makes a lot of sense for us and that's why I mentioned and then like thankfully adam also chipped in here so yeah

Ryan: Yeah, this is great. I'm really glad that he shared this with us and that he did it personally, jumped in here and wrote some discussion stuff. In fact, I feel bad I haven't replied yet. Sorry, this last cycle has been sort of crazy for me, getting ready for this trip and traveling and all that. But yeah, I need to reach out to him and thank him and engage this because this is great, first of all, to see collaboration between the BitX guys, ESP-Miner and us. And yeah, they have a lot of experience with this hardware that we can learn from. So yeah, I remember when I was originally implementing the driver for these Bitmain chips, From the reverse engineering, it didn't fully... And all the research I did, even into ESP-Miner, I think some of this might be sort of new because even at the time, maybe a year ago, it wasn't well understood what some of these registers did and how they controlled the search space that the chip works through. So I'm excited to see what they've learned and take that into our code. So yeah, thanks for... I'm sticking on this and interacting with Adam so far. I'll reply to this discussion soon. Anybody have any questions about that?

Dylan: Just a quick comment. I thought it was cool that Batman is working on Mujina.

Ryan: I thought the same thing. What a great nymph, if that is true. I love it. Okay, what else on the discussion list here? Okay, we already hit number 64. Why did I put this here? Oh, I just wanted to mention again, since it's new that we created this, good vibes category and discussions for people to put, to share, vibe-coded branches, prototypes, things that aren't really quite destined for merging or ready for merging, but that they want to share with the community anyway. That might come up a little later when we get to PR, so we probably should talk about where certain things go. Anybody have anything else for discussions before I move on to issues? Okay, issues. There are several, okay, let's just take a look at the whole list. There are several open issues. Most of them are just contributor-friendly, you know, start here if you want to contribute something. And I saw in my email that, was that you, Brett, that fired through like a fix for number 52?

Brett: Yep. It's pretty quick. Like it's just a couple expect statements replaced.

Ryan: Yep. Yeah. I mean, obviously a lot of stuff here is like stuff like we could work on, but it's nice to just put some little hanging fruit out there for people who want to get started. And for something that isn't like urgent.

Aadhi: Right. And I think, I have like Mujina like running on windows, but, I think I should like create a PR and push it.

Ryan: Oh, cool. Yes. I'd love to see anything you had to change. Even if you just put that in good vibes or start another discussion for it and just link to your branch, whatever you think. I mean, if you want to organize it into a mergeable patch series for a PR, that'd be great. But even if you just want to share, that would be cool too. I'd love to see it. Perfect. Okay, good. I guess it is good. We go remind people what's on that list. Sort of my wishlist was for... To be able to run in Windows. Okay, there is one issue that I wanted to talk about specifically. There were some issues, there are some issues in mainline in the CPU miner. Jungly noticed some of these when he was preparing for the last telehash. And I noticed them in a big way the last couple of weeks preparing for this workshop I'm going to give in Nairobi, part of which uses a CPU miner. And so I jotted, I mean, I doubt anyone else runs into this stuff because who's CPU mining, but I logged it here anyway. This is something that worked for the last, last, last telehash. And then I made some changes in other areas of the job sources that sort of impacted this and made it work less well. So I mentioned last week that I was working on some fixes. I have a whole branch here of things related to CPU mining that I will probably try to get this committed this week, actually, because I want the students here to be able to pull mainline Magena and use it rather than a branch of mine. But there's lots of stuff in here for fixing CPU miners. And then let me see who's got their hand up.

Tyler: Jayr, go ahead. I just had lost the tap, sorry.

Jayr: I was just, I wanted to say that maybe a month or two ago, black hash reached out. I was actually trying to find the exact issue. It was some of the, straddle V2 repose, and he wanted to use our CPU miner, like to replace their own. They have an old implementation they created, but then they didn't really maintain it. And he seemed pretty excited that we have CPU Miner. And as a matter of fact, during the development launchpad I attended with Vint Hume, he used CPU Miner in one workshop for us, like 40, 50 people using it. Oh, from Mujina? Yeah. Just to show that, yeah, some people, they actually do see a lot of value in this.

Ryan: Yeah, no, thank you for, yeah, good point. I meant more, I doubted anyone on this call had used it. But yeah, that's good. I don't think I remember that he used it. But he would, wouldn't he? That's very cool. I've also been told by Jungly that they replaced their P2Pool v2... Like testing stuff. They had, I don't know what they were using, maybe cgminer. They replaced all that with Mujina too. So they're using it, which is why I feel especially bad that I broke it. So... So, yeah, and there's really no excuse because of all the things that should be able to be CI tested well, it should be our CPU miner, right? Because it doesn't require external hardware. So that's totally my bad. And, oh, cool. Can you put that on that bug, a comment on that?

Jayr: Yeah.

Ryan: Or if that's appropriate. I didn't click through and see what that was, but that was like a comment for us. Yeah. So yeah, so I recommit to keeping the CPU miner of a full-fledged feature. I always meant for it to be. It just kind of got neglected there for a minute. But so I fixed the bugs that everyone noticed with it. I also added some new stuff. So what here? I'm looking through this list. It did not previously support difficulties less than one, fractional difficulties. Which only shows up in a test situation, but it's very important for a test situation. So I fixed that, piped that all the way through. We sort of supported it, but only halfway. The CPU miner didn't understand it. And At some level. And also, I don't want to get into this too much, but Mujina does something interesting, I think, compared to like a Bitaxe at least. And that is like when it connects to a pool... It doesn't really know what to suggest for difficulty. Like as a rule, it's not like built for one instance of hardware necessarily, right? Mujina responds to like whatever's plugged in. So you could have, you could be CPU mining with like a mega hash per second, or you could have a ton of boards plugged in and be like at 500 terahash per second. So obviously those are very different things. Difficulties to suggest to the pool so one of the things the scheduler sort of has to be aware of is what's plugged in and how much hash rate is going to be directed at any one pool so that we can suggest difficulties correctly and so making sure that works is a bit of spaghetti sometimes but I think I sorted most of that out another thing that I would in the same area that I'd love to have like someone like Jungly comment on sometime is So in Mujina, you can also hot plug boards. So you could be connected to a pool and all of a sudden plug in like three times your hash rate or unplug three times your hash rate, you know, because you take boards out. And so rather than wait forever for the pool to adjust to your difficulty in those situations, adjust to your hash rate, which it will given enough time, I also have Mujina suggesting difficulty on major hash rate changes like that. So some pools pick up on that and some pools don't. And that's definitely something that I think Stratum V2 is going to care about. You can tell me whether that's right or wrong, Jayr. But anyway, this difficulty thing, there's some extra challenges to Mujina with its hotplugging. And so a lot of the fixes I made this last couple weeks are in order to get that right. So that'll be fun. And I think that'll be an interesting point of integration with pools is because I don't think many miners suggest difficulty throughout the lifetime of their runtime. I don't know. Do you know, have you seen anything like that, Brent?

Brett: Is it a masonry?

Ryan: Yeah, I was wondering if, in your experience, you've seen miners or setups that will suggest difficulty to a pool after being connected for a long time because their hash rate has changed for some reason.

Brett: I can't even think of a miner that would do that. The only thing that I could think of that would think about doing that is Proto's new rig.

Ryan: Yeah.

Brett: Because nobody really supports hot plugging anymore, right? But yeah, honestly, it's not really my area of expertise, so I wouldn't really know. But you think about like, okay, for example, an Ant miner or a Watts miner or a Canaan Avalon miner, all of those are using bus bars for their power. So they do not expect you to ever change anything while the machine is running.

Ryan: Right.

Brett: Right. It's like bus bars and bolt them down.

Ryan: Yeah. True. I wonder if some of these rigs where you can like select a low power mode.

Brett: Yeah, I can see that, but you're looking at like the biggest change I've ever seen is LuxOS on an S 19 K pro, which was like 140 terahash to 60 terahash. So cutting your hash rate in half, how big of a deal is doubling your difficulty at the pool? Or having your difficulty at the pool not much right like I just feel like that's not a situation that the pool really cares about that much like I guess the other situation is like oh I run a massive data center and I just turned on 20 pdus with a bunch of miners on each of them and now I have more miners online but Generally, you're not putting those into the same worker name. And even if you were, an individual miner couldn't suggest the difficulty anyway. So it's still just up to the pool to figure that out.

Ryan: Yeah. Yeah, maybe proxies do this too. Anyway, that's something to watch for.

Brett: That would be a better thing to look into, actually, is how do proxies handle this? What does the SV2 proxy do when it has a boatload of miners coming in under the same worker name and it wants to send them out on the same worker name? Is there any optimization that it does there? What's it doing?

Ryan: Anyway, there's lots of details here. I guess I mentioned it just to be aware of. This is something that Majin is trying to do that's a little bit unique and may or may not cause integration issues with pools. I'll get Jungly's take on this at some point as a pool author. And I think we'll see some interaction with SV2 on this too. Right, Jayr? Does this ring any bells? Did you run into anything like this when you were integrating SV2?

Jayr: Can you please repeat the question? Because when you asked the first time, I was a bit distracted.

Ryan: Oh, sure. I just pointed out that one of the recent changes I have coming in has to do with the way Mujina changes difficulty, suggests difficulty on the fly as you plug in new boards. So within one stratum connection, it may decide to suggest difficulty. Because the hash rate has changed in a major way. Stratum V2 has some awareness of that too, right?

Jayr: Yeah, it's because the way it works for Stratum V2 is that you have your nominal hash rate, which is something you declare when you turn on your equipment for the first time. And then you can also, there is a message in the protocol to update that value. So that you can keep the same average number of shares within a minute, right? Because that is calculated. They have this mechanism called VARDIF. Exactly meant for giving you a consistent stream of shares within a period. So I think I know what you're talking about. It's because since now this exists, then we need to have that value in the CPU miner as well. Is that the thing? I think I remember in my pull request.

Ryan: Yeah, I'll have to look closer at how your pull request integrates with this. It actually goes beyond the CPU miner. It's a scheduler level and job source and client level issue. All the job sources are given updates as to what the hash rate that should be headed their way is. And then the job sources can decide what to do with them. There's a dummy load job source that doesn't care. A Stratum V1 client obviously may want to suggest difficulty again. And it sounds like the Stratum V2 client will, you know, has a message for doing the same thing, sort of like suggesting difficulty. So yeah, it's sort of across, it touches many components, but I just wanted to mention that I had made some changes to that recently because it wasn't quite working right.

Brett: In theory, it's not that hard to compute this, right? You just compute your nominal hash rate based off of core count and clock speed and then pass that upstream, right? I assume that's what you're doing?

Ryan: Mm-hmm. Yes.

Brett: Yeah.

Ryan: But I think for...

Brett: I don't think it's a big deal.

Ryan: For... Yeah. What I ran into with the CPU miner is it's sort of fun. Like, the CPU doesn't necessarily know. Like, that is sort of hard to predict ahead of time. So it actually... Oh, yeah.

Brett: Compared to an ASIC where it's like, oh, my clock speed is two, so I'm going to compute two hashes every second or whatever, right?

Ryan: Yeah. Like, the CPU is all over the place, depending on your machine, depending on other things. So...

Brett: Yeah, OK. That was a good test.

Ryan: That was a good test for me of this whole mechanism. You were saying something, Jayr?

Jayr: Two things, actually. So I think this last comment about you, can you help me with the B. Rowan's name? Is it Brett or Brad?

Brett: Brett. Yeah.

Jayr: Brett.

Brett: Yeah. Sorry. Maybe I should just come on here with my actual, I just go off my like GitHub username.

Jayr: Yeah. No, that's okay, man. I just wanted to say that, you know, I think this last comment was probably related to that, four 20 pull request I mentioned earlier, the one on like a nonce, space because like this whole like calculation, it also has to do with that. The second point is like, if I remember well, Ryan, there is something that we do. It's like the job that we give the ASIC, it actually has a lower difficulty or a higher target because that's what we use to, like we... Accept the shares that we wouldn't broadcast to the upstream, and those shares are meant to help with the hash rate calculation, right? Yes. So yeah, I think that might also somehow help in this.

Ryan: Yeah, we do. Yes. I won't get into details of it, but that's one of the things that sort of changed, because the scheduler does measure hash rate live that way for its own reasons. I ran into some issues where it was tough to know, like as a machine is warming up, you know, that measured hatch rate like swings around a little bit. And so I was running into cases where I was definitely over communicating with the pool about my hash rate changes. And I really just wanted to give it a nominal, sort of a nominal value. Like I'm going to get here eventually. This is what the difficulty I want from the pool is. Versus like tracking actual too closely. So I split that up a little bit actually recently so that... The hash threads can more just declare to the scheduler, like, this is what hash rate I'm going to give you. Like, I might be warming up for a few seconds, but I'm going to get up to, you know, 120. So don't overreact to my low value right away because I'm still ramping or something like that. So, yeah, all this stuff is sort of related. But we're probably getting too detailed for here at this point. So I'm going to leave that.

Jayr: We only have a few more minutes let's see what's worth talking about the PRs well definitely tell us about your big PR jr this is a big gyre this is a big deal yeah so I mean I've been working on this for a little while I think this is like my second or third implementation obviously like the first ones were just like vibed, cause I was like, learning SV2 spec and like playing with it, trying to connect to their pool and see like all the messages and the flow of messages and so on. So finally, like after a couple of also like iterations with LabHash, LabHash is a friend of mine and, He's been guiding me and helping me with the SV2 support. If you guys don't know who he is, he works at the SV2 team. And if I could maybe mention one thing, how this one is different from my previous implementation is that I try to leverage as much as possible of their code. And by their, I mean straddle mining organization. So they have a few crates, like channels SV2, they have Codec. SV2, binary SV2. And this is valuable because since this new protocol, it has a binary protocol instead of JSON-based as we are used to with the RPC. And it works with frames. So there is some logic for you to be able to consume the frames and route the frames. And on top of that, you also have the fact that the communication is encrypted, so everything there is noise encrypted. So you have these variables that didn't exist before with Stratum V1, because it was more of a request-response JSON-based protocol. So in that sense, it was simpler to integrate, but then it had a bunch of other downsides. So basically what I did was like, okay, I'm gonna use as much as I can of their library, especially since they also wrote everything they do in Rust. So we could like just declare these as dependencies here and then just like leverage as much as possible. So I didn't have to like set up my own like, noise communication or like shasha or poly encryption I didn't have to do any of those things I mostly like you know brought what worked from them. I had to do a little bit of a state machine to basically make sure that the messages, they are a thing. For example, in the beginning, we have a handshake of sorts. There's a sequence of message that needs to be completed. And then after that, there's a loop. So I mean, it's pretty straightforward, to be honest. But it's a big pull request, 3,500 lines. But at the same time, if you see my other implementations, they were a lot bigger and a lot more complex. I think like the amount of lines here, like a big portion is because also I introduced some integration tests. So you'll see that I have a great deal of integration tests that I actually like raise a proper pool. And then like the pool and the client, they are like communicating over the network in my integration test. So I did like a full blown, like a black box testing here, which I'm much like sure we will want it in the final solution. That's something I wanted to hear from, from Ryan. I did check like from like our SV one integration and we don't have those there.. But I thought it would be a good way for me to gain confidence in what I'm proposing here. So I did that. And I think, I mean, that's it. If you guys have any questions or comments, I'm happy to take them.

Ryan: This is awesome, man. Well done. So yeah, I definitely will be taking a serious look at this soon once I get over this trip. And so this looks way more mature than the previous versions. So this is the version you want us to start massaging and getting merged, right?

Jayr: Yeah, because, like, last week I spent mostly, like, after I raised the PR, I was like, okay, let me just, like, check everything over, like, twice. And then, you know, because if there's still something here that I could improve and, like, change before I make it ready for review. But then, like, at the same time, I could be getting feedback, right? And I did get some from Adam, which was good. But yeah, I think I would honestly just like to see comments and feedback from other people, because maybe my eyes are too biased at this point.

Ryan: I know the feeling. Yeah, this is excellent. I'm really excited to get this merged in. This is perfect. And just general comment about the test question you asked. Like, yeah, probably the more the merrier. So, you know, the only reason I didn't write enough more for SV1 was probably just because time or I didn't have nice crates to work with that already had some of it. I think it's great that we're leaning on the reference crates like that. That's why they wrote them, right? I'm sure they're very excited to see us actually use them. So this is great. I think this is good. So we'll focus on getting this merged once I get some bandwidth to review stuff. Thank you. Looking forward. All right. We're sort of over time. Let's make sure there's not something else big we're leaving out. Let's see. What is this? Oh, you wrote some doc updates. I'll take a look at that. That's probably something I should have already merged. Jayr wrote some updates just based on our conversations to our contributing docs. Schnitzel has a few things that he ran into with Dumex here. And then I still need to look at your... Latest fan speed controller, Jayr. Sorry to be the bottleneck here for a while. It's been a crazy month. Sounds good. One thing So, okay, this is one thing I did want to talk about. He's not here, but Ronald contributed a bunch of different documents about the way BZM2 behaves. And this time changed them to be PRs into markdown files in the docs directory. I think we need to think about this. I'm not sure that I want to merge... Just general purpose reference documentation into our tree. Though I don't want to lose this. I really appreciate the contribution to the project. I do want this to be available somewhere and for us to sort of archive it. I just don't know if I want to mix it into our code tree unless it's describing code we've already got. So we need to figure out how we handle these things as a group. We can table that till next time. I just thought I'd throw that out there. Does anybody see that and have any thoughts? All right, well, we'll deal with it later.

Dylan: I didn't see it, but I agree with the framing of not just having extra stuff in the main line unnecessarily.

Ryan: Yeah. Yeah, just kind of like having... Same spirit as like, you don't want dead code that just kind of, you don't know if it's up to date anymore or maintain. It's not something, you know, we're like signing up to maintain and that it's correct. So yeah, it needs to go somewhere. Just probably not in our tree. All right. And I threw a link in there to the workshop I'm about to give this week and here in Nairobi and, I'm doing sort of just a general purpose mining class, but I'm using Mujina as like a hands-on component. And also Solo Satoshi donated 15 Bitaxe boards for me to bring here. So I'm going to sort of take people through Mujina CPU mining. And then we're also going to enter the ASIC era by using Bitaxe as hash boards plugged into Mujina. And the class is sort of just a tour of... Getting your hands dirty with mining. But the theme of this Nairobi conference is of this Bitcoin++ is open source. So 256 naturally had to show up and represent open source mining. So I'm really excited to get more people to see it. Yeah, they are gammas because that's what already works. Yeah, I'm all for us having driver support and board support for all the Bitaxes. I'm just unlikely to add one myself personally in the near future, but yeah, go for it. I'd love to see more. What was the other? There was another comment I missed. Ouch, it's covering up.

Brett: Comment button with... Aadhi says, by the way, I'm working on getting Mujina working in Braiins Mini Miner 101 and Canaan Avalon Nano 3S.

Ryan: Very cool. Yeah, Aadhi, next week I'll have you share some of the stuff you're working on. That'd be very... You might have mentioned that in chat and I just missed picking up on it, but that's exciting. All right, I don't want to keep anyone over any further, any longer. I'm happy to stick around and chat for a little bit, but we'll call it there. I'll stop the recording.