 Okay, let's see. Is anybody from Parity here? Yeah, Arcade is here, right? I'm here, yeah Arcade. Oh, welcome Arcade. We got someone who hasn't set the name also. Yeah, if you could go, if you haven't set your name, go to the top left corner, and there should be like a little box with a face, click that and change your display name. Hey, Kamavis, can you hear us now? Yep, it seems to be working great. I haven't used jits before, but this is nice. Awesome, awesome. Am I pronouncing that right? Because I always have trouble with that name. Spot on. Perfect. Okay, I think everybody's here, so let me go ahead and pull up the agenda. And yeah, the agendas in the All Core Devs Gitter, it's in the PM repository. So the first item on there is going to be, should we set up like a recurring meeting time? We usually do like a Google Doodle, but people have been asking if we can just set up like a, you know, always on this date this time. So a suggestion that I had was the first and third Friday of every month at 1400 UTC. So pretty much this time, first and third Friday of every month. Is there anybody who has a better suggestion or anything that's a deal breaker for that time? No, but could you link the agenda again? Absolutely. Let me send it out on Skype and on Gitter. Is that a particular reason for doing Fridays instead of Thursdays? Because the last few times Fridays seem to be like the least busy for people. But yeah, I'm okay with Thursdays as well. It just kind of depends on what people think. And what we might do is there's going to be some days that, you know, there's going to be conflicts with a bunch of people missing, like Ed Kong and Paris coming up on the 14th of February, so we'll have to change it. But I was just thinking we try, I was just thinking we try Fridays 1400, see how that goes. Would 14 be better, Martin? Yeah. Great. For me? I said 14, I meant Thursday. Yeah, doesn't really matter, but yeah, I'd prefer Thursday, but it doesn't really matter. I think it's, we could give it a go to regular walls and if it doesn't make sense then let's skip it. Okay, sounds good. Great. So the next item, I'll just start setting that up and like send out invites and stuff. Okay, so the next one is Christian about EIP eight and that one is the gas cost for return value. So Christian, you can take it away. Thanks. So yeah, we discussed that for quite some time already and if I remember correctly, there was a proposal last time, which was waiting for the confirmation by parity and I think Arkady was present and he said that he's not at liberty to decide about that. Did that change in the meantime? No, not really. We haven't discussed it here in detail. But do we have anyone from parity right here? But I mean, yeah, I'm here. And can you make decisions about the design of the consensus changes in parity or not? Yes, at this point, we'll be happy with anything that you guys decide. And we can always have a situation where we can have like a very tentative yes with a 24 hour or 48 hour period for kind of final comment on that or someone else from the parity team has any issue. We can just let them know to send in their comments in that time. So then I would propose that I think that right. Yep. And so to be honest, I don't remember the exact details of the two alternatives. But I guess most of the work does not have to do with that single decision. Yeah, we're going to be redoing the EIP soon. So Christian, I'll get with you on formalizing that one from an issue to a PR. So then once we get the implementation and we can just reach out to all the teams and relevant people about that. Good. Okay. So yeah, unless there's any other comment on that one, we can just run on to the next one. Also on the left upper left side. Yeah, sure. Just for Jeff and Jeff and Vitalik, what are your guys thoughts about implementing the return code? Any thoughts, pros, cons? So it looks like Jeff dropped off for just a second. And I don't know where Vitalik is. Let me see. Sorry. So what was the question? Everyone, okay, yeah. Turn off the video to say bandwidth is what someone's saying. Oh, sorry. Yeah. Yeah, so Jeff, I was wondering if you as one of the client implementers, if you have any thoughts about this dynamic return code? I think it's the same as always. I mean, the same as it was before. I'm happy to implement this. I think it's fine. I mean, we've been discussing this now for over two or maybe even three e-calls or core calls. I think it's about time that we actually do something. Jeff, could you hear Martin? Sometimes some people cannot hear some other people. Yeah, he answered. Oh, then I couldn't hear him. Yeah, Jeff, do you hear me, Chris? I hear you. It's all on board with it. Okay, good. Let me just reload quickly. Yep. Hey, Chris, can you hear me now? Chris? Yes, now I hear you. Okay, cool. So I said, as in the previous discussions that we have had over the past three, four, I don't know how many calls we've had about this, I think it's fine. I think we should implement it. I think we have been postponing this for too long. I think an answer is, you know, I'm not in the liberty to make a decision. Then either you get someone that can make a decision or, you know, don't. I mean, you know, we've got to do something. Yeah. So if Gavin is the person that can make a decision, get him on the call here. And otherwise, you know, I think this has been the third call, the fourth call, maybe I think we should, we should just either we should do it. We should implement some. Sounds good. So just real quick about the process for these decisions and EAPs. So this was actually the last agenda item, but it's probably better that I bring it up now. The new EIP process has a more defined way of, you know, getting through EAPs. So there's going to be just a little bit more of a formal method. We're still going to be using, you know, just general consensus and meetings like this and other things to, you know, come up with if an EAP should move forward. But things aren't going to be waiting in queue for months anymore, as long as they have, you know, pretty general consensus and we can quickly get together with most of the main parties. So yeah, that should fix things a lot. But yeah, sounds like everybody's in agreement on that pending any more comments from Parity. And we can check in the All Core Devs channel for that. Oh, on the top left side, because I think someone just asked if there is a chat. If you open the shared document on the top left, it's like, it looks like the little document icon that opens up an etherpad so we can just use that. And I'm taking notes and I'm going to release those on the GitHub afterwards. Will you be responsible for that every call? It would be good to know. Yes, I'm responsible for that every call unless otherwise stated. So I would just, yeah, I'll just let someone know if I'm not here or something and they can do it. Hey, Roman, can you hear us? Yeah, I was, Roman, Alex, Vitalik. Can you guys hear us? I can hear you. Okay, cool. Did she get anything of the conversation that we have just had? I personally dropped out a few minutes ago when someone asked me about the return gas at EIT8 and I said that I was fine with like every version of it. Oh, okay. I actually, I didn't hear you, but cool. But you can hear us now fine, yes? Yes, I switch to better internet. Yeah, we might need to switch to Skype, it looks like, because there's enough people who are dropping, let me see. Yeah, so I mentioned it on Skype as well, but so we've been, I'm not suggesting that we do this now, but maybe for the next time we switch to Discord. Discord, we've had some, you know, we've had pretty good experience with that so far, no dropouts, no weird, I mean, we've had some weird corrects like the ones that we've had right now, but things seem to be improving rapidly. They seem to be doing a lot of improvements and they seem to deploy code every now and then, so that's good. Discord, please look into that, it might be a way forward. Great, yeah, I think it's a good idea I've used it before. I would say that, because we're having enough trouble, does anyone know if Skype supports 19 people? I'm like, I'm totally open to trying Discord next time around. I don't think so, I think it supports up to like 10, even less. Okay, we're going to keep trying this for the time being then, I'm releasing notes after, so I'll just let everyone know we kind of have to go through this way. But list some options for people to troubleshoot. So while that's happening, let's go ahead and the next one is also Christian talking about pre-compiles for elliptic curve point addition and a number of other topics on that. So this is basically about adding pre-compiles for, yeah, to enable the case notes on Ethereum. And I, together with Ariel Gabison, I had some kind of, yeah, research session in December. And at first we try to keep the pre-compiles as flexible as possible to support multiple curves so that we can switch to different curves if some curves turn out to be bad. But it looks like this can't really be done, there are no generic elliptic curve addition or, yeah, in general, elliptic curve operation implementations. Because we would need, so we of course have to assign gas costs to every pre-compile and there's no way to do that in a really generic fashion. So I would propose to concentrate or to implement pre-compiles exactly for the elliptic curve used by Zcash. And in particular one elliptic curve point addition pre-compile, one scalar multiplication pre-compile and one pre-compile for the, for a pairing function. The, okay, the pairing function, perhaps I also should say something there. So in general it's a quite complicated thing that maps a point that takes two points on two different elliptic curves and maps them to a rather complicated finite field. And all of these, in all of these we could potentially run into representation problems because there's no really, yeah, not a unique way to represent elements from these sets. But the good news is that we can, instead of implementing this pairing function, we can, it suffices to implement a pairing checker which basically just returns true or false depending on whether the result is the identity or not in the target group. And that removes the need for a complex, specifying the complex encoding of this complex finite field. And so what remains for the specification is just to, yeah, fix an encoding for these two elliptic curve, so for points for these two elliptic curves. And of course, yeah, to assign gas costs for that. Yep, so I have a kind of working group here in Berlin to work out the details for that. I would like to hear general opinions about this from the others. Hey, could you link to the in the Gitter channel the if we want to make the sum of the pre-compile was slightly more generic. Well, one thing that we could do is we could make the addition and multiplication be support any curves that have like any B parameter. So the A parameter would be of the curve would be zero, but the B but the B could be anything. One reason why this kind of slight increase in genericness is nice is because it also covers the sec P256k one curve that we use already for easy recover. So like we get for what's probably actually might even be a zero complexity game because the addition form in a formula is there I believe are independent of B. We had yet just a bit more support, but that's a fairly small point. So you're saying we can make the elliptic curve operations a bit more generic but not the pairing. Is that correct. I believe so making making the pairing more generic I think might be harder. Actually, you know what hold on. Let me actually check through my code right now. I'm just going to check if they're like where the A's and B's are. But we'll be telling I think you cannot hear Hudson is that true. Yes, I am. I cannot hear. Oh, it's not important, but I was just going to say Christian, could you post a link to this EIP or anything about the specification. But in general, I'm fully on board with the pairing implementation. The one thing that's worth adding is from an implementation standpoint as I believe Sean does have that hearing implementation in Rust, right. I think so there should be implementations in Rust and in C++. What is the what is the go team think about. That's how I think about it. No, right or not. So we would need to find either find an implementation or reimplemented and go. Do you have go applications of the electric off the recovery and stuff. Yeah, yeah, of course. Well, I mean, so the only C dependency that we have is the recovery functions and assigning obviously. Other than that, we would probably need to implement it ourselves. And as far as I know, Vitalik has already implemented it in go so that's could serve as a good example. And other than that, you might be able to help. If necessary, we'll find a way, I guess. Yeah, so we're not too keen on C++ dependencies because this kinds of break are complete. Cross compilability. So that would serve big time because we can right now we can compile to any platform and adding a C++ dependency would probably break that. Yeah, I see makes sense. It keeps dropping off things. So people hear me. Yeah, I can hear you. Chris, what kind of dependency were you? Vitalik, can you hear me? I can hear you, but Jeff cannot hear you. You cannot hit Jeff. Okay, what's with jit seal like it seems like like it seems like some pair wise connections like communications work but some pair wise communications don't. How do you even make it a chat app that like fails in that way. To be fair discord often has the same problem. Sometimes you get what you pay for. I've always found Google Hangouts to be really quite reliable. Yeah, but Google Hangouts doesn't. I figured the last up to 15 participants. Yeah, exactly. So yeah, we're going to let's also look into WebEx and I'll look into some paid ones and I'm taking lead on that after the call. So Chris, what kind of dependency where you're looking? We're looking for this. So we need a an implementation of the of the pre-compile of the of the pairing function. Yeah, we can we can probably write it and go I don't think it should be that much of a problem. Okay, I mean, it's not so the the pro side is it's not sensitive implementation. So we don't need to keep track of leaking side channel data. So it's fine. We'll find a way I'm sure. Okay, so it sounds like we have go and C++ and Python clients. So Anton Roman or Arkaday, could you comment for your teams? Now there's also Rust library. So we're good. Yeah, about Zcash and all the abstractions for we just started to look at it. Just finished a big release. So I didn't have a chance to actually go into details, but we are okay with why with your decision. If people want to make an implementation, I mean, you can always feel free to just copy the one I made in Python because it was designed to be kind of both like as readable as possible, even at the at the expense of speed. But yeah, so you actually is suggesting to take Python as a reference implementation. I mean, I'm, I'm hold on to Java. I mean, first of all, I would recommend the step one trying to see if there's any pairing implementations written already in Java. And if there aren't, then I guess copy and Python and if if it passes all the tests and it's probably worth giving it a review is probably second best. Yeah, we need to dive into those. Yeah. So also, I'm sorry, I totally forgot. I see Jan's in here. Jan, what do you think of this? I guess because you work on both Python and Ruby? Oh, yeah, I think there should be no problem with Ruby and Python because we can use FFI wrapper to wrap the C library. Yeah, that should be okay. Great. Anyone from Parity, Arcady or if Gavs joined or anyone at this point? Yeah, can you hear me? I already mentioned that there is a rust rate and that works for us. Perfect. Okay. Did everyone just hear Arcady? Just want to get a check. Okay, cool. So yeah, everyone seems good on that. So we can just check that off and say that. That's a lot. Oh, yeah, Arcady said Arcady was on board. Yeah. Perfect. So yeah, we can check that one off. So the next thing and this one is going to take a little bit. The agenda that I posted, if everyone could go there during this conversation, there are about five links for the EIPs that Vitalik is going to be discussing. He's going to be talking about Metropolis, but real quick before we do that, what is, because I know Martin posted that the difficulty bomb is about three months away. Is that still the case? Well, it's not so much a bomb. It's an ice age, right? So like the, it never explodes. It just kind of becomes the war on the block. Time becomes worse and worse and the security becomes worse and worse over time. So like three months as the word starts to become noticeable, I think actually hold on. Let me just get my script out again and I'll just read it out again. Yeah, but basically this conversation topic is about the impending ice age, sometimes called difficulty bomb, but yeah, ice age and then also Metropolis going forward. Okay, so from what I have in exactly three months from now, so around March 25th, the block time is going to go up to 15.2 seconds. So that's about 6% up. Then six months from now, so like around July 25th, the block time will be up to 29.7 seconds. So like between three to six months is where it starts to kind of substantially manifest itself. Okay, cool. So interesting. So I guess, does anyone have any questions or concerns about that? We're going to have a number of core depth meetings in between that time and it sounds like we're coming along with some of the Metropolis planning. So if there's no other concerns about that specifically Vitalik, you can go ahead with the Metro EIPs you were going to discuss. Sure. I mean, from these five, I think I'm pretty sure we discussed almost all of them already. So like EIP 86 as the abstraction changes. So I recall us discussing this several times in previous meetings. Basically allows a new transaction type that's kind of more basically it has a sender of zero and then it also has a two extra transaction. It has two extra features which basically modify the scheme that's used to determine the determine an address of a contract. Basically the moving from sender and nonce to sender and code. And like this, we talked about all of this and I recall from last time that people generally found the idea acceptable. There were a couple of versions of this, but as I recall we get into like one version, basically there's one of the issues that you started getting is like what if you try to, what if there's an existing contract that calls create in such a way that it tries to create a contract with the same code many times. And you don't want to break existing stuff unless you absolutely have to. So the debate was between having a very complicated scheme that checks for that it automatically tries to jump to a different address versus just having like a new create opcode. Like I called it create P2SH, but you can call it create whatever. And I recall the opinion being more toward creating a new opcode because it's just like cleaner. Then so that's then after that there's the EIP 96, which is basically trying to kind of on the also on the abstraction roadmap trying to take block hashes and state roots and move them kind of into the formal state, rather than being something that requires sort of extra infrastructure to try to try to access from inside the VM. Then there's also, I recall us previously talking about EIP is for elliptic curve addition and multiplication, but like that's, that's now kind of being rolled into the pairing discussion. So I'm not worried about that. Then EIP 101. So this is a big inter arithmetic and I which so hold on instead of an opcode can we cannot we have a pre compile for creation. That's worth, I guess worth considering, although matches well with how wasn't would operate. Okay, I mean, I'm happy to take that discussion offline, but it's so I think at some point we basically I think the question there is, is whether or not like the question is do we have more opcodes versus do we have pre compiles that have a new kind of stuff like this would basically be our first impure pre compile. No, I can't hear Christian. Yeah, I was about to what was impure. That's the exact saying. Oh, I think he was just clarifying the definition of a of a term. So he'll probably just put that in chat in a second. Okay, cool. Is this on one of the EIPs? Yes, so the block hashings. Hold on. I think EIP here. Right, exactly. So that's what I was getting at that. Basically, if you have a create pre compile without without having a create opcode, then you have a pre compile that cannot even theoretically be implemented in VM code. And like this is a sort of fundamentally new kind of complexity. So that was the kind of best argument to get in favor of just making it an opcode for the time being. What's the EIP number? I don't see it. This is 86. Yeah, so on the I just posted GitHub slash Ethereum PM issues three that has a list of all five that the talix talking about from what I've been able to keep up with so it's not in the order on the page but it's there they're all in there the links. Okay, and it sounds like Alex just clarified. Yeah, I got it. I just hadn't read that part of the conversation. Yeah. Great. So yeah, was that all the EIPs metallic? I didn't know I was just like just to keep going through all of them following. So with the IP 101 big integer arithmetic. So the reason why I'm just finished answering a Christian. Oh, cool. What about EIP 98. Let me just check over this. Ah, yes. I'm very good point EIP 98. Yeah, EP 98 is going to screw over the line client though. Jeff, was that you talking? Yes, that was me. Okay, great. You did not hear me. Oh no, I heard you. I was just making sure when I tell the talix the talix. Can you hear Jeff? Jeff, can you say something? Yeah, I don't think you can hear me because I just did. Maybe not. Oh, okay. Let me see. Yeah, I almost might be worth me just throwing in a Google Hangout link because everyone's on Google for their projects. Do you think that's worth it anybody? I feel like it'd be like a couple minute delay, but yeah. If you do make sure you send it from an EIPs account because apparently EIPs accounts 25, but regular Gmail accounts 10. Oh, you said from an EIPs account? Wait, which kind of account? EIPs, Google EIPs as an Ethereum.org account for instance. Ah, got it. Okay. So yeah, I'll start that up while we're still having this discussion over talk and chat. And then when there's kind of a stopping point with the talix comments, I'll just send out the link and get everyone switched over. So yeah, Vitalik, I think, yeah, you just got all that. So yeah, Vitalik's talking and chat that looks like the EIP. Yeah, they're going to go. Well, EIP 98 is like controversial for and or at least like not fully settled at the moments, but we'll discuss it offline. Hold on. Which other one? Yeah. So the other thing that I wanted to finish off on is that 86. Okay. I almost got the hang out up. And let's hope that so a video call. Great. Here we are. All right. I'm putting it in the jitzy link. I'm also putting it in Skype and get her. What are we supposed to do? Everyone switched to Google Hangouts. I just put the link in and we have confirmation tentatively that it supports up to 25 people and we have less than that. Okay. Hello. Can people online hear me? Yes, I can hear you, Vitalik. Yeah, this is much better. I can't hear Vitalik now. Nick, he used to work for Google. Oh, sorry. You were talking on Hangouts, right? Oh, yep. I should get off jitzy. So testing can, can you hear me? Yes, I have so you can hear you. Okay, great. Awesome. Okay. Looks like Nick's on. We have a lot of people. So we have most people. Casey's joining. Let me see. I'll wait a couple of minutes. Oh, yeah. It won't take that long. We have most people here. Kamavis, did you get in here? Yep. I can hear you. I can hear you, Jeff. Awesome. Thanks. Okay. Let me just make sure. Arkaday, can you hear? Yeah, I can hear fine. Perfect. And then we have Alex Bergzalsi, Yoichi Alex, I understand. Casey, Christian, Jan. This is representative of every major client. So Talc, if you wanted to continue. So basically what we just did for those who didn't hear is go over some EIPs for metropolis. Yeah. Yeah. So how about I'll just kind of recap a few things because it looks like there are lots of bilateral communication problems. Sure. So I'll throw this into the chat. And the other thing is, hold on. Okay. That doesn't seem to work well, but basically there's five EIPs that people seem to be looking at. 86, 96, 98, 101, 140. So 86 is general abstraction. And which has two components to it, one of which basically says if you send a transaction from that, whose signature is zero, then it's assumed to be sent from the zero address. The second, and there would also be like client-side minor logic that says, what was it, if that would like provide some extra conditions for accepting transactions like that, but that's not something we need to have consensus on. So that's like not really any IP. Then the second part of EIP 86 is this rule change for how to generate addresses for contracts. And 96, or sorry, and it seems like there are a few paths with a few different trade-offs and it seems like the one people are most happy with is adding in this kind of new create-off code that follows the new rules. And then figuring out how to deprecate people once safely. Then the EIP 98 basically removes intermediate state routes, which has its pros. It does have a couple of cons and we decided to, like myself and Jeff and whoever else is interested will take it offline and discuss at some points to figure out if it's actually worth it. Then EIP 101, just to skip ahead a bit, is basically BigInt's computation. I originally proposed this and the original rationale basically was that there's at least a few people that need to use RSA and we might as well make it generic and support various kinds of BigInt-based crypto. My current position is that if we're doing this, I think module or exponentiation itself should be enough. So basically don't bother with multiplication and don't bother with addition. My reasoning basically being that addition is probably quick and like of the three, exponentiation is the only one where you actually really might need the optimization. In addition, you can just do fairly easily any VM. Multiplication, you can do any VM. It's quadratic, but like it's still not too bad. Or if you want, you can basically do like, you can convert a multiplication into two modular squareings and use the exponentiation pre-compile for that. So there's like two fairly accessible paths for it. So basically the question is like whether or not to add this. So like the main users would be, I mean, like Oracleize is one example and there's a few others. There's just a lot of at least some cases where people want to like verify existing like cryptography that comes from outside of VRAM and that cryptography happens to be either RSA or something big, something BigInt is your based. Then 100. So this was in response to a vulnerability disclosure bug report made by Sergio Lerner where he pointed out an incentive flaw that basically encourages large mining poles to mine uncles. And the solution is that instead of targeting a fixed block time, we would target a fixed time between block number increments. We would target a fixed time between blocks, including uncles. And there's like a slight formula change. It's like one line of code that'll give us that. Then EIP 140. And I throw it in because I feel like we haven't discussed it enough, but it's interesting, which is Nikolai's idea of basically a throw up code that doesn't just burn all of the gas that's given to a sub goal. That's basically it. And if also, I guess at the same time, I know there's a bunch of stuff that we've discussed over the last like six months of these calls, so maybe there's stuff I missed that's worth bringing up again. So the reversion, the 140 seems to be particularly dangerous where reverting state comes at no price. It does come at some cost because like it doesn't give you 100% of the gas back like it's like the idea is that you would still lose the gas that you spent. But you would, but you would get back the gas that you haven't spent yet. Didn't we already, don't we already have the situation that we have to implement it at no cost because I mean you can have a throw after you run out of gas so it has to be. Yeah, fair enough. The one thing I'm so that might be dangerous with this is that currently we can do some kind of sloppy gas counting when we hit the out of gas. I mean, it's not this is not really an out of gas. So it's an it's a specific opcode. So it might not be too, too difficult to do that. And so, I have to admit, I didn't read the haven't read that proposal. Does it include some kind of error code you can also supply. Quite often. I'm not sure if that proposal has I mean it might make sense to. Let's see, it says details extra things to consider, it will be useful to pass back a return value to be interpreted as an error. This is a nice to have. Yeah, so there's a. So there is a kind of proposed extension to it that would make throw have one arguments that would be like the value that gets that gets pushed back onto the stack. I'll just face the link here. I'm, yeah, I'm happy to implement this. I'm, you know, I'm, I'm supportive, but although like, although, yeah, I would add that if we end up running into a time crunch, then this probably is one of one of the ones that's that that I'd be willing to sacrifice pushing off till it's all serenity. But like, I guess we'll see. I have a quick question to be clear. You had talked before. I'd seen some discussion about having, I think it was either serenity or metropolis and phases, especially the phase in the bigger picked features is that for only serenity or metropolis as well. I think. Hmm. Let me think. I remember talking about serenity and phases. I mean, I remember metropolis being. No, so the time when I broke that I was proposing breaking up metropolis into part one and part two was when we thought that we would do a Dow fork and like if we're going to do or sorry, when we were debated first discussing the idea of not the Dow fork, to fix the DOS issues and I brought up the idea of well, hey, if we're going to hard fork, we might as well knock off a few other items. And we decided not to do too much of that, but like even still actually we did implement a couple of the EIP is that made me fairly happy. So like that was intended to be kind of metropolis a step one if it would be but like at this point it seems like one step is probably. All right, sounds great. Discussing the list of of changes you want to include from a tropical is or is this just a no this is considered at all. No, this is a discussing the possibility of making like which probably is part one and which probably is part two. No, I mean that the list of your piece you gave is that your proposal to include that into metropolis or. Well, no, that was a lot some of them are mine but like some of them aren't so like 140 is from Nikolai but like a lot of like most of them are things that we had already discussed and that I recall us kind of tentatively already agreeing or okay for metropolis. So yeah they are all about metropolis Christian they're all potentially to be included in metropolis pending further discussion. So when my question more aims that is, are we also discussing that, or does this also imply that others are not included or not. So what are there any, look what other EIPs are there that have been discussed that we're not that we're not considering for metropolis. Yeah, I would like to at least have the 58 from a tropical is. Okay. 58 that's the return gas thing right yes. Yes. I think we were all supportive of that. Perhaps, which are you can you repeat it broke up for me. We said that the return gas is probably also part of the tropical is. But in general. So, yeah, I mean, how do we decide what is included in metropolis and the time frame especially so shouldn't we rather discuss that things to be said that that we should have and then if something turns out to be extremely hard to implement then potentially postpone it or and things that are easy to implement to include or I don't know. I think that's a good idea Christian. Is there a way to maybe do point values or something relative to say the difficulty of each EIP that Vitalik's listed out and then the 58 that you just mentioned is that should be done in this call or would be very quick to say, you know, for each client, you know, how fast would it be for you to do this to kind of get an idea. I mean, first of all, I guess the first thing is, and do we have like a just a list of all of these EIP is that we're considering in one place. Is that somewhere in the repo or docs or thread Hudson. I've never seen that document. I don't think that don't think that document exists whether that sounds like a document that you're saying yes we can definitely do that in the PM repository we have a folder called metropolis now and we can also set up an issue so post call I'll set that up. Cool. I mean it doesn't need to be something like a really formal and fancy it basically just needs to be like an issue. Yeah, that would work. I mean theoretically even like a yeah and either pad page would also be fine. If we can find a version of either pad that stays up. Yep, exactly. So there may be even a combination so yeah Christian answer your question. Since we're going to start having these every two weeks that should be something especially for the next agenda to say, you know, everyone, you know between now and the next meeting. See if any of these are going to be too difficult to get done in, you know, X amount of time. So actually speaking of time just because this is something we can probably, you know, decide pretty much today. What would be the approximate time for metropolis now that we know that the ice age is coming. Well, as last time we I would bread enough brush it as we had last time so I would like to have ample time for testing. Good call. So I guess it's more dependent on or I guess what I'm trying to say is we can, you know, figure this out or the minimum stuff. The next core dev meeting if it's in three months or if it's in six months because I think you gave that timeframe right metallic. Yeah, so I think a good strategy for this and obviously I want everyone else's opinion is to kind of come up with a minimum viable metropolis. I guess before or during the next all core dev meeting based on a lot of feedback between now and then for EIPs. And then using that we can say, you know, for testing time and for just general implementation, how long things will take. And then I think it'll just kind of organically come out of that what will be in metropolis. So yeah, would that satisfy your kind of feelings about the testing time, Jeff? Sorry, could you repeat your broke up? Oh, no problem. I think it's my, I think it's my internet connection. I'll just blame you in either way. So I, what I was saying is I think that if we come up between now and then with like a page that just says EIP, you know, time to implement time to test estimate and then give ourselves a ton of time on that. We can safely create a list of EIPs we definitely want to get to before metropolis and then some like maybe one or two stretch goals as far as the EIPs. So yep. Yes, sounds good to me. Okay, so yeah, we'll, we'll, I'll do that post call just kind of start that document sometime today. So yeah, did you have any other EIPs or places to go with the discussion Vitalik? I mean, those were all that I had but then I mean I also wanted to bring up static call but that seems like that's number five on the agenda anyway. Great. Anyone else have metropolis topics before we move on to static call? Okay, great. Then we can move on to anyone. There's another item before static colleges. Oh, yep, you're right. Sorry, I skipped one. Martin, if you could bring up the general state test, I believe that was one that Dimitri wrote. Dimitri, are you in the call? Hello, could you hear me? Yes, I can. Perfect. And you can hear us. Oh, yeah, that's fine. Finally. Yes, definitely. This thing works from my phone. Yeah, so this EIP is one that Dimitri wrote and Martin if you want to start because you're listed as facilitator. I have problems hearing just bad connection maybe. So you suggest me to start discussing general state tests? Oh, I think Martin Hulse-Wende was going to start because he had a, I don't know what direction he was going to start the conversation with. But yeah, both of you could speak on it. But Martin, are you here? Oh, he might be dealing with something right now. So yeah, go ahead Dimitri. If you could just, I have the link in here. It's EIP176, so take it away. You sound like a robot to me. Oh, sorry. Yeah, if you could, you could just start talking about 176. Martin's not on right the second. Okay, so you could hear me well, right? I can hear you just fine. Martin, did you get back on? Yeah, Martin, we can hear you. Sorry. The point was that as a client developer should start implementing the general state test proposal that I mentioned on the EIP. Because we have lots of tests in this. All previous tests are converted into a new general state test. It's basically changing the development. And recently we have added more new tests for state reversion and so on. So we really want to see how other clients are doing with this. What are the results? Okay, so you were saying you wanted feedback from other clients about how they're doing the test? It might be better. Yeah, that might be an offline thing, but yeah, that's a good strategy. And it looks like, yeah, that's an active EIP thread. So if we could just recommend everybody to go to that EIP thread and make comments on it, I think that might move it along a little bit. And it looks like Martin's still having connection problems. Martin, can you hear us now? Yeah, you still sound like a robot. I can barely hear you. Yeah, let's see. Oh, Jeff, can we not hear you anymore? Yeah. Yeah, no, I was just typing to Martin. Ah, got it. Okay. In that case, yeah, we can just have that on pause until Martin gets back. But Dmitry, I think basically you're saying take conversation offline for that EIP. Dmitry, can you hear me? Yes, just barely. What is your question? Maybe you could type it in Skype and then I could phone you. Testing, testing? Yeah, there we go. Yeah, I can hear you. All right. I guess it's a device not too powerful. Yeah, we can just chat, we can text chat then Dmitry. Martin, since you're on now. Can you hear me? Yep, I can hear you. So the reason that I wanted to bring this up was that I wanted some clear go or no go from the client developers if they're okay to move on with the general status. And if they have an objections, please raise them. Otherwise, just say go and we can know that it's on. Yeah, so I was looking at it the other day and I had a few suggestions that I think we should be discussing over. I don't want to discuss them now because it's taking up too much time. I think we should move on to other things. This can definitely be done offline on the all core devs channel. It's just mainly adding some extra fields that might be helpful. And that's all so we can discuss that offline. I definitely think it's a good idea and I think we should be moving forward with this. But I said, I have some suggestions. Great. Okay, yep, we'll do this offline and then next all core dev meeting, we will collect all sentiment by then the EP will probably be done anyway and we can just finalize it next all core dev meeting. So yeah, we can move on from there to static call. So Christian go ahead. Yeah, right. So, this is a proposal about a kind of adding new call up codes again, which restrict the the virtual machine that inside that call and all subcalls to modify the state. And in addition, there might also be an extension that even restricts the quality to read from the state which would make the it a. Yeah, a pure function. I mean, in general, I think there's a lot of benefit of making call a bit more parametric to restrict what colleagues can do. But we have to find a solution so that we don't need a new opcode for every single thing so perhaps you could also combine delegate call and all these these combinations there. I know Gav had an EIP somewhere for a new opcode called interrupt, where the idea would be that they basically would be like a new kind of one call up code to rule them all and it would just have as one of its arguments be a bit field that represents the various flags. Yeah, the problem with with that these flags being an argument is that it's hard to do static analysis on that. And I think it would have better to to move that into an immediate argument or something like that. If we if we go to multiply top codes anyway, then that's a good solution. That's some a good points though I will point out that like static call is implementable with like easy to medium difficulty but if we start going in that direction then the complexity starts racking up. So there's the usual kind of expediency purity tradeoff and static analysis is generally difficult. Anyways, how does one approach make static analysis easier than the other Because with different opcodes or with an immediate arguments you statically know what kind of call it's going to be. And so you can more easily do things like statically verify that particular functions are pure. So so that that's in line that that's not for debugging development that's that's for the essentially for the for the for the validator to be able to optimize validation. Yeah, in validation, valuable kind of verification checking debugging like all those things. So one use case would be these these entry contracts so these these abstract accounts. And if you use a static call there then the minor doesn't have to look what is called the minor kids can immediately see that the status didn't change. Yeah, yeah so so the so the complexity is is is. If we don't know what it is then we may have to have some type of refund mechanism for the for balance gas cost but if we know what it is done just so am I going down the right path there. It's, it's a nice EIP so it sounds like either solution could be discussed in the in the comments. Not necessarily in the comments also just offline over the next one or two weeks. So it looks like that that's going to be brought to 116. And there's more discussion to be had on that and then by the next all core dev meeting will have that as a top agenda item along with metropolis to decide on does that sound good Christian. Great. Okay, so we'll have everyone included in that EIP to look at the next one is Christian with EIP 141 the EVM opcode for invalid instructions and I felt like we talked about this earlier in the call but it might be it might have been something different. This is this is this is not not actually a consensus change but more like a agreement. Solidity would like to change its behavior for reversion. So the, the thing is, we want to distinguish explicit throw from things like arithmetic overflow or array out of bounds access. We want to keep the jump to invalid jump test. And for the other we want to use an embedded opcode. And the question is just, is it safe to assume that we don't break any compatibility by assuming that this opcode 0xEF will always be invalid. And the serpents use a 0xEF but like I'm fine with keeping both of those inaccessible or like always invalid. What's the benefit of the proposal Christian. And basically the but it's like an agreement and lots to have future hard for us that makes some one particular currently invalid opcode do something with the understanding that like programs can safely use that opcode knowing that it's kind of the row. Okay, I get it now. So I mean, I can also just use f e. No. Alex, I think you initially created that yeah piece that right what was the reason to choose EF. Oh, he just says plus one in chat. Let me see if he can talk. Alright, Alex just gave a shout out to the Ethereum Foundation and chat or he was talking about. He might have to be logged into that account to talk. I don't think that's the case. Oh, oh, zero EF is equal to Ethereum Foundation. Oh, nice. Nice. Nice. Okay. So yeah, it sounds like you're like the Ethereum Foundation in French. So take that. Yeah, I mean if you already use FE then I'll see if we have to waste any of codes. Just waiting for Reddit to yell about centralization again if we do that but I'm yeah, that's worth it. Okay, so yeah, it sounds like we will continue that discussion on the EIP. And there's a few key people who have some thoughts on that so any other comments on that from anybody. But I mean, I would like to use that from from now on because it's not a consensus chains. Is everyone fine with keeping FE unimplemented or invalid? No problem. Keeping or keeping invalid? Alex, I think is asking. No, keeping invalid because it's invalid now. Martin is saying that we should use the same as Serpent. Yeah, I think Vitalik mentioned that's how it's already implemented in Serpent, right Vitalik? Yeah, yeah. It looks like we have consensus on that. That's yeah, and that's not even an EIP is it? Let me see. It's an EIP IP improvement proposal. Sounds good. Sounds good. So sorry, just a quick question. What about the static call? We are going to decide that later or are we going to decide later how we're going to do future calls? Is it unclear to me? Not clear to me either. So I mean, you know, we could quickly discuss the implementation details of static call. I don't think we need to move it necessarily to another meeting to just discuss this topic. We can have calling conventions and stuff like that on another call, but I think it is important to discuss static call. Christian, if you don't mind taking that back over again and just outlining it, kind of like Jeff saying, or Jeff, if you want to take it, either one. I mean, no, I mean, I'm happy with a static call to begin with. Got it. But do you prefer it to be a new opcode or not? You know, just apart from that, I mean, shouldn't we be discussing whether we want to have a static call at all? Okay, what's your opinion on that? Like I said, I'm completely fine with having a static call, but I don't know about anyone else. I just wanted consensus from others. So it sounds like that Alex good Christians, good Jeff's good. Can we hear from Java? So perhaps I'm setting all this. This is a basic question and also what about a pure call, which is a pure function that cannot read state apart from the code. Yeah, we are we're following. Oh, hey, Roman. Welcome. I'm here all the time. I'm recording pure recording pure call. One challenge is that, in my opinion, pure call implemented that way would still be not quite pure because the contract contract code is technically mutable because contracts can start existing and they could get decided. The thing that the thing that I would prefer is I have an opcode that I already use in some of in my cast for POCs, which is called call black box, which just like directly takes a piece of code and a piece of data as an argument. And so basically two bite slices. But I think there might be an EIP for for it somewhere. Yeah, I remember. Yes. So you're right. I mean code is part of the state so it can read that. Yeah, I have to think about it. I mean, the thing is that pure map slides nicely into what we're doing with Solidity currently or planning. Yeah, no. So I think I mean what we could do is like I don't think that having it be address based to necessarily has any benefits because like if you haven't take two memory slices and you can always just grab the code if you really want to grab it by call by your ex decode copying it. So it's just all right. I see. Okay. Yeah. So you do a you do read from store. You do read from the state to grab the code and then you execute in the pure way right. Okay, it sounds like. Yeah, I think most people want static calls that is that hitting that right. I think most people want both static call and some kind of pure call or black box call or something in that category. Cool. See if anyone opposed. No, I like to black box idea to slices containing the code and data. And in addition to that, I think having a set of call where you can read but not necessarily right to state would be helpful. Yeah. Okay, so let's get some formal EIP is on that. And again, I'm going to send everybody really soon what the new EIP template is it's very similar to the old one though so as long as you all just kind of follow that it'll be good enough. Okay, I think there already is are some EIP is on that but just yeah kind of digging them up and putting them for the, like maybe in the meeting notes or something so that I can reference this that'd be great. So also we since we have a bunch of you forget is these is this like new EIP format. Still, it's not using issues in the same way anymore is it like is like. Yes. So, and yeah, that's the last topic but I can just run through it really quick. Yeah, how it's how the new EIP processes and it's actually not new it's actually just enforcing kind of how it currently is with a few updates. The template similar. It's going to the template for the EIP is similar it's going to have a section for like plain text. Like when I say plain text I mean like human readable what this EIP is about so someone just like with not as much technical or specific Ethereum technical knowledge can know what the impact of it is or the proposed impact. Additionally, just a few more clarifications in there to avoid issues like we had in the last hard fork with different implementations implementing it different ways. And then also moving it to PRs helps with tracking the changes. So for instance, there's been a few EIPs where changes were discussed in different channels like Skype and then not updated on the main EIP. So then there was some miscommunication there so it's pretty much just to get clarity of communication and to help streamline the process. So the process is when you have an idea, put it in an issue and you can discuss it in the issue. Talk about whatever you want it can be as simple as one line it can be as complex as a whole template like PR style template. And then when you want to actually move your EIP into like a draft status, make a PR for it. Now GitHub allows you to make PRs like within the repo. So you don't even have to, I don't even think you have to clone the whole repo anymore, but a lot of people will be more comfortable doing that. And then there's just a, it's pretty much just kind of how it was before. I think we took out a few of the, we took out a few of the labels so instead of like approved and accepted, there's just accepted now. I'm going to post the link to all of the change discussion and at the very top there is all of the details of the changes. Okay, Nick just corrected me. You do have to clone, but you can do everything through the web interface. And then finally, let's see, there's one more thing. Oh yeah, we changed it to four subtypes. So we've been having a lot of ERCs come through like the token standard. So, and the ENS standard, so we're going to have those version now. So whenever there's an EIP, a subcategory of that can be an ERC and you would have like the token standard version one and then once consensus has been met, you can go ahead and just kind of approve that as, you know, an approved EIP slash ERC. And then when you want to update that you would make a version two. There's also, yeah, the tracks now are core networking interface and ERCs. So yeah, if you just go to that link I sent, oh the things that are going to be most interesting are the future goals, which is having a signaling system using blockchain and GitHub so that you can go in and a smart contract will automatically fill in current EIPs and you can submit votes that are just, you know, plain weighted, not weighted by coins or anything about how you feel about them, like approve or disapprove and we might even have groups set up and things like that. And then something that like a node.green that will check for compliance of EIPs. So I just posted a link to it. So something that looks like that, but for any EIP we discuss cross client compatibility. So yep, just kind of a mouthful of stuff. Again, go to that link and that'll give you all the information you need. So yeah, we just got through static call. We're going through EIP 141, or actually we just did that. Was that finished up Christian or should we go back to that? No, that was finished. Okay, perfect. And then the last, the second to last one difficulty bomb and we already discussed that. So yeah, and then yep, I just went over the new EIP process. So if anyone has comments on the EIP process, it's not final. A core group of people who have been active and wanting to change it and, you know, help out with the changes have been discussing it, but anyone can jump in. Additionally, the list of editors it currently stands is let me pull them up, because this is also kind of an important thing. Right now the editors are myself, Martin, Martin Beze, Vitalik, Jeff, Gav, Roman, Fabian, and Casey D. Trio. So I've talked to most of you guys, but Roman, do you feel fine being an editor on the EIPs still? You were set as one initially, but I'm just kind of checking with all the editors. Yeah, sure. Perfect. Okay, so we'll start getting some communication for that with the kind of the responsibilities. Jeff said he's fine. Vitalik, you're cool staying that. And then I'll talk to Fabian because I don't think he's on the call and I'll talk to Gav and then Casey's good. Okay, so yeah, that's all for the EIPs. Expect that in the next two weeks at the latest. Hopefully it'll happen this week. Well, thanks for coordinating Hudson. I appreciate it. And I also appreciate the works being done and the EIP streamlining process. Very nice. We need it up. Thanks, Jeff. And yeah, actually the Casey and Nick and Greg and a bunch of other people have been helping out. So yeah, we've been having hours of Skype combos. So they should be thanked as well. Good job, guys. All right. So yeah. Thank you. That's all of the... Oh, yeah. So Casey asked, is there a clear statement on point seven for the difficulty bomb? I think if I remember correctly, it was three to six months, depending on certain factors, Vitalik. Yes. Okay. Wonderful. In that case, is there anything else anyone wants to talk about? We're just under an hour and a half, which is perfect. And I think everything's checked off the list. Well, what's the status of swarm, Jeff or Vitalik? Do you know where we... I don't think it's... Yeah. Well, I don't think it's really necessary to talk about that now. There is a swarm room on Gitter. Feel free to ask those questions over there. To be honest, I don't know the exact set as I know it's operating on the test net. And it's semi-functional. But yeah, go ahead and jump into the swarm Gitter room. It's public. Yeah. It's working for me. It has some good... It's had a little bit of hiccups, but it's working pretty well right now from what I can tell. Yeah. I have a question. So if you guys can hear me, can you? I can hear you. Yes. My question is, do we... Is the plan to kind of move forward organically with this, or is someone going to propose an actual plan for the coming six months if it's going to be one fork or two forks and what's going to be included? I think it sounds like the very near-term plan is like after this call for developers to kind of start implementing these... At least the EIP is that we have very clear consensus on and to continue kind of discussing amongst each other to continue to research the path for implementing pairings. And hopefully we'll keep coordinating and within the next one or two weeks or so we'll have a much better idea of kind of what the priority list is. Yeah. So I just made an issue in the project management repository. So I'll fill in kind of the info at the top of there. The main goals of that is going to be deciding definitely what is required for the next hard fork, rough timelines to then finalize timelines hopefully by next all-core dev meeting or as soon as possible, and come up with time estimates for the how long EIPs can take to implement and how long they would take to test on a per-client basis. So I can round up everybody for that. That's not going to be too bad because we're all in the same Gitter channel. So yeah, just posted a link to that to everybody. And so yeah, Martin, did that answer your question? Yeah, perfect. All right, yeah, perfect. So would it be fair to say that the plan is for all-core devs to see what they can implement and what is the single thing so that by the time the difficulty bomb starts, we can do the fourth of what we have? I mean, start to see what you can implement. Then I would even say as soon as possible, once we get kind of informal kid census, then just start going ahead and implementing. As I think, like, given that we do have that, we do have a deadline, I think, trying to kind of pipeline things and just getting to work on the first half and even while getting to kid census on the second half would be quite sensible. So it's more like the reverse deadline, right? We have at some point the bomb kicks in and we want to see how much we can do until then, right? Yeah, and I mean, obviously, what our goal is to give us a lot of padding, a lot of time for testing and for potential issues implementing, especially across the clients with the most, I guess, client or node share. So we'll be working closely on that. And so, yeah, what Vitalik had said, we're going to get to this as soon as possible. Oh, what was that, Jeff? No, sorry, I said something to my girlfriend and I was unaware that I was in mute. Hi, Jeff's girlfriend. She can't hear you. Oh. But I've said hi to you. Oh, thank you. All right, so anything else? Anybody? I just wanted to say that this was a really, really lovely meeting and I'm looking forward to more regular meetings and more structured process. Yes, me too. I think this one was definitely helpful. You get a one on the same page. Yeah. So what we have is, yeah, that's pretty much the meeting just to remind everybody we have, where is it, the first and third Fridays of every month at 1400 UTC. I'll be sending out emails to everybody about that. If I don't have your email, I'll just reach out to you on Gitter and get it. I think I have almost everybody's though. And if I'm missing a client that is significantly built, I guess, or people that should be added to here just ping me and I'll get them included in this. And by the next time we'll have a myriad of options for the calls. I'll try to test some between now and then as well. I know a few people had volunteered to help me test Jitsie. So we might have like a Jitsie server like locally with a lot more power instead of using the public one. Yeah, but also look into discord, please. Someone had mentioned that it has the same issues as Jitsie as far as disconnects. Yeah, I mean we they used to but I think it's been improved and it was Nick that said it. Okay, it's not open source. I don't know that really matter. It's more important to some people than others. We can definitely check. Oh, you know what? Before we go, who cares if this is this audio is presented to the public? Is that something that anyone has a problem with? I'm not doing it yet, but just I'm thinking about that as a way for people to more clearly go back and see what's going on. No problem. Roman, do you have a problem with that Vitalik? No problem. Cool. Yep. So it sounds like if anyone does have a problem, you can PM me privately and we can work through that. But yeah, otherwise I think I'm going to start to release these publicly because that'll make it a lot easier. So we don't have to take as many detailed notes for the community. All right, great. I'm not going to keep you any longer. It's exactly an hour and a half since it started. I'll call everybody and we'll see you on the first Thursday or the first Friday. So that would be the 3rd of February. All right. Cool. Thank you guys. Thanks everybody.