 Hey guys, can everybody hear me? Okay. Hey Perfect It looks like oh One more thing I gotta fix Okay, someone from the conference call try talking again Okay, try one more time One more time. Ah, we got it. It's working. Thank you guys All right, I'll just make sure Hope so this is gonna be a short meeting So, yeah, we have Jan in the back. We have the talent. Sorry. I'm so sorry All right, and we have Casey So, yeah, we're at Cornell right now doing a week-long boot camp and Yeah, pretty much what's going on Let's see Oh, it's fine now. Okay, volume up a little bit more Trying to deal with the troll box complaining about volume Please help us. Um, why why should I help you? The troll box is fine Okay, so yeah first item Metropolis so we were I've talked to like the testing team. I've talked to some of the Debs and people are saying that EIP 86 slash 208 should be Should be changed to two hard forks So I just wanted to get everyone's opinion on that Just to see like what everyone thought so I Think let's just start with this room. So what do y'all think? It seems for me personally seems like it seems like if you're a reasonable idea, cool Casey Yeah, I'm in favor of deferring it and getting something more like 101 So Casey just said EIP 101 so that's like 86 but like Oh that EIP surrounding the currency and crypto abstraction Okay, it was not the currency abstraction part just the crypto abstraction. Oh, right. All right. Yes. Yes. Yes Okay, right, which is since then turned into 86 which is since then turned into a B208 and So which parts of 86 would we take in metropolis And which parts would we defer and the one part that I could see us taking in is that is the create to opcode but like even that I I mean, I do have the And probably wants to get other people's opinions on this because like create to does introduce this like Contract the contract code mean ability and look just in case like some clients are designed in such a way that Handles that like to handle that terribly in a way that might lead to a consensus failure. That's Like basically I just want to make sure there's enough test cases for it Especially since like the the one thing that made me a bit more concerned is that in the process of implementing EIP 98 and Python, which is the media intermediate state with removal idea ran through I ran across one bug very good and half before which arise from Basically from the fact that in a cat like if you don't Commit if you don't commit the state from high ethereum's cash every time a transaction ends then an account could get Suicided and then revived and like Pytheon didn't handle that. Well, so Basically, I mean like I do think EIP 98 is very important because this is a significant performance improvement But I do want to make sure that there's like enough testing on that particular side of things so like one particular one way to do this testing would be to turn off committing the state during a After every transaction for existing clients and just make sure you can think the entire blockchain so but So the only thing that could make it a bit trouble is from from 86 is create to is is create to Use so much useful on its own on its own not too useful. I mean like I do I Could be a better way to create contracts in Some cases because like No, so what one so one particular way in which I create to a superior to create for example is that if you Have a contract on the ethereum chain and you accidentally send ETC to that address Then I know that doesn't work because ETC is not going to support create tube Like if it did then it would be easier to like do the credit It would basically be easier to recreate the exact same contract in that on another chain if you wanted to Well, that's a fairly small benefit. I think only Including create to might be harmful because that allows an easy way to cause address collisions and the client's behavior when address collision happens is One of the under tested very much and different clients behaved very differently Until like three days ago, and I haven't Got enough confidence I'd be fine with like basically deferring all of the ep 86 Yeah, I think that it's better. It seems cleaner to not Subdivide 86 through different hard forks because that just seems complicated that almost Organizational at least for me. No so if we were to not do 86 to 2008 what we would be doing is The rest of the EIPs which include all the cryptographic primitives for the case snarks The 90s wait 96 and 98 or so or 96 and 98 are they like pretty much done like or is there any complications? So 90 98 shouldn't be too hard except for like as I mentioned the testing just Testing is just in case the 96 all we need So I wrote based for that we need the hunk of code that you would stick into the black hash contract And I wrote a version but then Nick when I came in one and said that he could make a better version And I have been pretty much waiting for that ever since so Yeah, I mean if that's done then we could use it But if that's not done then like I did their option is to just go ahead and use the one I gave okay So that's that's Nick. What's the status on that? We I discussed that as in previous all core devs and somebody else was keen on taking it over and it Slips my mind momentarily who that was I'm just gonna look up the relevant EIP if anyone can remember what number that is You said 96, right? Mm-hmm. Yeah, that's block hash refactoring. So yeah on the main. Yeah Okay, so this is something that really should be doable within like an hour or two So I'd recommend we just like get together and get it done today Okay, that's perfectly fine. So that sounds like And what I'm looking for when I'm going through these EPS is there is there anything else similar to 86 that has? very outstanding questions Because basically by hopefully the end of this meeting I want to say these are at an EIP level formalized and accomplished, right? Okay, removal of intermediate state routes So I remember there was an EIP where we wanted to think Nick wanted to replace the state route with something else So I think the idea Yes I just updated the pull request early as a day to propose What the talic and the conclusion result I came to which was that we should only store the status code in that field So basically like you would in that in that field you would store a one if the transaction if the Outermost call in that transaction return success and zero for return failure Yes Also to go back to the block hash thing pull request 643 is part of attempt at Refactoring the block hash stuff. I've just linked it in the chat 643 Yeah, okay 96 Okay, so it's just a few it's just a few changes to the original EIP or is this a totally new EIP? I think I got lost It's a new pull request on an existing EIP Got it. I'm trying to pull it up. Oh, I didn't go to the latest one And I don't know I actually like the 10 lines. So what did he think that Nick? He did a while back even more than either of these Do you remember what I yeah what I'm talking about like there was one that just like did a little did this like loop Yeah, I do remember yet. I mean if you want to Because it looks simpler than like either of these certain things because it just like Properly doesn't move instead of like having lots of different like if statements Yeah, I agree. Um, you mentioned earlier just getting together and doing it. Do you want to pay a code afterwards? Sure It's all in early enough. We'll have some time Okay interesting All right. Yeah, so we y'all can get together after that and Paul's Solution here does It seems complicated, but is it more efficient potentially or not to the point where it matters. Yeah, great Okay, so we'll have Nick and Vitalik and people stick around after to help with that anybody else who wants to help So where was the list of the IPs Here we are. Okay The next one would be I think we've gone through all the other ones Is there any others that anyone sees that may have some outstanding things? I think 214 and 211 are finalized Everything else looks finalized can anyone pull up the list and just everyone can take a minute Does anyone have no of any other? Outstanding things with these most of them are implemented already in clients go through all them. Okay So 86 we're deferring 96 we can do 98 it's just like removing a commenting out of line and then making sure you pass tests 100 is I think it's done 140 is fine 196 197 198. I think we have tests for What is the status of the C plus plus tests for like all for all three pre-compiles? Which compiles? The 196 one set 197 198. This was the elliptic curve and that begin stuff So, you know after after CPPSM passed to test from Vitalik There's been no other progress. No additions Remember the one thing that we got stuck a bit on is that for modular Exponentiation like some people wanted to do you is like karate above for the sermon and gas costs. I Remember one thing but that one thing was sort of the long time ago How was that solve long time ago? I'm looking through right now and I probably say so long time ago that I don't remember what it Yeah, I think it was it was just the one word Dan this was Daniel Naie. Yeah, it was a June 2nd comment and then You said that carrot suba method and then I Don't know what we just I think Robert from parody might have done some estimation after that to compare is what it's looking like Donnie's told me that he began generating some tests and But he actually never actually showed me the test themselves, but as far as I know he did write a test generator and a test suit Maybe Function where I wrote a yeah, I Have a couple of proposals and then I have like this simple or piecewise quadratic function and something else and then I'll paste the comment in the chat Yeah, sure Yeah And this follows what we've been just talking about All right The one thing that concerns me is that like between all of the kind of bits like the bit-based pricing and this I feel like the gas schedule for 198 is getting a bit complicated Mm-hmm, like it's literally more complicated than the actual exponentiation No, I kind of know this seems slightly Something to note is Daniel did thumbs up your comment. Yeah No, just like the facts that like the gas schedule is getting this big just makes me a bit uneasy There are other comments like Peter Christian or anybody about gas schedule Nope Hmm. Okay. No, I feel like this is the other thing we might want to talk through today and finalize For you for 198 for 198. Yeah, so then we're fine with 196-197. Can we go back to the 211 return data size return data copy and 214 static call and I think we're all fine there Those were those were finalized. Yeah, okay Okay, I think we're fine. Okay Anybody else have anything from the accepted EIP list again, we highlighted 86 as being deferred to a second quote second metropolis fork 96 and 98 being basically finished today as well as 198 getting through concerns about How we're gonna be doing it Okay, let's see what the next thing is Do we have the gas course? specified for the elliptic curve addition Artification Right. Yes. So this is the other thing that we were supposed to talk about that there is a bunch of benchmarking that happened And this was supposed to feed into like gas costs for all these pre-compiles. So Martin did some gas estimation I believe it was based on get and I believe Arkady also did some based on parody I'm not sure it was for that particular that particular opcode but Martin said I'll try to consolidate the get benchmarks for op codes later on Not much need to report since last time. Okay, so he's just run more tests and then the parody teams on a retreat And they don't have any updates. They said so What we can ask them later for the gas cost estimations, but that's something that is Less vital to find out today or does that affect some of the things? It's less like it's just a number like it's probably safe to change it even two weeks before Okay Sounds good I Faced it in a link with Martin's numbers that he generated about I think two weeks ago So I'm not sure how relevant they are if you get I'll just share it Thank you I think if we get benchmarks for and I think this has been discussed before that if we get benchmarks for get and parody Those are the two primary ones we can compare Compare I guess to try to get as close as possible. And I mean Would this be something where we could change this? on hard fork to if we find out that it is been miscalculated or Misestimated Totally, okay, great. That's less of a deal Okay, we've gone through this EIP list Any other comments about this particularly? No Great. So section B in the agenda is updates to testing I think you know, he's the only one in here Okay, but yeah Somehow the focus is okay. So the interesting the thing is now very Implemented the state general state test in Goetrem and he found many many things that can be improved in the test format and the testing infrastructure. So The the efforts and the focus is somehow shifted to the infrastructure in these Weeks in this one or two weeks Just like on the bit on that. So Felix was working for the last week or so together with the C++ team to To port all the tests suite over to Goetrem so that we can actually run it as part of our CI infrastructure Which entails rewriting But mostly all of our consensus tests infrastructure and It's mostly done. I think but they are kind of ironing out the quirks and the Time to figure out the weird corner cases that are really hard to port over to other projects Cypher in No, no problem. So Now it's great that the Goetrem client can run the general state test format And with respect to adding new test cases for Metropolis when I see the Google spreadsheet of test cases It's 70% or 80% of the dines already green saying implemented Okay, that's very promising. So and that's is that just for general state test or across all of the metropolis test Across all of the metropolis tests, but yes We have more progress in the general state of tests that involves only one transaction We are not so that the progress on the more complicated case is involving Much more transactions. This is not as good Okay, great Any other updates with regards to testing Oichi? No, not coming Okay, thanks a lot Welcome Jan, okay The next is the updates from the client teams parody's done Get it. Look, I think you're according to the PR. You're all done. Did you have any comments or questions Peter? Well, so basically we have a follow-up PR which which we began just to polish up and even after that We decided to split up the different the IPs in separate requests So we're currently working on separating them and just making sure that each of them looks okay on their own As far as I I personally would start merging in already the finalized the IPs But we agreed with Felix that we're kind of waiting for tests to to make sure that it kind of looks like it passes all the tests so it's We're in the phase of if we consider that the tests are looking good than the our code passes the test of your starting to merge in So that's that's our big Great, do you mind in the comments of the agenda posting? I if the PRs aren't organized don't worry about it But if they are some of the follow-ups you were talking about if you can post that that would help me keep up with it Sure Thank you All right See if you be a theory and any updates worth mentioning There are some minor bugs being discovered during this You're each affected several of them these weeks You cut out on the last part Andre, could you say that again? I'm saying that apart from several minor fixes we did to these two weeks. There's no Many updates on the trouble is we're mostly done Okay, perfect, and I see that in your PR you both Pavel actually added the Google Docs link to each test that you are implementing. So that's nice Yeah, probably Dimitri was who who added that oh great cool So the next thing is Yellow paper yoichi, I think you said there was just like one outstanding issue last time No, that that was just the gas cost and then after that the EAP 86 changed a little bit Reflected the change so it's up to date Okay, great Pi f app that would be the talak or jam or both I think Any updates worth mentioning or I mean nothing too worth mentioning except just that we did release like pie Ethereum 2.0 a while back. So it's more modernized and A clean double bunch of tests as far as implementing metropolis go So it basically just been waiting until C++ test to have stabilized more So if they have stabilized enough Actually, the thing that you want to wait for it also is this finalizing EIP 96 and EIP 90 the 98 gas visual and once we have that then We can like run through the test and make sure we're still passing them back when I was checking I remember we were passing most of them except for a few And the few that we were pat were not passing was because C++ had some bugs in it um Although I think you had been working on them fairly recently So Now I'm seeing many errors on hive even before metropolis. So I Um, I want to clean this stuff Because otherwise, uh, yeah Problems will be hidden among many other problems. So yeah, I want some cleaner state Hmm Would someone like piper from the pieth team could work with you each year or something? Ah, yes. Yes, I learned about this. Uh, he's Debugging oriented client. So yes, it's interesting Thanks Okay, great. Is that pretty much the end of the pieth app updates? Yeah, sweet Uh, no other clients are in the room. I don't think Um, so that ends the updates from the client teams. Um The other so another agenda topic is determining the gas price for new op codes and pre-compiles Martin left a note saying I'll try to consolidate the geth benchmarks for op codes later on Not much to report since last time and then uh, Archety from parody said no updates So we'll get that information from parody in the next meeting and hopefully compare metrics Um, are there Any other comments on the gas price for the new op codes? Great So the last part review time estimate for testing and release We've been kind of going with an august or september Like very rough estimate Since we are delaying 86 Um, I think that's going to help either speed things up or keep us on track Um, does he would have any opinions on the timing of when things should happen? I guess now that we've delayed 86 What I still don't know is uh now how How many of the metropolis metropolis tests? Can go with them and the parity run With success and how much failure Uh, there I that I'm missing Okay, so that's something where we'll be able to have a more concrete estimate once they are passing the test. Would that be high? Yes, so some outstanding number of failures and The speed of the decrease in the number of failures Um, this would be kind of indicate This would be a good some indication Of the Our readiness Okay, sounds good Um, so ideally let's I'd say august or september But obviously that's going to be pending all of the testing changes. So we'll just keep that in mind for now Um, any other comments on that? Okay, cool. I want to post a link I did. Oh go ahead Uh, quick question So, uh, I'm guessing the test if you decide to postpone the account's reaction as would be updated accordingly And also I'm wondering do we want uh Mix proposal mix eip about the adding the The success code or failure code to an uh transaction receipt do Will we do that for metropolis for the first forecast metropolis? And if yes, when can we expect tests for it? Which eip is that or is it more of something that would be added to one? Uh, so it's nix eip. I'm Oh, so the modifications are 98. Um, I'd say you should just bring that individual of us Part one or part two part one Okay If that's the case we need someone to jump on that and get that, um, eip updated to Talk about adding that. Um, and then we can plan to get tests for it. I don't know how extensive that is Well, my point being that uh If we modify the receipts then basically it means we're modifying the block caches Which means all of the tests are invalid currently That's true Um It's not much work for general state tests and go with them can run general state tests already um Filling all blockchain tests however would take some substantial amount of time In the counts of days, but General state tests can be updated totally Even if the transaction receipt formats change Okay So is that something that Now that we've delayed 86 would be Something you'd be in favor of yoichi as I mean it would be additional work in the grand scheme Yeah, we with this additional work. I still prefer the delay of eip 86 Oh, yeah. No, I'm specifically talking about how much extra work would be put on for the changes to the The block hash that you were just describing or to the hash Okay, it's the change of the transaction receipt um But we we already are changing receipt formats and we have been we have updated the tests in the matter Yeah, so It's not a blocker okay, um That sounds good, uh In that case who should be responsible for editing that eip To add that that that was uh 98 correct Yeah, I think that might be The tower. Yeah, I can do that hold on. Okay In I think it's already in a comment from nick or someone um, we can just add Literally edit this right now I actually wrote 615 as a replacement 98, so I think with 615 we don't need 98 You said 615 Yes Okay You'll hold on 615 is subroutines and static jumps Sorry, uh one sec then Oh Oh 658 So it's literally a copy of a 98 but with your addition Um pretty much. I mean 98 just just suggests removing the um Intermediate state field and 658 suggests replacing it with status code. So it should be possible to just obsolete 98 and replace it with 615 Sorry, so it's 58 Yeah 98 replace with 650 you said 650 a Uh, yes Okay, great. Um, I think metallic might be Just adding it to 98 since everyone's kind of already gone there. I think you implemented some of the so we'll be either one Yeah, it's the content that matters not the number Yeah, so um Either way, we all agree on that and we'll just add it to one of them and then Push it forward if we obsolete it. I'll make note of that in the read me I see so nick you have a single byte. Whereas, um, I'm the way I'm writing it up is we have 32 bytes 32 bytes of zeros with or or or 31 bytes zeros in the one pretty much. Yeah, okay. Um I guess there's this trade-offs there one is that having the adding it like that reduces the migration hassle for clients Um, but it also introduces 31 bytes of pointless overhead Right, but in the long term the 31 bytes of pointless overhead is going to have to be removed once we add some kind of proper network protocol compression Yes Yeah, and which we have to do anyway because like the gas schedule kind of assumes that we were Assumes that we had a network protocol compression since day one Yes, I mean it weren't entirely a little like the other here, but it will reduce as at least Yeah So they're a problem with just doing one Um, it's just basically if you have if you keep it in 32 bytes then like the format of the like the data types Just like totally unchanged Okay I'd be interested to hear what Peter and and others think of the two alternatives Yeah, yeah And to be honest I'm on So I see the benefit of one of them is that you clients become a bit simpler if you don't if they don't have to care about two different formats on the other hand Retaining 31 zero bytes till infinity also seems a bit wasteful Of course, they it will be compressed in a database and Hopefully sooner sooner rather than later it will be compressed twice too. So it's not such a huge issue I don't know to be honest. I I can see the advantages of both And I guess uh clients are going to have to branch to determine how to treat that field depending on which block it's included in Anyway, so the overhead is was decoding it differently may not be high Well, uh, yes and no so in theory So if I'm running for example a client, so I just attach the remote mode and I want to It would be nice if I didn't have to care about the block number On that perspective, maybe On the other hand, it's not such a big difference. So Uh, uh, andre or christian, do y'all have an opinion on this? Yeah, I don't really Cool anybody else Okay, so yeah, um What what do you say metallic out? Yeah, that's good enough for now Okay, so just you're saying do the one by or not do the would do the oh, oh, you mean um the one by versus 32 bytes thing Yeah, that's the only thing we would talk about pretty much I I mean first like personally, I don't care into a python perspective either one is trivial, but I See what you have to be ready to think I guess I'd say if everyone's ambivalent about it then go for one byte because it's at least marginally better Yeah, and I mean we're getting a lot. I don't know I mean we could say like we can fix that later But why not now right? Okay, sure One byte it is All right one byte for that one cool I lost track. What were we doing? That's why we have an agenda Where'd it go? I have too many tabs guys. I don't know where my agenda is Oh, here it is. Okay, so uh Oh, yeah, so as far as the timeline goes The other thing that kind of goes with this agenda item is if we do so we are doing two hard forks We're taking out all of 86 for the first one and that's going to go in the second one What and this is super early, so we don't have to go into a lot of detail on this But what other EIPs would we consider? For the second metropolis fork, which in my opinion should probably not be till 2018 Just with the next few months and us getting metropolis out We can if anyone wants to do it faster, that's fine, but we'll be going pretty hard and then there's dev con and stuff So maybe january or february would be ideal for the next one But um any any thoughts on that just initially No, once we're once the First hard fork looks like it's being close to finalized We can figure out like exactly how much we want to do in this next one like what and what what what it'll entail I mean It would be a pretty significant change to A bunch of very low level infrastructure, so it's worth thinking more about kind of What could go along with that to kind of help or yeah exactly Okay, and there's also some other interesting ones like minor reward, which I feel like That being changed in the second hard fork makes more sense than we're going to change it No, the minor reward having it makes the most sense to change it at the same time as we cut off the bomb And the bomb has to get cut off in the first one Okay, I forgot where we landed on doing that for this Hard fork, so there was an EIP somewhere Um, it's a pretty trivial one Is it 186? No, well, it was um, hold on I'm leaving you one of the other ones Uh Yeah, be 100 because basically It's EIP 649 and pull request 669 That's the that's just the difficulty bomb, right? Yeah, we're talking about the minor Oh Yeah, the reward reduction. I didn't know where that one was And the reason for that would be Oh, so yeah, the reason for the minor reward reduction happening at first is because the difficulty bomb would change And so doing it on the second hard fork would make less sense Well, I mean It is what that's the same that the miners would revolt, right? Yeah, like in general just seems like in my opinion It seems weird to just like let walk rewards be really really high for two months and then like Cut it back down. Yeah Is anyone invitation wise they're both feeling straight forward Yeah Can someone figure out How much to reduce it and all that other stuff because there's been so many debates on it I can't really keep up anymore I think the informal consensus was to reduce it to like rough so that the rewards per second are roughly unchanged When the bomb gets diffused I think it was the most recent suggestion I heard was three years per box. Yeah, three years like the other got approximation Okay Or do we want to calculate it based on whenever the fork is I think it's much cleaner to just set an integer number of these personally Fair enough Okay I mean, you know, and basically want to make it pie or something Let's make it half a pie or three quarters of a pie Yeah, depending on how hungry we are you can make it three-fourths or a whole pie Yeah, well, it would lead to some great articles on coin disk, wouldn't it? Pie talk reigns an all four dev meeting um Okay, so That's straightforward. So between now and next time let's just make an eip for that um I'll put that on my to do Eip for Minor reward reduction That's pretty universally liked by the community um Okay, the other issue with this is it would be nice to finalize it fairly quickly because again it impacts all the tests I mean all the work does Oh, okay. Um, I can just write a comment to us six 69 The difficulty bomb delay. No, the yeah just like beat for issue. How did you add an insurance reduction? You know, yeah, that can go with the bomb delay one. Okay. Yeah, that's actually a good pairing to have both Uh, and that's an eip that can be quickly finalized, but at least we'll have the spec in there if you write that in right now That'd be great And that'll just have a day or two to for people to discuss But it's pretty much been decided in previous meetings Let's see Um, I did a reddit thread the other day where I said dap developers What is the maximum time that the block time could be before it affects your daps and I was trying to aim toward Getting stuff like casino daps and other ones that rely on low block times to kind of let me know what You know daps that are in production what they're doing right now and the wide consensus is that Most of the daps are favoring us doing metropolis right versus getting the you know, the The ice age fixed faster, I guess are like putting in the hard work more quickly and there's More there's few apps that rely on Block times being under 45 seconds if anything it just makes it a little bit annoying for many daps So above 45 seconds it starts to get a little bit more difficult for some some of them, especially the ones that deal with like casinos and Like ether delta decentralized exchanges because a lot of people can put up their A lot Just a question So, um, I'm a bit I'm not not sure how relevant this is but so So I can imagine a few apps that it would be smoother if the If the block times are 15 seconds will be your guarantee that your transaction will get in the next month You still have to count with that annoyance Yeah, all I was doing by doing this thread was to say You know if metropolis goes out and like we have problems and then it gets pushed in october where it could I didn't earn the calculations, but I think it could get to 40 45 seconds by october um How much would that affect the network as a whole? And it's sounding like it wouldn't be the end of the world so Okay So basically if we go 45 seconds, but at the same time we should look at it then in theory Either Yeah, yeah, that would be that would be in theory depending on also You know if the network with all the you know the i like the coin distributions recently like how many transactions are filling blocks That's slowed down a lot though. And so no one can predict the future, but I would I would reckon that we don't have like Huge like full block delays like we've had with recent coin offerings Beyond the end of the year Or before the end of the year So yeah, and then I guess the miners can just yeah adjust the block gas limit Uh, what were you saying Nick? I was about to say exactly what Peter said Great So yeah, just wanted to throw that tidbit in there Do you have any numbers the talak or anyone else on block times like between september and october? Um, sure. I can run that scripted. Um, I'll just rerun this the execution I did about like two days ago Great and while that's happening out. I could just wrap this up. We're pretty much done Okay, so we can expect We can expect block times to hit 21 uh 22 seconds at the end of july Then we can expect them to go up to 27 seconds on august 26 And then we can expect them to go up to 35 seconds on september 27 Okay, so that sounds like it'd be 40 to 45 with an october Um, it goes up to 45 on november 6th Oh, all right Yes, because like as the block time gets longer the periods also get longer So the block in the long run the walk time increases actually linear Okay, that's actually even better than I thought so this isn't going to be as much of an issue There shouldn't be any way that we would get metropolis out later than november. It should be well before then, okay Um, cool. That was the last item. Uh, is there any other comments topics Stuff like that Okay, great. Um, so I have a list here. Um We basically need to do 96 Wait, sorry It's a nice 96 98 and 198 are the ones without standing problems that I wrote down um The people who were going to help with that after this meeting were Nick and metallic Um, other people can stick around if you want. I'll probably turn off the live stream. Um But yeah, specifically 198 for the gas schedule and then Uh, why are we? Oh, we're just finalizing 96 and 98 with a few different things Um, just making it specific Uh So, yeah, let's get to that. Um, cool. Yeah, there's no other comments. Um Good meeting and uh, just everyone who wants to stay on the call stay on the call and we will Work through those three EIPs Cool. All right. Thanks everybody um I still have to see what it means to really help um I'm just interested. Okay, then I mean