EIP-1559 on Ethereum Classic Discussion

0:00Istora MandiriI think that I will kick off the call with a bit of a preamble, and maybe we'll get some join us as I'm reading this, so I'll just get this out of the way. But usually I start with, hello and welcome to Ethereum Classic Community Call. Today is the 10th of October, 2025. This call is today on Zoom instead of Discord, in order to cater for all regions, so sorry for the last-minute change, and thanks for accommodating. The call is being recorded and will be published to YouTube. This is a special call to discuss the topic of how Ethereum Classic might integrate EIP1559. The call was spurred by ongoing discussion within the ETC community, and in particular by a recent post on GitHub by Diego, a core developer contributing to the Ethereum Classic Node of Clients. Diego's full post is in discussion 541, and is recommended reading But as a very brief summary, Ethereum Mainnet has long since implemented EIP1559, which is a modified transaction fee system that improves user experience when pricing transactions during high traffic periods. To maintain compatibility with Ethereum. op codes and future smart contract patterns, it may be worth considering adopting this EIP with Ethereum Classic. I wanted this call to be a relatively freeform discussion, but with limited time, I'll do my best to moderate and allow all viewpoints to be adequately addressed. Please raise your hand in the Zoom reactions, and I'll try and make sure we get all voices heard. I want to be respectful of everyone's time and the late night time zone, so let's aim for about a 40-minute call. I wanted to begin by welcoming our attendees, and I believe most of you have already introduced yourself, so… Yeah, I can see that Donald's just joined us, In alphabetical order, I just wanted to… ask the attendees that are here to give us a quick summary of your relation to Ethereum Classic, and less than one minute, On your position with regards to 1559, if you have one. So, I guess we'll start with Cody. If you could just, say… Hello, and what do you think about 1559? I believe you're a co-author of the, Olympia, so… 2:24DPBYeah. Hello everyone, Cody Burns, Here representing the Ethereum Classic, co-ops board, point of view. That's what I do most recently in Ethereum Classic. I've been on the board for… The last few years, helped coordinate things as far as the GitHub and repo and, EIPs, so… And I think… are we supposed to have a one-minute overall view of 1500, or we're just doing intros right now? 2:54Istora MandiriYeah, just your opinion of it, and what do you think, very briefly, Ethereum Classic should do? 3:01DPBSure. In general, I think it's, from the discussion, I like the idea of the, smoothing algorithm that's discussed, in the economics package. I think it's after the block reward is gone, that something like that would be interesting. I think it's, In general, Ethereum Plastic needs to have a discussion on what our future is, if we're gonna… Staying compatible with the mainnet Ethereum is still something that's valuable, or now that their roadmap's going to something that's a risk-based architecture with roll-ups? Is that something that still matters, or is Ethereum need something different that's, better suited for the community? So, happy to have a discussion. 3:50Istora MandiriOkay, thanks. I see Diego has joined us, and as the next alphabetical person. Diego, could you just quickly, explain your role with relation to Ethereum Classic, and if you have any, opinions on how ETC should move forward with regards to 1559, if any. 4:12Diego L. L.Yes, hi, guys. Yeah, thank you for joining. Today. Yeah, well, well, my role is, I'm, A blockchain, yeah, protocol developer, for… for ETC. Yeah, well, I posted this, proposal for how we could introduce 1559. In the protocol, in a way that will not disrupt the current monetary policy. I don't know if I should go into that detail right now, but, mostly my… my proposal was, will be, if we could think about, implementing something like that, I mean, like, distributing. The base fee in a way that will keep the monetary policy the current one. 5:04Istora MandiriOkay, thank you. And I guess Donald's next? Donald, could you quickly intro yourself and your opinions on… 1559? 5:14Donald McIntyreThank you. I'm Donald McIntyre. When Ethereum and ETC separated, I actually stayed with Ethereum until 2018. And in 2018, I was hired by ETC Dev. to do business development and marketing. ETC Dev was the core developer team of Ethereum Classic, so ever since I've been with Ethereum Classic. In early 2019, I started to write about the hearing plastic, and my main role has been to write… be like a blogger for Ethereum Classic, writing articles and explaining all my vision about Ethereum Classic ever since. And then I was hired by the ETC Cooperative for 2 years, where I wrote my whole vision for Ethereum Classic on the Ethereumplastic.org website. I think it's more than 200 articles. And another similar number of videos about these things. With regard to… EIP1559. I thought it was a bad idea for Ethereum at the time. I think that the… That the underlying goals were… we're naive. I believe in the free market, and not setting fees… by algorithm. I prefer… I prefer the old system, so my preference would be not to implement EIP1559. But… Cody said something very important, which is, up to what extent do we want to be compatible with Ethereum? And, Diego has Explain to me in previous meetings that we had, that DIP1559 does not only change the feed, but introduce a new transaction type, and that transaction type is widely used in Ethereum, and that it has some features that actually… are important for the building of DAP, so I, I would… I would be flexible to implementing EIP1559 up to that extent. 7:27Istora MandiriOkay, I will go next, as I'm next in alphabetical order. I'm Astora, long-time contributor to ETC. I've been helping organise community resources, like the website and organizing community calls. Originally, my stance, was to… if we were going to implement 1559, to just burn the fees, but have since been convinced by reading Diego's post that that is not really an option, because we have a fixed emission curve. And unlike Ethereum, we need… I believe all the… incentive to go to miners, to continue mining the chain. And, as Cody mentioned, something like an L-shaped curve seems like The most reasonable and simple way to do that without introducing Problems with relation to myopic mining. So, with a deeper understanding, thanks to that posed by Diego, I've kind of changed my mind, if we are to implement EIP1559. And if compatibility is, like, a critical thing. But… In any case, I think the most important thing is maintaining, security of the chain, above all. So, we also have SP, So, Phil, next in the output order, if you have any comments on 1559. 9:01philAnd, for our… for myself and of our company, so, we don't have a position, or, against or agree on this, let's say, because, yeah, I've been offered by none. But for, personally, I… Think the path towards the… upgrade to, let's say, to a more modern way of, like, Ethereum Classic is, More, as if possible. to have the upgraded rate beds for the, yeah, P15? I don't have too much comments on that, and as for other companies. Thanks. 9:54Istora MandiriOkay. And thank you for that. And Stealth? Did you have any comments on that? 10:01StealthNope, I'm just here to learn. 10:04Istora MandiriOkay, awesome. Well, I guess, I would like to… I think that there's… There's… to break down the options. The default position is do nothing, which is not implementing 1559. And… Perhaps, Diego, you can, explain a little bit deeper about why that might not be a good option. I know there's… a new transaction type that, Donald mentioned. Do you think that, compatibility… Is, is gonna be at stake if it's not implemented going forward. 10:51Diego L. L.Well, yes, actually, yeah, that's… that was my point about why I decided to move forward and propose something with regards on implementing 1559. The thing is that the problem is not only the usage of Type 2 transactions, because that, in a way, that's something that we can keep avoiding. Because legacy transactions still works, and that's fine, and that's something useful so far. But the problem is that, with the progress of Ethereum, they were also introducing new type of transactions, like 7702, and there are some others, upcoming. Recently there was a, EOF discussion that, that also were introducing Another type of transaction, and all of these new transactions, in a way or another, uses the same mechanisms of base fees. So, the 1559 transactions were, like, the most simple implementation, like, just have the very same mechanism that we already had, but using a different market fee. But for the new features that they are introducing, and we could hopefully add, and they are really important for a network like ours, all of them uses the very same concepts. So, the best approach for this is to follow their own… their same path that they went through, I mean, to implement, like, the most simple transaction type for this new market fee, and then move forward, using the same ideas that we have… we could decide for implementing 1559. So that's why I think it's important to start thinking about this. 12:41Istora MandiriUnderstood. Yeah, I think, it seems like there's not really much of an option if we do want to maintain compatibility, going forward, which I believe is a goal. And, definitely provides value. 12:58Diego L. L.Yes, I mean… Just to add some other, aspect of this, we… could maybe introduce the same type of, like, as I say, 7702, which is for account abstractions. We could invent our own way of implementing 7702. But it will not be compatible, so we will be in the same position. I mean, it will be a lot of burden on our development teams and protocol, and research, and all of that. That's something that we don't want. 13:35Istora MandiriOkay. And what is the current state, of the opcode? I remember something about… 13:41Diego L. L.there just being a zero or null value used at some point, or… Yeah, no, so far, the base fee opcode is, like, a non-existing one. So if you put, a smart contract, having that opcode, it will basically… the same to… or having a non-existing opcode, it will fail as any… yeah, as a non-existing opcode. So, yeah, there is no behavior with that regard. 14:10Istora MandiriSo that means that currently there may be existing contracts that are not compatible, that are not deployable to ETC, because they're not using this opcode. 14:19Diego L. L.Yeah, I mean, you could deploy whatever you want, but it will not execute. 14:24Istora MandiriI see. I see. And just as an example for listeners. There may be contract systems in the future that use the base fee for market dynamics and other such, more complicated, I guess, interactions in the future? 14:43Diego L. L.Yeah, probably, but something else that's interesting about a base fee, that it's also something that will help you to measure the load of the network, too, and that's something. 14:54Istora MandiriHmm. 14:55Diego L. L.interesting for some applications. So it's not only something that will give you information about the market fit, but if that value is high or low. with respect, with some target value of a block, it will give you an idea of the load of the network. That may open new use cases that were not, yeah, I don't know, exploded yet. 15:18Istora MandiriOkay, thanks. That makes sense. I saw, Cody, that you had your hand up. 15:24DPBI did. I was gonna let you guys. Hold on a second. Sorry, I'm at the airport. Yup. I completely agree with Diego. I mean, I guess where I'm at in this whole… what do we need to do? Is that we've… it's no longer a computing problem or a silicon problem. The code is there, we could implement it if we wanted to, it's… as a community, we need to figure out what… is ETC going to be a world computer that's powered by a proof of work, or is it a peer-to-peer cash system that's a more efficient, or a more programmable Bitcoin version? And… 2018, 2022, this was a different conversation that we thought we would have been having. But we're in a new reality now. This is post-Genus Act, where the Clarity Act will come out at some point later this year, so… every bank globally, or every financial institution is trying to figure out how they custody assets, how they start bringing these onto their books so that, like, Tesla, they can hold Bitcoin, or they can use stablecoins to accept payments. So, it's… every custody right now is… it's Bitcoin and Ethereum is what everyone wants to bring. They're the major ones, but whenever they start talking about what's the wave 2 of coins that platforms support, ETC needs to be in that conversation. So this is… Kind of the defining moment of, do we… how do we reposition ourselves as a chain that's not a scam and, is active in doing development and not falling behind? So, that's… I am a co-author of the, Olympic… or Olympus, EIP. I think it… having sustainable funding is good. I think it's… not, I guess, relevant to 1559, or the two are separate issues. You can implement one without the other, or do something mechanically. The funding is something that So, happy to talk about later, but I don't think it's relevant here. 17:27Istora MandiriCan I… can I jump in there? Because, as far as I understood, Olymp… Olympia… fully relies on whether or not 1551 is implemented, and… sorry, 1559 is implemented, and how it's implemented, i.e. if those… If the base fee goes to a DAO, then… It's not going to the miners. So, Olympia, as a funding mechanism, requires Kind of like 2-in-1 hard fork. both doing 1559, and also redirecting those base fees to a DAO. So… 18:03DPBWhoa. 18:04Istora MandiriYeah. 18:05DPBIt does, and it's a current implementation, but it could always be a percentage. That's what Zcash is done, it's just a percentage of whatever the reward is, so it doesn't have to be the full base fee. It could be a 3% of the base fee, or some arbitrary percentage that we'd negotiate out with each other later, but it doesn't have to be the full base fee. Half the base fee could go to whatever. It's just code, Getting everyone to agree on what we want the code to do is probably the harder part than figuring out how to make the map work. 18:31Istora MandiriOkay. 18:32DPBBut you could, yeah, you do need something like 1559 implemented for it to work, but in general, 1559 could be implemented with or without. Splitting the base, or it could be done by some people a lot smarter than us a long time from now, so… 18:48Istora MandiriI see. So, we could say that, like, we've… it would be easier to reach consensus that we need to implement 1559 as a standalone step before, tying it to any DAOs, basically, and having a more simple implementation first, and then maybe later down the line. I mean, to begin with, there's not gonna be any base… there's not gonna be much of a base fee anyway. So, sending it to a DAO is kind of meaningless, but your position, I guess, would be… Maybe in the future. 19:22DPBYeah, I mean, it's symbolic, I guess, sending to it out for now. It's… it's pennies, now that the co-op's restructured, and, the ETC DAO, group and others are, gonna be supporting developers and It's… It's not a pressing matter. It is something that I believe needs to happen long-term, but it's not, worth throwing the baby out with the bathwater. 19:48Istora MandiriI see. And I think that would make it easier to… To have a, what's the phrase? Like a compartmentalized discussion about 1559. In a way that's not, sort of, tainted, so it's easier to reach alignment within the community about this. 20:09DPBYeah, it's best to have outrage about one thing at a time. 20:13Istora MandiriYeah. 20:14DPBWe can all get agree on, doing something that's technically good for the network. I think that that's worth the squeeze right now. This is a security advisory. Please maintain the system of your bags at all times. 20:31Istora MandiriYo. I think… Is there anyone on this call that is, like… I mean, Donald seemed to be… Somewhat against it at first, but now potentially is open to, implementing. Something similar to 1559. I guess the… the next… Step in the discussion is, like, what would be the, like. Most basic implementation, technically. 21:00DPBThat is, like… 21:02Istora Mandirieconomically sound. I'm assuming that burning that fee is not… economically sound. I mean, it's possible, but… A couple of the problems highlighted by Diego would be changing the monetary supply, And then, also requiring… like… The only way that miners would be receiving any reward for a block as the emission goes down. Is through the priority fees, which in most cases probably would not be a thing, unless all the blocks are fully congested. Do I understand that correctly, Diego? 21:44Diego L. L.Yes, if we burn fish, that will be the only, yeah, incentive for the miners. 21:54Istora MandiriSo, so basically, as the commission… as the… Subsidy goes down. If the fee is burned or directed away, then there's, like, no incentive to… to mine Ethereum Classic, which I don't think is a reasonable option. So, the only alternative is to give miners the fees back, no? At least, for now. 22:19Diego L. L.Yes, I think that that was the thing that Ulko thought on how to implement this. Well, I think I mentioned this in the in the… in the post there, but, it was considered as a point in Ethereum to implement 1559 this way. So it's not something that doesn't have any sustain, at least in some broader community. 22:42Istora MandiriAnd, and that… That basic implementation would be using an L-curve. 22:50Diego L. L.What do you mean by L-carve? 22:52Istora MandiriLike the smoothing curve over n blocks instead of just on. 22:56Diego L. L.The same block. Yes, yes. Yeah, splitting among, like, for the upcoming and minors from the future. Yes, I don't know yet if that will be in a linear way, or… yeah, it's something that we're up to discuss. I think something, equal for every miner in the future will be something I know, pretty okay and simple, at least to begin with. 23:26Istora MandiriYeah, it seems like the most simple… Ungameable, or at least less gameable, approach. I'm not sure if it fully… Disincentivize myopic mining over, like, midterm. If there's, like, a large mining pool. They still might be incentivized to… To publish transactions. 23:50Diego L. L.Yes, because the idea is that in the end, I mean, in the long term, every participant, every miner will get the same, because the pool will be equally distributed among, like, the pool of miners participating. So, eventually, in the long term, everyone will get the same. I mean, assuming, like, a pretty equal distribution of transaction fees among the life of the network, but thinking… I mean, at least it's pretty fair for everyone. 24:20Istora MandiriIs there… Sorry, please. 24:25DPBYeah, sorry, I wanted to jump in real quick. There is an alternative, I guess, that's being discussed, not in Ethereum plastic, but just broadly in the bigger blockchain ecosystem right now. Zcash, finally published their… the NSM, the Network Sustainability Mechanism, and it's… For their, emission curve, since they're a fixed supply, too, this smooths out the stair step of it, so that miners have, A smoother curve, more predictability, and then the long-term Is that, the emissions last… or block rewards last longer until the transaction can support themselves. So, it's, it's a different way, of course, of getting to the same goal of, we want Miners to be aligned with the long-term incentives of the network, so… I think… you can either go with something like NSM, or you can do something like the L-curve on the base fee. I like the curve better because it… it, it incentivizes based off how much the network's used, so miners get paid the more that the network's used, and everyone, I think it works better longer term, because block rewards eventually run out, and then you want something that's sustainable. 25:39Istora MandiriYeah, and it seems pretty… Like, the least simple, good option. As far as I can tell, unless I'm missing any other options. And is there any, like, Research or modeling being done into the actual numbers to be used as, like, how many blocks in the future That is smoothed out, too. 26:08Diego L. L.Yeah, no, no, in the paper, there is a mention of, 1,000 or so. I think it's… 26:14Istora MandiriYeah. 26:15Diego L. L.That's a bit too much. Also, we have to… measure of A impact on the client, because if we are going to use 1,000 blocks, that means that we will have to have that 1,000 blocks accessible in the memory of the client, so it's something that will have some impact on the footprint and the execution, so it's something that we have to measure pretty well about what will give us enough security and will not, put too much load into the client. So it's something up to, yeah, research, yeah, still. 26:50DPBDiego, is it still just Basu and, 4GF as the clients? Or… I mean, does getting… being Ethereum compatible get us any benefits of being able to use other clients or nodes or anything like that? 27:05Diego L. L.Mmm… Do you mean with regards to 1559, or in general? 27:09DPBIn general, we've made a big deal about we're aligned to, Ethereum, we're a code… compatible. So, I mean, dApps can deploy, smart contracts can deploy, wallets can connect, but, like, as far as the actual infrastructure that we're running, are we still, does… we… when Ethereum did their merge, they split the execution and consensus clients, so you can mix and match any consensus with any execution agent. Can Ethereum Classic use any of those execution agents, or are we still… 27:40Diego L. L.No, no, no, CoreGath is quite different than GoEthereum nowadays, more and more, every day, because they are removing a lot of, code waste from proof of work. On the vessel side, we are still in the upstream as, like, as a flag for enabling, the compatibility with Ethereum Classic, and those are the only two clients that we have so far. And if we were going to add ETC for some other execution clients, we will have to do some work, like in Ethermine, or Nethermine, or… or Aragonals, or any of the others. Some of the others are more, friendly to extensions, than GoEthereum. But, there is no work being done into that. I think Isaac, at some point, he did some effort on, including the ETC layer of compatibility in Aragon, but I… probably that was, that's really outdated now. So, yep. 28:45DPBOkay. I mean, and I guess that goes to the other point of the other option is we could make a reduced version of Ethereum Plastic used Not try to keep up with everything, keep our current functionality, and… Be as hard-coded as we can around everything, and still do 1559, but lock it down for the longer term, and not try to be… support everything that Ethereum does after this. 29:12Diego L. L.Yes, I think at some point we will need to make a decision of, to continue, over which client. I think, with every day, it's becoming more and more difficult to merge, GoEthereum with, Corga. code ways, and I think in the long term, that doesn't scale too well, because it's really complex, it's really error-prone, and there are not many people capable of handling those enormous merges. So, eventually, the idea might be to make some research on top of the other clients and see which client is the more friendlier. For… for including other networks, having, like, a small merge. But yeah, to solve that problem in the long term. 30:05DPBDo… do other blockchains have multiple implementations, or, like, I guess I'm thinking of, like, Polygon or the Optimism stack. It seems like, for Solana, most of them kind of align to, like, there's one client, and then all the development effort can be focused on that. Would that maybe be a better model for us than trying to spread out and have as many clients as possible? 30:27Diego L. L.Maybe, but still, we will need, Some upstream to rely on, Because it's, for me at least, working, go Ethereum, I'm never looking at them. It's, like, even a security issue, because they will be… they keep fixing things and all of that, and adding new features, and improving the execution of the overall engine. And I think we will need to be tied to some client. Ideally, it will… it should be a client that will embrace us as partners, or being part of the same community of developers. So, that's… that's what I think. I'm not against having or supporting a single client, but I think it should be part of some other bigger community of devs. 31:18DPBYep. And the reason why I'm, I guess, asking this is, right now we have Diego as our developer, and the Others are being hired by other companies that can support whatever we implement, but it's… it's a limited group of people, we have limited skills, so if Besu and if Diego, if you're a Java developer, and Basu's where you want to go, then maybe that's what we should focus on, since you're our core dev right now, and… or look at Mantis and see if we can arrive that was custom-built for us and just be our own upstream from there. I haven't thought about Mantis in years, but it is still around, I'm sure. 32:00Diego L. L.Yeah, yeah, I think it's up to discussion, and also if, the ETC, Grandstow is going to hire two new people. I think it's a discussion to have with them, too. Well, they will be. Yeah, what they want to do, and what will be our focus on the near future. 32:27Istora MandiriI, I wanted to… sorry, please go ahead. 32:30DPBI've drifted away from our 1559 conversation, so I apologize, but I haven't heard anyone violently disagree that we need to start discussing how it gets implemented, though. I would like to hear from you, Donald. Just, you have the… written the most on your overall vision of everything, so… I'd like to hear your input on everything. 32:51Donald McIntyreI think it's a good idea to… to… Isolate the next step to… PIP1559. I support it because of the reasons that were explained here today. I think Diego expanded more on not only it's a transaction type that is widely used, but also it has things that are going to be used in future transaction types, so… And I agree with, Histora that, compatibility is still important. So, I would agree with EIP1559 on ETC. 33:34Istora MandiriAwesome. I also wanted to throw in another potential opportunity, if 1559, or… a new version of it for ETC is implemented. And that is the question of. How big the maximum block size can be. And I know on Ethereum, they served on, like, double the target block size. But I was thinking that maybe it would be… Wise to think about different variables for that. And this also might tie into Donald's idea about having more of a fixed gas? Limit, or gas target. In the client itself, as opposed to variable gas. But I just wanted to throw these ideas out there. The idea of having, like, maybe 4 times or even greater maximum block size would allow for extremely complicated Deployments to occur with massive contracts that would otherwise not be possible. And this goes back to previous discussions we've had about, Ethereum having larger, big blocks, but we could achieve the same outcome With the same, like, total gas emission, just by having, like, more stretchy blocks, but with the same target blocks. 35:04Donald McIntyreYou mean to to fix the block size in terms of GAT, to fix the GAT limit. So that miners can't use it anymore. 35:14Istora MandiriWell, there's two… there's two elements to this. One is just the maximum block size versus the target block size. And in Ethereum, it's double the target block size, but we could have it much larger, for example. And it would still have the same target block size. And another separate issue, which could also be tied into the same hard fork. Is having a fixed target Gas. Limit. Such that your goal, Donald, is achieved, of making it more difficult for minors to just, like. Have… have huge blocks. 35:52Diego L. L.I just want to add something about this. Probably we'll need another session for discussing this, but still, I mean, we can briefly talk about this. I think that having variable or mining… miners controlling the blood size Was part… was also part of a protective mechanism for the… for the network, because, it… it will allow faster, coordination among the miners to… for example, right, if we are under a huge attack, that will blow the state, or maybe tear down the… the clients because of some bug on the execution side. Okay, we could tell us, the miners, if they could lower. the block limit at the point that the network is able to handle, and that's a much easier coordination than making a new release, making everyone to deploy them, and all of that. So, the existence of that mechanism is not only for yeah, for the miners to play with, but also a protected mechanism for the overall network. That's something I just wanted to mention. 37:05Istora MandiriOkay. Could the same benefit be achieved by simply having an upper limit? But without a lower limit. 37:14Diego L. L.Yeah, but, well, actually, it's an upper living right now, isn't it? 37:23Istora MandiriOkay. 37:23Diego L. L.I mean, so, yeah, that's it. 37:27Istora MandiriSo, there is a hard-coded upper limit already. 37:30Diego L. L.Well, no, it's… there is a default value. On the bike. 37:34Istora MandiriYes. 37:35Diego L. L.I can't override that. I don't think it will make too much sense for the miners to increase that too much. It will… cause, I mean, problems for the network themselves. Right. Yeah, I mean, so far, it's… it's not a huge deal. For them to… to be able to… to change that, and I think the benefit of being able to easily change it, among this, coordination is greater than the… Done there, there. the problems that they could have. But I'm open to discuss this. And also, I mean, it's something that we have to research a bit more, because it will also… see… we'll need to see if that, will affect the ankle rates and all of that. I've been reading a few, posts online about the relationship with, block size, the limits of block size and ankle rates and all that, so maybe it's something that… it deserves a bigger, research. 38:39Donald McIntyreI think it's important to remember that the miners, Can increase arbitrarily the size of blocks. but they can also arbitrarily keep them small, and actually, EIP 1559 was motivated by the miners in Ethereum keeping the blocks small when there was a lot of demand. In 2021, I think. So, so they, they, they have a bias to do one or the other. It's not only to make the blocks big. 39:22Istora MandiriWell, as far as I know, 1559 is more about… well, there's… there's, like, the UX element for users who don't know how to, like, price their transactions reasonably, and are frequently overpaying what they should do in order to get into a The next, like, reasonable block. And if miners did want to increase the gas limit massively, it would take some time, whereas 1559 allows that to occur on a shorter time period, if I understand correctly. And without them having to, like, go through this auction system. So they are related. But I think they solve slightly different problems. Did… could I… Corey, I see you. hand up, but I was… I would like to just ask with Diego about your thoughts on the… The, like, much larger block size Flexibility. Concept. Is that something… is the double the size? decided for any particular reason, or could it be. more flexible. 40:37Diego L. L.I'm not sure. It might be related to some of the math, behind how the base fee is calculated, because that's, yeah, it has some coefficients and all that, and those might be related to doubling the target, I'm not quite sure. 40:56Istora MandiriOkay. 40:56Diego L. L.Yeah, there is a really interesting set of discussions in the Ethereum ecosystem when they were talking about 1559. Those are around, I don't know, 25 sessions, where they go really deep into all of these questions, and we have to revisit those. I watched some of them. Mostly the… the first ones. They are really interesting, and they're… they touch, really interesting topics. 41:26Istora MandiriAwesome. Do you think, you'd be able to point us to those discussions? I think that might be useful in a… Sure. drafting. 41:38Diego L. L.Yeah, absolutely. 41:40Istora MandiriThank you. Cody? 41:44DPBYeah, I'm about to have to drop here in a minute, but I wanted to point out that, the Ethereum mainnet has dealt with making blocks big and floaty in two different ways. The first way was with the eigenlayer, where it was a more… capitalist version of people could pay and keep all the big block stores, with whatever the restaker's network was, so all the apps could dump their data there. And then the worst way of doing it is when they added the blob stores to the actual blocks that the validators are going, because that forces it to store it on everybody. So, I guess… I'd say that to say that if we lock the block size, it'd probably create some, economic incentive to move that. 42:29Istora MandiriHmm. 42:30DPBJunk data auction. 42:43Istora MandiriOkay, well, we have, reached that 40-minute target. for the… for the length of the call. So… at this stage, I think it's been productive, and I think… Like, the next step would be to try and put together some of these ideas into, like, a revised version of 1559, and what that might look making it compatible with Ethereum Classic. I can try and summarize some of the topics we've talked about here, add it to the current discussion on the Diego's post. And I guess we can move on from there. If there's any final comments or things that wanted to be mentioned by anyone? Please do so now. Otherwise, we can wrap things up. 43:36Donald McIntyreI think the… the comment by Cody. asking what is the vision, what is it that we want for hearing plastic, for the future of hearing plastic? It's an important question, that it was not for this, yeah, it was for me to talk about that here, but, I'm gonna write an article or something. Considering these… these things that we talked about today. 44:00Istora MandiriAwesome. I'll just mention that, like, a couple… Yep, please. 44:07philOh, again, the, for… on that arm, as a final add-on, it is not for the, the perspective of our company, just the perspective of myself. I think for the 1599, it is… it should be more… suitable. I'm… I'm more towards to the idea of not redistributing it to the Dell, basically Dell, and more to… I'm more towards to the idea of, the diverse idea, to re… to redistribute it to, the money. LinkedIn may be, compatible, easier to implement, and less resistance of the miners. But that is only the perspective myself. It doesn't, hurt the perspectives of my company. 45:01Istora MandiriUnderstood. Thanks for that, Phil. I tend to agree, and I think we… we have, like, not talked about Olympia on this call. I was hoping maybe, Ronin or Freebird might have been able to join, but perhaps we can discuss that on another… occasion. But I think one of the key takeaways from this is that As Cody mentioned, there's no, like, critical need to rush this decision. And we can take our time, at least for a… A year or two, and the fees that would be raised are not gonna be… enough to… like, solve any problems in any case. So, let's just, you know… Let's… let's do this methodically and necessarily slowly with the correct consensus gathering. Mechanisms, and make sure that everyone's on the same page, and let's not try to push anything through that's gonna cause any, rifts unnecessarily. So, unless there's any other further, final comments, I think we can wrap things up, and I'll summarize this call, and Add it to the discussion on GitHub. 46:20Diego L. L.No, nothing on the side. Thank you very much, Sora, for leading this. 46:24Donald McIntyreThank you. Thank you, Stora. Yep, thank you. 46:28Istora MandiriThank you all for attending, and looking forward to future discussions. 46:34Diego L. L.Thanks, guys. Take care. Bye. Bye bye.

Full Transcript