EIPIP Meeting 96

Transcript

welcome to EIP IP meeting 96 this is issue number 300 on EIP IP GitHub repository um for discussion today we have on agenda EIP process standardization some issues and poll requests uh those are new and people would like to discuss perhaps there would be uh information on call for input and we'll have insights on our monthly eips ercs status reporting so starting with the first item which is updates on Penning task for repo split I wonder if we have any update on the list there and is it the correct list that we are still going to follow I don't see Pand on the call I

wonder if anyone else has any update very well uh we can get update from Panda async moving on to the next topic which is web page rendering in the past meeting we had quite a few discussion on how do we want to see the web page rendering and I know Samson has been working on that so Sam if you would like to take it from here and share uh how are we seeing this web page rendering and what is the approach we taking here uh sure so I've been working on uh getting eeview B to work for working groups um I haven't changed anything about the rendering of my prototype

yet um I'm assuming that we are in a position to have all three of them being reflected on the same domain maybe with some complexities on UI side I I still think it's possible I haven't worked on it okay before we move on is is there any other question on web page rendering very well we can follow the updates in following meeting and also on the E cat do EIP editors Discord Channel if people have thoughts suggestions and would like to uh learn more about

it there is this next item uh which is need a process for moving cloning eips as rips and how they are numbered so basically it is here for discussion suggested by Andrew and Associate editor um Let me give a bit of context here so one of the proposal which was pursuing as a EIP has now been moved to RPS GitHub repository and uh the question here is whether that rip contain the same number that was allocated as an EIP or it should be allowed to have a new number and we are hoping to see a

process in place wonder what editors thinks here so if we're moving it in the same way we moved erc's I think it's probably fine to um leave like a placeholder on the Eeps repository that redirects um but I'm not even sure if we've ever discussed for whether we're adding our IPS to the EIP process I would agree this is a discussion that that's worth having here uh but just for some more context here as we know that there is a repository

which is ethereum rips and the proposal under discussion here is a issue number F sorry the pull request number five uh in this repository I just shared the link here yeah um so yeah the idea here is to move this proposal under rip category because it seems that it would be adapted by the L2 projects rather than the um um being deployed on the ethereum main net however uh the category mentioned here is core which I think is not the appropriate one on I'm open I'm

open to open this platform to maybe discuss what do people think generally about considering RPS or the involvement in the RPS process so I'm in favor of making a like Layer Two working group um I don't think we should pull them in until we have a more formal process for working groups um but uh yeah generally I'm in favor of it just for some context here like

historically proposals have moved from one type or category to another type and category and we try to retain the same number also when the migration happened from the EIP ercd post split all the ercs moved to a different GitHub repository retained the same number so in my mind I feel like it would make sense to keep the history of The Proposal even if the proposal is being moved from EIP repository to rips repository it should contain the same number just to have the history of it draft and review because the proposal is getting into the last call although there is no Clarity on like the last call process I'm hoping that rip uh team

will discuss it internally and it will be communicated unless uh someone uh from the team would like to share here I mean join the eapap meeting and would like to share it here but yeah um any other editor has any thought please share um a few things uh their their meeting is at the same time as ours so that makes causes some troubles with coordination um I think clearly clearly we need to to keep the numbers series uh such that there's no conflicting numbers or there'll be just total

confusion um and for last call I think a working group is pretty much in charge of their statuses so if they want there to be a last call there can be a last call but if if they have another if they want a different uh a different sequence of statuses and requirements for moving between statuses that's not the editor's business um just as for the core working group I don't I don't think they want there to be a last call it's not really relevant to their process and it's it's not for us to dictate their

process and the other thing I heard go by is that I think clearly uh core is is not appropriate core proposals are specifically those that are going onto the ethereum main net and Layer Two um there are multiple Nets that are Layer Two so they'll they'll have to decide um [Music] um uh um I don't know what to call them but they're not core yeah Layer Two is is probably their category or maybe RIP just like we have

a standard track interface ERC core um we can have standard track RP that may be able to Define um their proposals but I also feel that core may not be appropriate mhm and just to respond to the meeting conflict we are trying to avoid that just like today's meeting has been planned at 1600 UTC in order to avoid the conflict I have added the alternate meeting time in the agenda we can perhaps get to there by the end of this meeting so we should never be in the conflict with that meeting yeah am I right that that we're leaving basically leaving the status field up to

them of course yeah yeah I mean I can see that it is mentioned on the pull request number five on RPS get of repository that the proposal is in last call and they have mentioned status as last call but there is no um last call deadline added I mean um I haven't had time to look look at any of this I am essentially six months behind in the work I'm doing for our startup and I'll probably remain six months behind for another year uh but um

um it's just real important that working groups um uh that are actually organized like like the core working group is and like this working group uh wants to be have complete control of their own process um sure we'll continue to follow uh the meetings and uh we'll be able to share more updates and upcoming meeting about ribs but in general um from this discussion um taking it that people are open to have a working group as rip and the numbering process should be a part

of for the EIP ERC numbering which I think is being maintained as of now as well m anyone has any other thought to add on it before we move on is there any tooling issue with that Sam uh with them having their own statuses that that was that's the plan yeah yeah and with the numbering uh so the numbering there's there's um some oddness like um I'm going to have to special case this e because they moved it but other than that it should be fine going going forward it's it's not a problem as groups come in to just

yeah okay try to make it all as automatic as possible so that if somebody comes in we can effectively click a button make a repo in GitHub and and it's ready to run so okay so we're all in agreement that that we don't want proposals to have the same number confuse everyone so there is some ambiguity about that so Matt wanted to just have a completely separate numbering scheme for RPS um Tim suggested something interesting um which is that each working group should take the lowest available slot greater than the biggest number in that working group and that would make um RPS fill in the holes of

anyways it's we can talk about this on Discord there's just a few options but yes I want each working group to have like the same numbering space I'm bringing it up now because I I can't follow everything that goes by in Discord I have something like 15 channels that come yeah I have to prioritize the ones that I'm paid to follow uh so there there will only ever be one ep1 123 and there won't be an rip1 123 it'll just be unique but there's some some details that need to be worked out because rfc's come in um the the uh iatf spans a huge range of working groups covering a huge range of of

Technology but rfc's come in and they just get numbered as they come in so there's never any any confusion um uh about yeah the RFC number something uh is is RFC number something no matter what it's about um I just yeah I think we'll we'll preserve that okay I don't care how it happens with the tooling I just don't want I don't want documents in our system to have two different documents to have the same number that makes sense

okay very well um let's move on on to the next one which is discuss open issues pull request and other topics um I have listed a few open PE here which I believe are the uh edits to final proposals we can quickly take a look into each one of them the first one is on um ERC side I'm sharing the link here in the chat it is for ERC 1046 it's about fixing typo the other two are also about fixing typo and I think they are from the same authors so yeah what do people think

about merging this uh just keep in mind it is final proposal yeah I can look through these um after as long as they're all minor edits I don't see a problem does anybody object to fixing spelling mistakes in in finally IPS um these keep coming around and we just don't have an Arata process um you you want some indication that you change things some

changes some changes are bigger than others uh erc20 came by with a a bunch of of dead dead links and its Earls um with fixes to them and there were some others and we've just been missing an Arata and that seems just like a section at the bottom of of of uh changes and for typos it could be as as simple as an entry that says on such and such a date we fixed a number of typos and here's the pr number um um I believe the next topic would

would help with uh this uh but my question or my comment here would be that I'm seeing a lot of new external contributors who are trying to uh I think this was pointed out by Dan to me people are trying to fix typos and eips to form airdrops so my question here would be is is it okay if we allow this should we allow this should the editor group allow this I don't know um that's that's

my question so this has come up like before um so if they're contributing meaningful changes what like like this spell spelling mistake one that I'm going through right now looks like they're actually fixing legitimate grammar and spelling mistakes um I'm okay merging it and if they happen to get an airdrop for it then that's a good incentive to fix spelling mistakes um but if somebody's like reformatting stuff or or like doing minor changes just to get a commit in um and it isn't like actually useful um then I'd be less inclined to merge makes sense but we need some some way in the

document some aratus section that indicates that on a certain date things did change we have the GitHub that you know we do have Source control which is good but we can't expect the reader of a document to go into the source control system um we need the reader of a document to know that oh this version has changed and the next topic is actually addressing exactly that okay all right uh so yeah I mean like I also had listed this as a separate topic

for discussion like specify condition under which final eips can be updated um we can perhaps get there and try to identify the points that we would like to be document and where we would like to be document all of them and if that's okay we can perhaps move on to the next PR which is eips PR number 8034 about vering schemes for eips and we are joined by Dan and Ahmed to maybe talk about it so yeah please go ahead and share about this new proposal um hi everyone um my name is Dan um just a quick background for

people that might not know me I joined the EF testing team um in this year in April uh working alongside Spencer who's also in Nicole and Mario Vega and um I'm mainly working on uh tests for the evm and infrastructure in order to um help execute those tests in the in the best possible way um so one thing that crossed my mind while working on this infrastructure is it is quite difficult to track changes inps and this is uh something that Greg just mentioned right now um it's not only software testers it's also other members of the community who are reading ANP online um and so I was talking to Ahmed betar

about this while we discussed um testing infrastructure and Ahmed suggested that we introduce a versioning scheme for eips and uh it was music to my ears and I basically set about like writing down how this could look and so ammed and I have been working on this idea about introducing basically semantic versioning scheme that is mainly based on an EIP specification section um so like a major minor patch uh scheme and Patch would exactly fit into what Greg just mentioned with um like a rata so like if it was a typo fix you can bump bump the patch version but you know that um there's been no serious change um to

the to the EIP um then the minor version would be responsible for if there's any new uh so the other two the minor and major I should say sorry are really um correspond to the specification section so the minor section would be whether um there's been new input or new part of the specification which require additional implementation on clients or um additional tests to cover that and the major version would be reserved for breaking changes to the specification so if implementation just needs to change and it's not compatible with the previous version or tests need to be updated because of that then you'd have to bump the major

version um that's the basic idea I'm very happy to share my screen if you want and give a bit more input um but yeah so have I have two questions so um the first is when do you envision this being used is this like a pre-final thing or a post-final thing okay so um I think this um actually closely ties to the status of the EIP and this is actually a comment that Puja made in Tim's like meta EIP e magicians thread that essentially as soon as you submit the pi you should have status draft um and I think an EIP can stay on status draft until other people are

working on imp implementations but as soon as another team is working on implementation then it would be worth um moving it to uh to review and as soon as you move to review you have to bump the major version to one and after that um you have to follow the the versioning scheme before that it doesn't really matter so much but as soon as implementation has begun uh begun then it's worth following a versioning scheme so everyone is can be on the same page so that if you're trying to compare different implementations you know exactly which status each implementation is based on a VIP all right and and so who do you propose um enforces these rules like uh this doesn't seem like something we could

automate so this would be something editors have to check I think we can automate it up to a point so um I think geub actions could so I mean I can I can share the I don't know maybe it's just distracting to share the link now I can share it later but essentially I would propose that there's a a new version metadata field in the header of standard track cips and then secondly there's a change log section added and I think it's quite difficult to write tooling that catches this exactly that a version that um that a new change log line has been added and that this version matches the version in the header but I think you could get

something quite close but definitely EIP editors would have to be more attentive to this yeah so I think it'd be fair easy to you know require that every time you change the EIP once it's in review you have to bump you have to change the version in some way and add a change log line like that's that's easy to automate I'm more concerned about like how do we determine if it's going to be a uh like minor patch or or major version um obviously in the correct order so so that part is either going to be on authors or editors um to to enforce that and that requires kind of a deeper understanding of the EIP and I'm

concerned that that might be too much technical requirement but I'm if we're okay with it being like author provided um then then maybe we could do something like this I think I think the author should be responsible for bumping this and I think they have a good feeling for whether um this would affect their their implementation or not um of course there will be ambiguous um cases as there quite often not the entire Essence is captured in the specification um as precisely as you might want it as as a as doesn't implement it but um I think in general it should work out quite well um and of course no one's perfect so I mean of course it can can also be mistakes and we can retroactively correct that all right and I guess my my final

question is could we do something where um you have to put like minor patch or major um in your commit message and then it just automatically renders that in the document that would be fantastic yeah yeah that's not that's not in the proposal at the moment but that's a good idea okay um I would just like to add um other like uh we spoke about uh I would like to add like elaborate on the reasoning behind the importance of this uh because I do understand the additional uh overhead uh to both

authors and editors that this will bring but the benefits that this would bring to both the implementers uh and that testers or the ones who are implementing the tests uh are uh are outweigh the the the overhead that that's my belief uh as there was a lot of instances where we would be surprised that a spec in a certain IP had changed I'm speaking as a core Dev who has suffered from this right we were we were just surprised that something changed in an EIP and we would we were not aware of that change and we we and we looked at the EIP

multiple times we just did not notice that change because there isn't really uh a way where change uh the changes are listed right uh what with the EIP that we are proposing not only there is a version that is in specified in the metadata of the AIP but also there is also a change set or like uh a list of changes that uh happens uh on the EIP so it specifies in this version this change happened it would it would make uh that both the implementers and testers life way easier where they would be able to know okay this change

requires my attention or uh this change does not look like it requires my attention right uh because it's it's just like a Lex a a a lingual change or a t a typo fix or a spelling check right something like that yeah I I definitely see the value in this I don't need to be convinced that this would be useful for people I just also don't want to do the work of implementing it so um I yeah it's definitely something we can think about um yeah I think it's a good idea I'm just not sure if we'll have the bandwidth to implement it for a while yeah a couple things uh one this is what

jiub is for um so yeah you do have a record in a jiub of of things that are changing and generally if there's a change in the specification section it's suspicious and should be looked at and changes in other sections should not require any change to the testing um and two this seems like something that's um specific to the core working groups process um and could be handled by the core working group adding a field to the header that they maintain for the

purpose um so that it's not an imposition on the editors at all if if the core contributors fail fail to maintain the header the core contributors fail to use the header the way they're supposed to it's it's a problem among the core developers because I don't even know that review is um part of their stages right now I think uh Dan is not here today I don't think but I think he had a last he described it there was a different set of stages that are relevant um to the Core workking Group having to do with where it was in the

testing process um so I would say we can all agree for example that um when when an EIP reaches the final stage and it lands on mainnet that means that there shouldn't be any changes in the specifications especially uh or or a bump in the major or minor versions uh and only there could be patches to fix spelling mistakes and this would address like the concern uh where we like are final eips mutable like they can be semi immutable

in a way that they can have certain changes but not minor or major changes right uh they can have like spelling changes grammar fixes Etc but not uh changes to the uh spec itself [Music] um and and I do see that this should and it makes sense to be maintained by um the authors or the working group uh but in my opinion it is important that the editors also uh are aware of this mechanic because the the editors

especially like uh if if they are aware of this mechanic they will be able to push changes to PRS for for example uh uh spelling fixes Etc or grammar or proper English fixes to the pr without bumping the major or the minor version and then the testers wouldn't have to recheck the pr uh that the AIP sorry not the pr uh the AIP uh for important spec changes right and and like have to see if they have to rewrite chest or change the tests and at the same time when an uh SPC change

happens uh you the test both the testers and implementers would would be in the no uh as soon as it lands that there there there has been a spec change well um if the spec fails to describe the behavior of the main net um it's wrong and there has to be an atata so again we we have to we have to agree on just what the aratt look like um if the change is not to the specific ification section um then it should not affect the testing if it is to the specification

section it probably does but the editors are probably not competent uh to say whether it does um so it's sort of a lot to ask of the editors to look at a change to the specifications section and decide for sure whether it's a normative change or not no yeah yeah that that totally makes sense what I meant is if the editor wish to fix something in the grammar or in the spelling uh they can do so even to the specification section re without alarming uh uh the working

group uh about this change and there can be just a small uh patch in the patch version bump where you can just up that number by one and mention in the change set under under the EIP that there was this small spell fix or grammar fix right uh which would be like it still seems like that's what the proper use of jiub is for I mean the the thing is as as Dan pointed out out like right now they check the testing team checks the

comet uh hash of that specific uh EIP I'm not sure if they check the check sum of the MD file or the commit hash but either either one would change if there's even a one letter change in thep whereas if so so even a single letter or a spelling check change would require the testing team okay we need to change that check sum that we keep checking or we need to change that um Comet hash that we we are checking for this for this specific uh EIP whereas if if there

is this virging scheme they would just look at the major and minor and if they haven't changed then there is no worry and they don't have to check anything but if the minor or major changed then they would be get involved right I just don't want it to be the editor's job to make it's not it's not I'm not saying it is again I'm not saying the editors are GNA be involved in anything I'm just saying that this will facilitate for the editors to do their job uh in an easy way without affecting the working groups operations right I I think the working groups are perfectly free to add fields to the

header for purposes like this um so the EIP that me and Dan are are proposing are is not only adding a Feld to the header but also proposing that at the bottom of the EIP there is like a history of the changes um H H how does everyone in here feel about adding that uh I guess that's up to the working group again I so working groups don't exist yet um

so if we want to like think about this either we do it today uh before we have working groups or we do it after we have working groups and um today I just I don't think we have the bandwidth to work on this right now whether whether we want to or not um and after working groups I think that's a that'll be the time to think about this but like like it's either going to be me or Panda pip implementing the tooling for this and I you've convinced me that this is a reasonably good idea and then Greg will get your list of changes your at a table um and I think that'll be great um one thing that also I want to bring attention is that this EIP does

not go retroactively into older eips and apply this and try to enforce this it will only enforce this in on newer aips so there is no worry uh in that sense I believe the idea would this um it would be from when this this IPA gets accepted then then any upcoming um edits to or pull requests on existing eips would then introduce a change log and the version um my question to Sam is if if you or Panda don't

feel that you have the time to implement the checks would you like someone else to help implement that would be great yeah um if you'd like you we can make a group on Discord or Telegram and uh we can coordinate that if I'm not sure I have the expertise but I I will see what I can do we can talk about it and I don't want to forget about this I think this is a reasonable way to solve um Greg's like arit table and I think notifying people of important changes is also a good idea so so I'm on board with this it's just it's probably going to take a while

cool are you guys in the um uh EIP editing um Discord Channel or not yet okay um I I think I am uh in the R&D right anywhere yeah just just add me on there and we can set something up okay I'll add you thank you yeah also happy to help out for tooling or trying to find someone who has the expertise to do it awesome thank you so much for sharing this EIP I am hoping that this is definitely going to be helpful as I can

clearly see the use case with the core IPS however I feel like it will be useful for net networking and interface as well I'm not sure if uh it would be useful for ERC giab repos but when this is a proposal a standard it can be adapted by other giup repositories if they would like to but I suppose Victor had some ideas on the ERC side and yeah just wanted to give a few minutes to Victor if he would like to share anything uh on the same context about uh providing support for versioning that's right yeah yeah I think we haven't officially talked about this but uh we've seen a

lot of um um erc's that either has erada needs for um for change like um what we see notoriously uh ERC 712 uh or an virging as well like we have seen that for V1 V2 V3 um and so we were talking about that um but so far we haven't like proposed any specific solution to it I I think the what Dan brought uh is something that inspires and then shows that across the board uh there's needed uh for for just the kind of thing and uh I think speaking of uh versioning there's also this concept

introduced in it which is called best current practice um I think for things like uh ercs that uh a lot of time needs backward compatibility as opposed to EIP usually go in after half work best current practice is something that I I think could be evaluated but yeah again I think will take it to the broader forum and and solicit feedback from people thank you so much um on this okay um so uh I'm hoping um just for not notes taker this will be in discussion

people may discuss it on Discord and of course there is a fellowship of e magician link for further discussion if people have thoughts ideas suggestions and if they are open to help us with tooling please feel free to chime in there and we hope to get this proposal uh implemented in the best way whenever it is possible moving ahead I think we have a few call for input open here uh Sam if you would quickly like to run through those proposals and where we are on results because I see see that dates have already passed for all of these uh yeah so the big one that needs input from people uh and I don't feel closing and I don't feel comfortable deciding

until people say what they think about it um dexan wanted to remove external implementations from erc20 so he wanted to remove the links to consensus and open Zeppelin's repositories um I C like have the suggestion of moving the reference implementation into um our repository since they are MIT licensed and we're allowed to do that uh so this is issue 287 and if you could either um tell me now what your opinion is or comment on it um that would be great this is for rc20 right

yeah so there's two things here uh for one I think it's generally good who have a reference implementation and I'm actually okay that they are being cited rather than they are um a um they are included in our assets I'm I'm fine either way I want to give author more I I for giving Freedom that said erc20 specifically I think it's a very widely adopted widely cited uh ercs and um as as a historical documents obviously RC haven't been following any of latest many of the latest requirement for format and I'm I need we need a much

bigger justification to change it especially um the uh content when there's no mistake there all right so to be clear out of the three options remove them move them into our repository and leave them as is you would like to leave them as is yeah I until otherwise convinced I strongly favor leaving the methes all right how about you Greg and Matt there it is um I didn't follow all of that um we had an older PR just fixing a bunch of

dead links um this is are these links dead at this point or no they're they're live they're live so there's there's no big hurry on this that the document is still totally useful uh yes the the concern is that we are unfavor or unfairly giving traffic to these implementations um as opposed to uh like a neutral like destination what's what's unfair here uh there are you know dozens sorry just to be clear these aren't My Views these are just the views of Dex are in but um that

were unfairly favoring open Zeppelin and consensus over um other implementations that might exist so they're getting like a like unfair traffic because the official Source links to their website instead of uh not i' generally be in favor of of moving it just so far is um you know having a canonical Source it's not going to go away um as long as that doesn't amount to a normative change um so to be to be clear the files would be copied so literally the exact same files that they link to now just in our repository right right so okay so

out of the three options remove the links entirely leave them the same or move them your choice is to i' I'd love to I'd love to see it moved and in general I'd love to see all the broken links in erc20 fixed because it it's a very important standard and with broken links it's it's much harder to understand and when the links are fixable they should be fixed we have a PR that's just been hanging out for quite a while on that um all right and uh Matt what do you

think yeah I'm pretty indifferent on the options I think if I had a very slight heing in One Direction I Would probably just delete the links but I really quite indifferent all right I'll add your comments and then I can close out this uh call for input uh the next one is ERC 20 uh 1271 they want to update the security consideration section um they have a what I consider to be a legitimate security consideration they want to add um but it is a final uh ERC and um this is issue 291 if you guys could leave your comments on here um

otherwise I will be closing it by the end of today um and then finally we have um Dax Ran's in uh informational EIP uh describing flaws in erc20 uh this is kind of like a kind of equivalent to a cve um he wants to add an EIP that says like uh transfer is uh proven transfer is bad and has some flaws and he wants people to know about it uh so this is issue 293 on ethereum cat herters EIP IP um again if you could leave your comments on here I'll be closing it probably by the end of day today um that's about it thanks thank you Sam for that and

um I think the next item here is changes to final proposals and we are joined by H to discuss update ERC 1271 H if you would maybe like to provide a little bit of background and then yeah what are the changes that you're hoping to get here yeah so uh background I'm a smart contract engineer Alchemy um first of all I I don't think I should be leading this um I don't have enough information and I'm not like an author of 1271 or something um so like some background information is that we found some weird HKS with 1271 which kind of constitutes

like a um vulnerability um on our end like we're just trying to patch some of our smart smart contracts as well as uh as part of like the disclosure uh process just want to follow up on um what this looks like but yeah I I'm not sure like who should be taking this issue but I'm actually just here to listen got it um I don't see Fran the on the call but I believe it was a recommendation coming from Victor Victor I wonder if you have any anything to add here I don't know if you so how can you clarify which uh vulnerability are you talking about there I just keep when this call is

recorded yeah yeah prefer not to share too many details but it's uh regarding a replay oh yeah I think that I was the one the one of the the telegram right that is cor there's a telegram group about this okay yeah I think this is not the best venue for that conversation um but I can f up with you on the tegram well I think I think it is a good venue for deciding how we want to deal with these in general um it doesn't matter that this security vulnerability is or isn't real how do we want to deal with security vulnerabilities in general oh yeah that's right yeah we can

talk about that in general the appro the editorial uh sounds good so sounds like we'll take this offline thanks Victor and Sam yes I think uh just to quickly try to get some answers from people here um do we want to update a final EIP so that it shows a security vulnerability yes or no

all right I'll call you out by name Matt do we want to update a uh an EIP with a security vulnerability that was discovered after it went to final probably not all right Victor so just to clarify if we are talking about core EIP and then we realize core EIP has security caveats um I'm to start to think about cases and this specific uh situation is erc's or so I think we will treat them

differently right for core eips um did we ever have uh like security issues is after they they finalized and half work I couldn't recall on uh I'm not sure um I'm not 100% sure but I think with one of the proposals we had to change like one very minus pack after the upgrade um but I'm not sure if that was related to security or

not mhm and uh for the erc1 1271 uh that they discovered or they happen to encounter it um I have not I have not learned that I need to look into what kind of security uh issue they are I think generally uh security issues need to be point out uh the best forum is a question I would be okay of a informational EIP but in these two specific cases I wouldn't like fully associate that with the SEC security flaw like for example

if we one of things that RC71 introduced that um for for sometime they haven't talked about uh for applying um chain ID into the signature or applying the uh contracts being signed into the signature and then um over the course of discussion oh yeah one uh 712 over the course of discussion they realized this could be attack surface now that uh there would be let's say fork of uh Etc right when the when the merge happens um um that was an attack surface and um situation like that and so they started

suggesting adding those and then it usually comes in with as a new ERC saying hey in addition to 722 the S 12 you have to add these new uh domains so it's adding on top of it it's rather not saying hey um if you forget this you can um this is security flaw and likewise for the one that then uh that Dex run has been talking about circulating the idea us7 if you if you send something into a contract that doesn't react resp respond to um well it could get locked there and that's more of a common sense rather than a security

slot I would say because you can do the same for just sending native e and so in these two situation I hav't seen a strong need for updating existing final erc's um but I'm all for encouraging people suggesting their own ER it's just that either you propose your own ERC or you propose a sing Single separated informational ERC erc's but um what Dexron did was doing both um and then I think that needs additional justification all right so on this like to sum up your feeling so far for this particular case it depends on the

severity of the security vulnerability and in General you'd prefer an informational EIP but there are cases where you'd update the the final EIP I haven't seen a I I would be open to updating final EIP with things like it and says there's security vulnerability you really need to change but I haven't seen a real case so far yet that justify such an import change so I would be waiting for it when that comes in and then discuss that okay as a president great and sorry uh just because we're running on short on time uh Greg how do you feel about uh updating 1271 with a security

vulnerability that we're not going to discuss on the call um I don't have an opinion at this point all right thanks Sam do you think it would be a good idea to maybe you know the conditions that we are trying to specify here for final eips can be updated come we can come up with call for input and we can collect the responses from editors who may or may not be on the call asynchronously and we can perhaps in in one of the future meetings list them all for people to follow yeah sounds good all right we are close to an hour mark and I hope we have

covered most of the uh topics that we wanted to cover uh we have added the website link for eips inside then we can find three different tabs for eips ercs and RPS RPS do not have any proposal as of now for ercs we have two proposals moved to the final stat uh to the last call and three proposals move to the final status and uh yeah before we end of this meeting I would like to check uh uh with the members here participants here what do we feel about skipping one week that means the uh next meetings the next scheduled meeting and move the meeting

to the odd week that means to January 3rd and uh that way we will never be in conflict with uh rollup or euf meeting is my understanding I'm fine with that I have nothing on the opposite weeks perfect and any preference on time 1400 or 1500 uh what do we want to go ahead with oh what's the current time like not not today's but the normal time uh so 14400 is 900 a.m. when all cev calls happens and 1500 is like 10 a.m eastern time I'd prefer 1500 but I I know I'm a late sleeper

so all right um yeah so we can keep the 1500 it was a ear as well but because of call conflicts we were trying to move here and there and uh so let's try to have the next Met meeting scheduled on January 3rd at 1500 UTC all right uh with that I thank everyone to join today's call and U see everyone in the New Year in the meantime we can continue discussing uh things on Discord Channel have a great rest of the day everyone thank you thank you guys bye

bye bye thanks everyone bye bye