-
Notifications
You must be signed in to change notification settings - Fork 47
dev call 20260831
Ryan: Recording is on okay we will not acknowledge who is here all right let's get started welcome everybody I'll try to stay organized even though I'm not at my normal workstation I have Mr. 9000 next to me in attendance. We are in the podcast studio at Bitcoin Park, but we're on my laptop because it's not easy to like plug in foreign equipment here, sadly. So if my audio or anything is crazy at some point, just holler and I will try to change it because we're using our speaker and microphone. So I don't know if there's echo or whatever. Hopefully Apple cancels that well. Okay can you see my screen yeah we can thank you all right so welcome to our bi-weekly call our agenda is to roughly follow this discussion post here where we go down through the different categories of maturity as things flow through our project, discussions, issues, PRs, et cetera. This is recorded and we post the transcription later. I will try to hand off to people as, the topic involves them, but feel free to interrupt me and feel free to interrupt me and at any point if you have something you want to say. So we'll start with announcements on my part.
Ryan: So Skot and I are here in Bitcoin Park because we're doing mining illustrated tonight. So this is the workshop I ran in Nairobi. And you may have seen I've posted, reposted several versions of this that have been hosted by people I taught in Nairobi. They've held these workshops all over Africa. Swimsuit issue. Yeah, Skot, it's hot here in Nashville. Yeah. So that's why I'm wearing my swimsuit. That's why we're in swimsuits. So it was always my intention to run this workshop again wherever we had the chance to. So we're doing it in Nashville. Hopefully we have some good attendance tonight. This is the workshop where we've got a Bitcoin test network set up in the room. That's that devpool repo that I've shared before. I should have put a link here, but I didn't. Devpool is a development stack anybody can use. It's not under the 256 organization, but it's in my GitHub repo. And it's a stack of containers. It's a Bitcoin node, a mempool.space instance, a dashboard like the 256 dashboard, a Hydrapool, and a couple web pages of instructions and you could use this to spin up like a custom test network if you're hacking at home or also like we're gonna do here for a whole group of people I've hacked that bitcoin core and Hydrapool combo to work at very low difficulties. In fact, Hydrapool in that instance will do fractional difficulties, so you could reasonably mine to it with CPUs and Bitaxes and whatever else. And that network finds a block every 30 seconds-ish. And it adjusts quite quickly if you pile on a lot of hash rates. You can start out with CPU miners, add more CPU miners, add Bitaxes or whatever, and the hash rate dynamically adjusts within a few blocks. So it's good for a classroom or for testing. Anyhow, we've got talk and some hands-on here tonight at Bitcoin Park. If anyone's nearby, probably not. Maybe we'll do one at the space. Or maybe we'll maybe we'll do maybe we'll do that at Heatpunk summit next year so that's why we're here in Nashville that was announcement number one.
Ryan: Announcement number two, you may have seen on X over the last week that the 256 Foundation is now part of the Stratum V2 working group That means we get our logo on a web page somewhere. It also means that Tyler and I joined a call. I think it's once a month. So we did this last Thursday. I don't have a whole lot to bring back from that. If I ever do, I'll mention it. They mostly talked about security issues because I think this was their first meeting since the AI red team apocalypse descended on every project and filed a bunch of issues. So that's mainly what they talked about is issues in Stratum V2 and how they were working them. That doesn't have a lot of bearing on Mujina at the moment because our Stratum V2 implementation isn't in our mainline tree and Even if it were, there's not a ton of people using it. And there really wasn't anything security significant that they brought up in that meeting. So anyway, it's nice to have our name associated with that.
Skot: Who else is in the working group?
Ryan: Oh, good question. It's bigger companies than us. So like Braiins is in there, Foundry is in there, Mara is in there, Block. Yeah. All the big boys.
Schnitzel: So, and is it just a monthly call or is there like a forum or what? Like how does it work?
Ryan: Jayr has answered that question.
Dylan: It's seemingly just a monthly call.
Ryan: I'm trying to find the chat thing you just pasted. Oh, a picture with all the working pools, groups that are involved.
Dylan: Is Pyblock a Bitcoin mining pool anymore?
Skot: In their minds.
Ryan: So yeah, there's nothing very tangible for us coming out of that at the moment, but it's good to be in that conversation. Speaking on behalf of the Mujina project and the 256 organization like we want to throw our weight such as it is behind SV2 because we think that's ultimately the right direction to head in a well-defined protocol that answers a lot of the feature requests that we've always had for SV1 and importantly The job declaration is sort of the job declaration features in SV2, which are optional. SV2 has a lot of optional features. Those job declaration features are sort of the open source equivalent to Datum. So that's what would allow people to mine to a pool yet pick their own block templates. So that seems like the right way to do it rather than... Although who knows what becomes of Datum now that Ocean is sort of fruit basket upset but in any case SV2 is trying to be the community well-defined project for all that so that's why we want to be involved and want to implement it in our stuff and want to throw our weight behind it that's also something we want to see happen in Hydrapool although that's that's only aspirational at the moment that's not something that's underway so that's the Stratum V2 working group antpool is in oh yeah antpool that's interesting I don't remember there being any representative who I recognized or who represented himself as like hey I'm here from antpool I'm on the call like it was mainly the people I mentioned plus several people from SRI, the Stratum reference implementation guys.
Ryan: So, and then the next announcement is, this will show up a little bit later in PRs, but I have gone ahead and forked the bitaxe-raw repo. And turned it into its own repo under 256 Foundation that is purely the pass-through firmware for Bitaxe Gamma. And I have started calling it RHAP. So bitaxe-raw is, of course, the pass-through firmware that we run on Bitaxe Gamma so that Mujina can talk to it and it's also useful for testing and of just at a hardware level you want to poke around at the hardware that raw access is nice then that sort of same idea became the way to talk to the EmberOne so EmberOne has its own firmware that implements this protocol So for a while, I've been saying, hey, that protocol needs a name. Like, it's not just something that one firmware implements. It's something we're going to have implemented in many places and clients for it. So like, let's give it a name. So I gave it a name. RHAP, Raw Hardware Access Protocol, pronounced rap. So this is the RHAP protocol. So I... With Skot's blessing, at least if he remembers from a couple months ago, he was like, yeah, that bitaxe-raw, like that firmware, that's like not the official firmware for Bitaxe. So Mujina should probably, it would be okay if Mujina sort of had its own version of firmware to be put on Bitaxes for this purpose. Anyway, so that's what this is. This is a standalone firmware implementing the RHAP protocol for Bitaxe Gamma. And so there's a repository now under 256 called RHAP-D. RHAP-D sort of is meant to make you think Linux daemon, but it's on raw hardware. So it's really the device, the D stands for device role in the protocol. So RHAP-D implementation for Bitaxe Gamma.
Skot: And is the idea to keep the protocol the same?
Ryan: Yes. Yeah, absolutely. The protocol is the same. It's just, you know, its implementation on different hardware boards may look a little may have different features. Obviously, they have different like pin assignments, you know, stuff like that. But I also went ahead like once it became its own repo, that sort of gave me the freedom to implement a bunch of the things I wanted to implement. But I didn't wanna mess anybody else up who was also sharing that firmware with us before. So like on this hardware I wanted, like when you power it up, I want the regulator to start off. So there's no power to the chip. Like what else? I'd have to go back to look at my commit history for what I did yesterday because I remember but oh and I put some stuff on the screen like I wanted to put I wanted to put some things you could see that it was alive when you turned it on so like now the screen puts some there's something that goes on the display so so yeah I think every every piece of hardware will sort of have its own implementation that does board specific things but it's like it offers that protocol interface. And that protocol should be as standard as possible. So I didn't do anything that would change that breaks compatibility. And that protocol could also be something like ESP-Miner it one day in the future, if anybody cared, which you might, it might never but you know, it might offer that mode, right, like built into it. So like, press this button or boot up this way. And then ESP-Miner, you know, offers a RHAP device interface or whatever. Does that make sense? I'm just trying to separate the concept of the protocol from the concept of like the firmware implementation. So now anything can speak this protocol, anything that wants to, like the EmberOne firmware speaks this protocol and this Bitaxe Gamma firmware, the special one speaks that protocol. And that's about all it does.
Skot: Yeah, I mean, I think that could be really useful for a lot of things, right? And if we stick to the same protocol, yeah. It could be useful in the factory for building Bitaxes and testing them and all that stuff. So I think that's a great idea.
Ryan: So there's that. The bitaxe-raw repo has several branches for different hardware flavors.
Dylan: Mm-hmm.
Ryan: So I guess we could just consider the Bitaxe Gamma portion of that sort of abandoned at this point. I have no intention of doing anything with the other boards that I don't have hardware for or anything.
Skot: So is it the idea that it's going to be, it's like RHAP Bitaxe, RHAP EmberOne, RHAP whatever. That's how we do it. Different repos for the different hardware implementations.
Ryan: Yeah. Right. The protocol is just a standard thing. But yeah, each firmware for its own hardware is its own repo and its own totally own thing. For the most part. And it doesn't have to be named RHAP either. Like the reason I named the Bitaxe Gamma one RHAP-D is because it's that firmware is designed specifically. It's like an alternate to the regular firmware and it's just for serving this protocol. So like that doesn't mean I'm going to go rename. There doesn't need to be a RHAP-D for ESP-Miner. Sorry, RHAP-D for EmberOne. Like the EmberOne firmware could be called EmberOne firmware. And it just happens to serve the RHAP-D protocol interface. Does that make sense?
Skot: Yeah, that makes sense. Yeah, because in a lot of cases, it will be the default firmware for like Bitcrane.
Ryan: Yeah. So we don't need to go around renaming everything RHAP-D. I just named this one because it's like an alternate firmware for Bitaxe Gamma.
Skot: Awesome. I think this is a great idea. We don't want to get in the Stratum V1 case of it just got defined by various implementations.
Ryan: Yeah. And I haven't yet, but I'm going to pull out the protocol definition from the README and make it its own standalone. Thing that's a little beefier. Good idea. Like independent that can be pointed at by all the things.
Skot: Ooh, yeah. I like that. Like agents. Yes.
Ryan: So there's the big haps in the last couple weeks that don't fit into everything else on the list here. Anybody want to say anything before I move on to our PRs? Any questions about this firmware stuff? All right, hearing nothing.
Skot: Well, we need to get this ported to an app that runs on that runs on Linux, right? So we can get it going on. We do get it going on stock control boards to take its commands over the network. So we can do testing on, you know, existing ant miners and what's miners. Really useful.
Ryan: Yeah. Sort of like raw peek and poke at the hardware.
Skot: Yeah, yeah. It's like a bootloader.
Ryan: Well, to that end, Like this might, I might try to make, I don't need to do this right away, but I might make the client part of RHAP in Mujina its own crate. Oh. So that you could like use it as a library and I'll give it like a little CLI. Okay. So that from the command line, you could, I know you sort of do this now with the, A Python library, right? You've done that for some testing. Yep. So maybe I'll make like a CLI that is sort of the same thing, or it can be, well, for starters, a rust library because Mujina needs that.
Skot: Yeah.
Ryan: But then I could wrap a little CLI around it. Or even there can also be a Python library implementation.
Skot: Yeah I mean I anyway at some point I imagine that like reusable client pieces will spring up too okay yeah I mean I think just my point is that this has a lot of uses outside of just Mujina talking to the Bitaxes so yeah yeah this is good to standardize it have it documented so you can point your agents and bring it because I've I've done like bespoke versions of this probably half a dozen times now for different right things so this would be great it'd be a huge win to have it where you could just essentially drop it on a new miner and start banging at serial ports and GPIO and I2C and all that good stuff.
Dylan: Yeah. Okay, framed that way, this is awesome because my agent was having a hell of a time trying to poke around on my K Pro. And anything to help expedite and make it easier sounds awesome.
Ryan: Yeah, for sure. I mean, really, truly, at the end of the day, we're building all this for the agents. Yes. Yeah, totally.
Skot: Yeah, we just want to make their lives easier.
Ryan: But yeah, but I mean, it's nice to build pieces that are like solid and reusable. And then, because while the agent could figure this out on its own every time, you just point it at the spec, it's also a little bit easier to point it at, here's a CLI to use. And like you're saying, like, If someone implements it on the stock control board once, then it's like ready to go for all the uses.
Skot: Right. I mean, it could be amazing to use an Antminer running, you know, a RHAP-D client and Mujina on your computer, right? So you don't have to flash it to the like stupid encrypted file system all the time, right? You're just... Yeah. You're just able to develop sort of live from Mujina running on your development machine. I think that'd be rad.
Ryan: Yeah. OK, cool. Well, this is the first step in that direction. I've been meaning to do that for a long time. Doing the workshop again today sort of pushed me over the edge, because I was setting up 15 Bitaxes again with firmware, and I wanted to make some changes. Went ahead and did what I had time for, so.
Schnitzel: Another use case while you're talking about this could also be, right, like this is this whole fleet management system. So you have one miner with Mujina installed and then maybe two or three other ones just run RHAP and they connect to that main Mujina. So like four miners or four hardware miners appear as like one device forward to the pool and also like to your home assistant and things like that. Like that's definitely something I could use or could make use of.
Ryan: Yeah well that's the idea I mean that's where this started right like this is the USB serial interface to EmberOne yeah so it's meant to be our USB inter you know our USB protocol to USB connected dashboards does it have to be USB could you run it over ethernet I don't see why not. I don't see why not. There's probably double in the details, you know, with real networks, latency and stuff like that. So you'd have to maybe probably. I mean, for basic stuff, obviously, yes, but yeah. It's just a different latency environment. I'm not sure what implications that would have, but there might be some. Cool. Awesome.
Skot: Yeah. It might be a little bit weird for like production mining, but I think for development, it certainly is. Yeah. It certainly is useful.
Ryan: Anyway, more to come on that in the future. I saw a question. Let me find my text again. Link to the workshop. Is this the same as I did in Nairobi? Yeah. If you follow... If you follow that Mining Illustrated link I put at the top of the page, that links to my repo with the slides. And it doesn't have the slides from today updated, but I will push them there later today once I finish them.
Ryan: OK, working through the PRs. So I merged a big one. I merged a big one that's sort of a stable snapshot of some of the stuff I've been working on. Ryan, why the hell did you merge a 7,000 line PR? You would never let us do that. Well, it's also 78 commits. I don't review things in terms of PRs. I really review things in terms of individual commits so if you go through here you'll see all the commits are small and well formed I just so now that we're a little more rolling as a project I used to just push stuff directly to main myself and I'm trying not to do that anymore I'm trying to like put in a lot of my work through PRs also but some of them are just huge and like it wouldn't make sense to do this as 78 different small little PRs like it's all related related work you know the PR sort of represents the point at which I merge another branch into the tree so care more about the commit size than I do the PR size although obviously a large PR takes a long time to work through the different commits this just happens to work for me a little bit because I'm sort of the only one reviewing it so anyway that's my hand-wavy excuses for why such a big PR. So this represents a lot of rewrite of the Bitmain chip driver stuff to go from something that was just initially written sort of as a prototype test for the Bitaxe as a hash board into something that totally supports all the chips on all the different miners from one driver. So I don't expect anyone else to really look through this but if you're interested in what it looks like there's certainly a lot of cool code here and also that's a lot of commits so you can sort of see the granularity that I typically work at in commit wise and would like to see in other people's PRs as well so it's sort of a good example of that although A 78 commit PR is hopefully the exception for all of us rather than the rule. There's a lot of backlog work I'm trying to get merged in here that really only I care about or I'm the one working on.
Schnitzel: How much, you say that's the, it says first part. How many parts are there, or like what is left to work on in terms of multi-chip support, or specifically S19 and S21?
Ryan: It's mainly just board files now for those and whatever bugs those reveal in the sort of common code that need to get fixed. So I wish I had a diagram to pull up here, but you could probably picture this. And we've talked about it before. But in the code, there's sort of a module that represents the chip and all of its features, all of its registers. Everything is well typed. Yeah, it would be cool to pull up. Do I have any good examples? Let me hop in and just look at something, for example. I don't know. Maybe I'll get lucky. Well, I wasn't really prepared to show code. Yeah, I mean, you don't have to show code. The voice line is fine. And then there's another module that's sort of like the user of the chips that implements sort of a whole chain of chips and you give it work and it knows how to take the chain of chips and hash with it. Those two things are pretty basic and foundational to the way all the bitmain miners work. And then sort of at the very top of the stack is like the different board files that get to reuse those hash threads and the underlying chip implementations. And the idea is that sort of each layer just defines what's unique to it. So each board file EmberOne, Bitaxe, and S19 sort of can just declare these S19 board files. You know, just lay out, like, here are the, you know, this is the chip model that's in use on this board. It's laid out in chains that are this long, configured like this is what the voltage domains look like. And this is, you know, the other hardware on the board that needs driving. And you sort of just pass that configuration down to the common hash thread that knows how to once you give it the layout it knows how to how to drive that chain of chips so most of that common stuff is in and I'm still working on the edges now but it also sometimes pushes me to make changes lower down so I'd say I've banked about half of the work I've got flying around here in this PR and there's about another half that I'm still working on landing
Schnitzel: OK. So what I'm hearing is that it's not at the point yet that it makes sense to rebase my branches on top of it or all that work.
Ryan: You could, but I don't know that it would be a..
Schnitzel: I mean, I'm not in a hurry, so.
Ryan: Yeah. I don't think it would be worth it. OK. All right. This isn't the final milestone to do that on top of yet. Cool. OK. Awesome. I would wait. So that's there if you want to look through it. I'm gonna keep moving unless anybody stops me but just put a hand up or yell if you if you want to stop me.
Ryan: Also merged is the changes related to this RHAP-D firmware I talked about and this is worth showing because this is small so RHAP-D was really just a renaming of the bitaxe-raw protocol. So, and plenty of people have Bitaxe boards out there already with bitaxe-raw flash on them. This doesn't break any of that. All that still continues to work. What I did was the new RHAP-D firmware just has a new board descriptor in the Bitaxe board file that gets matched on so now so the RHAP-D firmware uses the USB VIDs and PIDs that we got allocated for Bitaxe, nice, it also has its own product string so that you could tell it like if ESP-Miner ever adopted this VID and PID this product string is how we would tell them apart, among other things, perhaps. So this is the way that USB discovery works in these board files. So this is one declaration here that matches boards that get plugged in that are implementing this Bitaxe Gamma. This is how it recognizes that Bitaxe Gamma board. I'm running the new firmware. There's a definition right above it that you see didn't change. This is the old one for bitaxe-raw. This is the way it showed up. It used generic VIDs and PIDs that weren't assigned. And it just said Bitaxe in its description. And so that descriptor is still there. The new one is still there to match the new firmware. And you can see the way these descriptors work are they sort of give the common USB transport layer a set of things to match on. And then it also passes in a create function that calls into this board file. And that's how the board knows which device is showing up. Anyway, this is all it took in Mujina to support the new firmware because the protocols are compatible. Basically, the device shows up looking a little bit different over USB. There's stuff named bitaxe-raw in Mujina modules that will that will eventually get renamed to the generic protocol name because it's it's an implementation of this protocol it really doesn't bitaxe-raw is the name of that firmware not the protocol anymore so that will eventually get renamed but this is all it took to support the new firmware was to add in one of these things to the board file now this This is for USB boards. This obviously does not work this way for native control boards that have nothing to do with USB and have things plugged into their pin headers. That's called an IO mouth, right? The Bitmain IO mouth. That's a totally different thing from this USB...
Skot: Well discovery here. I mean, the IO mouth is for the control board to talk to the hash boards. So that it doesn't really have anything to do with that. That's just what the serial ports are connected to. So this could still work if you had USB on your control board, which a lot of them do.
Ryan: Yes. To support. Yeah. You just don't plug in hash boards that way on a Amlogic control board. Anyway, I want to get too far into the weeds on that. And I lost my. Sorry, let me pull up. Where is the dev call?
Skot: Yeah, this is tangent, but we could totally make an Amlogic control board into a Bitcrane. Yeah. You could work exactly the same way as a Bitcrane. And it would be cheaper, probably, because they're just like e-waste at this point.
Schnitzel: Yeah. And then you would connect that Amlogic Bitcrane via USB to another Amlogic that runs regular Mujina?
Skot: Or to connect it over USB to your laptop or whatever. Yeah, okay.
Ryan: That's part of the fun here, right? If we get the abstractions right and get the mechanisms that tie things together right, then the same code works in all sorts of different settings. Yeah. Mujina can drive... A S19 J pro hash board over an IO mouth or over USB connected in various ways, right? Like an added board or a Bitcrane or an Amlogic thing running that looks like a Bitcrane sort of like, and it's all the same code. It's all the same drivers just like tied together in different ways. So that's, That vision implements some of how, you know, if you get in here and look at like how the transport layers work and how the boards connect, like it's all trying to implement that vision of something that's that kind of flexible. Okay, I wanna keep moving.
Ryan: Other little PRs of mine fixing things. This one I wanna point out though, had our first we had it had a first contributor susan contribute this small PR here if you remember from way back in the beginning we had a an issue about reducing dependencies and marked it as something that like going in there and removing a dependency would be a good perhaps first contributor item or something for someone to do that doesn't have hardware and they just want to contribute something like hey go out and reduce one of our dependencies or whatever so that's what Susan did here And this was small, and so I was able to merge this yesterday. This just replaces the CRC implementation for the bitmain driver. I was using a library, and it's only like 10 lines of code if you write it yourself.
Skot: Oh, cool.
Ryan: So this cuts us off from a library we didn't need. And it was sort of unmaintained. It probably would have been fine. This wasn't an absolutely necessary thing to do, but it's nice to drop a dependency. A good way to get started contributing is to make just a small change like this. So thank you, Susan, who I saw on a call last week or a couple of weeks ago, but I don't think she's here today. Is that right? Speak up if you're here. All right. Man, I'm totally lost doing this on this laptop screen.
Jayr: It's so small.
Ryan: All right, PRs that haven't merged. Another first time contributor, Jonathan. So you'll remember I talked last week I think or last time about a new CI mechanism that I was always checking our dependencies for new rust advisories for those crates so like if if there's a security bug or something in a crate rust has this advisory system So we have a thing that checks every night to see if any of our dependencies are mentioned. And it files an issue if they are. So this is an issue that got filed about a week ago. It's not, it wasn't a high severity thing or we would have jumped on it. And, But Jonathan said, hey, can I try to fix this? Can I try to update this one? And so that's what this PR is, just a small change to bump a version from a dependency version that had a problem to one in which it had been fixed. So conceptually, this is very simple. Because of our cooldown mechanism, though, remember, we don't want to pull in brand new packages in crates because that's a supply chain attack vector. So we have this seven day cooling off period. That's the reason I didn't jump in and fix this advisory on day one is because it was low risk to us. So I wanted to wait till the cooldown was over because there's no need for us to make a high risk move by taking a brand new package to fix a bug we don't really have. It's just sort of a theoretical bug. So it turns out there's actually, this revealed a bug in that cool down mechanism where if you try to update a specific package, it didn't, like this PR Jonathan submitted actually tried to merge an update that was, too new, newer than our cooldown. So that's why I haven't merged it yet. I'm discussing that with him in the comments. So this needed to wait for the cooldown and something was actually wrong with the cooldown tool or else he would have noticed before he submitted this PR. So that's this PR that's open. Thank you, Jonathan.
Jayr: So... May I ask something, Ryan?
Ryan: Absolutely.
Jayr: So can you maybe just explain again the cooldown? Because I think I understand you touched on two different topics. One was more related to the security advisor. And then the second part was related to updating or upgrading a library. So can you maybe just elaborate a little bit more, like how does it work or when does it apply?
Ryan: Sure. I'll step back and try to just paint the big picture. So cool down. Let's talk about the cool down. So crates.io is where we pull all our Rust libraries from. You know, we have a list of libraries in our Cargo.toml file. And... We also, there's a corresponding lock. A lot of languages work this way. There's a corresponding lock file that lists all the versions of those libraries that we download and use in Mujina. So when you type cargo build, if you don't have it on your system already, it will fetch those libraries from crates.io at those versions and build them. So languages that use this kind of package system sort of famously like npm in the JavaScript world, can be attacked by someone uploading a malicious package to that central crates repository. So maybe someone steals developer credentials for a popular library that everybody depends on and they update an infected version of this package. And then the next time anyone goes to like build it out in the world and download a new version, they download what looks like a sane patch version of this popular library. And all of a sudden they've actually downloaded a bug, a malicious code to their development laptop. So that's called a supply chain attack because it attacks one of your libraries, the supply chain for your libraries. So one of the ways to defend or to mitigate this risk is if a malicious update gets uploaded like that, normally people figure it out within a couple hours or within a day or something. People notice like, hey, my credentials were stolen and that news gets spread. Or someone actually gets infected by one of these viruses and then you know, notifies the crates.io maintainers and they pull that malicious package down or whatever. So it's best practice to not pull down libraries that are brand new and to just give it some time because most of those malicious things are found within a couple hours or a couple days. So that's the cool down is in theory, all you're doing is saying, I'm not going to take any libraries until they've they're at least seven days old, because then chances are the community, if there was a problem with them, the community would have found them already. So that's the cooldown conceptually. And there's some code I added a couple of weeks ago that when we update to newer versions of libraries, it tries to check and make sure that it doesn't pull in anything that's newer than seven days. That's the cooldown mechanism. Does that make sense? Any questions about that?
Jayr: No, I think that that part is clear. No, I'm just like wondering when does it apply? Like, because, or maybe like, it's not even when does it apply? But like, how did you connect? When you explain the PR, like the
Ryan: Security advisory to that that part is still like a bit unclear like how the cooldown thing and the security okay advisor are connected so the advisory thing is they're actually not connected in any like hard way so let's discuss them as if they're it's a totally separate thing and then we'll talk about there is some relationship but totally separately from the cooldown is there's an advisory mechanism sort of like cves but for rust crates so like if if I'm so now we're not talking about malicious actors uploading poisoned crates we're talking about like you have a library you depend on they find a bug or security vulnerability in a particular version of that, and then they patch it and upload a new version. Well, the advisory thing is their way of putting out a warning on those old versions saying, hey, there was this serious bug. It's worth your attention. So there's a tool you can run that checks your dependencies for any new advisories. I simply tie that into our build system and into CI so that every night our dependencies get scanned for any new advisories. And that system files a bug in our list. It doesn't take any action. It just files a bug so that we can take action. So that's the separate thing there. The connection is if you get an advisory on a package, probably the action you want to take is to upgrade to a new version of a library. But at that point, you're sort of subject to the cooldown or you have to make a decision. Is it important enough that I take this brand new version of a library because that bug was so serious at the risk of supply chain issues? Or it's not a serious bug and I do want the new version, but only after it's aged for seven days. So I actually want to wait the cooldown. So our tools don't actually force that decision. Like, cause that's sort of a decision you make on a case by case basis. Like, do you want to violate the cool down because you're trying to fix a urgent bug or do you just want to wait for the cool down, you know, and eventually clear this advisory. So does that make that make sense?
Jayr: Yeah, totally. Okay. Thank you.
Ryan: Yeah. Oh, wrong window. Okay, so that's what that contribution from Jonathan was.
Ryan: I want to keep this on the list because it's important. Again, I want to thank Jayr for this SV2 PR, which is great. I'm about halfway through reviewing it, and I've just been too crazy busy to get through that other half, but... Especially now that there's more visibility on this, because we're in this, now all of a sudden we're in the Stratum V2 working group. Like I really want to get this feature merged into Mujina. And so I will, this remains close to a top priority, just it gets interrupted by a lot of other things. So anyone else is welcome to also take a look. That's this PR number 65 here. Is there anything you want to say about that?
Jayr: Yeah, two comments on this one. The first one is, I think I mentioned you in that other discussion we started on the SV2 support. And then I mentioned that we expect this new BIP to be adopted as people upgrade their Bitcoin Core to V32. And then with V32 comes this BIP 2.2.5.3, or is it 2? No, I think it's 3.2.3. Yeah, 3.2.3, BIP 323. And it's basically increasing the number of bits in the version field. So basically, as of today, we're using 16 of those bits when we do version rolling. But with this, it goes up to 24. And then that question was because when we decided the type of channel, SV2 channel implementations, we went for the extended channels because we thought that this could be relevant since Mujina is focused on these, let's say, industrial devices where they could reach the theoretical ceiling. But now with this BIP 323, then the theoretical ceiling goes up to 72 petahash. And then we don't really need to do the extended channels for the reason that we decided to do it in the first place. So that's just one of the decision points that I wanted to touch on with you, because I can make the change if we think that would be good enough. And the second thing is like I had this retreat with the SV2 guys last week or at least two of them, plebhash and the baliero was there, so there there are two messages that I implemented there and that they they said that although they're in the spec but they are not really used so I might do like a few changes in the coming days to this PR
Ryan: Yeah sure yeah so I just wanted to give you this heads up as well okay thanks yeah I think we won't be colliding as far as your first the extended channel versus standard standard channel I'm gonna have to refresh my memory on the details yeah the concern I have and that you should think about too is that even if the standard channel has a lot more room in it, which will be good. One of the differences is that that extended channel was, it was easy to see how you would like divide that work up and distribute it to many hash boards. Whereas it was a little less clear how, with a standard channel, you could divide it up.
Jayr: Yeah, I think that makes sense.
Ryan: Because you don't have the extranonce to play with.
Jayr: Yeah, the local root would be fixed, yeah.
Ryan: Although... There's a lot of details to think through here, because if the version is bigger, you could divide it up. No chip we have right now, for example, is going to roll those new bits in hardware. It's not capable of doing that. But you could use those new bits to divide up the work among multiple boards. So we just need to think through that. Like standard channels, like if you ended up with a standard channel that only had 16 rolling bits, you know, that's the part like we have to think through that I don't think every miner has to think through because we potentially have a lot of boards to divide work up amongst, not just, you know, three per box or whatever. And our boards come and go. So like it's mainly that work division thing that I was concerned about and that I think we have to think through how, how that flows through given the different type of channels and the different things that it could be, the different ways the work could be divided up. Anyway, I think that's a solvable problem. It's just not trivial.
Jayr: Maybe just one last thing, Ryan, on this one. I remember asking you in one of the comments there, because I brought this dependency to the integration tests SV2, which is a great... Their team created with this, let's call like end to end, like the real device, the real pool communication. And then they have this like sniffer that you can, you know, assert on, like, if you are, like, building communication using their protocol, if the messages are, you know, like, flowing through and, you know, as you want them to go. But at the same time, one downside is that it had some transient dependencies. And then this whole discussion we just had on the dependencies, and it also made a big change to the cargo lock. So that part made me a little bit uncomfortable. I'm not sure if the value that we're getting from those integration tests versus the dependencies that are being brought. So I just wanted maybe you to give me some feedback on that. Because if we decide to go a different route, I can just remove that part and try something else maybe.
Ryan: Yeah. Well, that was definitely my first impression too. That was toward the end of the things I was going to comment on and review. But yeah, just to give you a heads up, like, yeah, that part seemed pretty heavy. So we should think about how. Yeah, I didn't have a final thought on it. It just struck me as, yeah, that's a lot. That's a lot of just pure test code in there. So, yeah, I don't know. Maybe that lives external. Maybe it's okay because it's just test dependencies not stuff that gets baked into the runtime yeah I don't know but it was it was it was heavy I don't I don't have a full right on it though yeah all right thanks yeah.
Ryan: Noting the time, is there anything anyone wanted to talk about that they want to get in before we start going too long?
Schnitzel: Yeah, I need to jump in like five minutes. I was wondering if you have any questions for my three PRs. You just mentioned that we might not use the code, which I'm totally fine if you just use the issues to fix it.
Ryan: Yes, I think that's, yeah, these are, I just carried them over from last week. Because I looked at them. I didn't think they were super urgent. They're probably mostly going to turn into issues that get fixed in slightly different ways. So I don't have any questions on them. But that's sort of what I thought of them.
Schnitzel: Awesome.
Ryan: There weren't any new ones, right? I don't remember seeing any. You want more? No, not yet, unless they're important.
Schnitzel: I can send you some for robotsminer if you want to fix some other runtime stuff. No, nothing of Mujina, but I also haven't been pointing a lot to it because so far there were a lot of other targets that were more juicier.
Ryan: Yes, yes. Well, that class of bugs that the three you did file came from, I suspect there's more lurking in that area of malformed pool inputs and stuff like that. I bet every miner's not defensive enough. Yeah.
Skot: Classic Bobby Tables stuff.
Ryan: Classic. Yeah. So I'm sure there's more to poke at there. But nothing that I'm losing sleep over yet.
Skot: So should those get made into issues? Is that what?
Ryan: Yeah. They showed up as PRs, but they probably point out a valid issue that probably we want to fix. It fits better in our code in a slightly different way. All right. Anybody else with stuff they want to bring up? Oh, Dylan has linked to the Bobby table.
Dylan: You just got to get some people caught up sometimes.
Ryan: That's true. Famous xkcd. All right. I don't think there's anything else that is urgent that I need to cover. I think we can let everybody go closer to the time here. I noticed a couple of new people on the call. If you have any interest in introducing yourself, I can stop the recording and let you do that. I'm going to shut off the recording.
Dev-call summaries and transcripts live in the Dev Calls discussion category. Transcript pages here are linked from their discussion threads.