# Post London EIP-1559 Assessment Part II (Breakout #13)

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2021-10-09
- Duration: 55:55
- Topics: blockchain, smart contracts, distributed ledger, ethereum
- Watch: https://streameth.org/watch/yt-YtkU2773K6w
- YouTube: https://www.youtube.com/watch?v=YtkU2773K6w

## Description

https://github.com/ethereum/pm/issues/374

## Transcript

okay uh let me grab the agenda again for anybody in the chat who hasn't seen it yet um this is the second post london breakout call i think number 13. uh 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 uh look at each other's faces maybe so the first thing um jake if you want to kick us off that's fine or we can start with something else but uh be really cool um 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 um and i'd love to hear from them as well if they'd like to say anything but jake if you want to start um give us your general thoughts or if you have a presentation prepared yeah no presentation but have some some thoughts for sure um so i can talk about kind of the the ux of how at least how metamask has implemented 1559 how it's been received um i think like overall i think it's going well but there's a lot of uh 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 um so 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 a max fee don't try to sugarcoat it for advanced users um and i we definitely learned that people who are drifting towards advanced fields are not always people who like truly understand how 1559 works um 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 yeah so so they're they're even advanced type users i guess are not as up to date as we had hoped or assumed um but what we are learning is that that vocal group of people seems to be a very small group of people um uh so we we've been tracking some analytics and our analytics are rough because we don't track a ton of things in details and um for privacy reasons but uh one one reason stat that was interesting is um and kevin 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 edited it or that they found it confusing or that they said something bad about it or good about it um so it is a small number of users that are getting into there but we definitely need to uh 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 um advance being you know going off the rails of an estimate like not using a default value um so another thing that we've learned as well is so on the flip side only 20 or you know 80 percent of people have not clicked edit in the past seven days that could also be dangerous because we're seeing really big price bikes right like so there's kind of consistent price bikes with nft drops or whatever it may be and 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 there i think there was also an assumption that um you know let's focus less on editing um there maybe there's less value in waiting um and paying a lower price since we you know we have better estimates we can just kind of give you the estimate you'll go you go through with it the transaction will go through soon and that's great uh with these price spikes i think um 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 bike also on the flip side um 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 the gas price right so it was much easier to edit now there's a couple of fields um and you know i've sat in a couple discords with like kind of tea drops and stuff and people were talking about like what do i change my gas settings and they're discussing it and um now that we don't now that we don't have um like so our basic estimate right now are low medium high there's not a huge variation between them they're they're all kind of in the same range so we we need to be i think have much lower options and much higher options much higher options for those when there is a price spike and there might be a gas war coming um allowing people to be easier you know to access that type of setting easier um trying to think i think those were the high points of what we have learned um yeah so i'm happy to talk more about it um for more details or answering questions uh we are going so we are looking at i mean we we launched with a you know with a v1 we had improvements in mind uh so some of these learnings have shifted that we're we're going to be rolling out a new uh ui after another round of user testing so i think we'll learn more in the next couple weeks too if some of what i'm talking about is actually true or just false assumptions but that's kind of reading between the lines what i've seen awesome yeah i know 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 um 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 i may have said something like that um i think it really is the assumption that one people people will understand like if if you give people if you call something advanced and you give them the advanced controls 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 um so that i mean that was one assumption that we were wrong about um 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 um and like it just doesn't really make sense right like if you're gonna 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 risk 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 also just if i can add to that is like we did not anticipate that the crazy surges that uh are happening so often uh you know we we assumed that it would happen but we didn't assume that it would happen so often during the day it happens several times a day and i think therefore the controls were as as jake said a little bit more towards the middle as in like the variations weren't that that different uh because we're uh assuming that the users 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 um but we have to also provide the flexibility in cases where you know users want to you know be fast or be slow or you know have be be adaptable as much as possible um i just had a question so uh 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 sugarcoat them exactly so we didn't talk about them we literally had two fields there was max priority fee and uh max fee and we we have some tool tips you can you can look at them but it's like we pretty much just gave you the raw fields 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 a you know a chart of current base fee and stuff to well i shouldn't say that they're 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 the 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 um and i think which makes sense with just like the narrative around 1559 it's it's base fee and priority here right that's how people people who understand 15 59 think about because that's that's yeah the mental model that's how it makes sense so the the fields that we're looking at now if i'm remembering correctly um priority fee we're calling a priority fee even though it's technically a max priority fee we're just not saying that because the idea of a max priority was kind of confusing and i do think right now we're using max base fee um yeah okay and yeah instead of saying base fee but that's where yeah um yeah our designer was just able to send us over some designs uh this week and so yeah 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 the priority um cool cool and i think exposing the current base v2 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 too i mean of course people need a reference point right cool and um also may i ask what your so for the multiple on the base fee that you're doing on the low medium high are you um i think i s micah said that oh no no so what we're saying is um unfortunately the way that we're presenting it to our users is not like a max total so for for users who aren't like ultra in the eip1559 world um 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 um but so because technically it should be max fee right yep yeah um but the wording we are using is max basie for the user to know that this is just the base fee that they're potentially doing a max of because that makes sense i had also the same confusion when i saw the designs because i was thinking in like a total max um i mean so so the protocol does not allow you to set a max based 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 based 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 max 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 one five five nine um if they're asking where's my base fee that means they like read half an article and are now confused um but i worry about exactly what happened now what 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 as each wallet can do what they want i would prefer to optimize though for users who have never heard of base fees or party fees or transaction fees or anything they're 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 may be 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's coming here 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 b we don't talk about priority fee we're optimizing for we're optimizing for somebody who knows nothing but they're we are like what we're hearing about is this like 20 use case of like advanced users who are confused with dance settings so that that's what we're talking about and i i totally agree yeah it should be did you want to you had your hand up for a while did you want to say something uh yeah i had a question to metamask how you currently uh handled trezor basically now that the firmware is not yet released and how you plan to do it in the transition phase where basically some users have the old firmware and some have the firmware with one five five nine thank you i think i heard did you say yeah i said treasure so they currently didn't yet release the firmware so they have a firmware um with one five f9 but it's not yet released um 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 uh trezor on 1559 so it falls back to the the legacy um but we we will support treasurer shortly we currently just rolled out today uh support for ledger so uh you know all the you know supporting uh hardware wallets are high on our initiative so we're taking them uh one one hardware wallet at a time and is the ledger support going to be rolled out progressively or is it just 100 all out uh i believe it's at 10 right now but yeah it's it's progressively rolled out yeah so we're we're looking into whether or not things are breaking we're also gathering feedback from from ledger uh themselves we're in close partnership with them gotcha thanks yeah one of the things i'm tracking pretty closely is uh or as sort of a proxy for how all the user-facing interfaces are working is if you scroll to the bottom of the link i just sent um legacy versus dynamic fees we've been hovering around 60-ish percent um for the past week uh and it's actually decreased in the past few days so um if anybody has ideas or providers that they know of which haven't implemented it yet please let me know and i can reach out to them and try to get them support because hopefully we get this to 100 sooner rather than later 100 um so yeah that was lee's question about treasure um i didn't mean to interrupt whatever discussion was happening we can jump back into that about naming cool oh yeah so well i i had um another question uh 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 um the expose like histogram or or you know what whatever the last few whatever priority fees are but uh 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 i don't have a sorry go ahead juventus oh yeah because because uh you know we've seen a few different places where you know the the the base v is like consistently 2xed and we from like the data it doesn't seem like that's necessary and so um we're trying to figure out how to be smarter about it so that we're not like over bloating the price to our users yeah totally sorry for the consumption i think we want to say when we say base fee here we want to say max max fee per gas right maxine where you 2x the the the the max priority fee per gas right so when you meet bet when you mean base fee you mean uh max maxi do you so i feel like maybe i'm forgetting something but uh my understanding was like like 2x base v plus uh 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 c plus the part like so ignoring the priority ignoring um yeah so ignoring the party just keeping like what is the multiple two x plus you know that that's what i that's what i'm referring to yeah there was some initial discussion a few weeks ago about uh it could possibly be defaulted to 1.2 or 1.3 two might be a little high um right but there's no i don't think any hard research yet uh that's probably on part of a spec burner for now um but definitely something to 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 uh 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 so if you set that too low you will have a larger percentage of users who will end up with a bad experience if things do not go well for them um 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 two percent to be sad or do you want you know 99 to be a little less happy and one percent 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 ending for three hours yeah i guess i guess i see having a bigger number for the fee is also a sad category for us as in that's like uh it's it's right yeah and like the happiest user is sadder yeah i guess like if you could if you could keep the bands right the multiple of this pretty tight and then just uh manipulate the priority feed kind of competing in the priority fee in that sense then you kind of opt like you're you're maximizing kind of their you're minimizing that 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 uh hard-coded number for this or i i 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 you hit the nail on the head with like everybody talking about this it's like this is like the hardest part because so i i'm not the best person to speak about the exact 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. um 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 [Music] try to make 98 of your users happy or wherever which is pretty much what our middle case does you're totally not supporting the use case of somebody who wants to save money in a spike right because you're responding to the market so quickly that that medium price is relatively high to the past two hours six hours or whatever um 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 that transactions don't get stuck we have to have people opt-in to a potentially dangerous situation where they have to wait um and i i'm sorry i don't have the exact number so i can't answer the question but i it was around like 1.5 when we first launched and then it's adjusted from there and did you um and so is there a big difference though between low medium high on the multiple aspect of it so i think yeah sorry because like um you know technically the the longer you wait the the higher it can go but then you if 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 because you don't want them to overpay and then for the like if they're really urgent you also want to keep the you know there's like these people who want this transaction in now or or never and in which case you want to keep the multiple also pretty tight and just bump up the priority fee quite a bit so that 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 uh i don't see how the multiple should change for like a low medium high per se versus like just the priority 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 based fee should be much much lower than the current base fee 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 over rest made 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 priority fee really high up so that it gets accepted immediately and if it doesn't go through well then you just gotta 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 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 the like high has a couple ways you could play it like moderate base fee high tip or high tip high max basically oh i have a kind of like a follow up question uh is is there anyone actually detecting trends uh you know if that there is an uh a trend like the the base fee is trending up and you know that will mean that you will have to like uh potentially uh choose a a higher multiplier uh or you know a lower if the trend is going down is there any wallet doing that so i'm not a wallet dev but what i've noticed um this is anecdotal that barnaby may have better data i've noticed is there tends to be relatively few trends outside of day to day seasonality um with the exception of when there's one of these nft sales in which case there's no way your user is going to get in like the only users that get in over those like 5 to thirty minutes that empty 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 user is going to be able to beat that then i think the trends are just generally general seasonality you know like at what whatever time it is so that's sorry uh at like 8 a.m 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 if you look at a big graph over many over the whole week you'll see the up and down daily um but 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 these spikes that are happening uh is it is it regular is it consistent and there's no consistency to this at all so it's it's very hard to to create uh any type of predictive algorithms based on that i have good question have you actually seen um 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 um transactions we did not see any transactions at just the base fee everything has to have some kind of priority mostly 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 um whether it's too high i know one of the issues on the agenda we can get to that after but it's um uh either a presentation issue or the i think it's the web 3.js is if you're using an older version pre-1559 it's suggesting the wrong uh the tip the wrong priority fee um but i don't think that there are a ton of transactions going in if any that uh have zero tip um i personally have said the lowest i sent i think was i think uh point zero one quay it took maybe 15 minutes so much much longer than typical but that's the lowest i've sent and um i don't think that's going to be standard for every other user uh i think what people are normally recommending is one to two gray were you asking are there any uis that do not prompt the user for a well priority 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 um the reason i'm asking because we're working on the eye right now and their version that we came up with is we actually did not present the base fee at all um we have the three priority versions like normal high and highest i believe and all of them include the tip in them um so i'm just wondering if this is a um good assumption to make just because in general yeah yeah the the network the gossip network shouldn't actually um propagate any transactions that have zero priority if they if they are that's a bug or a very very altruistic person um on the network somewhere as far as miners there was some miners initially that had some mis configured deployments of their nodes around london and they were mining transactions with zero priority fee i believe they are now all fixed and so a your transaction will not propagate if it's got too low of a priority phase yeah or shouldn't and b even if it did no one will mine it um if you're running like your own local miner then you could mine one with zero party fee and minor payouts may do this um 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 just kind of get lost in the ether uh sorry ethers they're lost in the space between things all right thank you uh yeah the other go ahead on the on the multiplier thing too i do think maybe somebody has a different opinion on this i'd love to hear it if they do but 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 if if we have a strong 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 oh have the user over pay even though i mean point one guy and one guy is probably not a huge difference um 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 medium 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 ui suggests 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 fft or whatever like something where i 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 all basically always go in within one block i actually just had 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 mined i also make transactions at times for the gas prices low so i've i've i'm also like low i don't have the right word 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 consec multiple consecutive blocks that are i guess there's two situations one if miners are setting the minimum priority fee they'll mine higher than one we've been advising miners to set it to one because that is above their opportunity cost and so you know a spherical miner will set it to one because that's the rational we don't actually know for sure if the miners are actually doing that and i don't know if anyone has good data on that but that'd be great to see if possible so if they're studying at 2 1 or whatever then in theory the only time you should not be including the block is if the block was 100 full and while we do frequently see you understand full blocks we very rarely see more than like two blocks in a row that 100 full sometimes you'll get like three um but even that's pretty rare again ignoring those nft drops which are just like this oddity that you cannot account for um so you shouldn't see a difference between 2.5 and eight like you shouldn't really see much of a difference between 1 and 2.5 even yeah so it seems to me like the more important thing to actually set is that multiplier rather like that the priority should almost just kind of always be hardcoded whatever value you want to use for uh uh uncle risk plus uh mev risk whatever so is priority even the important thing to modify like if you're talking like high high medium low like it almost depends what you really care about like i feel like the sorry it's kind of loud here um sorry i'm just like i'm half asleep as well but yeah i feel like the multiplier is the more important thing to set in this case is oh actually i want to bring up another quick thing um i really like what metamask is doing with the kind of every couple seconds stall the universe take away the button for me so i can't click on it and like fetch the new uh 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 uh 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 um anyways i'm kind of all over the map but i feel like what that multiplier is more important than the priority fee and that's my my my thoughts as per usual micah completely disagrees um but maybe he can talk if he'd like i i do find myself in that position as well where you know i'll open i'll 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 uh unhelpful comment there um i do i do appreciate that metamask is repeatedly updating the the base fee um 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 so you don't want the you know 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 ethernet or something i see i see the difference now so i completely ignore um what the actual current base fee is 100 i have a fixed price i'm only going to pay for a transaction and i know i know before i 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 set one 100 go like 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 then i set 100 and then the ui locks up and i wait for it and then i click go um and so i don't actually care what it's doing which i realize now is a difference in like how we're going about about using the ui which is why we have different opinions so so this means like you you don't really care about the bloat because you're the one like deciding like what like this number and i i i'm a spherical human okay unlike everybody else like i i literally 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 price is like what the current cost and sometimes i will put that through and i will have to wait because the something's happening and i wasn't paying attention um right and like i expected 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 uh 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 yes that's interesting i think a lot of users um i mean this is something you see just in in retail and everywhere 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 you're paying how much is the bag worth to society and to everybody around you and i think humans that's very common in humans to have that sort of behavior when it comes to pricing things um and i think they apply that here and so like i want to know what a normal price or a good price for gas is just like i want to know what a 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 costs 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 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 uh greg if you want to talk next but really quick uh i don't know if you wrote this before or after we narrowed it down but tim had written something about when um 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 web3.js um harif do you remember what that i can tell you what the i can tell you the problem is so the i i'm pretty sure the problem is is um applications are sending metamask a a transaction and they're pre-populating for what if some applications populate the gas price in there and so they're telling metamask use this gas price and then metamask is saying hey you told us to app told us to use this gas price so we're going to use this gas price um and with the change to 1559 those applications you know they are not updated for one five five nine 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 at gas price even though that behavior is probably not what's actually desired anymore yes um yep that's that's what i was getting to you go ahead so at least from eating side uh that's actually not true uh we've never suggested a guest price uh either before or now uh so we don't know right now whether it's something that metamask is doing or the library uh what pjs is doing uh but yeah it it there's two parts yeah uh it it's giving those uh two same numbers and um at least on metamask there is a ui that says it is suggesting this gas price and yeah we don't actually know what to do because we've never no for what for what it's worth um i message somebody one of your team members on twitter like you guys are using an outdated version of metamax of web3.js like that's 100 that's causing issues there so so um we have a fix for that already uh the thing with that is that if we push that fix then uh as far as we understand the um if we do that then users who use uh ledger at least until uh it was launched today uh wouldn't be able to use uh the right contract feature at all which is an even bigger problem so we just decided to delay until uh that ledger support is uh rolled up okay that's good to know uh 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 on so 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 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 ledger no i think it's just one five five nine support yeah so i i assumed that metamask would just um downgrade to legacy transaction if it's connected to a ledger is it not doing that my ledger works on metamask with type 2 support i'm like very certain all right so let's say you have a ledger that doesn't support type 2 will metamask do the right thing and ask for a signature a type 1 signature i have no idea i i i mine are updated to the latest firmware so okay so yeah for my experience at least uh well i was using like metamask i totally updated it and i could not like sign type 2 transactions for a while until i used metamask with a pager and then i saw that it was actually worked out so i think that's what somebody's saying earlier that ledger didn't support it at least the the combination of two wasn't supported so then metamask was following back to that zero transactions so i think it's well it's definition is done properly right if the job doesn't support it then you'll be taught zero and if it does then it goes to that's i guess what i'm getting at is that etherscan should be able to update the web3 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 ether skin correct behavior okay if this is definitely the case then uh we we can push it like whenever uh it was just our understanding that if we did push it then the users wouldn't be able to uh to use the features at all yeah i i don't think that's the case and the reason i say that is because like we broke yearn or we broke somebody kinda fan 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 uh greg maybe we should uh kind of follow up later and there's a telegram group um between itasca and metamask and it wasn't really responded to maybe we should have uh communicated better as well but yeah we didn't want to make the assumption and break user experience yeah yeah no sure let's go async that sounds good uh so i actually had a quick question because somebody mentioned that they uh well michael was saying he just sets the price he wants and lets it fly um and so i have not experienced this like i said i've been kind of choosing my times 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 error that says um transaction oh maybe it's a gas price 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't just set some low base fee that i want this is how much i'm willing to pay and send it to the network because if it's too low it seems like the memory pool just won't adopt it right which it kind of has to do for a ddos mitigation um well so there's a few nuances here um if you are using your own node 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 will eventually gossip it 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 pain subscriber they would do that behavior and if you're a free subscriber they would say hey too low we're not going to hang onto your stuff for you for free again 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 mempool right now you'll get gossip and so you don't have to be um you shouldn't have to be above the current base fee you should just have to beat whoever the lowest in the mempool is the global based off the bait do you stop the beat the current base fee you should not like you just have to beat the you just have to be high enough that um someone else gets kicked out of the men pool not you but wouldn't that be easy you should the force just by publishing a whole lot of transactions because i mean it's pretty safe to broadcast a 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 mine anytime 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 it's like eventually like your nonce is now sitting in the pending 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 ethernet and so you are locking up that eth um until such time as you spend that eth on a base fee sometime in the future and so it's not a free attack like you do have to spend money to do this and there's some 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 mempool for three days knowing that in three days i'm just gonna bump the gas price and it will 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 ddos standpoint okay i would add that that attack is a little bit limited because um the 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 mempool 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 they're 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 feed transaction yeah 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 mempool such as your own node or again i don't know if inferior or alchemy and 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 is there is there a general rule in how long a transaction can sit in the rent pool and what are the conditions based on which it gets kicked out uh so the the only rule is that each client on the network each node in the network sets has a mempool size so they have like a certain number of transactions or bytes depending on the client that they're willing to hold and then um if that 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 consider that a local transaction it will prioritize those and never evict them i would like to there are infrastructure providers such as ourselves a block native that also run uh several nodes with extremely large memple basically infinitely sized mempools in order to ensure re-broadcast of lower feed items so that a typical mempool which might be let's say 4k slots um you know it it it will rebroadcast those two 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 mempool 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 members to do that is it are you guys willing to share what exactly how big your mentals are i'm curious how big we allocate or what the size of it is at any given moment um i guess uh we we know these are they i'm sorry are they not full i assume they'd always eventually fill up they do not okay we run nodes that can support up to one million transactions and they are definitely not full okay all right so there you have it so that so ignore everything i said uh the global mempool um is apparently run by block native and they'll hold on to transactions forever i i wouldn't quite characterize it that way but i i think that you can you can you can have very large mempools to measure how big the mempool is and uh those can then sort of rebroadcast um another another item there is that in for example guest the um you can there's a setting that will tell how long it'll hold on to a transaction if it does not hear a rebroadcast of it um 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 um we just do a quick wrap-up um i think this was pretty productive uh 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 herders youtube but uh there'll be a link somewhere uh but if you can't find it reach out to me in a few days or later today and it'll be uploaded um just generally i want to say thanks to everybody who's you know putting in effort um 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 uh and just completely not engaging and i'm really excited the fact that people are on this call is that you're engaging with um the ethereum ecosystem as it changes as it evolves uh so thank you from me personally um i think 1559 is it's gonna take time but uh it'll it'll be an improvement uh i think it already has been an improvement um it's just gonna take user education you know tweaking tuning uh 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 um i think we covered all of the issues and if anything else comes up i know last time we automatically set uh the next meeting i don't know if we need to do that right now um i think what would probably be most fruitful is when we have more data and i know barnaby's been a little busy not that we're expecting him to do all of our data analysis but he's definitely got the 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 uh we might 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 uh any closing thoughts from folks please join the ethereum r d discord pound fee market if you want to discuss any of these topics async um lots of people there 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 the chat here and if you don't get it uh before this ends just dm me somewhere and i'll send it to you yeah a lot of great discussion happens async there uh and by discussion i mean people trying to understand what 1559 is and slowly learning what it can do and what it can't do but um it's definitely a great place to have discussions um 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 uh 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 thanks