EIPIP Meeting 106

Transcript

welcome to EIP I meeting 106 this is issue number 340 on E cath EIP IP GitHub repositories on agenda we have some open issues and P requests to take a look uh by the editors and uh then we will look into some other discussion topics uh suggested on uh the agenda by uh different users and authors we'll take a look at the monthly sight and um few other updates from earlier meetings so starting with the first item um that is edits to final proposal I see we are waiting on editor decision the pr number

is 8590 yeah I'm okay merging this it does it require Force merging or we are waiting because oh yeah I think light CLI was not on the call last time and we could not decide on that so do we want to yeah I don't think we can do anything about it okay perfect let me make a note of it so I can ping light L separately to maybe take a look okay 8590 I see uh next few PR are already merged so let's move on to the next not

merged PR which is 8634 on EIP repository and the blocker here is again it seems like okay third approver okay uh I don't know Victor could you approve this can you maybe take a look and I think it requires three editors approval yeah I we could also do a call for input if we really really want to wait didn't we already do a call for input on this or did we not I think my bad it was my responsibility and I messed on that part no we did not do call for input for this

one Sam you know my position I think this a general thing that we should approved all right then yeah so you've approved it it's good to go okay great so the next one is M miscellaneous issues and that may require attention and the first one is oh wow so resolve the EIP 7212 migration can we move it to the later part I know it's going to be a little bigger and we do not see uh the proposal on the call so can we move it to the later and look into other

stuff yep okay cool um the next one is node J action or replicated PR on ERC repository 473 I'm not sure if it is a genuine one or kind of spamming um it it's legitimate like uh we you need to we you need to update our things eventually they'll stop working um when GitHub drop support for the old node.js um but we don't need to do anything until then so is there any message that we can communicate to this uh user like um are

we going to look into it or if it has to be looked after some time we can just let them know I think they are also pointing towards um full request that is 202 for uh send sorry colorized nft yeah so this isn't blocking anything it's just annoying yeah okay so we can just let it open let it be open there yeah I'll get around to it eventually perfect something that cat H herder uh could help let's say someone who's interested in helping out would actually try to um Fork the fork it and test it that they can deprecate the 16s

and no JS 16 and get it work and then come back with with a PR that you can approve rather than waiting for your bandwidth to open up to do it on your own and it also a good training for them do you think this is the kind of task or do you think this is oh yeah absolutely this is this should be trivial um literally just changing a a 16 to 20 somewhere so I don't know if if this can be rewarded and created as an issue then some maybe we can give it to some new contributors yep yeah okay yeah please share that link so I can share with the team as well perfect uh thank you Victor for the suggestion it's helpful I will leave say this is open up

for public contributions P welcome yes of course that's why we want a public issue so people can like look into that we will share the issue and people can look into that whoever is available may be able to work the next one is fix assets redirect seems like a genuine one and it is yeah yeah of course some conversation ongoing except for the last one seems like a Spam it is can it be closed and oh I think uh GitHub has already but

why GitHub has uh already commented that it could be closed oh uh yeah it's just our our stale bot doing that yep y it's fine okay so what is the next step here um there's a couple ways forward for this so uh if we want to just continue on with the repositories we have now um we need to do something uh to like further separate the eips and erc's websit um and once we do that then this will like fall out and be fixed um the other option is we convince me to finish um

working groups and we just switch over to that and that'll also not have this problem okay me which which specific uh context that you discussing about the this thing uh like the issue number it's 243 on the erc's reposit [Music] oh assets redirect yeah yeah so when you link to an asset um in the markdown file right now you have to link to it with like uh EIP in the um name um but when like so natur like but you have to put

it in the ERC folder and it's very confusing for people I see okay no further questions okay so I think both suggested next steps may take time so this issue I see it's being open and staying there for quite some time I would definitely encourage you Samson to maybe take out time and work on the the working group page that you were creating for rendering all these proposals it would be nice so that that's more a question of like do we as the editors want to move to that um not it's it's not really

up to me to work on it at this point it's do are we making that change and if so we can we can do that Sam there's regarding two options are all great but it would take time the third option is actually enable the real link right if if like I saw that it's sec2 Das V2 if it's a legitimate external link like they don't even need to put a PDF into into our repository unnecessarily right so yeah if we approve external link with these things we don't need to wait for that so what yeah that I'm using that as an argument that we should

be more flexible in in external link yeah I I understand uh going back to Sam's question I think Sam the mo main blocker there was like what kind of working group we are planning to have and uh I think the conflict was on like should working group be based on repositories or not um I think there were two proposal one by you one by me and uh this was the main point of conflict I suppose um do we want to take it on right here right now or is it something that I should add explicitly on the agenda for the next meeting and maybe invite editors to make

a decision on yeah I think we need to do this like with a write up and uh like have people make a decision because I I don't think we're going to get everybody on the call to talk about it ever so okay okay that sounds good then yeah we can look into some write up and maybe ask um start asking questions around try to collect some thoughts from editors as well as other people from the community and we'll try to put it together sorry for the delay I actually find that you're not conflicting each other actually like we can have a higher level let's say governance group and or um rep repositor group and then any

other people who want to collaborate can can form topic Group which could be like subset within a repository or across different ratories doesn't matter it's a topic that people want to collaborate so I I don't see that it has to conflict these two proposals can coexist actually and can combine very well let's try to add some more thoughts to the proposals and if possible we can come up with a write up and see um where we go with this one okay yeah I think I can do that Sam perfect yeah perfect cool um okay let's

move on the next one is um the next one is closed of course so we move on to issue number 8718 the issue has been deleted perfect thank you and 8717 oh wow Sam looks like you have already bought it all of them yeah yeah perfect perfect thank you so much uh so that's all about it uh let me check the last one if it has gone as well yes so I don't see the call for input deadline has reached for the only call for input that is number 343 U so yeah perhaps we can move to the next section and we are also joined by

Dex Ren so the first item on other discussions is security issues with erc20 and erc's in general uh dexan has added some comment to this agenda dexan I would like to invite you to maybe give some background and uh yeah share your specific questions how we can help you hello everyone uh today I'm here with Dario Dario works for your support we also implements the ethereum viral machine in its smart contracts as well so whatever we are going to discuss here is also relevant for your community so I would like to start with a summary of the history of the problem that I'm going to discuss because quite long uh so we have anc20 standard in ethereum it

was developed in 2015 at that time there was a call stack De Bu in ethereum virtual machine so in order to make token not affected by this bu there were two transferring methods implemented in the year C20 one is designed to transfer tokens to externally owned addresses and the other is used to deposit tokens to Smart contracts in 2016 the call St deps B was fixed but fc20 specification was not upgraded obviously and in 20177 I was researching the erc20 and I discovered that it lacks error handling if you use a method designed for transferring tokens between externally owned addresses to send tokens to a Smart contract then instead of getting an error you will successfully deliver

the tokens to the smart contract but it will not be recognized as a deposit as a recipient contract and you will effectively lose your money I have reported this problem in rc20 in the rc20 finalization trade on G H you can still find one comment there however Fabian V replied that they are finalizing a20 anyways in 2017 I have created an alternative token standard year C3 which was designed to solve this problem and in 2019 uh there were about2 million of dollars worth of2 tokens lost because of this issue that I discovered and reported in 2023 I wrote a script that calculates the amount of loss

tokens and uh after the result of the SC it was possible to conclude that there are at least 80 millions of dollars worth of erc20 tokens slot to this issue that I reported seven years ago at this point I was trying to escalate this problem in 2023 you may remember my proposals and my general proposal was to add this description of the problem to the ec20 security consideration section in the text of the ec20 uh if I remember ly at some of the EIP editor calls my proposal was voted out by Greg cvin uh when he stated that the problems of money losses caused by the design of rc20 standard must be

described somewhere outside of the rc20 standard text and I was told to create an informational EIP to describe this problem of rc20 I have created one but it was subsequently rejected by EIP editors I don't know the reason but uh we can find it on the GitHub it's still there uh so here we are right now currently it's 20 24 yesterday I ran my script again to calculate the amount of lost tokens and uh as of today there are another 20 millions of dollars worth of your tokens lost which were not lost on 25th August 2023 uh so if we will take this uh

amount as a key performance indicator of the G C's idea of how to handle the problems of disclosures in E then this idea quite fail because uh people keeps losing money to well-known issues it was reported seven years ago so now let me explain what is done wrong uh one say no those requirements that I'm going to highlight are not my personal invention I did some research on the evolution of C++ programming language standards and I found some documents that describe the workflow of iso C++ committee uh and uh this is a practice adopted by this

project uh one of the largest project with largest development histories I think it's quite good to link so the first one exposure in order to solve a problem in a standard the problem must be clearly communicated to the implementers it is very important not only to communicate the problem itself but the severity of the problem problem as well because people tend to treat known issues as something they don't need to worry about I have a great example here for you uh in 2023 I've reported to open Ze that the pure implementation of rc20 in the course is prone to this uh uh problem that I described and uh at the same time it

fits in critical security vulnerability criteria in their open Z backround page uh they that even though it does fit in critical security vulnerability no back bounds will be paid obviously and uh this is because it is a known issue and it is reported long time ago so they are not going to do anything about it uh if irc2 standard itself will not change so in fact they have a noncritical security flaw in their contracts and people keep losing money because of this but they place a secure label on their smart contract repository as if everything is good and you can observe it it's still there uh so we need to make it very clear for the implementor that a pure

erc20 implementation will inevitably cause their users to lose money as a result they need to implement a sort of modifications of on top of the base standard to prevent this and this is more than possible and here comes the second requirement to solve the standard problem according to ISO C++ committee document Alternatives if we are stating that there is a problem in the standard then in every place where the problem is mentioned and in my opinion it must be mentioned in every place where fc20 is mentioned on ethereum resources uh there must be a list of actions that the implementors can take to either mitigate it solve it or avoid it unfortunately it's not possible to

solve the problem for ec20 tokens especially the existing ones but it is possible to implement a number of modifications to the transfer function that would prevent it and in newly created versions of vc20 tokens it is possible to mitigate like 80% of the damage that it can take it can inflict to the users it is also possible to avoid this issue by using alternative standards and here comes the third requirement to solve the standard problem upgrading processes if one standard must be replaced by another one then the upgrading process must be coordinated currently in EA process there is no such thing as coordination of an upgrading

process there are no tools for this and as a result we didn't see any major standard upgrade like uh rc20 is the first standard that emerged in ethereum and it has a problem that fits in critical security vulnerability criteria according to open zein back bound and it's still the mainly used one I'm the also of an alternative toking standard so from my side I'm working on ERC 7417 and I'm trying to change the Paradigm one token one contract where if there is a USD token on ethereum then every other us token that you can find is this scam so with IRC 7417 there will be one version of each token in each standard

and effectively uh there will be rc20 usdt there will be erc223 usdt created by a special contract uh yes I will add the link to the documents and the comments uh after this call thank you for the reminder uh so I will continue on the upgrading processes description uh as the notor of the rc23 uh standard I am developing an upgrading process that will allow the rc20 and RC 223 tokens to be converted from one to another but imagine that you are the implementor and uh if they is

one standard that everyone uses and uh it is supported by most of the exchanges and F2 is supported by all of the exchanges and it's the only standard that's supported by exchange it is supported by wallets then why would you consider any alternatives uh what can be the arguments to convince you as an implementor to even start thinking of using any alternatives uh I had some discussions with the implementers I can also provide the links uh and the best argum for the implementers can be written in the text of this exact EIP so everything that is written outside of the text of the EIP is treated as someone's opinion and not

a valid argument to start doing something for the implement this is important to understand and uh one note regarding Greg Colin's proposal if some object is particularly dangerous then the danger warning is normally placed on that object for example there are some dangerous household chemicals like bleach and you can place a warning message don't drink bleach on a bottle of Coca-Cola and pretend that you did great job warning people about the dangers of drinking bleach if bleach is not designed for drinking then you please don't drink this message on the bottle of Bridge to war the pill and this kind of explains why Greg Colin's proposal doesn't work and why we have an extra 20 millions of

dollars lost after the implementation of the proposal and uh now I would like to propose something that in my opinion can solve the problem or at least uh reduce the damage to the ecosystem so the first proposal I would like to revive the erc20 vulnerability disclosure EIP that I was working on and finalize it we can revise the old one I can write a new one it doesn't matter and we need to add the warning to the security consideration section of ERC 20 text as I initially proposed currently a year pass 20 millions of dollars are lost I think it

it's time to change the strategy may I interrupt for a second yeah so I think the prime example of why we can't or won't do that is I believe that your EIP 223 has a security flaw in it which is that if you send tokens to a counterfactually deployed contract there's no way to know uh ahead of time and the account will be locked and those tokens will be lost so obviously the only way to fix that would be to require a signed message from any account that uh you're you're transferring to so I want to put that warning into your EIP uh well I would say that this is not a problem of my token standard this is a problem of how ethereum treats addresses

for example here is Dario from OS and in EOS addresses do not exist before you do some special action so it basically has some built-in naming rice and uh this is not a problem of a token standard this is a problem of how ethereum creates addresses right but it so on ethereum 223 can't detect counteract deployed contracts and so they the tokens might be lost so that is a security problem and now I believe that should be added to your EIP so how do I add that to your EIP in our process or in the process that you're describing uh wait a minute uh why would you think that this is a security

problem of my standard uh my standard is a copy paste logic of the A and uh do we add it to the description of how a Works sorry your your EIP is a copy paste description of what um the logic of erc223 is based on the logic of e the native currency of eum that it's still a problem though like you can still lose tokens by sending to an address that is eventually becomes a contract yes it's obviously a problem yeah I agree fully that this a problem but this is a problem of ethereum not this this is a problem of addresses generation not the transferring method

it's a different problem yes it is a problem but different problem so I think what I'm trying to say is that any process that we create for modifying final eips needs to be able to account for these kind of disagreements and needs a way to resolve these disagreements that doesn't rely on editors being experts on what's a protocol problem versus a standard problem yeah and this is the next thing that I was going to discuss I have a propos perfect perfect yeah uh I recall that we had a discussion a year ago regarding whether EIP editors are supposed to make these actions and act as Security Experts to determine whether something is a security problem or not uh I would propose that uh there can be

a simple rule if something cost a veryable loss of funds uh after a certain amount like 10,000 of dollars uh then uh it can be added to the security consideration section we don't if this is a security vulnerability or flaw or something else if something has CA a verifiable loss of money that can be detect by simply going through transaction history and open blockchain explorers then it can be added to the security consideration section of the corresponding EIP I think that EIP editors can do this without any specific requirements for their security skills and going through the blockchain history

and reviewing if something was lost is not that specific and if something cost the loss of money after there is a precedent you add it to the security considerations so if the situation that you are describing here will happen to erc223 tokens once it happened we can add it to the security considerations and is there is there a particular dollar value you're suggesting or could it be one way uh sorry I didn't understand the question oh sorry uh is like is there a particular dollar value that you're looking for or can it be as small as one way I think it must be something like spam because if you will put $1 then

someone can artificially throw $1 worth of Assets in this situation and nobody will sacrifice 10 thousands of dollars for this to blow out the specification and uh add the problems that naturally never happens so I think it it must be smaller than $1 million and uh a little bit higher than something that an average person can sacrifice to gain a competitive advantage in the process so you're say like you're kind of describing we put a price on getting a competitive advantage or in theory we can do it as little as

$1 for but it will not be representative you will blot the specification with the issues that you as have to handle but it's up to you I am just proposing a way of how we determine if something is a security issue or not in theory even if you lose $2 it's an issue the question is if it is worth your editor time to investigate small issues or you need to focus on something else if you will be investigating all the issues it's fine for me uh I'm just anyways like uh is is at the end of of your like discussion or or do you want to say I don't want to cut

in too much yeah I had three proposals so the first one is to revive the old vulnerability or security flaw description EIP that I was writing and add something to the security consideration section of year20 implement this role of how we can add new security considerations based on loss money and uh I'm here to ask for feedbacks uh because it seems that I'm championing the solution of your C20 problem so I'm here to hear feedbacks and maybe some else ideas of what else can I do to facilitate the solution and who else I can contact like this thank

you thanks for thanks for coming I I appreciate it I think you did a a really good job like articulating the problem and it's good to have a record of that in our record in um so thank you um as for like I think the problem is more that there's like a missing layer in ERC governance or or in ethereum standards governance so we we deal with documents right like we um just make sure they follow a certain Rule and and such and then um we try to be as objective as possible uh which is kind of different from other standards bodies like uh the C++ standards body or um w3c or or any of the other ones who are generally a

bit more opinionated um and I think we're missing this kind of um opinionated layer that sits above the documents um so in the core development world that's all core devs um so for example like I can make an EIP that uh I don't know sends all of The Ether to my address and get it through all of the document stages get it to final uh but that doesn't mean anything it just means that the document can't be edited anymore um there's this layer above eips all core devs that kind of manages um what they're implementing and what they're not implementing that layer is missing for ERC development and um obviously

it's hard to kind of Envision one existing there um just because there's so many different competing actors and and such uh and I think very hard to say like you know you better not Implement erc20 anymore or else we'll fine you or will like um so I think that's the problem is that we don't have this kind of opinionated governance layer and it's it's not necessarily that uh something that we can solve at our you know document Centric layer but I I'm definitely open to other opinions on that okay so I will say that I disagree with your of where the problem Li because if you can make a proposal to

change the protocol of etherum yes it's up to implementers to decide and it's up to the keepers of consensus to adopt it or not but uh here we are talking about something that uh Community implementors will look on and you are not providing them with sufficient information to make a proper choice you are silent ing the problems you are not intentionally sing the problems I think but the problems that exist for years and cause severe damage to the customers are not highlighted they are hidden from the implementers and when me I'm a security auditor I own a security auditing

company when I am stating that there is a problem in the standard they are treating it as if it is my Auditor's opinion it it's it's not my opinion already it is discovered it is discussed it is documented it's not an opinion already it is the effect we can verify it by transaction history and this needs to be included in the documentation and you are governing the documentation so that's why I came here to make some proposals of uh what can we change on the documentation governance level so that we security Auditors on the social level will gain a proper argument to

convince the implementors who are too lazy to do the research themselves to make a proper Choice well thank you Dix thank you Sam I he the main problem is about the governance layer here as Sam very well put it out we do not have um some some place where we decide or maybe can make a decision on what would go in or not the standard repository that we are having right now is open and open for all as much as I understand the concern and I shared the concern as well uh Dex um I am not very con very much confident that we have a solution right away but

we can definitely consider those three proposals that you have proposed today under consideration and would try to work on that however um as you have also mentioned in the issue itself the document shared by Sam Wilson about you know brainstorming for security disclosure as we say that this EIP process or the erc's those are available on the standard are mostly author driven we definitely can help them understand the issue but adding such warning um has not been accepted so far far I'm just trying to explore if there are any

other venue where we can add it without uh disturbing the current uh organization or the template that we are following for proposal I do not have a straightforward um next step for you but what we can do is like if you want to like as you have already Champion 223 and it is there for us now if we want to propose something new we can maybe increase discussion on that side or if you think we should involve more parties maybe some application developer who would like to spot the idea of getting uh this thing documented in either E1 or erc20 I'm open to have a specific

discussion on this if you would want to uh well uh I'm not here to propose something new I'm here to state that what was already proposed and rejected was the proper version because I made a proposal Greg Colvin voted it out and made another proposal his proposal doesn't work we can identify it by the amount of lost money and it's time to change the strategy in my opinion and uh I'm here to basically ask if it is worth to revive this EIP that I was working on a year ago and if uh in the light of new events see lost money can you tell the number of the EAP you mentioning here if

it is not 223 I can find it I'm not sure right now I will find it and attach it in the Common Thread alongside the documents that I mentioned of course uh yeah that I think would be a good uh start again for bring this bringing this conversation back if it is backed by a proposal uh already either in draft or stagnant status even if it is there we can perhaps start making discussion on that but the main blocker is um U main blocker with not updating erc20 is when a proposal move to final status we do not want to make any changes to that and if we have something new we can perhaps

make room for that but we want to avoid updating erc2 as much as possible yeah but uh the problem here is that uh you do not allow eips to go to the implementat before it reach final State and uh bugs and problems are normally describ discovered during the testing state so in your system you don't have a room for testing period proposal reached final and at that time it becomes immutable and only at this time a new issue can be discovered when it is already immutable well so last call would be the the time to start implementing an EIP and then reporting

any issues while you implement it yeah I understand we do not have like proper testing devet and public test net kind of thing as we have it for core proposals that's not existing for ERC and that's why we have been stating it as a standard and authors should Implement on their own risk what we are trying to provide here is to make sure the standard that a user want to make available for the community has proper uh template has proper checklist and they have done their due deligence they have documented the specs in a way it should be useful by any other

implementor to implement in the project EIP editors may not be able to verify whether this has been tested 100% or not yeah I understand but uh the problem here is uh why is the security consideration section immutable uh I understand why the specification is immutable you can change the standard which is already in use it will break the compatibility with already existing Solutions but uh security considerations can be append only that's a fair point all right um I think um security consideration is definitely for implementers support so

they should be aware of what what are the things that they should be mindful of I hear your um thoughts over there may not have again may not have immediate solution for that but I would highly recommend you to come back with the proposal that you have uh anywhere even if it is in stagnant status we can perhaps bring it back and start talking about it and see if that would be helpful all right thank you I will definitely revive this proposal and I will attach the link to the comments yeah if you could add it that would be nice to have we can perhaps

take a look and if that is like something uh in the stagman status already and you want to revive it please make a new PR to bring it back to active status we will take it into EIP editing office hour to make sure that proposal is merged as active and then we can start discussing it actively on its Fellowship of ethereum magician page to see what we can do next very well that was a big chunk of uh our discussion today I know we have a few other items to go over um and there was also a request from 7212 te to see what we do about it um like uh we know that there are two proposals one is 7212 in RP

GitHub repository and there is the other 1 721 to an EIP GitHub repository to add some context when we made the split of EIP and ERC we moved all the erc's out of the EIP GitHub repository to the ERC GitHub repository and 7212 was one of those proposals which was moved to the RP GitHub repository and here the status shown was moved now the proposal 7212 is in final status as per r GitHub repository and they are also trying to push the proposal to the final status on EIP GitHub repository that has brought some

confusion and this is being done because proposal 7212 is being considered for Petra upgrade I think uh people are getting confused uh whether they can have the same number on both repositories I would be curious to hear thoughts of editors and we should keep it in mind that the number allocation process is uniform across all these repositories so so far we have only one number existing in one repository we do not have duplicates of that our call for input for it that would be nice yeah and yeah another point that is for

consideration here is the pre-compile address is different in R 7212 and EIP 7212 so we should highlight that as well that means the specs are not 100% exact same they have one minor change and that change is in specs section well thank you Sam uh I think that is also up for all cev meeting so if you could create the call for input we can also share it with people um there uh developers people if they have any to add although this call for input is specifically for editors but we can definitely collect their thoughts as well okay um couple of other

items this I think we can perhaps skip it because we don't see too many editors here but we can get into the other one okay discuss blockers to merch a pull request so the last week I was in um edes marala an event uh in California and I got a chance to talk to too as well and we were discussing the issues that EIP um Team think that they have these issues with the EIP editors like where they would need support from EIP editors so uh we looked into uh the pr blockers it seems like on a broader level we have like four different kind of PR blockers number one is waiting for editor number

two waiting for author Au third we have lot of open PR which are into draft status but haven't been merged there are a few of course more uh which are based on CI test spending so there were two issues that I think this group may be able to support one PRS which are waiting for editor and second PRS which are made for new draft on the Discord channel of e R&D also we have received one PR suggested by one of the developer and he's having this question like what should I do to get this proposal merge as

draft my question to editors here would be like can we think of some maybe an estimated timeline for merging draft proposals but when we are um suggesting this timeline we should keep it in mind that draft proposals are very basic it need not be 100% like correct because for that we have the review status but if we can come up with certain timeline that way it will help us reduce the number of open poll requests as well as it will give the confidence to uh Cod developers who are trying to make a proposal for consideration in network upgrade that they are

there uh I see I noticed some of the PRS which are in draft step St us have also been moved to stagnant but I Tred to list out some of them which are out there please uh share your thoughts on how we can minimize uh this weight time uh sure so um one idea that my partner Nikki had um who isn't here to present it unfortunately but since it it came up I'm going to talk about it anyways is um this um it is a uh rust tool that pull pulls the repository and puts all of the pull requests into the order that they require attention by an editor um the algorithm is basically

like find the oldest author interaction that is after an editor interaction and then sort by oldest first uh so this can kind of give you an idea of when your P request is due to be reviewed like how many things are in front of you um and it also makes it a lot easier for editors to um find stuff to work on instead of having to go through the whole list um so this is one idea we had to kind of a give authors an idea of how long they're going to be waiting and uh B make it easier for editors to find out what to work on um yeah so that's kind of one idea I guess it's pretty interesting like uh how we can implement

this what support we can provide that this tool is made available for um either on the EIP repository for editors to maybe take a look into yeah so the my end goal is to have this is part of the build so that every time uh you know somebody publishes the website um it'll update this and kind of just let you know how many things are in front of you that would be awesome to have so you did mention that it would be a part of build and someone publishes on their website um by that would it mean that people may need to look into eips .org to get a feel of how long is the wait time or is it something yeah exactly okay perfect sorry Victor you were saying

something oh no I I I like that this idea a lot uh I think uh having this information will help at least give a um give an estimation for how long it would take for them to to approve but also I think in general having um a statistic published like every time get from what place I know that meip Insight already have that information maybe we can also publish that to get a general um General kind of estimates but for what uh uh Sam says like for one specific EIP instead of uh in in addition to um publish like who what other eips are out there

waiting for attention um we can't have a very good estimate unless we have there's a there's a expectation of let's say cue or ordering or scheduling of who is going to work on them right even if this EIP could be in the queue some other like EIP editors or other people might be focusing on other eips not yours which means you can wait longer right so how do we figure out which one to schedule which one to prioritize is there any ever a prioritization approach I think that's a question I have like how should we what's your opinion on that I think it is prioritized by date like if I understand that correct s so

in this tool um yeah so it so okay for editors in general I would very much recommend just picking the oldest EIP and trying to get that one merged and uh if you're blocked on the author move to the next oldest one and don't prioritize in any way other than that because it gives the uh the appearance of you know non-neutrality um but that that's just me I'm not going to force anybody to do that uh The Tool uh specifically does it based on uh the oldest author interaction so that's like a commit uh a comment um an edit like any of those things so the oldest interaction by an author of The EIP that is after uh the most recent interaction by an editor and

that's how this list is prioritized I agree with your approach I think that's actually a good good good way at least for the pure editing part yeah exactly it just means like the oldest the people who have been waiting the longest um get interacted with first that would be awesome to have because as I was mentioning earlier I have seen some of the proposals which are in the draft status and has been moved to stagnant because the weit time was a little bit over than expected do you mean uh like stale or do you oh Oh you mean like the EIP was merged as a draft and then it wasn't Mar yeah no

those are the worst I try to so my editing routine is look through the recently closed things and unclose the ones that were uh that haven't been reviewed yet yeah yeah so I have tried to uh maybe uh share a list here on the agenda which are some of the open um proposals for new core EIP and networking and interface perhaps I'm not very uh confident that all of them are core but definitely I have taken all of them from the EIP GitHub repository and it would be nice if someone can maybe take time and maybe able to merge some of them has received some attention some inputs from editors and they all all of them have a number

but they aren't merged yet so if on the draft level we can just make sure that uh the proposal is abiding by the template the EIP template they receive the uh real number and it can be merged so these people can talk a little bit more about it and we can get into indepth review when the status is proposed to be changed to review sure I can I can take a look three okay perfect I think that would definitely help providing some confidence to the core development team that EIP process is not completely broken editors are there they are reviewing it just that the number of

proposals or PLL requests for review are a little more than than the number of editors we have here to review all these proposals and uh if I'm being completely honest I don't review eips anymore I kind of hope that Matt and gajinder uh do those um I haven't I haven't done ANP in quite some time that's not bad even like we have two people to maybe take a look at into EIP so I unfortunately I'm not seeing them on the call today so we'll try to talk to each one of them as well uh if they can follow the same norm and may be able to merge uh these proposals and not

get involved with reviewing uh because the main issue that was highlighted to me when it gets on to review on the P request most of the conversation are there on the pr itself and they are not being captured on the fellowship of ethereum magician that way some people may lose some context so it is a suggestion that we should merge The Proposal as draft so whenever they are having some discussion it would be moved to the fellowship of eum magician not on the initial draft bll request yeah that's a good good point and also Sam I I some of the erc's I like to merge but I saw that you

already have some comments so we're waiting for authors to to kind of come back um I wonder if some of those uh comments could actually be given after uh the the merge of draft because a lot authors need them to be published as draft uh and then sometimes it's just a a very basic gra grammatical change that doesn't affect understanding and completeness of the draft for it to get feedback I wonder if it if it's okay I I go ahead yeah wait waiting for them to come back with the with an updates for as as long as I haven't marked it as um request

changes um like as long as like there's the three ways to reply right there's approve there's comment and there's request changes so as long as I haven't request changed on something you can like approve it if you want I won't be mad yeah so okay so as long as it's not a request for math right if it's just like suggest the change that's fine right yeah exactly like if it's not the red icon you're good to go okay yeah makes sense I I think that's some of them seem um well ever since Matt doesn't want me to Ping people to say hi are you still working on this because of course that also reset the timer for the for the Bots which is I think Matt's ask is reasonable I like yeah that's another

consideration let it stale or let or approve it yeah yeah yeah we can perhaps discuss some of the uh options how to uh bring them back uh for discussion and things like that I have couple of more points which we wanted to discuss from the meeting there uh but in the essence of time we may want to move it to the next meeting but uh from this meeting uh for note takers if I can conclude it in a way that we are open to the idea of merging the initial draft as soon as possible I know the number allocation is done with within 24 hours and if we can just try to merge um draft proposals within a week's time at the max

definitely before next CoD of call or next developers call ACDC or acde uh that would be helpful and the same thing can be applied on ERC side as well we would try to move most of the discussion out of the GitHub repository we'll try to push it onto the fellowship of ethereum magician page whatever suggestions recommendations we have for authors all right um I know it's about time so uh I wouldn't go through all of the details of vs inside we have added link um we have some changes seen in the month of June not major changes coming up in July because today is just third of July people may take a look at it and uh yeah I think that would be all yes I think there was this make a call

for input for uh PR number um 839 zero was there which I was supposed to do unfortunately I did not do it U maybe I'll try to do it this week anything else anyone would like to uh share add for the next uh agenda item very well well thank you everyone for joining us today I know some people got some resolution get to the next step but we will try to solve uh issues as we are getting in we definitely have our next step we are open to bring up anything in the next meeting if if anyone has any thoughts new ideas that they would want to share or discuss with

their dets so once again thank you everyone for taking out time for this meeting I would welcome all of you to share your thoughts comments in the E caters Discord channel on the EIP editors Channel you can always share your thoughts there and add any item for the next meeting as well all right thank you everyone have a good one