EIP-1559 Implementers' Call #6 [1/2]

we are recording um so hey everybody welcome to 1559 implementers meeting number six i just shared the agenda in the chat uh a couple people joined incense so let me reshare it just in case um so first thing on the agenda was just uh client updates on on the testnet uh maybe we can start with nethermine i know uh thomas you just posted an update on the discord yeah sure so we're fully synced with validating blocks uh so abdul hamid mentioned that there is some some problem with filling the blocks i believe at the moment uh the the issue with synchronization that we've seen last week so when i looked at it was a very small thing so i i love the code that was comparing the available block space for both the old style transactions and the new transactions and since we merged them together in the transaction pool and in the blocks it was no longer important so when the old style transactions appeared we treated them as beyond the space in the block for them and we rejected the block but after removing that code that checks it's all fine cool um yeah abdel do you want to give an update on the basic side uh yeah so nothing really new on the core ethereum client except some new fields added to some rpc endpoint lags like the get block by number and get blocked by hash and points to basically return the base fee so corresponding to the three eip i wrote about adding the e-1559 fields to the existing rpc endpoint for example for endpoints that return return block field and yeah we are working on the tooling but we have a specific item on the agenda about that so i will talk about that later cool and uh rick or ramil do you want to get an update from the get side yeah i can provide updates so we completed updating and death code to be aligned with latest version of eip and also we tested synchronization guest to get and get to this su and it works well and uh now we are working on testing guests to never mind got it um and when you say test you ran your local network or have you been thinking on the network that uh that we've been using with leathermine uh no it's a local network okay got it um yeah i would suggest to skip that step and test directly on the test net because we are in synchronized network so if you that works with bezos that should also work with netami but uh it's up to you just saying yeah uh yeah i have questions about test network uh how can i uh join to that uh can i get uh okay so we can talk about that later because i have a point about that during the demo yeah yeah one important thing is that most likely we'll have a person joining on the research process development side part-time specifically uh involved with eip1559 only for another mind and that's what's back is happening next week that's that's really good news um cool so yeah i guess this is kind of from the client side um maybe it makes sense uh i know barnaby you had a new notebook as well that you released uh this week or last week i forget uh do you want to give a quick update on on that before we dig more into the testnet stuff uh sure whatever you prefer i can do it after the testnet as well but i guess i'm just concerned we end up getting bogged down in the test nets and we don't have time uh so yeah um yeah is it wait so first so i released this new notebook which looks at the combination between 1559 and the escalator so this idea that you can have 1559 to have like a nice default market price for the transaction and meanwhile users can use this kind of incremental bid strategy to to increase their beats over time let me just post the link here right um should i share my screen sure yeah go ahead okay i'll do that right so in one of my previous notebook i kind of show that whenever demand is shifting quite fast and increasing users have incentive to become strategic and to kind of try and over beat each other which is what we see currently in this first price auction mechanism that we we currently live in and so this idea of the escalator was coming to say well many people are doing this resubmission pattern on the wallet so you send the transaction and you resend it you bump your your gas price a little bit to hope that now you are more competitive and the idea of the escalator is to take that pattern and put it in the protocol and allow you to decide on how low your bid is starting from and how high you are willing your beat to go and over time your bid is just increasing between these two these two bounds and it's kind of a neat idea but the main let's say problem was that it has a lot of parameters like you have to decide your start bid you have to decide how high you're willing to go you have to decide how fast you want to go as well uh and the nice thing about 1559 is that we actually get kind of this default price which is you're being quoted this uh entry price to the transaction gas market so so the idea of combining the two is to at least remove at one parameter which is how high you should start your bid like you should start it that what the base fee is currently and then in this notebook i was trying to investigate let's say different strategies so i look at two strategies first maybe i'll show like okay this picture kind of shows you in blue here you have a base fee which is moving around so here you assume that it's increasing maybe because the demand is increasing and you have two players like alice and bob and alice is kind of in a more of a hurry than bob is so she would set the herbid to ram faster than bob does so what happens with this mechanism is you kind of track the base fee so your bid looks like is varying the way the base fee is but over time you you keep adding a bit more to your bid and you keep saying hey miner my bid is getting higher and higher so now maybe you want to include and so that's that's that may be helpful uh in these cases where the demand is is increasing and users would rather try and compete against each other uh rather than take the the base fee as a as a market price so really like the escalator is it's it's more expressive than plain vanilla 1559 is but the question is do we care about this expressiveness at all like what do we gain from having this more expressive building language and so what i try to introduce in the notebook is this idea of efficiency which is how we look at let's say the performance of a mechanism in uh in game theory so we really care that users which have very high value for their transactions going first or at least or going as fast as possible and so i'm looking at these two different strategies so this one is a strategy where i have let's say very high costs i i don't want to wait i'm trying to arbitrage this transaction and so i want to get in as fast as possible so i look at how much costs i have to for weighting and i set my escalator to ramp about as fast as my cost is so the more it pays me to wait the faster i'll get my escalator to to increase and maybe i'll let you like read through it i'm also planning to release videos and i haven't gotten around to it but i think it'd be it'd be nice to have a bit of an audio description as well uh all right no i don't want to get into this but the second strategy sort of encodes a different behavior which is sometimes i don't really care that my transaction goes in as fast as possible i just want it to go in at some point so i'll just tell myself okay i'm willing to wait for 10 blocks and i'll keep increasing my bid escalate my bid over time until these 10 blocks are done and hopefully i get in by by the time with by the time of this 10 blocks so the interesting thing is that when the users in your transaction market use these different strategies you really see like different let's say behavior of the market as a whole so even visually not going to go into the details but visually you see that it's kind of very different i picture users as dots and the color of the dots is the wave of users that are progressively coming in uh and i think it's it kind of gives some intuition it's definitely like an introductory work because there's a lot more work to do on let's say figuring out these strategies uh in game theory we like to know that okay is this an equilibrium or not like what should i do as a user what is my best strategy so yeah this is kind of still on the roadmap to figure out something i actually hope to do with a team here in singapore uh so yeah maybe more detail on this uh at a later point but re read through it and let me know if you have like any questions or thoughts or if it's helpful at all thanks does anyone on the call have any thoughts questions okay um in that case maybe i don't make sense for you to take also a couple minutes to walk through some of the tooling you've been working on yep sure uh so to give a bit of background so we can see that this eip introduces a lot of working changes in terms of ux and all of those stuff with the new block header field and the new transaction fields so that impacts wallet providers block explorers so almost all the the chain so we decided to implement some tooling around 1559 to make it easier for users to to interact with the test net also for client implementers that will join uh after uh that will be easier for them to to do to in to do their implementation then to validate it so yeah i will show you some of the tooling uh let me share my screen okay so first we have the standalone components that have the rest api so we have open api documentation so this is pretty standard documentation so we have some rpc not rpc so we have some rest apis to to basically submit transaction using legacy style or the new format style and yeah another thing is likely we will have to change the format of the transaction again when we will use the type transaction envelope so if we all already have this tooling we will change only one tool and that will be profitable for everyone so yeah some api to play with transactions and some api to basically retrieve the basi because this is not yet integrated in the current rpc endpoint so you can try directly using this interface uh yeah i have to choose the right endpoint and yeah you can get the base fee so if you don't specify the block number it retrieves the list the basis of the latest block and you can get the base fee for at a given block here it is and uh yeah so this is a standalone http service and on top of that we also built a web interface to make event easier for users to play with it so yeah obviously there is an issue there because you have to specify the private key because metamask and all other wallet providers don't have the new format transaction so i'm planning to add the whitelist mechanism to accept only uh private keys from the changes and this is already what i do in the web interface for example you can choose among a list of accounts that is loaded directly from the genesis so the ui provides some links to the specification work updates also we have a block explorer for the test net and the network status so we can see the three bezel nodes and the neta minot so if anyone uh if anyone needs uh the credentials for the head stat let us know in the discord channel and we are we started also to write a wiki guide basically to join the test net so this is why i'm gathering information from letterman and get as well about the branches to use i will need also the genesis file and the configuration file and the scripts to to launch the different clients so if you need the genesis you can click there and you will have the bezel genesis that will be great if you could provide me the time genesis and get genesis as well same for the cli option or config file will be even better and yeah basically let's do a quick demo so you can specify all the transaction fields so i'm in legacy mode so i have only the all the existing fields i can set autonomous so it will retrieve the the nodes using the add transaction con endpoint i can choose the recipient the value uh the unit gas limit and gas price so this will be a legacy transaction that will be automatically converted to an e15 gt9 transaction so you have the link to the explorer so the transaction has not been mined here it is so you can see the information of the transaction so we have not updated yet uh the explorer to integrate e1529 fields so this is why you can see the gas price set to zero and yeah if i switch to 1559 i can i can see two new fields and the gas price is not available anymore so the miner bribe and the fake app so the minor pipe will be added on top of the base fee i have a helper button estimate that basically take it sets the the minor bribe to one way the value is configurable for the settings and it also adds a margin on top of that and also it retrieves the latest batch fee and there is an addition with all those three things to have a working fix up so obviously you can play with different settings but this is just to have a uh yeah an easy to to do settings and basically you can submit the transaction it's the same way okay it has been mined and yeah that's it and about the tooling we also have a tool that basically stress test the network and uh try to fill blocks so let me show you one block for example that have been created 20 minutes ago there is nearly 2 000 transaction with indeed in that block for uh gas gas used near 40 million so we almost reached the maximum block elasticity so yeah and this tool is a command line tool so all those tools are open source and yeah i will provide the links of the repositories in the discord channel and yeah that's pretty much it thank you for the demo any other thoughts comments on on it okay oh sorry i say it's really cool great job thanks sweet so i guess uh the next kind of big thing to figure out is what are the next step for the test nets um so it seems like we have uh you know basu and nethermine kind of 95 percent there yes and and and basically it seems like it's pretty much there and we still need to see what get and undermined um how much more time do you people think we need to spend on the poa network um and then is it worth starting to look at proof of work in parallel um what do people feel is like the best next step here it'd be nice to agree on if we're going to do 2018 or not so we can get that in mind okay yeah maybe we can start there my i guess opinion on 2718 is i would implement it once it's actually kind of scheduled for a hard fork block on mainnet i'm just scared that like i don't know it gets pulled out at the last minute or kind of changed or whatnot um so even if it even if it's not scheduled with 29.30 then it will be scheduled with 15 59 i believe like i think the the plan is 27 18 will go out with the next new transaction type whatever that is if that's not 2930 in berlin then 1559 is a good candidate for the next i don't believe anyone really wants to release a new transaction type without it it's the impression i've gotten at least i guess my yeah my only concern is it feels like it's not really a blocker to add 2718 support right like we know we can do it and it's pretty straightforward and you know we there's no kind of huge rush to do it as well because um you know yes it's not a long poll certainly it's just one of those things that needs to be done sometime before 1559 launches yeah and if we are waiting for someone to implement uh like if we'd wait to do 15 or 27 18 until later then it means open ethereum and geth have to implement something and then change it whereas maybe it will encourage them to implement if they're money in a more complete spec one of the problems that i know we're having is trying to get other people to implement uh just i think like that yeah maybe that's contributing to their heads yeah i think open ethereum my hunch is they probably won't implement anything until it's actually scheduled for mainnet uh turboget said that they don't really have an issue with implementing 1559 but they're just not in a rush to do so um so i i personally would be a bit biased towards trying to test proof of work before just to make sure that there's no actual issues there but yeah i'm curious i don't know uh thomas and and rick do you have any strong opinions on that my opinion's not very strong but um my preference would be to implement uh 18 is that what it is 2017. yeah to implement it sooner rather than later um okay i just don't see any uh i mean the work has to get done either way and i think i'm not entirely clear what is where the total road map is frankly so once we so i do believe the plan is to move to the single transaction type and and um and once we've done that there's no two pools anymore there's just one transaction type once that's done is there anything else that needs to really be done i mean besides the enormous amount of testing yeah no i think i think 27 18 is the last kind of major spec change like um and after that yeah i think it's testing both proof of work and um just like dealing with a large state which is something we're starting to do on the basis side um but i yeah i think in terms of like big changes to the the actual eep itself 27 18 would be the last one i'm sorry when you said large state you mean just the fact that the blocks are bigger so there's more state no so one thing uh we're trying to work on at basu is to see the performance impact of 1559 on a network that has kind of a state comparable with mainnet so we're going to start building you know just local test nets first to have you know ten thousand accounts then a hundred thousand a million and whatnot and see if there's any like major performance impacts of 1559 on those uh but that is something we can do in parallel and i'll probably take a couple weeks at least to get uh going okay yeah i took two questions from you one uh rick was suggesting uh two pulls and we already have one pool only on eip1559 and like there is no need for uh for introducing two pools because the two transaction types they very nicely um yeah yeah and that it's we're already at one pool right that was the last major change i was aware of but it's already been done sorry then i misunderstood you the team they you say to to check the state size how would tip 1559 even affect the state is there like it doesn't really change the behavior of the existing system so there is it feels like okay i understand that there are blocks go i just wanted to say this is because people are already worried about the actual state and the pace it goes up and effectively won't uh because of the block elasticity some people are worried about the negative impact it can have yeah but how can you how can you just i mean what's there to compare like between the ip1559 and the existing state that's just the state will be growing potentially like i think 10 percent faster but it's only temporary i believe the fear is there's some there's some super supra linear um issue with gas per block and a single block that is twice as big when interacting with a large state network like mainnet could have super linear costs that are not that's exactly that's exactly it so i think if we can at least run this you know have a test net which has a 100 million accounts and a smart contract with 100 million storage slots we can run it both on 1559 and not and just see you know as anything kind of much worse under the 1559 case where the blocks are twice as big um it really really the test could be done without 1559 just having a 40 40 million gas block against a large state network i'd like you to simply fork off main net set the block gas limit to 40 million and then fill a bunch of blocks and see if anything crashes i think that's what it's desiring so team instead maybe instead of uh faking this network big network let's let's just work mainnet and that will be better test and faster achievement of just not just work maintenance for a private testing we've uh we can use any accounts that we want to create disable signature checking yeah go ahead abdo uh it will be harder to have accounts with the large value of it if not really though you can add that in the hard fork right okay yeah okay okay okay yeah yeah okay that makes sense i mean you can just disable signature tracking and then you could use any account you wanted as part of the fork that way you could test with any account that has any arbitrary real world situation going on there is nothing like signature checking it's just the extraction of the address so this is a bit harder you just have the signature like the you just have the r value is just treated as an address so you just say whatever the r value is use that address like just as part of the fork if one wanted but then but then the format of transaction is different so it seems like a bit more work yeah than just adding your list of accounts like adding a list of whales basically as part of the hard fork yeah this seems super simple that's what i say they seem simple and the other one is it's requiring new transaction format which and i guess i assume we can also change that in a hard fork but you could change the hash rate as well right like just lower the hash rate back down to basically zero yeah you want to set the difficulty to zero so that way you can mine on your three difficult laptops i'm just as a slight side note uh in general i think that this being able to fork mainnet and test would be very use useful for many people in many situations um so if you guys do do this um add this feature into your clients um it'd be awesome if you kind of formalize it at least a little bit just so like someone can use like a config file that does this in the future i know i've wanted it many times in the past during testing you can share the mind uh chain spec for such a chain and then you can sync to it so if we if we launch a public testnet on it then people will be able to start testing it that would be great actually because so practically everyone who has the uh mainnet maintenance can just use a different chain id for signing transaction and start experimenting on it yeah you're saying there's existing tools like that rick yeah like uh hard hat apparently claims to do that um i haven't tested it oh nice uh it used to be called builder but now it's called hard hat um apparently it will fork from mainnet if you can share a link to that rick in the in the discord that would be great yeah yeah give me answer thanks um yeah so does i guess just from a test net perspective does it make sense then to go from this proof of authority test that we have now to that like fork of mainnet do we want like a smaller proof of work test net in between or should we go just a 14 magnet let's go to mainnet anyone feel like we shouldn't do that test and prod basically no no that may not mainly yeah so i guess if we get if we get a thousand bugs uh forking magnet maybe we can try something easier um i think will be very useful for the future as well just like networking for testing different eips and like imagine for every single ap will be able to create a separate fork and people be able to use their accounts that they are used to to check if their contracts work fine yeah i think that's it that's a good idea um so then okay so i think it's still worth kind of just ironing out the details on the proof of authority testnet to make sure we're actually all kind of compatible with each other um should we implement 2718 before we fork maintenance so like when we do the fork of mainnet should that be a new version of the 1559 spec i would prefer not to okay so just go to mainnet asap yeah same okay and then once we've once we've forked mainnet and we see that it you know generally works um then then we can add the change for 2018 right yeah we're going to have it for 29.30 pretty soon so i think there won't be a big time difference but just wouldn't like to say that we have to have 2718 to just do the fork of this uh test okay yeah and abdel would your let me know sorry go ahead micah just let me know once you guys are ready to do 2018 and i'll update eip1559 with it i've been waiting until you guys are ready i didn't want to have the ap once again out of sync with what's actually live since i had problems before okay so yeah let's do that let's try and like you know a finish like the proof of work proof of authority work we have right now uh in parallel i think us you know at the basic team we can start looking at like just the hard fork for magnet and what what that would look like um and share that information and so hopefully by the time that's done we have everyone kind of agreeing on the spec on poa and then we can we can do the fork on uh with multiple clients on on the the main net um and then after that assuming everything goes smoothly we can add the spec for 2718 as part of it and and we'll already have this mainnet size test net does that generally make sense yes um cool anything else on test nets or just next steps in terms of testing if not uh just last thing i think i wanted to go over is just uh this main net readiness checklist to make sure it's still roughly up to date uh based on this conversation i'll have to change it um but uh just also useful for people tuning in it's kind of where we keep track of things that needs to be done uh so the client teams have been changed i guess if they're mine you did hire somebody so we can remove this yeah i cannot yet confirming hundred percent but mostly yes okay yes okay so i'll leave it up for now and uh paid me when you wanted to move um in terms of issues dos risks i mean this is kind of separate from from this eip itself uh so i you know i don't think we can do much except kind of 14 magnet like we just talked about and that will maybe give some interesting data transaction encoding decoding uh we'll wait for 2018 but do that afterwards uh replace by fee i think is the other thing we haven't like fully sorted out um and and it's kind of related to transaction pool sorting but like how do we actually sort transactions uh and replace them in a transaction pool without creating denial of service risks um i know barnaby you sorry go ahead uh yeah uh i i think we kind of assumed that we would have to prioritize a new format transaction because we have removed the migration period so if we don't do that there will be no incentive to use the new format right so so the incentive to use the new format is you get a refund on your fee cap oh yeah that's true yeah um we should probably prioritize the transactions so you're saying 1559 style transactions do what in the transaction board or in the block they get priorities they just they just both they just get prior either well you don't have to if you don't i mean if they're prioritized in the block that's pretty much the same thing as saying they're prioritized in the pool yeah i guess it's a more uh it's a stricter prioritizing right yeah so well well i agree that out like altruistically prioritizing would be good um it's in a minor's interest to choose the ones going to pay them the most regardless of what we suggest they prioritize and therefore clients who want minors to use their clients will write code that miners like which means paste them more i mean i don't think we can really enforce that i i work with minors i i don't really i don't know that i necessarily buy that narrative miners you know we think they'll use whatever we write yes we all if those of us in this room agree to just write the same thing then they'll use that same thing yeah and i don't really see the downside if if miners do choose to rewrite i'm not sure i mean i think i guess my thinking is the social consensus should be that we're all moving towards 1559 style transactions i mean that's we're kind of on this call trying to you know through this bizarre process figure out what the social consensus is so i think we should be pretty assertive and actually but you know we should assert that these new transaction types are the preferred type and we should do that by telling the clients to sort them you know insert them first right and if someone wants to invite their client they can do that so there's not only miners but also the users who may not have access to the tools for some of the operations they'll be executing so not all of the users will be able to switch quickly and it doesn't feel like there is a such a requirement to prioritize the new transactions very rapidly so they will all work very nicely side by side the pool works nicely side by side we plan to prioritize based on the fee paid to miners as resulting from the discrepancy between the gas price gas fee max cap and so on i think it would be risky to create two different markets without because we removed the transition but also if we started doing some kind of prioritizations it would create two markets it would be competing not on the same basis and we don't have any analysis of the behavior of such market and some users could be just removed from that market uh just because they cannot use some tooling so how do you expect people to stop using the traditional transactions more and more tools will be using them and they'll be like if they if the 1559 is solid enough and if it sales for users they predict the predictability of the gas prices as we all uh prove that it does via simulations then users will be moving towards those better tools but in that case maybe wallet providers won't do the implementation if they can do they will because they compete on the market to be the best tool available on the market for the users so they want to have their users be able to use eip1559 i i so um i i mean let's no i don't know that competition in the i guess philosophically philosophically uh that seems inconsistent to me so either we are deciding what the new transaction type is or we're going to allow people to choose um i you i don't think we can split the difference i feel like the way we've been moving is though to allow people to choose right because by removing the transition period we're basically saying you know yeah so go ahead yeah that didn't mean europe so i thought i heard a break no no no no go yeah go ahead yeah fine so just to be clear this will this prioritization will only come up in full blocks right so if our estimates are correct like five percent of the time will actually have prioritization matter am i correct in that i don't think so i i guess the time it will come up is like right after the hard fork right like they'll be but this is not like a huge deal um i made for like 10 for like 15 minutes yes what because we are expecting like what while we were but then after that i believe the expectation is is we should not see um really prioritization have any effect and except for in overfill blocks meaning more than 2x demand increase so um so i think whichever route we choose probably doesn't matter too much because of that yeah so my assumption is that no one is going to change with i mean the incentive as i understand it now is that they get or there's a discount on the 1559 transactions how big is that discount uh so the i think the reason wallets will change i actually have a blog post that i'm gonna post probably tomorrow about this but i think the reason wallets will change is because it solves a major support headache for them um coinbase wallet is the kind of canonical example because they do not allow the user to set the gas price they set it for them because they have determined that setting gas gas prices is too complicated for their users and so the problem is is that this works great except for when there's increasing congestion at which point coinbase users all simultaneously suffer because all of them end up stuck in spending transactions and those pending transactions compound these files because the users don't know how to deal with it and so they just send more transactions thinking oh that one didn't work let me just refresh the page and try again and then they end up with like 15 transactions stuck and then they need to get specialized support to help them get out of that the coinbase follower doesn't actually let you solve that problem yourself you have to switch wallets to solve it so you switch over to metamask or just wait and so coinbase for example i strongly suspect and i haven't talked to them but just based on having to support their users like they are bleeding users to metamask just every single time congestion happens because every support channel i'm in says to people oh stop using coinbase wallet whereas with 1559 they can just set the the base fee to like two or three times the current base fee and their users will basically never get pending transactions like unless we have some crazy ramp up in gas prices and so i think for wallets that's the big sale it solves a major user ux problem that causes heavy support load and then i think users will just follow their wallets that's my theory we of course can't know for sure they are treated they all become eip1559 they just come in more efficient or less efficient uh as the gas price is defined either as a max fee and gas premium which actually can give you some discounts or as a gas price which always pays maximum potential uh gas premium so so they all eip-1559 we are totally free to support them indefinitely after transition to 8.559.

if 1.59 by itself it solves the problem whether you make everyone start using new transaction type or not and the users will because of how good it will be in simplifying their pricing mechanism and saving them some of the gas fee they will transition to the tools with 8.5 so i think you're making i agree with your argument even though i don't think it's ontologically look you're basically saying when you use users you mean wallets you're saying that wallets will because if basically if i use this other old wallet that doesn't update my gas fees are going to be higher by using the old wallet so the wallets will change because the users the whole problem here is the users don't have this like we all know so much more about how the system works than a normal user the users aren't going to know what's going on all the user is going to see is that if they use wallet a their fees are whatever percent cheaper than if they use wallet wallet b so they're going to stop using wallet b and so my own and that's a perfectly fine model but then my question is how big is that discount it depends so i think the way to think about that discount is almost more in the engineer time you spend on your gas estimation algorithm because in theory if you got so if you use the legacy transaction format and you estimated things just right where like your fee cap or sorry your gas price is equivalent to the base c plus one guy and you get that estimate just right your discount might actually be zero right like you might be able to like sneak in at the right uh 1559 price using your legacy transaction but the challenge is like that's just a hard estimation to do whereas under 1559 it's kind of trivial so i feel like the discount is more like yeah the engineering effort you spend on your estimation algorithm which will not be kind of perfect um does that make sense yeah yeah the problem that you are solving with vip1559 is that people have trouble to actually calculate this perfect pricing so exactly yes the minimum discount will be zero but it will be never would be never paying less with the all-star transactions yeah honestly users i don't mean only wallets i mean also many users that build their custom tools custom algo trading tools or whatever that are actually generating transactions with the custom build solutions based on the client code and there are probably plenty of users like this and it might be a very big cost for them to have to transition to stools and some risk potentially and we want to avoid that risks i'm talking about users in general whoever is signing transactions generating transactions so by volume do you which group do you think represents the majority of i mean i guess so i think that that's i understand what you're saying there um i think that those are that's a very different model for um who the chain is for right if you are making millions of dollars a day uh running your arb bots then you can figure out how to patch your code right i don't i'm not i'm not worried about those people uh you know they're all very savvy and very uh capable i'm more worried about the broader base of people that are represent the larger numeric number of people not the value on chain right i mean at some point it's like why are we doing this if if we're doing it to uh facilitate arbitraging then you know there's no point in even having this call if we're trying to increase adoption and make more applications viable on ethereum then that's when these sorts of changes become important the the broader base of user would be the one that is using the most common tools and the most common tools would be the ones who would be implementing eip1515 like metamask or coinbase wallet so yeah i think it's it's it's okay to think like this but i do see that there is an incentive for let's say the major wallets that the non-power users are using to to shift to 1559. so i think my opinion on on the why shift why switch is is not for the fee saving like i don't i don't think coinbase wallet's gonna add the code to save fees for their users i don't think metamask is gonna add the code safety is for users i really do think both of them will change because it saves it improves the ux for their users pretty significantly in certain situations and those situations are a support nightmare i currently have a team running support in uniswap and the the number one problem that you swap users have like 100 questions every single day scammers are number one number two is by transaction stuck pending like this is the support load for decentralized apps and essentially end wallets like the number one question after i got scammed is why is my transaction pending what is a gas fee why is why do i have 17 queued transactions like what happened how do i fix this like these are all like this is where support comes costs come from and so i think 15 59 makes it so that should only happen incredibly rarely like when you have you know six blocks in a row that are all double full which we expect to be an incredibly rare event and so i'm of the opinion that the gas savings the fee savings is not the big deal like i don't i agree with rick that people will not switch for that gas savings because it's fairly minimal in the end but i do think people will switch for that ux improvement like and and i think that's where i disagree with rick at least a little bit it's just that i do think people will volunt or wallets will voluntarily move which will cause users to move because users will follow the wallets just because the support burden is so high for for this issue i guess to take a step back um about the transaction pool sorting you know this is not something we can enforce in consensus without major changes to the spec i personally would be pretty opposed to doing that just because this is already a hugely complex eep and uh and like trying to enforce ordering in every single block feels like you're adding another i don't know i don't think there's even a known known solution to that problem right now yeah so in that case basically you know the transaction pool is outlet consensus we don't necessarily have to have a solution on that now right like i think it's and and it's also something we can update in like we don't need a hard fork to update it right we can update it in like a you know bi-weekly release of guest or basu or whatever if we see that there's an issue obviously that's not like 100 true because you know miners won't have to update their notes then and and they will at the hard fork um but i guess i'm just you know it feels like kind of a pretty big rabbit hole that we might not get resolution on right now and and we can certainly fix it i don't i agree we don't need to agree on it um but i do think there's value in making sure at least every client knows what they're gonna do like yes and yes make sure everybody has a plan and that yeah we kind of talk to each other and share what our plans are so that way no one's left like having to solve this problem yet again while someone else has already solved it and same thing with the replace by fee like everybody has to solve the replaced by a fee problem they can solve it differently but it'd be nice to at least share our potential solutions with each other yeah and replace by fee i guess to me is a bit different because we we talked about it on the discord i think it was like a month ago and it seemed like there were a bunch of solutions that were vulnerable to potential denial of service risks um so i think this is something where maybe yeah having a canonical formula that like different clients all use that we know is somewhat safe actually has like a pretty big benefit rather than the order range of 1559 versus 9 15 59 transactions and obviously there's overlap right like the replacement by fee might change how you do the the ordering but um yeah i i think that's one word having a common solution is is higher in priority yeah i agree we saw that recently with guests where they their semantics for transaction ordering uh resulted in some problems because they're the dominant minor yeah yeah and i know i i don't know if i'm remembering this right but i feel like barnaby you had put together a formula or something for the replace by fee that was like decent is that correct uh yeah it was just a way to make sure that you never can replace for free where like for free i mean you can do it indefinitely just spamming the network and you never get accountable for it and the idea is just that you need to increase like the minimum between the minor bribe if i remember correctly between the minor bribe and the free cap like the minimum of the two has to increase with every replace by fee probably has to increase by like 10 percent or or something like this but but that's the only way that you don't get into edge cases where i'm resubmitting with a different minor bribe but it doesn't really matter anyway because i'm maxed out on my feet cap or the other way around so yeah it's it's we've discussed it a bit i don't think it was very optimal but it seemed that there wasn't any other option that didn't like protect you from spamming yeah is there i don't know what's like the right place to just like store that or save that so that there's like a proper discussion on it because yeah i remember like discord messages i'll write something yeah if you could write something up that would be that would be really valuable and then all the client teams can kind of look at it and give feedback and i think even getting like you know peter and martin and from guests to look at it could be it could be really valuable awesome yeah cool okay and so yeah i think yeah for the transaction portfolio we can just keep the conversation going and shares would make progress but it feels like there's a lot of different options and we don't necessarily need to resolve it now well it just sounds like they don't need to be sorted at all right i mean am i missing something i mean basically uh if the if the uh yeah it doesn't sound like you need to do any different sorting than what's already been done because there's only one transaction type effectively if you depend on how you code it i mean you could like have a flag on on your transactions like in memory and then you say this one was originally a legacy transaction so we're gonna de-prioritize or prioritize so it would be possible um but if you code it such that like when the legacy transaction comes in you basically do an in-memory conversion and then you drop it into a pool with everything else uh it you could very easily design it such that you forgot that it was your legacy transaction originally so i think this is i mean i'm sorry i don't want to beat this dead horse but i i think for me the issue is having these different code paths for something as uh used as broadly in the guth code base as transactions um is a risk but if other implementers or implementers are comfortable just you know absorbing that risk in perpetuity that you'll have two transaction types with no cut off for when you'll support the old type that's um that's fine with me but uh i i just seem it just seems like it'd be better to plan that than not plan it i think the last i remember we talked about this there was the tentative plan for deprecation if we decided to go forward with it was to introduce a basically legacy transaction tax that if you submitted a legacy transaction you would be taxed a little bit and that tax rate would increase over the span of like two years or something the major counter argument against any kind of deprecation is people who have signed transactions from a paper wallet from three years ago that they cannot resign for whatever reason um we want to make sure their transactions will always be valid and submittable to the chain even in 10 years i think that's the main contention that i've heard is that just perfect do we definitely know or not yeah that's a perfectly fine argument i think that you know i met my experience in working with geth which is limited but my experience in working with geth is that's ultimately going to be some sort of you know recipe for an event in the future where things go sideways but if that's the desired user experience that's that's fine with me is that worth maybe just adding as like a security consideration in the eep like i don't know i think it's worth here if uh because rick what kind of uh what kind of risk is suggesting that actually this um sorting mechanism working i mean we still have to define how exactly this conversion is done right so because the the gas price to uh to feed cap conversion or like to premium conversion is uh different and different block we are just discussing today in many mine that when you sort like then historically you would sort and that sorting order would be unchanged from block to block if you start sorting by gas price including the legacy and e1559 transactions and f1559 change their gas premium based on the block by block because of the fee cap being there so so the sorting order may change even without new transactions arriving or not so sorry i'm missing something why would the sort order change like certain transactions will no longer be eligible oh you can clear it you cannot determine yeah it depends on the block yeah yeah because the you may if the fee cap if your fee cap is reached you may end up with a lower minor bribe than the previous block yeah i see it okay that's unfortunate ugh that sucks yeah so i i think that when we talk i mean maybe we should just sort of change this uh bullet point to say instead of transaction pool sorting transaction pool eviction right if i'm understanding that is actually an issue is that what you were just saying uh tomas both i mean it's good to keep the discussion and maybe write down how everyone decided to do that because maybe we just assumed that we'll do it the same way but we won't sir definitely i agree with your comment here rick that uh it may go wrong if we at least don't describe it so everyone can read it and feel confident and i think the account abstraction eep actually did that quite well uh they posted in all core devs this week and i was reading it but they as part of the eep they have like suggested behaviors for the transaction pool right and that's not obviously part of consensus but they still specify it in the eve and explain the rationale why um so i think that's probably something we would want to do as well yeah there was uh there was some talk a while back and i just realized not on this agenda about actual eviction strategies again not a consensus issue technically but there was discussion of what if we just say your transaction is evicted if the base fee goes past up like passes up your um fee cap like you just flat out getting evicted need to resubmit the idea being that we can keep the the pending pool cleaner like thinner the disadvantage being that could result in more gossip if the base fee is fluctuating heavily so we were thinking to keep even the uh negative negative uh sorry trying to find a uh you call it minor bribe okay negative minor bribe in the pool if it's still in the top x uh transactions is if you assume that the pool holds uh four thousand transactions and some of them towards the bottom are actually having different negative values we still want to keep them and drop them if better transactions arrive the bigger question for us was what if we drop transactions that actually after the base fee falls would become a bit uh more miner friendly afterwards but we we think that's not a very big issue but it might be so i prefer to have it on paper yeah there was uh there's an argument i think vitalik made it where there is some i'm trying to remember if someone else remembers please jump in there's some potential advantage we get by evicting people evicting transactions um because it solves some kind of nuisance problem that we've had in the past anyone remember if not i'll bring it up later it was the idea that's actually interesting scenario where users go sorry oh okay um it was the idea that you could send your transaction with a fee that was too low uh like let's say lower than base fee currently is so that you just wait for it to be included when base fee becomes lower and i think the argument was that you shouldn't be using the network as your like transaction pending transaction queue your personal pending transaction queue all right which basically don't peers should not accept transactions with base fees that wouldn't be included in the current block like if you get someone gossips you something and it's not can be included just reject it and you say yeah don't don't tell me about that please it's a waste of gossip a softer rule to say if your transaction is 10 below the current base fee okay then we accept but if it's if you're just sending it in the hope that base fee gets halved at some point then we shouldn't be looking at it because it's too too much to handle yeah i'm a fan of that it reduces the gossip of the network and like you said it keeps people from using the network as their personal storage effectively yes think it would be intuitive and problematic for some of the wallet users but uh i'm not very against it but i think it's not necessary that uh we already have all the clients holding top x best transactions and even with e1559 we still be able to tell which transactions are best so there is no need to specifically evict them different way i think the idea is with 1559 the pending pool actually should be empty most of the time right if we are evict people the base fees too low or if we don't accept people's base fees too low like so the whole idea of like historically we've always had a fending pool that's always full we're saying that hey we don't have to do that anymore we can now run clients with basically empty pending pools almost always um because your transaction either is included right away like within a few blocks or it's not going to be included at all like those are the two scenarios and so we don't need to have like you know 50 megabyte pending pool anymore if we if we don't if we decide we don't want to gossip that stuff makes sense okay so does it make sense to keep discussing this like yeah to discuss the different options the more details i feel like personally i just need to think through it more um i do think there's value in discussing and at least having every client document what they do for place by fee what they do for eviction what they do for accepting gossip of new transactions and what they do for transaction pool sorting like i think knowing what each of the clients do for those four is valuable and i suspect once each client gets to implementing it they're going to have a ques it's going to come up as a question and they're going to ask what are other clients doing and so i think just having that documented and talking about it is valuable so replace eviction sorting and what was the fourth and the gossip accepted around about the word for that yeah what what do you what does your client accept this gossip as a valid transaction and what do you not accept as gossip and then also this is actually very important what will you kick people out of gossip for like if someone gossips you something that you think is just outright wrong you probably are going to blacklist them and we want to make sure clients aren't blacklisting each other so we need to at least agree on that much and what's the where's the best place to like actually write that down probably not in the eep itself but it feels i don't know does anyone have a suggestion i agree not deep um i can start a hackmd document i'll link it in there uh i'll link it in this in this page and i'll just add a section for every client um yeah and then people can can uh can uh just add their behavior there um oh sorry just see this shot i'm not sure an informational i wouldn't do an utter eep until we're actually like settled on some best practices and maybe once we are settled on some best practices we can add it i don't know like some appendix to this eep or something but just now okay so testing um reference consensus tests i don't think we're quite there yet especially given that like the 2718 change still hasn't been done um so this feels like it's probably a bit too early community testing like i think we're starting to do this and you know abdel's tool can kind of help people interact with the network uh we'll keep improving on it and then i think the public testnet that applications can use this is basically our fork of mainnet that we discussed earlier so it seems like it's going well um