 Well, yeah, I'll just get started on the first bullet point. So yeah, we just went through the EIP overhaul process. What that entails is putting together a new EIP one, so that is already in place. Right now we have it so that you have to go to the issues if you want to discuss your EIP and then once it's kind of formalized and you got everything fleshed out and get some you know community feedback okay I'm here all right so yeah Greg I'm talking about the new EIP process so you go from issue to a PR and with that PR we have a new set of or actually I guess a refined set of template to use on that we're gonna be clearing out all choose so so yeah that's that's kind of in process all the other informations on there if you have an EIP please go to your EIP and convert it to a PR or close out the issue whichever one applies to you so it's a PR already awesome it's been a PR for a month or so yeah so what we're gonna do is slowly work through those either in the all-core dev meetings or using the signaling systems we're building we should probably review meetings so just so that I understand is right so it is basically similar to now just that at some point we will move it to an actual like proper pull request exactly and there's a newer template on there that makes it a little bit easier to digest and with the pull request if you want to update an EIP it makes it easier to go through that process of keeping history of the EIP and is there also a template for the issues so for the issues you can just you can use the PR template if you want a lot of people just go in and say I have an idea so it's it's very unstructured all the issue section is now is a place for people to go and talk about the EIP's and they can use the PR template or not so it's not an eighth until it's an accepted pull request is the important thing and who is then merging them there's a group of eight editors myself Nick Casey Dietrio Gav Roman Vitalik and I believe there might be Greg as well I'm right yeah and then there's like one or two others but I think maybe Christian so yeah the editors go through and once consensus is met we will merge it right now there's kind of a backlog so it's going to be a little bit slow at first but we're working on the Ethereum package manager just because that was already mostly written up by Piper so that's going to go in very soon as an official EIP and then Robert you just joined us yes hello awesome hey nice to meet you and you're I guess gonna represent parody and f-core yeah I guess I guess so cool so yeah how these meetings go down we just go through the agenda which I will paste to you in GitHub or sorry get her and we kind of try to come to consensus amongst our different development groups about what changes are going to happen in the future just kind of have a sync up so any comments you can provide would be great and there'll be plenty of opportunity for that and if you have an agenda item at the end feel free to let us know and we can tag it on okay sure thing so that was the first item the second one is going to be Christian talking about the case not pre-compile so I believe that there might have been some finality on that so Christian if you want to go ahead thanks so I did not convert the issue to pull request yet but I updated the issue description to the pull request template the main changes or yeah yeah the main changes between the last version were that addresses are fixed to oh sorry I clicked on the link and it brought me to the right okay it's basically it's to it's to EIPs and the first one is 196 which is additional scalar multiplication and then 197 I guess which is the the pairing function right okay it's two agenda items they are just incorrectly linked okay then let's talk about CK snark parents first so that's 197 I think the specification did not actually change after a suggestion from Vitalik I simplified the the actual mathematical specification but the semantics have not changed I assigned the address of eight to the pre-compile we settled on two dimensional coordinates for the for curve points and I think that's it so what still needs to be determined is the the gas costs and that's I guess a topic after some of the implementations are finished are there any comments yeah I was wondering a bit about I don't know the full mathematical details but regarding the gas costs is this are these methods easy to to have one type of to estimate the gas and processing based on input or does it vary widely even depending on the actual inputs I guess I mean it's elliptic curve points so I think we can just try random random coordinates or something like this I don't think that it will differ a lot so that the number of points is a factor that that influences the runtime and fine with actually limiting the number of inputs to something like 10 perhaps if we can't find a good asymptotic for that yeah but I think it should be linear in the number of points so that's that's not a big thing and what did you say about you wondering about the mathematical specification what did you mean by that no I didn't mean I just meant that I didn't but I didn't know much about it I was just that that was the basis of my question I didn't know the complexity could be estimated based on inputs or if it was hidden worst worst cases in there you wouldn't then you know the text so I think the telling knows more details about that but I think once you fix the curve then the complexity is more or less fixed because you have this so the main the main computational unit you have is this Miller loop and the number of iterations there is is bounded depending on the actual curve you use okay so it sounds like is there any if there's not any other comments on that it sounds like this is going to go into the process of formalization now there shouldn't be much of an issue with consensus but we might check outside of an all core dev meeting just for the final you know just kind of getting the thumbs up from those people about that does that sound good Christian yep so concerning formalization so you mean converting it into latech oh that I was actually talking about the PR but on the topic of the yellow paper that will need to be something we work out because there's a lot of open pull request in there and right now I know yoichi has been working to kind of clean that up but there's also things that are not updated from spurious dragons so it's kind of a question of do we update the yellow paper who needs to update it and that and that kind of thing but until then I guess we would be using the EIPs is our more or less our spec until the yellow papers updated by the way do we have pre-compiled contracts in the yellow paper are they specified there yes they're specified at least the first five of them I don't know about the more ones okay great so yeah that part is complete let's see all right so yeah that's for both item two and three this next one is metropolis so what I'm gonna do is so the talax signing on in the next couple minutes yeah I thought we I thought the the elliptic curve operations were a different item oh you're right I was grouping them together I need more sleep yeah go ahead and go go on with that Christian so I'm not sure so yeah not sure if much has to be said here yeah I mean the encoding is basically the same encoding of curve points yeah I think I got resolved last meeting we were just gonna get like a final kind of thing from parody team and I think Arkady joined can you hear us Arkady yep I'm here awesome welcome okay so so here are multiplicators a bit more complicated with regards to guest costs but I guess it can be dealt in a very similar way to to exponentiation so that should not be a big problem yes I see the progress in implementations there I've seen that to go Ethereum started yeah I started a representation I didn't I didn't get much further than just to feel the elements but okay and for parity is the plan to just use an external library for what exactly you see if I yeah let the operations and and yeah also pairing yeah we'll just use library there is a number to choose from just pick okay okay I think we can conclude these two items great great and then Martin and chat talked about how one of the items is now it went from like 140 to 196 I think the IP numbers are generally gonna stay the same as the issue number unless the author wants to do it otherwise so it kind of goes into flux so if there's a weird PR number just look for the reference to the issue number so yeah next on the agenda is a city metropolis so this is a big one so the talax gonna join soon and facilitate a lot of this Christian until the talent gets here if you could just kind of lead this and Nick to know damn all right cut out anyone else still here yeah yeah it's him when so I'm sorry I just Christian question about 196 I'm fully aware that we probably want to do 1 9 1 9 7 when did we discuss 1 9 6 I don't remember this for many of the previous calls that we've had oh yeah I thought we discussed 1 and 6 also in the previous call perhaps you you more or less combined it with 1 1 and 7 the thing is that that for these case the case marks you also need elliptic curve multiplication of points otherwise it's not official enough and it's yeah it's basically the same operations on the same curve I mean when you when you implement the when you implement the pairing function you also need that anyway I guess it's okay all right yeah all right so these these methods are you will need them anyway for the pairing good yes all right and it's also on the same curve so right cool okay thanks so Nick do you want to take over yes shall we press on to the next item which was so we just covered you like to shouldn't metropolis associated eeps I guess is Christian here because for talent isn't so we don't have either of the facilitators yeah sorry in that case do you want to take this away sure yeah okay sorry so eep 5 8 between the last meeting and this meeting we noticed that so yeah everyone is aware of the proposal a and proposal b where proposal a says charge memory enlargement for return value to the caller where proposal b is charge memory enlargement to the call lead to the remaining gas of the call eep and we noticed that this might break existing contracts when they call into the the identity precompile because the gas costs for the identity precompile are quite easy to calculate and thus solidity generates code or generated code where the the amount of gas was was exactly specified and if we now change it to make the the call eep pay for enlarging the memory then there won't be enough gas to do that so basically the the compromise proposal was to keep the old semantics unless the size of the return area specified has a special value which could be 2 to the 256 minus 1 or 2 to the 64 minus 1 or something like that and only in that case apply the special rules where memory is enlarge twice and the enlargement for the return value is charged to the call the what are the opinions on that proposal what's the advantage of all of the sova just charging the caller the whole time sorry the caller the whole time the advantage is that the caller does not know in advance how large the return value will be but they they specified an upper bound didn't they ah sorry so you what you just said was basically proposal a is that correct effectively yeah well it's like big is getting more complicated so the advantage of proposal b over proposal a is that you know for a fact whether the call opcode will fail or not before you execute the the actual call and I mean in a way this also kind of protects the caller because if the caller does not specify an effective upper bound so just a gigantic value then the callee can make the outer call fail by making you out of gas but then isn't that easily solved if the caller just specifies a maximum gas that is below sorry maximum memory that won't consume all of their gas that is hard to come up with true because it's quadratic yeah getting into all sorts of each cases with sometimes charged to caller and sometimes charged to callee and so on for b seems a real problem though why because it significantly complicates the PM and the proposal and introduces more potential for eras it makes it out as a reason about basically sure I mean yeah the proper way to do this would to would be to provide a return something like something like a call data but for return data but I think we'll pass that so the only way to fix is is one of these problems these methods I guess well could we not do that actually I mean if we just said that return data always gives you you know return data and return data then let you access all the return data and the amount of memory you provide in the call up code it'll fill up to that much then new code could simply set that to zero all the time and use return data yeah I mean so you mean just like call data land and call data copy add up codes for return data land and return data copy yes and the the call up code would remain would continue to function the same way as previously except that you could also fetch return data through those new op codes and if return area is too small to so yeah basically it writes whatever it can up to the limit of the return area and then that's it and it would avoid this you know the memory accounting issue what is the model for E wasm in that area someone from E wasm here great I'm not an E wasm person I keep it I do keep an eye on it could you state the question more precisely I might be able to answer it how is the interface for function calls in in E wasm how do you pass input data and how to you be retrieved return data I'm I'm not really sure no I'm not really sure okay where's Michael he's not here okay once it gets you know into the EVM it looks the same but how they make that happen I'm not sure hello Vitalik hi everyone sorry bum laid we were just discussing okay yet another proposal yeah so I think we need to have yet another proposal for this one and we move on to to the next team while we better discuss 5A perhaps opinion from Vitalik hold on so why do we need a new proposal so the proposal would be to add basically return size and return copy in a similar way as we have call data and call that a copy the reasoning being that counting for return values is turned out to be more complicated than expected with the current proposal what on so what would be a return return what would the return size a return copy of course do so return size would tell you the total amount of data that the most recently called contract tried to return and turned out a copy would copy the specified segment of that into the specified signal memory and the call up code would continue to operate as as it does already so if you're writing new code that expected a variable return size you just say return size 0 or whatever suits and then get data through the new outputs okay this just sounds like way over complicated to me check out the recent discussion on 5 about gas okay because that also turns out to be more complicated issue issue 5 yes sorry issue if you can I take it in the notes as 5 slash 8 okay well what what next proposing seems quite doesn't seem to be so complicated let's I think Christian's right we should take this offline and discusses amongst those of us interested in and it's rather than try and resolve it here yeah okay so I guess that brings us to 86 proposed initial abstraction changes from a topless yes so the basic idea I think as well I think we've probably already mentioned in the call as a few times is that we allow a new type of transaction where if the signature is equal to 0 0 0 then that transaction gets treated as valid and the sender васous assumes to be to the 1 6 to minus one which is like 0x f if if F F F F F F F F so and then there's also two now the basic reasoning behind this is so that you can use this as a kind of a type of transaction where the what's meant to be the account instead actually as the destination of the transaction so the ideas of the transaction would go to an account and that accounts would actually be in realistic use cases a forwarding contract, which would basically check this, the transaction data for a signature. And if everything passes, then it would either pass the message along or in some cases do something, do other things. And I mean, this has a few goals. One of those goals is to kind of abstract away account security, one of them is to abstract away, at least partially abstract away nonces. A third one is to allow contracts to pay for gas. So in order for this to work well, there are kind of three things, or as we discovered in the thread four things that would needs to be eventually done in parallel. So two of them are items two and three in the IP, and what they do is they basically switch the way that contract addresses their determined from being based on sender and nonce to being based on the code and the sender. And the purpose is basically so that you can send to accounts before those accounts exist. And because that's like what you can do with any regular theory of address. So, and the idea would be that you would calculate yourself what the address would be with that particular piece of code and people could send ether to it or do whatever or send whatever other tokens to it. And whenever you want to kind of start using that account you can by basically creating, sending a contract creation transaction which creates that particular account. And the only kind of, the only account that you can create at that particular address is an account that has that exact same piece of code. Now, for backwards compatibility purposes, like this was debated in a previous discussion and like previous calls and people seem to most in favor of basically creating a new op code, which can be, I mean, I use create P2SH but you can rename it still like create what, create with code address or whatever. And that would basically apply the same principle to a contract creation transactions. Now, there's in order for this, so that's in protocol. Then there's also extra protocol stuff. The nice thing about the extra protocol stuff is that it's not critical, it's not consensus and it's not critical path. And so we can theoretically implement it like a month or two after the hard fork and that'll be fine. And that basically is logic in the minor and logic in any know the dust transaction propagation that would basically scan for specific, like come up with a set of rules that say if this transaction passes at least one of these rules, then it can be either it can be propagated or it can be included. And like the rules, one simple rule as was described in the comments would be to check for a red gasp that would basically say this account, this transaction goes to a particular type of account which is guaranteed to pay at least some fee to the minor. Yeah, that's the latter sound definitely reasonable. I've already partially implemented this change and go. Apart from the mining strategies and transaction relaying strategy. So I have a question, sorry. How exactly you protect the attackers from kill all the budget of this contract? Attackers from doing what with the contracts, sorry? Just trying to spend all the money that are there for paying for good transactions, just send transactions. Okay, so one important point is that the contract only pays gas after it determines that it's the signature is valid. So if you just send it junk data, then it's just not gonna do anything. Yeah, but the signature is also all zero, right? Yeah, exactly. So yeah, so I- No, it's the signature provided through the call data. So it's not the signature and the transaction itself. So you would pass in... So the transaction data would contain the actual signature and you validate the signature within the contract itself. That's basically the idea. But basically you could still then spam the network of invalid transactions and imminent signatures, right? So- Yes, but no minor would be stopped. But you would have to start process already. So the idea is that no minor would be stupid enough to include transactions that don't pay them and by default, until we start implementing strategies and minors, they're not gonna mind any of these transactions anyway. I mean, to be clear, at present, attackers can make nodes to work by validating the signature of the transaction. So I think the idea is that the cost of validating one of these would be roughly on par with the current signature validation. It's just that now it can be used as specified. But in this case, they would have to spin up the EVM first to execute this contract, the contract would stop at this point, throw and that's it. Yeah, so we might have to increase the transaction fee proportionally. Although that doesn't really help. Currently, if the regular expression is strict enough, we don't actually have to run the EVM. We can also just do a, yeah, basically what we do with pre-compose. But it's hard to do a fast path effectively and say, oh, I know what that contract does. I'll compute it myself. Yeah. Yeah. Sorry, I still miss it. Like what is the basic principle that we use to identify addresses that we should pay for them and others that we are not going to pay for them? What do you mean? Like you get the transaction, right? You identify it was sent by some address and now you know that you have to pay for that or you don't have to pay for that. Okay, hold on. So who is it? Who is you? Are you a minor or are you a sender or are you a receiver? Yeah, you are a minor. You are a minor and you show on the study. Okay, you're a minor. You receive an EAP-86 transaction and that EAP-86 transaction has some two address, right? So what you would do is you would basically run a Regex on the code of the two address and you would determine whether or not it matches what one particular preset pattern that would determine that it's kind of safe and that transaction is actually going to pay you a particular fee. So you also have to check the balance of that contract, right? Yes. So you have to check the balance of that contract against the max guess that is also specified as part of the check. I didn't think you would necessarily have to do that if you're sure that it will execute quickly and give you an answer because it might be quicker just to ask the contract. Oh, so sorry. So if I'm now in the head of the facilitator of this type of contract, I should specify Regex for all contacts. Sorry, for all addresses I'm going to pay for? No, no, no. So the Regex is a minor strategy rule, right? So the idea is that would be like at some point after the fork, you would release a version of them or anyone who runs a client that gets used by miners would add in like at least one or two Regexs that would, and these would basically identify pieces of code that are kind of okay for the, likely to be profitable for the miner to include. And I cannot fake this Regex if I'm the attacker. If I'm the attacker and I want to take advantage of some budget that is saved there for some addresses to be paid, I cannot fake the trade or imitate the right Regex to be paid. No. No, so the Regex would be strict enough such that you can prove that any code that matches it would be code that basically if the account has enough money to pay for it and if the signature is valid, then the transaction would actually take money out of that account and give that money to the miner. Sorry, one more question. So we are talking about Regex of the code inside the smart contract? Of the code inside the, of the code of the two address. So but the regular expression itself is stored in the code of the client. Yes. And it can only be changed with a software upgrade basically or it will only be changed. So I have some sort of proposition to maybe add to this CIP and then tell me if it's reasonable. For example, addresses that are not identified by this Regex, but they are there, they have a value. So it's very hard to attack with them, if the value is large enough. So maybe these addresses can be also passed into the contract and it can be valuable in some very famous cases. So I think the important thing to keep in mind is that once EIP AD6 is implemented, like we can definitely keep on coming up with more and more Regex, capture more and more classes of contracts that are safer minors to include. And minors are going to be, are free to kind of add new Regex laterally. And, you know, they, Sorry. So it's not just on the address code. It's on any field of the transaction. Okay. So basically, so the rule that a miner would use to determine whether or not it includes a transaction is a function that takes the following inputs. One input is the code of the contract of the two address. Another input is the balance of the two address to make sure it has enough money. And the third input is the data of the transaction. And the reason it needs the data of the transaction is so that it can tell whether or not the fee is high enough and whether or not the signature is valid. Now, theoretically, of course, you could, you could have, like these rules could potentially be like arbitrary, quickly computable functions on those three pieces of data. Well, sounds interesting. Okay. I guess we should, you know, make this common thread on this EIP more active. I guess these questions are, it's still a little bit, you know, shaky for me, but it just in details, I don't want to take all the time of everybody, so I will pass on, you know, if you ask questions on the thread, just take a look there, okay. Okay, then. Perhaps one thing I think to discuss here is, is there a good strategy to test this? How would we test this? Yeah, that's my question. Do we necessarily, hmm. As we do usually, we just implement this and wait somebody is going to attack it. Well, no, because the important thing is, right, that like when the EIP, when the hard fork is implemented, initially none of these reg apps are going to be implemented, right? So initially the only, like basically, okay, theoretically a malicious miner could include one of these transactions, but it would just be processed according to the consensus rules and we use the same, like the same state test methodology that we've used for two years and it shouldn't really be a big issue, right? Like it's basically just a fairly small extension to the signature scheme. The, So anyone, nobody would relay these transactions anywhere and like Vitalik said, if somebody include, if a miner includes each transaction, then so be it. Yeah. Now, I mean, in terms of actually testing these expressions, one thing that we could do later on is that once the EIP is at least implemented, once the fork is done on the test and on the main net, then on the test net, we can probably start letting some clients and have turned some of these reg apps excellent and that will be a separate process. So it's important to know that these reg apps are also being used for relaying and not just as a mining strategy. Yes. So what I'm trying to say is it will be hard to attack, especially when we just roll out this hard fork. Yeah. Yeah. So like the, in general, right? The kinds of attack classes we have to worry about are basically like one of them is consensus failure and this is fairly simple for my consensus standpoint. The other one is like network propagation and various kinds of transaction doses and at least initially, there aren't going to be any reg apps and so there's not going to be transaction propagation issues and we'll be able to kind of loosen that over time on whatever schedule is necessary. So, you know, apart from relaying and mining strategy, can we say that this proposal has been accepted? Accepted as in, first of all, that we would like to have it in a hard fork and second, do we want to have it in metropolis? I think it's reasonable to call it accepted. I defer to others whether we can include metropolis. Yeah. I say, I mean, I personally say this is one of the, probably one of the higher, my preference would be to try to put it into metropolis and one of the reasons why I say this is just because of complementarity with the ZKStark applications. And alongside, it's also one that just has a purely kind of high trade off of value to implementation cost. Personally, I would much rather, if we have to start putting things on the shopping block, I'd much rather purge things like the revert off-code, but that's my personal opinion. Are there any objections from dev team leads or members to implementing this in time for metropolis? What is in time for metropolis? I wasn't aware we had a concrete date. Well, let me say, are there any objections to implementing it in the next fork from the people who are in charge of figuring out what their teams can do? And in the absence of that, I think it'd be fair to say that this is tentatively on the next fork. Do you agree? Yeah. Okay. So I guess this needs to be put in a pull request now so that we can actually accept it and rotate it. I will do that. Okay. Next one was, where are we? Sorry. I still have a question. How does AD6 work with the CIP-155? Replay protection? Replay protection? So it's a question like, will EIP-86 transactions be replay protected? Like, the two are kind of mutually exclusive with each other. I'm inclined to say that by default I don't see any risks. Well, actually by default there's not going to be risks because like the other blockchains aren't going to, or like the other if you're in instantiations aren't going to immediately implement this. I mean, the one thing that we could bring in is the chain ID parameterization. So, if we want to... I actually assumed that we actually put the chain ID into the V and that V being zero would be after having derived the chain ID. Okay. In that case, that's, yeah, that's fair. So we could, basically instead of making it be 0, 0, 0, what would be just be like either chain ID 0, 0 or chain ID times 2, 0, 0. That seems like trivial enough and I can just put that into the PR. So, and to be clear, intra-chain replay attacks are the responsibility of the verification function. Correct. So that's something perhaps that should be talked a bit more about in the issue. So, I mean, with that abstraction, we can't have an ordering of transaction anymore because if, I mean, the contract can check the nonce, but then the transaction will be executed, it just won't have any effect, but it will consume gas. So, you can't basically, you can't put out a queue of transactions that will be then executed in order, which is probably also a good thing because it consumes resources in the miners and clients that aren't paid for, right? Right. I mean, that sounds highly dependent on miner strategy. It's like, you could potentially have like miners have a regex that checks for a specific type of account but has a non-scheme in which case you can keep an order or you could have a regex for some different non-scheme that might not require an order or you might have a regex for some UTXO scheme. So, it's like in the longer term, it seems situation dependent. Sure, but any miner can include transactions with the future nonce and that will be accepted by all clients. Correct. So, from the point of view of kind of relaying information about the effect of transactions, the two new things would be that number one, theoretically a transaction can be included twice. And so, you'd have to look at, I mean, this is basically how to look at all, you'd have to make sure that the transaction emitted a log if you wanted to check that it actually did something. All right, but that's something I actually even didn't consider. So, by just taking an old transaction, you can rob anyone. Is that correct? No, no, you can't rob anyone. Why not? Because if, like, there is still going to be, like any sane actor is still going to have some kind of non-scheme or some alternative inside of their contract. True, even if you have a non-scheme, you have to pay for the gas that checks the nonce. Ah, but the transaction is not going to, the transaction or the account code is not going to pay for the gas until the nonce is correct. So, if a miner includes it, then the miner is not going to be paid anything. The gas price will be zero. All right, so the insiders that are there in your code will break early and don't pay. Yeah, right. Exactly. I see, yeah. So, guys, sorry to interrupt, I need to leave now. Peter and Nick are both from the call, so they'll further represent the growth team. All right, see you. See you. So, can we move on to 36, putting block hatches and state routes into the state? Yes. All right, you want to take that again? Yeah, so basically the reason why I, well, there's two reasons why I came up with this. One reason is as part of abstracting and simplifying the protocol, I wanted to move to, basically move away from having any kind of implicit state except for state that's actually reflected in part of the state route. So that the state transition function actually has, take a state, add a transaction and get a new state without also having some other state that we don't actually call the state. And right now, the last 256 block hatches in some sense are kind of part of this phantom state. And this ends up like actually increasing implementation complexity. And it's also kind of limited because it's, there are use cases for checking block hatches way further back than 256 blocks. But if we were to try and stretch it much further back then it would require even more infrastructure in order to be able to actually fetch these hashes quickly enough. So the intention here basically is that we would store some number of block hatches in the state. And the block hash op code would be kind of redirected to read this and basically look at what the contract says. And at the same time the contract that stores these state routes, or sorry, these block hatches would also have a function. So the goal would be that we would try and like nudge people to work to use this function to access the block hatches instead of using the block hash op code. The second part of this is that would make state routes accessible just as block hatches are. The thinking here basically is that this would allow it's more intended as a longer term feature in order to allow, in order for things like Casper or future changes to the consensus algorithm be more capable of kind of evaluating things from inside of the EVM. But it's also something like some applications might decide that they could benefit from. And it's fairly relatively easy to implement. So the idea is that basically there would be a parallel mechanism that does the exact same thing the state routes as is already done with block hatches. I hear if nothing else allows contracts to very easily produce proofs of previous states. Right, sorry. And the other main important benefit here is for light clients. So right now basically in order for light clients to actually properly have the full light client security, it technically still has to validate the entire chain. But because with this mechanism, you would have an automatic kind of mechanism by which blocks would directly points to blocks that are like 50,000 blocks before them. This would allow light clients to kind of verify a partial chain that's gonna skip 10,000 blocks at a time. And you'd basically be able to have like potentially even higher sinking efficiency than the existing guess light clients. And at the same time kind of base the full chains worth of proof of work security without checkpoints. Yes, so one question. Is there a plan to eventually extend this contract to store all state routes or all block hatches? Okay, so this gets a bit more intricate. So there's a bit of a trade off here because like you could potentially store every state route and every block hash and that would actually technically be the easiest thing to code. But that would also lead to like a lot of state growth. So in a block for, or sorry, in a year right now, for example, there are going to be at least at about 2.2 million blocks. 2.2 million blocks times 32 bytes gets you to about 70 megabytes. And then that times an overhead factor of two and then that times another two for block hashes and state routes would get you to 280 megabytes of state growth a year. So that's like it's a bit overkill. Now, if we want to go back further, then I actually did, this hasn't been updated yet, but I do have a mechanism which kind of doesn't much better. And the idea basically is that you would store the last two, you would have one mechanism that stores the last 256 blocks. Then you would have another mechanism that stores the last six, five, every 256 block for the last 256 blocks. And then you would have a mechanism that stores every 256 square block for the last up to 256 cubed and so forth. So the idea would be that you would kind of have several copies of the same mechanism except they would have kind of different levels of frequency and at the same time go further back. So like individual block hashes would only be accessible within a fairly short frame, but if you're willing to restrict yourself to block numbers that are specific multiple, then you could go back much further. So theoretically it's actually not that much more difficult to code up, but this would actually allow you to kind of basically hop from any block to any other block in the blockchain and logarithmic time. I see, okay, but that's not the plan for now. Right, I mean like if needed, I could always just write up any IP for that just to let people can see kind of how easy or how complex it is. Well actually from an EIP standpoints, the two are equal in complexity because the goal would be that from the point of view of consensus code, what you would actually be doing is you would be doing a call to a contract and it would be contract code that's running the logic and the contracts code would only need to be written once. Okay, and then I have one more question which was you spoke about like a very fast sort of initial sync mechanism where we would be able to just go backwards very quickly by skipping the whole batch that's included in storage. But if we're starting from some header which is entirely disconnected from the genesis, then an attacker could just put in fake block ashes and fake state routes. We still have to walk backwards and verify the proof of work for all of those individual blocks to the genesis. Actually, so for this to work well, basically you would actually need to have a somewhat different role. You would need to have a block points directly to ancestors that just accidentally end up satisfying a much higher proof of work threshold. The idea would be that the probabilistic chain would end up being almost as hard to falsify or almost as hard to make a fake copy of as creating an entire fake chain. Because if you imagine if you see a block where that block satisfies a difficulty threshold a thousand times higher than normal just by random chance, then from a proof of work standpoint it's worth a thousand times as much as a regular block. So the goal would be that you would kind of try and find a chain containing all of the high, high difficulty blocks. And you would use that as kind of probabilistic proof to show this is a chain that actually had a lot of people doing stuff on it. Interesting. So it's sort of we find the keystone blocks that occur by coincidence. Exactly, yeah. Okay, yes, that sounds pretty reasonable. Yeah, the way that I'd even see it is I think you might only need to prove the correctness of like maybe 10 or 20 keystone blocks. So basically the algorithm on the server side would be step one, scan through the entire chain. Step two, find the 10 or 20 blocks that satisfy a difficulty threshold a hundred times, a hundred thousand times higher than normal. Then step three, use this kind of block hash linking mechanism to prove a hash link path from each one of these super blocks to the previous. And then you would just send it off as a proof to a light client. And the whole thing would be maybe like five or 10 kilobytes along. And the light, well, fine, maybe like 10 to 50 kilobytes. And the light client would be able to just kind of blaze through it, probably in a few seconds. Is there any for that proposal? It's, I can, I haven't written it up so far because it's not consensus, or at least like it's not based on consensus but I can also assign myself the task of doing that. Okay. Showing move on to the next one on the agenda which is the 100 change difficulty adjustment to target mean block time, including angles. Yes. So this was originally posted by a response to a bug that was uncovered by Sierra deal learner, which is basically the uncle mining incentive issue. And the idea here is that because right now the block time targets one unit of height growth per 14.3 seconds, it's like theoretically a malicious cartel of miners that wanted to maximize its own revenue would actually have the incentive to make three blocks at every height level. And that way instead of earning and then just include each other as uncles. And that way instead of earning five ether for 14.3 seconds as normal, it would end up earning something like 14 ether every three seconds. And now that's the case if you have a perfect cartel, but if you have even a single miner, a single mining pool that has more than about 20% of the hash power then you actually have incentives to do a kind of weaker version of the strategy to increase revenue. So the solution here basically is that to make a tweak to the difficulty adjustment rule so that instead of targeting one block height increase per 14.3 seconds, it basically instead ends up targeting one block header per something about 13 seconds, including uncles. Now there's a difference between version one A and version one B. And version one B basically treats blocks with one uncle and blocks with two uncles as being the same thing. And even though this technically does slightly weaken incentive compatibility, but even still you get about maybe 75% of the benefit. But the nice thing about this is that the challenge with treating one uncle and two uncles as being separate things is that you can't extract that information from the block header because in the block header, you just get the hash of the uncles. But from the block header, you definitely can tell the difference between one header and zero headers because zero headers just would be represented as the hash of the RLP empty list. And so that's something you can trivially check in the block header. So the idea with one B would basically be that you would be the block difficulty targeting rule would target a variable, which is basically the one kind of unit per 13 seconds where the unit is one per block and two per block that contains either one or two uncles. I mean, personally, this seems reasonably uncontroversial. It's an obvious fix and it improves things. Does anyone have any objections to it being a metropolis fix? Strong preference towards the version which simply relies on the block headers. I think difficult calculations relying on block bodies is a pretty strong change. Yes. So all opposed to one B passed by, yeah, I need to gavel. Yeah. But. Thing, yep. All right. And we didn't actually make an actual decision on 96. I mean, it sounds as though the decision is that people want me to kind of write up the, basically write up the version that kind of goes back further in history with decreasing frequencies and write up the EIP for the yellow line algorithm. And then discuss it again next time around. Okay. You're happy to do that? Yep. All right, cool. In that case, the next one is 196 and 197 pairings. There's also a missing, actually, don't ever mind. I thought 101 was missing, but then I remembered that 101 was superseded by 198. So all good. Yeah, pairings, Christian, you're around. So we already talked about that in the very beginning? Mm-hmm. Yes. So, something else? So, V wasn't there, but I guess the consensus was, yes, these all seem okay, wasn't it? I think so, yeah. Okay. I am happy to provide a number theory tech support to anyone trying to implement this and having problems that you're stating how it works. I suspect that will be appreciated. I've been telling that there was a question about the expected resource consumption, I guess for the pairing, it should be linear in the number of, yeah, pairings. Yeah, like I think the resource consumption should be A plus B times N, where A is a constant or N be our constants and N is the number of arguments that get multiplied up. Does it make any sense to limit the number of pairings or not really? I'd say no. I mean, at least I don't see any reason why. It's not just time, right? It's not that some of the numbers need a lot of memory or something like that. Yeah, no. No. Good. And the elliptic curve, scalar multiplication that is similar to EXP, right? What do you mean similar to EXP? The gas cost will probably be used. The gas cost for elliptic curve stuff should just be constants because we're sticking to one curve. Scalar multiplication. Oh, sorry, scalar multiplication. No, that should also be a constant. Oh, I see, because what? So my opinion is that I don't really see many use cases in practice for scalars where the expected absolute value of the scalars much less than two of the 253. So I just say make it a constant that's dependent on the maximum. Okay. Like, what's the last time that anyone's ever multiplied an elliptic curve points by 479, right? Like it's always a random 256 bit number. Yeah. I mean, yeah. Okay, inversion squaring that might be useful. That could be cheaper. But yeah, it's probably dominated by the cost for the call anyway, so. Yeah. Okay. By the way, speaking of costs for calls, can I just make a quick poll on the level of support for any EIP that would reduce the cost of calls in this specific case that the destination is a pre-compiled from 700 back down to 40? I think that would be excellent. That cost increases has caused significant problems, I think, for that sort of stuff. Yeah, I think I would support that too. Okay. So 198, begin to mod X. Yes. So the goal here is fairly simple. It's just modular exponentiation of big numbers. And so basically the data would be an encoding of three numbers. Well, the encoding would be very similar to the ABI, where you just have three lengths followed by the three actual values. And although it would be a kind of less strict, it would just expect a length followed by the concatenated byte arrays and it would return the base to the power exponent module or the modulus. There's a couple of edge cases. So one of those edge cases is what do you do if the modulus is zero? And my opinion is to throw. The second edge case is like, how do you actually figure out the gas costs? And we spent a bit of time arguing and since the last time the formula was slightly updated so that basically it's the floor of the max of the length of the modulus and the length of the base, or well, basically take the maximum of the length of the modulus and the length of the base, square that and multiply that by the length of the exponent with a minimum of one. It is slightly more complex than it was before, but this removes kind of two risks where one is situations where the base is much larger than the modulus and the second is a situation where the exponent is zero. So situations where the exponent is zero basically are gonna return one in all cases except to those cases where the modulus is zero in which case it throws. Yeah, I mean, that's basically all there is to it. The rationale is to support both RSA and in general any kind of big number of cryptography. What about Alex's comment on the effect that 32 bits ought to be enough for anyone? To the effect that what? As that the length fields don't need to be 32 bytes each. Hold on. Or like 32 bits. I'm inclined to say making the length field 32 bytes instead of 32 bits basically because that's the way that the existing ABI works and there's no reason not to stick to that. And I would even argue making it 32 bits would be more annoying because it's actually more difficult to construct 32 bits in EVM than it is to construct 32. Or it's more complex to pack 32 bits than it is to pack 32 bytes. So I'm inclined to kind of stick to ABI style. I intend to change that. It probably won't be in time. Mm-hmm. Okay. Well, any objections? All right. I guess move to make that part of Metropolis as well then. I mean, it seems like an obvious synergy with custom signature algorithms. Okay. In which case that brings us to 206, the revert opcode and 207 encoding a revert opcode. Yes. So this is basically the kind of updated version of EIP 140, whereas I understand the main changes that instead of the revert, instead of like it providing an error code as a stack argument, it would provide error information encoded in bytes that would be returned in the same way that they're called data or that regular return output would be returned. That's more or less the idea, although there's some disagreement in the over whether or not call should return this in the return data area if the call fails or whether it should be punted for a future opcode. I'm personally familiar with the opinion that it should return it. Wait a minute, can you just repeat that? So there's some discussion in the whether or not the call opcode should return the value from revert if the call fails or whether that should be revert to continue. So you mean the value that gets pushed onto the stack if the revert fails? Yes, well, the memory area specified by the values on the stack. What do you mean the memory is specified by the values on the stack? So as I understand one night at 206, the idea is that the revert opcode would have the same as the return opcode. Yes, right. So what's the answer to that? Well, so the discussion is whether the call opcode should populate memory with the data returned by revert or whether it should be punted to some future opcode for accessing revert. Okay, my instinct is to work making call do it directly. My arguments are that number one, it provides a nice symmetry appear to between return and revert. And the other arguments would be that it avoids introducing you opcodes and particularly it avoids introducing kind of new forms of temporary stage. But that's my instinct. Yeah, personally I'm inclined to agree. I mean, the problem raised is that call doesn't provide a good way to access the length of the return data, but at least in my mind that's also going on to whether it returns from revert as well. So it's a problem we already have and we already need to fix. So yeah, if we add return data size, that's a good pair to add, right? Yes. So return data size and return data copy in that case would also work on the revert result. Right. Yeah, so like the, I guess those would also be opcodes that ends up kind of introducing a weird new kind of state of runtime state. So are you saying that the thing that you have to basically keep the return data alive until the next call, is that what you're saying? Basically, yeah. So can anyone think of a problem with gas here? I mean, the memory was paid for by the callee. So I don't think that's the problem, but are there any other complications? Okay, so basically what happens if the callee returns like 50,000 bytes worth of data, then that's basically a kind of second memory already in some sense. It's memory that was already, it doesn't increase the... Right, it's memory that already gets paid for inside the callee. Yeah, I mean, it doesn't seem like there's a needle from that standpoint. So what you have to do is you have to do another copy probably because you won't keep the full memory area of the callee alive, just the return parts. You have to copy that somewhere. I mean, you could keep the full memory area through the callee alive. You could, yeah. But would everyone agree that how we handled that is orthogonal with whether call returns with that data? Yeah. I mean, my own instinct is that the seed isn't, like discussion isn't settled enough yet to say definitely include it as it's in metropolis. Okay. I don't know what other people think. So we're already using the opcode visibility or just about to use with the idea that as long as it's an invalid opcode, it's unassigned, it will revert, so which is fine. And once it gets implemented, it doesn't waste any data. Yes. That's fair enough. Yeah. Okay. So how about I will commit to like summarizing our discussion here on that EAP and sequences there. So we're happy with that. Okay. And then the other one was 207, which is how contracts should encode revert data. Yeah. It lists use the facilitative italic. I don't know whether you had something else to say. Let's see. I mean, I already gave my comments, which is that I think just for symmetry purposes, we should like just use ABI. Yeah. Yeah. It seems that seems a lot more relevant if we're definitely returning it from call as well, because it's even going into the same memory area. I mean, I believe the original proposal was when the expectation was that the main thing accessing this would be off-chain debugging tools, not necessarily anything on-chain. And I would argue that off-chain debugging tools can don't necessarily even need like anything that gets returned to the revert opcode because like the thing you could theoretically do is you could just push and pop a bunch of dummy variables. And that's something, yeah. Anyone else want to comment? And then the last item on the agenda is static call one-month-six follow-up question facilitating. Are you still there, Christian? Yes. I think not much changed on that. Yeah. There is a pure call pull request. Is that... Yes. Same thing? No. So the difference is that static calls can read state but they can't write. Pure calls cannot read state and they cannot write state. Yeah, I see. What number is the pure call? All right, 195, I think. Yep. Okay. Yeah. So for pure calls, the main use cases are, I mean, well, for static call, the use cases basically are that any constant function where just you want to very easily provide an assurance and it's not gonna do a reentry attack on you. And for one, for pure call, the use cases are, one of them is just generally pure functional programming but the second one is a cast for validation code. It might also be very useful for account abstraction. Yes. So regarding static call, I think it's important to note that it won't do you any good against our attack type things where what you actually want to do is send value to the recipient. Yeah, like it's not a magic fix to all kinds of a reentry attacks. It's just a particular way that in some cases you can gain assurance that reentry attacks won't happen. What was that, can you say that again? Can static call send value? No, no, static call can't send value. Actually, hold on, let me just reread. Static call cannot make any modifications to the state but it can read from the state. I think it would be problematic if static calls could send value because then you would have to wait by passing. What was the reasoning about it not being a protection against reentrance to them? No, basically there is going to be reentrancy attacks that involve calls that are not, that are meant to change state but that are not meant to be reentrant. So for instance, sending money to someone. So there was a question whether pure call can make pure calls? Right, Greg recommended that. I mean, I personally don't care either way. It's basically just flipping a bit. If you implement, if you restrict pure calls to not be able to make any... So one argument... Oh, sorry, yeah, pure calls don't go to addresses, they get code, yeah, so that's fine, yeah. Yeah, so it's... Yeah, one rationale we suppose for making pure calls be able to make pure calls is that pure calls should be able to call precompiles and because precompiles aren't pures, so you might as well let them make other kinds of pure calls too, if that's... So and pure call is subject to the same stack depth, gas, 63, 64 thing as a stack code, right? Yes. Yes, so I have to admit I'm a bit behind when creating pull requests from the issues. I hope I'll be able to catch up next week on that. Okay, so anything else? Oh, well, what do we want to conclude on the static and pure call front? I mean, I'm... Is there any real specification on the pure? It's a 190, yeah, P195. So I think both pure and static call are very useful and also quite easy to implement, right? Mm-hmm. Static call seems offhand easier to implement than pure call because pure call requires taking code from the EVM. That's just my guess. But then, I mean, so does create. Easy enough. Sorry? It seems easy enough to me. I don't know what else any other implement or as an opinion. Do we want this to go into Metropolis? Please. Both of them? Please. Okay. All against? Have you got that? Gave all the telek? Ding. Excellent. Okay. Anything else? That's the end of the... That's... Sorry, agenda. Yes, PIP 98. Last time someone mentioned the problem with the white client, potential problems. I'd like to hear. Oh, right. Yeah, so I think the issue that was brought up is that white clients seem to might be, might have a need to re-execute a transaction in the context in which it was originally executed. And for that reason, they actually need to have the intermediate state route. So basically, so what that means is that removing intermediate state routes actually does have at least some cost. So personally, I'm... By the way, can everyone still hear me? Yes. Yes, okay. So personally, I am a less kind of, I mean, I'm less strong on EIP 98 than I was back when I first came up with it. My main reasoning being that I've realized that the bottleneck to hear it's a scalability isn't so much average case performance as it is worst case performance. And like even with EIP 98, like you can still come up with worst case, so like a single transaction dos attacks that would be able to, would be just a totally not parallelizable. So, yeah, I mean, so I personally say it's, I even say it's much lower priority than most other EIPs at this point. So if we had to chop it, I'd put it first on the chopping block right now. Yeah, okay. But like that, I don't know, it's still a little worth, there's still the benefit of increasing parallelizability. I mean, I personally be happy to keep the continuing the discussion offline. Okay, should we do that then? Any others? I do have one, I wouldn't say agenda, I'm just something we noticed in the go team. So we saw that parity began working on the life client protocol too. And actually there is a parity light protocols back on their web page, which is kind of based on the last protocol, but a bit modified. And I just wanted to bring it up that perhaps it would be best not to diverge the light client protocols because then we'll have a separate parity island and a separate get island in a network. So maybe it would be nice to start standardizing the light client protocol to through EIPs to ensure that we don't get to non confirming protocols. And then one of the clients need to suck it up and give it up. Yeah, so that wiki page is really strongly work in progress. I'm in pretty regular communication with Jolt already. So I don't know, yeah, probably we can merge some of those changes back into LES, I'm not opposed to it for sure. We can continue that discussion offline though. Yeah, of course, there are some really nice ideas that you guys are doing. So it's definitely to benefit both projects and the whole thing in general. I just wanted to be on the same page that we don't accidentally bring up two separate protocols and then fight it out between them. Rather, we should be aimed for a more constructive approach. Yes, I agree. Cool, I'm not sure whether you guys want to do it through EIPs or more personally or more directly between the teams. So I think the thing I'd really like to see in EIP is the V five discovery protocol. And I understand that gets like client uses this already and Arkady and I went over to the office and spoke with Felix about it a couple months ago. And it seems like a good proposal. I'd love to see it as an EIP, start getting that standardized and implemented in parity as well. And that's definitely a big step towards like clients. Well, definitely I think Felix definitely wanted to document the whole thing. But I think the problem was that it was always labeled experimental. So they didn't want to spend too much time on it. But since it appears to work more or less nicely, I think, yeah, we should really put in the effort to catch up a nice, a proper EIP for it. So I'll try to talk with Felix and try to convince him or Zolt or maybe we can also help him to gather the IP. Because it's really awesome that you can just start the discovery protocol and you immediately get peers. I think it would be really helpful for the test nut to do. Okay, any further questions? Yeah, I'd like to suggest that we consider saving, I mean, separating these EPs and these changes into separate two or more hard forks and not just one big metropolis hard for. But I guess that's a lady question anyway. I think that's probably worth seeing what our progress is at about a month from now. And basically seeing how realistic that is. So, Matt, are you concerned about deadlines or are you concerned about technical risk from the fork? I'm thinking about the technical risks and the... The fact that this has to be implemented, like some fork has to be implemented within the next five months to push the Ice Age back. Yeah, that's one thing. And I'm also concerned about doing two large changes in one go and not having sufficient test material, for example, to test how everything here interacts with everything else when we do all these changes. So I'd prefer doing several smaller forks. But I guess it doesn't something we have to decide right now. I guess it is probably at least at this stage it's feasible to start implementing basically everything and then see how it goes. And we'll get a feeling on what needs more testing and what can be done quicker. Does that make sense? Yeah, it's not good for me. Another thing that we don't have to discuss now but it would be nice maybe to schedule it for the next meeting is for basically for HD wallets. There's an EIP with derivation paths, it's fun. And so for the last few weeks I was working with integrating the ledger into get and it kind of works awesomely. It will probably release it on Monday. And but the ledger itself is an HD wallet. So you can actually derive arbitrary accounts and that is also supported in get. For now, if you read that to EIP proposal page I think there are two competing derivation paths being discussed. The basically the whole debate is around adding an extra nesting, zero nesting at the end or not. The ledger uses one path and certain wallets use an extra zero at the end. And basically what I wanted to say is it would be nice to kind of arrive on an official path because as more and more wallets pop up and more and more clients started implementing HD functionality it will really screw with users if we get diverging the paths. So it would be nice to fix that sooner rather than later. Yes, absolutely. I think plug and play HD wallets would be really amazing in having to reimplement their own custom protocols just to interact with them is probably gonna be significant overhead. Yeah, the only question would be here like how would this be displayed to the DApps and how DApps would interact with it if there's like randomly new accounts added because currently kind of using account and reuse same one all the time. So we can change this abstraction a bit. For example, in the way we did it in gap was that we introduced an extra layer of abstraction called wallets and then you can have a wallet can contain arbitrary many accounts. And UI wise what MIS could do is that instead of just displaying plain flat accounts you could also say that, hey, here's a ledger wallet and there are five accounts in it. So basically just another grouping. Okay, so this is, yeah. So the important, actually most important current RPC endpoint is underscore accounts for almost all DApps is the first one to use in order to like know you were in a way. So that doesn't have to tell me to care about wallets. I would say probably the Ethereum wallet if you just use your funds then you probably want to know which accounts are grouped under which hardware dongle. I don't think DApps should really care about. But does Nano ledger creates each account a new account after each transaction? No, no, no, so the... You can just create as many as you want. Yeah, you can create as many as you want. You can read them. Yeah, this is the answer. So the question was about if the Ethereum method if we should make some kind of official decision about the duration path, right? Yeah, so currently there are two competing specs and as more and more wallets will appear I'm guessing there will be more competing specs. Yeah, and the problem is that it's all I'm not sure what the Trezor uses or Kipke for example, maybe Nick, you know I know that I only work with the ledger and the ledger is already supported for example by my Ethereum wallet too. You're asking what it uses for what exactly? So the derivation path, the base path. Right, if I remember correctly it uses the one without the extra zero but it's been a while so I'm not 100% positive. Oh, then that would be nice. Anyway, so it's just maybe if you have time just read that. I think the debate is mostly big one out of the three. I did have something I wanted to bring up very briefly which just so get a feel for the order. What do people think of the possibility of a pre-compiled it allows you to validate an Ethereum proof of work? The idea being that it would allow easier cross-chain interaction in order to test that a submitted proof was valid. Yeah. What parameters exactly are you envisioning like a full block header or hash, pound, hash nodes? Yeah, exactly just the hashes and the nodes. And it would validate that it was correct. So there is a paper that states if a smart contract blockchain can evaluate its own proof of work, there's a chance of a 37.5 attack or something like that. I mean, actually, I think to be fair that's still true if the smart contract, if there's another smart contract watching, like in the first contract watching is proof of work and I'd also add that if people really wanted to implement that it's well, Lulu actually implemented ethash verification in Ethereum already and if you're only takes about 4.1 million gas. That's still an entire block, of course. True. So Ethereum is just barely powerful enough to run its own like client, excellent. I mean, my thought is just that as we see why the deployment of Ethereum may well see consortium chains wanting to interact with the main chain and so forth. And the easier we make that, the more it's gonna be done. So I actually think that this was something that was overlooked in the beginning for a pre-compile that should be added. Because it's an obvious thing. I mean, you want to be able to. How much memory would that require? 60 next? 60, yeah. It should be a bit higher now. It should be around 30 megabytes or so. So, I mean, yeah, regardless, it's gonna be pretty expensive in terms of gas costs. Just hopefully less than the 4.1 million that it cost to do it natively. And I mean, maybe this is a waste of time if that's moving towards Casper with a well-eaten level solution anyway. Anyway, I mean, I can put together a really simple proposal or even just post an issue on the EAPS tracker just to get some discussion. Yeah, I do. Okay. I'm curious about what your favorability on deprecating the ETH underscore compile RPCs is. I think it's sort of unnecessarily solidifying the set of languages which we can use right now. And it puts it over burdens the responsibilities of the node. I'd prefer if we leave that to development tools. I mean, I'm inclined to agree. It could be fine for it to exist on a node specific basis, but it shouldn't be the ETH namespace. So it kind of also restricts the ability of adapt to use a specific version of a specific compiler. So I'm also inclined to deprecate it. Yep, seems sensible. Yeah, I guess also anyway, doesn't have a built-in compiler. It just calls, so see whatever it's installed on your machine. So if you don't have it installed then it won't work anyway. Okay. Then I'll probably draft up a quick little EIP for that. Cool. All right, anything further? Great. Well, I guess we can call this to a close. All right, that's good to me. Yeah, thank you for coming. Just one thing, the next meeting is in exactly two weeks, right? I believe so, if you ask him. Okay, cool. I feel the EIP agenda said that every first and third Friday of the month. And today's was actually basically next week is Adcon and that's why it was, so I'm not sure whether it will be in two weeks or three weeks. Okay, let's ask for, let's wait for Hudson to settle in. Okay, okay. Bye. Bye. Bye. Have a nice evening. Bye. Really well.