EIP 1559 Implementers' Call #3

Oh so hi everyone thanks for joining this is implementors call number three for a IP 1559 and now now also other proposals oh we have more people kind of slowly rolling in yeah so the goal of today as pretty agenda was made me to try and analyze the different proposals that have been put forward so there was the original IP 1559 then Dan Finley from madam asked put together their I sort of counter or composable proposal for it I called escalator fees and then Myka is old too I hope I'm getting his name right and also had another proposal around pipes transaction envelopes which both eeap's could use I think it would be valuable if we can get to a spot where we we have you know pretty broad alignment on on what's the best way to move this forward because then we can start answering some other questions around how do we actually test this what's required you know for us to feel confident deploying this on the network yeah does that generally make sense everyone yes okay so I mean I can go through kind of the list of comments that people post it as a sort of conversation starter but yeah there are three main things that that that people I don't think any of them are on this call voice in terms of opinions with regards to if we should bundle or unbundle the proposal first there was Micah's comment basically saying that he strongly against bundling the eeap's because they both add value on their own and and and so we should just have them separate because of that then Barnaby put together kind of a pretty long pretty long explanation saying that either either we have to keep keep the current transaction model with the escalator rule for the fee and by current I I assume that he means III assume he means like what's on may not debate and then the second option is you use 1559 and you use the escalator rule to calculate the premium and then finally a der bit which is kind of a research block chain analysis blog put together a pretty thorough analysis of the escalator proposal and and how it works or doesn't work with 1559 and they're kind of take away after the analysis was 1559 probably provides most of the value and the escalator can be done outside the protocol so maybe it makes sense that just start from 1559 so I'm curious to get thoughts from just other folks on this call yeah for the last point I kind of disagree with that I think it's better to have the escalator algorithm and the protocol layer because if you delegate this to a third party you will have to resign the transaction so we will have a background service on the pilot for example and to resubmit transaction and I think it's better to avoid this signature process if we can have this in the protocol layer so there's anyone on the call think we should not bundle VIP 1559 with the escalator fields proposal I'll say neutral on that for me it depends also on if we want to make the type transaction envelope a requirement of them because if we don't it will be hard to let's say implement it 1559 alone and after at the escalator if we don't have the type transaction envelope I think it will be better to have the type transaction envelope before implementing both the IP so that we can even imagine a system where you have some basically three transaction types VIP 59 alone escalator alone and the combination of both but I guess it will be maybe bad because the user experience will be different for different types of transaction but yeah I will strongly advocate for having the type transaction and developer requirement for both are you saying have the type transfers first and then do 1559 and or before either of them right basically on the same hard fork but just let let's say for example pass the tap transaction envelope to efi and then make this as a requirement for a 1559 and it oh sorry why are you saying that they should be on the same hard fork like wouldn't it just make sense to do tie transactions as soon as possible and if the next hard fork they're both at it's great if not i mean it's it's mainly to avoid changings user experience from half of to another because if we implement trust in 1559 we will have some breaking change and while its implementations etc also on user experience and then if in the next heart fork we decide to add esqueleto we will again have some breaking change on the user experience so I think it's pretty bad but yeah and that's with with without the envelope in both cases I mean we could have a combination of both 15:59 and escalate or without through the type transaction and drop it will be just harder on and purer implementation side but we can deal with that but for the breaking change on the user experience it does not depend on the transaction type envelope in my opinion how she just joined who I think would probably have something to say about this if we turn off the speed they're talking about bundling these two IP e IPS whether that should happen and and the pros and cons against escalator being in protocol or not mmhmm yeah hi I don't have a strong opinion on whether they should be funded or not I think that's clear in general it's a good idea I think we we see that it's being adopted on the client side and it's it's also something that uses to manually already so that's that's one of the main points of our analysis that we published today that there are some arguments that the protocol should be as lean as possible in the base that protocol so we should see if it's being adopted on the client side then it's very popular than we can internalize it that would be my approach and in that case you accept to have to breaking change because even if it already exists outside the protocol if we integrate it after an the protocol that will be working change so yeah in my if I could have everything all lined up right I just for simplicity of less moving parts I would prefer for 1559 to go in first and then say maybe in four months we can even plan this advance in advance and work towards them of having like a four month window between 2.15 59 and then adding that square algorithm it's just there's simplicity and having less moving parts when it first started because there still is some risk of things going wrong and so having less things that could go wrong all at once seems nice as far as breaking changes I think it's valuable enough for the users of the network to like the reason we don't break changes is because of user experience and it's and it hurts somewhat users expectations but in the case that users want it enough then it makes sense to go forward with them so you're saying if you ship 1559 as is you change the transaction fee that means every single wallet has to kind of readapt and then if we then ship escalator you know call it for six months later you have that that that patient again right you're asking once more every single wallet or thing that sends a transaction to readapt I feel like that's like a lot like I yeah I feel like that's a lot of added complexity to the entire ecosystem that we can maybe manage better by either saying you know 1559 as is is complicated enough we want to ship that and and let's just do the escalator like the protocol or if we really want the escalator in protocol I think it makes more sense as a single a single EEP like a new EEP that's like a merge of the two in a way because then you have this very complex change but you only have it once right yeah so you're you're saying having 1559 as is and then having the escalator be done outside of the protocol with the option of coming back later and doing it I don't have a strong opinion or something either either that or you basically create a new EEP that's the escalator with a base fee or 1559 with an escalator tip however you want to frame it but you just do it all in protocol from day one as far as for like the difference between the the escalate the escalator change isn't really that big of a change if it was just on its own as far as its true X and odds so I especially if we were to say we're rolling out in part in phase 1 and phase 2 so while people are prepared and they know that their that these kind of changes are happening in and they have to build the UI anyway for both if we're going to do both if we say hey we're going to do one and then we're gonna use some time to inform to make sure that our decisions are correct on all of these on all these variables and and then deployed escalator tip maybe it turns out that we don't even need that because of whatever ends up working yes it is saying part one and then we're gonna come around and say let's do everything again part two or like completely separate change because we keep free yeah if we do need escalator after it will be confusing for user because the the fields they were using without will mean another thing so it will be confusing for them because if we combine them it is the interpretation of each field is slightly different so I think it can be confusing for user and if it is in such a short period it can be really hard because a lot of the work will be about educating user I guess and and also in 1559 is already designed to be you know there is two phrases on in 1559 so there is already a transition period to make the wallet integration smooth before and it seems to me that will add complexity if we say we have an e p-- that makes the integration smooth with the transition period but four months after we will have again a breaking change without the transition period again so yeah changing the minor tip to an escalator I don't think is complex enough to warrant a transition period no but it's more about the wallet integration there the wallet integration if it works outside of protocol like let's say we do 1559 first and then encourage wallets to do the escalator yes have the escalator tip outside yeah I see what you mean we can leverage ux/ui but the most difficult part will be about transaction signing because it totally change how you signed transaction with or without I mean if it is outside of protocol basically it just simulates skeletor by resigning transaction with different gas prices but it is not the same that yeah with the skeletor in the protocol you sign the transaction only once so you have to include more fields in the transaction signing and how you encode the transaction etc so yeah it's this is the main important change we it's true that that we can leverage the UX UI but not the signing yeah one one thing I'd be curious to get other people on the calls opinion is in your piece has you you mentioned like there's sort of privacy implications at the escalator fee right because if you if you kind of put a transaction in a transaction pool and then resign into the higher gas fee like sure somebody might be able to track that but it's not like part of the protocol forever or part of sorry to kind of history forever whereas if you have the escalator basically every transaction signals you know this is the least in the back side willing to pay and that's gonna be recorded as part of like those heels being added to the transaction does anyone like what do people think about the privacy implications there the people think it's like a concern is that something that you can already kind of infer anyway on the network yeah so I see two implications - one is on user balances or user accounts so accounts may be associated with a higher like propensity to spend or something like that but that's right forgot my point I think we already had this thing maybe less big but because you cannot know from where they started to to bid but you know the final price so you can have some signals about about how important was the transaction for the user so it it disclosed some information less than with escalatory in protocol that yeah yeah I agree the second point the second point is on whatever if - can use this information to come up with any new strategies - may be delayed transactions mmm they know if they know deterministically that the transaction is willing to pay X amount in the future if it isn't included now that's information that - don't have today but I I don't know if there's a way for them to exploit that I don't know you could certainly wait and hope that nobody else puts your butt's there the transaction and like if everyone waited till the end then everyone would have the maximum escalator fee that maximum fee so that it's actually kind of a good point of having if it's outside a protocol level then you remove that information from the miners so they're they don't know yeah I mean you would hope that this coordination problem amongst - where they are like one of them is incentivized to break the kind of cartel formation and just include a transaction once its profitable instead of delaying and delaying and delaying yes locks are generally full though and most miners are following the strategy of waiting then once I come along even if I want to be honest I'm still going to pick the ones that have been waited on so the strategy might still be dominant even if you have like one honest person that wants to to break it just because breaking it would assume that they would pick up all the that most valuable but also pick up the ones that haven't reached the top escalator but if the blocks are full they don't necessarily have that option anyway so does that suggest that we should think more seriously about how to do it outside the protocol here I'm not necessarily suggesting that I'm just suggesting that in the extreme case you might have you know the honest player doesn't necessarily break the strategy yeah yeah I was I'm also wondering more people on the calls that's kind of the direction that this is they came to my intuition is that it's not a big yeah that yeah that you leaked this information to - I have the same intuition so then what are the the big deals there you can still escalator your if you want to do not reveal information you can still like put the min and Max very tight and then sign a new transaction rather than dealing with the protocol escalator yeah you can still use the info local escalator strategically all right now you only encode it for young Koda strategy for two blocks or three blocks and then you write even if you're willing to go higher and more block exactly strategically don't reveal your true preferences yeah my biggest I think big concern at this point is just I'm not that confident there's actually the time to do both separately like and that the UX burden is worth it right like I think 1559 like changing the way transactions are formatted is probably the most breaking change you can do on each one at least because literally everybody who sends a transaction needs to adopt I would strongly try and avoid doing that twice especially given that like historically we have like a six to nine month delay between hard Forks and so that means that say you know say best-case scenario we ship whatever just 1559 early next year and there's another six months it means you're still looking like at another year before the escalator goes live on the network and right when everybody's kind of starting to get comfortable with 1559 you're basically breaking things again to me I I don't know my intuition is that's like worse than either option of like never shipping escalator in protocol or just you know the extra complexity of bundling them together and I wish definitely was on this call because I feel he has the best perspective from Mellon asked on like yeah how much breakage is is acceptable but yeah yeah is there problems on from just like transaction inversion perspective of having because we don't really have that capability built-in or having multiple transaction types if they're implementation problems of separating and from that perspective well I guess that one I can see is do you want all your transaction types to burn the base fee right and if if you do which seems to be like a lot of where the community support for 1559 comes from that if all your transaction are burning the base fee anyway you're kind of back at this problem right where they all have this pretty common they all have this common component and you're kind of messing with like the other parameters you so it seems like I don't know no one here has like a super strong opinion for her against but newlymet's you I have a strong opinion for my chili for bundling okay yeah yeah okay does anyone have like a strong opinion against bundling them together I would assume that barring more analysis most people on this call would not particularly have a strong feeling unless bundling was going to significantly delay deploying 1559 you know if there was additional complexity in employment protocol on getting it tested in getting it released that was gonna push everything back say six month or you know a single hard fork I would have imagined a lot of people in this call would rather push out this in 59 than bundle but I don't have I don't have a good handle on the relative complexity of adding elevator and protocol versus just to me it's easier to do them than adding them later especially if we don't have the type transaction envelope by a Mayans assumption was based on the fact we accept to have the tag transaction and developed as a requirement of 1559 is it also possible to ask a question on 1359 in this coil sure okay so what would be interesting to me is have you ever tried to simulate any 20 million gasp blocks as the proposal suggests designs we decided to remove the block limit hard riders and let miners decide as it is right now and there will be a separate EIP to add riders if we think it will bring value but we decided to separate it 15:59 from the riders I mean just in terms of stability how okay no and that was basically the next point on the agenda but I think the hard part is we basically want to agree to a spec of like what those blocks look like before we start those simulations but I think that would be that would be the next step yeah and maybe regarding the block voting the guesstimate voting is it is anyone seriously in favor of that at this point or would it in favor of removing it of keeping it I feel like it's a known incentive incompatibility issue having - decide the the gas limit so I'm just surprised that there have been arguments made that we shouldn't bundle those two things together right because like there's different proposals in some sense yeah that's my strong opinion as well as like if you know if we want to make the blastia blood gas limit something that's controlled by say hard forks that's a separate EEP that's like 1559 shouldn't introduce that as a sort of five dependency because it's a pretty critical change and I would I would strongly be for putting it as protocol layer not as in minor control so we're giving a blood gas limit implementers call we could do that it's just it's yeah this that would take I think that would take the discussion would be for answering hostage question I would I would there's been some discussion about how to like procedurally manage some of the amount of changes that are happening so we talked about it as removing riders and such but I think we should seriously consider having the protocol have it be a protocol level and not something that miners choose this is kind of yes side-side rabbit hole though but yeah I think I think that this should be a separate yeah yeah but it should be a separate deep like I I think I'm fine with that I'm I agree that that should be the format yeah I think we should also still execute on that okay got it so I guess related to that back there sorry bundling that you eats would it make sense to try and you know put together a proof-of-concept implementation of the bundle and you know see if it's if it's pretty straightforward start testing with that because I feel like if the main the main concerns are either you know it'll slow things down then we can't really know that in advance if there's a concern about maybe you want that at another level of the protocol then the client I I just don't think we have the right people on this call to figure that out but we can at least move forward with kind of the escalator tip and and then start doing stuff like modeling you know 20 million block sizes I like doing some more kind of formal simulations and whatnot but at least we have like a single spec to go on and then if there's any significant problems with that we can kind of go back to 1559 sort of vanilla 1559 if you want because otherwise I just think you know it'll kind of slow every conversation down to always be discussing do we do escalator do we do do we do the original one and it won't get us to like yeah figuring out can we handle 20 million gas blocks can wallets actually provide you know a good interface for that and whatnot yeah I agree with that I think Danny is on there on point with that the biggest concern would be around timeline changes so if we could just agree that we the ideal version is to have 1559 and escalator trip the question is how does that move forward if they happen separately or if that at the same time then we can look at what what actual effect on the time let would be because if it was if we had to wait an extra three months three to six months to put the escalator tip in then we're then were we've pushed 1559 back a bunch and then how to say this clearly so if we have a timeline of 1559 could happen sooner if it was without this clear tip and then three to six months later we could have that escalator tip separately versus if we put them both in but then they're both delayed three to four months then yeah we solve it that we end up being worse off yeah yeah I don't really have an opinion on my timeline so on but under the condition that one of ff9 is delayed I would also oppose bundling them together if that's the result I don't think it will be delayed if we add algorithm we can start implementing the proof-of-concept to add a scale at all just to unlock people that will do the simulation and then we can see if we want to do the tag transaction envelope but that won't change the simulation does it clear the so for for perhaps maybe for Basu but like has anyone going to be writing the gap client implementation or the other client implementations for that there's other I can ask I am from veganize who did 15:59 implementation to see if he can walk on the escalator yeah he he wouldn't be able to unless we got funding for and yeah yeah so there there isn't currently someone wind up to do that work on the get client so that would be something else we need to solve okay yeah that was I think you know frankly if nobody's gonna do the implementation work there's kind of bigger problems of you know whether or not we fund all the tip because they're still going to be you know four months of getting this live right it's gonna take more than like it yeah reference implementation on wherever the spec was at six months ago yeah there's a different amount of work to polishing up the current in 1559 that actually does things versus refactoring to put it isolated like that's that's a significantly different amount of work okay so I guess can we decide that the ideal world is that we have both and it's about how do we get them in yeah in the best way yeah I think I would rather go for that and then we can always trim down and and we can just assume they're both going in and figure out the implementation details you know in the broadest general sense but at least be clear on the spec of like okay this is what it should look like um and if we if we say the igl version is to bundle them we we have to decide how we be the ideal version would be to have both but it's a clear which if they should be bundled or released a series okay okay so we can decide perhaps today that that is the what we want to work towards and the next question is that's way I get to do that whether it's bundled or not bug that make sense with particular sensitivity to timeline the effect on the timeline okay by by bundling these are we inducing the ability for more side by raising the complexity of this change for example and I know there's some people that are calling for more in-depth technical and economic analysis in 59 if we add lsq later and don't as well do this type of analysis and there's kind of open questions about leaking information like I said we shooting ourselves in the foot a little bit I would say definitely okay yeah I think I think the challenge deal is you know Dan's rationale for having the the escalator in the first place it's like there's a bunch of problems that are like not solved by 1559 so so yeah and and and I guess the big open question is also how you know how much of these could be self outside of protocol and if we could get you know 80% of the fixes out the protocol and minimize the consensus change maybe that that's a better approach that comes back to like agreeing that we want to get to the world where they're both in but not sure how to best fit them yeah um so maybe in terms of sorry go ahead is there anybody strongly opposed to having that be like the vision that we talked about is having 1559 with the escalator as the ideal case yeah and maybe one way we can flesh this out in more detail is I can schedule kind of a call with Dan Finley and Adele and and maybe Ian he's available so that we can actually go over you know what it would look like to bundle the two eeap's as well as as well as what could be done outside the protocol with the escalator and and what the implementation impact of those things would be does that make sense yeah okay so next thing on the agenda was basically testing Nick Johnson was on the call but he dropped off I think I know he's been kind of pushing for having like a more rigorous analysis of the 1559 inspect hassey you mentioned you know trying to simulate 20 million gas blocks and seeing what the network looks like under those conditions Barnaby has been working on simulations I think it would be valuable to kind of you know get people's thoughts here on what we think like good enough you know testing scenario for 1559 and the escalator is I'm by the way just a kind of more general question on this one I'm on the etherium test that's do you know like how much activity there is like how many transactions a day how many people using it and so forth just looking now Rob's tonneau 515 transactions each average of like I don't know most blocks most recent blocks seem to be either like less well either less than like a million are like you know Phil would probably like I don't know three four million which is probably like a couple of large contracts that people deploy mm-hmm if you give Ness Pacific's for the question I can do some sequel queries and get back to y'all that's a bit unfortunate because I feel like the challenge with this mechanism is that like all the economic analysis in the world is honestly gonna be less useful than like just seeing it run for a while and people getting getting a feel of how to interact with it and I guess we don't have the ability to use to really properly use the test as an environment for that I mean we would but it's just that the guess the base view would kind of hover around one way most of the time and then maybe occasionally else it'll start spiking up oh if there's bursts of usage yeah and the last last call I recall before Thomas from after mine said we should basically you know once we have a spec have a public test net and try to you know just market its pretty pretty heavily so that people kind of deploy stuff on it in the first few blocks because that's kind of what you want you have like a burst of usage right on the network what kind of both what one way this might be a little bit extreme but the for Rob Stein is we could temporarily move the gas limit to like two million so you even if it's low usage you can simply are girly a little extra step the thing you could do is and keep the gas of limited ten million but keep the target at one or two million oh yeah yeah that's a better way and how under challenge what Robson is obviously applications kind of depend on it and we'd be putting in a sort of you know half ready 1559 what are people's thoughts on that this may be the wrong call maybe I'll core devs a better place for that but yeah what are people's thoughts on like breaking Robson early versus you know using your new test met the challenge therapy and getting people to actually use it and ultimately wouldn't we have to do both like first yeah with a dedicated test that and then like any hard fork goes on Robson before me man and in anyway though in this case we could do it on Rob's done like six weeks before instead of four B or whatever so that there's more time for X yeah but if we do an artificially low target on the gas limit it might actually a grenade I see usage there yeah and I can imagine where like before we're ready to deploy 1559 and like a proper hard fork we want to get some network usage data because like you said it's probably what I'll inform the best with breaks right so I was thinking of like you know we did this ephemeral test net for Berlin could we have another one easily for 1559 and then the challenge is how do you get like a lot of usage on it is there a way we can just like write transactions you know like a sort of bots that sends tons of transactions to it the little bit of complexity as far as looking at comparison to Yolo is that part of the equation is looking at how miners react to it so having to be a mining will testing like is that a make or break for is is it necessary for the pre-test net to be doing this beam mind proof work I think it might be just because of the implementation right that Dell like we said 15:59 won't like will be like a proof-of-work thing is that right it could work with storage in network yeah that's certainly be easier to do and then a lot of the stuff you're talking about of throwing transactions and stuff is - is very much possible so we basically have one like a cleat test net yeah probably with more than one validator just to make sure it's actually works on and bigger than 1 and we can fake volume on that yeah can we reasonably write trips to fake volume you know and you know in a meaningful way feel like you should be able like especially if you have like Genesis accounts with huge amounts of ether right like they can just that what we might not be able to do is or or might be more complicated to do is just like complex smart contract calls so you're not making that but if we just want to feel blocks I don't see why you couldn't automate that pretty easily we vary the agents activity to kind of induce like interrupt yes this is what I was going to say Barnaby is working on implementing some agent date simulation and I don't know the stages but he was pretty advanced last time I talked with him so the basic question but why couldn't you simulate 20 million blocks trimming gas box like that that is that should be done separately for that that is that week so there's two questions to answer one is is the 20 million blocks safe for the network okay and then the other one is does 1559 actually sort of work as we want it to in practice yeah but I think we still haven't figured out the best way to test that but a but I got like a thick net that all it does it just pump out big blocks and then see how that how that works is something we should talk about I'm gonna have to head off now by the way thanks for coming yep yeah and I did yeah in terms of blood sisters yeah there's a few things like can the network handle 20 million gas blocks without crashing and then the other piece is also once you have the transition from regular transaction to 1559 style transactions you're basically cutting the block like the the block limits of like based on the type of transactions and so would you stop would you make it impossible for you know large contracts to be deployed because the block is like say 50/50 between normal transactions and transactions intuitively I don't think so we can we can reduce the transition period and we can even start with directly phase 2 maybe I mean is there any value to tester phase 1 where both legacy and new transaction or accepted yes because wallets need to upgrade right yeah but for for what we want to test Oh introduction of justice yeah just for what maybe not initially but and I think on on main net so say you you're affectionately doubling the blood gas limit right so if I wanted to deploy a 10 million gas contract you would always be able to do it because of the slack right so if it starts and it's like mostly old transactions and some 1559 then you deploy it using an old transaction and then once it's tips the more than 50% of 1559 style transactions then you can deploy your 10 million gas contract using a 1559 size transaction you'll just fill up the block right okay um so just to kind of summarize it the test nest stuff we need it probably makes sense to start with a new test net that we can at least run like a fleet version of 1559 on and have large blocks and see this you know does this actually work and crash before we do anything else as is or if 5959 alone would that be quicker yes because we have already the implantation but maybe we want yeah maybe try have you tried connecting with the Geth implementation like yeah it works yeah it works so then we could do that this week next week yeah exactly we can set up like a yellow or whatever 15:59 yellow yeah what we won't be probably able to do within a week is then fill it with like huge transactions and whatnot but we can just restart the test nerds yeah that make sense and one thing I guess maybe not on this call but yeah how feasible is it to start an ephemeral test net like I'm not super familiar with how to get team did it but is this something that you need you know Peter from yes actually you like work which you honor is an all open source and we can just do it ourselves is it the thing that you are talking about no it would be puppies and Cleve basically yeah so maybe yeah like James [Music] yeah next couple weeks yep and then yeah and then once we have that running I think we'll figure out enough about how how they EEP works to inform kind of future testing but the other the other question is I guess next Johnson's question of like just more formal analysis but if he's not here maybe we can chat with him offline about that um if we are concerned by delay to me it is it is this is the kind of things that could delays well it's a different thing right like because it's like you're you want to make sure this thing is properly tested before you move it the main net yeah yeah yeah and to do that you have to have like a final or final implementation sorry James if you're gonna say something oh no they must have been the birds okay so the last bit on the agenda was funding [Music] or sorry I guess before that there was a the type transaction I feel like we've kind of touched on it in a bunch of different ways but we didn't discuss it directly did anyone have any more comments on that and we can we see if we want to pass it as EFI use it next Oracle def maybe you can it's not typical that any IP is accepted in dfi the same core dev call that it's brought up okay well out there something that could be not okay and then the I'm curious from others here is is making that a requirement for like to have 1559 is to have this kind of transaction thing is that a general consensus we have or people feel strongly about either direction I haven't followed it enough to know yeah I mean either abdel are you familiar enough with it the like talk about it on awkward elves this friday it's a type transaction the envelope itself yeah yeah feel free to do that yeah yeah that would be great Matt if you can just bring it up there and and I think based on the reaction of you know the Chordettes call we can see we can get a feel for like how likely or unlikely it is to be kind of a something that'll delay 15:59 yes okay is there a timeline for when you think 1559 it's gonna be including a hard work yet I'm not really familiar with my hope I'm touching wood as I say this is I'd like to get it for the next forecaster burden okay know when that will be in terms of time but I just thinks in terms of like roadmap it probably makes sense and and one it feels like it's kind of getting ready at that point and then - I think a lot of the stateless Theorem stuff is gonna start you know ready to ship after that and if 1559 is being developed at the same time as all the stateless stuff is being developed I think they might you'll have like these two things that might like interact that are both in development and that's that just means it's really hard to move them forward so yeah anyway short logs so recharge I'd like it to be the next upgrade after burden but I'm not sure when that lands okay I'll present 27:18 on Friday and we'll get a temperature for it and if things are good then we can talk more about what the actual attack plan is regarding 1559 sounds good um anything else on the type transactions okay last item on the agenda was the community funding bit I know James you mentioned this already on the call and you mentioned this to me before like the idea of maybe having like a get Quinn grant or something like that dad you want to give a bit of your thoughts on this yeah I've millions been doing great a lot of I did a lot of great work for the Geth client and continuing to maintain it I think it would be a gate coin grant would be a good opportunity to one fund some of these little things that can that we're looking to happen like a lot of the little stuff and perhaps have some bounties and not it doesn't really need to be a lot of funding but it would be it would help move things along quicker if we could if we could resolve some of these smaller stuff separately and then it would also be a good opportunity for the community to signal their support of 1559 cuz like a one died donation is a skin in the game way of saying yes I really want it and have having that that signal I think would help a lot for the court outside because they they spend a lot of time on the protocol level basically keeping the network alive and that takes a lot of their time and attention and brain cells so clear ways for the community to tell the court halfs how strongly they feel about something I think would be beneficial for their reception on swallowing the complexity of the change because I opened the other ways but that's just has been my thought about it yeah I like the idea of like the community signal from get coin does that mean do you know when the next like CL our CL are around this I believe the current ones still going okay so we could kind of put something together really quick and have it there and then the obvious challenge also with that is like how do you kind of allocate the funds yeah yeah the people have thoughts on that does anyone other than me have thoughts about that or preferences so one like preference that I have that I'm not sure how realistic it is but it's like you you ideally you don't want people to vote to pay themselves right but given like how small you know a number of people there are and and yeah it seems like maybe in practice it actually won't work we could that could be a requirement that the people who are or who administer the funds are ones to receive any of them yeah I mean like it like in my case I'm my work is funded so I I don't I I could fulfill that yeah I guess to like I mean you know we're all kind of getting paid as part of our day jobs to do this so we we don't require any additional kind of funding for it yeah I think if you know the two criterias like if you're roughly affiliated with 1559 and you don't want to be a recipient of the funds then we could just have like a majority votes and we can post in the discord slack to see who the discord channel to see who who wants to be that and basically by by asking to be on this sort of you know voting this you're you're renouncing the funds you could potentially get right yeah does anyone disagree with that approach how do we how do we get the bounty up as soon as possible then and share to the community I can talk with Bitcoin yeah you can make them you can make it today you can the the thing getting into the CLR is a conversation with get coin grants okay you can deploy the grant outside of CLR getting it included in CLR as a matter of just having a conversation with them as far as the governance of the funds and things like that talking with uh as long as the weed aren't getting a lot and we have transparency about where they're all going yeah um I can I can make yeah I can take a stab tomorrow it's putting together to get coin grant and we can maybe I'm sure we could get Hudson to do it I get asked him yeah yeah Hudson yourself some others who are involved in 1559 or have like a lot of domain knowledge one thing that's been a struggle with finding funding is a lot of there isn't a lot of people who have a lot of understanding about a lower level understanding but all the things are going on so it takes a lot of conversations to say oh yeah we do need this little thing because then I'm reacquainting over our and trying to just has a lot more friction than I anticipate so if I'm a like like I can't think I can think that catalyst can also help in setting up this thing the state coin CLR thing and as far as I know as long as it is under the CLR like I believe for this time in 4th of July if we apply before - we are you getting CLR and yeah we would be happy to go ahead terms honey we did is previously for proper so we can do distribution should be completely your I mean the group's decision so yeah we would be happy to help in coordination part sure that sound good yeah so I'll try to get a v1 of the grant ready tomorrow I'll share it in the catheters chatted and in the 15 people think give feedback and yeah we can we can take it from there the the other thing I think we should add to it is as 1559 closes we should donate any extra funds to matching to imagine Graham's system so there's anything yeah okay okay was there anything else that anyone wanted okay well thanks a lot everybody let's go over like the things to follow up on okay okay a call a call with me you and and some others about implementation what we're what were the ones okay yeah so I guess starting from from from the beginning basically under there's three things right there's bundling testing and funding suffered how we bundle things I'll set up a call with Dan Finley I am Abdel James if you want to be there as well great to see basically how we can bundle them and how much of escalator we can do outside of the protocol and and come up with a proposal for that then with regards to testing we we should set up another call or anyways this a sink but just setting up an ephemeral test nets that runs clean which we can start start feeding twenty million blocks for four for a IP twenty 27:18 match you're gonna bring it up on our core dev we can kind of get a feel for for for for how other people feel about the eat there and then for the get coin grant I'll set one up tomorrow and I'll share it with which folks on this call and in the chat rooms to get feedback on it another one is evaluating the time the timeline effect the effect on the timeline of if we move forward 59 first yeah yeah it goes it goes it's a it could be a separate call or borrow the same one but it's something that fall yeah yeah I think that make sense anything else okay well thanks out everybody thanks