Post-Quantum Interop Call #20

Transcript

Okay, let's get going. Um, so welcome PQ interrupt. This is call number 20. Uh, we've survived 2025. So, just a reminder, this is we're going to take a twoe hiatus for uh some holidays and then we'll be back. I believe it's uh January 7th uh or sorry January 6th Tuesday the first the seventh uh first Wednesday in in the new year. Um, so let's jump in with some reverse alphabetical order client updates.

Uh, Zam team, uh, how are things going? And maybe if you could people could bucket their updates if it makes sense into like, uh, anything related to the long living DevNet one versus DevNet 2 and future uh, research. Yeah, I will. Uh so the update has been uh that the anible PR for long running DevNet on you know multi- nodes cluster that was merged and uh para has been experimenting on that he has been facing some issues which we are trying to figure out and debug and uh for the local

devet I think katya got some success running it till 70k slots after which basically I think the performance deteriorated and uh which basically seems to stem from uh from the state size that get big that gets big because uh we don't do any justifications map pruning that we have in the state and for that uh we will raise a spec PR as well as uh then the clients can do uh uh do the implementation because uh that will basically enable clients to uh clean up uh the justifications map that is in the state whenever you know finalization is

advancing or justification is advancing. So that is something that we need to do apart from that other things that we have identified is that we also need to prune our state memories uh that's basically cache states that we have once basically finalization is advancing. So uh so some some of the so basically all these uh efforts have brought into focus some of the things that we need to do for making sure that the clients can uh run long. So that is something that we are focusing upon and apart from that for DevNet 2 uh so there was a PR that

uh that got merged by anel which basically does a stationation aggregation. Uh so this is the first step and the second step is to actually integrate the lean VM u which in which he was facing some issues but uh uh then we decided that maybe we do the lean uh VM integration PR in the production config mode uh because uh the test mode uh uh lean VM is I think throwing some error with regard to sizes because obviously they won't match. match. Uh so in in that regard I think uh uh we are making progress

>> sounds like thanks a lot gadgeter um re team. Yeah. Um so two main things on PQ. Net for first. Um so yeah so with the signature aggregation spec PR that got merged by anaw we are updating our code base uh reflecting that. Um we have also just implemented the signature aggregation with the lean multisc2 branch. Um and share did that. I think he he's also got some updates for us as well. So I'll pass on to to sh to to give more details.

>> Sweet sweet. uh on the long running DevNet side uh from what I heard from Katya she had some uh feedback for us on how we uh structure our logs uh so we plan to address that uh however I I believe from what Katya said uh re was successfully running even after 17k slots with no issues uh so I I think we should be good on uh the longrunning DevNet side on the lean VM side okay agrees with that on the lean VM side uh We unshell I believe got a PR merged for precursor to signature aggregation that we have now updated our codebase to uh and the on on the and I I want to

appreciate Emil for his work on the devet 2 branch uh integrating the that into the codebase was seamless. Uh so what I got going was uh taking generating some lean six signatures. I was only generating like five seven signatures. Uh so generating some lean six signatures, aggregating them, verifying them uh and all of that worked seamlessly. Uh so I think for DevNet 2, we should be able to go ahead and take uh take the Devet 2 branch and uh do a DevNet with that. Uh if everyone is on the same page uh on that one uh on just a tiny nitpick uh and I may I may

make a PR for this uh in re what we like to do for our GitHub depend dependencies that are linked to like a GitHub repo. uh we like to link it with a revision uh which is uh like a commit hash uh just because it makes it more stable for uh like like if there's any updates pushed to the br instead of like branch or just like main uh if there's any update pushed to main or branch that does not uh affect uh our codebase uh so I I'll make a PR to lean multisc to lock all the GitHub dependencies to the revision instead of branch uh that That is our update. Thank you.

>> Oh, awesome. Thank you. Uh clean. >> Yeah. Hey everyone. Um yeah, on our side, uh yeah, we've been working. Yeah, basically uh during last week, yeah, there was a question like whether we support the sync and yeah, we actually were testing whether clean um is stable for that because yeah, we had some u yeah, it was working for net0, but we was not checking if it's still uh stable. So yeah, we discovered some bugs and fixed them. Uh yeah, I updated link quick start triple with the most recent uh clean version which has the fix for that. Also, thanks for Katia. We introduced the PQ signature matrix and

updated the stationation matrix with labels. Um yeah also yes just getting started with uh lin mode seek just writing bindings and yeah so that it's easier to add into clean for the net 2. Um also did some yeah just analysis for the dev net one uh for the networking just make sure yeah just run some simulations for under shadow checking like um yeah performance for the station block propagation there yeah if time permits and people curious yeah I can uh talk a bit more about that later um yeah I think that's all from our side thanks >> thanks Camille um yeah Let's come back

to the analysis once we get through the remainder of the updates and spec talk. Um, lantern. >> Yep. Hi everyone. Um, so basically last week uh I discovered a bug. Um basically um if there was a a peer disconnection um like if lantern was connected to peers and if one of the peers disconnect basically it would repeatedly try to send gossip messages to that disconnected pure um so I've implemented fixes for it um and that issue is not happening in my local testing and this week um basically made improvements to the lip library to basically reduce the

CPU usage. So the zen team reported that the CPU usage was extremely high for lantern but I've uh implemented a fix for it and updated docker image. So the CPU usage should be minimal now. Um and as well as updated the docker image today to add um date in the logging um so it's easier to track logs um and uh for devet 2 uh I know that the pier got merged uh signage aggregation um and I'll be looking into implementing that in lantern next. Yep, that's my update.

Thanks, Mayor. Um, I don't Is anyone from Lighthouse on the call? Okay. uh Grand Dean or Ethics there's a lot of teams that have been signaling interest in they're at various states of uh building a lean client and to make sure we're picking time for everyone. Okay, great. Um Nepor, I dropped a note in the chat. I believe it was you that was working on uh adding issues to the PM repo and uh project board updates.

Happy to share my screen. I don't know if there's anything that you want to talk through there. U me I I think human mercy. Oh, maybe I forget who I was communicating with in GitHub. >> Sorry, there we go.

>> So, yeah, I've been raising those issues which were we've discovered in the long running DevNet on the PM repo. Uh, I've reached out to teams as well, both Mahir and K. Uh, yeah. Um nothing else to add there at the moment but I just had a generic question. So the issues that we identify in DevNet longunning DevNet one uh are we looking to address them as a part of the same DevNet or do we add these uh to test in DevNet 2? >> Uh I think we should test them in DevNet 2 just cuz we uh froze the spec for DevNet one. Uh but like we can include

them if other teams want to. Uh I'm okay with either of these but I just need everyone uh to be on the same page here. So Kajender Cam and Mihir if you have anything to add. Uh sorry can you describe the issue again? >> Uh the issues that we identify right now in the long run DevNet do we uh fix them and test them in DevNet 2 or do you want to address them even before we commence

testing of DevNet 2? >> And if the issues regarding peer connections and stability then yes we should address them right away. I mean, >> okay. So, we can do this on a case-to case basis directly discuss these on the uh GitHub issues that are being reported. >> Yep. Right. And also I think uh we should also try to put the spec PR for cleaning up the state so that state also stays small. So uh I mean if we can put up the spec soon enough then before DevNet 2 we should

also try to test it out as well across all the clients because uh before moving to aggregation we should basically get to a point where all clients can run stable in a stable mode for a long long amount of time. Um yeah just as uh was written in some chat yeah we had some issues with out of memory yeah fixing that should be fixed like I don't know in a week or two weeks basically yeah we we're not using any persistent stores so far so yeah we just

introducing this now it shouldn't take too long but yeah want to make sure it's kind of stable Um yeah, this should fix out of memory issue that we have. Great. Um moving forward to spec updates. Uh Emil, there was I think some work that was being done uh recently on lean VM. Maybe start there.

Yes, sorry. What is the question? Sorry. >> Uh just curious if you wanted to share any color or add any updates uh regarding lean VM work. >> Uh yeah, I'm currently trying to make the this LINVM simple branch as simple as possible uh to be able to have real end to end recussion. And uh about this DevNet 2 branch, I have a question about this um test config in the in the the spec because currently this test config if I understand correctly is useful for the Python spec because of the of the slow

GitHub um CI, but it's not implemented in the lin repository in order to keep only with safe like secure instances but because of the link multisig uses the linig repository like import it and use the link repository for tests uh it's not like uh my question is the following is it really important to have this test config in lin multisig given the fact that it's not in linig so if it's really necessary I can totally do it uh using like some kind of fork of lingig extra but uh I'm not sure if it's really

necessary because it's not uh the test config is is not in linig if that makes sense. >> Yeah, that makes sense. Um yeah indeed like we have in the spec this test config because uh first to run the pi test so just the test uh to verify that XMss is correctly implemented and other pi tests we need the test config just to generate the key and stuff because if I don't do that then I need to test I I cannot really test the key gen function Because if I use the production configuration inside the keychain

function, I I simply cannot test because it will take like two or three hours especially in Python. So I need that to test and also both to test locally and also to test in the CI to generate test vectors. For example, when we set up some validators, uh, we create some keys at the beginning. And so, right now, what we do is that we just read the keys from a JSON file. But if we choose to do that via the production configuration, first you will have to read like huge JSON files, so like hundreds of megabytes. So, this will take like couple of seconds just for the

dialization. And if you want to advance a bit in time to test for example like long slot stuff and what's not then you need to advance the mer tree a bit and that is also not possible with a production configuration in a reasonable amount of time. That's why we have this um on the linig repo. We already have a a small test config let us say um I tested that in the lspec but this is not small enough meaning that even with that the world test framework could last like 10 minutes or something like that and if we do like 10 minutes for each CI this is

completely a nogo. Um so I of course I am open to change the parameters there of the test config if we want to adjust maybe find like a balance or anything of course this is reasonable but I think that we should keep that here then not necessarily we need to integrate that into linig I don't know maybe for homogeneity let us say or maybe not I don't really But I think that in the spec this is unavoidable unavoidable sorry otherwise like we will simply cannot be able to test. So

this would make like the testing not practical especially locally you know because when you you are looking for a bug and when for example you want to run like a given test vectors like hundred of time within one hour then this is impossible to to run with a pro config. Does that make sense? >> Yeah that that makes perfectly sense. So the question is even even though we need this test config in the in the spec, do we also need it in lin multiig given the fact that it's currently not in linig? >> Yeah. Yeah. Yeah. Um maybe we need to check in linig if we can add such a small config because in the past we

haded the small config already for testing purpose but it we found out that for python this is not small enough. So maybe we should add in uh linig the smallest the smallest possible config let us say and so that you will be able to import that from lin multisig. I don't know if Benedict is there and if it makes sense >> makes sense to me.

Yeah, the ideal situation would be to to find the smallest config that we can have. I mean from my perspective the only like whatever solution we find is fine. The only thing we need to make sure is that in the end everyone knows and it's clearly documented that this stuff is just for testing and not the production thing. >> Yep. Yeah, definitely. Yeah. Um, yeah, ideally in Russ when we do that, we just put like a cfg test, but I don't think that this is a good idea for this specific case because then this will not compile in without the cfg

and so um you will not be able to use that in your day-to-day basis on on. So probably what we should do is just to have like the smallest uh test config and just have like a documentation clearly saying that warning warning this is not secure and please don't use that for production. >> Yep. >> Makes sense to me. just to just to add to it, I mean even though we are trying to solve the problem for CI but uh I think eventually we will need production based uh test vectors because uh uh all the clients should also you know have the test or the spec test

based upon uh production config. So at some point we might act we might just need to pregen something and uh >> yeah based on that >> I have just linked a PR in the chat who is currently working on this um he already has set up like another repo because if we put like the keys of the production config in the linspec repo then even the repo will be big and so you will have problem to clone on your computer and So it just delegated this into like a separate repo where you have two folders that is under the lin configuration. So

you have two folders. You have one folder for the test config and one folder for the production config. And so you are able to have like JSON's file for both of them and with a simple flag in the test CLI stuff that you you want to run you can just specify prod or test config. So in the CI basically it will be test config but if you want locally or via any platform you can just run that on pro config. So it will be much slower because you will have to go to the pro scheme in the ski in the the other repo dialize the very very big JSON and run all of your test but this

is possible if you want here. >> Yeah I think this approach makes sense. Yeah, the PR will be merged very very soon like we we found out the latest detail and then we will merge. I'm I'm close to m even if like with an activation lifetime of two or four so only two or four onetime signatures even if in this seemingly simple situation the secure instance of XMSS is still too slow on Python correct

I think you're muted. >> Yeah. Sorry. Sorry. You mean when you advance the mer tree? >> Uh I mean um like couldn't we use the real XMSS parameters but uh simp but we would only use a very small activation lifetime. So the XMSS in the tests would be valid for only four or eight >> Yeah. >> epox. >> Yeah. Yeah. I get there are two problems with that. The first is that even if we have that I I need to test the the Python XMss implementation. So I I need to test the counterpart of the of

the XMSS Rust and so I need to test the key gen function. So somehow I need to have like a a test configuration. That is one point. So in any case even with that I will need somewhere like a test configuration just to test my implementation of XMSS. But you are right like for the test vectors for the rest of the test I could just use like the production configuration set a small lifetime and just do that so that the key generation will be reasonably small and then I can just run that but even without with that I think that even with what you are saying like the the JSON to

desize are really big and if We want to test a special config because the goal of test vector is to test outsource of config even edge config. If we want to move quite far in time then we will need to to move like the mer tree a bit a bit a bit and with the pro config this is very huge. You see what I mean? >> Okay. Makes sense. Okay. Okay. But I I agree that we should find the best uh solution to uh consider both of the config knowing that the test config

is only for test and the pro config is the one we should use. I I found that this problem at day one when I tried to implement that I I just found that the proconfig will not be practical but uh yeah we have to find the right balance I think and I think that I discussed that also with Pelipe because I had this problem in mind and so I was curious about the choice that were made for the other spec. We found out that uh for the content spec right now they already have like a minimal and mainet configurations probably not for the signature sake but for other stuff. Uh

so we already have experience with that and after discussion we found out that the proposition of O was pretty good with like um environment variables that you can just set to pro or test to switch between the pro and test config so that you have this possibility even if you want to just run the pro config. Uh yeah. >> Uh I think how we did it is uh we made all the internal functions work with uh like any ex generalized XMS signature type from lean sig. Uh and then uh we used feature flags to switch which signature scheme we using on a higher level. Uh I'm going to link a PR where

we did that. Uh so anyone can like at least for lean multisec that should work just straight out of the box. >> Yeah. Yeah. for rest. That is a pretty straightforward. You can even have like a Yeah, exactly what what you have like a a pro cfg and a test cfg and you can just switch between the two. But in Python you have to to tweak a bit this because this is not as simple as this. Yeah. But yeah. Yeah. Yeah. Your your solution is is good. Yeah. you have a CFG test or CFG pro and then you just switch.

So actually we don't even need to modify linig like like I could hardcode hardcode the variables like the number of the target etc etc in l multisig it's quite ugly but it would work I guess yeah yeah we can discuss as I think if we want to modify linig or or not uh yeah and even like to be honest like the parameters that I chose for the testing in config. I am not sure that they are the best ones. Uh I just show them for the CI to be okay and I tested different configurations.

Uh this one seemed to be okay but maybe we could find better parameters like a better compromise or anything. >> Okay. Okay. Thanks. I just got done typing that but I'll voice it over. Uh yeah, last week there was some discussion around design options and explorations with regard to the signature encoding and speed and security trade-offs for lean beh But I think that we merged a PR

yesterday on lin to make something public for you to be able to access them from lin multisig so that you will be able to work directly with the linig repo. Correct. >> Yeah, it it worked very nice. Uh now like multisig imports the the official main branch of linse. So it works fine and will I I guess your question was about the encoding and I think it's a an area of research in which Benedict is uh active and he has some ideas but I think it's still like in the research phase.

So there's some project where we are working on the encoding stuff and uh I hope that soon we will have a a draft out um and then we can start implementing it and tests and and stuff but this still takes some more time. Um and about the tweaks there was another thing I think there we had some progress emotionally. >> Yeah. Yeah. Because the thing which is really nice is that the tweaks are the same for all the signers. And so you can let the verifier write down the tweaks in the public part

of the memory of the virtual machine. And this avoids the virtual machine to recomputee the tweaks for each hash for each XMss. and it makes it quite efficient. In the current DevNet to branch, the program for verifying XSS is quite slow, a little bit above 100 XMss per second on my machine, which is like 10x slower than the target for various reasons. Uh, one of which being that the program is not optimized at all. like there is not a loop unrolling and also

the pre-ompiles are not uh custom customized for the the XMSS and lot of uninteresting technical reasons but uh in theory I just want to say that in theory um we could like with non-trivial but some small modifications get to maybe four or 500 100 XMss per second on this branch. But hopefully we will get we'll be able to to reach the thousand XMss per second on the Linville simple branch and uh to be to have at the same time recursion and fast XMSS. I hope.

>> Excellent. Thank you. Um, I saw you post an update about py significantly faster than my py. >> Yeah, we updated this. This is a type checker made in Russ. So we wanted to do that with Felipes in the beginning. So I just took a bit of time this beginning of the week to just switch that so that now both locally and on the CI when you just check the types. Um this is much faster and u so we also modified a couple of things associated. So now uh things are a little bit cleaner. So this is good. We

removed a bunch of uses functions, a bunch of casting stuff, um, and a bunch of other stuff. So now the code is a bit simpler, but not that much, but a bit simpler. Um and I as I just mentioned just previously we will also soon merge the PR of O with which is pretty nice uh because this had the ability there to just switch between the pro and test config very easily just via flag in the CLI. This is currently under review but very last few comments and we will merge that uh very soon. Uh that is basically

it on spec updates. I spent a bit of time uh this weekend and uh beginning of the week to simplify a bit the XMSS uh the XMSS specification when I have done that I have done a bunch of uh useless stuff let us say so I simplified simplified again and I think I can again simplify a bit more uh so when I have time trying to simplify And also we had a PR we had some PRs in preparation for the integration of the aggregation

uh signature aggregation. So we merge the PR beginning of the week about this and I think other one are in preparation by the Zim folks if I am correct. Uh so yeah that is basically hit on spec update. So as always don't hesitate to open issues, PR or concerns, question in the chat or directly on GitHub. Uh I am always very interested by the feedback stuff that are not clear or anything. So yeah, just read hopefully by the by Friday we

will have a PR to actually integrate lean VM and use the aggregated signage signatures. uh even though it will be based on the production config and might not actually run on CI for lean spec but we will have that and uh we can basically discuss it and finalize it. >> I will try to do the test config as soon as possible. >> This is based on bindings right? Yeah, I think this is based on binding has a conflict for this particular time slot. So, he's not here but yeah, >> he's sort of

>> No problem. Uh yeah, as I just me as I mentioned like previous uh meetings before uh yeah of course if this can unlock like test nets or stuff very soon devet sorry I am really like supportive of adding the binding stuff and and all this of course there is no problem but really in the long term we should take care of the fact that somehow like the lin VM will have to be speced into Python This will help us in a lot of fashion like maybe being able to do fuzzing between the Rust and the Python implementation, cross testing, having LINV VM as an educational tool in Python. Um a

simplified version of LINVM, something that the community can read and all of this. So we will have to spec that as I just mentioned a bunch of talk before this is not the right moment because the spec the the lining VM evolves a lot and so if I try to code that in Python right now I will probably have to redo everything in two months. So this is not the right moment. So bindings are probably the good solution but we should have in mind that this is not the final solution. Yeah, I totally agree. But that's exactly the purpose of the branch lin simple. Honestly, it it's it begins to to be like really simple

like the VM is basically you have one we commitment uh you check three or four errors, one log up, one log up star, one batch we openings and that's it. So I honestly uh I think we are close to a state where the spec could be written in Python in and it wouldn't be that long. So I'm quite optimistic on this topic. Yeah. >> Very good.

>> Sorry. The hard part will be to make it at the same time fast and simple. But uh uh we'll try. [snorts] >> Yeah, amazing work. recommend. So, uh I think what we are the timelines that we are looking for DevNet 2 is maybe in the first week of the new year or when when are other clients sort of comfortable because I think by end of this week we will have at least a spec which might not get merged to the lean spec we'll have a PR that basically tells all the clients what to do and we can implement that in the coming week or so If the client

teams are still not going on full holiday mode and maybe on the first week or the second week, we can aim for a DevNet to interrupt even while we'll keep doing our longunning DevNet uh efforts in parallel. >> Yeah, we should be good for that. Yeah, I I will be there also like most of the old days. So no problem to review, merge or anything about the spec. Yeah.

>> Amazing. Uh any remaining spec conversations? >> Nope. On my on my side that is that is okay. Yeah. Uh was there anything on the metrics or monitoring side? >> Uh yes, hello everyone. So uh this week I've been working on the um setting up metrics and uh all the stuff for monitoring like Prometheus and exporter and I'm pretty happy with the results actually because um I could see the devet one on the summary dashboard and it helped to quickly detect where we

lost finality. Um so thank you for all the teams for collaboration. So we are in touch to discuss logs and metrics. And just quickly reminder about the pure connection metrics. Uh there would be really helpful because we have um a lot of these events connect disconnect events. Uh just for investigation the issues um pretty helpful. I think like the bandwidth is not the hot topic but um connection disconnection is important.

uh so we can easily investigate this if if you have resources for this that would be really helpful. Uh so um the metrics setup will be uh finished soon I guess. So so uh I'm currently working on storing the metrics on the server side and setting up everything. So I guess next week uh everything will be ready. Thanks. >> Great. Thank you, Kadia.

Um, on a related note, Camille, did you want to speak about the attication analysis report? Um, yeah, thanks. So, yeah, I'll try to be good. Um yeah. So yeah, we just were curious like what are the limits of the current DevNet and in future we plan to move from like uh putting u yeah all stations well just using aggregations to to kind of have smaller blocks and everything like that. Uh so just to set up some kind of baselines so what we can expect in future and what are the limits. So we did some simulations using shadow. Um yeah, we took uh we a little bit updated

clean so that it works under shadow so that it actually doesn't use XMSS signatures because they are so a bit timeconuming and they are not really affect the networking part took the real kind of bandwidth and latencies from riless database. So yet the uh latency and bandwidth histograms here could be also observed here. Um we just checked like four types of network like 64 nodes, 128 nodes, 256 and also 256 with uh to bandwidth. Um but yeah the main thing that yeah we observed is like when we have small networks like 64 nodes yeah everything is great. So at stations

yeah the the way it we measured that is just we we took some um some slots slot 10 and took some random at the station and check how fast it actually propagates for the network. So here we see like when we have 64 nodes everything is fine like it propagates uh yeah um approximately within like 100 milliseconds uh and when we increase the network to 128 nodes yeah it's around 200 milliseconds um but when it goes to 256 nodes um yeah it actually getting really slow because uh I I suspect that the reason is that Yeah, the network grows like we have

more attestation so the network is congested and um yeah the propagation of stationation is getting slower. So um even when we increase the bandwidth twice it's still quite uh yeah uh quite slow. So basically single attestation propagates it could take almost like the entire slow time to propagate a single stationation. And we actually observed that the finality is getting kind of stalled after some time in such networks. So yeah and um yeah we we did the same analysis for the block propagation. So here again like everything is fine when we have small networks because just when for 64

nodes like propagation of block happens within approximately 100 milliseconds for the 90% of the nodes and then uh for the larger network it's like around 160 milliseconds and for larger networks like 256 nodes um yeah the block propagation is really slow like more than the time for the slot. So yeah basically we can say that current limit for the dev net one um yeah it should be like approximately 128 nodes and when it's becomes 256 uh yeah basically the network is u getting really really slow. So yeah uh that's just as I said like baseline in

future we have dev when devet 2 I I'm pretty sure like everything will get much faster but yeah that's the situation right now. So yeah, when we have DevNet 2, we will kind of create the same report and yeah, compare the numbers. Thanks. I guess can help. And that that's using the current leanig spec. Yeah, it's basically we took the DevNet one version of clean which is like compatible with all the clients and compliant with the spec and um yeah ran the simulations using that version of clean.

>> And so remind me how many nodes are in the long running Dubnet? I suspect much less. >> Okay. >> What was your question? How many nodes are in it? >> They just >> Yeah, just four. Okay. Great. Yeah, it's going to be really interesting to watch those.

I'm assuming will you continue to do those uh like a similar analysis with each of these subsequent dev nets? >> Yeah. Yeah, certainly. Like uh when we introduce aggregations, we can do this when we maybe introduce something like I don't know uh regoded UDP based propagation for the aggregations which we discussed in Cambridge. Yeah. So we can measure all the benefits that we gained with all this on different scale of the network. Great. Uh any remaining open discussion items that anyone wants to touch on?

So, it sounds like people will we're taking time off, but folks will be around reviewing PRs. The goal is to do what needs to be done to ship uh DevNet 2 hopefully the first week in January. and Kasha. >> Uh yeah, well just wanted to ask um do we have a holiday schedule like what are what calls are we missing and what not? >> Yeah, I dropped a note in the the telegram. It's just the next two calls uh we'll be off and then we come back and pick back up uh January 7th, that Wednesday.

Okay. Well, have a great holiday break, rest of your year, beginning of 2026, and we'll see you call number 21 uh in January. >> Have a great one, guys. Uh have a merry Christmas and a happy new year. Happy holiday, >> Christmas. >> Thanks. Thank you. Bye. >> See you around. Bye.