# EIP 1559 Implementer's call transcript April 30 -- I have like a pretty I guess lightweight agenda for the call because this is the first first time I had a goal is mostly to get a feel for where everybody's at and then what the next steps would be that move something like 1559 or Dan’s proposal forward. 06:03 It is obviously a pretty like sweeping change so we want to make sure that we roll it out with a lot of community engagement. Um, I'm not sure if I guess what I had in mind is just first, you know getting like a status update for the different teams which I think is just Besu and Geth right now working on this. and then maybe it would make sense for you Dan could then give an overview of your your EIP and then we can probably get into the nitty gritty of like the various issues with either of the themes and and and how we make sure that we actually test those that make sense for everyone. 06:43 Yeah, no objections are just wrong around and yeah, maybe it makes sense for you Ian to start I know your team has been working on this for for the longest so that maybe just gives like a bit of context for people on the call like kind of the whole process you went through on a high level and and where the implementation is is up right now. Ian: Yeah, certainly so. I've been working on this for number of months now it started out with a higher level overview that was done by MS slipper. Matthew Slipper and I'm not sure everyone here has access to that document that might be helpful for directing implementations elsewhere and so that's the higher level overview that we use to direct these implementation in go-ethereum. https://docs.google.com/document/d/1yqvvfrQ_He0fN1SsUcvZNBdyhv__d8-1QPyteCbNT6Q/edit 07:33 So that PR was opened. I think it's been a couple months now since that was opened and so to be honest, I haven't really been thinking about it all that much and the time since. But the status of that go with that PR is that everything is ostensibly in place and ready to go for further testing before we go ahead and merge everything The few things that I am certain need more work are to ensure that the light chain and the LES packages are covered by the changes and to also test the gas oracle for these new pricing is working properly and then also to ensure that the other consensus engines are hovered as well the current implementation focuses on the fast engine, of course, so the the main. The main thing that needs to be done as I see it at this point is larger scale system testing. there is unit testing included in that pull request but they're to my knowledge there has not been the larger scale system testing that needs to be done to prove that this model is safe and secure and ready to be merged over to mainnet. 08:55 And just today I went back over the PR and replied to some common comments on there for a few days and made some changes and specifically made the change to enforce that the gas price is greater than or equal to the base fee and also updated the max gas in EIP 1559 to 20 million instead of 16 million. Abdel: I can give the update for Besu. So this one implementation is almost aligned with the geth implementation. I was able to run a small test nets with some geth notes and some besu nodes. We are almost aligned except we don't have the mining for example, but I started the test net with some geth nodes and besu nodes and I was able to correctly synchronize blocks, etc. 09:57 So all consensu rules are okay. So especially the changes about new transactions structure and the block header structure. So everything works fine. To make the test with real transaction. I also submitted the PR in web 3G and the PR is merged. So in the next release of web 3G, it will be possible to kind of play with the new EIP1559 transactions. 10:27 So this is how I tested these small test net locally. And yeah, we need to work on the mining. And we did also the changes to enforce the gas price to be higher than the base fee, and change about the hard block unit to 20 million. Tim: Thanks guys. Yeah. I think Dan it probably makes sense for you now to give a high level overview of what your proposal is and and I think that the EIP did a good job like contrasting with with the 1559 but yeah. I think it would be valuable with everybody's here kind of have that context. Dan: Yeah should I the screen share or just describe it a high level. --l go ahead and screenshot if you want yeah sure.-- Uh, yeah, I'm just gonna show the the um, yeah, so yeah sorry for sharing this kind of so late not being more engaged in in the kind of debate process, but um what I wanted to highlight is just a kind of alternative fee structure. 11:37 It was written in 1988 by Mark Miller and Eric Drexler. Mark Miller's cited in the ethereum yellow paper for pioneering the concept of smart contracts. And this algorithm was designed for allocation of CPPU over a bunch of bitters. In the escalator algorithm and this EIP structures it for the purposes of Ethereum. 11:58 Each bit has a starting price and ending price in its duration that its price its bid price would escalate during which and so on each block each miner would look at their mining capacity and of the current price of all available transactions, they would pick the highest ones they could fit into the block and include those. 12:21 Um I think that so there's a lot of different conditions -- so I just wanted to highlight because I've seen like a lot of analysis of 1559 and you know, a lot of people are just focusing on the burning of fees and and I think that it's very important that we focus on user experience also. There's also been a lot of advocacy under the case of normal conditions like high probability of next block inclusion and then I've also seen people suggest that it 1559 performs better under highly volatile conditions like under the recent transaction glut with the DAI kind of crash. 12:56 On but I think that if we compare each of these against specifically you so if we consider those various types of conditions with users that have different preferences both from price and for urgency. I think urgency is kind of a consideration parameter that's not getting considered very much in these analyses the simulation it was posted on ethresearch didn't consider it, but it actually is very much I think of parameter that's important, um, for example. 13:25 I think it was during the status ICO there was it was also right after. The ENS had launched and there were a lot of people whose ENS bids were closing. and so they had like a very very specific kind of end block and so they maybe didn't have like a very high cost preference in the short term, but they definitely had a time at which they would want to pay their highest price and escalator algorithms is very friendly to to that kind of preference. There's been a little bit of a so I tried to do like a situation comparison so the blocks are regularly full and the user wants urgent inclusion so like this is I think the normal or wait a Conclusion okay so blocks are I I want blocks maybe under full maybe half full user wants urgent conclusion so this is kind of the normal condition that I think 1559 is often hailed as is like really kind of ideal for because if you bid over the current price tier, you're likely to get included in the next block. I think under current conditions, you know, it's not hard to over pay a little bit but that's the core criticism of the current single price auction. 14:36 I think the escalator algorithm also performs well here because the wallet can just start the Bid within or near the current accepted price range so I think it actually has a very high probability of getting the same next block inclusion as as you get out of 1559 except that unlike 1559 in situations where the blocks do fill up suddenly, the escalator algorithm prioritizes the person who's bidding the highest and I think that this is a kind of key a differentiator right now the the TIP parameter becomes the tiebreaker in situations where a block is full and and I know a lot of a lot of critics of the escalator algorithm. 15:16 I Highlight well a 1559 makes sure that blocks usually aren't full, you know, the price goes up but there's still a pool of transactions under that price and and so once the the price falls down to that the TIP comes the tie breaker and so so it seems to me like it's kind of recreating the single price auction and creates a kind of rare situation where sometimes people with urgent transactions can be basically in the same price pool as a bunch of people who were just waiting for the price to come down to that tier. 15:49 So I think that's kind of it in a nutshell. There's a lot of conditions to consider but I think that I think that escalator performs similarly under normal conditions and under extreme conditions. I think it performs better. And that's probably a very very high level summary of why I somewhat prefer it. 16:10 I don't I don't think it's like a deal-breaker. I don't think it's destroys protocol. I think it's got some slightly beneficial properties specifically from my experience dealing with users who are freaking out during high urgency scenarios, which which are moments when users care a lot about proper transaction processing. 16:41 Yeah, any questions? Ian: So this is probably a pretty naive question but just immediately one of the things that comes to mind is what wise that the price is increasing over time instead of decaying it seems like a user should you know would be willing to pay more if the transaction got accepted right away and if they have to wait longer than they should pay less. Dan: I think it I think that by increasing you have like better low price discovery. If you were decaying then you'd have a similar problem to today where somebody who wants an next block inclusion has to dramatically overpay and and now it's going to decay down and so you have a lot of people just overpaying, you know, 10x or 100x over the current price. By gradually increasing you're going to find the the lowest price that you would pay with similar to 1559, right? Like the price is going to go up until you know, it reaches where you would get processed. Except under this condition, you kind of have a way of spiking through a little faster even if there's A lot of transactions at the current price tier. Ian: Kind of related does this add a new gameability to the system that miners as a whole are somewhat incentivized to wait until the final block where they'll be paid the most. Dan: Yeah you know I think there's a lot of games like that I was trying to think of a good word for this is like the opposite of chicken where like a bunch of people are waiting because like incentives getting bigger over time. But because there are other miners watching you don't want to be the you don't be the slow one. 18:15 Right? Yeah, I was I was thinking about this because I berries ripping and I I'm playing this game with my birds, you know the birds and my yard. Yeah, I think that this has an equilibrium where where you know, maybe you want to wait a little bit but you're not gonna wait it forever because you know, there are other people racing for it. Tim: I guess users and wallets can also adapt to that right like say if because I assume from the user perspective you might want to abstract say, you know what's like the median price you're willing to pay and whatnot and then the wallet can kind of, you know, submit the minimum price that's like under that and in a higher price it's over that and and and over time will have data on like, you know at what that's what percentage of that of that curve do transactions typically get a included. 19:06 Dan: Yeah yeah and and as a wallet like you can also start a little below the current median and and that can help drive overall market prices down. while the developers today don't have a great way to to drive the prices down like users want, you know near next block inclusion and the only way to do that is to bid over median, which means that prices tend to upwards over time. 19:37 Ian: So this is um, not really related to the last question but um, one of the things that I think some members in the community are excited about for 1559 was the burning of the base fee and the you know, the apparent deflationary aspect of that so just wondering if you could talk to that and whether or not, 1559 could use that to kind of garner attention and support and if there's some way that we could translate that to to this EIP as well. 20:11 Dan: Yeah I mean my impression is that the burning was introduced to solve the problem where the second price action doesn't fit under this kind of game. but I think that you could introduce burning on any transaction like burn a percentage of every transaction for example and you could slap it on to any any bidding mechanism. Vitalik: So the reason why this gets subtle is because like there are a lot of the kind of more naive proposals that set people sometimes make the reform fee markets, like I think 1559 and your escalator algorithm are both immune. But like some, One of the academic ones I saw that a couple years ago is not. which is collusion between miners and and the transaction senders by making side payments. so basically if you have a mechanism where like even just taking as an example of partial fee burning, so we burn 50% of the fee, then you like if you're a major at transaction sender you have an incentive to go make a private deal with say either mine and you go say like hi ether mine, how about all send some I'll send my transactions with a gas price of two wei and At the same time kind of off on the side we'll do some economic how much money I owe you and I'll pay you the the real fee using some other mechanism. and so like that can't get taxed right and the reason why 1559 is immune to this the becausethe the fee isn't the amount that gets burned isn't dependent on any parameter that's set the transaction. The fee that gets burned that's only dependent on the amount of gas consumed, so like no matter how you do it there's going to be gas the times base fee that gets burned and there's not any way to get to get around it. And in the escalator case, that's basically just. The existing fee market with a with a modified bidding structure, so it just inherits the existing fee marketss immunity that sort of thing but like the reason why a lot of the alternative proposals do end up breaking down is basically because of that right because there isn't this kind of one-to-one correspondence between what you pay and how you influence the miners income and whenever those two things are out of sync there's some opportunity to kind of get around this kind of payment. Tim: I feel like this is probably something you've thought about Dan and curious see what you think, but could you solve I guess both problems so the problem of like fee burning seems to be kind of an important thing for part of the community and also the other problem you mentioned before of like miners waiting to include transactions Could you have something where like the percentage of the fee burn kind of goes up similarly like I guess quicker than your bid or something? where you know, if miners included when it's close to lowest bid almost none of the fees burn and if they wait all the way to the end. I don't know maybe there’s 50% fee burn. is that an idea you've kind of thought about? Vitalik: I think the problem with that is that would kind of counteract the the whole reason why the burn motivates minors or sorry why increasing fee would motivate the miners to include the transaction, which is that miners are more motivated than who transactions at the later step in the escalator because those transactions actually do pay more to the miner. 23:53 Like I think the design space of burning is that like actually is a pretty constricted design space. The design space basically is you have to set some base fee and that base fee gets burned. It's strange but they're literally are no alternative to that… and that base fee could be adjusted if you want 1559 style, it could just be set to a constant one gigawei, it could be some non-linear function or what whatever but I think I burning in amount that's only dependent on the amount of gas consumes in a in a block and possibly in previous blocks is like the only way to burn. Ian: Seems like if you burned a fraction of the transaction you'd preserve both the incentive to to process the high speed and and the burning I can't see it well definitely Vitalik: the problem is getting around the side with side payments right so if say I am would pay 10 get 10 gwei and you would get five gwei or it's it's a more marginal thing.. Or this time you get five, and then we make a side payment or whatever. Dan: But the minor would have to be allowed to process something that had a lower bid than I guess the top well yeah. I guess they always have the ability to pick what they want yeah yeah, so that does give away to bypass the rent yeah. 25:25 Tim: I think another like really important a bit around 1559 is is the fact that like it introduces two transaction pipes for a while and that basically breaks everything… you know, like and and I'd be curious to Dan get kind of your thoughts on that because you're the only wallet developer in the room, you know, if we went ahead with with 1559, what do you think the impact would be on metamask and and other things you think we can do to mitigate it 26:00 Dan: Oh yeah part of my motivation for being here is partly that like oh well we're gonna have to implement something in response to this so so better get involved, you know, we haven't done a design exercise on this yet and I think that would be really valuable for any of these proposals while there's two I guess that's just an intensive for us to move over to the new input type as quickly as possible. 26:22 I think that the escalator has a kind of graceful migration path because the current fee structure is just equivalent to a flat escalating bid, so I think that it's kind of a subset of that mechanism but yeah, I you know, either way there's gonna be a new input designed for while it's developers and I think there's an open question of how friendly we can make either one. 26:49 Ansgar: Could you combine like an 1559 style base fee with the escalator bidding structure? Dan: I think tha’s what Vitalik was just suggesting... as long as it was a flat fee it probably wouldn't be gameable, so I guess the answer is probably? Tim: The TIP becomes the escalator V: right right yeah, you can definitely make the tip be the escalator. or be an escalator rather hmm. Tim: I’d be curious to hear like client developers thoughts on that like, how would like would that change to complexity of it that much and are there any things you can imagine that would break. Ian: I don't think it would make it much more complex than it is right now you would need to hold in context the block number when you're calculating the gas price but you already have to hold in context the base fee currently, which also comes from the header so…. I don't think you would add much more complexity than we've already added with 1559. 28:05 Tim: And this might be like a really bad idea but because 1559 is already like a very large change would it maybe make sense to do it in two phases right? like 1559 version one you just ship the the tip as is and 1559 version two, you ship the escalator is that simpler or is that actually worse because then it's like breaks metamask and everything twice? 28:32 Dan: I'm not I'm not totally sure. I I'm partly trying to think through how the the combination would work like whether we could abstract it to the user basically has one escalating TIP you know, one escalating bid where you know, it's actually just prone to the 1559 style base fee or if they would actually have to set two prices that sounds like a lot of needless user complexity, but but there's probably a way of combining them into a single user for a you know, kind of expression. 29:08 And and yeah, yeah, I would be obviously to things that implement but hey, I I care more about keeping users happy. 29:19 Ian: It's a good perspective to have. 29:27 Tim: There's a lot of potential breaking points with you know either of these proposals, like obviously the UX is a big one. I think there was a lot of concerns with like the block size increase or variability for 1559 and and how that would affect the network So one thing I kind of wanted to get out of this call from all the people here is what are the things we kind of need to validate if we want to move this proposal forward? 30:01 I feel like Dan you hinted at one already would just like the wallet designs and maybe getting a feel for what it looks like and getting feedback from the community, but on the technical side of like the implementations of the EIPs. Ian you had kind of started just mentioning like more larger scale testing what do you think that would look like? 30:25 Ian: Well I think for the most part we need to test a number of the parameters that right now are just kind of hard-coded for example, the per transaction limit, the max gas limit, the the range that we have the transition occurring over, and as an effect of that also the amount of gas that is transition from the legacy pool to the EIP 1559 pool per block. so all these parameters that are kind of hard coded at this time and, They were somewhat arbitrarily selected or not arbitrarily selected but they're I don't think there's been the proper modeling and testing done to support settling on those parameters. 31:07 Abdel: Yeah, I agree especially for the hard block limits so Vitalik you mentioned that we could go up we could go higher than the factor of two so we will have to determine the optimum factor for that so I was wondering basically would it be better to express the hard block limit as a factor of the target gas usage to kind of mitigate … to Change this limit basically. Yeah that definitely seems reasonable and I think even the original EIP 1559 I set a scaling factor instead of setting … yeah so setting a scaling factor is definitely a good idea. 31:58 I mean, I think. In the short term like there's enough kind of I think clients developer kind of uneasiness about making block sizes much bigger that I don't expect a scaling factor of higher than two to be in a political viable, but if if two works for some time and we have a lot of data showing that three or four or five are safe then having an easier path to increasing seems like very smart. 32:25 Abdel: Okay, so maybe at this testing phase it will be great to have it configurable to avoid the rebuilding clients every time we want to change it. 32:43 Vitalik: Seems reasonable. 32:52 Ian: And another question that came up in the magicians thread was the transaction ordering. And whether or not we should place that under consensus and maybe this isn't the time to bring that up, but I'm go ahead and mention them. Vitalik: Whether or not we should put what about transaction ordering under consensus? Ian: the ordering itself? V: Meaning like enforcing a particular order or? I: Yeah, exactly. V: What would the benefits of enforcing an order be? I: I can't really speak to those myself. I think the supposed benefits would be predictability for contract developers. Just being able to make certain assumptions about the ordering of transactions based on the perimeters. V: Like what would be an example of an of in ordering a guarantee that would make things nice to developers? I: I'll have to look at the thread sorry. V: Right and I think I'm the challenge is um, like the current default behavior is just increasing is just including them in decreasing order of gas price, right? I guess my concern is that if we Start mandating kind of inclusion based on some order based on weird parameters that and instead of things like a front-running being just between a moderately transparent gas auction, it becomes some even weirder thing that's more centralized and opaque and harder to participate in. 34:38 Ian: That makes sense to me. I was actually opposed to it myself. It was just one of the ideas that was brought up in the magicians for it. V: That's fair. 34:54 Tim: So it seems like so far there's like three kinds of big buckets that we need to look at. The first is just like trying to mock this in the UI and see and see you know, what it looks like from a user perspective. The second is trying to understand the escalator versus the base fee and and what would you know, what what are the trade-offs maybe a bit better? 35:16 And the third is modeling I guess all of these parameters. For the third bit around the modeling as you have Barnabay, I hope I pronounced it right on the call. I think you had worked on the the model for 15 the original like Python notebook for 1559. 35:36 I'm curious if you have any thoughts on my modeling these kind of constants and in the EIP and what that would require? Barnabe: Hey, thanks. Yeah. I do want to look a bit more into modeling and actually reply to Dan in the ethresearch thread. So it's more about like figuring out how do we write down like being incentives of the miners or the users? How do we write on like the parameters? On the transaction level but also let's go on to the protocol level like the block size. These kinds of things. I’m less concerned about actually parameters like the gas limit. I think it it's more down to like technical things than it is down to incentives. 36:21 I may be wrong on this but I think this is the case. So yeah, my work only is more like to try get like a more game theoretical model and make sure that there's no let's say bad incentive, but some people have been speaking of some kind of let's say Blackmailing where miners could be saying “well, we don't include any transaction that has less than five gwei in the tip. So just want to make sure that this is not possible. 36:53 Tim: Got it. So in that case for the more I guess at technical or like, you know in protocol parameters like the per transaction and the the range of the the transition the amount of gas per block… would th best way be to set up like a small test network between say geth and basu and basically try, you know, various ranges and and see what breaks. 37:18 Abdel do you have thoughts on that? 37:25 Abdel: Mm-hmm. You mean a real test net? Tim I think at first maybe just like a slide I don't know what you can't qualify by for real right but like not a fork of Ropsten basically no I think I would yeah so for context I think at some point they would make senseto fork a real testnet that has states that has contracts and what not and and get that up and running that maybe an empty test net yeah be better at first it just test these things quickly but I am not sure yeah. Abdel: I agree it would be better to have an idea of the optimal parameters when we go through the. Kind of real testnet, yeah. 38:23 Tim: So. After is there any other kind of big like I'm not sure what to call them but like areas of this change that people want to discuss like so far we have kind of the UX, the tip versus escalator, both the theoretical models and maybe like the setting up a test net. 38:47 Yeah, is there anything else that people feel is like kind of the potential deal breaker on this EIP? 38:58 Vitalik: Do we want to talk about this question of like basically our we concerned about kind of all miners colluding to try to push the base beat down to get more revenue? Abdel: Oh yeah, by the way, I wanted to ask how did you choose the value of the fee smoothing constant? 39:21 Oh this is the um, in my EIP1559 that I linked to… Um I am included a proposal which is basically that like so I have some analysis in there for why I think it's not that miner collusion to push fees down is not that big of a problem you're not that likely to be stable, but if people are still concerned there is a modification that kind of reduces that risk even further which is basically that you would burn you would burn part of the base fee but the other base fee you would kind of redirect to a much larger group of them of miners like the miners of the last that was like 8,000 blocks. 40:16 And I think the calculation there is basically that so first of all like it has to be a larger than something like one or one or two probably even larger than larger than four basically just that because if it's really small then it would still give a substantial amount of revenue to adjacent miners and you could take advantage of that to collude somehow. And then whatever it should be a larger or much larger like the difference is basically acts as a kind of stabilizer on minor revenue as so do you want to kind of minor revenue to be more volatile or do it or do you want to be more stable? And if you set it to long then I guess just because you have miner churn like miners are not really going to care about it and so it existing miners might still end up colluding to the detriment of future miners. 41:15 So, you know, you don't want it to be one because the that just makes it a whole thing meaningless you don't want it to be a million because then current miners and future miners become misaligned. And so I think realistically like 800 would be okay 1,000 would be okay 8,000 is okay, 65,000 would also be okay. I don't really get matters too much. Abdel: That makes sense. Barnabe: You're talking about the size of the pool right not the multiplicative constant of the basically yeah? Vitalik: I'm talking about so in my proposal or amendment proposal where basically I put half the EIP 1559 burn into a pool and then every block you take one over n of that pool and you give that one over n to the miner. Like basically house like how large should that potion then be? 42:10 Right Thank you. 42:24 Tim: Oh are there any other big topics people want to bring up? Abdel: Jjust a last comment about that. I was wondering on the other hand wouldn't have miners incentive to make the base fee high if it is a fixed ratio?, Vitalik: So it does so if the portion of the base fee that was given to miners what higher than one then yes, they would be able to collude to abuse it. 42:57 But like remember that the amount like the base fee like in the status quo that amount like if we're talking about analyzing the case for miners colludes, so we just treat them as a collective right So in the status quo kind of 100% of the “base fee” goes to the miners, in the original 1559 its zero, and and in this amendment like it would be 50. Yeah, yeah. So it's something between anyway, yeah, I see. 43:39 Tim: Any other big topics people we should bring up? 43:46 Ansgar: just very briefly I wanted to clarify for my own understanding and because one of the three topics we mentioned earlier… Escalator just to like see if I basically understood that correctly summary it seems like basically 1559 and escalator are fairly orthogonal where you could like basically do both both or either or combine them as as you would want. 44:13 So you can bet you the basically like, Split the discussion there or is there anyone who disagree with that characterization? 44:26 Dan: This is the first call where I’d heard the consideration of combining them and I definitely personally need to think more about how that could combine. I heard the one suggestion of it being added as the tip parameter that could work it's also possible that escalator could just work with the moving base fee. 44:42 I think both of those are to me totally new ideas from this call and I'd have to think through. Abdel: I am wondering if we can buy them we lose one advantage of the escalator proposal. because it will become a broken change as well and you also kind of promoted that it will be backward compatible right so… Ian: Yeah, I'll second that certainly. I think the fact that it's doesn't break and it's completely backwards compatible is one of the more promising aspects of that yeah yeah it actually what's what's the whatever wins out wins out, you know, you leave the choice up to the users. Tim: Questions or clarifications? 45:49 So if not yeah I looking at my desk here just like four main things I think we need to figure out: so UX mocks with this looks like how tip and escalator and base fee kind of all, you know could interact together and and maybe like more clearly thinking true that the tradeoff is getting some community feedback on that looking at the in protocol parameters and and probably doing that by setting up an empty for a new testament between geth and besu who and then looking at the extra protocol incentives with Barnaby you were talking about. 46:26 First of all, this is that seem about right the people? And the second of all who wants to do what? I guess. Yeah. I think yeah, it would be really valuable to make progress on on all these fronts. I understand, you know, everyone here has a day job and and most of those day jobs are not working on the EIP 1559, but yeah if people want to volunteer for different efforts, I think it could make sense to try and move those forward and then maybe have a call like in a month or something that the share progress is that some reasonable. 47:05 Abdel: Yeah, I can interrupt the test net report it will be great if we could sync together, Ian, to be there yeah yeah to see how we can first we had to make the parameters configurable and then because currently it's not part of any release on geth, so it's fine because I just built from the source code of the PR but just to think when things are already or not to test the, Ian: Yeah, absolutely yeah that's that sounds good to me. 47:40 I can certainly commit to keeping up with any changes that need to be done that PR. 47:49 Okay. 47:57 Abdel: By the way, one of the issues I had with the PR I don't know if it is fixed or not but there is no support for eth 65 protocol so I don't know if you merged the master branch on that yet, 48:30 Ian: yeah I I need to rebase that branch… Abdel: good luck! [haha] Dan: I had talked with some of our designers about doing some wire frames for these different algorithms. I think we're willing to give a limited amount of effort to that but maybe it would be even more beneficial to like, I don't know if it's crazy to do like a design contest and we can throw it out to the ecosystem and just see what the wider community comes up with. 49:11 If we could pick a few judges from this call or something that might be an interesting. Thing to explore. Abdel: Do you think it would be possible to have a kind of abstraction to make a single design for both proposals? 49:30 I mean that could be a nice stretch goal... I think they have different enough parameters that yeah, they probably yeah, yeah, Tim: I think I I mean if it's like meta masks can contribute even if they're super rough wire frames, you know and kind of the next month. I think that would be extremely valuable because it gets people, you know at first view of what this implies. We had Ken from the grants team who left but I think maybe we can we can also reach out to parallel to ken and see if like the EF grants team would be willing to do like a fairly small bounty to get some more proposals on the design side. 50:09 Um, yeah, I'm happy to follow up on the bounty, but yeah Dan if you if you could get some like really like simple mocks that that would be super valuable. Yeah, yeah. I will bring this back to the team. I have already the idea. 50:30 Tim: I guess that leaves us with the whole tip versus escalator at a more technical level. I don't know if anybody kind of wants it to look at that and then the other bit was around the the modeling you have like the extra protocol incentives. Barnabe you said you were kind of already thinking about working on that sorry to put you on the spot there.. Barnabe: yeah yeah kind of like I'm focused let's say not extra protocol but the like the more economic incentive rather than protocol parameters like the block size or yeah yeah, so yeah, but I do want to make like a comparison between the escalator and EIP 1559, so I'll probably like connect with them as well. 51:13 To us like more questions on this. Tim: Yeah, if you were able to have like a comparison of the two I think that would be super valuable as well to help kind of make it a decision here. 51:33 Barnabe So the comparison would also like someone pointed out I think on the github discussion of this call trying like to get past transaction data and analyze it to kind of understand like what the patterns are. I think any comparison will be easier to make if we also kind of are able to predict how often we see spikes how often like do we see the kind of black swan events like what can we expect as the normal conditions so it's something I kind of left open and that we end of my notebook but I think it'd be something like useful to to get an idea like, A like you can't really just like compare them maybe in the abstract like you would make more sense to use actual data. 52:20 Tim: Yeah, it's basically I guess like a back test almost of how like each of them would have performed throughout like the various phases of the network, right? Barnaby: In any way it's a bit hard to do because I mean it was a different mechanism for all this time that you you can still understand like what were the time preferences of a users especially if you have access to things like when are they canceling transactions or when are they bumping the fees so just trying like to get a sense of what is going on on the network like how do people interact with it? 52:58 Tim: Cool yeah. I think we're pretty much covered then I guess does anyone else on the call have any like initiative or thing they'd like to move forward and the next couple weeks to the months? 53:15 Ian: That makes me think is there like a general timeline that we have with this?. Tim: So my optimistic timeline is I would really love to see something like this on main net by kind of the end of 2020 and the reason for this is there's a lot of work going on on stateless ethereum and that better probably gonna bring a lot of breaking changes and it's my fear is if both these proposals are kind of in R&D at the same time then they end up having to like constantly iterate off each other and and you never get to a final spec for either of them, so if we could kind of, you know, wrap this up in 2020 and then you’re going to start to see a lot of like I think less stuff go live on the network. That would be like the cleanest separation of concerns. And you know Pegasus we've kind of made it a priority to help push that but it's obviously kind of a broader community effort. 54:11 Well, yeah, that's kind of the timeline understand of like, you know things change and often take longer than you expect them to especially on Ethereum.. That's kind of what I had in mind. Thank you. And I guess you know breaking this down a bit more It means, if you have like a fork going on main nets at the end of the year, you probably need to test nets a month before you need the fork be finalized around Devcon more or less. 54:39 And because this is a big change you probably need a couple months of like actual data on some sort of a forked ropsten or something like that. So I can see it being like the summer being mostly prototyping and getting like some initial concepts out, you know, part of the fall getting some more thorough kind of testing in the wild data to refine some edge cases and then towards the later half of the fallopia goes into the the standard EIP process phases. But that's my view as kind of a product manager on this so Ian or Abdel might completely disagree that this is possible. 55:22 A&I: It sounds visible. Yeah. I think it's possible. I'm. Tim: Cool and doesn't make sense to schedule another one of these calls like roughly a month out from now. And and kind of report back then. Yeah does that work for it for people? It's good to meet. Yes. 55:48 And one last small thing a couple people on Twitter asked if this was livestream obviously it's not this time around but if we had another call would anybody opposed to it being livestream like the Corps of Dev Calls because I think there is a lot of community enthusiasm about this and it's it's good to get to get more eyes on it. 56:08 Good to me. No opposition here. 56:15 Cool. Well, yeah then I guess we can wrap up. Thanks love everyone. We appreciate really appreciate your taking the time. Thank you. Thanks nice to meet you, all right? Yeah. Thanks.