# EIP 1559 (+ other stuff) Implementer's call #3 ### June 25th, 2020 00:09 Tim: So I hi everyone thanks for joining this is implementers call number three for EIP 1559 and now now also other proposals, oh we have more people kind of slowly rolling in. Yeah, so the goal is today as per the agenda was maybe to try and analyze the different proposals that have been put forward so there was the original EIP 1559 then Dan Finley from Metamask put together a sort of counter or a composable proposal for it called escalator fees and then Micah I hope I'm getting his name right also had another proposal around typed transaction envelopes which both EIPs could use I think it would be valuable if we can get to a spot where we we have you know, pretty broad alignment on on what's the best way to move this forward because then we can start answering some other questions around how do we actually test this what's required, you know for us to feel confident deploying this on the network yeah does that generally make sense to everyone ? 01:36 Okay, so I mean, I can go through kind of the list of comments that people posted as a sort of conversation starter but yeah, there are three main things that that people I don't think any of them are on these calls voice in terms of opinions with regards to if we should bundle or unbundle the proposal. 02:01 First there was Micah's comments basically saying that he's strongly against bundling the EIPs because they both add value on their own and and and so we should just have them separate because of that. Then Barnabe put together kind of a pretty long a pretty long explanation saying that either either we have to keep keep the current transaction model with the escalator rule for the fee and by current. 02:37 I I assume that he means. I yeah, I assume he means like what's on main net today and then the second option is you use 1559 and you use the escalator rule of the calculate the the premium. And then finally durbit it which is kind of a research blockchain analysis blog put together a pretty thorough analysis of the escalator proposal and and how it works or doesn't work with 1559 and their kind of take away after the the analysis was 1559 probably provides most of the value and the escalator can be done outside the protocol, so maybe it makes sense that you start the 1559. 03:32 So maybe you make sense to just start with 1559. Thoughts from just other folks on this call. Abdel: At the last point, I kind of disagree with that. I think it's better to have the escalator algorithm and the protocol layer because if you delegate these two third party, you will have to resign the transactions so you will have the background service on the wallet for example and to resubmit transaction and I think it's, better to avoid these signature process if we can have this in the protocol layer. 04:28 Tim: So there's anyone on the call think we should not bundle. EIP 1559 with the escalator fees proposal. 04:42 V: I'll say I'm neutral on that. 04:49 Abdel: For me it depends also on if we want to make the type transaction envelope a requirement of them. Because if we don't it will be hard to let's say implement 1559 alone and after add escalator if we don't have the type transaction envelope. I think it will be better to have the type transaction envelope before implementing both EIP. 05:21 So that we can even imagine a system where you have some basically three transaction types. EIP-1559 and the combination of both but I guess it will be maybe bad because the user experience will be different. For different types of transactions. But yeah, I will strongly advocate for having the type transaction and developer requirement for both. 05:50 James: Are you saying have the type transfers first and then do 1559 and or before either of them? Abdel: Like basically on the same half fork, but just let let's say for example pass the type transaction envelope to EFI and then make this other requirement for EIP1559 and escalator. 06:16 Matt Why are you saying that they should be on the same hardfork? Wouldn't it just make sense to do typed transactions as soon as possible and if the next hard fork they're both in it, great, and if not.. Abdel: I mean, it's it's mainly to avoid changing the user experience from hardfork to another. 06:39 Because if we implement first 1559, we will have some breaking change and wallet implementation that etc also user experience and then if in the next hard fork we decide to add escalator we will again have some breaking change on the user experience so I think it's pretty bad but yeah James: and that's with with without the envelope? 07:05 In both cases. Abdel: I mean, we could have a combination of both EIP 1559 and escalator without the type transaction envelope it will be just hard on the pure implementation side, but we can deal with that but for the breaking change on the user experience it does not depend on the transaction type envelope in my opinion. 07:42 Danny: Hasu just joined who I think would probably have something to say about the different part of the speed they're talking about bundling these two EIPs, whether that should happen and found the pros and cons against escalator being in protocol or not. Hasu: Mm-hmm yeah hi I don't have a strong opinion on motivation be bundled. 08:05 I think that escalator is a good idea. I think we have we see that it's being adopted on the client side and it's it's also something that users do manually already so that's that's one of the main points of our analysis so we published today that the there's some arguments that protocol. 08:29 Should be at lean as possible in the base layer protocol so we should see if it's being adopted on the client side then it's very popular then we can internalize it, that would be my approach. Abdel: But it in that case, you accept to have to breaking change. Because. Even if it already exists all outside the protocol if we integrated after the protocol that will be a breaking change. 09:06 James: So yeah. In my. If I could have everything all why not write I I've just for simplicity of less moving parts. I would prefer for 15-59 to go in first and then say maybe in four months we can even plan this advance in advance and work towards them of having like a four-month window between deploying 1559 and then adding the escalator algorithm, it's just there's. 09:35 Simplicity and having less moving parts when it first started because there still is some risk of things going wrong and so having less things. I could go wrong all at once seems nice. As far as breaking changes, I think it's valuable enough for the users of the network to like the reason we don't break changes is because of user experience and it and it hurts somewhat users' expectations but in the case that users want it enough then it makes sense to go forward with them. 10:15 Tim: So you're saying if you ship 1559 as is you change the transaction fee that means every single wallet has to kind of re-adapt and then if we then ship escalator, you know call it four or six months later you have that that that adaptation again right you're asking once more every single wallet or thing that sends a transaction to re-adapt. 10:37 I feel like that's like a lot. Like I yeah, I feel like that's a lot of added complexity to the entire ecosystem that we can maybe manage better. By either saying, you know 1559 as is is complicated enough we want to ship that and and let's just do the escalator outside the protocol or if we really want the escalator in protocol. 11:02 I think it makes more sense as a single a single EIP like a new EIP that's like a merge of the two in a way. Because then you'll you have this very complex change, but you only have it once right? Yeah. 11:19 James: So you're saying having 1559 as is and then having the escalator be done outside of the protocol with the option of coming back later and doing it. Tim: I I don't have a strong opinion or something either either that or use you basically a new eip the escalator with a base fee or 1559 would escalator tip however you want to frame it. 11:43 But you just do it all in protocol from day one. 11:50 James: Yeah. As far as for the like the difference between the the escalate the escalator change isn't really that big of a change. If it was just on its own. As far as UX goes. so I as especially if we were to say we're rolling out in park and phase one and phase two so what people are prepared and they know that they're that these kind of changes are happening and and they have to build the UI anyway for both if we're going to do both. 12:27 If we say, hey, we're going to do one and then we're going to use some time to inform to make sure that our decisions are correct on all of these on all these variables and and then deployed the escalator tip maybe. It turns out that we don't even need that because of whatever ends up working. 12:48 Right yes, they didn't like they're saying hey part one and then we're gonna come around and say let's do everything again part two or are like completely separate change because we. Yeah, Abdel: If we do need a escalator after it will be confusing for user because the the field they were using without will mean another thing so it will be confusing for them because if we combine them it is the interpretation of each field is slightly different so I think it can be confusing for user and if it is in such short period it can be really hard because a lot of, 13:31 The work will be about educating user I guess. Also 1559 is already designed to be you know, there's two phases on EIP1559, so there is already a transition period to make the volatile integration smooth yeah so and it seems to me that we'll add complexity if we say we have an EIP that makes the integration smooth transition period. 13:31 But four months after we'd have the game a breaking change without the transition.. Again, 14:06 James: So yeah. Changing the minor tip to an escalator. I don't think is complex enough to warrant a transition.. 14:19 Abdel: it's more about wallet integration. James: yeah the wallet integration it would if it works outside of protocol like let's say we do 1559 first and then encourage wallets to do escalator and have the escalator tip outside protocol level Abdel: yeah. I see what you mean we can leverage the UX UI, but the most difficult part will be about transaction signing because it totally changed how you sign transaction without... 14:50 I mean if it is outside the protocol basically it. Just simulates escalator by re signing transaction with different gas prices but it is not the same that that yeah with the escalator in the protocol you sign the transaction only once so you have to include more fields in the transaction signing and how you encode the transaction etc so yeah, it's this is the main important change week, it's true that we can leverage the UX UI, but not the signing. Yeah. Tim: One thing thing I'd be curious to hear from 15:29 People on the calls opinion is in your piece Hasu you mentioned like this sort of privacy implications of the escalator fee right because if you if you kind of put a transaction in the transaction pool and then resign it for the higher gas fee like sure somebody might be able to track that but it's not like part of the protocol forever or sorry the kind of history forever whereas if you have the escalator basically every transaction signals, you know, this is the least in the max. 15:57 I'm willing to pay and that's gonna be recorded as as part of like those fields being added to the transaction. Does anyone like what did people think about the privacy implications there the people think it's like a concern is that something that you can already kind of infer anyway on the network. 16:22 Hasu: You know, so I see two implications to one that's on user balances or use accounts. So accounts, maybe associated with a higher like propensity to to spend or something like that. But the... forgot my point. 16:56 Abdel: I think we already had this thing maybe less the but because you cannot know from where the started to to bid but you know the final price so you can have some signals about about how important was the transaction for the user. So it it discloses information. 17:17 Less than with the escalator in protocol that yeah. Hasu: I agree yeah. I just remember the second point. The second point is on whatever if miners can use this information to come up with any new strategies to maybe delay transactions. They know if they know deterministically the transaction is willing to pay X amount in the future is included now that's information at miners don't have today. 17:48 But I I don't know if there's a way for them to exploit that. 17:58 James: I don't know. You could certainly wait and hope that nobody else puts your puts the transaction and like if everyone waited till the end then everyone would have the maximum escalator fee. That maximum fee for that it's actually kind of a good point of having if it's outside of protocol level then you remove that information from the miners, so they don't know. 18:23 Hasu: Yeah, I mean you would hope that this coordination problem amongst minus where they are like one of them is incentivized to break the kind of formation and just include it transactions once it's profitable instead of delaying and delaying and delaying. James: Yes Danny: if blocks are generally full though and most miners are following the strategy of waiting then once I come along even if I want to be honest, I'm still gonna pick the ones that have been been waited on until the strategy might still be dominant, even if you have like one honest person that wants to to break it just because breaking it would assume that they would pick up all the stuff most valuable but also pick up the ones that haven't reached the top escalator, so if the blocks are full they don't necessarily have that option anywmore. 19:27 James: So does that suggest that we should? Think more seriously about how to do it outside the protocol layer? Danny: I'm not really suggesting that I'm just suggesting that in the extreme case, you might have you know, the honest player doesn't necessarily break the strategy. James: Yeah, yeah. I was and I'm also wondering more people on the call if that's kind of the direction that this is the main tool. 19:58 Hasu: My intuition is that it's not a big deal. That's you. Yeah that you link this information to miners. Okay, it's just an interest. Abdel: I have the same intuition. Danny: There's you can still escalator your if you want to do not reveal information, you can still like put the min and max very tight and then sign a new transaction rather than dealing with the protocol escalator. 20:28 Hasu: Yeah, you can still use the the in-protocol escalator strategically right where you only encoded for it two blocks or three blocks and then you right even if you're willing to go higher and more block. Yeah, exactly strategically don't reveal your true preferences. Right? 20:52 Tim: Yeah, my biggest I think big concern at this point is just. I I'm not that confident there's actually the time to do both separately like and and that the UX burden is worth it, right? Like I think 1559 like changing the way transactions are formatted is probably the most breaking change you can do on ETH1 at least because literally everybody who sends a transaction needs to adapt. 21:21 I I would strongly try and avoid doing that twice, especially given that like historically we have like a six to nine month delay between hard forks so that, Means that say you know say best case scenario we ship whatever just 1559 and early next year and there's another six months it means you're still looking like at another year before the escalator goes live on the network and right when everybody's kind of starting to get comfortable with 1559, you're basically breaking things again. 21:51 To me, I I don't know my intuition is that's like worse than either option of like never shipping escalator in protocol or just you know, the extra complexity of bundling them together, um, And I wish Dan Finlay was on this called because I feel he has the best perspective from Metamask on like yeah how much breakage is is acceptable, but yeah. 22:19 James: Is there problems on from just like transaction version prospective of having because we don't really have that capability built in. 22:36 Or having multiple transaction types is there. I implementation problems of separating them from that perspective? 22:47 Tim: Well I guess that one. I can see is do you want all your transaction types to burn the base fee? right and if if you do which seems to be like a lot of where the community support for 1559 comes from but if all your transactions are burning the base fee anyway, you're kind of back at this problem right where there they all have this pretty common they all have this common component and you're kind of messing with like the other parameters. 23:39 So it seems like I don't know no one here has like a super strong opinion for or against but only......... Abdel: I have a strong opinion *for* actually Tim: okay, yeah yeah, okay great, um, does anyone have like a strong opinion against bundling them together? Danny: I would assume that barring more analysis most people on this call would. 24:06 Not particularly have a strong feeling unless bundling was going to significantly delay deploying 1559, you know, if there was additional complexity in implementing this in protocol on getting a tested and getting it released that was going to push everything back stay six months or you know, a single hard fork. 24:25 I would have imagined a lot of people in this call would rather push out their 1559 than bundle but I don't have a I don't have a good handle on the relative complexity of adding elevator and protocol versus just beyond. Abdel: To me it's easier to bundle them than adding them later especially if we don't have the type transaction envelope. My assumption was based on the fact we accept to have the type transaction enveloped as a requirement of exist 1559. 25:00 Hasu: Is it also possible to ask question on 1559 in the call?. Oh okay so what would be interesting to me is have you ever tried to simulate any 20 million gas blocks, as the proposal suggests? Well, how do clients deal with Abdel: we decided to remove the? Block limit hard riders and let miners decide as it is right now and there will be a separate EIP to outriders if we think it will bring value but we decided to separate the 1559 from the riders. 25:44 Hasu: I'm interested in terms of stability how Tim: okay yeah yeah the next point on the agenda but I think the hard part is. We basically want to agree to a spec of like what those blocks look like before we start those simulations, but I think that would be that would be the next step yeah. 26:12 Hasu: And maybe regarding the the vote block voting or the gas limit voting is anyone seriously in favor of that at this point or would it be V: in favor of keeping casting recording or removing it? Hasu: of keeping it and see that it's a known incentive incumbent ability issue of having miners decide the gas limit so I'm just surprised that V: yeah there have been arguments made that we shouldn't bundle those two things together right because, Like they're different proposals in some sense Tim: yeah that's my strong opinion as well it's like if you know if we want to make the block gas limits something that's controlled by say hard forks that's a separate EIP but like 1559 shouldn't introduce that as a sort of sly dependency because it's a pretty critical change. 27:11 James: And I would I would strongly be for putting it as protocol layer not as in minor control. 27:21 Tim: So we're going to need a block gas limit implementer's car James: we could do that. But it's just it's yeah this that would take I think that would take the discussion with for answering Hasu's question. I would I would there's been some discussion about how to like procedurally manage some of the amount of changes that are happening so we talk about it as removing riders and such but I think we should seriously consider having the protocol have it be a protocol level and not something that miners choose. 27:58 Tim: Yeah, this is kind of a yes side side rabbit hole though, yeah. I think I think if we don't do that this should be a separate yeah, but it should be a separate EIP like I James: I think I'm fine with that. I'm I agree that that should be the format yeah. 28:13 I think we should also still execute on that, Tim: okay got it. 28:20 So I guess related to back to sorry bundling the two EIP wouldn't make sense to try and you know put together a proof of concept implementation of the bundle. And you know, see if it's if it's pretty straightforward start testing with that? Because I feel like. If if the main the main concerns are either, you know, it'll slow things down then we can't really know that in advance if there's a concern about maybe you want that that another level of the protocol then the client. 29:01 I I just don't think we have the right people on this call to figure that out but we can at least move forward with kind of the escalator tip and and then start doing stuff like modeling, you know, 20 million block sizes. Like doing some more kind of formal simulations and whatnot, but at least we have like a single spec to go on and then if there's any significant problems with that, we can kind of go back to 1559 sort of vanilla 1559 if you want. 29:36 Because otherwise I just take it out it'll kind of slow every conversation down to always be discussing do we do escalator do we do do we do the original one and it won't get us to like yeah figure now can we handle 20 million gas blocks can wallets actually provide, you know, a good interface for that and whatnot. 29:58 James: Yeah, I agree with that. I think Danny is on on point with that the biggest concern would be around timeline changes, so if we could just agree that we the ideal version is to have 1559 and escalator tip, the question is how does that move forward if they happen separately or if they have at the same time. then we can look at what what actual effect on the time that would be because if it was if we had to wait an extra three months. 30:29 Three to six months to put the escalator tip in then we're then we're we've pushed 1559 back a bunch and then. How to say this clearly so if we have a timeline of 1559, it happens sooner if it was without this clear tip and then three to six months later we could have it escalator tip separately versus if we put them both in but then they're both delayed three to four months... 30:56 Then we're slowly solve it that we're end up being worse off yeah yeah another Hasu: I don't really have a an opinion on like timelines so on but under the condition that 1559 is delayed I would also post bundling them together if that's the result. Abdel: I don't think it will be delayed if we add escalator algorithm we can start implementing the proof of concept to add escalator just to unlock people that will do this simulation and then we can see if we want to do the type transaction envelope, but that one changes simulation basically. 31:36 James: The so for for perhaps maybe for bassoo but like as anyone going to be riding the geth client implementation or the other client implementations for that. I guess there's other Abdel: I can ask Ian from Vulcanize who did the 1559 implementation to see if he can work on the escalator. 32:02 James: right well he he wouldn't be able to unless we got funding for him yeah yeah so there there isn't currently someone lined up to do that work on the geth client. so that would be something else we need to solve okay, Tim: yeah that was yeah that was the other point but I think you know frankly if nobody's gonna do the implementation work there's kind of bigger problems of you know, whether or not we bundle the tip because they're still gonna be you know, multiple months of getting this live right it's gonna take more than like it yeah a reference implementation on wherever the spec was at six months ago. 32:36 James: Yeah, there's a different amount of work to polishing up the current 1559 that actually does things versus refactoring to put it isolated to like that's what that's a significantly different network. 32:53 So I guess. 32:59 James: Can we decide that the ideal world is that we have both and it's about how do we get them in yeah and the best way Tim: yeah I think I would rather go for that and then we can always trim down and and we can just assume they're both going in and figure out the implementation details, you know in the broadest general sense, but at least be clear on the spec of like okay, this is what it should look like. 33:29 Abdel: if we if we say the ideal version is to bundle them we we have to both like the how we James: the ideal version would be to have both but it's unclear which if they should be bundled or released in series, so we can decide perhaps today that that is the what we want to work towards in the next question is how this way to get to to that... 33:59 With particular sensitivity to timeline the effect on the timeline, okay Danny: by bundling these are we inducing the opportunity for FUD by raising the complexity of this change for example in I know there's some people that are calling for more in-depth technical economic analysis of nine if we add escalator and you know, don't as well do this type of analysis and there's kind of open questions about leaking information that kind of stuff per week ourselves in the foot. 34:32 James: A little bit. I'd say definitely. 34:37 Danny: Okay, yeah. Tim: I think I think the, The challenge though is you know, Dan's rationale for having the the escalator in the first place is like there's a bunch of problems that are like not solved by 1559. 34:56 So so yeah, I. And and and I guess the big open question is also how you know. How much of these could we solve outside of protocol and if we could get you know, 80% of the the fixes out the protocol and minimize the consensus change, maybe that that's a better approach. 35:25 That comes back to like agreeing we want to get to the world where they're both in but not sure how to best fit them. 35:36 James: is there anybody strongly opposed to having that be like the vision that we talked about as having 1559 with the escalator. 35:51 As the ideal case. Tim: Yeah and maybe one way we can flesh this out in more detail is I can schedule kind of a call with Dan Finley and Abdel and and maybe Ian he's available so that we can actually go over you know, what it would look like the bundle the two EIPs as well as as well as what could be done outside the protocol with the escalator and and and what the implementation impact of both those things would be. 36:26 Does that make sense? James: Yeah. Okay. I'm. Tim: Cool so next thing on the agenda was basically testing Nick Johnson was on the call but he dropped off I think I know he's been kind of pushing for having like a more rigorous analysis of the 1559 spec Hasu to you mentioned, you know, trying to simulate 20 million gas blocks and seeing what the network looks like under those conditions.... Barnabe has been working on simulations, so I think it would be valuable to kind of, you know, get people's thoughts here on what we think. 37:10 Like good enough, you know testing scenario for 1559 and escalator is. 37:22 V: I'm by the way just they are going to more general question on this one. I'm on the Ethereum test that's you know, like how much activity there is like how many transactions a day how many people using it and so forth. 37:39 Just looking now Ropsten blocks have like, you know, five-15 transactions each on average, mm-hmm. And gas use of like I don't know most blocks most recent blocks seem to be easier like less well either less than like a million or like, you know Phil would probably like, I don't know three four million which is probably like what a couple of large contracts that people deploy mm-hmm. V: That's in a bit unfortunate because I feel like the challenge with this mechanism is that like all the economic analysis in the world is honestly gonna be less useful than like just seeing it run for a while and see and and if people getting getting a feel of how to interact with it and I guess we don't have the ability to use to really properly use the test as an environment for that. 38:42 I mean we would but it's just that the gas the base fee would kind of hover around what one wei most of the time and then maybe occasionally. Else it'll start spiking up if there's bursts of usage. Tim: Yeah on the last last call or recall before Thomas from nethermind said we should basically you know, once we have a spec have a public testnet and try to you know, just market it's pretty pretty heavily so that people kind of deploy stuff on it in the first few blocks because that's kind of what you want you have like a burst of usage right on this on the network. 39:23 James: What kind of both what one way this might be a little bit extreme, but for Ropsten we could temporarily move the gas limit to like two million. So you even if it's low usage you can simply grow even V: Or the thing you could do is and keep the gas limit at 10 million but keep the target at one or two million James: oh yeah yeah, that's a better way. 39:57 Tim: And how that the other challenge with Ropsten is obviously applications kind of depend on it and we'd be pulling in a sort of, you know, half-ready 1559... what are people thoughts on that? this may be the wrong call maybe all core devs would better but yeah, what are people's thoughts on like breaking Ropsten early versus you know, using a new test net the challenge there being getting people to actually use it. 40:30 Danny: Which one is Reddit using? Tim: Yeah let's not do that one... V: Ultimately wouldn't we have to do both like first yeah with a dedicated testnet that and then like any hard fork goes on Ropsten before mainnet and anyway though in this case we could do it on Ropsten like six weeks before instead of three or whatever so that there's yeah, Danny: but if we do an artificially low target on the gas limit, it might actually affect you there Tim: yeah and I can imagine where like before we're ready to deploy 1559 in like a proper hard fork we want to get some Network usage data because like you said it's probably inform the best when it breaks, right? So I was thinking of like, you know, we did this ephemeral testnet for Berlin. Could we have another one easily for 1559? And then the challenge is how do you get like a lot of usage on it? 41:25 Is there a way we can just like write transactions, you know, like a sort of bots that sends tons of transactions to it? 41:36 James: The little bit of complexity at as far as looking at income personal yellow (?) is that part of the equation is looking at how miners react to it. So having it be a miner test net? then like is that a make or break for is it necessary for the pre-test net to be doing this be mined proof of work? 42:04 Tim: I think it might be just because of the implementation right Abdel?, like we said 1559 won't Like be like a proof of work thing. Is that right? 42:18 Abdel: I don't think it needs to be. No, no, no, it could work with proof of authority, Yeah. James: That's really easier to do. And then a lot of the stuff you're talking about of throwing transactions and stuff is very much possible. Tim: So we'd basically yeah what like a cleaned testnet? 42:44 Yeah, probably with more than one validator just to make sure it's actually works on and bigger than one. And we can fake volume on that. Danny: Yeah, can we reasonably write scripts to fake volume? You know and, You know in a meaningful way. 43:05 Tim: If you'll like you should be able like, especially if you have like Genesis accounts with huge amounts of ether right? like they can just that what we might not be able to do is or or might be more complicated to do is just like complex smart contract calls, so you're not making that but if we just want to feel blocks. 43:24 I don't see why you couldn't automate that pretty easily. Danny: The agents activity to kind of induce like and trust. Abdel: Yes, this is what I was going to say about these walking on implementing some agent-based simulation and I don't know the stages but it was pretty advanced last time. 43:51 I talked with him. So, We Hasu: Basic question, but why I couldn't you simulate 20 million blocks training gas blocks on testnet. James: That that is that should be done seperately. or that that is that. there's two questions to answer one is is 20 million blocks safe for the network, okay and then the other one is does 1559 actually sort of work as we want it to in practice so the one yeah but I think we still haven't figured out the best way to test that but a what it get like a thicknet at all it does is just pump out big blocks. 44:34 And then see if how that how that works is something we should talk about. V: I'm gonna have to head off now, by the way. 44:48 Thanks for coming yep. Tim: So yeah and I did yeah in terms of blocks yeah there's a few things like can the network handle 20 million gas blocks without crashing and then the other piece is also once you have the transition from regular transaction to 1559 style transactions and you're basically cutting the block like the the the block limits of like based on the type of transactions and so would you stop would you make it impossible for you know, large contracts to be deployed? 45:28 Because the block is like to say 50/50 between normal transactions and 1559 transactions? 45:41 intuitively I don't think Abdel: so we can we can reduce the transition period and we can even start with the directly phase two maybe. I mean is there any value to test the phase one where both legacy and new transaction are accepted yes because wallets need to upgrade right? 46:05 Tim: Yeah, yeah, Abdel: but for a for what we want to test Tim: oh for what we want yeah, yeah yeah, maybe not initially but and and I think on on main net so say you you're actually doubling the block gas limit right so if I wanted to deploy a 10 million gas contract, you would always be able to do it because of the slack right so if it starts and it's like mostly old transactions and some 1559, then you deploy it using an old transaction. 46:40 And then once it's tips the more than 50% of 1559 style transactions, then you can deploy your 10 billion gas contract using a 1559 size transaction, you'll just fill up the block right yeah. 47:01 Okay. I'm. So just to kind of summarize the testnet stuff, um. We need it probably makes sense to start with a new test net that we can at least run like a clean version of 1559 on and have large blocks and see this you know, does this actually work and crash before we do anything else as is all? 47:30 Abdel: 1559 alone? Would that be quicker? Yes because or we have already the implementation, but maybe we want yeah. James: have you tried connecting with the geth implementation? Abdel: yeah it works yeah yeah it works yeah James: so then we can do that this week next week Tim: yeah exactly we can set up like a YOLO okay or whatever 1559 yellow yeah, okay under that. 48:05 What we probably able to do within a week is then fill it with like huge transactions and whatnot, but we can just restart the testnet hmm, yeah that makes sense. Yeah. I'm. And one thing I guess is maybe not on this call but yeah how feasible is it to start an ephemeral test net? like I'm not super familiar with how to get team did it but is this something that you know Peter from guess that actually like work which you want or is it all open source and we can just do it ourselves? 48:46 James: It would it would be puppeth and click basically. Yeah. 49:01 Tim: So maybe yeah like James. Abdel, me and Ian can look into that and getting that up and running yeah does that make sense? Yeah a couple weeks. Yep. Um, And then yeah, and then once we have that running I think we'll figure out enough about how they EIP works the informed kind of future testing but the other the other question is I guess Nick Johnson's question of like just more formal analysis, but if he's not here, maybe we can chat with him offline about that. 49:42 Abdel: I'm. If we are concerned by a delay to me, it is the it is this is a kind of thing that could delays Tim: well, it's a different thing right like because it's like you're. You want to make sure to spend the thing is property tested before you move it the main net and to do that you have to have like a final or final implementation. 50:23 Okay, so the last bit on the agenda was funding yeah. Or sorry, I guess before that there was a the typed transaction. I feel like we've kind of touched on it in a bunch of different ways, but we didn't discuss it directly. Did anyone have any more comments on that? 50:43 Abdel: And we. Can we see if we want to pass it as EFI. It is the next all core devs maybe. 50:56 James: You can it's not typical that an EIP is accepted in the EFI the same core dev call that it's brought up. Okay something that could be it has been never agreed a problem. Abdel: It has never been presented? James No. And then the I'm curious from others here is is making that a requirement for like to have 1559 is to have this kind of transaction thing is that a general consensus we have or people feel strongly about either direction. 51:37 I haven't followed it enough to know. Tim: Yeah me neither. Abdel are you familiar enough with it to like talk about it on all core devs this Friday? Abdel: The type transaction envelope itself? Yeah. Matt: I was also planning on goig to all core devs to talk about it. 52:01 Abdel: Yeah, feel free to do that. Yeah. Tim: Yeah, that would be great Matt if you can just bring it up there and and I think based on the reaction that you know, the courts call we can see we can get a feel for like how likely you're unlikely to be kind of a something that will delay 1559. 52:23 Matt: Is there a timeline for when you think 1559 is gonna be included in a hard fork yet? I'm not really familiar with the, Tim: My hope and I'm touching wood as I say this is I'd like to get it for the next fork after Berlin. and I don't know when that will be in terms of time but I just think in terms of like roadmap it probably makes sense and and one it's like it's kind of getting ready for that point and then two I think a lot of this stateless. 52:59 Ethereum stuff is gonna start that become kind of, you know, ready to ship after that. And if if 1559 is, being developed at the same time as all the stateless stuff is being developed. I think it might it you'll have like these two things that might Like interact that are both in development and that's that just means it's pretty hard to move them forward so yeah anyway short I'd like it to be the next upgrade after Berlin but I'm not sure when that lands Matt: okay. 53:31 I'll present 2718 on Friday and we'll get a temperature for it and if things are good then we can talk more about what the actual attack plan is regarding 1559. Sounds good. 53:48 Tim: Um anything else on the type transactions? 53:54 Okay our last item on the agenda was the community funding bit. I know James you mentioned this already on the call and you mentioned this to me before like the idea of maybe having like a gitcoin grant or something like that again, you want to give a bit of your your thoughts on this? 54:12 James: Yeah I am Ian's been doing great a lot of I did a lot of great work for the Geth client and continuing to maintain it. I think it would be a gitcoin grant would be a good opportunity to one fund some of these little things that can that we're looking to happen like a lot of the little stuff and perhaps have some bounties and I'm not a doesn't really need to be a lot of funding but it would be it would help move things along quicker if we could if we could resolve some of these smaller stuff separately. 54:42 And then it would also be a good opportunity for the community to signal their support of 1559 because like one DAI donation is a skin in the game way of saying yes, I really want it. and have having that that signal I think would help a lot for the core devs side because they they spend a lot of time on the protocol level basically keeping the network alive and that takes a lot of. 55:10 Their time and attention and brain cells so clear ways for the community to tell the core devs how strongly they feel about something I think would be beneficial for their reception on swallowing the complexity of the change. 55:30 I'm open the other ways, but that's just has been my thought about. Tim: Yeah, I like the idea of like the community signal from Bitcoin does any do you know when the next like CLR round is? James: I believe the current ones still going Tim: okay, so we could kind of put something together really quick and have it there. 55:55 And then the obvious challenge also with that is like how the you kind of allocate the funds yeah yeah do people have thoughts on that? 56:15 James: Does anyone other than me have thoughts about that? 56:23 Or preferences. Tim: So one like preference that I have that I'm not sure how realistically is but it's like you your ideally don't want people to vote to pay themselves right but given like how small you know, a number of people there are and and. Yeah, it seems like maybe in practice it actually won't work. 56:47 James: we could that could be a requirement that the people who are or who administer the funds are ones to receive any of them. Yeah, I mean I get like in my case. I'm I am. I will work as funded so I yeah. I don't I. I could fulfill that. 57:11 Tim: Yeah, I think it's just too like, I mean, you know, we're all kind of getting paid as part of our day jobs to do this. So we we don't require any additional kind of funding for for it. Yeah, I think if you know the two criteria is like if you're roughly affiliated with 1559, and you don't want to be a recipient of the funds. 57:36 Then we could just have like a majority vote and we can post in the discord slack to see who the discord channel to see who who wants to be that. And basically by by asking to be on this sort of, you know, voting this year, you're renouncing the funds you could potentially get right? 57:52 Yeah. Does anyone disagree with that approach? 58:07 Cool. I'm how do we how do we get a bounty up as soon as possible then and and share it to the community? James: I can talk with gitcoin. Yeah, I mean, you can make them you can make it today. You could make. The the thing getting into the CLR is the conversation with gitcoin grants. 58:31 You can deploy the grant outside of CLR but getting it included in CLR as a matter of just having conversation with him. As far as the governance of the funds and things like that talking with a. As long as we aren't getting a lot and we have. 58:50 Transparency about where they're all going. Tim: Yeah. I'm. I can. I can make yeah I can make a stab tomorrow at putting together the gitcoin grant share it, you know, share a draft of it in the channel and we can maybe and I'll ask today for some people who might want to be like early fun administrators. 59:16 James: Yeah, I'm sure we could get it. Get Hudson to do it. I could ask him. Yeah yeah, so like Hudson, yourself, some others who are involved in 1559, or yeah have like a lot of domain knowledge -- one thing that's been a struggle with finding funding is a lot of there isn't a lot of people who have a lot of understanding about like lower level understanding about all the things are going on so it's takes a lot of conversations to say, "oh yeah we we do need this little thing" because then I'm re-explaining over our and try to. 59:51 Just as a lot more friction than I anticipated yeah. I can imagine. Pooja: So if I may like I can think I can think that cat herders can also help in setting up this thing let's get one CLR thing and as far as I know as long as it is under the CLR like I believe this one ends 4th of July so we are eligible if we apply before that we are able to getting CLR and yeah absolutely happy to coordinate funds. we did it previously for truffle so we have we can do it for this you know distribution should be. Completely your I mean, the groups are decision, so yeah, we would be happy to help in coordination path. 1:00:41 Tim: Sure that sounds good yeah, so I'll try to get a V1 of the grant ready tomorrow. I'll share it in the cat herder chat and in the 1559 channel people to give feedback and yeah, we can the we we can take it from there. 1:01:02 James: Oh yeah the other thing I think we should add to it is as 1559 closes we should donate any extra funds to matching to matching grants system, so there's anything yeah, that's over. That it will just go back in. Okay. I like that. 1:01:30 Tim: Okay was there anything else that anyone wanted to chat about? 1:01:44 James: let's go over like the things to follow up on okay, okay a call a call with me you and Dan. And some others about implementation what we're over the ones okay Tim: yeah so I guess starting from from the beginning basically on the there's three things right there's bundling testing and funding so for how we bundle things. 1:02:10 I'll set up a call with Dan Finley Ian Abdel James if you want to be there as well great to see basically how we can bundle them and how much of escalator we give you outside of the protocol. And and come up with a proposal for that. Then with regards to testing we we should set up another call or anyways can add this async but just setting up an ephemeral test net that runs click which we can start start feeding 20 million blocks for. 1:02:49 For for EIP 2718, Matt, you're going to bring it up on all core devs. we can kind of get a feel for for for how other people feel about there. And then for the gitcoin grant, I'll set one up tomorrow and I'll share it with which folks on this call and in the the chat rooms to get feedback on it. 1:03:12 James: Another one is evaluating the time the timeline effect the effect on the timeline of if we move forward 1559 first. Yeah, and I guess that would yeah it goes it goes it's a it could be a separate call or the same one but it's something that falls. Yeah. Yeah. 1:03:31 Tim: I think that makes sense. Anything else? 1:03:40 Okay. Well, thanks now everybody. Thanks. See you all.