Skip to content

Latest commit

 

History

History
241 lines (127 loc) · 48.7 KB

Meeting 024.md

File metadata and controls

241 lines (127 loc) · 48.7 KB

EIPIP Meeting 24 Notes

Meeting Date/Time: Wednesday 13 January at 15:00 UTC

Meeting Duration: 1 hour

Moderator: Pooja Ranjan

Notes: Alita Moore


DECISION ITEMS

DECISION 23.1: Remove linked EIPs on EIP1 that are dead, none of them are critical. 39:51

ACTION ITEMS

ACTION 23.1: James is collecting ideas for single source of truth; which, he will report on next meeting 9:02

ACTION 23.2: James is working on hardfork information into eth 1 specs repo 11:15


1. Single Source of Truth for EIP

Pooja - welcome to eipip meeting 24. the first item on the agenda is single source of truth for eip i think uh bent he was looking into this event if you may have any update on this

Brent - yeah i've been working on one of my action items in our last meeting was to start a google doc to collect some of the information and try and get a handle on what what needs to be done for all this and i think i'm having some uh creep of what this is supposed to do because i've added in the yellow paper and and and other so there's multiple wikis depreciated and then there's githubs that control those wikis and so i'm just trying to collect all that stuff trying to get my head around all that stuff but anyway i'm making progress and working on all that stuff to try and figure out how we can get some of this cleaned up and standardized and um and and also the next item on the agenda item is figuring out how to do the spec and and that's kind of also dealing with the yellow pages and stuff like that and so so anyway yeah i'll put let's see there's the link to the um here here's the link to the google doc that i'm working on i'll stick that in the chat so if anyone has any opinions if i'm having too much creep and responsibility or or if they any ideas of what direction we should push basically my goal is to have that document to collect all that kind of information so anyway making progress hoping to continue on that hopefully we can it's mostly probably for my education to understand what all the what all is important to everyone

2. Discuss the possibility of creating a bounty to populate the Eth1.0 spec repo with useful information on the Eth1.0 chain.

1:56

Pooja - all right um as you mentioned the next item is also like uh linked with this we were talking in the earlier meeting about maybe creating a bounty kind of stuff to get uh at one dot post spec populated with important information including yellow paper and all uh i'm not sure uh james uh would you like to add more to it like how would you want to see it and i believe you have some thoughts that you shared in the earlier meeting

James - the i think it was it first came out of discussion with micah if i remember correctly but just in general there's a space for each 1.0 specs to be a collection of useful information and figuring out what that is and then getting some kind of bounty or team to be able to do it um i don't remember totally uh like it had to do with something with collecting this like the the state of certain things so developers would be able to find them easily

Pooja - i think ah lightclient has pointed it out for i mean like he also mentioned it sometimes um like what should be added like if you would like to add something here too

Lightclient - yeah i mean i think it's a spectrum you know it in the ideal world it would be great if eth 1.0 specs was similar to how the eth two specs repo is laid out and it has this you know python spec that has everything up to date with what it means to be a consensus client for you to mainnet and there's not really something like that for eth 1 we have the yellow paper but it's the yellow paper just isn't very approachable even people in the space have trouble like really under like if they want to understand something or read something but it's faster often to go to geth to figure it out to actually look at the yellow paper so if we could build something like that that would be huge it's hard to find people who have that kind of um you know understanding of ethereum or like willingness to understand that much about ethereum and write that out so we might have to settle for something in between and i'm not sure like what exactly that would look like

Brent - yeah i mentioned to um puja earlier earlier earlier on we since the ether winter is finally over jim and i spent about 10 of our time helping with this kind of stuff but that's not near as much as i'd like to but anyway so we're thinking of possibly hiring on another partner to work with jim and myself and basically his role would be 100% to spend time on exactly this to be a member of this team along with us we're hoping to find something that would that could be technical to help with that but anyway yeah and i'm just trying to get educated on exactly what all's involved and what would be perfect for the ideal world and push towards that

Lightclient - i mean to me i think that a great first step is just to create a comprehensive repository of eth 1 information and to me that's you know number one the yellow paper that's you know if we can make that if the yellow papers new home or something like that that would be that would be helpful and then to to document the hard forks in a single place and the changes that would be in each hard fork i know that we have like these hard fork metas and stuff scattered around but i think one of the best resources like a my crypto medium post that has this information and it would be nice if we had this as a more official document

Brent - yeah yeah appreciate all that information that's the stuff we're trying to collect and pushing towards exactly what you're describing

Pooja - on the hard fork documentation um we are in touch with the ethereum.org team and possibly we'll be adding a page over there so that they would display all the information of earlier hard work and it would be easier for a new community member to just log into ethereum.org and get this information there so yes we are working on that

James - is there others is there i i would like it's it's okay if we don't do this today but some more brainstorming on stuff that could be on eth 1.0 specs that we could collect that would be beneficial for developers of on maintenance ethereum whether it's client devs or its contract devs because there's some there's some room for a team to be able to help with that and it might be something that we might be able to also get resources on resources with too so getting ideas on what needs to go there would be a good way of defining like the scope of what kind of team or work would need to go into it

Micah - to echo Lightclient i think it depends on i guess the side the funding you have available so to speak or how big this team is going to be if the team like if we think the team will be big enough to handle doing everything lightclient said that i would say just start working towards that if we think that the team will not be able to handle that i do i agree like i said that there are smaller things we could take on that are still useful do you have any sense for like how much resources you think we have access to like if it's just the people in this room and i would say let's take on something very small because we do not have indicators that we have a ton of time here

James - yeah i think it would be more than the people in this room but i don't have a sense of what would be beyond that

Brent - yeah as far as resources go what what because like i mentioned um i'm going to put the current job description we have for the person we're looking for and hopefully we would have someone that could push towards being what you guys described i'm going to add the job description that we've started but if if you guys could um let's stick that in the chat anyway i'm thinking of passing this around and and and but basically there's it's basically a professional cat herder with focus on this kind of stuff and and of course he would be an employee of canonizer.com and so to me one of the important things that i would like to do is help with this kind of stuff and consensus building around controversial eips and stuff like that i feel like that's what we're good at and that's what i love doing and so that's what we want to push towards but anyway so so there so though that will be one resource but if we can get some other funding to get some other team members to help with that stuff too just fyi

Action 24.1 | 9:02

James is collecting ideas for single source of truth; which, he will report on next meeting

James - cool uh other people have ideas well i'm starting to collect them so maybe next week i can next uh eipip can uh report on sort of what i've collected so far next meeting i mean

Micah - cool sounds good i think for for me the things that i constantly look for that like it's smaller than all of things um is consensus data structures and the wire protocol because in theory with just that i can build a thing that at least communicates with the rest of the network and maybe it's not consensus compatible yet but at least i can communicate and that's it and i'm always the first step in building a client and making sure you can communicate with other clients and then after that you want to communicate in a way it doesn't get kicked off um and so i feel like the shape of the different data structures like what is the shape of a block what is the shape of a transaction what is the shape of the receipt track um and then like that p2p i guess would be the other one that p2p currently i believe lives a wiki somewhere um with no version control last i checked

Lightclient - it has a um the repo ethereum slash the p2p that does have version control

Micah - oh does it okay

Lightclient - yeah that's the specs repo for dev p2p

Micah - it's been there before too okay uh so yeah so yeah that if you're looking for a smaller chunk to bite off for eth 1.0 specs that's my vote for where to start is data structures and network maybe we can just hold the p2p in or something

Pooja - okay so i'll keep this on agenda for the next meeting as well maybe uh by then we we can have some more clarity on it how we would want to proceed

Action 24.2 | 11:15

James is working on hardfork information into eth 1 specs repo

James - um okay um and lightclient thought the hard fork information's been on my backlog to do into the east one specs repo so that's something that's on my plate to get done

Micah - i guess that's perhaps another question um for for you james is who is the target audience of this repo is it current ethereum developers looking to maintain consensus compatibility or is it new clients wishing to like write a new client from scratch

James - to be determined but that i think is one of the first steps to tackle i guess is deciding that

Lightclient - i think it's more often than not that existing developers are trying to use these resources just to answer questions about the protocol whereas a new client developer you know a new client being developed it's just very uncommon

Micah - very true though part of me wonders just to play little devil's advocate is the reason it's so uncommon for to have new clients because we have no place for them to go to look i don't actually believe that's necessarily true just a thought experience

Brent - and also there's people like us that what that want to make because we we need a tool that will like given an address how much ether was in that address at any point in history and so we need to write a tool that can do that but it's kind of how do i find the spec and figure out how to do that and stuff like that's so it's not a client but but it's a tool to do some things like that

Lightclient - but i think vulcanized db can do something like that if you haven't looked at it before

Brent - oh okay i'll check into that thanks

James - the vulcanizer would probably like something like this to be able to build what they're building or at least keep it up to date okay yeah i don't have a lot more updates other than there's possibility that is exciting so with tim moving over to help with the all core devs call stuff it's just it's a good time for reevaluating some of these things that need to be done and make sure that we have people to be able to do them

EIP inclusion process to address conflicts (EVM vs BLS) as mentioned in the ACD meeting?

14:01

Pooja - so i believe we can move on to the next item the next item i i think uh we can skip i don't see edsen here it's from the like earlier meeting that we are we are to submit a medium post on that summarizing the roles and responsibilities we'll come to it again uh i have added a few comments uh like a point i'm not sure if this would be the right time to discuss about it or right place to discuss about it but it came in the last all core dev meeting about the uh inclusion process and there was some conflicts with eip so do we think we can discuss here in this meeting on this topic

James - i'm not sure can you can you say that again i'm not sure i totally follow

Lightclient - talking about evm384 versus the bls over that one it was like 2583 or something yeah yeah i mean i was just talking about the conflict in general like there is this one two five three seven; yep so it's like uh a proposal is going on in the process uh and then another proposal comes up and there is a conflict like which one should go how how do we plan to address this i believe this is more of a process thing uh so i'm trying to separate it from the breakout room meeting and try to bring it to eipip meeting maybe we can come up with some process or some solution to that

James - so far being able to identify early when something like this like that that a more kind of consistent breakout room might need to happen on a topic because i think a lot of time could have been saved if on the main all core devs call if we had thought of doing this like six weeks ago or when it was coming up saying hey there's this thing that's taking up a lot of time on the that's a reoccurring item that's taking up a lot of time maybe we should make something that's reoccurring that isn't that's off the main so that some of these things can be decided like that was just a really good idea i don't know what to do after that necessarily as far as process wise

Lightclient - i don't know if we can make a like unilateral framework for solving these problems i think it's very contextual and this is you know a great example

James - yeah there's the why something that might come out of this that could be a process would be if evm 385 so evm384 is likely to happen um if bls does is bls gonna happen at a precompiled level is not is not totally set is not known but there could be a world where most things are most of what could be a pre-compile is done by evm 384 if as long as gas efficient enough and then some subset of things that need to be more efficient for whatever reason than gets pre-compiles i kind of see that as a likely path of what will happen but that's like like how to decide if something should be is necessary enough to be a pre-compile

Micah - i think that the the frequent file version operating compile is and i think the real issue is much deeper than that uh this is my feeling from talking to the developers that are working on the evm 384 stuff and the bls pre-compile um i think the frustration and the reason they keep bringing it up is has nothing to do with the pre-compile itself it has more to do with they have sunk an inordinate amount of engineering hours into this project and they are frustrated because they have no light at the end of the tunnel like there is and this is a problem many people run into anyone who's had to deal with the core devs call has basically run into this where it is not clear how to move forward and how to actually get something in or just get a hard no like for a developer getting a hard no early is much preferable to spending thousands of engineering hours building a thing and then getting a soft no or a soft maybe later like that's the worst like if you just keep sinking more and more time and energy into this thing keep thinking you're always right there at the edge almost ready to release and then you get just like some other requirement shows up like it's really demoralizing and from talking to these people the impression i get is that they're really demoralized not because they like really need this feature or they want it in just because they have sucked so much time into it and they keep doing what they think is going to get them across the finish line and as soon as they get there they realize oh this isn't actually the finish line this is just a checkpoint and there's an infinite number of checkpoints that they don't know where the end is so i think the real problem here is and i don't have a solution for it is that we have no way of giving people you know clear goals they can work towards or just hard nos early on because they know we're not going to do this i think that's the real underlying problem here not you know like it's not really about you know okay there's bls versus 384 it's more just like you know we did all this work and we thought we were done and then you guys threw this other thing which was oh well what if we do this instead and then now that they were telling them okay now go do a bunch of research and prove to us we shouldn't do this other thing it wasn't even part of this discussion when you started all the first work you did originally and so i think that's where the real problem lies and again i don't have a solution to this this is a very hard problem when you have no leader

Bren - yeah to me that's exactly what i i mean this wouldn't solve the problem but if you have a petition like a dynamic dynamic petition like system that you where you make your proposal what you want to do and then of course you would sign it like signing a petition then other people as they get on board could sign it and then if anyone has any objections they could create a competing camp says no i'm not for this and they could sign it and they could recruit people and that would be that would be at least a way to track who is on board who isn't on board and then that's also needs to be about falsifiability what would it take to get people on board who aren't on board and stuff like that but anyway that's what we're pushing for it is is creating a petition-like system where work where it may not completely solve that problem at least it would formalize it and track it know who is on board who isn't on board and you also need to track when people change if you make some adjustment to your proposal then then six more people get on board and stuff like that it seems all critical to me to be able to track that and and and hopefully early on you could get much more idea of of where this could go and which direction the consensus is going and that kind of stuff

Pooja - i think uh um not i mean talking about this particular eip i think last year like in 2020 when we started our january we started by saying that um whenever bls is ready we will be going by going with berlin but it was stopped at one point like there was no further discussion on them so in my mind it may not be a perfect solution but i think we should have some parameters of readiness of an proposal before we you know just say no to any other proposal that may be helpful i may be wrong on the eip numbers but but i believe there were similar incidents that happened earlier it was for ep 2046 and 2666 some discussion happened and both of the eips are like no more in discussion i don't know obviously something better we have uh along with the process but i think if we can get some uh criteria some checklist that may be helpful to maybe kind of create a process for selection here

James - i don't i that seems like a bit of a trap to me and and i and i mean that in like a it's um like if i have these puzzle pieces and i got this sense on the last call and i i'm and i definitely agree with you micah as this is a a hard problem and not um and at the root of it that's what's really going on um like it's just what it sounds like they were looking for is if i do a b c and d and e and f then yes but we don't have like a good way of of guaranteeing that that list doesn't grow it's it's like we can make a checklist but but no way to enforce it realistically in in the no side

Micah - yeah exactly like there's even if we do build a checklist because we are leaders of the organization and anyone can add items to that checklist um the checklist as we saw is problem proof of work the checklist can grow forever like as long as there is someone who is willing to drag things out in order to avoid getting that change made for whatever reason whether it's political or they just don't like it or they do believe their alternative is better whatever the reason is like if we try to build a checklist it just introduces an attack vector for people to stall indefinitely so i agree like checklist would be ideal but i don't know if it works in a leaderless organization

Brent - right and that gets to my point if someone's trying to game the system and trying to just delay something by adding dish you've got to find out who is asking for exactly what is that just one person is it 50% of the ether community is it the miners all that kind of stuff and and really the no it seems like to me is we want to avoid a fork and if you can track if there's only one or two people then you don't need to worry about a fork but if there's a third of the population and we need to find ways to track those kinds of things rigorously so so you can get an idea of what's going on and because basically the no is if you do this half of the ether community is going to fork and so being able to tell that okay there's there's a handful of people that don't like this but we can still move forward with this because that's all there is a handful of people even if they are noisy people

Micah - then we get into the question of uh who's allowed to whose voices do we care about and if the answer is only core devs don't get people asking how can i be a core dev

Brent - yeah that's that's the thing about canonizer is anyone who wants to create a camp a competing camp to say something else can do that at any time and we're working on different canonizer algorithms we'll have a peer ranking system so that you can set a canonizer out what do the core devs think what do the miners think what and so you can canonize things different way so you want to find out what different people think and so it gives you a rigorous measure of who's on board who's not in board how many people and that kind of stuff and and and again everyone has a voice but you can canonize and filter things multiple different ways depending on what you're trying to accomplish

Micah - i see so that the data would be tagged with like a person's role but the anyone can view the data filtered by different texts

Micah - exactly so in other words we have an ether canonizer algorithm where you can go in and verify that you own an ether address and so everyone that can vote their ether then so if you set the ether canonizer algorithm then then everything resorts and the camp's prioritized and you can see okay 80 percent of ether wants to go with this and there's a few noisy people but they don't have an ether and and then you can switch it to a core dev expert where the peers rank each other and you can have a quantitative value for who is considered in the peer ranking system to be a core dev and then you can say okay the core devs want this and and and you could have that just like you have ether you could have the miners who get credit for mining blocks you you could get minor voting to so you could do things like that what do the miners think so so yeah basically if you join a camp then whatever canonizer algorithm is selected gives you how much vote you have if and and so if you have a lot of ether and the canonizer algorithm select you get a lot of ether votes and then if you're high ranked on it on a pure ranking system you get a high vote there and then it ignores anyone else and the idea is is make a canonizer algorithm that filters let anyone create a canonizer algorithm that can filter anything and not count anyone they don't trust any way they want and let everyone filter things any way they want and and basically what that does is accomplish and pulls everyone together in the same thing and then and then yeah that kind of stuff

Micah - i'm going to openly try to nerd snipe you here rent is it hypothetically i know you're a big fan of canonizer and you want everybody to use it that's what i've gathered

Brent - or at least the tools yeah whoever develops it is fine with me

Micah - so would it be possible to have you or someone from your team or something um follow the all core dev calls and just in the background kind of build up a canonizer thing instead of having the people themselves actually go to canonizer and post just have like one of the admins kind of post on their behalf to build up the kind of the graph so to speak um the idea being two twofold one benefits you because in theory uh makes us so people can come and we can start using canonizer but without needing to get everybody on board first and so it helps and it helps us potentially if if it does truly add value then it means hopefully we'll see that value just by kind of recording the all core devs calls in canonizer if that makes sense

Brent - yeah yeah yeah that's that's kind of exactly i think you just described the the job requirements for the person we want to hire is someone who can do exactly that

Micah - okay so yeah because it might be valuable like oh the idea of like it would be nice to for two reasons one to get an idea of sometimes it's hard in over the course of core dev calls being once every two weeks whatever they are and spread out over you know six months it's hard to keep track of if there is just one person who's consistently kind of say no to something while everybody else is either quiet or saying yes um because the time elapsed like i've i have no idea you know who was against bls six months ago uh exactly and so it might be valuable just to get that recorded so we can see if it's just one person who is continually saying no in which case we maybe sit down with them out of the core dev call and just really discuss more directly and openly and also it has potential to help i think sometimes people don't realize that they're alone on a hill dying and just being able to see that hey i'm the only person that has routinely denied this for the last six weeks i just realized i don't actually care that much i thought it was me and a bunch of other people and i was just helping you know defend all of us and really it was just me fighting on a hill by myself and so if we can just show people you know and say hey this is the current layout and you know person a shows up but they look at it like oh wow i'm the only person on the right here everybody else is on the left i don't really care and so maybe that will also help like without anyone having to call anybody out people might just notice on their own once we have that visualization um or maybe nothing else will work i don't know it's just a theory

Brent - hey man that's that's exactly what we're trying to do you've got to just rigorously track all this stuff because when everyone's posting stuff you've got to track when they jump camps and if that you find out what exactly is required to get people on board and it's all about falsifiability what would falsify your position then you can do an a b test and they can see the results okay the test proved i was wrong so i'm going to jump on board all that kind of stuff yeah i can see how this would require a full-time person to keep track of everything

James - it's full time for me just to try to remember it and it would be nice to be able to suss out some of the nuance for new people trying to join the calls and understand who is who is doing what or saying what it'd be really why what would take you way more yep way more approachable and and there's like there are people who have a stronger no say than others and just practically speaking if someone if some people get on the call and they were to object it would be a stronger objection than other people

Brent - yeah yeah we also we also have infinite delegations so my guess would be not only would vitalik be the top-ranked peer-reviewed expert but gazillions of people would delegate their vote to him and so any camp that he joined all his huge delegated tree would follow him around and then so in other words it's exactly what you're saying whatever vitality and then a vitalik screws up and then everyone can delegate to someone else and so so there's a lot of that kind of stuff too

Micah - i think the Vitalik right now actually does not have the strongest no vote

James - yeah yeah i was going to say you me there may be other it's not Vitalik who you're talking about

Brent - well cool yeah but this would formalize that and you would and everyone would be able to track who has the strongest no vote and who doesn't and you could track all that kind of stuff more rigorously

Lightclient - i mean do enough people you know know how to properly delegate their their votes because it's like you know a lot of people would just delegate to vitalik but Vitalik wants to get rid of self-destruct and i think that that's a very dangerous path to be going down

Brent - yeah so on the self-destruct um you have different topics and you delegate your vote for each individual you don't give delegate for air across the board you just delegate on individual issues when you go to support a camp that shows your position there's two different kind of supporters there's direct supporters if you direct support the camp then you're expected to receive the emails and expect it and review the new versions and and be involved in the stuff if you don't want to receive those emails and be involved then you can delegate your support to anyone else at the camp and and you can delegate to anyone so it creates any trees large trees on and every topic has a different tree and different set of experts and everything so um yeah so every so different people would have more authority on different topics and and some people on some topics wouldn't have as much story but but again when you go when you go to canonizer you think of signing a petition by signing your camp and you can either sign that directly and be involved or you can delegate your signature to someone else and and if that someone else jumps camp your vote would follow them when they jump camps and stuff like that but again it's a little it's much it's a little more it's an order of magnitude more complicated than a wiki system so it takes a bit for people to get to understand what's going on so so there is quite a big what is it that canonizer can do what is the goal and understanding all this these questions that you're asking and stuff like that but my prediction is that the first community that learns how to build consensus like this instead of governance it learns how to build consensus and track consensus it's going to blow away any other cryptocurrency because you don't really want governance you want consensus and consensus is finding out in the fewest possible camps what everyone wants and then then finding creative ways to get everyone everything they want

Pooja - thank you uh brent uh for providing an overview how does canonizer work and micah for maybe a possible solution i don't know if it is or not but to at least keep track of where things are moving in other direction

James - starting on just attendance of the attendees of the all core of calls and organizations that they represent

Pooja - i think attendees are being recorded in the meeting notes that are covered by cathedrals so it's available there yeah i just mean for brent to focus on like the stuff that would most value add would be for someone else to track and start measuring these things because i just something uh something that happened uh last year march when i was starting to volunteer more with the core devs i guess even though it was two years ago now holy cow time um but i realized the most helpful thing to do was to show everyone what's going on and then they make the best decision with that information so i i didn't i was like coming i was new to the all core devs calls um some people knew me i wasn't hired by anyone i wasn't funded by anyone i didn't have any say or whatever but i was still able to help move along the processes because i would just map them out map out what was going on with istanbul and then when people saw what was going on they would just make they would make decisions i wouldn't need to tell anyone to do anything

Brent - yeah thanks for that info and if anyone else has any other ideas of things priorities we want to work on then that's what i created the google doc for so if you have any ideas and and i i guess um alita's taking the notes for today so yeah i guess i'll have to but it looks like she's not here but anyway i'd like to work with alita to get some of the goals you guys are talking about from the hopefully we'll make it into the notes but if you have any specific ideas if you really want those to be prioritized by us then go ahead and add it to that google docs so that would help

EIP-1 clean up with removing obsolete EIPs eg. EIP-26, EIP-67 etc.

38:32

Pooja - great so moving on uh the next comment that i have added is like um like uh we might want to review the eip1 dock and clean up with like removing the obviously eip those are mentioned there uh i mean like when i looked into eips.ethereum.org i could not find those eips maybe at the time when it was written originally they were in work in progress and they somehow could not make or

Decision 24.1 | 39:51

Remove linked EIPs on EIP1 that are dead, none of them are critical

Micah - they there's there's a bunch of them um i ran the same problem when i tried to do a mass update and then gave up on it there are a lot of eips that are linked all throughout the EIP repository that don't actually exist usually it's because someone creates a pull request and then a bunch of people start linking that pull request and then the full request gets closed without ever being merged instead of the eip never actually gets created uh it's not just a problem with the eip1 but it's definitely existing if you want i think there's half dozen links or something like that that are all broken um i support just removing them i don't think any of them are critical

James - so i would i would say remove them and then i think it's a good time to go through eip1 and like as a group mark things that are kind of out of date there's a lot of language that doesn't fit anymore with the change to the statuses and such so doing like a review of of stuff that should be deprecated on the eip1 might it might be a good time to do that all right

Micah - my personal preference for a process there is just start creating pull requests that delete or change things and i'll review them i don't know if other people have preferred process well that exactly was my question i was about to ask that like is it okay for uh like creating small small pull requests for removing things as people find they're creating one so yeah that would be one thing yes small pull requests are my preference the smaller the better so like if you as long as the change is all like there so you know if you just see a typo a single request of a single type of fix is preferred um if you have like a bigger change that changes you know multiple paragraphs but it's all together like it doesn't make sense individually then do it's one well one pull request so whatever the smallest request is that um still makes sense in isolation is my again personal preference i don't mind other techniques or strategies if other people have other preferences

Pooja - okay okay i think that was it on the agenda side and one thing uh i don't know i wanted to talk about it is not added here but maybe this is the right group because from here only we come up with the eip network upgrade process so if i can if i can just ask everyone to move to this eth1.ospec project board i'm gonna share the link in the chat here so uh like so far i'm trying to update this uh this project board and we have all the five eips which are considered for yolo v3 my question i know we could not find answer earlier but it was like sometimes back i'm hoping that we get some clarity here the next stage is testing green light does that mean that whatever eip when when they are running on yolo v3 and if they have successfully passed on there they would be considered as green light or do they have to follow some other process

James - yes uh the the things before that are getting on yolo v3 having it be live and then the fuzz testing team usually is kind of the last step as far as integration tests and stuff go then if they say yes then it's good to go

Pooja - okay yeah i just wanted to have some clarity on that uh because i mean i was looking for some clarity because i have to like go for a presentation i just don't want to be confused there so yeah so after yolo v3 we would be having the list of eips that we would considered as green light and then from there it can directly go to the public testnet

James - yep and in between those is the decision of the fork blocks for the test networks but those don't need to happen necessarily depending on each other

4. Review action items from the previous meeting

43:51

Pooja - okay so that's all the questions i had on this and uh one last agenda item is review action items from the previous meeting we are very close to that so in in the last meeting we decided on to move things to final there's not a requirement for a yellow paper to be updated i think that was decision i'm not sure it was something i don't know micah if you had pointed it out.. if you move things to final there's not a requirement for the yellow people

Micah - oh currently yes that is correct we don't currently we have that requirement i don't know if we should have that requirement um update the paper is kind of hell i would feel bad asking anyone to do that also i don't have to do it for my eips

Pooja - okay the decision number 23.2 it should be plan to have someone update the yellowstone to make another source of truth and bonds and in the new year we are working on it we discussed something today and maybe i'll keep that on the agenda for the next meeting next uh decision is tentative decision to publish eip status law and eip editor role we we are waiting on adsense for the editor's roles and responsibility blog but eip status blog is already published action item uh the first one is put on the agenda that we already did and we discussed number two james will do an at one or spec repo list for eip's first book i believe james mentioned that he is working on it or even studio uh the next one is micah to update the issue and implementation section in the eip and close it is it closed or okay i'll have to check on it then to create a temporary google doc to help coordinate the cleanup and documentation i believe the doc is up now and yeah

Micah - sorry i was muted when i was responding to the action item for me um i'm pretty sure i already did that one uh did do you happen to have a link to the thing that in the notes that you have it's it just has a link to a video recording but yeah i'll try to pass it on i just said text me in discord in the chat here whatever you have and i'll double check i'm pretty sure i already took care of it

Pooja - okay i'll do that so yeah that's all from uh last meeting action item and decisions made so if anyone has anything else that you would want to discuss with

5. Anything else

47:23

Micah - um not to start anything but i just figured i'll bring it up do we want to talk about the one fifteen fifty nine situation or no we just want to pretend that it's not a problem

James - which part of it do you mean

Micah - uh the continually growing um brigading that appears to be happening everywhere on like

James - you mean people showing up

Micah - yeah it's like random people who show up and say the exact same thing as the last guy who showed up yeah and then as soon as you try to discuss with them they disappear and the next guy shows up and says the same thing again did we keep just going as is and just hope that the core devs are wise enough to ignore it um my only fear is that people like start taking to heart what these what the aggregators were saying

James - my experience has been that doesn't happen to that if you just let people talk and that most of the time people people get it and they and they get to the actual stuff it just ends up taking a lot of time it'd be nice if there was some kind of um like a pin i don't know if this could be an eth cat herder thing but like a someone to help write a summary that we could pin in those situations that say this is us talking about your issue because they end up getting a lot of times just saying oh well you need to write a summary this is just like paraphrasing what happens generally it's like oh well you need to write a summary why my point's wrong and the other one's like i'm writing all these and then it's like no if you collect your thoughts then we can respond to them but really what happens is people just yell at each other forever so help help with that would at least mean we could we could move on from the conversation faster

Brent - yep you just described what canonizer is you have a dynamic camp that people support and it's a wiki cam so and once you support a camp you can override anything that gets added to your camp any supporters can override any proposed changes and um and so you can track and you can update your camp and your arguments and collect the arguments and you can measure the quality of the argument by how many people it converts and all that kind of stuff but anyway i've been trying to get up to speed on 1559 and i'm going to try and contact some of the promoters of that and try and do exactly what you guys are talking about describe exactly linked all there's a lot of material out there that you know but anyway yeah and i'd like to work towards that

James - at least in this case i think that would be a little more than than we need just like even a post in the discord that we could pin

Pooja - so we we have been sorry so we have recently created a channel in uh catered as discord where we are inviting community members to share their thoughts um definitely not technical because for technical discussion we are pointing them towards rnd discord the 1559 channel there but if they have questions and the confusion is going around uh they are welcome to uh join the ethereum cat herders discord and we have a specific channel for discussion for eip1559 and um yeah i also come across like some kind of allegation that minus and the pressure that is being created by miners on the core dev and because of that codes and hardware coordination team are not taking appropriate steps so we are trying to pacify them in like whatever way it is possible but i'm not sure how much helpful it will be just by sharing information about the progress and the meetings implementers meetings whenever they are scheduled and whatever notes are available we're trying to share that with the community i hope that helps somehow

James - maybe just a little bit of venting on my side here i don't want to make sure we're not going over anything okay but um it's it's surprising to me how fast the community goes from things aren't progressing on 1559. oh well it means that the miners are messed are like making the process slow down and just like i've never had that experience then i and i don't know how to like that when the narrative kind of spirals out of control like that

Micah - so i think the i mean i might be partly to blame for that i don't think so but maybe no no it shows up it shows up all a lot it's weird it's more like the the general stuff escalates to completely not what's happening like for me the thing that's confusing one two five five nine is that it feels like we have a pretty simple change i mean like mechanically it's mechanically simple change a lot of code required is very low for one five five nine compared to some of the things we've done in the past yet it's been kind of just stuck and not really moving forward and so the it makes me wonder okay why is it why is this stuff why is it coming before we have all these people who all want it and we have we have multiple champions for it like we have more champions for 1559 than any other eip yet it's not making progress and so that makes me wonder you know why is it stuck and then when i look into it it looks like okay well because people keep asking for more and more things and this again reminds me very much of the product proof of work issue or the bls issue where it's like this theme where you see something that looks good and everything looks like it's done but then there's just more stuff keeps coming up can can you do this can you test this can you research this can you do this other thing and it just it makes me draws me to the conclusion that there is some shadow group out there that is just trying to delay you know these business eips whether it's pro proof of work or 1559 or bls or whatever it is and you know i recognize that there's probably not some shadow organization out there that is just trying to ruin ethereum but that's what it feels like and so now i'm looking for i'm looking for okay who who is most likely to not want this thing and so in the case of 1559 miners are the obvious person or group who wouldn't want one five by nine and so i have a tendency to naturally want to blame them and i do my best to not say this [...]

James - did we just lose him you're you were muted i couldn't hear anything micah and then now you're muted they got him the shadow organization [lol] oh my goodness

Micah - yeah that's when you guys are laughing at me we're laughing in the shadow organization yeah they they got you right as you were about to talk about it they cut me off so anyway so i it's possible that other people maybe feel similarly like maybe i'm not the only one that's feeling this where you have this kind of somebody is asking for you know way more on this eip than any other eip like way more data way more research like we hired an independent game theory researcher just to research this one eip we did not do that for like the block reward any of the block reward changes which are arguably far more impactful to miners and you know we've never done that to calculate what is the right you know payment to miners what should we be paying for hash rate to keep the system secure no one has any clue like this is something i learned a long time ago in blockchain because no one actually has any clue how much we should be paying for hashrate like there is no formula out there there's just wild guesses yet we don't hire someone for that and so this is what kind of leads me and perhaps other people to conclude well there must be someone here that is demanding things that are unreasonable or that are not demanded of other things because they have an agenda or they have an incentive to not want this to make it through or they're trying to delay it for whatever reason um whether that's true or not i'm hypothesizing that maybe this is why people go there that's why people then start saying ah minors are trying to sabotage us

Pooja - well i think this is a topic that we are not going to get rid of easily because this is a decentralized chain and people will keep coming and keep blaming one or the other yes okay so i think uh we are on time and we have covered whatever uh there on the agenda and this is something we would like to bring here the process change the process improvement for uh next meeting or onwards if people will find some topic that that could help in improving process or cleaning up process or anything that could be helpful for the chain feel free to add on the agenda as a comment and yeah anyone has to say anything thank you thank you everyone for joining us that today the next meeting is on january 27th two weeks from now.

Attendees

  • Pooja Ranjan
  • Brent Allsop
  • James Hancock
  • Micah Zoltu

Date for Next Meeting: January 27th at 1500 UTC