 Yeah They're kind of I think it's being from Korea, that's what they're hating on Yeah, I'll have to see I'll post the link in the in the scroll box. I Mean in the I'll post the troll box link in GitHub is what I meant. All right. Cool. All right. We can start guys Yeah, okay, let's check this out. All right first agenda item. Thank you everybody The subtleties we're gonna work out Let me just see here is Arkady on Hmm. I don't see this. Okay, in that case we can we'll just keep going for now. This is the 649 Metropolis difficulty bomb delay and issue ins reduction. I think that Afri was going to redo that. Let me see what his updates were Yeah, I see that okay It looks like he just did put in the changes that we talked about last time which is to Reduce the difficulty bomb as Vitalik had said there's still some There's still a little bit of discussion on that, but I think we're generally set it was Specifically this comment. I'll put it in chat So what this is trying to do is this is trying to replace 186 Which was going to Where is that? Oh, yeah reduce f issuance before proof of stake. So I think all this did is combine it. Yeah So yeah, this looks good to me. Does anyone have any comments on this Which specific comment was this was this the one I wrote or is this a different one The one I pasted was the one you wrote that I believe Afri included in here, but I'm double-checking right now Okay, yeah, and I guess the main question is was there anybody Here is the link to the file. I don't think that This has any difference for Okay, yeah the block uncle and nephew reward rates was Three trillion of block number is greater than or equal to metro fork of Of three three Three f actually so the new uncle reward is eight minus K times new block reward divided by eight Mm-hmm, and the new nephew reward is new block reward divided by 32. This looks the same Yeah, I like I mean like the simplest way to define it would be just like a across the board 40% reduction in all All of the balance changes in the block finalization function but I Think I think everyone understands well What the spec is Okay, sounds good. So any other comments the need to happen on that feel free to go ahead and do that Okay, which one away aiming for with this one. Oh this one is something 649 Mm-hmm Yep, I say that one more time Martin. I think I missed it Which one of the forks the first or the second? Yeah, that's a good question I think it was the first is what we talked about. I mean Yes, it has to go into the first because like there's it's if we wait until the seconds to do the delay the issue at the issuance reduction and the Block in the Ice Age delay then blocks are just going to be way too slow. Okay, cool So for the next item unless it was there any other comments on that it looks good to me But that's something that can be quickly That can be kind of finalized next meeting if need be but I don't think we've changed anything about it in the last few meetings Do we have an update on the projected block times? I can do that right now Meanwhile Hudson is this is this finalized one 649 Yeah, I wouldn't say so because Afri just made changes on it like three days ago but I mean it's For that for the purposes of this call I was looking for anybody who has skimmed it because it's a real short EIP and found any problems with it But I wouldn't declare it finalized To the extent that we declare EIP is finalized. I think it's Go ahead with that Sorry, so I got so here are the results for block time increases on August 25th We can expect an increase to about 25 seconds then on September 24th, we can expect an increase to 32 seconds and on Halloween so October 31st we can expect an increase to 41 seconds Okay, cool. Let's see so there any concerns around those numbers being given whenever I did kind of a really unofficial Reddit thread about the block time everyone was kind of saying After 30 sec or after 40 seconds, it would be a little bit tough But right now there's no there's not many daps in production that require sub 40 second block time Yeah, so one thing we could do is try as an initial like to see if we can get metropolis in by September 24th, which would be 4.3 mil um Though i'm not sure if that's like over optimistic over optimistic not optimistic Uh, yeah, I think that we'll have to get to the point where we talk about testing and which EIPs are going in Right because I think there was some confusion Yeah, so let's go ahead now that we know the block times. Let's re-approach that once we get to the item on where the testing is Okay Hudson, uh, just um Could you could you make sure that that EIP winds up on the first page of ethereum EPs for either accepted or under consideration? Absolutely. I think there's a pull request from I thought there was a pull request from um afri to add that so i'll double check that And if not then me me or kasey, you'll change it Yeah, it's good to have those collected Definitely Okay So the next item should we defer EIP 96 uh kasey you can go ahead with that on the agenda page There's a link. I'll paste it into chat as well Uh that is talking about Uh EIP 96 and why we should defer kasey wrote up a thing Yeah, just looking at the progress made on different ones. It seems like 96, uh legs behind a little bit um I don't need to repeat everything I uh wrote in the comment But uh didn't want to hear what other people thought Um, and I definitely would be okay with delaying 96 if it meant we could get matril we could get um by zane tm out faster Yeah, I'm looking through this my question is does this um affect any of the other EIPs that would be going in or can it Does it stand on its own? It's totally stand alone Okay, then yeah, I think that as far as you know getting the difficulty block Uh delay change in there. I think that that Could be more important Yeah, it sort of depends on whether it's um More difficult to call the change out of the uh Code bases that already have it which I think is um mainly c++ and parity Um versus it's not so much a matter of pulling it all we have to do is just like a rename Change the word Istanbul to the word. I'm constantin opal and then set the constantin opal for a blocking number to like 50 trillion Okay I see what you did there All right, um calling it constantin opal instead of Istanbul is a rather political move Hello, uh, I think in case of this cap, there are some pending issues there and and I would say it's quite a lot of unanswered comments about the About the change it's into some details. I also put a Put a comment in the in the agenda just after Casey Listing some of of points that Are coming from my side, but I've seen there are some your issues issues as well Not clearly answered. I think so I would say the pace on on this one. It's not ideal So I would also go For delaying this to the next hard fork Okay. Yeah. Um, is anyone else in agreement on that? I've thumbed it up. Yeah, so good Okay That's pretty much everybody. So I think that that's good that we delay that So unfortunately, we don't have any parity folks here Yeah, exactly. I mean And we'll we'll say for the moment. This is okay, and I'll double check with Arkady because I think I'm gonna be talking to Rob soon um, specifically So Next item and I'm actually actively updating this um but Let's go to the one that Tim posted. I'm gonna it's a Recent comment. I'll post in the chat and in Gitter So this is it. It's basically asking about um, the big int mod exp eip 198 um, the requirements for the Benchmarks on that so Tim you can go ahead Yeah, hey, what's going on everyone? Um, so yeah, it looks like, uh Here uh, you're up here just commented on that and uh, I said it was mostly finished And that he was going to maybe add some some other requirements later But yeah, I'm not sure what uh, you guys wanted or needed in regards to, um, that specific issue So for for the mod exp, I think the There was a discussion if If short inputs were penalized unfairly And I think that's been settled and it's settled on what formula to use For the mod exp what is not really settled and that goes for mod exp and the rest Are the specific costs But as far as I know the formulas are agreed upon Cool. Cool. Yeah, um Yeah, let me know if anybody needs any any more benchmarks or whatever Yeah, thanks Tim. It's been helping a lot. I've noticed on the testing channel So that's great. And um, and does that pretty much wrap up that point? Yeah, more or less. I'm gonna try to set up like uh, some kind of framework or check out holyman's, uh Testing framework. But yeah, that's it. Thanks. Great. Just a quick Uh, quick mention regarding one of the pre-composed mod exp Um, yesterday I was working on emerging all the pre-compiles into geth and I double checked With the other implantations just out of curiosity And I saw that parity is still using the old the original gas calculation I tried to reach arcady. I couldn't so if anyone here speaks with parity people Please ping them that the gas calculations change. Yeah, but bitter We discussed this in our core devs channel a couple of weeks ago and I got thumbs up from um, I think Robert Robert and On parity team so this I mean it should be aware, but of course it's good to make some extra wear Okay Any other comments on that? Okay, great Um, so it looks like The last point for section a for subtleties or questions to work out is Um, let me I'm gonna ask is eip 86 The only thing going into constants and opal, which is the hard fork part two. So it sounds like now Exactly and then nothing else. Um, so the only thing is we talked last meeting Um, considering the bitwise shifting eip 215 Um, which is the one that um, alexberg's ozzy AXIC brought up the link to that's going to be an item three of the agenda Um, that was shifting to replace eip 145 So is that something to still be considered? Of enough importance to consider putting it into constants and opal since that was brought up I'd say it's worth considering, but I don't think it's uh, That useful so what it says spends discussion time on it until Um, basically the every metropolis has um settled or on the roads are being settled Okay, um alex, do you have any comment on that? So the the first half was breaking up what you you said had some Oh, I was saying that um, I was asking, you know, which ones are going into hard fork part two constants and opal and For that one you said, um, you made a comment recently that Eip 215 bitwise shifting was considered as part of that and since I believe that's your eip What's your perspective on putting it into? um metropolis at all Well, of course, I would be happy, but it's uh, it's really up to the people implement, you know, the different clients And the client I could handle is the javascript and perhaps the c++ um I would be happy to work on those two, but then other clients. It's not really up to me Um, but I would be happy to to have it sooner than later, of course Um, I guess it's not such a high priority at the moment And compared to the other work in progress Understood. Yeah, I would agree there and um, I do I do think it's pretty cool Uh anybody else um on the line have an opinion up or down about this? Okay, yeah for the moment. I think that we don't want to put any more on our plate. It's kind of the The feeling I've been getting from other people. So we'll just um Keep this um off of the metropolis schedule for now So let's see. Um, if there's no other questions on that, um Let's go ahead and do updates on Let's do the actually instead of updates to testing. Let's do updates from the client teams first Um, Geth, is there any updates on your end worth mentioning? Um, yeah, sure So philix has been working with the c++ team on test generations We are as far as I know all the tests that have been generated are currently imported into our repo So we have all the wrappers. I think for all of them and uh, we also, uh Uh, finished more or less polishing all the pre-compiles and basically just Ready for merge. So whenever markin or philix thumbs it up. It can be added and um the last batch of Polishes that we need are the opcode EIPs In theory, they are done in practice. I just need to polish it up and merge so, um Uh being one of the few issues that I do have is that for example, we've merged in already way a few weeks ago Two EIPs one of them was the difficulty adjustment, which obviously needs a rework due to the ice age And the other one was the removal of the intermediate state route, which now Was obsolete So it from my perspective, it would be nice to have a list of EIPs that We are finalizing so that We have an idea of where we're standing because it's a bit annoying that That we have to weed out previous EIPs that were At least previously thought finalized um So we can look through the github.com slash ethereum slash EIP is a repo I'll just link that again So if you look through the ones that are in there now Number 96 should probably be put into deferred because we've moved it to constantan opal Then 98 should probably be just removed entirely because 658 supersedes it um Then 100 is still um Fully intended to be happening Then 140 is um it's gonna happen 196 is going to happen 197 is going to happen 198 is going to happen to 11 is going to happen to 14 and 214 is going to happen and we also needs to add in to that 669 At least that's my understanding Yeah, it's a 649 slash 669 Yeah Okay, that sounds great Yeah, and we can update that list after this meeting Cool, so that was geth. Um, do we have anyone here who can speak for parody? Um, Matthew English. Are you with a client team or consensus or? Uh, with consensus, okay, perfect just making sure I thought you might be worth parody Uh, no, no, actually I've been working with geth Sweet. Oh, welcome um So let's see who let's let's see parody. I think last time we checked they said they had everything Implemented as far as test passing. Does anyone have um Has anyone seen them comment about how many tests were passing versus failing recently? Martin, I know you've been talking to Arkady some Yeah, I've been quite out of the loop for the last two weeks. Uh So I don't I don't know The hive tests show a lot of failures and currently I don't think they're running. I need to look into To that On the morning a few days Sorry Oh, no problem at all Okay, so the next one would be c++ ethereum Which I think would be christian air pal. Yeah Yeah, I can I can start here. Uh, I think There were there were no functional changes in terms of eip implementation Dimitri and to issue is our hard working on Tweaking the the the test Test suite and bringing more tests to a piece So that was the the main the main point of Following hard folks implementations I don't know if your issue wants to add something to this Now we are working on We are working on a random test generation. And the case is studying Court coverage approach from different clients what I want to do is fast testing tools that could Run a random test On every client and I badly need support from get or go I mean from other clients I need a comment that I could use to execute this randomly generated state test At least one client. Yeah, I think we've come quite far both on on get parity and cpp empire ethereum and Yeah, I think it's just one Thing that needs to add to parity and that's a receiver command. So we'll just have to bug them a bit more about that So I think the way to proceed here is to First Dimitri provides a sample file And maybe Dimitri can also create issues on each client people The file is the same as a state test and just a state test, but it's randomly generated. It has some random VM If you have finished implementation or not in order to know that it's it's convenient to have a fixed One file Yeah, any test from the state tests folder on repository. I just I need a comment from like get That I could provide this pass to a test file Maybe it's to the input and then get could run this In particular one file with one test and then I see Yeah, I think you can already create an issue them because Yeah, I mean the command should take this argument and does this My idea would be to to have put up a server which does 24 seven fast testing on all clients which can be fast and then The outputs from that would be consensus failures Where you could download what the command the traces and the commands needed to Genesis and the code needed to Actually run the evm and reproduce the issue That's kind of what I'm hoping to put together Martin same as Casey Yes Isn't our isn't the evm utility in go ethereum suitable for this task? Exactly. Yes. That's what I've Been trying to achieve with the evm utility and the same with the party evm bin Which I think it's thomas has been done most Most of the work on that one Casey said the evm utility doesn't calculate the post state hash No, it doesn't But what you can do it Gives you the internals for your job code and that's kind of enough for to do equivalence testing It also needs to uh a few tweaks to calculate and Pre-pay the gas and and charge for the intrinsic gas of a transaction Because when when the state tests run All that stuff is already done, but with the evm command Currently that's not it doesn't do that Yeah Yeah, so maybe some additional tweaking is needed Let's have a chat next early next week about how how we need to tweak the clients and the evm bins to get what we want Okay, any other comments on that it sounds like um a separate meeting is being set up Cool. Um, lastly, okay yellow paper, um, yoichi, I'm guessing there's not really much update um Still, um, there's a pending task of separating metropolis into Isn't him and constant enough that has not been done Here some coordination with giving is necessary. I think Okay Sounds good. Let's see Um, the last the next one is python pythap the talak Um, I did run the uh tests for metropolis and they were they all seem to be passing The there was one exception that has to do with code size and I believe So we still need to confirm whether or not the code size is a 24 000 bytes or 24 500 and 76 Um, so that was one thing that we need to confirm And so I both so I'm pretty sure that it is 24 exactly 24 000 is uh Oh, I believe most clients implemented the other number the other one Yeah Okay, so this is importance. Can we quickly check right now to see what client what number is implemented in particularly in gap and parity Uh, yeah, uh, can someone we can tell you if you look at looking up the hive Or if there is uh Is it so what's the name of the blockchain test and then you know, I can look up the hive result for that I mean the simplest thing is to just go through the source code. Um Yeah The maximum code size Yeah, can someone go through parodies, uh, who's most familiar with it? Or if the hive test work for a quick look that that could do it to everyone else here's from geth mostly The geth code size max code size is 24 k 576 Okay, um, just to clarify does that would a contract of size exactly 24 576 be accepted? Let me check it Yes, okay. Yeah, let's check parity to then the max code size is accepted Cool, is there anyone in the call looking at parity or Parities also 24 576 And is 24 576 exact accepted For cp a theorem it's uh 600 all in hex Maybe so that's um, yeah, so that's four five seven six and convert on the fly. So That that is two four five seven six. Um Okay, so this is important because the eip that introduced this change number 170 actually said, um, That the max is that the maximum code size is two three nine nine nine and somehow we ended up Um diverging in the eip. I'm also you can you check what the yellow paper says um, so First I did this 24k And after a while some tests failed and I asked around and the people told me no no no Don't look at the first comment in the eip. Just look at something below That's the right number. Okay. I don't remember who told me but I followed that. So I'm sure it's the nice hex number Okay, um, let's see parity max code size Um, okay, right. Let me check through that link Um, and then okay, so that gives you max code size and now I want to search through How the number max code size Actually gets used Um Wait, hold on I'm not seeing this. Okay. So can we can you search for the line of code in the parity clients where backscode size actually gets called? or I'm trying to do this and I can only find the json files Same here. Yeah, well, they put it in a variable with underscores instead of coming It's nice underscored thing That it becomes create data lemon right Okay Um, if or data line is greater than okay. Yeah in parity it accepts exact size um If you look at east core slash as um src Yeah, put the link there in the chat There we go. It's a line 311 of this file too. Um, okay No, that's okay. Good that we've cleared that up. Um, the other thing I wanted to confirm is are we confirming like in the In the skype channel, um, I yeah, I I had suggested the change that we the change um retroactive from the uh from genesis that if you try to create a contract At the point ends the contracts code or non says non-empty Then contracts creation fails immediately. So before initialization even starts and My reasoning for this is that number one. This is ultimately The basically the only right thing to do once ea p86 gets implemented and number two is that it's uh The only way to trigger any of this um before constant noble is basically to do an address collision And there's plenty of worse things that you can do with address collisions anyway Is there any is there any Thing that is pressing that we do this now instead of um, there's nothing pressing I guess so we could if we wanted to we could just weave this issue into a constant in opal but basically there is one test which is failing and It would be nice to Agree on what what should happen in that test I mean if this does mean just not thinking about this until constant noble and that's fine too because as I said The chance this will turn into a consensus failure is microscopic So for example, I know for a fact that the when it turns out that c plus plus is implementation of this Like we should I figured out the c plus plus implementation of this was bugged so If someone can create an address collision then they'll create a consensus failure Yeah, this change will make the implementations a little bit easier because Just because address collisions can now overwrite codes The journaling system needs to keep track of All the codes so that all the codes can be recovered But that's only necessary for address collisions And if this proposed change Comes in we can make the journaling system already easier Yeah, I guess it's a good change. I mean because if it's already a consensus issue It's just good if we define it how it should The definition in the yellow paper now is address collisions not considered and When a contract when a contract is deployed When a contract is created it starts with the empty code so address collision overrides a contract And do we today have tests already which So yes, we do Yeah, so it's just a something that needs to be implemented and the test will succeed So sram slash tests already have this test So basically there are two ways. I mean yes, did the no the default way would be just believe the yellow paper and Try to get it right in shape of pcp sram and test cases and Other clients implement this for this virtually never happen in case The other way is vitalex proposal Yeah, I would personally go with the vitalex proposal here It seems safer and more aligned with systems like git and others When you never accept The same hash to be downloaded Okay, vitalex to that cover that topic All right, so what's the this decision for the moment? Is there one? I'm not sure there is one. Um, if anything So if I hear no oppositions, I will go ahead changing the cpp sram To change the test suites with this respect Uh, does it record if if we're going to to to disallow Overwriting uh existing contract does it Does it need a EIP for this to be specified? correctly or um, give just some tests and Force everyone to to be compliant with the test Yeah, so my current my opinion is that the probability that any of this is going to be Any of this is going to be an issue at all like even in the presence of attackers before constantan opal is very small And so I would personally view it as being kind of similar to um, eip 170 where we had Um implemented the code chain of the maximum code size limit and implemented it retroactively um Or at least we may have it let's it retroactively I forget So, I you know, I'd be happy to write any or write up any idea for this if you're quickly if We want to do that for procedural reasons Uh, that's probably good because there's no one from the parody team here and we're missing a few other client teams like java. So Yeah, thanks Vitalik Let's see. So did that cover that? Um, I think it was Vitalik who brought up that point initially Okay, great. And we were in the middle of seeing where pythap was so pythap Um, you were just saying you were figuring out that main point Oh, you're cutting out and I think we should be Um, can you hear me now? Yep, I can hear you now Okay, with those two points addressed we should be fine on the state tests But I do want to call attention to the facts that the block tests the the block specific eip is so specifically 98 and 100 and 669 No, haven't been implemented in pyatherium yet. And basically I'm just waiting for tests for those to exist Is the pyatherium client running blockchain tests? Yes, again Okay Okay, um, do tests exist for you for any of those? Um, actually no the pyatherium I forget no the pyatherium clients can run blockchain tests But it has not been passing them for a while And part of the reason why is basically confusion on what block schedules are supposed to apply to what sets of block tests, but I mean We can take that offline and figure and uh, Figure that out. Uh, do the blockchain test currently implements the block block specific eip is The Transaction Okay, and specifically the version that replaces the transaction at receipt with a single byte for success or failure, right? Yes Okay, um, what about 90? Uh, okay, so that covers 98 and um 100 the um unclean's um, uh A difficulty change Is the difficulty in the blockchain tests should be already computed with the new Formula and I had to repeal some tests when I changed it. No when somebody changed the difficulty formula Um, so there are there are tests involving uncles. So there should be Okay, so and is um Eip is 669 am augmented in cpp aetherium now Yes Okay, in that case uh, okay, then I'll we'll take this discussion offline and we'll figure and figure out how to Oh, and I'll run pytheon through all the blockchain tests and try and talk talk through any of the ones that Yes, I'm interested. This is a priority if there's a test missing Okay, um sounds good to me In that case, I'm I'm I'm satisfied Okay, great any other teams in here? Um Um Tim, are you mostly doing uh, geth and geth and parody testing or are you with a client team? Uh, it's a good question. I uh bouncing all over the place between geth parody and uh, I was planning on looking at the c++ cementation possible Pythap or whatever else Yeah, cool. Well, hey, thanks for thanks for helping out and uh So you're not on the aetherium j team then I'll try to get one of them involved To see where they're at not that they're a client that has to be Up to them metro necessarily, but I think that's what they were potentially aiming for Um See, I don't mind looking at my there that's for java. Yeah aetherium j they're they're getting back up and going again for metro Um compatibility is my understanding Okay. Yeah, keep me in the loop on that cool All right, uh, so that since that's all the clients, um, I think with throughout this we've been talking about testing But demetri martiner yoichi or anyone else is there any other uh testing updates? We should be aware of and is there any type of percentage or uh quantitative measure about how close we are to being done We have a split into them tests with metropolis field to bizantine and constant genobyl And um, there were some updates to blockchain tests nothing that often new features but And just cosmetic updates and the vitality of said that you Don't know the schedule of a blocks and blockchain tests. It's now has a network field that's specifying which rules to use when computing the test and There are transition blockchain tests specifically to test them transition from one group to another And the block five and we could add the okay. Um, is there any uh documents like that? It's written out that describes how all of these uh rules work They're pretty speaks for themselves like a transition block five from this Okay, I mean I recommend like having that kind of explicit document written out As I said, we can go through this later I pasted a link from from our internal test suite which initializes Might be a hint might might help you Yeah, and also hive tests are generated from the state test. They are also in a test repository and develop Please check always check that you're on latest develop branch from the test repository and You could see on a blockchain test. There is a folder general state test which actually a blockchain test representing them And this are the tests that hives should pass on all clients So, uh, Dmitri, I'm curious. Um earlier. There was something called transition that would transition that five eight seven fourteen and two hundred I sent the link there Is that deprecated It's uh, it's a link that uh Peter sent better source of truth Uh a link right now I said in the in the chat Google hangout chat Yeah, it's it's it's a link to the go source code Yeah, yeah, I said one about that Rules for transition and yeah, this is deprecated now. All right. So I'll update that wait wait wait. There was one single test in a transition Use it. I have to check Okay, so if I understood you right Dmitri you said all tests are written, right? Yes, that's deprecated um Tests are never written Yeah, I get you I get you To solve that problem. I I want to run a random test generation like fast test and is the one that Casey's country working It's his own approach and my approach to generating a random positive code And run that's random scenarios of hope code combinations on Other clients and see maybe I found something Yeah, Casey was telling me about the first testing. It's really really awesome looking So if anyone hasn't talked to Casey about that or seen it talk to Casey. It's really really cool Yeah, okay, Casey's using some tool that covers all of the possible scenarios or code coverage and Then he did this for one single client the if you Will be able to trans this test on other clients and maybe you could find some issues We are working now on coverage with the fast and random test Okay, great the the the art of buzz testing. There's actually a whole subreddit about buzz testing by the way Oh, wow um back to Hudson's question if we have Measurement or both progress how many tests are fading? How many are succeeding? um when the online hive Statistics works it will be that measurement um currently It's weird because in it's a lens rush tests metropolis tests have disappeared Now there are only Byzantium tests and the Constantinople tests but in the online hive interface we Just see the metropolis test yet. So The measurement is not up to date so Yeah, but when this starts working we can you know follow the numbers Hopefully decreasing. Yeah Hive hasn't been updated to these new networks These new rules names. That's why we're not seeing any Byzantium tests on hive But it's already helping a lot Okay, that sounds great. Um, so that kind of goes over testing. So We're back kind of to when the testing and release should happen and Vitalik Can you remind me when the block what the block time when it hits like 35 seconds? Did you say? Um, hold on. Let me look through that Thing again, um Okay, so September 24th is when it goes up to 32 seconds. That's right And hello and halloween is when it goes up to 41 Okay um, is it feasible To get this in by end of september. So that would mean by Later this month starting testing uh for I've heard numbers being thrown around for a amount of time to test and I think that we hit a sweet Spot on four to five weeks, right? Yeah And so I think right now the major progress we've had with this meeting is that it seems like there are client we've Established that can work like we're established a full specification of all the eip is and it does not seem like we are arguing over eip protocol anymore And that we have clients that have implemented them and it seems like we may already have tests for all of them So the next stage at this point seems like getting to the point where all the clients are passing all the tests and we're comfortable The test cover just complete enough In terms of tests, there are two things to catch up 96 should move to constant noble And this hasn't been done in the tests yet. So this has to be done. Um, this Is age delaying Is not implemented. So this has to be implemented in gpp and the tests Yeah, I would feel good and I just want to see everyone's opinion on this if we can get some Approximate dates that we think we would be able to launch testing today Just because the next core dev meeting is august 25th And then the one after that is september 8th and then we're getting into some higher block time territories so I don't know For instance, like Which teams have the resources to make sure this is done by then martin. What was your opinion? But wow, I was going to say that I mean testing is happening All the time, but I think that we should perhaps start weekly calls People who are doing testing and are writing tests and doing these things To really Get that ball get all the tasks done That needs to be done I'll Testing phase could also mean Activating it on the the test that on on ropston Yeah, and actually with that would ropston be the network we use and is it stable enough? Well, that's the only network that the whole client speaks. So I guess Yeah, unless we just spin up a whole new one. But yeah, I think I feel like the easier thing is to just do ropston Well, it makes sense to activate it independently on on coban and rinkabee as well um Yeah, peter, what would you think about updating rinkabee with uh with this type of thing? Basically that's just modifying a configuration. So it's For me, it's all the same. Okay, cool All right, um Anyone want to be brave enough and throw out a time we should be doing all this or should we wait till next time to declare a time? I keep getting worried when we push it back, but if i'm the only one then i'm cool waiting What if we Meaningful targets So let's say that uh, let's try to wrap up and try to pass all the tests by the next core dev meeting Okay, yeah, that would be okay So if we're doing that if we're wrapping up and have the test done by the all core dev meeting then we could feasibly Then like Something like the last week of august start the testing period, right? for a test net Or first week of september Yeah, oh first week. Well, basically last week of august august first week of september kind of period Yeah, the talak. Did you I thought you were about to say something I didn't see No, just kind of say that sounds fine to me Okay, so right now we're going to shoot for testing the start Somewhere between the last week of august and the first full week of september um, and then testing would occur for um Do we say what was the number four weeks? Or actually can it be shorter than that? Or I I mean I feel like we had this discussion in multiple core dev meetings ago, but there's like some There's not like basically the more weeks of testing doesn't necessarily provide that much value as you go up a number of weeks past a certain week Do we have any features which are Already entirely finished everywhere and could be launched already Or do you want to launch everything at the same time? I think everything at the same time just like how it would be on live nets. Usually how we do it, right? yeah Well, there isn't really a better way unless we want to simulate three small forks yeah I think that we should just do a everything on test and at the same time everything on live net at the same time just because We're already breaking up the hard fork to put things on a second part of it Or a second mini hard fork. I guess we can think of it as so Breaking it up for the actual launching of the features further doesn't make sense to me But i'm not actually implementing these features. So i'm i'm totally happy to hear anybody who thinks differently I think that's an easy way to launch one feature but not launch the other one. So it's it will be just messy okay Okay, so yeah, we'll shoot for end of Uh, yeah last week of august first week of september and then Four weeks from them. So we'll basically be getting it done by Um, let's see one two three If we do four weeks of testing it would be first week of october if we do three weeks of testing it'll be um the last week of september Of course depending on when we actually, you know launch it on ropston Oh, also I'm guessing it's better to like Just just as we're deciding dates and stuff It looks like it's better like during the week to launch these things right because that's like work week instead of a weekend Yes Okay, cool I'm I'm with that too Oh man, my birthday is on september 24th. We could it's a sunday though. So let's not launch it then It's about to say I could get a birthday present, but Yeah, that'd be a that'd be a stressful birthday present. Let's not do it that day um Well, we use the current target for the for the 41 second mark how some nice candy and ghosts on it Yeah We're also in debcom and cancun them. I don't know Oh, yeah, we are I feel like I feel like multiple teams and multiple people would have heart attacks if we did the fork during cancun Uh, so yeah, let's not do that. Okay, cool. So we have we have dates at least for testing done last week of August first week of september time period um So, yeah, um, I have something on here for gas prices and opcodes for pre compiles Martin, um, I think we've been going over updates as we've been talking But is there anything any updates you want to describe or anything any needs you have? No, I haven't been able to spend any time on this. Um, but what I can say that it appears to me that the new opcodes Uh Compared or the new pre compiled compared to the old ones. It seems like the ones are Too cheap and the new ones are a bit too defensive to Too expensive And should be made a bit cheaper and perhaps the other ones. Yeah, they're not in sync And it looks like Tim and Matthew had been messing around with running some of those on different clients so we could probably Um, um get their support a little bit more if needed. Um, I think yeah, I think I've been seeing that in the testing channel at least Uh, so feel free to to to ask for help. Um, as you've already been doing Yeah, I'm back in working full-time now. So I'll I'll talk with Arkady and the other guys for the benchmark you reach and Tim and we'll try to Sweet Decide or something Okay, cool. Um, uh, we already talked about bitwise shifting. Is there anybody else who has any other topics that aren't covered on the agenda in this call? Nothing. Okay, I'm gonna post something funny. I found in the troll box Basically someone kept seeing Greg's picture and making up like different scenarios about Greg being this wealthy wizard with birds in his beard. So you can you can read through that if you want Cool, bro Well, see you've got to be kidding. Yeah, apparently you own likes 80% of ethereum and like everyone what he was like, I want to keep hearing that guy talk I want to keep hearing that guy talk and it was like All this all this stuff. So yeah, just just gonna end on a comedic note there All right, cool. There's wisdom, Greg Yeah, do you have any wisdom to share Greg before we go? What I don't have any wisdom at all Okay, so that that guy if I had any wisdom, I wouldn't be living in a beat-up mobile home in the middle of nowhere Okay, cool. Well, thanks everybody I would have bought some eth a year ago. God, yeah Okay, thanks everybody. Have a good day. We'll see you in two weeks Okay, bye. Bye. Bye. Bye