 Okay, let me grab the agenda again for anybody in the chat who hasn't seen it yet. This is the second post London breakout call, I think number 13. Thanks everybody for joining. I appreciate people taking time to help us, you know, share your feedback and any issues that you've had. Like I said, we don't have a ton on the agenda so there's going to be a lot of open space for discussion, or us to just look at each other's faces, maybe. So, the first thing. Jake, if you want to kick us off that's fine or we can start with something else but be really cool. Something I've been looking forward to is seeing a little bit inside of how the other wallets have been handling 1559 I know we've got a couple other teams here. And I'd love to hear from them as well if they like to say anything but Jake if you want to start. Give us your general thoughts or if your presentation prepared. I have a presentation but have some, some thoughts for sure. So I can, I can talk about kind of the, the UX of how at least how MetaMask has implemented 1559 how it's been received. I think, like, overall, I think it's going well but there's a lot of, there's a lot of noise on like Twitter and public places, we, like, we definitely learned we shook up people's workflows who use advanced settings. There, there was the thought of advanced settings we should represent how the actual fields are in the UI so like give them max priority fee give them max fee. Don't try to sugarcoat it for advanced users. I, we definitely have learned that people who are drifting towards advanced fields are not always people who like truly understand how 1559 works. You know people are saying, switch back to the old controls we don't like these new controls these are dumb and it's like, you know, so, so they're even advanced type users I guess are not as up to date as we hoped or assumed. So what we are learning is that that vocal group of people seems to be a very small group of people. So we have we have we've been tracking some analytics and our analytics are rough because we don't track a ton of things in details and for privacy reasons but one one reason stat that was interesting is and is on the call correct me if I'm wrong but I think it was 20% of people have only attempted to edit to click the edit button of a transaction in the past seven days. So that means only 20% are even getting to the point in our UI where they could be exposed to the advanced UI and that doesn't even mean they actually added it, or that they found it confusing or that they said something bad about it or good about it. So it is a small number of users that are getting into there but we definitely need to support that you like support that use case a little bit better so that's one thing we're really focusing on is like how do we improve this advanced edit experience. Advanced being, you know, going off the rails of an estimate like not using a default value. And one thing that we've learned as well as so on the flip side, only 20 proceed or, you know, 80% of people have not clicked edit in the past seven days. That could also be dangerous because we're seeing really big price spikes right like so there's kind of consistent price spikes with nft drops or wherever it may be. In those cases, we actually, you know, we want people to at least be aware that they, they potentially could pay less and they don't have to pay market value if they're willing to wait for their transaction to go through and going into 1559. I think there was also an assumption that, you know, let's focus less on editing there maybe there's less value in waiting and paying a lower price, since we, you know, we have better estimates and just kind of give you the estimate you'll go, go through with it the transaction will go through soon and that's great. With these price spikes, I think we need to support, like the use case of like all weights like I'll set my transaction I'll queue it up and I'll wait for the base fee to come come down dramatically in the case of a price spike. Also on the flip side, for people trying to get into nft drops and stuff. They use the advanced controls, even though I don't think they fully understood within MetaMask like what I mean they were only editing one field before there was the gas price right so it was much easier to edit a couple fields. And, you know, I've sat in a couple of discords with a kind of t drops and stuff and people are talking about like what do I change my gas settings and they're discussing it and now that we don't now that we don't have like, so our basic estimate right now are low medium high. There's not a huge variation between them. They're all kind of in the same range. So we need to be I think have much lower options and much higher options, much higher options for those when there is a price increase in the amount of gas we're coming, allowing people to be easier, you know, to access that type of setting easier. Trying to think, I think those were the high points of what we have learned. I'm happy to talk more about it, or more details or answering any questions. We are going so we are looking at, I mean we we launched with the, you know, with a v one we had improvements in mind. So some of these links have shifted that we're, we're going to be rolling out a new UI after another round of user testing so I think we'll learn more in the next couple weeks to if some of what I'm talking about is actually true or just false assumptions but that's kind of reading that's what I've seen. Awesome. Yeah, no that's really great perspective. I remember one of the things you mentioned was a lot of the assumptions that you had gone into the design with were either flipped or, you know, completely wrong. What were do you remember what a few of those were, or maybe I'm remembering somebody else talking about it but I think it was somebody from MetaMask. Yeah, I may have said something like that. I think it really is the assumption that one people, people will understand, like if you give people if you call something advanced, and you give them the advanced controls. And you assume they know, like, if you represent what's going on behind the scenes accurately that that it's okay if they don't understand it because it's advanced, right, and maybe it's not for them and if they, if they want to use advanced controls, they're going to understand it. It doesn't seem to be the case like people even even people who have an understanding or like have a high level understanding of 1559. I think the narrative of, you know, base fee and tip and like just the language that has been thrown out like it just didn't match the two fields that we put in there, right. So it could be as simple as changing the names of them or you know making them a little more accessible. And that was one assumption that we were wrong about. The other I think was that our range of estimates like the algorithm shouldn't be as wide it should be a little bit more conservative and, you know, high medium low is all within this like sort of smaller range. And like, it just doesn't really make sense right like if you're going to go low. You should wait a long time and there should be some risk attached to it that your transaction may not go through and if you go really high there should be some risks that you're going to pay a higher tip, but there's lower you know but that is going to go through much quicker so our assumptions that we didn't need a wider range on our estimate was probably the other one that was wrong. And of course, if I can add to that is like we not anticipate the crazy surges that are happening so often. You know, we assumed that it would happen but we didn't assume that it will happen so often during the day, it happened several times a day. And I think therefore the controls were, as Jake said a little bit more towards the middle as in like the variations were that that different, because we're assuming that the user will choose from from one of those three settings so I think the learnings here is that these spikes will happen and we have to account for that. And, but at the same time the majority of time you know users will choose the middle option. But we have to also provide the flexibility and cases where no users want to, you know, be fast or be slow or, you know, have be be adaptable as much as possible. I have a question. So, when you talk about the sugar coating that you did for the advanced fields. I was curious, like what were the fields that you did expose and like what did what did you call them, or like how did you sugar coat them exactly. So we didn't show them at all. Oh, we literally had two fields there was max priority fee, and max fee, and we have some tool tabs, you can, you know, can look at them but it's like we pretty much just gave you the raw fields if you were going to use them really If you were going to use them realistically you'd have to be, you'd have to have something pulled up another tab you'd have to be looking at, you know, a chart of current base fee and stuff to well, I shouldn't say that they're default populated with their estimates but you'd have to understand what what that meant to go off the rails with them. So. Oh, I see. Yeah, the new. So we are going into user testing now and trying to, you know, shift these fields around a little bit from what I have gathered. And I think which makes sense with just like the narrative around 1559 it's, it's base fee and priority here like that's how people, people who understand 1559 thinking about because that's, that's the mental model that's how it makes sense it. So the the fields that we're looking at now if I'm remembering correctly. Priority fee we're calling a priority fee, even though it's technically a max priority fee which not saying that because the idea of a max priority fee was kind of confusing. And I do think right now we're using max base fee. Yeah, okay. And just saying base fee, but that's yeah. Yeah, our designer was just able to send us over some designs this week and so yeah that that matches with what we have right now is is we decided to show the current base fee and then the two fields that we expose are the max base fee and priority. Cool. And I think exposing the current base fee to is a piece of feedback that and we were going to put in our UI we just haven't we didn't have it in there for the first version but that's been consistent feedback to I mean of course people need a reference point right. Cool. And also may ask what your. So, for the multiple on the base fee that you're doing on the low, medium, high, are you. Oh, I think it's Micah said that. Oh, no, no, so we're what we're saying is unfortunately the way that we're presenting it to our users is not like a max total. So for users who aren't like ultra in the EP 1559 world. So it doesn't make sense. It like gives them more work to do if you make them do the math of like having the total and then subtracting the priority fee versus having the base and adding the priority together that seems to be like the most intuitive way. But so because technically it should be max fee right. Yep. Yeah. So the wording we are using is max base fee for the user to know that this is just the base fee that they're potentially doing a max of is that makes sense. I had also the same confusion when I saw the designs because I was thinking in like a total max. So the protocol does not allow you to set a max base fee. So there's no way that your UI can be asking user for max base fee because that's impossible. You might be asking for something else and then calling a max base fee, but like there's no way you could actually be putting that into a transaction. Right, you're setting the max fee, which would be the difference between your yeah. And that's that's that's one thing that has been confusing is like the max fee like people look at when they see priority fee and max fee they're like well where's the base fee. What's my base fee so you could call the field max fee and then explain around it that well actually this is your base fee you got to subtract your tax priority and like that's kind of what we attempted to do. And I think so it sounds we're just trying to get around that a little bit maybe it sounds like we're in this uncomfortable position where we have a set of users who have heard a little bit about 1559. They're asking where's my base fee that means they like read half an article and are now confused. What I worry about exactly what happened now. What I worry about just a little bit is optimizing user experience for these users that have ever heard of base fee, I would prefer and of course is each wallet can do what they want to prefer to optimize though for users who have never heard of base fees or party fees or transaction fees or anything that brand new to Ethereum, and they're like, I don't know there's a fee here. And I feel like this optimization is kind of special case for the current set of users, not necessarily the future set of users, which maybe at the moment is an appropriate optimization, I don't know. Yeah, I think I think you might be misunderstanding the the UI if I'm like you're saying don't optimize for somebody who would be talking about base fee is that what you're saying like optimize for. Yeah, like if somebody is coming in fresh. Yeah, exactly they're they're not a fresh user. So that's that's totally the case like our UI, you have to go three levels deep before we say anything about base fee. We don't talk about base fee we don't talk about priority fee we're optimizing for we're optimizing for somebody who knows nothing but there we are like what we're hearing about is this like 20% use case of like advanced users who are confused with the advanced setting so that that's what we're talking about and I totally agree. Yeah. Let me just jump right away. Leaky did you want to you've had your hand up for a while did you want to say something. Yeah, the question to me to ask how you currently handle treasure basically now that the firmware is not yet released and how you plan to do it in transition phase where basically some users have the old firmware and some have to handle it in the transition phase where basically some users have the old firmware without one five five nine and some have it with one five five nine. Yeah, currently we don't support. Trezor on 1559 so it falls back to the legacy. But we will support. Trezor shortly. And how do you handle it currently so do you fall back to the old behavior and how do you plan to handle it in the transition phase where basically some users have the old firmware without one five five nine and some have it with one five five nine. Yeah, currently we don't support. But we will support. Trezor shortly. We currently just rolled out today support for ledger. So, you know, all the, you know, supporting hardware wallets are high on our initiative so we're taking them. One, one hardware wallet at a time. And is the ledger support going to be rolled out progressively or is it just 100% allow. I believe it's at 10% right now but yeah it's it's progressively rolled out yeah so we're looking into whether or not things are breaking. We're also getting feedback from the ledger themselves or we're in close partnership with them. Gotcha. Thanks. Yeah, one of the things I'm tracking pretty closely is, or is sort of a proxy for how all the user facing interfaces are working is you scroll to the bottom of the link I just sent legacy verse dynamic fees. We've been hovering around 60 ish percent for the past week. And it's actually decreased in the past few days so it really has ideas for providers that they know of which haven't implemented yet please let me know and I can reach out to them and try to get them support because hopefully we get to 100 sooner rather than later 100% So yeah that was Lee's question about Trezor. I didn't need to interrupt whatever discussion was happening we can jump back into that about naming. Oh yeah, so well I had another question for Jake about what you guys are using for the multiple on on the base fee. And so I assume for like the priority fee you might be using the expose like histogram or or you know what whatever the last few key fees are but what are you guys using for your multiple on the base fee in general or like how do you decide how to do that. Is it. Yeah, I don't have a, sorry, go ahead. Oh yeah because, because you know we've seen a few different places where you know that the base fees like consistently to X and we from like the data doesn't seem like that's necessary and so we're trying to figure out how to be smarter about it so we're not like over bloating that the price for users. Yeah, totally. Sorry it's for the question I think we want to say when we say base fee here we want to say max max fee per gas right max where you to X, the, the, the max priority fee per gas right. So when you mean that when you mean base fee you mean max max do you. I feel like, maybe I'm forgetting something but my understanding was like, like to X base fee plus some tip was like the max that people were recommending earlier on. So I just mean like the multiple like the two times the base fee plus the party like so ignoring the party ignoring. Yeah so ignoring the party we just keeping like what is the multiple to X plus you know that that's what I that's what I'm referring to. There was some initial discussion a few weeks ago about it could possibly be defaulted to 1.2 or 1.3 two might be a little high. Right, but there's no, I don't think any hard research yet. It's probably on Barnaby spec burner for now. But definitely something to anybody if anybody knows of a deeper dive into this I'd love to see it. Yeah, because I guess like. Oh, sorry, go ahead. I think the important question to ask is what what experience do you want for your users and how many of them are you willing to have a bad experience. And that's the trade off right and so if you set that too low you will have a larger percentage of users will end up with a bad experience of things do not go well for them. And so I think a very important question is to decide what what your cutoff is like you want 98% of your users to be happy and 2% to be sad, or do you want you know 99% to be a little less happy and 1% to be very sad. Where a little less happy means they see a bigger number for the fee and sad means their transaction ended up pending for three hours. Yeah, I guess I guess I see having a bigger number for the fee is also a sad category for us isn't that's like, it's right. Yeah, and like the happiest user is sadder. Yeah, I guess like if you could, if and if you could keep the bands right the multiple of this pretty tight, and then just manipulate the priority fee kind of competing in the priority fee in that sense, then you kind of off like your your maximizing kind of there. You're minimizing the bloat that they see and you're maximizing how quickly they can actually successfully get in that time. So yeah I was wondering like, Jake, do you guys have like a hard, hard coded number for this or it's like sort of feels like everybody's got a hard coded number for this and I was wondering if there was any, anything else. Yeah, I hit the nail on the head with like everybody talking about this is like this is like the hardest part because I'm not the best person to speak all these numbers I could probably throw some out but we've been changing them so frequently but they're all within the range that everybody said like 1.2 to 2. And the, the problem is, it's like the happy sad user right like if you take, if you take the middle case, and you try to make 98% of your users happy or whatever which is pretty much what our middle case does. You're totally not supporting the use case of somebody wants to save money in a spike right because you're responding to the market so quickly, but that medium price is relatively high to the past two hours six hours or whatever. So yeah, that middle one is the tricky one like what is the default and like how, and I think we in order to not disappoint users we have to be, we have to show a higher max fee, right. So we have to have people opt in to potentially dangerous for a situation where they have to wait. And I, I'm sorry I don't have the exact numbers I can't answer the question, but I, it was around like 1.5 when we first launched. And, and then it's adjusted from there. And did you. And so is there a big difference though between low medium high on the multiple aspect of it. Yeah, sorry. Like, you know, technically the, the long you wait the higher it can go but then you're paying low you don't want to have this huge, huge range of prices right so you'd expect actually to keep it tighter for even the low just that you don't want them to overpay. And then for that, like, if they're really urgent you also want to keep the, you know, they're just like these people who want this transaction in now or never and in which case, you want to keep the multiple also pretty tight and just bump up the party if you quite a bit so you're competing and getting into ASAP. So, so I assume the multiple shouldn't really change. Like, I don't see it why you would. I don't see how the multiple should change for like a low and medium high per se versus like just the party fee. Yeah, yeah, I think, I think there's definitely some truth there I think for it depends on how low your low setting is right like if the low setting is really low, then I mean the max base fee should be much, much lower than the current base depending on where it is right it should be it should be like a low over a period of time or something. For the high, you're right, like, if it would be like now or never where you would just slightly overestimate like do a medium overestimate of the base fee so that you're eligible for the next couple blocks if you don't get in immediately and then you crank your you're really high up so that it gets accepted immediately and if it doesn't go through well then you just got to wait. And you cancel the transaction worst case scenario is like you miss the ride up and then you get hit on the way down when it comes back down to your max base fee. The other way you would set a high is you would set a super high max base fee and a super high priority fee. And then you're just saying no matter what I want this transaction in right so that like high has a couple ways you could play it like moderate base fee high tip or high tip high max base fee. I have a kind of like a follow up question. Is there anyone actually detecting trends. You know, if there is a trend like the base fee is trending up and you know that will mean that you will have to like potentially choose a higher multiplier. Or you know, a lower if the trend is going down. Is there any wallet doing that. So I'm not not a wallet dev but what I've noticed this is anecdotal Barnaby may have better data of noticed is there tends to be relatively few trends outside of day to day seasonality. With the exception when there's one of these nft sales in which case, there's no way your users getting it get in like the only users that get in over those like five to 30 minutes that nft sales are going on is if they're very professional, you know, bots stuff like that. And so, if you ignore that because no normal users going to be able to beat that. Then I think the trends are just generally general seasonality, you know, like at whatever time it is so that's sorry, at like 8am utc daily is the cheap time of the day, you know, and Sundays tend to be cheaper, the cheapest day of the week so like that seasonality is there but those are very long term trends so if you look at a big graph over many over the whole week you'll see the up and down daily. There doesn't seem to be a lot of trends just like within an hour, for example, again, ignoring the nft sale drop thing. Yeah, we've been we've been tracking doing analytics as well and we're trying to make some sense out of the spikes that are happening. Is it is it regular is a consistent. And there's no consistency to this at all so it's very hard to to create any type of a predictive algorithms based on that. I have a question. Have you actually seen a substantial number of transaction that actually has just the base fee without tipping. Because we've been like, I mean, I guess we haven't done much research but just kind of basic monitoring transactions we did not see any transactions that just the base fee. Everything has some kind of priority. Most. I think almost all interfaces are going to put something in there. The question is, what the default suggestion is, I think that could definitely use some work. Whether it's too high I know one of the issues on the agenda, we can get to that after but it's either a presentation issue or the, I think it's the web 3js is using older version pre 1559 it's suggesting the wrong. The tip the wrong priority fee. But I don't think that there are a ton of transactions going in, if any that have zero tip. I personally have sent the lowest I sent I think was. I think point zero one way it took maybe 15 minutes so much much longer than typical but that's the lowest I've sent and I don't think that's going to be standard for every other user. I think what people are normally recommending is one to two way. Were you asking, are there any UIs that do not prompt user for a priority fee or were you asking if there are any transactions that actually get mined on chain without a priority fee. Well I guess I was asking the latter. The reason I'm asking because we're working on the area now and their version that we came up with is we actually do not present the base fee at all. We have the three priority versions like normal high and high so believe, and all of them include the tip in them. So I'm just wondering if this is a good assumption to make just because in general I. Yeah, the network the gossip network shouldn't actually propagate any transactions that have zero party fee if they if they are that's a bug or a very very altruistic person on the network somewhere. As far as minors, there was some minors initially that had some misconfigured deployments of their nodes around London, and they were mining transactions with zero party fee. They are now all fixed and so a your transaction will not propagate if it's got too low a party fee or shouldn't and be even if it did no one will mine it. If you're running like your own local minor, then you could mine one with zero party fee and minor payouts may do this. But as far as user interfaces for end users, you definitely need to include a priority fee on everything and I wouldn't recommend going below one. Like, below one, you probably won't propagate and so your transaction will kind of get lost in the ether, sorry, lost in the space between things. Thank you. Yeah, the other. Go ahead. On the on the multiplier thing to I do you think maybe somebody has a different opinion on this I'd love to hear it if they do it does seem like the correct. The correct algorithm would adjust based on network traffic right because like if you can submit a point one way tip and blocks aren't filling up. Like, that should probably be the default for your medium option like if it's if we have a strong in if we have a strong belief that there's not going to be a sudden spike which we can never predict it could happen. The default should not like have the user overpay even though I mean point one way and one way is probably not a huge difference. And then that's what the like a higher option should be for is like saying, hey, I want to make sure I get it like I'm buying insurance against a sudden spike I'm there's an NFT drop I'm going into a gas war or something and that's what that setting should be so like the in a perfect world would be much more flexible to medium meaning the default value should be much more flexible to what's going on but that's, and that's something we're exploring but it is, it is hard. As an anecdote, when I'm personally doing transactions on Ethereum. For most of my stuff I do one party fee, just flat and just say one no matter what the way I suggest to me I always put one. If it's something that I really need to go in right away, I will sometimes bump it to like three. The only time I will go up to, like, beyond that is if I'm doing some sort of highly competitive action, like, I'm actually trying to, you know, buy an FT or whatever. Like something where I know there's because of information I have that's outside of the scope of what a wallet has like I know about what's going on in the real world. I know there's going to be a burst of activity and I want to participate in that burst. That's the only time I'll go above like, you know, three. Again, just anecdotal my experience and this seems to work really well. All of my ones go in within a few blocks and my threes basically always go in within one block. I actually just have a quick question, like, I think I've been using 2.5 for literally everything, and I've never not had anything included in the next like block or two. Are we seeing people with like, like, is there actually any meaningful difference between two between 2.5 and like eight. Are we seeing cases where there's a bunch of things in the transaction pool sitting at 2.5 and not getting I also make transactions at times where the gas price is low. So I've I'm also like, low, I don't necessarily work for it but lower than than we're seeing so maybe that's also part of the reason why, but I'm just curious is there actually any value to having a really high priority fee. So the time you need a high priority fee is when you have consecutive multiple consecutive blocks that are, I guess there's two situations one if minors are setting the minimum priority fee though mine, higher than one. We've been advising minors to set it to one because that is above their opportunity cost. And so, you know, a spherical minor will set it to one because that's rational. We don't actually know for sure if the miners are actually doing that and I don't know if anyone has a good data on that but that'd be great to see if possible. So if they're setting it to one or whatever, then in theory the only time you should not be included in the block is if the block was 100% full. And while we do frequently see 100% full blocks we very rarely see more than like two blocks in a row that 100% full sometimes you'll get like three. But even that's pretty rare. Again, ignoring those NFT drops which are just like this oddity that you cannot account for. So you shouldn't see a difference in 2.5 and 8, like you shouldn't really see much of a difference in one and 2.5 even. Yeah, so it seems to me like the more important thing actually set is that multiplier right like that. The priority fee should almost just kind of always be hard-coded. Whatever value you want to use for uncle risk plus MEV risk, whatever. So it's priority fee even the important thing to modify. Like if you're talking about like high, high, medium, low. Like it almost just depends what you really care about. Like I feel like the, sorry, it's kind of loud out here. Sorry, I'm just like, I'm half asleep as well. But I feel like the multiplayer is the more important thing to set in this case is, oh, actually I wanted to bring up another quick thing. I really like what MetaMask is doing with the kind of every couple seconds stall the universe take away the button from me so I can't click on it and like fetch the new price. Because I also think that kind of reduces the problem right now because that means the multiplier that you're using isn't something when the UI first popped up. Like I usually click around for a second, check all the prices, make sure the data looks safe and what's going to do is what I expected to do. So I really enjoy just kind of like having because I feel like that also reduces the risk of what the multiplier needs to be. One quick thing I would kind of like to see like, you know, three seconds left before we refresh this price and they refresh so I find myself doing is waiting until I see the price fade away and the button come back in because then I know it's got the most recent values. Anyways, I'm kind of all over the map but I feel like that multiplier is more important than the priority fee. And that's my, my thoughts. As per usual Micah completely disagrees. But maybe he can talk if he'd like, I do find that position as well where you know I'll open start to send a transaction and then go do something else and then come back and it might be a completely different base fee a few minutes later. And just for clarity on my unhelpful comment there. I do, I do appreciate that MetaMask is repeatedly updating the base fee. What bugs me is the fact that the whole UI freezes and it's like, there's so many times about to click a button, and it just goes out from under me. And I have to wait a second, and then I try to click it again but another block comes really quick and I miss and it drives me nuts. You don't want the, you don't want the price to change as you're clicking the button. That'd be even worse if you like, if you agree to something and like mid click the thing like sweeps out from underneath you and next thing you're like, three ether or something. I see the difference now. So I completely ignore what the actual current base fee is 100%. I have a fixed price I'm willing to pay for a transaction that I know I know before even look at that window. And I'm just setting it. So like, for example, I know I'm willing to pay 100, 100 for this. So I said one 100 go. That's what I try to do. But, you know, I set one and then the UI locks up and then I wait for it. And I said 100 and then the UI locks up and I wait for it. And then I click go. And so I don't actually care what it's doing, which I realized now is a difference in like how we're going about using the UI, which is why we have different opinions. So this means like you, you don't really care about the bloat because you're the one like deciding like what, like this is your number and I'm a, I'm a spherical human. Okay. I'm like everybody else. And really ahead of time, I know, you know, like I care about this transaction enough that I'm willing to pay this much for it to go through. And I know that before I know what the current crisis like what current costs and sometimes I will put that through and I will have to wait because the something's happening and I wasn't paying attention. Right. And I expect that and I'm okay with it. That's just how I operate. So that would be the reason why you don't care about the current base fee being part of the UI, whereas I think most people would want to know like, Hey, I'm in this advanced setting what does this number mean relative to what the current state of the world is, I assume. And so, yeah, so it's interesting. I think a lot of users. I mean, this, this is something you see just in retail and everywhere in, in, in terms of pricing, people often want to pay something that they feel is fair or normal. More than they have like some sort of utility function where they're trying to figure out, you know, is this actually valuable to me. Like when you go out and buy a Louis Vuitton bag, you're, you know, you're not paying how much the bag is worth to you're paying how much is the bag worth to society and to everybody around you. I think humans, that is very common in humans to have that sort of behavior when it comes to pricing things. And I think they apply that here. And so like I want to know what a normal price or a good price for gases, just like I want to know what normal price for apples is, and I'm trusting society to have priced that appropriately. And you know, if that's what it costs, that's what it costs. They're not thinking, Oh, this is worth this much to me. If it's cost more than that, I'm going to go somewhere else or I'm not going to eat an apple or I'm going to buy a different bag. Yeah. So let me jump in real quick. There's this thing that Tim had put in the agenda, and I want to make sure we get to it. And then we can jump back into discussion. Greg if you want to talk next but really quick. I don't know if you wrote this before or after we narrowed it down but Tim had written something about when the max priority fee and max fee is auto filled with the same value. And I think I believe it's related to using an old version of a library I think what through JS. Harry, do you remember what they can tell you what the problem is so the pretty sure the problem is is applications are sending metamask a transaction, and they're pre populating throw to some applications populate the gas price in there, and metamask use this gas price and the metamask is saying hey you told us to have told us to use this gas price so we're going to use this gas price. And with the change to 1559 those applications you know they are not updated for 1559 so they're just still doing the old thing they're maybe using a gas oracle or something. And so metamask is doing what the application told us to do which is set a gas price, even though that behavior is probably not what's actually desired anymore. Yep, that's that's what I was getting to you. Go ahead. So at least from eaters cat side. That's actually not true. We've never suggested a gas price either before or now. So we don't know right now whether it's something that metamask is doing or the library where pjs is doing. But yeah, it, there's two parts. It's giving those two same numbers. And at least on metamask there is a UI that says the scandal I always suggesting this gas price. And yeah, we don't actually know what to do because we've never. No, for what if for what it's worth. I messaged somebody one of your team members on Twitter, like you guys are using an outdated version of metamask of what through jazz. Yes. So, so we have a fix for that already. The thing with that is that if we push that fix, then, as far as we understand the, if we do that then users who use ledger, at least until it was launched today, wouldn't be able to use the right contract feature at all, which is an even bigger problem. So we just decided to delay until that ledger support is rolled out. Okay. That's good to know. But yeah, if anybody comes across this in an application, or finds other issues similar to this just forward it to me, and I can try and maintain a list and reach out to these teams, unless you want to do it yourself but I'm more than happy to take that and just forward me the name of the application or the team that's working on it. And I can see what I can do about that. So I might have missed this at the beginning. Is that a known bug with metamask that if you, if the app doesn't supply a gas price then metamask cannot interface with the ledger. No, I think it's just what 559 support. Yeah, so I assumed that metamask would just downgrade to legacy transaction if it's connected to a ledger. Is it not doing that. My ledger works on metamask with type two support. I'm like very certain. I mean, so let's say you have a ledger that doesn't support type two will metamask do the right thing and ask for a signature type one signature. Your music or other type zero. I have no idea. I mine are updated to the latest firmware so. Okay. Yeah, sorry. Sorry, go ahead. Okay. Yeah, for my sense of this. Well, I was using like metamask data. I commit like sign type two connections for a while until I use metamask with a major and then I saw that was actually. And that's what somebody said earlier that ledger didn't support it. That is the combination of two wasn't supported so then metamask was falling back to zero projections. So I think it's, well, it's the operation is done properly, right? If the job doesn't support it then the beta zero and if it does then because that's my opinion. So I guess what I'm getting at is that either scan should be able to update the web three library and not have ledger users break. If that's happening, then something is wrong. Like there's a bug somewhere that someone should be fixing. Like either scan is correct behavior. If we need a case then we can push it like whenever it was just our understanding that if we did push it then ledger users wouldn't be able to use the features. Yeah, I don't think that's the case and the reason I say that is because like we broke yarn or we broke somebody on a band tag blew me up and like we patched it and it seemed to work for like every all of their users. So I'm pretty sure you guys should be safe to update. All right, Greg, maybe we should kind of follow up later. And there's a telegram group between you just get in with a mask, and it wasn't really responded to maybe we should have communicated better as well. But yeah, we didn't want to make the assumption and break user experience. Yeah, no sure let's go. That sounds good. I have a quick question because somebody mentioned that they, I will Michael was saying that he just sets the price he wants and lots of fly. So I haven't experienced this. Like I said I've been kind of choosing my time as well and that sort of thing, and giving good priority fees but I've seen people complaining that they're setting a base fee and they get this air that says oh maybe it's a gas pressure says transaction gas price is too low for the next block which has a base fee per gas of XXX. So is there, how does the transaction pool memory pool. Yeah, make sure like you can just set some low base fee that I want this is how much I'm willing to pay and send it as a network because if it's too low it seems like memory pool just won't adopt it right, which is kind of has to for a DDOS for mitigation. Am I just going to say that or. Well, so there's a few nuances here. If you are using your own node and your own node will always accept your transactions no matter how low they are and they'll hold on to them until they can gossip them. And so if you're connected to an own node, then this just works, which I admit I have my own node and so this works for me great I send it basically send my transaction to my node, my node just hangs on to it and we'll eventually providers like infura and alchemy I can't speak to exactly what they do, but a reasonable strategy would be that if you're a paying subscriber, they would do that behavior. And if you're a free subscriber, they would say hey to low we're not going to hang on to your stuff for you for free. I don't know what they actually do, but that probably influences the behavior you get. And that being said, there is like, as long as you're higher than the lowest person in the event pool right now, you'll get gossiped. And so you don't have to be, you shouldn't have to be above the current base fee you should just have to beat whoever the lowest in the men pool is the global men pool. Based off the bait. Do you still have to beat the current base fee. You should not like you just have to beat the you just have to be high enough that someone else gets kicked out of the men pool not you. But wouldn't that be easy. You should force just by publishing a whole lot of transactions because I mean it's pretty safe to broadcast the transaction, whose base fee is less than, let's say what let's say equal to one half the current base fee, because you can do that relatively assured you're not going to get my name soon. And that means you can kind of evict people doesn't it. So, so yes, you can evict people who lowball, but you will eventually have to pay that or more. So like, eventually, like your nonsense now sitting in the penny pool and will stay there until someone else evicts you, or until you pay something. So your your account basically is locked up and that account has to have Ethan it. And so you are locking up that ETH until such time as you spend that ETH on a base fee sometime in the future. And so it's not a free attack. You have to spend money to do this. And there's some new again, some nuance there, if you plan on doing a transaction like in three days, you say okay, I can use this account, like there's one account to consume one spot in the mem pool for three days, knowing that in three days I'm just going to bump the gas price and we'll go through, and it'll be fine so there's a little nuance there but again it's, it's a expensive enough attack that we don't have to worry about that particular vector from a DDS standpoint. Okay. I think that that attack is a little bit limited because the nodes will separate the underwater transactions underwater on base fee from those that are marketable. And so it's not like you could consume the entire mem pool with these underwater transactions. Well, that's kind of my concern right it's like somebody who's using underwater transactions not because they're trying to attack the system, but because they just, they want a cheap fee and they're willing to wait. And so I feel like there's like the two different things are kind of at odds with each other, because if I'm willing to wait three days and I put some low fee in there. I don't be evicted because someone else kind of has another one that they're like, assuming all legitimate users, I feel like a legitimate user could lose out having a lower base fee transaction. You definitely can, which is why if you're going to do this sort of low balling you should have a node that's willing to prioritize your transactions in its own local mem pool, such as your own node or again I don't know if inferior or alchemy or these providers do this but hypothetically, if you're a paid subscriber to those services, it would be reasonable for them to keep them consider your transactions local. So is there a general rule in how long of transaction concern the mem pool and what are the conditions based on which it gets kicked out. So the only rule is that each client on the network each node network sets has a mem pool size so they have like a certain number of transactions or bytes dependent on the client that they're willing to hold, and then fills up which it usually does eventually, then the lowest one gets kicked out basically so it's just a simple, the top end users get to stay everybody else gets kicked out. Again, with the caveat there that your local node so it, if your node considers the transaction to be local meaning it was sent directly via json RPC to that node, not received via gossip over the network. And I consider that a local transaction will prioritize those and never evict them. There are infrastructure providers, such as ourselves a block native that also run several nodes with extremely large mem pool basically infinitely sized mem pools in order to ensure rebroadcast of lower feed items so that a typical mem pool which might be, let's say 4k slots. And it will rebroadcast those to, when the prices come down to those lower fee ones, and I think other infrastructure providers might be doing themselves. If for example they're measuring the total size of the mem pool which is typically around 150,000 or more entries then you kind of have to, you would typically be running a few nodes with extremely large mem pools to do that. So are you guys willing to share what exactly how big your mem pools are. I'm curious, how big we allocate or what the size of it. Yeah, give a moment. I guess, we, we, are they not folks. I'm sorry. Are they not full I assume they'd always eventually fill up. They do not. We run nodes that can support up to 1 million transactions, and they are definitely not full. So there you have it so that so ignore everything I said, the global mem pool is apparently run by block native. They will hold on to transactions forever. I wouldn't quite characterize it that way but I think that you can you can you can have very large mem pools to measure how big the mem pool is and those can then sort of rebroadcast another another item there is that in for example get the you can have something that will tell how long it'll hold on to a transaction. If it does not hear a rebroadcast of it. And I think the default for that is three hours. So if you don't hear any gossip on the transaction for three hours and you're not seeing any activity on that transaction, then you might get rid of it. Good context there. Thanks. Thanks for that discussion. We're just about three minutes from the end so we just do a quick wrap up. I think this was pretty productive. Again this was recorded so we'll have this, if anybody wants to send it on to their team members. I think we'll upload it to the cat orders YouTube but there'll be a link somewhere. But if you can't find it reach out to me in a few days or later today, and it will be uploaded. Just generally I want to say thanks to everybody who's, you know, putting in effort. There are some parts of the ecosystem, which are, you know, leaning into this and really trying to make it work for the users and there are some who are sort of sitting back. And just completely not engaging and I'm really excited. The fact that people are on this call is that you're engaging with the Ethereum ecosystem as it changes as it evolves. So thank you from me personally. I think 1559 is it's going to take time but it'll, it'll be an improvement. I think it already has been an improvement. It's just going to take user education, you know, tweaking tuning things as they come up. So again thank you for all of all the work you guys have all put in. So it's really great. I think we covered all of the issues. And if anything else comes up I know last time we automatically set the next meeting. I don't know if we need to do that right now. But what would probably be most fruitful is when we have more data and I know Barnaby spent a little busy. Not that we're expecting him to do all of our data analysis but he's definitely got the chops for it so maybe when he has more time and can put together some analysis of what the best tip is some analysis on how quickly the base view moves. I think I schedule another call, unless people feel, you know, in a few weeks there's there's time for another deeper discussion I'm totally open to doing that as well but I don't want to just make the assumption that everybody wants to have this call. Every few weeks. But yeah, any closing thoughts from folks. I'm going to join the ethereum R&D discord pound fee market, if you want to discuss any of these topics async lots of people they're happy to discuss any questions. No need to wait for a meeting if you don't want. Even better. Yeah I just dropped the link in the chat here and if you don't get it before this ends just DM me somewhere and I'll send it to yeah a lot of great discussion happens async there. I mean people trying to understand the 1559 is and slowly learning what it can do and what it can't do, but it's definitely a great place to have discussions. If there are no other final comments, we can wrap there I'll wait a few seconds for anybody to speak up. And that's a wrap thank you again everybody and we will reach out if there's going to be another call. And maybe we'll see you in the discord. Appreciate it. Thank you. Thanks.