# Ethereum Core Devs Meeting #10 [2/10/17]

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2017-10-09
- Duration: 1:40:15
- Topics: blockchain, smart contracts, distributed ledger
- Watch: https://streameth.org/watch/yt-huYl7eOlKJE
- YouTube: https://www.youtube.com/watch?v=huYl7eOlKJE

## Description

Agenda: https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2010.md

## Transcript

well yeah I'll just get started on the first uh bullet point so yeah we just went through the EIP um overhaul process what that entails is uh putting together a new EIP 1 uh so that um so that is already in place uh right now we have it so that you have to go to the issues if you want to discuss your EIP and then uh once it's kind of formalized and you got everything fleshed out and get some you know Community feedback there we go okay I'm here all right so yeah Greg I'm talking about the new EIP process um so yeah you go you go from uh issue to a PR and with that PR we have a new set of um or actually I guess a refined set of uh template to use on that we're going to be clearing out all isues so um so yeah that's that's kind of in process uh all the other information's on there uh if you have an EIP please go to your EIP and convert it to a PR uh or close out the issue whichever one um 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 going to do is slowly work through those uh either in the all core Dev meetings or using the signaling systems we're building we should probably I think it be idew meeting so just that I understand this right so it is basically similar to now just that at some point we will move it to an actually like proper PR request exactly and there's a newer template on there that makes it a little bit easier to digest and with the poll request if you want to update an nip it makes it easier to go through that process of uh keeping history of the EIP and is there also a template for the isues uh 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 eips and they can use the pr template or not so it's not an a until it's an accepted poll request is the important thing and who is then merging them uh there's a group of eight editors um myself Nick Casey uh drio gav Roman vitalic uh and I believe there might be Greg as well I'm yeah and then there's like one or two others but um I think maybe Christian so yeah the the editors go through and once uh 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 uh ethereum package manager just because that was already mostly written up by Piper so that's going to go in uh very soon as an official e and then uh Robert you just uh joined us uh yes hello awesome hey nice to meet you and you're you're I guess going to represent parody and ethor uh yeah I guess um I guess so cool so yeah how these meetings go down we just uh go through the agenda which I will paste to you in GitHub or sorry getter and uh we kind of try to come to consensus amongst our different development groups about what uh changes are going to happen in the future just kind of have a sync up so uh any comments you can provide would be great and uh 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 great so that was the first item uh the second one is going to be Christian talking about ZK snark pre-compile so I believe that there might have been some finality on that so Christian um if you want to go [Music] ahead thanks so um I did not convert the issue to pull request yet but I updated the issue description to the uh pull request template um the main changes or yeah yeah the main Chang 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 Bas it's to it's to um eips and the first one is 196 which is additional scale multiplication and then 197 I guess which is the the pairing function um right okay it's two agenda items they are just incorrectly linked okay then let's talk about CK snark parents first um so that's 197 um I think the specification did not actually change uh after a suggestion from vitalic I simplified the the actual mathematical specification but uh the semantics had not change I assigned the address of of eight to the precompile um we settled on uh two dimensional coordinates for the um for the curve points uh I think that's it so what still needs to be determined is the uh the gas costs and that's I guess uh a topic after some of the implementations are finished are there any comments yeah I was wondering a bit about um I don't know the full uh mathematical details but regarding the gas cost is this uh are these methods easy to um uh to have one type to estimate the gas uh and processing based on the input or does it vary widely you mean depending on the actual inputs um 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 there can do so the number of points is a factor that that um influences the runtime I'm fine with actually limiting the number of of inputs to something like 10 perhaps if we can't find a good uh ASM totic for that yeah but I think it should be linear and the number of points so that's that's not a big thing and 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 um but I didn't know much about it I was just that that was the basis of my question I didn't know if the complexity could be estimated based on input or if it was hidden worst worst cases in there you wouldn't you know detect statically so I think vitalic 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 uh it sounds like like this is going to go into the process of formalization now um there shouldn't be much of an issue with consensus but we might check um outside of an allore Dev meeting uh just for the final you know just kind of getting the thumbs up from most people about that does that sound good Christian yep so concerning formalization so you mean converting it into lat oh that I was actually talking about the PR but um 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 uh right now I know yoichi has been uh working to kind of clean that up but there's also things that are not updated from spirus Dragon so it's kind of a question of uh 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 paper's 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 newer ones okay great so yeah uh that part is complete uh let's see all right so um yeah that's for both item two and three the uh ZK snark pre compiles uh this next one is Metropolis so what I'm going to do is so vitalic signing on in the next couple minutes um y I thought we I thought the the uh elliptic curve operations were a different item oh you're right I was grouping them together I need more sleep uh yeah go ahead and go uh go on with that Christian so not sure if so yeah not sure if much has to be said here yeah I mean the encoding is basically the same the encoding of curve points yeah I think that got resolved last meeting we were just going to get like a final kind of thing from parity team and I think uh Ary joined can you hear us Ary yep I'm here awesome welcome okay so um so here multiplication is a bit more complicated with regard gas costs but I guess it can be dealt in a very similar way to um to exponentiation so that should not be a big problem yeah the the progress in in implementations there I've seen that go ethereum started yep yeah started with implementation I didn't I didn't get much further than just the field elements but okay and for for parity is the plan to just use an external library for what exactly EC operation yeah tic curve operations and and yeah also uh pairing yeah we'll just use Library there is a number to choose from just pick up good okay I think we can conclude these two items okay great um and then Martin uh in chat talked about how one of the um items is now uh it went from like 140 to 196 I think um the uh EIP numbers are generally going to stay the same as the issue number um unless uh 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 y uh next on the agenda is let me see Metropolis so this is a big one um so V's going to join soon and facilitate a lot of this uh Christian until vitalic gets here um if you could just kind of lead this Nick to uh oh damn all right uh Hudson's cut out uh is anyone else still here is it just Hudson I'm here here yeah yeah it's just him when so I'm sorry I I just Christian um question about 196 um I I'm I'm fully aware that we probably want to do 19 197 um when did we discuss 196 I don't remember this from any of the previous calls that we've had oh yeah thought we discussed 1 and six also in the in the previous CL perhaps you you more or less combined it with one one and seven uh the thing is that that for z z case narks you also need elliptic curve multiplication of points otherwise it's not efficient enough all right and it's yeah it's basically the same operations on the same curve I mean when you when you implement the um when you implement the pairing function you also need that anyway I guess it's just okay all right all right cool yeah all right so these these methods are you will need them anyway for the pairing good okay yes yeah all right and it's also on the same curve so right cool okay thanks so Nick do you want to take over yes uh shall we press on to the next item which was so we just covered curve Edition Metropolis Associated Eeps uh I guess is Christian here because isn't so we don't have either of their facilitators yeah yeah so I'm here oh sorry um in that case do you want to take this away ah sure yeah yeah okay sorry uh so e 58 um between the last meeting and and this meeting we noticed that uh so yeah everyone is aware of the proposal a and proposal B where proposal a says um charge memory enlargement for return value to the caller where proposal B is charge memory enlargement uh to the call to the remain gas of the coli and we noticed that this uh might break existing contracts when they call into the um the identity pre-compile because uh the gas costs for the identity pre-compile are quite easy to calculate and thus solidity generates code or generated code um where the the the amount of gas was was exactly specified and if we now change it to um make the the coli pay for enlarging the memory then there won't be enough gas to do that so um basically the the the compromise uh proposal was to keep the old semantics uh 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 um apply these special rules where memory is enlarged twice and the enlargement for the return value uh is charged to the call what are the opinions on that proposal what's the advantage of of all of this over just charging the um Quality 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 up bound do they ah sorry so you what you just said was basically proposal a is that correct effectively yeah well it seems like B is getting more complicated the advantage of proposal B over proposal a is that um you know for a fact whether the call up code will fail or not before you execute the the actual call and I mean in a way this also kind of protects the caller um because if if the caller does not specify an effective upper bound so just a gigantic value then the call E can make the outer call fail by making go 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 uh all of their gas that is hard to come up with true because it's quadratic yeah fair enough um getting into all sorts of each cases with sometimes charge to caller and sometimes charge to call E and so on for B seems a a real problem though why because it significantly complicates the the the in in the proposal and introduces more more potential for errors it makes it harder to reason about basically sure I mean um yeah the the proper way to do this would to would be to provide a uh return simp like simply like call data but for return data but I think we're past that so the only way to fix this is is one of these problem the 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 L let you access all the return data and the amount of memory you provide in the callop 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 Len and call data copy add op codes for return data Len and return data copy yes and the the callop code would REM would continue to function the same way as previously except you could also Fitch 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 uh you know the memory accounting issue to the same degree what is the model for ewm in that area someone from ewm here uh Greg I'm not an ewm person Oh I thought you were for some reason I keep 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 easm how do you pass uh input data and how do do you retrieve return data I'm I'm not really sure um no I'm not really sure okay well where's Mark he's not here oh okay on once it gets you know into the evm it looks the same but how they make that happen I'm not sure hello vitalic hi everyone sorry if I'm late no worries we were just discussing uh uh okay yet another proposal yeah so I I think I think um we need to have yet another proposal for this one and we move on to to the next D while we further discuss 5 ax perhaps some opinion from vitalic um hold on so why do we need a new proposal so the the new proposal would be to add uh basically return size and return copy in a similar way as we have call data call that a copy the reasoning being that accounting for return values has turned out to be more complicated than expected with the current proposal hold on so what would be a return what would the return size of return copy off codes do uh so return size would tell you the total amount of data that the most recently called contract tried to return and return data copy would copy the specified segment of that into the specified segment of memory and the callop code would continue to operate as as it does already so if you writing new code that expected a variable return size you'd just say return size zero or whatever suits and then get data through the new OP codes okay this just sounds like way over complicated to me check out the recent discussion on five about um gas because that also turns out to be more complicated um issue issue five yes sorry issue okay in the notes as 58 okay well what Nick's proposing seems quite doesn't seem to be so complicated let's I I think Christian's right we should take this offline um and and discuss it amongst those of us interested in in it rather than try and resolve it here yeah yeah I agree okay um okay yeah so I guess that bring brings us to 86 proposed initial abstraction changes for Metropolis you want to take that um yes um so the basic idea I think as well I think we've probably already mentioned in calls a few times is that we allow a new type of transaction where if the signature is equal to 00 Z then that transaction gets treated as valid and the cender address is assumes to be two to the 160 L one which is like zerox f FF 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 is the destination of the transaction so the idea is that the transaction would go to an account and that account would actually be a like 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 uh either pass the message along along or in some cases do something do other things and uh I mean this has a few goals one of those goals is to kind of do abstract away account security one of them is to abstract away at least partially abstract away nonis um a third one is to allow contracts to pay for gas so in order 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 which and what they do is they basically switch the the way that contract addresses are determined from being based on sender and nons uh to being based on the code and uh and the sender and the purpose is BAS basically so that you can sense you accounts before those accounts exist and because that's like what you can do with any regular theorum address so and the idea would be that you would calculate yourself what the address would be you would 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 of start using that account you can by uh 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 an exact same piece of code now for backwards compatibility purposes um I like this was debated in a previous discussion and like previous calls and people seemed 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 um like create with code address or whatever and that would basically apply the same principle to 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 like it's not critical it's not consensus and it's not critical path and so we can theoretically implemented like a month or two after the hard fork and it'll be fine and that basically is logic in the minor and logic in any no that does transaction propagation that would basically scan for specific type 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 uh comments would be to check for a regex that would basically say this account this transaction goes to a particular type of account which is guaranteed needs to pay at least some fee to the minor yeah that's the latter s definitely reasonable um I've I've already partially implemented this change in go um apart from demanding strategies and uh transaction relaying strategy so so uh I I have a question sorry how you how exactly you protect uh you know uh attackers from kill all the budget of this contract attackers attackers from doing what with the contract sorry just just trying to spend all the money that are there for you know for paying for good transaction just send transactions and ah okay so one important point is that the cont the contract only pays gas after it determines that it the signature is valid so if you just send it junk data then it's just not going to do anything and yeah but the signature is all all zero right yeah exactly so yeah so I I no no no it's it's the it's the signature provided through the call data so it's not the signature on the transaction itself so you would pass in um so the transaction data would 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 invalid signatures right so but you would have to start process already at least like so the idea is that no minor would be stupid enough to include transactions that don't pay them and like that and by default like until we start implementing strategies miners are not going to mine any of these transactions anyway I mean yeah to be clear at present you could attackers can make uh nodes do 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 power with the current signature validation it's just that now it can be user specified but in this case I would have to spin up the evm first to like execute this contract the contract will stop at this point throw and that's it yeah so we might have to increase the transaction fee proportionally although no that doesn't really help currently if if the if the regular expression is strict enough uh we don't actually have to run the evm can also just do a yeah basically what we do with precompose but a fast effectively and say oh I know what that contract does I'll compute it myself yeah so sorry I I still miss it like what is the the basic principle that we use to identify addresses that we should H pay for them and addresses that we are not going to them what do you mean like you you get a transaction right you identify it was sent by S address and now you know that you have to pay for that or or you don't have to pay for that okay hold on so who who is who is you are you a minor are you a sender or you a receiver yeah you are a minor you are a minor and and you should understand if it's a valid okay you're a minor you receive an EIP 86 transaction and that EIP 86 transaction has some two address right so okay what you would do is you would basically run a reg exp on the code of the two address and you would determine whether or not it matches like one particular preset pattern that would determine that it's kind of safe and that it's and that that 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 gas that is also specified as part of the I didn't think you necessarily have to do that if you're sure that it will execute quickly and give you an so 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 I should specify regx for all contracts sorry for all addresses I'm going to pay for uh no no no so the regex is a rule is a minor strategy rule right so the idea is that would be like at some point after the fork would release a version of the like or anyone who runs a uh a client that gets used for M by miners would add in like at least one or two reg exps that would uh and these would basically identify you know pieces of code that are kind of okay for the or likely to be profitable for the minor to include and I cannot uh you know I cannot fake this regx if I the attack 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 you know fake the T or or imitate the right t x to be paid for no um no so the regx would be strict enough such that you can prove that any code that matches it would be code that basically if if that if the account has enough money to pay for it and if the s and if the signature is valid then the transact the transaction would actually take money out of that account and give that money to the minor oh sorry one more question so we are talking about reg X of the code inside the smart contract of the code inside the of the code of the two address so but but the regular expression itself is stored in the code of the client yes it can only be changed with a software upgrade basically or will only changed so I I have you know some sort of proposition uh to maybe add to this CIP and tell tell me if it's reasonable H for example addresses that are not identified by by this regx but they are uh they're I they have a value so it's very hard to attack with them you know if the value is large enough uh so maybe these addresses can be also passed into the contract and um and you know it can be valuable in some very famous cases so I think the important thing to keep in mind is that once e86 is implemented like we can we can definitely keep on coming up with more and more regex that capture more and more classes of contracts that are safe for miners to include and miners are going to are free to kind of add new regexs unilaterally 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 um the so the so the reg so the rule that a minor would use to determine whether or not it includes a transaction is a is a function that takes the following inputs one input is the code of the 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 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 pot like these rules could potentially be like arbitrary um quickly computable functions on those three pieces of data well sounds interesting um okay I I guess uh we we should you know make this uh comment thread on this CP more active I guess these questions are it's it's still a little bit you know shaky for me but uh uh it just in details I don't want to take all the time of everybody so I will pass on um but you know if you ask questions on on on the thread just take a look there okay okay then perhaps one thing to discuss here is um is there a good strategy to test this um how would we test strategy yeah that's my question do we uh [Music] necessarily as we do usually we just implement this and wait somebody going to attack it well no because it the important thing is right that like when the EIP will when the hard Fork is implemented initially none of these RS are going to be imped right so initially the only basically okay theoretically a malicious minor could include one of these transactions but it would just go be incl processed according to the consensus rules and we use the same like the same state test methodology that we've used for 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 anyone nobody would re relate these transactions anyway and like falic said if somebody include if a minor 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 uh EIP is at least once the fork is done on the test net and on the main net then on the test net we can probably start um letting some clients kind of turn some of these rag apps exps on and uh and but that'll be a separate process so it's important to know that these regs um are also being used for relaying and not just for 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 this hard for yeah yeah so like the in in general right the the kinds of attack classes we have to worry about are basically one like one of them is consensus failure and this is fairly simple from a consensus standpoint the other one is uh um like Network propagation and various kinds of transaction Doses and at least initially there aren't going to be be any R exps 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 um 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 in a hardw and second do we want to have it in Metropolis I think it's reasonable to call it accepted um I others where we can includ it Metropolis um yeah [Music] I I'd say I I mean I'd personally say this as one of the probably one of the higher my preference would be to try to put it into into Metropolis and one of the reasons why I say this is just because of complimentarity with the ZK Stark applications um but and alongside it's also one that just see has a fely kind of high tradeoff of uh you value to implement mation cost but that's I mean personally I would I would much rather like if we have to start putting things on the shopping block I'd much rather Purge things things like the rever op code but that's my personal opinion are there any objections from from De 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 give let me say there objections to implementing it in the next Fork from from the people who are in charge of of figuring out what their teams can do and in the absence of that I think it' be fair to say that this is tentatively on the next talk agree y okay so I guess this needs to be put in a PO request now so that we can actually accept it yes and Mer I will do that okay uh next one was where are we uh sorry um I still have a question how does 86 work with cp55 the replay protection replay ATT protection um so is the question like will e86 transactions be replay protected like the two are kind of mutually exclusive with each other um I'm inclined to say that by default I don't see I don't see any risks um well actually by default there's not going to be risks because like the uh other blockchains aren't going to or like the other ethereum instantiations aren't going to immediately implement this I mean the one thing that we could bring in is the chain ID parameterization so so if we want I actually assume that we that we actually put the chain ID into the V and that V being zero would be after um after having derived the chain ID okay um in that case that's yeah that's fair so we could uh basically instead of making it be z00 Z it would be just be like either chain chain id0 or chain ID time 2 that seems like trivial enough and I can just put that into the pr so uh and to be clear in chain replay attack are the responsibility of the verification function correct so that's that's something perhaps that should be uh talked a bit more about in the issue so I mean with with that abstraction we can't have an ordering of uh of transaction anymore because if I mean the contract can check the nons but then the trans transaction will be executed it just won't have any effect but it will consume gas so mhm you can't basically you can't put out a cue of transactions that will be then uh executed in order which is probably also a good thing because it consumes resources in the in the miners and clients that aren't paid for right right well I mean that's s that's sounds highly dependent on minor strategy is like you could potentially have like miners have a X that checks for a specific type of account that 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 regx for sub utxo scheme so it's like it's in the longer term it seems situation dependent sure but but any minor can include transactions with a future nons and be accepted by all clients yeah correct so like from the from the point 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 that can be included twice and uh and so you'd have to look at like this basically you have to look at a you have to you'd have to make sure 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 um because if uh like there there is still going to like any any sane actor is still going to have some kind of non- scheme or some 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 non ah but the uh but the transaction is not going to the transaction or the account code is not going to pay for the gas until the non correct so if a minor includes it then the minor is not going to be paid anything the gas price will be zero ah right so the that are there in your code will will break early and don't pay yeah right yeah exactly I see yeah yeah so guys um sorry to interrupt I need to leave now um Peter and Nick are both on the call so they'll further represent the Go Team all right see you see you uh so can we move on to 96 uh putting block hashes and state routes into the state yes right that again yeah so uh basically the reason why I I well there's two reasons why I came up with this one reason is as a part as part of kind of abstracting and simplifying the the protocol I wanted to move to like basically move to away from having any kind of implicit State except for state that's like reflected in part of the state route so that the state transition function actually is you know take a state add a transaction and get a new state without also having like some other state that we don't actually call the state and right now the last 256 Block hashes in some sense are kind of part of this Phantom State and this ends up like actually increasing implementation complexity um and it also it it's also kind of limited because of it's h there are use cases for checking block hashes way further back than 256 blocks but if we were if we were to try and stretch it that 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 hashes in the state and the BL cash up code would be kind of redirected to read this and basically look at what the what the contract says and at the same time the the contract that stores these State these State roots or sorry these block hases would also have a function so the goal would be that we would try and like nudge people to where to use this function to access the block hashes instead of using the block the block has op code the second part of this is that would make State Roots accessible Bas just as block hashes are the thinking here basically is that um this would uh allow um like it's it's more it's more intended as a as a kind of as a longer term feature in order to allow in order for things like uh Casper Casper 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 deal is that this basically there would be a parallel mechanism that does the exact same thing to State Roots as is already done with block hashes if nothing else that allows contracts to very easily process proofs of previous States right um uh sorry and the other main important benefit here is for light clients so right now basic uh basically in order for light clients to like actually properly be have full the full like lli 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 points to block would directly points the blocks that are like 50,000 blocks before them this would allow light clients to kind of verify a partial chain that skip that kind of Skips 10,000 blocks at a time and You' basically be able have like like potentially even higher syncing efficiency than the existing GE life clients and at the at the same time kind of Bas the full the full chains worth of proof of work security without checkpoints uh yes so one question um is there a plan to eventually extend this contract to store all state roots or all block cashes okay so this gets a bit more more intricate um so there's a bit of a trade-off here because like you could potentially store every state word on every block hash and that would actually technically be the easiest thing to code but that would also leads 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 or about 2.2 million blocks 2.2 million blocks times 32 bytes gets you to about 70 megabytes and then that times times an overhead factor of two and then that times another two for block hashes and state Roots would get you to 280 megabytes of State growth a year so that's like it's a bit Overkill now if we wants to go back further then I actually did I I this hasn't been updated yet but I do have a mechanism which kind of does it much better and the idea basically is that you would uh 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 655 the 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 uh diff at the same time go further back so like Block H individual block hashes would only be accessible within 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 go back much further so the uh it's theoretically it's actually not that much more difficult to code up um the uh but you know but this would actually allow you to kind of basically hop from any block to any other Block in the blockchain in logarithmic time H I see okay uh but that's uh not the plan for now right I mean like if if needed I could I could always just write up in in an EIP for that just so that people can see kind of how easy or how complex it is oh actually from an EIP standpoints the two are are equal in complexity because the go what 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 contract code only be needed would only need to be written once okay and then I have uh one more question which was um uh 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 the storage but if we're if we're starting from some header which is entirely disconnected from the Genesis then and it's attacker could just put in fake block hashes and fake State Roots uh we still have to walk backwards and verify the the proof of work for all of those individual blocks to the Genesis right right now sorry so for actually so for this to work well basically you would actually need to have a somewhat different rule you needs to have a block points to its uh an points directly to ancestors the satis 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 kind of being almost as hard to falsify as or almost as hard to of make a a a fake copy of as creating an entire fake chain right so because like if you imagine a 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 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 all of the kind of high uh High difficulty blocks and you would use that as kind of probabilistic proof to show you know this is the CH this is a chain that actually had a lot of people doing stuff on it uh interesting so it's sort of we find the Keystone blocks that occur by coincidence exactly yeah okay yes that sounds pretty reasonable yeah like see yeah the way that I'd even see it is I think you might only need to me to prove the correctness of like maybe 10 or 20 Keystone blocks so just basically the algorithm on the server side would be step one scan through the entire chain step two find the 10 or 20 blocks to satisfy a difficulty thres 100 times 100 thousand times higher than normal then step step three use this kind of block hash linking mechanism to prove a hash link path from each one each one of these super blocks to the previous and then you would just and like ship it off as a proof to a light client and the whole thing would be maybe like five or 10 kilobytes along and the or well mean fine maybe like 10 10 to 50 kilobytes and the leline would be able to just kind of Blaze through it probably in a few seconds is there an for that proposal um it's I can I I haven't written it up so far because it's not consensus or at least like it's it's not bful no consensus but I can also assign myself the task of doing that okay uh should we move on to the next one on the agenda which is e 100 uh change difficulty adjustment to Target mean block time including ankles yes um so this was originally posted a response to a bug that was uh uncovered by SRA Garner which is basically the uncle mining incentive issue and the idea here is that because right now the block time targets one unit of of height growth per 14.3 seconds it's uh like a theoretically a malicious C T of miners that wanted to maximize its own Revenue would actually have the incentive to make three blocks at every height level and uh and that way instead of earning and then just include each other as uncles and that way instead of earning five ether per 14.3 seconds as normal it would end up earning something like 14 ether every three seconds and now that 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 of 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 uh block to the difficulty adjustment rule so that in instead of targeting one block height increase per 14.3 seconds it basically instead it ends up targeting one block header per something about 13 seconds you know including uncles um now there's a difference between version 1 a and version 1B and version 1B basically treats blocks with one uncle and blocks with two uncles as being the same thing and even though this this technically does slightly weaken incens of compatibility but like even still you get like about maybe 70% 75% of the benefit but the nice thing about this is that the challenge with the two Uncle with treating one uncle and two uncles as being separate things is that you can't 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 as the hash of the RMC list and so that's something you can trivially check in the block header so the idea with 1B would basically be that you know you would kind of 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 one per block and two per block that contains either one or two unles I Lally this seems reasonably uncontroversial it's it's an obvious fix and it improves things does anyone objections to it being a metropolis um 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 okay okay so all opposed to one B passed by yeah when I need to get yep all right uh oh and we we didn't actually make an actual decision on on 96 um I mean it sounds as though it's it sounds as though the decision is that people want me to uh kind of write up the uh B basically re uh write up the version that that kind of go go back further in history with with decreasing frequencies and write up the EIP for the heline algorithm and uh then uh discuss it again next time around okay you happy to do that yep all right cool um in that case the next one is 196 and 197 pairings um there's also a missing actually no never mind I I thought 101 was missing but then I real I remembered that 101 was superseded by 198 so all good um yeah heing um Christian you're around so we already talked about that in the very beginning yes so something else so yeah V wasn't there but I I guess the consensus was yes these all seem okay wasn't it I think so yeah okay I am I am happy to provide number number Theory Tech Support to anyone trying to implement this and having problems that you're understanding how it works suspect that will be appreciated V tell there was a question about the expected uh resource consumption I guess for the pairing it should be linear in the number of yeah pairings yeah like I think the G the resource consumption should be um a A plus btimes n where a is a as a constant and or and the are constants and N is the number of uh arguments that get multiplied up does it make any sense to limit the number of pairings or not really um I'd say no I mean Le see reason why it's all just time right it's not that some of the need a lot of memory or like that yeah no no good and the yeah the the elliptic curve Scala multiplication that is similar top right um what do you mean simar to exp the the the gas cost will probably well the the gas cost for up to curve stuff should just be constants because we're sticking to one curve curve no uh scal multiplication oh sorry scaler multiplication um no that should also be a constant actually oh I see because what what um so my opinion is that I don't really see many use cases in practice for scalers where the expected ABS value of absolute value of the scaler is much less than two 253 so I just say make it a constant that's dependent on the max M okay like like what's the last time that anyone's everever multiplied analytic curve points by 479 right like it's always a random 256 bit number ah I see yeah I mean yeah okay inversion squaring that might be useful and could be cheaper um but yeah it's probably dominated by the cost for the call anyway so yeah okay um by the way speaking of costs for calls can I just make a quick PLL on the level of support for an EIP that would reduce the cost of calls in this specific case the destination is a precompile from 700 back down to 40 I think that would be excellent um that that cost increases has caused significant problems I think for that sort of stuff yeah I think I would support that too mhm okay okay so 198 B mod exp yes um so the uh goal here is fairly simple it's just modular exponentiation of big numbers um and uh so basically in the data would be an encoding of three numbers well the encoding would be like very similar to uh to the ABI where we just have three likes followed by the three actual values and uh although it would be kind of less straight it would just expect a length fold followed by the concatenated bite arays and it would return the base to the power of exponent module of the modulus um the only kind there's a a couple of edge cases so one of those edge cases is uh what do you do if the modulus is zero and my opinion is to throw um the second Edge case is uh how to actually figure out the gas costs and we spent a bit of time arguing and since last time the formula was slightly updated so that basically it's uh the floor of the max of Max of the length of the modulus and the length of the base or well basically the 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's uh but it is slightly more complex than it was before but this uh removes kind of two uh 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 um so situations where the exponent is zero basically are going to return one in all cases except those cases where the modulus is is zero in which case it throws um yeah I mean that's basically all the is to it the is to support um both RSA and in general any kind of big number cryptography U what about Alex's comment on the to the effect that2 bits ought to be enough for anyone to the effect that what that the length Fields don't need to be 32 bytes each um hold on oh like 32 bits um I'm in I'm inclined to say make the length field 32 bytes instead of 32 bits basically because like that's the way that the existing API works and uh there's no reason not to stick to that's and I would even argue making it 32 bits would be more annoying because like it's actually more difficult to construct 32 bits in evm that it is to construct 32 or it's more complex to pack 32 bits than it is to pack 32 bytes true so you know I'm I'm inclined to kind of stick to ABI Style I intend to change that but it probably won't be in time okay uh well any objections all right um I guess move to to make that a part of metropolis as well then I mean it's it seems like an obvious um Synergy with Uh custom signature algorithms okay uh in which case that brings us to 206 the revert op code and 207 encoding is R op code yes so this is basically the a kind of updated version of EIP 140 whereas I understand the main change is that instead of the revert instead of like it providing an error code as a stack argument it would Pro it would provide error information encoded in bytes that would be returned in the same way that the that call 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 uh this in the return data area if the call fails or whether it should be punted for a future op code I'm personally for me is the opinion that it should return it wait hold can you just repeat that so there's there's some discussion in the E whether or not um the call op code should return um the the value from revert if the call fails or whether that should be whe it Contin so you mean you mean the the value that gets pushed onto the stack if the rever it fails yes well the the memory area specified by the values on the stack um hold on what do you mean the memory is specified by the values on the stack so as I understand one at 206 uh the idea is that the reverse op code would have the same um semantics as the return op code yes um right um is there so what's the alternative to that well so so the discussion is whether the callop code should um populate memory with the the data returned by revert or whether it should be ped to some future op code for excessing see um okay my instinct is to my instinct is to call is to making call do it directly my arguments are that number one it provides a nice imetry here uh to between return and and the the other argument would be that it avoids introducing new OP codes and particularly it avoids introducing kind of new for new forms of of temporary State yeah personally I'm inclined to agree um I mean the the problem raised is that call doesn't provide a good way to to access the length of the return data but at least in my mind that's a fog an alter whether it returns from reverse as well so it's a problem we already to fix MH so yeah if we add uh return data size and that's that's a good pair to to add right so yes so return data size and return data copy in that case would also work on the revert result right yeah so C I guess those would also be up codes that end up kind of introducing a weird new kind of state of of of runtime State um so are you saying the 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 a problem with gas here I mean the the memory was paid for by the col so I don't think that's problem but are there any other complications um okay so basically what happens if uh the call E returns like 50,000 bytes worth of uh worth of data then that's basically basically a kind of second memory array in some sense um but it's memory that was already it doesn't increase the it's right it's it's it's memory that already gets paid for already gets paid for inside the collie yeah yeah I mean it doesn't seem like there's Po from that standpoint but so what you have to do is you have to do another copy probably because you you won't keep the full memory area of the collie alive just The Return part so you have to copy that somewhere it could I mean you could keep the full memory are through quity alive you could yeah um but would everyone agree that that how we handle that is orthogonal with with whether call returns revert data yeah okay I mean I my own instinct is that the SE isn't like discussion isn't settled enough yet to to say definitely included as is in Metropolis um I don't know what other people think so we're already using the op code or just about to use with the idea that uh as long as it's an invalid op code it's it's unassigned it will revert so which is fine and once it gets implemented it doesn't waste any guess that's fair enough yeah okay so um how about I will commit to like summarizing our discussion here on that e and secet senses there is everyone happy with that okay and then the other one was 207 which is how contracts should encode revert data yeah um it lists use the facilitative italic I don't know whether you had something you wanted to say on it um let's see yeah I mean I already me already gave my comment which is that I think just for symmetry purposes we should like just use ABI yeah no 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 I believe the original proposal for C was when the expectation was that the main thing accessing this would be offchain debugging tools not necessarily anything on chain and I I would argue that uh I mean well offchain de offchain debugging tools can don't necessarily even need like anything that gets returned in the rever op code 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 uh comment okay um and then the last item on the agenda is static call 116 followup uh question facilitating are you still there Christian yes [Music] um I think not much changed on that um yeah there is a so there there's a pure call pull request is that yes same thing U what not no so the difference is that static calls can read state but they can't write pure calls cannot read State and they cannot read State yeah I see yeah what number is the pure call or right 195 I think yep okay yeah so for Pure call the main use cases are I mean well for for static call the use cases basically are that any constant function where just you wants to very easily provide an assurance and it's not going to do a re do a re-entry attack on you and for one the four pure cic use cases are one of them is just generally pure functional programming but the second one is Casper validation code it might also very 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 D attack type things where what you actually want to do is uh send value to the recipient yeah like it's not a magic fix to all kind to all kinds of re reeny attacks it's just a particular way that in some cases you can gain assurance that reury attacks won't happen what was that say again can they can static call some value no or um no aesthetical can't send value actually hold let me just reread make any modifications to the state but it can read from the state I think it would I think it would be problematic if static calls could send value because then you would have a way bypassing what was what was the reasoning about it not being a protection against re-entrance then no basically that like there's going to be reentrancy attacks that involve uh State calls that are not that are meant to change state but that are not meant to be re-entering 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 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 yes so that that's fine yeah yeah one one rationale we suppose for making pure calls be able to make pure calls is that pure calls should be able to call Pre compiles and because pre compiles are pure so you might as well let to make other kinds of pure calls too if that's yeah so and pure call is subject to the same uh stack depth gas 63 64 thing as right yes yeah so I have to admit I'm a bit behind when creating P requests from the issues I hope I'll be able to catch up next week on that okay um is there anything else oh well what do we want to conclude on the state can you co friend um I mean I'm was is there any real uh um specification on the pure it's uh 19 IP 195 so I think both pure and atic call are very useful and also quite easy to implement right mhm athetic call seems off hand easier to implement than pureal because pureal requires taking code from the evm that's just my guess but then I mean so does create easy enough sorry it seems easier enough to me I don't know if anyone else any other impl has an opinion do we want this to go into Metropolis please both of them please okay all against have you got that gavl theic excellent okay uh anything else that's the end of the minutes uh sorry agenda yes IP 998 so last time someone mentioned the problems with the light client potential problems like to hear um oh right yeah so I think the issue that was brought up is that like clients seem to might be might have a need to ex to reexecute 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 like Pro so what that means is that removing intermediate State Roots actually does have at least some cost um so personally I'm uh by the way can anyone still everyone still hear me yes okay so personally I am a less uh kind of I mean I'm less strong on on e98 than I was back when I first came up with it my main reasoning being that I've realized that the bottleneck to a theor scalability is that so much average case performance as it is worst case performance and like even with uh EIP even with e98 like you can still come up with uh worst case like single a single transaction Doss attacks that would be able to would be just uh totally not paralyzable so um yeah I mean like so I personally say it's uh I even say it's much 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 [Music] but like that I I know it's still worth there's there's still the benefit of increasing paraly ability I'm I mean I'd personally be happy to like keep the continuing the discussion offline okay should we do that then any else yes I do have one um I wouldn't say agenda item just something we noticed in the go team so uh we saw that uh par began working on the light client protocol too and uh actually there is a par light protocol spec on their web page which is kind of based on the last protocol but a bit modified and I just wanted to BR bring it up that perhaps uh it would be best not to diverge the light client protocols because then will have a separate par Island and a separate G island in the network so maybe it would be nice to start standardizing the light client protocol to through Eeps to ensure that uh we don't get to non-confirming protocols and then one of the clients need to suck it up and give it up uh yeah so that wiki page is really strongly working progress um I'm in pretty regular communication with Jolt already so so I don't know yeah probably we can merge some of those changes back into Lees I'm not opposed to it for sure continue that discussion offline yeah of course so also said there are some really nice ideas that you guys are doing so it's it definitely it would benefit both projects and the whole thing in in general I just wanted to make wanted to be on the same page that we don't accidentally dream up two separate protocols and then fight it out between them rather we should be aim for a more constructive approach uh yes I agree ohol I'm not sure whether you guys want to do it through eips or or more personally or more directly between the teams I think so I think the the thing I'd really like to see in an EIP is the V5 Discovery protocol and I understand that gets like client uses this already and Aradia and I went over to the office and spoke with Felix about it a couple months ago and it seems like a a good proposal I'd love to see it as an EIP start getting that standardized and implemented in parody as well and that's definitely a big step towards light clients well definitely I think Felix definitely wanted to document the whole thing but uh I think the problem was that uh it was always labeled experimental so they didn't don't want to spend too much time on it but since uh it appears to work more or less nicely I think yeah we should really put in the effort to uh catch up a nice a proper IP for it so I'll try to talk with Felix and uh try to convince him or jol or maybe we can also help him to together the IP because it's um it's really awesome that you can just start the discovery protocol and you immediately get peers I think we should it would be really helpful for the test not to okay any further items yeah uh I'd like to suggest that we consider [Music] saving I mean separating these e and these U changes into two separate two or more hard forks and not just one big Metropolis hard Fork but I guess that's a lat question I um I think that's probably worth uh seeing what our progress is at about a month from now and basically seeing how realistic that is so M are you concerned about about deadlines or are you concerned about technical risk from the fork I'm concerned about the technical risks and um the fact that this has to be Implement like some Fork has to be implemented within the next five months to uh push the ice AG back yeah that's one thing and I'm also concerned about doing two large changes in one go and not having a sufficient uh test material for example uh to test how everything here uh interacts with else when we do all these changes so i' prefer doing separate several small smaller Forks but I guess that's not something we have to decide right now just I guess it is probably I mean at least at this stage it's it's feasible to start implementing basically everything and then see how it goes and we'll get a feel feeling on what needs more testing and what can be done quicker that yeah does that make sense yeah sounds good to me another thing that we don't have to discuss now but uh it would be nice maybe to schedule it for the next um meeting is uh for basically for HD wallets there's a EIP with derivation pths it's fun mhm and um so I for the last few weeks I was working with integrating The Ledger into G 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 G for now um I if you read that EIP proposal page I think there are two competing um derivation paths being discussed the basically the whole uh debate is around adding an extra nesting zero nesting at the end or Not The Ledger uses uh One path and certain wallets use an extra zero at the end and uh 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 re really screw with users if we get diverging path it would be nice to fix that sooner rather than later uh yes absolutely I think plug-and playay HD wallets would be really amazing and having to reimplement their own you know custom protocols just to interact with them is probably gonna be significant overhead yeah the only question would be here like how how would this be displayed to the uh that and how DS will interact with it if there's like randomly new accounts added because currently kind of use an account and reuse you reuse same one all the time so we can uh change this abstraction a bit for example in the way we did it in gap was that we introduced an extra layer of extraction called wallets and then you can have a wallet can contain arbitrary money accounts and UI wise what M 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 this yeah so the important actually most important current RPC endpoint is isore accounts for almost almost all tabs this the first one they use in order to like know you in a way so D doesn't necessarily need to care about uh about wallets I would say probably the ethereum wallet if you just use your funds then you you probably want to know which accounts are grouped under which Hardware dongle I don't think that should really care about but do does Nano lger 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 you can create as many as you want you can read this is so the question was about the if the if if ethereum me said if we should make some kind of official decision about the deration path right yeah yeah so 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 I'm not sure what the treasure uses or keepy for example maybe Nick you know I know the I only work with The Ledger and and The Ledger is already supported for example by uh my ether wallet you're asking you're asking what it uses for what exactly uh so the derivation path the base path right uh if I remember correctly it uses the one without the extra zero but it's been wild so I'm not 100% posi then that would be nice actually anyway so it's a just maybe if you have time just read I think the debate is mostly big one out of I did have something I wanted to bring up very briefly just so get a feel from um what do people think of the possibility of a um uh precompiled that allows you to validate uh e theum proof of the idea being that it would allow easier cross chain interaction in order to to test proof was uh what parameters exactly are you envisioning like a full block header or yeah exactly just the the the hashes and the dos and it 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 to be fair that's still true if the smart contract if there's another smart contract blockchain can like can understand the first smart contract watching proof of for and I'd also add that if people really wanted to implement that it's well um ly Lou actually implemented eash verification in ethereum already and apparently it only takes about 4.1 million gas that's that's still an entire block of course true um which yeah I mean theum is just barely powerful enough to run into own like client excellent I mean my my thought is just that as we see wider deployment of ethereum we may well see consorting chains waning to interact with the main chain and so forth and the easier we make that the more it's GNA you know be done so I actually think that this was something that was overlooked in the beginning for for a pre-compile that is that should be added but yeah because it's an obvious thing I mean you want to be able to how much ma yeah should it should be a bit higher now it should be around 30 megabytes or so so I mean yeah regardless it's going to be pretty expensive in terms of gas costs is totally less than the 4.1 million that cost to do it natively and I mean maybe this is a waste of time of us moving towards cas but would we need another solution anyway I don't know anyway I mean I can put together a really simple B proposal or even just post an issue on the Eeps tracker just to get some discussion yeah do okay I I'm curious about what uh your favorability on deprecating the ethor 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 overburdens the responsibilities of the node i' prefer we leave that to development tools I meane it could like be fine for it to exist on a node specific basis but it shouldn't be the E name space so it kind of uh also restricts the ability of of a dab to use a specific version of a specific compiler so I'm also inclined to to decate it yep I Y seems sensible and G also anyway doesn't have a built-in compiler it just call 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 e for that all right anything further great well I guess we can call this to close thank you for coming just one thing uh the next meeting is in exactly two weeks right I believe so ask okay I the EIP agenda said that every first and third Friday of the month and today was actually basically next week is atcon and that's why it was uh 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 it okay bye bye bye have a nice evening by really well