 We are recording. So, hey everybody, welcome to 1559 implementers meeting number six. I just shared the agenda in the chat. A couple people joined in sense, so let me reassure it just in case. So first thing on the agenda was just client updates on the test net. Maybe we can start with another mind. I know, Thomas, you just posted an update on the discord. Yeah, sure. So we're fully saying to validating blocks. So Abdul Hamid mentioned that there is some some problem with filling the blocks I believe at the moment. The issue with synchronization that we've seen last week. So when I looked at it was very small thing. So I love the code that was comparing the available block space for both the old style transactions and the new style transactions and since we merged them together in the transaction plan in the blocks, it was no longer important. So when the old style transactions appeared, we treated them as beyond the space in the block for them, and we rejected the block but after removing that code that checks it's all fine. Cool. Yeah, Abdul, do you want to give an update on the base you said. Yeah. So nothing really new on the corretarium client except some new fields added to some RPC endpoint lacks like the get blocked by number and get blocked by hash endpoints to basically return the base fee. So corresponding to the three API I wrote about aiding the 1559 fields to the existing RPC endpoint, for example for endpoints that return block fields. And yeah, we are working on the tooling, but we have a specific item on the agenda about that. So I'll talk about that later. And Rick or Ramil, do you want to get an update from the get side. Yeah, I can provide updates. So we completed updates and guess code to be aligned with largest version of the IP. And also we tested synchronization guess to guess and guess to be so and it works well. And now we are working on testing guess to never mind. Got it. And when you say test you ran your local network or have you been thinking on the network that that we've been using with letter mine. No, it's a local network. Okay, got it. Yeah, I would suggest to skip that step and test directly on the test net because we are in sync with net our minds or if you that works with business that should also work with net our mind. But it's up to you. Just saying. Yeah. Yeah, I have questions about this network. How can I join to that. Okay, so we can talk about that later because I have a point point about that during the day. Yeah, yeah. Okay, one important thing is that most likely you'll have a person joining on the research press development side part time specifically involved with the IP 1559 only for net our mind. Yes, most likely it's happening next week. That's that's really good news. Cool. So yeah, I guess this is kind of from the client side. Maybe it makes sense. I know Barnaby you had a new notebook as well that she released this week or last week I forget. Do you want to give a quick update on on that before we dig more into the test that stuff. So whatever you prefer I can do it after the test that as well. I guess I'm just concerned we end up getting bogged down in the test that we don't have time. So, yeah. Yeah, is it. Wait, so first, so I released this new notebook which looks at the combination between 1559 and the escalator so this idea that you can have 1559 to have like a nice default market price for the transaction. And meanwhile, users can use this kind of incremental beat strategy to to increase their beads over time. Let me just post the link here. Right. Today's share my screen. Sure. Yeah, go ahead. Right, so in one of my previous notebook I kind of show that whenever demand is shifting quite fast. Increasing users have the incentive to become strategic and to kind of try and overbeat each other, which is what we see currently in this first price auction mechanism that we we currently live in. And so this idea of the escalator was coming to say well, many people are doing this resubmission pattern on the wallet. So you send a transaction and you resend it you bump your, your gas price a little bit to hope that now you are more competitive. And the idea of the escalator is to take that pattern and put it in the protocol and allow you to decide on how low your bid is starting from and how high you are willing your bid to go. And over time your bid is just increasing between these two, these two bounds. And it's kind of a neat idea but the main, let's say problem was that it has a lot of parameters like you have to decide your start bid you have to decide how high you're willing to go. You have to decide how fast you want to go as well. And the nice thing about 1559 is that we actually get kind of this default price which is your being quoted this entry price to the transaction gas market. So, so the idea of combining the two is to at least remove that one parameter which is how high you should start your bid like you should start it at what the base fee is currently. And then, in this notebook I was trying to investigate let's say different strategies. So, I look at two strategies. And I show like, okay this picture kind of shows you in blue here you have a base fee, which is moving around. So here, you assume that it's increasing maybe because the demand is increasing. And you have two players like Alice and Bob, and Alice is kind of in a more of a hurry than Bob is. So she would set the heartbeat to rent faster than Bob does. So what happens with this mechanism is, you kind of track the base fee. So your bid looks like is varying the way the base fee is. But over time you keep adding a bit more to your bid, and you keep saying hey minor, my bid is getting higher and higher so now maybe you want to include. And so that's that's that may be helpful in these cases where the demand is is increasing and users would rather try and compete against each other, rather than take the base fee as a as a market price. So really like the escalator is, it's more expressive and plain vanilla 1559 is, but the question is, do we care about this expressiveness at all like what do we gain from having this more expressive bidding language. And so what I try to introduce in the notebook is this idea of efficiency which is how we look at, let's say the performance of a mechanism in in game theory. So we really care that users which have very high value for their transactions going first, or at least, or going as fast as possible. And so I'm looking at these two different strategies so this one is a strategy where I have let's say very high costs. I don't want to wait I'm trying to arbitrage this transaction and so I want to get in as fast as possible so I look at how much costs I have to for waiting, and I set my escalator to ramp about as fast as my cost is so the more it pains me to wait the faster I'll get my escalator to increase. And maybe I'll let you like read through it. I'm also planning to release videos and I haven't gotten around to it but I think it'd be nice to have a bit of an audio description as well. All right, no I don't want to get into this, but the second strategic sort of encodes a different behavior which is sometimes I don't really care that my transaction goes in as fast as possible I just wanted to go in at some point. So I'll just tell myself okay I'm willing to wait for 10 blocks, and I'll keep increasing my bid escalate my bid overtime until these 10 blocks are done. So hopefully I get in by by the time these by the time of these 10 blocks. So the interesting thing is that when the users in your transaction market use these different strategies. You really see like different, let's say behavior of the market as a whole. So, even visually, not going to go into the details but visually you see that it's kind of very different. So the user's as dots, and the color of the dots is the wave of users that are progressively coming in. And I think it's, it kind of gives some intuition. It's definitely like an introductory work because there's a lot more work to do on, let's say figuring out these strategies. In game theory we like to know that okay is this an equilibrium or not like what should I do as a user what is my best strategy. So yeah, this is kind of still on the roadmap to figure out something I actually hope to do with a team here in Singapore. So yeah maybe more detail on this at a later point but read through it and let me know if you have like any questions or thoughts or if it's helpful at all. Thanks. Does anyone on the call have any thoughts questions. Okay. In that case maybe Abdullah makes sense for you to take also a couple minutes to walk through some of the tooling you've been working on. Sure. So to give a bit of background so we can see that this IP introduces a lot of breaking changes. In terms of UX and all of those stuff with new block header field and the new transaction fields. So that impacts wallet providers block explorers. So almost all the chain. So we decided to implement some tooling around 1559 to make it easier for users to interact with the test net. Also for client implementers that will join after that will be easier for them to do to do their implementation and to validate it. So yeah, I will show you some of the tooling. Let me share my screen. Okay. So first we have standalone components that have the rest API. So we have open API documentation. So this is pretty standard documentation. So we have some RPC not RPC so we have some rest API is to to basically submit transaction using legacy style on the new format style. And yeah, another thing is likely we will have to change the format of the transaction again when we will use the type transaction envelope. So if we already have this tooling we will change only one tool and that will be profitable for everyone. So yeah, some API to play with transactions and some API to basically retrieve the base fee because this is not yet integrated in the current RPC endpoint. So you can try directly using this interface. I have to choose the right endpoint. And yeah, you can get the base fee so if you don't specify the block number it retrieves the base fee of the latest block and you can get the base fee for at a given block. Here it is. And yeah, so this is a standalone HTTP service say and on top of that we also built web interface to make even easier for users to play with it. So yeah, we obviously there is an issue there because you have to specify the private key because MetaMask and all other wallet providers don't have the new format transaction. So I'm planning to add the white list mechanism to accept only private keys from the genesis and this is already what I do in the web interface for example, you can choose among a list of accounts that is loaded directly from the genesis. So the UI provides some links to the specification, work updates. Also we have a block explorer for the testnet and network stages. So we can see the three Bezo nodes and the MetaMask nodes. So if anyone needs the credentials for the head start, let us know in the Discord channel. And we started also to write a wiki guide basically to join the testnet. So this is why I'm gathering information from MetaMask and get as well about the branches to use. I would need also the genesis file and the configuration file and the scripts to launch the different clients. So if you need the genesis you can click there and you will have the Bezo genesis. So that will be great if you could provide me the MetaMask genesis and get genesis as well. Same for the CLI option or config file will be even better. And yeah basically let's do a quick demo. So you can specify all the transaction fields. So I'm in legacy mode so I have only the already existing fields. And set autonome so it will retrieve the nodes using the head transaction endpoint. I can choose the recipient, the value, the unit, gas limit and gas price. So this will be a legacy transaction that will be automatically converted to any 1559 transaction. So you have the link to the explorer. So the transaction has not been mine. Here it is. So you can see the information of the transaction. So we have not updated yet the explorer to integrate the 1559 fields. So this is why you can see the gas price set to zero. And yeah, if I switch to 1559 I can see two new fields and the gas price is not available anymore. So the minor bribe and the FICAP. So the minor bribe will be added on top of the base fee. I have a helper button estimate that basically take, it sets the minor bribe to one way. The value is configurable for the settings. And it also add a margin on top of that. And also it retrieves the latest base fee. And there is an addition with all those three things to have a work in FICAP. So obviously you can play with different settings, but this is just to have an easy to do settings. And basically you can submit the 1559 transaction the same way. Okay, it has been mined. And yeah, that's it. And about the tooling, we also have a tool that basically stress test the network and try to fill blocks. So let me show you one block, for example, that have been created 20 minutes ago. There is nearly 2000 transaction in that block for gas used near 40 million. So we almost reached the maximum block elasticity. So yeah, and this tool is a command line tool. So all those tools are open source. And yeah, I will provide the links of the repositories in the Discord channel. And yeah, that's pretty much it. Cool. Thank you for the demo. Any other thoughts, comments on it? Okay. Oh, sorry. I say it's really cool. Great job. Thanks. Sweet. So I guess the next kind of big thing to figure out is what are the next step for the test nets. So it seems like we have, you know, basu and Nethermine kind of 95% there, get and basu seems like it's pretty much there. And we still need to see what get the Nethermine. How much more time do you people think we need to spend on the POA network? And then is it worth starting to look at proof of work in parallel, whether people feel is like the best next step here. It'd be nice to agree on if we're going to do 2017 or not. So we can get that in one. Okay. Yeah, maybe we can start there. My, I guess opinion on 2017 is I would implement it once it's actually kind of scheduled for a hard fork block on main net. I'm just scared that like, I don't know, it gets pulled out at the last minute or kind of changed or whatnot. So even if it, even if it's not scheduled with 2930, then it will be scheduled with 1559, I believe. Like I think the, the plan is is 2718 will go out with the next new transaction type, whatever that is. If that's not 2930 in Berlin, then 1559 is a good candidate for the next. I don't believe anyone really wants to release a new transaction type without it. It's the impression I've gotten at least. I guess my, yeah, my only concern is it feels like it's not really a blocker to add 2718 support, right? Like we know we can do it and it's pretty straightforward. And, you know, we, there's no kind of huge rush to do it as well because, you know, 1559 is not a long pull, certainly. It's just one of those things that needs to be done sometime before 1559 launches. Yeah. And if we are waiting for someone to implement, like if we wait to do 15 or 2718 until later, then it means open Ethereum and guess have to implement something and then change it. Whereas maybe it will encourage them to implement if they have money name or complete spec. It's one of the problems that I know we're having is trying to get other people to implement. Like maybe that's contributing. Yeah, I think open Ethereum, my hunch is they probably won't implement anything until it's actually scheduled for main net. Turbo get said that they don't really have an issue with implementing 1559 but they're just not in a rush to do so. I personally would be a bit biased towards trying to test proof of work before just to make sure that there's no actual issues there but yeah I'm curious. I don't know. Thomas and, and Rick, do you have any strong opinions on that. My opinion is not very strong, but my preference would be to implement. 2718 is that what it is. Yeah, yeah, to implement it sooner rather than later. Okay. I just don't see any. I mean the work has to get done either way. And I think I'm not entirely clear. What is where the total roadmap is frankly so once we. I do believe the plan is to move to the single transaction type and, and, and once we've done that there's no two pools anymore there's just one transaction type. Once that's done. Is there anything else that needs to really be done. I mean besides the enormous amount of testing. I think I think 2718 is the last kind of major spec change, like, and after that, yeah, I think it's testing both proof of work and just like dealing with a large state, which is something we're starting to do on the basic side. But yeah, I think in terms of like big changes to the, the actual eep itself 2718 would be the last one. I'm sorry when you said large state you mean just the fact that the blocks are bigger so there's more state. No so one thing we're trying to work on it base you is to see the performance impact of 1559 on a network that has kind of a state comparable with my net so we're going to start building, you know just local test nets, first to have you know 10,000 accounts 10,000 a million and whatnot and see if there's any like major performance impact of 1559 on those. But that is something we can do in parallel and I'll probably take a couple weeks at least to get going. Okay. Two questions for me one request suggesting two polls and we already have one poll on me on the IP 1559 and like there is no need for for introducing two polls because they to transaction types they very nicely. Yeah, it's we're already at one pool. Okay, great. That was the last major change I was aware of but it's already been done. And then I mean center student team they you say to check the state size how would you IP 1559 even affect the state is there like it doesn't really change the behavior of the existing system so there is. Okay, yeah. Yeah, I just wanted to say, this is because people are already worried about the actual state and the pace goes up and effectively 1559 won't. Because of the block elasticity, some people are worried about the negative impact it can have. How can you how can you just. I mean, what was there to compare like between the IP 1559 and the existing state that's just the state will be growing potentially like, I think, and person faster but it's only temporary. So the fear is there's some, there's some super net super linear issue with gas per block, and a single block that is twice as big. When interacting with a large state network like main net could have super linear costs that are not like that's exactly it so I think if we can at least run this, you know, have a test net which has 100 million accounts and a smart contract with 100 million costs, we can run it both on 1559 and not and just see you know is anything kind of much worse under the 1559 case where the blocks are twice as big. I really really the test we need could be done without 1559 just having a 4040 million gas block against a large state network. Simply fork off main net set the block gas limit to 40 million and then fill a bunch of blocks and see if anything crashes. So team instead maybe instead of faking this network big network let's just work main net and that will be better test and faster achievement of just. For private distance with we can use any accounts that we want to create just able signature checking. Yeah. Go ahead up though. It will be harder to have accounts with large value of it. Not really though you can add that in the hard fork right. Okay, yeah, okay, okay, yeah, okay, that makes sense. So you can use the table signature tracking and then you could use any account you wanted. As part of the fork that way you could test with any account that has any arbitrary real world situation going on. There is nothing like signature checking it's just the extraction of the address so this is a bit harder. You just have the signature like the, you just have the R value is just treated as an address. Whatever the R value is use that address, like just as part of the fork, if one wanted. But then but then the formative transaction is different. So it seems like a bit more work. Yeah, then just adding your list of accounts, like adding your list of Wales basically as part of the hard fork. Yeah, this is super simple. That's what I say the same simple and the other one is just requiring new transaction format which. I assume we can also change that in a hard fork but we could change the hash rate as well, right like just lower the hash rate back down to basically zero. Yeah, you want to set the difficulty to zero so that way you can mine on your three difficult laptops. Just as a slight side note, in general, I think that this being able to fork mainnet and test would be very useful for many people in many situations. So if you guys do do this, add this feature into your clients, it'd be awesome if you kind of formalize it at least a little bit just so like someone can use like a config file that does this in the future. I know I've wanted it many times in the past during testing. You can share it in the mind to change back for such a chain and then you can sync to it. So if we if we launch a public testnet on it and then people will be able to start testing it will be great actually, because practically everyone who has they may not may not if can just use a different chain ID for signing transaction and start experimenting on it. Yeah. You're saying there's existing tools like that, Rick. Yeah, like hard hat apparently claims to do that. I haven't tested it. Nice. It used to be called builder but now it's called hard hat. Apparently it will fork from mainnet. You can share a link to that Rick in the in the discord. That would be great. Yeah, yeah. Thanks. Yeah, so this, I guess, just from a testnet perspective. Does it make sense then to go from this proof of authority test that we have now to that, like fork of mainnet do we want like a smaller proof of work testnet in between or should we go just to fork in mainnet. Anyone feel like we shouldn't do that. Test and prod, basically. And I guess if we get it, if we get 1000 bugs for key mainnet, maybe we can try something easier. I think it will be very useful for the future as well just like mainnet working for testing different DIP's like imagine for every single EP will be able to create a separate fork and people will be able to use their accounts that they are used to to check if their contracts work fine. Yeah, I think that's it. That's a good idea. So then, okay, so I think it's still worth kind of just ironing out the details on the proof of authority testnet to make sure we're actually all kind of compatible with each other. Should we implement 2718 before we fork mainnet so like when we do the fork of mainnet should that be a new version of the 1559 spec. I would prefer not to. Okay, so just go to mainnet ASAP. Yeah, same. Okay, and then once we've once we've forked mainnet and we see that it, you know, generally works. Then, then we can add the change for 2718, right. Yeah, we've got to have it for 2930 pretty soon so I think the one big time difference but just wouldn't like to say that we have to have 2718 to just do the fork of this test. Okay. Let me know when it's when. Sorry, go ahead, Micah. Just let me know when you guys are ready to do 2718 and I'll update the AP 1559 with it. I've been waiting until you guys are ready. I didn't want to have the AP. Once again, out of sync with what's actually live since that had problems before. Okay, so yeah, let's do that. Let's try and like, you know, a finish like the proof of work at proof of authority work we have right now. In parallel, I think us, you know, at the basic team we can start looking at like just the hard fork for mainnet and what what that would look like and share that information. And so hopefully, by the time that's done, we have everyone kind of agreeing on the spec on POA, and then we can we can do the fork on with multiple clients on on the mainnet. And then after that, assuming everything goes smoothly, we can add the spec for 2718 as part of it and and we'll already have this mainnet size testnet. Does that generally make sense. Yes. Anything else on test nets or just next steps in terms of testing. If not just lasting. I think I wanted to go over is just this mainnet readiness checklist to make sure it's still roughly up to date based on this conversation I'll have to change it. But just also useful for people tuning in it's kind of where we keep track of things that needs to be done. So the client teams have been changed, I guess not the mind, you did hire somebody so we can remove this. Yeah, I cannot yet confirming 100% but mostly yes. Okay, yes. Okay, so I'll leave it up for now and pay me when you want it to move. In terms of issues, the OS risks, I mean this is kind of separate from from this EIP itself. So I, you know, I don't think we can do much except kind of working mainnet like we just talked about and that maybe give some interesting data. And then coding decoding will wait for 2718 but do that afterwards replaced by fee I think is the other thing we haven't like fully sorted out. And, and it's kind of related to transaction for sorting, but like how do we actually sort transactions and replace them in a transaction pool without creating denial of service risks. I know Barnaby. Sorry, go ahead. I think we kind of assume that we would have to prioritize new format transaction because we have removed migration period. So, if we don't do that there will be no incentive to use a new format. Right. So, so the incentive to use a new format is you get a refund on your feet cap. Oh yeah, that's true. Yeah. And we should probably prioritize the transactions. So you're saying 1559 style transactions. Do what in the transaction pool or in the block to get prioritized. They just, they just both. They just get prior either. Well, you don't have to, if you don't. I mean, if they're prioritized in the block that's pretty much the same thing as saying they're prioritized in the pool. The more it's a stricter prioritizing, right? Yeah. So, well, I agree that like altruistically prioritizing would be good. It's in a minor's interest to choose the ones going to pay them the most regardless of what we suggest they prioritize and therefore clients who want minors to use their clients will write code that minors like, which means I don't think we can really enforce that. I work with minors. I don't really, I don't know that I'd necessarily buy that narrative minors. You know, we think they'll use whatever we write. Yes, we all just, if those of us in this room agreed to just write the same thing and those use that same thing. Yeah, yeah, and I don't really see the downside. If, if minors do choose to rewrite, I'm not, I mean, I think, I guess my thinking is the social consensus should be that we're all moving towards 1559 style transactions. I mean, that's where kind of on this call trying to, you know, through this bizarre process figure out what the social consensus is. I think we should be pretty assertive in actually, you know, we should assert that these new transaction types are the preferred type, and we should do that by telling the clients to sort them, you know, insert them first. And if someone wants to write their client, they can do that. There's not only minors, but also the users who may not have access to the tools for some of the operations that I'll be executing. So not all of the users will be able to switch quickly. And it doesn't feel like there is a such a requirement to prioritize the new transactions very rapidly. So they will all work very nicely side by side. We plan to prioritize based on the fee paid to minors as a resulting from the discrepancy between the gas price gas fee max cap and so on. I think it would be risky to create two different markets without because we removed the transition but also if we started doing some kind of prioritizations it will create two markets it would be completed not on the same basis and we don't have any analysis of the favor of such market and some users could be just removed from that market just because they cannot use some tooling. So how do you expect people to stop using the traditional transactions. There will be more tools will be using them, and they will be like if they if they 1559 is solid enough and if it saves for users they predictive predictability of the gas prices as we all prove that it does by simulations then users will be moving towards those better tools. But in that case, maybe wallet providers won't do the implementation. If they can do. They will because they compete on the market to be the best all available on the market for the users. So they want to have their users be able to see a P1559. I, so, um, I, I mean, let's know I don't know that competition in the, I guess philosophically philosophically that seems inconsistent to me. So either we are deciding what the new transaction type is, or we're going to allow people to choose. I don't think we can split the difference. I feel like the, the way we've been moving is though, to allow people to choose right because by removing the transition period we're basically saying, you know, yeah, so go ahead. Yeah. I didn't mean to interrupt sorry I thought I heard a break. No, no, no, go yeah go ahead. So just to be clear, this will this prioritization will only come up in full blocks right so if our estimates are correct like 5% of the time will actually have prioritization matter. What's your reaction that I guess the time it will come up is like right after the hard fork, right like they'll be, but this is not like a huge deal. I made for like 10 for like 15 minutes. Yes, because we are expecting like what while we're working but then after that the, I believe the expectation is is we should not see really prioritization have any effect and to accept for an overfill blocks meaning more than 2x demand increase. So, so I think whichever route we choose, it doesn't matter too much because of that. Yeah, so my assumption is that no one is going to change with, I mean, the incentive, as I understand it now is that they get or there's a discount on the 1559 transactions. How big is that discount. So the, I think the reason wallets will change, I actually have a blog post that I'm going to post probably tomorrow about this, but I think the reason wallets will change is because it solves a major support headache for them. Coinbase wallet is the kind of canonical example because they do not allow the user to set the gas price they set it for them because they have determined that setting gas for gas prices is too complicated for their users. And so the problem is, is that this works great, except for when there's increasing congestion, at which point, Coinbase users all simultaneously suffer because all of them end up stuck. It's pending transactions and those pending transactions compound the spells because the user don't know how to deal with it. And so they just send more transactions thinking, oh, that one didn't work. Let me just refresh the page and try again. And then they end up with like 15 transactions stuck and then they need to give specialized support to help them get out of that. The Coinbase wallet doesn't actually let you solve that problem yourself. You have to switch wallets to solve it. So you switch over to MetaMask or just wait. And so Coinbase, for example, I strongly suspect and I haven't talked to them, but just based on having to support their users, like they are bleeding users to MetaMask. Every single time congestion happens because every support channel and then says to people, oh, stop using Coinbase wallet. Whereas with 1559, they can just set the base fee to like two or three times the current base fee. And their users will basically never get pending transactions, like unless we have some crazy ramp up in gas prices. And so I think for wallets, that's the big sell. It solves a major user UX problem that causes heavy support load. And then I think users will just follow their wallets. That's my theory. We of course can't know for sure. If we look at the transactions, the way they are treated, they all become EIP 1559 they just come in more efficient or less efficient as the gas prices defined either as a max fee and gas premium, which actually can give you some discount or as a gas price, which always pays maximum potential gas premium. So they all EIP 1559, we are totally free to support them indefinitely after transition to EIP 1559. EIP 1559 by itself, it solves the problem, whether you make everyone start using new transaction type or not. And the users will, because of how good it will be in simplifying their pricing mechanism and saving them some of the gas fee, they will transition to the tools with EIP 1559. So I think you're making, I agree with your argument, even though I don't think it's ontologically. Look, you're basically saying, when you use users, you mean wallets, you're saying that wallets will because if basically if I use this other old wallet that doesn't update my gas fees are going to be higher by using the old wallets so the wallets will change. Because the users, the whole problem here is the users don't have this like, we all know so much more about how the system works than a normal user the users aren't going to know what's going on all the users going to see is that if they use wallet a their fees are whatever percent cheaper than if they use wallet wallet B so they're going to stop using wallet B and so my own and that's a perfectly fine model, but then my question is how big is that discount. It depends. So I think the way to think about that discount is almost more in the engineer time you spend on your gas estimation algorithm, because in theory, if you got. So if you use the legacy transaction format and you estimated things just right where like your fee cap, or you sorry your gas price is equivalent to the base fee plus one way. And you get that estimate just right your discount might actually be zero right like you might be able to like sneak in at the right 1559 price using your legacy transaction. But the challenge is like that's just a hard estimation to do, whereas under 1559 it's kind of trivial. So I feel like the discount is more like. Yeah, the engineering effort you spend on your estimation algorithm, which will not be kind of perfect. Does that make sense. Yeah, yeah. The problem that you're solving with VIP 1559 is that people have trouble to actually calculate this perfect pricing so. Exactly. The minimum discount will be zero but it will be never will be never paying less with the old style transactions. Yeah, users I don't mean only wallets. I mean also many users that build their custom tools custom. I'll go trading tools or whatever that are actually generating transactions with the custom built solutions based on the client code. And there are probably plenty of users like this and it might be very big cost for them to have to transition tools and some risk potentially. And we want to avoid that risks. I'm talking about users in general whoever is signing transactions generating transactions. So by volume, do you which group do you think represents the majority of, I mean I guess. I think that that's, I understand what you're saying there. I think that those are that's a very different model for who the chain is for right if you are making millions of dollars a day. Running your art box, then you can figure out how to patch your code. Right I don't, I'm not I'm not worried about those people. They're all very savvy and very capable. I'm more worried about the broader base of people that are represent the larger numeric number of people not the value on chain right I mean at some point. Why are we doing this if we're doing it to facilitate arbitraging, then you know there's no point in even having this call if we're trying to increase adoption and make more applications viable on Ethereum, then that's when these sorts of changes become important. The broader base of user would be the one that is using the most common tools and the most common tools would be the ones who would be implementing the IP 1559, like Metamask or Coinbase wallet. So, yeah, I think it's, it's okay to think like this but I do see that there is an incentive for let's say the major wallet that the non power users are using to shift to 1559. So I think my opinion on the why shift, why switch is is not for the fee saving, like I don't, I don't think Coinbase wallet's going to add the code to save fees for their users and I don't think Metamask is going to add the code to save fees for users. I really do think both of them will change because it saves, it improves the UX for their users pretty significantly in certain situations, and those situations are a support nightmare. I currently have a team running support in Uniswap and the number one problem that Uniswap users have like 100 questions every single day scammers are number one. Number two is my transaction is stuck pending. Like this is the support load for decentralized apps and decentralized wallets. Like the number one question after I got scammed is why is my transaction pending? What is a gas fee? Why is, why do I have 17 Q transactions? Like what happened? How do I fix this? Like these are all like this is where support comes costs come from. And so I think 1559 makes it so that should only happen incredibly rarely. Like when you have, you know, six blocks in a row that are all double full, which we expect to be an incredibly rare event. And so I'm of the opinion that the gas savings, the fee savings is not the big deal. Like, I don't, I agree with Rick that people will not switch for that gas savings because it's fairly minimal in the end, but I do think people will switch for that UX improvement. Like, and, and I think that's where I disagree with Rick at least a little bit is just that I do think people will volunteer or wallets will voluntarily move, which will cause users to move because users will follow the wallets, just because the support burden is so high for this issue. I guess to take a step back about the transaction pool sorting, you know, this is not something we can enforce in consensus without major changes to the spec. Yeah, I personally would be pretty opposed to doing that just because this is already a hugely complex deep and and like trying to enforce ordering in every single block feels like you're adding another. I don't, I don't think there's even a known, known solution to that problem right now. Yeah, so in that case, basically, you know, the transaction pool is outlet consensus. We don't necessarily have to have a solution on that now, right, like I think it's, and it's also something we can update in like we don't need a hard fork to update it right we can update it in like a, you know, bi-weekly release of gas or basic or whatever. If we see that there's an issue, obviously, that's not like 100% true because, you know, miners won't have to update their notes then and they will add the hard fork. But I guess I'm just, you know, it feels like kind of a pretty big rabbit hole that we might not get resolution on right now and we can fix. I agree we don't need to agree on it. But I do think there's value in making sure at least every client knows what they're going to do. Like make sure everybody has a plan and that we kind of talk to each other and share what our plans are so that way no one's left like having to think solve this problem yet again while someone else already solved it. And same thing with the replace by fee, like everybody has to solve the replace by fee problem. They can solve it differently, but it'd be nice to at least share our potential solutions with each other. Yeah, and replace by fee, I guess to me is a bit different because we talked about it on the discord, I think it was like a month ago. And it seemed like there were a bunch of solutions that were vulnerable to potential denial of service risks. So I think this is something where maybe yeah, having a canonical formula that's like different clients all use that we know is somewhat safe. Actually has like a pretty big benefits rather than the ordering you have 1559 versus non 1559 transactions. And obviously there's overlap right like the replace by fee might change how you do the ordering, but yeah, I think that's one more having a common solution is higher priority. Yeah, I agree. We saw that recently with guests where they their semantics for transaction ordering resulted in some problems because they're the dominant minor. Yeah. Yeah. And I know, I don't know if I'm remembering this right but I feel like Barnaby you had put together a formula or something for the replace by fee that was like decent. Is that correct. Okay, it was just a way to make sure that you never can replace for free where by for free. I mean, you can do it indefinitely just spamming the network and you never get accountable for it. But you need to increase, like the minimum between the minor bribe if I remember correctly, the between the minor bribe and the fake up, like the minimum of the two has to increase with every replaced by probably has to increase by like 10% or something but but that's the only way that you don't get into edge cases where I'm resubmitting with a different minor bribe, but it doesn't really matter anyway because I'm maxed out on my fake up or the other way around. So, yeah, it's it's we've discussed it a bit. I don't think it was very optimal but it seemed that there wasn't any other option that didn't like protect you from spam. Is there, I don't know what's like the right place to just like store that or save that so that there's like a proper discussion on it because yeah I remember like discord messages. I write something. Yeah, if you could write something up that would be that would be really valuable and then all the client teams can kind of look at it and give feedback and I think even getting like you know Peter and Martin and from guests to look at it could be could be really valuable. Awesome. Yeah. Cool. Okay, and so yeah, I think yeah for the transaction pool sorting we can just keep the conversation going and shares would make progress but it feels like there's a lot of different options and we don't necessarily need to resolve it now. Well, it sounds like they don't need to be sorted at all. Right. I mean, am I missing something I mean basically Yeah, it doesn't sound like you need to do any different sorting than what's already been done, because there's only one transaction type. Effectively if you depend on how you code it. I mean you could like have a flag on on your transactions that get memory. And then you say this one was originally a legacy transaction so we're going to be prioritized or prioritize so it would be possible. But if you code it such that like when the legacy transaction comes in you basically do an in memory conversion, and then you drop it into a pool with everything else. You could very easily design it such that you forgot that it was a legacy transaction originally. I think this is, I mean, I'm sorry, I don't want to beat this dead horse but I think for me the issue is having these different code paths for something as used as broadly in the geth code base as transactions is a risk. But if other implementers or implementers are comfortable, just, you know, absorbing that risk and perpetuity that you'll have to transaction types with no cut off for when you'll support the old type. That's, that's fine with me, but I just seem it just seems like it'd be better to plan that than not plan it. I think the last I remember we talked about this there was the tentative plan for deprecation. If we decide to go forward with it was to introduce a basically legacy transaction tax that if you submit a legacy transaction you would be taxed a little bit and that tax rate would increase over the span of like two years or something. The major counter argument against any kind of deprecation is people who have signed transactions from a paper wallet from three years ago that they cannot resign for whatever reason. We want to make sure their transactions will always be valid and submitable to the chain even in 10 years. I think that's the main contention that I've heard is just do we deprecate it all? Yeah, that's a perfectly fine argument. I think that, you know, I met my experience in working with geth, which is limited, but my experience in working with geth is that's ultimately going to be some sort of, you know, recipe for an event in the future where things go sideways but if that's the desired user experience that's that's fine with me. Is that worth maybe just adding as like a security consideration in the EAP? Like, I don't know. I think that's worth it. Because what kind of risk is suggesting that actually this sorting mechanism is working, I mean, we still will have to define how exactly this conversion is done. I think that's a good point here, because the gas price to FICAP conversion or like to premium conversion is different and different block. We are just discussing today in that in mind that when you sort, like then historically would sort and that sorting order would be unchanged from block to block. If you start sorting by gas price including the legacy and EAP-1559 transactions and EAP-1559 change their gas premium based on the block by block because of the FICAP being there. So the sorting order may change even without new transactions arriving or not. So sorry, I'm missing something. Why would the sort order change? Like certain transactions will no longer be eligible. We cannot determine the actual value of transactions because it depends on the block. Yeah, because if your FICAP is reached, you may end up with a lower minor bribe than the previous block. Yeah, I see it. Okay. That's unfortunate. That sucks. Yeah, so I think that when we talk, maybe we should just sort of change this bullet point to say, instead of transaction pool sorting, transaction pool eviction, right? If I'm understanding that is actually an issue. Is that what you were just saying, Thomas? I mean, it's good to keep the discussion and maybe write down how everyone decided to do that because maybe we just assume that we'll do it the same way, but we won't. Yeah, definitely. I agree with your comment here, Rick, that it may go wrong if we at least don't describe it so everyone can read it and feel confident. And I think the account abstraction EEP actually did that quite well. They posted in all core depths this week and I was reading it, but they, as part of the EEP they have like suggested behaviors for the transaction pool, right? And that's not obviously part of consensus, but they still specify it in the EEP and explain the rationale why. So I think that's probably something we'd want to do as well. There was some talk a while back and I just realized not on this agenda about actual eviction strategies. Again, not a consensus issue technically, but there was discussion of what if we just say your transaction is evicted if the base fee goes path up, like passes up your fee cap, like you just flat out getting evicted, need to resubmit. The idea being that we can keep the pending pool cleaner, like thinner, the disadvantage being that it could result in more gossip if the base fee is fluctuating heavily. So we were thinking to keep even the negative, negative, sorry, trying to find the, you call it minor bribe, okay, negative minor bribe in the pool if it's still in the top X transactions is if you assume that the pool holds 4,000 transactions and some of them towards the bottom are actually having different negative values, we still want to keep them and drop them in better transactions arrive. The bigger question for us was what if we drop transactions that actually after the base fee falls would become a bit more minor friendly afterwards, but we think that's not a very big issue, but it might be so I'd prefer to have it on paper. Yeah, there was, there's an argument I think Vitalik made it where there was some, I'm trying to remember if someone else remembers please jump in. There's some potential advantage we get by evicting people evicting transactions. Because it solves some kind of nuisance problem that we've had in the past. Anyone remember, if not, I'll bring it up later. It's actually interesting scenario where users. Go ahead. Okay, it was the idea that you could send your transaction with a fee that was too low. Let's say lower than base fee currently is so that you just wait for it to be included when base fee becomes lower and I think the argument was that you shouldn't be using the network as your like transaction pending transaction queue, your personal pending transaction. Right, it was basically don't peers should not accept transactions with base fees that wouldn't be included in the current block. Like if you get someone gossips you something and it's not can be included just reject it and say yeah don't don't tell me about that please. It's a waste of gossip. Yeah, a softer rule to say, if your transaction is 10% below the current base fee. Okay, then we accept but if it's, if you're just sending it in the hope that base fee gets halved at some point, then we shouldn't be looking at it because it's too, too much to handle. Yeah, I'm a fan of that it reduces the gossip of the network and like you said, it keeps you from using the network as their personal storage effectively. I think it would be intuitive and problematic for some of the wallet users but I'm not very against it, but I think it's not necessary that we already have all the clients holding top x best transactions and even with it 1559 we still be able to tell which transactions are best. So there is no need to specifically evict them different way. I think the idea is with 1559, the pending pool actually should be empty most of the time. Right. If we are evicts people that base fees too low, or if we don't accept people base fees too low. Like so the whole idea of like historically we've always had if any pool it's always full. We're saying that hey we don't have to do that anymore, we can now run clients with basically empty pending pools almost always because your transaction either is included right away, like within a few blocks, or it's not going to be included at all. Like those are the two scenarios. And so we don't need to have like, you know, 50 megabyte pending pool anymore. If we if we don't, if we decide we don't want to gossip that stuff. Okay, so does it make sense to keep discussing this, like, yeah, to discuss the different options and more details I feel like personally I just need to think through it more. I do think there's value in discussing and at least having every client document what they do for replaced by fee, what they do for eviction what they do for accepting gossip of do transactions, and what they do for transaction pool sorting. Like I think knowing what each of the clients do for those four is valuable. And I suspect, once each client gets to implementing it, they're going to have a quite it's going to come up as a question and they're going to ask what are other clients doing. And so I think just having that documented and talking about it is valuable. So replace eviction sorting. And what was the fourth and gossip acceptance around with the word for that. Yeah, what what do you what does your client accept this gossip as a valid transaction. And what do you not accept this gossip and then also this is actually very important. What will you kick people out of gossip for like someone gossips you something that you think is just outright wrong. You probably are going to blacklist them. So we want to make sure clients are in blacklancing each other. So we need to at least agree on that much. And what's the worst the best place to like actually write that down probably not in the eep itself, but it feels. I don't want to have a suggestion. I agree not to eat. I can start a hack MD document I'll link it in there. I'll link it in this in this page and I'll just add a section for every client. And then people can, can, can just add their behavior there. I'm sorry just needed to shut. I'm not sure an informational. I wouldn't do an utter eep until we're actually like settled on some best practices. And maybe once we are settled on some best practices we can add it out it's I don't know like some appendix to this eep or something, but just now. Yeah. Okay. So testing reference consensus tests. I don't think we're quite there yet, especially given that like the 2718 change still hasn't been done. It's probably a bit too early. Community testing, like I think we're starting to do this. And, you know, Abel's tool can kind of help people interact with the network. We'll keep improving on it. And then I think the public test that applications can use this is basically our fork of mainnet that we discussed earlier so it seems like it's going well.