Ethereum Core Devs Meeting #12 [3/17/17]

um my cat is a core developer um specifically with uh creating a implementation of the ethereum client uh in the esoteric programming language brain [ __ ] so yes we know about that one yeah yeah so that that's what my cat's up to uh oh that would be a good language for cats yes MH this is good start of the meeting star bra definitely I woke up with 15 minutes to spare nice I woke up an extra hour 20 minutes early because I thought that 1400 uh GMT was 800 a.m. my time it was actually nine oh there's things on the internet to make that really clear yeah I've heard don't know even Google you type it 1400 UTC it will tell you like what the right time is in your time zone unless you have your IP really like hidden in the way true that that is very true um let's see so let me attach the agenda so that's gonna be a m so I just put the agenda in getter and on um the internal chat here so we'll wait just another second and then um start on up different than yesterday's agenda uh there's been just a couple of updates from yoichi and um I'm in the process of editing the um accepted eips CU we forgot one from uh one of our discussions on Metropolis okay so we have uh um parody CPP evm Ruby py theum go and I think that's it [Music] so hi uh Andre uh which uh development team are you with it's A++ team hi Hudson oh hi nice to meet you okay yeah I think I saw you on Skype cool God you have cat tails I have dog cards no one else can care them yeah and with that from Greg we'll we'll kick off this meeting um so the first agenda item is uh EIP signaling and voting system update uh so me and Casey uh Casey and I talked to uh some people from the carbon vote and boardroom and metam Mas teams and where we formed a group to create a voting system um on blockchain that also uh connects um to GitHub in order to show support uh by individual and by group uh for certain eips so uh yep that's in progress and uh some of the first um looks at that are pretty good and then Casey uh do you want to talk about um the overall idea of your um page that shows the implementations in which client it's implemented on um I guess not not too much to say really if you've already seen the table uh it's not mandating that and you know that client maintainers uh Implement any particular RPC method vote uh for an RPC method you know um approves or adds or change an RPC method doesn't mandate that uh a a um a maintainer of a client or cordev you know has to follow that um that specification it just means that there will be a red mark in the tables all Okay cool so yeah it's so that's about it cool yeah it's it's kind of like um uh what's the other uh what's that kind of based off of Casey it's the uh uh who else uses that was it uh JavaScript I guess yeah the es uh the es6 compatibility table and stuff it's linked in the in the EIP and the in the issue okay great I'll put that in the uh notes uh post meeting great so uh next is uh going to be EIP 225 this is the click proof of authority protocol and rink B proof of authority test net so uh Peter you can uh take it away on that I'm just going to link anyone's uh wondering here uh so basically the it's kind of meant as a solution for our constant testing problems um last time we um so obviously robam blew up we all know why it blew up um and problem last time we kind of agreed that maybe we should try to somehow um revive it but uh that didn't turn out go so smoothly as we expected and the problem is that even uh even if we do try to somehow incentivize Reviving RS then it's um it it will always be attackable if somebody really wants to do it and maybe if we start up a 10 gpus it can sustain some attacks but if somebody really wants to break it it can break it and the problem is that kind of everybody was entire Community blew up when robst went down because that developers kind of rely on it to be able to test their so we even though it's not proof of so they most of the developers don't care what consens test net runs on as long as they can depend on it many people kind of started rolling their own private testet kovan appeared and others it's a bit messy and then the entire suggestion behind the this CIP is that uh we can well my suggestion is to relaunch a new test net based on uh very very simplified proof of authority protocol now uh the proof of authority protocol that's that I kind of called The Click is kind of so the the basic design principle behind the protocol was that uh we reuse as much as possible from the existing consensus system basically it should be able to integrate be integrated into existing clients with as little hassle as possible and yet again it should uh it should play along with all current Technologies light clients fast sync uh warp sync it should not require clients developers to kind of update their entire code base just to support this and uh well I won't go over the entire spec but the idea is that uh the for example the the entire consensus of is implemented as part of the header fields and there's a small voting mechanism so that signers can vote to add new signers or to drop existing signers and the only field that is significantly Chang see extra data but that field can since that field is dynamic in the original spec I mean in our current protocol basically we can do whatever we want with that bu because it's doesn't break any rule any networking rule serialization rule Etc and the protocol is kind of I won't go over the entire thing you can read it it's um it's basically just a very simple elegant proof of authority protocol that that plays nice with with everything and just to point out we did uh also an implantation in go to um and uh uh we kind of I'm really proud that it's extremely contain so the whole consensus engine is uh extremely commment that is 500 lines of code and the whole voting mechanisms again extremely commented with some other stuff is 200 lines of code and basically this is two files that can be plugged into the existing systems and it kind of just works and this was one of the our core my core requirements that it should be something that's a that's trivial to add to all clients because otherwise if if clients require a lot of work I mean client implementers then it it be the purpose of running it as a test nut so that's the P VR okay cool um so um is there any comments from other uh client devs specifically if um anyone has you know just initial thoughts on potentially implementing that into their client um and also um if there if there's any concerns with this AR from party here so yeah it looks reasonable enough so we'll probably end up implementing Peter's proposal and also maintaining our role own contract based consensus engine for proof of authority as for the time frame it's hard to tell this point couple of weeks maybe okay thanks Ary um I guess yeah and then um oh balic are you back hey vitalic can you hear us yeah I can hear you I just switched to better inter con action oh perfect okay great and then um Jan uh what what what are your thoughts on this hi um I think uh once the uh once the standard is is satellite it is settled the code should be very easy to Imp in python or Ruby okay excellent so yeah what we'll do is uh Peter's already written a really uh very well written um EIP we'll transfer or I'll uh work with them to transfer that into a PR and we'll do a final check over um and pretty much considered accepted um and uh Christian just to make sure CPP is on board with this I thought I saw something in like a getter chat that y'all were good yeah sure so uh we will probably take longer than parity but because we're focusing on Metropolis now but yeah looks looks good no problem all right great so that one is accepted uh we can move on to the next item which is uh EIP 214 um so this I believe this is kind of shortened into static call versus peer call where um should static C do a state changing operation um and actually throw or just be reverted so um this was discussed um a little bit on the channel by Nick or Martin so I don't think I see Nick in here Martin um could you elaborate on this and give your point of view yeah uh well I guess it's um basically uh since um since we have revert it is possible to do a kind of synthetic pure call uh by having one of the having an initial um bouncing through basically a reverting operation which Returns the return value in the revert so and doing that kind of call will allow you to make pure calls but which are not hindered so it's kind of an ugly back door into pure calls hold on do you mean pure call or static call I'm not sure which I mean okay so static call can read but it can't write pure call can neither can't write and it also can't read yeah so this would uh be able to read it would they are able to to they're kind of able to write but anything they write will be reverted okay wait hold on so they can have sorry so how do you get the information out but still do the re but still revert anything that was written again yeah because the funny thing with the r is that you're able to get a return you can pass the return value as it's as it was eventually defined the I see it ah interesting you can bounce through a revert and and the effect you can have is that you can call stuff and it that stuff can store intermediary values during the calculation or whatever and it can access the state it can return and then you revert the return value instead of returning so so that does seem it's different functionality right because in that kind of situation the state could still change in the middle of the call and so you could still have like weird reury attacks through that yeah well no because it would yeah so I mean like what if no but I mean like T where let's say a like a calls B and that call is supposed to be a static call but then B calls a and then a calls B and then that does some State changes and like basically then like the the in call makes some stage changes and that influences the outer call yeah but if if the envelope call going to revert anyway well no but the point basically is that the outer call so let's say the outer call um so be so in my case b has some State and the the process of calling the function starts changing some State then let's say at some point then after that it calls a and then a calls B again and then that changes a bunch of State then after that once the execution goes back to B like the ex of B is going to continue but the state will have been changed in middle so it's like a reverted it it's a reent attack that's like one level deeper in yeah I'm not sure I follow you but so the point the point I was making is that as as as soon as we implement the revert off code and make point this out also then it will be possible to kind of abuse the revert functionality in order to obtain uh side effect fre course and um yeah do we want all these different kind of mechanisms right I see um okay you I'll think about it it might not it might actually not be an issue um no it might not be it's just an open question on the wev channel right actually if I can't think of any problems that then that definitely does seem like an interesting way of doing uh static of doing static call I think there are two reasons against it and one of them is you will end up with two calls so essentially The Proposal here was that uh in your contract if you're trying to call something with static call uh to to another contract first you will call yourself another function on your contract which does the call and does the revert um and the second reason is if we have the actual an actual static call then um with static analyzers you could you could be sure that it will be a static call right otherwise well I mean so the thing that you would do with static analyzers here is you would do a call and then you would do an assert that says that the result of the that the value that was popped onto the stack but the stack op code basically said that it got reverted um so one thing that does concern me though is that you what if you start using it in that way then you can't really disting like if the revert op code pushes a zero onto the stack then you can't distinguish between successful reverts and uh exceptions inside of the inside of the call so like it would almost seem better to push a two onto the stack or something else or well that inside the inside the the forwarder right I mean the forwarder always succeeds and the fact whether the internal call succeeded or not will be part of the return data of the revert kind of but like even it's there's still going to be cases where you can't really distinguish basically if a uh the internal call fails right then it's going the you can't really tell the difference between that and it returning zero data yeah there was a separate proposal to change the return value of call to have three states yeah okay I support that yes I I support that so and I would totally fix this issue but but that's not something we have uh planned for Metro right having we return valid for call I mean it's something that would be trivial to implement if we agree on it yeah but it would be um I mean it's definitely not backwards compatible well hold on so the revert op code right now doesn't exist right so no I thought we were talking about what call returns yeah so what core returns is not that easy to change uh because of all the existing solidity contracts right but I mean what if we have zero representing an act an actual throw one representing and an a a correct output and then the number two representing the revert op code then shouldn't that solve it in a totally backwards compatible way current Sol check for non zero yeah so that's fine because like if it unless OIC because right so the I guess the Challen here is that the throw up code has two use cases where one of them is to Signal a failure and one of them would be to abuse it in this way to return a static value so so if we have if we have a so okay just start from further back so revert with returning data only makes sense if we have at least uh return data size and perhaps even return data copy why um because the uh the success type the the the success data type and the failure data type is these are two different things and right they can have different sizes so we need Dynamic returns sure although um and well Ian we can still do it with uh I mean we could estab I think for most use cases the here a failure return data type just being 32 bytes should be enough right like like cases that require the failure return to be like variable size seem limited but then you need okay but okay assuming we have return data size then we can use that to distinguish throw from revert true throw will not provide data and revert will or I mean revert without data is basically the same as as just the throw right so like what would the what would the assert be after a call then would it say uh returns like would it check the stack value for one and then or the uh and then or that was the return data size or so what's what's the exact question so like how would highle programming languages Implement that work with uh all of these things are you not talking about the static call workaround or other solution or well both kind of both at the same time so like the static call workaround use case and the use case of using throw to actually signal an error so the just regular throw revert mechanism um yeah that has not been worked out correctly how to do that basically LEL language basically you check for uh failure and in the case of failure you just access the the return and that goes into some kind of exception object that's it yeah it's a bit unfortunate that one is success yeah so is this all um just just for me to kind of keep up with that is this all relating to EIP 214 or is this a culmination of eips that build on each other it's I think a culmination okay sounds good so um okay so yeah 214 is the new OP code static call and it sounds like based on that other things might need to change um would someone be able to um cross reference these eips in the repository and what I mean by that is either tag them across each other or give an outline more or less of what was discussed today today I think we didn't discuss more than is already written in the issues did we uh look yeah that's that's the thing I haven't looked through all these eips uh yeah potentially so um what we can do is we can bring this up in the next allore Dev meeting uh but this uh I think someone mentioned this isn't something that's going into Metro right no I think it is isn't it down for now so the question is so the proposal was to not include static call because it can be simulated by other mechanisms which will also make their way into Metropolis yeah um so one uh kind of side question are we also interested in in pure call and uh I mean pure call is is fundamentally different because it it doesn't to another address right but I mean I would say right yeah I mean like it does require some of the Machinery because like in the case of static call you have to do something to either disable or throw on any right operations and in the case of pure call you have to do the same thing for both rights and reads or but um although I guess doing just one is definitely simpler than doing both so okay so like I I personally definitely feel a bit a bit more comfortable with return data size if it means that we can kind of simulate static call without Act without actually doing static call um like so I think it would be good to to code up a specific example of how to do that exactly sure yeah um yeah that sounds like a good idea would that have to be across multiple clients or just one example that everyone by by code op me like an implementation inside of ethereum code or doing mean like an implementation of how that gets used in high level code uh no I was thinking about an assembly implementation oh yeah so in that case it'll be done in like serpent or solidity assembly or l or whatever yeah so the the high level thing I think that that needs to be discussed in separately but it's a bit the the main problem here is that uh when you look at solidity you can't really distinguish an internal from an external call and the mechanism is of course different for internal and external C so that might be a bit complicated but yeah we have to see okay sounds good so um to give a summary uh Casey and Alex uh in the chat put uh some of the ones that cross reference um this issue a little bit and um uh Christian would uh you all be able to talk about do that implementation you were talking about and just kind of post that across the eips and maybe the getter channels sure okay great uh Casey just had a comment yeah we can move it into the under consideration table that's that's a good idea so that they can all be in there and then we can um concatenate any that we need to so uh any other comments on this cool okay oh um and then Alex uh you typed in chat something did you have a comment uh well no it just casy said if maybe we should move pure statical revert and data size uh into enter consideration for Metropolis but I think revert itself is uh is Standalone yeah exactly like revert is uh seems very uncontroversial and it's usefully even if n none of the other stuff gets implemented okay sounds good um but if it is dependent on return data size yeah I thought Christian said that uh revert isn't very useful without return data size and return data copy at least it's more useful yeah it's much more useful when we also have these other two okay so let's keep it as accepted then uh okay sounds good yeah so it's it's useful with other things but it can also stand on its own even without those okay sounds good uh cool I think that's all the comments for this so the next item is um EIP 161 um I believe that's kind of already dealt with more or less uh yoichi do you want to um just do a brief summary of uh what you commented on in the agenda page and uh how that's being resolved ah yeah sure so basically it's about the yellow paper status and about Metropolis things look good but uh there are other bad stuff good news first um for Metropolis I've created PR requests for most Metropolis eips except eliptic Cs and I visited Gavin's office and with him I discussed metrop Poli p and now it's clear to me what he wants what he doesn't want so um things good things look good there uh but I have to do a little head head up here because the yellow paper on the master Branch currently is still at Homestead so even before spus Dragon the previous Fork um I once submitted spr's Dragon request Gavin merged it but he reverted the changes um and he says he wants some cleanup first and uh Gavin said I and he and I should meet more frequently so we will be meeting regularly working on the yellow paper together and a background to all this is the yellow paper is not under an open source license or Creative Commons no license so it's just G authorship and some other contributors copyrights so um so I I I I I need to keep working with him and I will be persistent about that okay sounds good um I saw that um and I I just want to know if this is oh go ahead so yeah I had a additional concern about EAP 161 that was on oh that's that's exactly what I was going to bring up yeah I I was going to go to your your comment and uh get her but go ahead Ary okay so yeah so e161 allows to delete empty accounts but it doesn't clearly specify if a pre-compiled contract account can be considered empty when it doesn't have any storage so my interpretation is that it cannot because it contains native code and this is not an issue for the main theum Network currently because all of the precompiled have some balance currently there but it might be an issue for future networks the new test net of the private Network whatever and would be good to clarify that and specified in the yellow paper as well I can explain the yellow paper status uh in my previous Dragon pre request uh it's specified that the pre compiles can be empty their code is empty and they can be removed um and then I believe that's what other implementations do currently okay well about this proposal um it's very easy in the yellow paper to implement this particular proposal so that promiles cannot be empty so as far as EUR the EUR paper is concerned whichever is fine if consensus is gained okay and um question related to that um I'm assuming that they won't be existing in the state try though right so the code the the native code this thing will not be in the state try uh you are right so the way to distinguish that is actually so there then there must be an in protocol mechanism to distinguish pre compiles and non promiles otherwise otherwise um we cannot distinguish empty usual accounts or empty pre compiles so we need a mechanism to specify which address contains compiles well if all the implementations already go with they can be empty it might be reasonable to just keep up with it the facto standard but I would like to confirm that this is really the case so I looked at the Go code and this seems to be the so yeah so it that that was the case before the the dragon hard fork and um I think I don't see the issue with keeping it although like implementation has to consider like having contract that can actually return some some data in course but that was the case before uh the hard fork and um I don't really see the the reason for the change yeah what is the reason sorry pet you can go ahead uh no I just wanted to say that I so I'm not I haven't checked that part of the codee for a long time in go ethereum but uh I think uh so there was at a given point there was a a mini fork in mainnet when gu and parity went two different directions and then it turned out that both clients had some bug and as far as I know the issue was that uh go ethereum did not delete something because it had a rule that pre Compass cannot be deleted while par deleted it so I'm not sure whether we delete it or or not but uh I kind of agree with ar that it's uh this is kind of a weird Corner case and it would be nice to specify especially if you want uh clients to play nicely on on non main network uh more precisely this consensus issue was about out of gas uh happening during precompiled execution so the spus dragon contained empty account removal thing accounts were removed when they were touched and the question was when the contract was being executed but out of guess happens if okay the question is if this contract is touched or not touched when the out of gas happened and usually um when out of gas happen everything should be reverted so State removal shouldn't happen and the account was not touched but for pre compil it was different and that's the state now so we currently have an exception on pre compiles that uh if even if out of guess happens during precompiled contract execution they are attached and their state might be cleared I have a question about uh how can this I don't understand how how this can be a problem on private networks since we don't create empty accounts but I'm missing something but I don't know what uh no this is only a problem if people start creating a new network with hom State rules for instance and then create empty accounts and then do the cleanup if people start with uh after SP Dragon ruls then I mean they will never see an empty account so right but if we implement this this will be part of a hard Fork so I mean we can't retroactively implement this I don't really understand um people can start private networks with pre spous Dragon bus and set up empty accounts that's the only case yeah yeah so in personally I think I think that over like over time we should be deprecating support for old rule sets more and more right so like I don't see much of a need for supporting people making hard forks with PRI buus Dragon rules or sorry for with people making private change with Prius Dragon agreed okay so uh it sounds like then that would just be a clarification at the yellow paper level and uh an assurance that all the clients are now um in compatibility which I believe was fixed during the uh the hard Fork around uh November I guess Thanksgiving time I think there was a pre-compile that was deleted on mainnet is that correct yeah yeah okay cool a question though uh regarding private networks uh should it be ass assumed that this the hard Forks are dependent on each other I mean if if only Spears dragon is uh is specified from block zero should it be assumed that all the previous hard works also are applied at that block we had a discussion about exactly this with Jeff and Felix a few days ago he's reworking our Genesis handling and what Jeff's proposal was that how it would be so awesome if people could uh could turn on and off individual softworks but in my opinion the problem that this is that this will open up a huge can of worms if uh there's some unforeseen dependency between um hard Forks it could really mess up yes so the impl implementation in C++ is also assuming strictly ascending hard Forks yeah it would be good just I mean it's not it's not critical but would be good if there was some general consensus not that oh vitalic could you mute uh sorry hold on okay so it sounds like um I don't think this is requiring of an EIP because this was more or less dealt with in the one of the last hard Forks so um yeah I think everyone am I right to say that pretty much everyone's in agreement of how the changes are going to go and it's more I guess at this point if where I'll trying to figure out if it's worth it to do backwards uh compatibility for this if someone wants to pick and choose what previous hard Fork um previous hard Fork changes they want to put in their private Network so uh are we kind of more or less saying we don't really want to go that path because it over complicates future improvements I'm not a client developer I've been interested in hearing what Peter and balic says about it and Chris whoever yeah I guess it doesn't matter that much but it would still be nice to clarify that in the yellow paper just updated to the current state of okay of the implementation okay great so yeah it sounds like the spec is important to be updated oh go ahead Peter no I just wanted to say that uh um the only thing I so if we do specify that they can only occur incrementally and you cannot cherry pick whatever you want I think the the benefit of that would be easier reasonable thing about security of the entire chain okay sounds good so um yeah we'll do the update to the yellow paper um is there any other comments on this otherwise I think it's pretty much resolved so I will clarify that in the Bri Dragon Prest I'm trying again I think he cut off there at the N I repeat that one more time ah okay so I will clarify this point in my superious Dron Pro request that I'm trying to fight again oh great okay sounds good uh the next item is okay that was four five is the Metropolis updates and finding a central location to document eips going into Metro so in the um get her Channel I will repost this but I posted um Three Links and then Casey add it a fourth for where eips um should go and let me get the fourth one real quick uh so basically there is a list from parody um within their GitHub PR system uh or issue system there's a uh list from gu um I believe it's a poll request and then there is a page on the PM repo that has um kind of a it was a really old list of all of them so that's in acccurate I'll be updating it and then I feel like the one that is the most updated is the link Casey posted which was the eips page accepted eips plan for adoption uh so if everyone can go there it has a list of um eips ready or that are planned for adoption and are in the process of being implemented so um looking at this uh across the the other um across the other clients that are implementing this it's mostly the same list uh does anybody see one that's missing or any comments about uh the ones that are added I think they've all been accepted in previous calls but we may have to check on that and um uh clarify that in future calls yeah because it looks like I think at least in the case of parody um 86 and 96 are not in their list for the Metro release uh so I was wondering about that if you could comment Ary I'm pretty sure they are maybe check the numbers and brackets because uh yep yep I see yeah I see because yeah the numbering is weird Okay thank you I see yeah and then let me just look at gu real quick just to make sure that all of those are correctly in there as well so we have 198 140 98 uh the pairing precompile return data okay I think they have all of them go ahead case may maybe we'll just add a column um to that table uh with that contains short links to you know to each client uh poll request you know where the the implementation is uh taking place okay great um I guess lastly uh Jan I think you have a PR or a issue that lists all this right or maybe I sell that for something else uh sorry uh APR set up for what uh for the Metropolis um changes so uh there the eips and their level of implementation uh per client uh I don't think so I have no PR setup for you Ru be uh yeah all right uh that or python um I just hadn't looked at them uh no there there's no one in Python set up for metrop I think okay no problem I just going to check so we could add that link or not okay cool um any other comments on uh the list of accepted eips uh plan for adoption yeah I was going to mention that um you know it helps to use descriptive titles in the you know in the in the PO request that people open and you know that um that specifies the EIP um because then that title whatever title is used in the uh in the IP then you know it then goes into the the table um and so where the titles were too short or undrip of like like ef86 um I took some Liberty and and inserted you know what I thought was a more descriptive title okay great great yeah I think that's a good idea uh so um everyone who's uh doing some of the EIP PRS that that's a that's a good tip to help them be a little bit more clear um I believe there's so I didn't actually add this to the agenda because I just realized this is still something that needs to be brought up but um the there's a list of eips under consideration so I know 211 which was the return data size and return data copy is still you know uh being discussed but EIP 5 gas usage for return and call um what's the status of that Christian has that I guess I forgot if if we've talked about it in a previous call or if there is a status on it so my preference would be to replace that by returned a copy and return to a size but yeah oh okay so it's not even really voed a different opinion last meet in the last meeting ah got it so yeah any updates on your opinion vitalic or uh was that kind of related to the previous discussion we had in this meeting yeah my opinion on which topic uh whether or not uh so uh on the EIP is under consideration on the read me the 211 is what we discussed earlier uh another one is EIP 5 gas usage for return and call uh and you I think was saying that yeah you were more um f yeah I mean I I still feel like five is like simpler than and more ideal than than 211 I mean I'd be willing to go with 211 if it also means that we can get rid of static call though I think there might also be an even cleaner way to do like five and accomplish the same goal with static call in some other way like basically my main concern is that we should be trying to like minimize op code inflation as much as possible okay sounds good um okay so that's going to still be under discussion then let's try to think a little bit more on that and next uh allore dev's calls start to come to a resolution I I would recommend just because of the timing um for the Metropolis things uh speaking Yeah speaking of which I believe oh uh Greg did you have a comment yeah I don't care about op code inflation per se but I don't have the feeling that this little collection of op codes um is sort of a logically consistent and minimal little yet yeah like it's for me personally op code inflation is maybe not the right word like I can handle op codes but the thing that may be uneasy about return data size is it adds also another data structure into the computational state so like it's also that that kind of so it's like another sort of unique Dimensions or complexity in some ways yeah but it can simplify other things right yeah I mean I can see that but we have to pull it all together it's some they're sort of unrelated proposals that haven't been pulled together right yeah like maybe we needs to kind of come up with a few competing alternatives for like how all of these things match with each other there's clearly interdependencies would it make sense to have a concentrated call on on these issues somehow at some point um that seems sensible or like a kind of research meeting or whatever I mean we could even just have an ongoing Skype chat over the next two weeks y um yeah that definitely sounds reasonable and another thing um so yeah the ongoing text discussion and then someone uh starting calls if needed the other thing is it sounds like part of the way to alleviate the confusion is to start coming up with like couple of paragraphs of different uh I kind of see it as you know eips building off each other and proposals building off each other so making sure that's all understood a lot a lot of the time when we're talking about about these things uh we're saying you know it's dependent on the rest of these either being implemented or the way we're going to implement some of these other things so getting a clear understanding of that I'm not sure the best way to do that I guess the ongoing uh Skype chat is probably the easiest cool okay so yeah what what we'll do is um I will send out a link on getter um about the ongoing Skype chat related to this I'll just go ahead and set that up uh between uh Chris Greg and vitalic and then anyone else who wants to can join based on that getter link MH great um there was oh uh vitalic you had mentioned somewhere online that uh because of it was either the price increase or something else uh I guess we have a little bit more time until the block times um are adjusted yes um actually like again probably run through the math right now again because it changes literally day by day so the most recent difficulty is um on E stats as being slow I'm not even sure why I'm using eth stats um I didn't even think eth stats was oh yeah e stats is kind of wonky right now I think um hold on I'll just use my light node okay 195 trillion so that's even higher than the last time I did this um okay then 195 trillion so that means our hash power is 14 trillion um then block number 33 68795 um hold on date plus percent as is fetch the current timestamp running this script thing again um yeah so by the end of June the uh the block time is only going to be around 19.5 seconds by the end of August it's only going to be about 28.5 seconds so like I think we still have like it's still uh like basically if we get it out before the end of June it's even better um and if we get it out before the end of August it's still like less bad okay so like my my recommendation is probably still um like end of June as a kind of normal case Target at end of August as a worst case deadline but like basically the conditions that nor users would have to go would uh be end up uh living through in either case or continue to get better and better okay cool and is that in any way dependent on the price increase or yes okay so in general the difficulty of a blockchain is a kind of very lagging moving average of the price so I would I would say first of all in any the CH the probability is probably like less than 10% that difficulty will ever go down again like it's uh almost certainly going to be above 200 so then the question is is is this the top and is it going to crash back down to 20 to 20 to 30 in which case I could see difficulty topping off and maybe the 2 like the 300 range is it going to stay the same as it is now in which case we could see a difficulty being in the four to 500 range is gonna still keep going up I mean potentially like if in the kind of Sky High scenario wor the ram takes over Bitcoin entirely we could literally see this delayed until actually let me see what let me see what happens if I just multiply hash Power by another factor of [Music] 10 yeah so in that extreme case um at the end of June the block time is still 15 seconds and at the end of August it goes up to 21 and only at the end of the year it goes up to about 43 so we basically the better the better we do the more the more time we have I would say in the more kind of in my personal estimation of the kind of 5050 case I can probably run through that right now so that would be difficulty in maybe topping off at 500 billion in this maybe middle of the summer or so that would or even just to be fair let's say 420 billion that would get us to um also 19 seconds at the end of June but then the 19 seconds would keep on going all the way up until the uh up until the middle of July maybe we should switch our efforts from implementing the eips to uh pumping the price yay let's get linear results for exponential work you go ahead I just thinking I think I was just wondering whether or not us dsing our own blockchain and slowing down the block time would also help um but I think that might be a yeah maybe it might basically it's like the Practical thing to do I think is to just like keep our heads down and make and see if we can finish this by the end of June yeah yeah we I mean we can always try but one thing I would like to um to mention to all all the people who are implementing these e m because when you do that you find edge cases and you think about edge cases and they maybe even make test cases for these but if they're documented so we can so we make sure that they become consensus tests in the actual ethereum test repositor also so we have a good test coverage of this because there's a lot of changes yes it's difficult for Demetri to keep up with all the the changes so this needs to be a concered efforts that's it all right did we lose hudsom oh can you hear me now yes ah no uh yeah my uh microphone went on mute so um no I was saying uh so Martin when you were talking about that uh did you mean people should uh write their eips very specifically in mention edge cases or just no no I meant that uh we need to make sure whenever whenever we re during the process of implementing these Eeps developers uh need to make sure that all these weird edge cases that they come up with that they're uh submitted so that they become test cases so that all the stuff we learn while implementing it they can benefit the other clients and and we don't have any consensus issues because they make sure they W wind up in in the ethereum test repository okay excellent um what is there a formal process or even just an informal process best way to get these to Dimitri or to whoever needs it I don't think there's a formal process the informal one is to just um ping him or me or anyone in the there's a Skype Channel etherum Dev test and there's I'm guessing all core devs would work also uh or wins Vega on di okay yeah I'll talk to him about getting a more concerted effort uh Peter I just wanted to add to that that uh I think one of the problems with this it's a really noble cause uh one of the problems that I see for client developers is that uh for example when modifying or pre building previous Forks um often we made a modification and it turned out that uh we couldn't sync test because something we changed something but uh the change the error wasn't quot by the by the test suite and then obviously the the no-brainer would have been to just submit a new test to the test Suite but the problem is that it's so complicated and messy to create a new test that nobody really bothers so uh yeah probably a long-term solution or long-term suggestion from my part would be if we could somehow create a small tool that allows a simple way to make tests so that if I know that this is my corner case so that I can somehow transform that into a test easily without having to manually create everything all the blocks and all the stuff yeah you're totally right Peter and definitely that's something that should be but in the meantime uh I mean you I wasn't meaning that everyone needs to submit uh uh actual test cases just document the scenarios or the cor cases and U we pre for the last hard work I think we set up U one of those uh what's it called it would just type the cases into paper pad something like that uh just something like that short description verbal description um so then Demetri or someone else can take over and make an actual test case out of it that's what I'm talking about okay sounds good uh yeah and I think over time they'll be more uh like a more clean process like the kind Peter's referring to so yeah I'm sure Dimitri would be very happy with that suggestion okay so uh any other comments on that just a short comment uh AIG already wrote The static call Via revert solution it's a comment on the on the boquest oh yeah and it's also uh a GitHub gist in um in this chat in this uh chat room we're currently in damn Alex you work fast okay so yep I think that's actually all the agenda items uh let me just double check but was there uh anything else from anybody uh yeah no I think this is good what we'll do is for the yeah the last item I guess was just just where we're going to put all the Metropolis uh stuff we're we'll use the read me page uh on EIP so if you just go to the eips repo it's the first page on there so it'll say under consideration or accepted and that's what we'll go with um for now and yeah just a reminder if youall have any IPS you want to throw in uh please add them to the agenda uh I usually try to set that up at least a week before I'll start doing it right after meetings though and I'll release the audio and some notes on this uh sometime later today hopefully so uh yep good meeting everybody uh see youall next time see you see you bye byebye