 So, hi everyone. Thanks for joining. This is implementers call number 3 for EIP 1559 and now also other proposals. Oh, we have more people kind of slowly rolling in. Yeah, so the goal of today as pretty agenda was mainly 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 composable proposal for it called escalator fees. And then Mika Zoltu, I hope I'm getting his name right. Also had another proposal around pipes transaction envelopes, which both EPS could use. I think it would be valuable if we can get to a spot where we have, you know, pretty broad alignment 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? Yes. Cool. 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 people, I don't think any of them are on this call, voiced in terms of opinions with regards to if we should bundle or unbundle the proposal. First, there was Mika's comments basically saying that he's strongly against bundling the EPS because they both add value on their own. And so we should just have them separate because of that. So Barnaby put together kind of a pretty long explanation saying that either we have to keep the current transaction model with the escalator rule for the fee. And by current, I assume that he means, I assume he means like what's on mainnet today. And then the second option is you use 1559 and you use the escalator rule to calculate the premium. And then finally, Derbitt, which is kind of a research blockchain analysis blog put together a pretty thorough analysis of the escalator proposal and how it works or doesn't work with 1559. And their kind of takeaway after the analysis was 1559 probably provides most of the value and the escalator can be done outside the protocol. So maybe it makes sense to just start with 1559. So I'm curious to get thoughts from just other folks on this call. Yeah. For the last point, I kind of disagree with that. I think it's better to have the escalator algorithm on the protocol layer, because if you delegate this to a third party, you will have to resize the transaction. So you will have a background service on the wallet, for example, and to resubmit transaction. And I think it's better to avoid this signature process if we can have this in the protocol layer. So does anyone on the call think we should not bundle EIP 1559 with the escalator fees proposal? I'll say a neutral on that. 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 EIP 1559 alone. And after add the 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. So that we can even imagine a system where you have some basically three transaction types, EIP 1559 alone, escalator alone, and the combination of both. But I guess it will be maybe bad because the user experience will be different for different types of transaction. But yeah, I will strongly advocate for having the type transaction envelope a requirement for both. Are you saying have the type transfers first and then do 1559 and or before either of them? Basically on the same hard work, but just let's say for example pass the type transaction envelope to EFI and then make this as a requirement for 1559 and escalator. Why are you just joined? Sorry. Why are you saying that they should be on the same hard fork like wouldn't it just make sense to do type transactions as soon as possible? And if the next hard fork, they're both at it great. I mean, it's mainly to avoid changing the user experience from a hard fork to another. Because if we implement first EIP 1559, we will have some break in change and wallet implementations, et cetera, also on user experience. And then if in the next hard fork we decide to add escalator, we will again have some break in change on the user experience. So I think it's pretty bad, but yeah. And that's with without the envelope? In both cases. I mean, we could have a combination of both EIP 1559 and escalator without the type transaction envelope. It will be just harder on the pure implementation side, but we can deal with that. But for the break in change on the user experience, it does not depend on the transaction type envelope in my opinion. And I also just joined who I think would probably have something to say about this if we caught up with the speed. They're talking about bundling these two IP EIP whether that should happen and kind of the pros and cons against escalator being in protocol and not. Yeah, hi. I don't have a strong opinion on whether they should be bundled or not. I think the escalator in general is a good idea. We see that it's being adopted on the client side. And it's also something that uses to manually already. So that's, that's one of the main points of our analysis that we published today that there are some arguments that the protocol should be as lean as possible in the baseline protocol. So we should see if it's being adopted on the client side, then it's very popular than we can internalize it. That would be my approach. Then in that case you accept to have to break in change, because even if it already exists outside the protocol, if we integrate it after under protocol that will be a break in change. Yeah. In my, if I could have everything I'll line up right I just for simplicity of less moving parts, I would prefer for 1559 to go in first and then say maybe in four months. We can even plan this advance and advance and work towards them of having like a four month window between deploying 1559 and then adding that square algorithm. It's just, there's simplicity and having less moving parts when it first starts, because there still is some risk of things going wrong and so having less things that 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. So you're saying if you ship 1559 as is you change the transaction fee that means every single wallet has to kind of readapt. And then if we then ship escalator, you know, call it for six months later, you have that, that adaptation again right you're asking once more every single wallet or thing that sends a transaction to readapt. I feel like that's like a lot like I feel like that's a lot of added complexity to the entire ecosystem that we can maybe manage better. Either saying, you know, 1559 as is is complicated enough we want to ship that and let's just do the escalator outside the protocol, or if we really want the escalator in protocol. I think it makes more sense as a single, a single eep like a new eep 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. So you're 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. I don't have a strong opinion, or either either that or use you basically create a new eep that's the escalator with a base fee or 1559 with an escalator tip however you want to frame it. So you just do it all in protocol from day one. As far as for the difference between the escalate the escalator change isn't really that big of a change. If it was just on its own. As far as it's you X and all this. So I, as, especially if we were to say we're rolling out in part in phase one and phase two. So, while 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. We're going to 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 deploy the escalator tip. Maybe it turns out that we don't even need that because of whatever ends up working. It isn't like they're saying hey part one, and then we're going to come around and say let's do everything again part two, or like completely separate change. Because if we, yeah, if we do need escalator after it will be confusing for user because the, the fields 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 the work will be about educating user, I guess. And, and also if 1559 is already designed to be, you know, there is two phases on 1559 so there is already a transition period to make the wallet integration smooth. Yeah. So, and it seems to me that we will add complexity if we say we have an EAP that makes integration smooth with the transition period but four months after we will have again a breaking change without the transition period again so yeah. Changing the minor tip to an escalator I don't think is complex enough to warrant a transition period. It's more about the wallet integration. Yeah, the wallet integration. If it works outside of protocol, like let's say we do 1559 first and then encourage wallets to do the escalator yes have the escalator tip outside of the protocol level. Yeah, I see what you mean we can leverage UX UI but the most difficult part will be about transaction signing because it totally changed how you sign transaction with or without. I mean, if it is outside the protocol, basically, it just simulate the escalator by resigning transaction with different gas prices, but it is not the same that that. The escalator in the protocol you sign the transaction only once so you have to include the 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 that we can leverage the UX UI but not the signing. Yeah. One thing I'd be curious to get other people on the calls opinion is in your piece has to 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 put a higher gas fee like sure somebody might be able to track that but it's not like part of the protocol forever or part of sorry to kind of history forever. Whereas if you have the escalator, basically every transaction signals, you know, this is the least in the max I'm willing to pay, and that's going to be recorded as part of like those fields being added to the transaction. One, like what do 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. Yeah, so I see two implications to one is on user balances or user accounts. So, accounts maybe associated with a higher like propensity to to spend or something like that. I'm sorry, forgot my point. I think we already have this thing, maybe less big, but because you cannot know from where they 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 disclose some information. It's less than with the escalator in protocol that, yeah. Yeah, I agree. 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. I know if they know deterministically that a transaction is willing to pay X amount in the future is included now that's information that miners don't have today. But I don't know if there's a way for them to exploit that. I don't know. I certainly wait and hope that nobody else puts your puts their the transaction and I give everyone waited till the end then everyone would have the maximum escalator fee, that maximum fee. So 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're, they don't know. Yeah, I mean you would hope that there's a coordination problem amongst miners where they are like one of them is incentivize to break their kind of cartel formation and just include a transaction once it's profitable instead of delaying and delaying and delaying. Yes. 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 going to pick the ones that have been been waited on. The strategy might still be dominant even if you have like one honest person that wants to break it, just because breaking it would assume that they would pick up all the most valuable but also pick up the ones that haven't reached the top escalator. But if the blocks are full, they don't necessarily have that option anywhere. So does that suggest that we should think more seriously about how to do it outside the protocol layer. I'm not necessarily 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. Yeah, yeah I was, I'm also wondering more people on the call if that's kind of the direction that this is. My intuition is that it's not a big deal that you that you leaked this information to minus that is just an intuition. I have the same intuition. So then, what are the big deals. There is you can still escalator your if you wanted to not reveal information you can still like put the men and max very tight and then sign a new transaction, rather than dealing with the protocol escalator. You still use the the in protocol escalator strategically, right where you only encoded for the encoded strategy for two blocks or three blocks, and then you write even if you're willing to go higher and more block. Exactly. You strategically don't reveal your true preferences. Yeah, my biggest I think big concern at this point is just, I'm not that confident there's actually the time to do both separately like 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 each one, at least because literally everybody who sends a transaction needs to adapt. 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. That means that say, you know, say best case scenario we ship whatever just 1559 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. 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. And I wish Dan fiddly was on this call because I feel he has the best perspective from that and ask on like, yeah, how much breakage is acceptable. Yeah. Is there problems on from just like transaction inversion perspective of having, because we don't really have that capability built in, or having multiple transaction types. Is there a implementation problems of separating and from that perspective. Well, I guess that what 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 transaction are burning the base fee anyway you're kind of back at this problem, right where they all have this pretty common they all have this common component. And you're kind of messing with like the other parameters. So it seems like I don't know no one here has like a super strong opinion for or against bundling to you. I have a strong opinion for actually for bundling. Okay. Yeah. Yeah. Okay. Great. Does anyone have like a strong opinion against bundling them together. I would assume that barring more analysis most people on this call would not particularly have a strong feeling unless bundling was going to significantly delay deploying 1559. Because there was additional complexity in implementing this in protocol and getting it tested and getting it released that was going to push everything back say six months, or you know, a single hard fork. I would imagine a lot of people in this call would rather push out 1559, then bundle. But I don't have a good handle on the relative complexity of adding elevator in protocol versus just 1559. For me it's easier to build them than adding them later, especially if we don't have the type transaction envelope. My end assumption was based on the fact we accept to have the type transaction envelopes as a requirement of 1559. Is it also possible to ask a question on 1559 in this 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. We decided to remove the block limit hard riders and let miners decide as it is right now. And there will be a separate to add riders. If we think it will bring value but we decided to separate 1559 from the riders. Oh, and then just in terms of stability, how. Okay, okay, yeah. No, and that was basically 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. And maybe regarding the block voting, the gas limit voting, is anyone seriously in favor of that at this point, or would it be in favor of keeping. Of keeping it. I feel like it's a known incentive, incompatibility issue of having minus decide the gas limit. So I'm just surprised that there are. There have been arguments made that we shouldn't bundle those two things together right because like their different proposals in some sense. And I think the opinion as well is like, if, you know, if we want to make the blast gas block gas limit something that's controlled by say hard forks. That's a separate deep, but like 1559 shouldn't introduce that as a sort of side dependency, because it's a pretty critical change. And I would, I would strongly before putting it as protocol layer, not as in minor control. I would read a block gas limit implementer scar. We could do that. It's just it's. Yeah, this that would take I think that would take the discussion would for answering Haas'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. That's for moving riders and such, but I think we should seriously consider having the protocol be having to be a protocol level and not something that miners choose. Yeah, this is kind of a, yeah, side, side rabbit hole though. But yeah, I think, I think if we do that they should be a separate. Yeah, yeah, but it should be a separate deep like I think I'm fine with that. I agree that that should be the format. Yeah, I think we should also still execute on that. Okay, got it. So I guess, related to back back to sorry bundling the two EAPS, would it make sense to try and, you know, put together a proof of concept implementation at 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 we want that at another level of the protocol, then the client. 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. Because otherwise I just think it'll, 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, figuring out can we handle 20 million gas blocks, can wallets actually provide, you know, a good interface for that and whatnot. I agree with that I think Danny is on their 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 trip. The question is how does that move forward. If they happen separately or if they happen at the same time, then we can look at what what actual effect on the timeline would be because if it was if we had to wait an extra three months, three to six months to put the escalator tip in. Then we're then we've pushed 1559 back a bunch. And then how to say this clearly. So if we have a timeline of 1559 could happen sooner if it was without the escalator tip, and then three to six months later we could have the escalator tip separately, versus if we put them both in but then they're both delayed three to four months. Then we're, yeah, that doesn't really solve it. There were were ended up being worse off. Yeah. Yeah, I under the I don't really have an opinion on like timelines and so on but under the condition that 1559 is delayed. I would also oppose bonding them together. If that's the result. 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 the simulation, and then we can see if we want to do the tag transaction envelope, but that won't change the simulation basically. The so for for perhaps maybe for basu, but like, has anyone going to be writing the depth client implementation or the other client implementations for that. I can, there's other. I can ask I am from vulcanize who did the 1559 implementation to see if he can work on the escalator. Yeah, he wouldn't be able to unless we got funding for him to do. Yeah, yeah. So there, there isn't currently someone lined up to do that work on the death client. So that would be something else we need to solve. Okay, yeah, that was, yeah, that was the other part, but I think, you know, frankly, if nobody's going to do the implementation work, there's kind of bigger problems of, you know, whether or not we bundle the tip, because they're still going to be, you know, multiple months of getting this live right. It's going to take more than like a reference implementation on wherever the spec was at six months ago. Yeah, there's a different amount of work to polishing up the current 1559 that actually does things versus refactoring to put an escalator to like that. So that's a significantly different amount of work. Okay. So I guess, Kim, can we decide that the ideal world is that we have both and it's about how do we get them in. Yeah, in the best way. Yeah, I think I would rather go for that. And then we can always trim down. 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. If we, if we say the ideal version is to bundle them, we, we have to decide how we. The ideal version would be to have both, but it's unclear which if they should be bundled or released in series. Okay. So we can decide perhaps today that that is the what we want to work towards. And the next question is, what's the best way to get to to that, whether it's bundled or not bundled. That makes sense. With particular sensitivity to timeline, the effect on the timeline. Okay. By, by bundling these. Are we inducing the ability for more fud by raising the complexity of this change. For example, you know, I know there's some people that are calling for more in depth technical and economic analysis. And if we add escalator and don't as well do this type of analysis. And there's kind of open questions about leaking information and that kind of stuff. Are we shooting ourselves in the foot. A little bit, I would say definitely. Okay. Yeah, I think I think that the challenge though is, you know, Dan's rational for having the, the escalator in the first place is like there's a bunch of problems. Like there's a bunch of problems that are like not solved by 1559. So, so yeah, I, 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. And that comes back to like agreeing that we want to get to the world where they're both in, but not sure how to best fit them. Yeah. So maybe in terms of, sorry, go ahead. Is there anybody strongly opposed to having that be like the vision that we talked about is having 1559 with the escalator as the ideal case. 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 maybe Ian if he's available, so that we can actually go over, you know, what it would look like to bundle the two EAPS as well as, as well as what could be done outside the protocol with the escalator and what the implementation impact of both those things would be. Does that make sense? Yeah. Okay. The 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. So I think, too, you mentioned, you know, trying to simulate 20 million gas blocks and seeing what the network looks like under those conditions. Barnaby's 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 like good enough, you know, testing scenario for 1559 and the escalator is. Just a kind of more general question on this one. 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. Just looking now, Robston blocks have like, you know, five to 15 transactions each on average. And gas use of like, I don't know, most blocks, most recent blocks seem to be either 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 a couple of large contracts that people deploy. If you give me specifics for the question, I can do some SQL queries and get back to you. I mean, that's a bit unfortunate because I feel like the challenge with this mechanism is that, like, all the economic analysis in the world is honestly going to be less useful than like just seeing it run for a while. 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 that's an environment for that. I mean, we would but it's just that the gas, the base fee would kind of hover around one way most of the time and then maybe occasionally it'll start spiking up if there's bursts of usage. Yeah, on the last last call, I recall before Thomas from Netermine said we should basically, you know, once we have a spec have a public testnet and try to, you know, just market it 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 the on the network. Well, one way this might be a little bit extreme, but the for Robston is we could temporarily move the gas limit to like 2 million. So you, even if it's low usage. You can go early and there's like even right or the thing you could do is and keep the gas a limited 10 million but keep the target at one or 2 million. Oh yeah, yeah, that's a better way. And how the other challenge with Robston 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's thoughts on that? This may be the wrong call. Maybe I'll court devs a better place for that. But yeah, what are people's thoughts on like breaking Robston Erty versus, you know, using a new testnet, the challenge there being getting people to actually use it. Which one is Reddit using. Yeah, let's not do that one. And I ultimately wouldn't we have to do both like first off with a dedicated test that and then like any hard for goes on Robston before main and anyway though in this case we could do it on Robston like six weeks before instead of three or whatever so that there's more time for it. Yeah. But if we do an artificially low target on the gas limit, it might actually affect the usage there. Yeah, and I can imagine where, like, before we're ready to deploy 1559 and like a proper hard fork, we want to get some network usage data, because like you said it's probably will inform the best way 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. Is there a way we can just like write transactions, you know, like a sort of bot that sends tons of transactions to it. The, the little bit of complexity as far as looking at it in comparison to YOLO is that part of the equation is looking at how miners react to it. So having to be a mineable testnet like is that a maker break for is is it necessary for the pre testnet to be doing this be mind proof of work. I think it might be just because of the implementation right Adele, like we said 1559 won't like will be like a proof of work thing is that right. No, no, no, it could work with proof of origin at work. Yeah, that's certainly be easier to do. And then a lot of the stuff you're talking about of throwing transactions and stuff is very much possible. So we basically want like a clique testnet. Yeah, probably with more than one validator, just to make sure it actually works on and bigger than one. And we can fake volume on that. Yeah, can we reasonably write scripts to fake volume, you know, and in a meaningful way. That 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 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. I don't see why you couldn't automate that pretty easily. So very the agents activity to kind of induce like them and trust. Yeah, this is what I was going to say Barnaby is working on implementing some agent based simulation. And I don't know the status but he was pretty advanced. Last time I told quit him. So the basic question but why couldn't you simulate 20 million blocks, 20 million gas blocks on Tesla. That that is that should be done separately or that that is that we so the there's two questions to answer one is is the is 20 million blocks safe for the network. Okay, and then the other one is does 1559 actually sort of work as we wanted to in practice. So the one yeah, but I think we're still haven't figured out the best way to test that, but a but it got like a thick net that all it does is just pump out big blocks. And then see how that how that works is something we should talk about. Okay, well, I'm going to have to head off now by the way, but So yeah, and I think yeah in terms of blocks. So there's yeah there's a few things like can the network handle 20 million gas blocks without crashing. And then the other piece is also when to have the transition from regular transaction to 1559 style transactions. You're basically cutting the block. 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. Because the block is like, say 5050 between normal transactions and 1559 transactions. And intuitively I don't think so we can. We can reduce the transition period. And we can even start with 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. Yeah, but for for what we want to test. Oh, for what we want. In production obviously there is value. Yeah, just for what you want to say. Maybe not initially, but and I think on on main net so say 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. And once it tips to more than 50% of 1559 style transactions, then you can deploy your 10 million gas contract using a 1559 size transaction, but you'll just fill up the block right. Yeah. Okay. I'm going to summarize it the testness stuff. We need, it probably makes sense to start with a new test net that we can at least run like a click version of 1559 on and have large blocks and see this, you know, does this actually work and crash before we do anything else. If 1559 alone. Would that be quicker? Yes, because we have already the implementation but it's what we want. Yeah. Maybe have you tried connecting with the gas implementation. Yeah, it works. Yeah, it works. So then we could do that this week. Yeah, exactly. We can set up like a yellow between whatever 1559 yellow. Yeah, we can do that. What we won't be probably able to do within a week is then fill it with like huge transactions and whatnot, but we can just restart the test net. Yeah, that makes sense. Yeah. And one thing, I guess, 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 need, you know, Peter from gas to actually like work with you on or is it all open source and we can just do it ourselves. Is it the thing you're talking about? I don't know. It would be puppets and click basically. Yeah. So maybe yeah, like James, Adele me and I am can look into that and getting that up and running. Yeah, does that make sense. Yeah, in the next couple weeks. Yep. And then, yeah, and then once we have that running, I think we'll figure out enough about how, how the ePorks to inform kind of future testing but the other, the other question is, I guess next Johnson's question of like just more formal analysis but if he's not here, maybe we can chat with him offline about that. If we are concerned by delay, to me it is, it is, this is the kind of thing that could delay. Well, it's a different thing, right? Like because it's like you're, you want to make sure the thing is properly tested before you move it to mainnet. Yeah, yeah, yeah. And to do that, you have to have like a final or finalish implementation. Sorry, James, are we gonna say something? Oh no, they must have been the birds. Okay, so the last bit on the agenda was funding. Sorry, I guess, before that there was the type 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? Can we, can we see if we want to pass it as EFI? In the next old codef maybe. You can, it's not typical that any IP is accepted into EFI the same core dev call that it's brought up. Okay. But it's definitely something that could be. It has been never a problem. It has never been presented. Not, no, I'm not aware of. Okay, okay. 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. I haven't followed it enough to know. Yeah, me either. Abdel, are you familiar enough with it to like, talk about it on all core devs this Friday. The type transaction envelope itself. Yeah. I was also planning to go to the core devs and talk about it if you don't want to. Yeah, feel free to do that. Yeah, that would be great Matt, if you can just bring it up there and I think based on the reaction of, you know, the core devs call we can see we can get a feel for like, how likely or unlikely it is to be kind of a something that will delay 1559. Yes. Okay. Is there a timeline for when you think 1559 is going to be included in a hard work yet. I'm not really familiar with it. I really hope I'm touching what as I say this is I'd like to get it for the next fork after Berlin. Okay. And I don't know when that will be in terms of time but I just think in terms of like road map. It probably makes sense and one it's it feels like it's kind of getting ready to that point and then to, I think a lot of the stateless Ethereum stuff is going to start to become kind of, you know, ready to ship after that. And if 1559 is being developed at the same time as all the stateless stuff is being developed I think they might, you'll have like these two things that might like interact that are both in development and that's, that just means it's really 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. Okay, 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. Anything else on the type transactions. Okay, 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 get coin grants or something like that. But yeah, do you want to give a bit of your thoughts on this. Yeah, I've Ian's been doing a great a lot. I did a lot of great work for the get client and continue to maintain it. I think it would be a get coin 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 not, it 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. And then it would also be a good opportunity for the community to signal their support of 1559 because like a one die donation is a skin in the game way of saying yes I really want it. And having that that signal I think would help a lot for the core dev side, because they, they spend a lot of time on the protocol level, basically keeping the network alive and that takes a lot of 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. There's an open to other ways but that's just has been my thought about it. Yeah, I like the idea of like the community signal from get coin. Does any, do you know when the next like CLR CLR round is, I believe the current one's still going. Okay, so we could kind of put something together really quick and have it there. And then the obvious challenge also with that is like how do you kind of allocate the funds. Yep. Yeah, the people have thoughts on that. Does anyone other than me have thoughts about that or preferences. The preference that I have that I'm not sure how realistic it is but it's like you 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. Well, 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'm, my work is funded so I, I don't, I, I could fulfill that. Pegasus to 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 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. We 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 the sort of, you know, voting list, you're, you're renouncing the funds you could potentially get, right. Yeah. Does anyone disagree with that approach. How do we, how do we get the bounty up as soon as possible then and share it to the community. I can talk with Bitcoin. Yeah. You can make the, you can make it today. You can make the, the thing, getting into the CLR is a conversation with Bitcoin grants. Okay, got it. You can deploy the grant outside of CLR, getting included in CLR is a matter of just having conversation with them. Okay. 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 transparency about where they're all going. Yeah. I can, I can make, yeah, I can take a stab tomorrow at putting together the Bitcoin 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 fund administrators. Yeah, I'm sure we could get, we can get Hudson to do it. I can ask him. Yeah. Yeah. Hudson yourself, some others who are involved in 1559 or 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 a lower level understanding about all the things are going on. So it takes a lot of conversations to say, Oh yeah, we do need this little thing because then I'm re explaining over and trying to just has a lot more friction than I anticipated. Yeah, I can imagine. So if I may like, I can think, I can think that cat or just can also help in setting up this thing, this Bitcoin CLR thing and as far as I know, as long as it is under the CLR like I believe for this time, July, so we are eligible if we apply before that we are getting CLR and yeah, we would be happy to coordinate funding. We did it previously for proper so we can do it for this and distribution should be completely your, I mean the grips decision. So yeah, we would be happy to help in coordination path. Sure, that sounds good. Yeah, so I'll try to get a V1 of the grant ready tomorrow. I'll share it in the catheters chat and in the in the 1559 chat for people to give feedback and yeah, we can we we can take it from there. The, 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. Um, okay. Was there anything else that anyone wanted to chat about. Okay, well, thanks a lot everybody. 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 were, what were the ones. Okay, yeah, so I guess starting from from from the beginning basically on the, there's three things right there's bundling testing and funding. So for how we bundle things, I'll set up a call with Dan Finley, I and 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 can do outside of the protocol. We can come up with a proposal for that. Then, with regards to testing, we, we should set up another call or anyways can have this async but just setting up an ephemeral test net that runs click, which we can start start feeding 20 million blocks for. For IP 2718, Matt, you're going to bring it up on our core dev, we can kind of get a feel for, for, for, for how other people feel about the 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 chat rooms to get feedback on it. Another one is evaluating the time, the timeline effect, the effect on the timeline of if we move forward 1559 first. Yeah, I guess that would, yeah, it goes, it goes, it's a, it could be a separate call or part of the same one, but it's something to follow up on. Yeah. Yeah, I think that makes sense. Anything else. Okay. Well, thanks a lot everybody. Thanks. See you. Thank you.