FOCIL Breakout #23

Transcript

[music] thing.

Heat. >> [music] >> Heat. Heat. Heat >> up here. [music] >> Heat

up here. >> Um, Akash, are we alive?

Cool. Thank you. Hello everyone. Welcome to the 23rd Fossil breakout. This one will be the last one before the next AC/DC where we decide fossil inclusion. So I'd like to suggest to use this breakout to share our thoughts on fossil inclusion after we share our development updates. So let's start with development updates. Um hello puja. Does anyone want to go first and maybe I can go first as usual.

Um so in my end I'm working on the spec that rebases fossil onto clasma and I asked people about what do we think about fossil in clamsterdam. Some gave us a feedback that they want to see fossils back on top of glass. I opened a draft PR when we see a fight fossil but it was stale. So I opened a new one couple of days ago. It's being reviewed. So please have a look when you have some time. And yep that's all from my end.

All right. So, no updates from Lowar. Uh, Loar is mainly working on EPBS. Sounds great. Um, yeah. Um, anyone want to go next? I can go next. Um, as I've just been working on the spec testing and moved it over from um EST to ELS. Um, all it took a little bit, but I have nine test cases passing, so I'm just working on cleaning that up so I can add it to the PR.

>> Sounds great. Uh, that test case is running in red, right? Yeah, it's I've only tested on well I'm running breath and hive and testing the fixtures through that. Uh I haven't tested on any other clients yet. >> Oh, sounds great. Thank you. >> Yeah, so tech was all the same. Uh nothing special but still working on PBS. Sounds great.

An APF fellow dropped a PR that implements FOS in Aragon. Do we have anyone from any Aragon or anyone who's working on that PR by any chance? Guess not. Um, okay. >> I'm somewhat familiar. I can just talk about it for a second. >> Oh, yes, please.

>> Yeah. So, that's been done by I think it's Fah uh Fahil. Um, it sounds like he just finished up his implementation and I've been working with him. the try to get some interop testing going on. So, not too sure about his implementation and everything, but uh it sounds like he should be joining interop testing soon. Sounds great. Sounds great. So, if it works out, then we're going to have uh three client interop, which is great.

Um yeah, I haven't fixed that um the the bug in the get yet. Uh I will be mostly working on the spec PR and then I will be traveling around dev connect. So not sure when I can finish it but uh I think um if you guys are continue working on that uh I think you guys can try interrupt between rest and argon and see if if it works.

>> Yeah, sounds good. >> Great. Thank you. Um, do we have any updates on metrics end? So, Katya is not here. >> Yes, Pelle. >> Uh, Katya went out for I think the last two weeks and I had just heard back from her from today. So, there's a few little tweaks we need to make. So, uh, not completely finished but pretty close. You mean metrics implementation?

>> Uh both the list of EL metrics and the implementation ref. I think we just have like some naming conventions to deal with right now. But yeah. >> Mhm. [clears throat] >> Oh, cool. Okay. Yeah. Thanks for sharing. All right, I think that's that. Unless anyone want to share their updates.

All right, it seems that's that for our development updates. Um, right, cool. Now, let's move on and share our thoughts on Fossil in Calamster. We are in fossil breakout, but it really doesn't mean that uh you have to be pro fossil or we don't have to derive any conclusion either. We could use this time to do some temperature check before ACD calls. So, who want to go first?

>> Yeah. Uh, I can go first for for for tech team. Um so basically we we we think we still think the same uh since we've gave our feedback for the uh Glamsterdom headliners. We definitely think that Fossil is the next EIP that should be SFI. So uh we are a little bit concerned for EPBS and the added complexity that it will introduce. So I think once we have at least uh a first EPBS working in DevNet, we can definitely uh voice for for for merging the this the forces spec into

the constant spec. So uh that's the only thing that we are uh a little bit concerned about basically uh how it will be with the EPBS. So yeah, but for now we did some good progress in EPBS. We still not have a a uh a working implementation, but hopefully uh as soon as we have one uh we definitely we definitely want to toss it to beified. So yeah, that's and uh we will share our thoughts on that uh before the next ACDC I guess.

Hi. Um, just so I understand, do you uh do you feel like it will would you be even more comfortable like delaying the decision or do you think it's just like fine to have a decision uh this week and like cuz it seems like you Yeah, I'm not sure exactly what what you have. In my understanding we need to I mean the CL teams are asked to give a feedback on the next uh consensus score right just to be sure. Yeah. So yeah, our feedback and yeah, our feedback is definitely that we can include um for should we voice that

in and my understanding uh do we need like to to say if we wanted to be SFI uh during that call or should we just give a feedback on >> Yeah, I think the idea is to uh to make choices is about EIP's uh client teams think should be SFI. So yeah, I mean from my what I understood like um teams are like asked for like a sort of like decision on what EIPs they would want to specify.

>> Yeah. Then our decision would be definitely yeah we we could justify it. Uh with the condition that we I mean EPBS should should is the headliner and should be the the the most important EIP like to implement. If if it really makes things hard and um could delay EPBS, maybe we should reconsider that. But for now, we think that it's it's doable and yeah, I think I think we would be okay to SFI it.

>> Okay. Yeah, that's that's clear. Thanks. Uh maybe one thing that's not only for for you but like generally like I feel like the notion of delaying EPBS with false I mean it will introduce some delays I think so I I feel like I don't know if it's fair to say um yeah I don't know I I I'm just struggling with the idea of like for example saying we want to SFI fossil but as long as it doesn't introduce delays um just because of the fact that it's

you know additional code and and and logic that needs to be uh shipped. So I I think it should be framed as like how how long you know how much of a delay are we ready to to accept for it to be SFI or or and then after that delay it should be dropped so it doesn't like you know actually delay PBS and like headliners generally like further than this. Um but just just suggest suggesting like it might be worth thinking along these terms as well. Um but uh yeah just wanted to know what people thought.

and see uh can you remind me what was load star exactly saying because I'm I'm trying to find the the docs but uh >> yeah it was a blog post um yeah basically supporting EPUs and full together But also, you know, since like last ACDC, there have been, you know, a lot of new EIP candidates. So, we still need to go through them and see if like our opinion has changed. >> That makes sense. Cool. Thanks.

Great. Great. Do we have any other comments? Uh if you want to express your personal opinion, that's also very welcomed. Uh >> so Nethermines also pro- fossil or Camster. Um though it's hard to say what the tradeoff is with the delay in PDS. Um so it seems we have or depths here from several teams. Maybe we can ask uh maybe it's not a good question but maybe we can ask how much delay do we

think acceptable like in when we CFI did uh the estimation was like two months then let's say we're going to delay PBS for two months I mean Glamsterdam then do we think that's Okay. Like, yeah. Can we get some frame that fossil is fine as long as it doesn't delay up to X month?

Or do we even need that? So 3 months would be the Glay and

Yeah. Well, I can give a personal opinion, I guess. Uh obviously a bit biased, but u uh no, we we've had actually quite a lot of discussions around this internally. I guess DF and I would say opinions are split. Um, and yeah, as I already said, I guess like on ACD or whatever, but um there are some uh researchers and devs at the end that just like really want to um ship on a like very regular strict cadence.

um and others that think it's fine um delaying a fork by a bit um if it's to include like an important feature. I sit like in the second camp I guess but it's not like a very popular opinion I guess yeah um my worry is that and and so yeah I have to say the I guess the more consensual like more broad broader like opinion at DF is to ship fossil for the H star fork. Um, but I I do think there's just like a lot of uncertainty when when take

talking about like future forks. I think we've we've seen that in the past. And yeah, I I I always basically think it's completely fine, you know, if we come to the H4k and for some technical reasons, uh, false is not the priority anymore and then it's delayed again or whatever, like that's all good because um because it's a technical reason like it means priorities have shifted and core devs and like the community like thinks it's not as important anymore. Um but yeah, as I said last time, I think there are um nontechnical reasons that could also affect uh an EIP like like Fossil and

that's why my position is basically strongly um pro Glammsterdam um just because um I want to derisk it. Uh, and it's it's a hard sell because fossil is a very like defensive sort of like EIP like it won't really drastically change UX for example for users um compared to I don't know scaling EIP for example but yeah I want to derisk it so we don't end up like having the exact same discussion for um for future forks and maybe um getting into a point where it's

just like harder from like a I don't know political environment perspective, let's say, um to to ship it, which would be a shame because then it wouldn't be for technical reasons, but yeah, I've said this already. Um, does anyone here like have like other arguments? Because, uh, I feel like we could also like go back to maybe like some technical decisions. Uh one one thing I said that

was yeah I think interesting is like what do you guys would you guys agree that um like repricing EIP should be implemented by the E folks after sort of like EPBS and BS are like stabilized which would give us maybe some time um to ship fossil or is that just not the right way to think about Yes. Do you have an idea like or anyone else?

Yeah. I was thinking about like do I have any good answer regarding uh the question of repricing EIP and that was the moment Justin came in because I asked him about like what do we want to prioritize when it's when it comes to repricing versus fossil. yeah, honestly I don't have a good answer to that question. Uh but if I were to share my thoughts on fossil in Calamsterdam um of course you know like I mean it's

also I want to see fossil in Amsterdam because the community has been signaled strong preferences for fossil inclusion and I think the main argument against fossil is that it will going to delay the fork which is true but I believe majority of people agree that we want fossil um so let's have it in heka but I think the same argument would be applied in heka as well it touches both layers it's not [snorts] crystal clear which of the three goals it belongs to the interaction with the headliner whatever that be is unknown so

we should have in let's say I fork um but the thing is the later we want to have it the more difficult it will become and I'm in a camp that um I believe we all want to add more value to Ethereum and yeah basically I just think that having fossil Amsterdam is a way to achieve it. Um but we al also need to consider other EIPs such as repricing and when it comes to that question I'll defer others to you know share a good opinions on it. So yeah maybe I don't know maybe E defaf here could provide us some insights.

So, um, I'm Justin from the basic team, ELDev, right? And I think that the comparison between fossil and gas repricings, I I don't find I don't find them very comparable, [clears throat and cough] meaning that they provide wildly different things and they are difficult in very different ways. meaning that fossil is difficult because it has to be done on both the EL and the CL. Um it it has some interactions with EPBS. EPBS makes it um a little bit easier, right? Um gas repricings on the

other hand um can be shipped in a lot of different ways. Um there's a ton of different EIPs. There's tons of different ways that you can bundle them together and they're difficult because of a scheduling and testing burden. They're difficult to schedule because they can be grouped in different ways and those groups interact with each other in hard to reason about manners. So, for instance, we're supposed to on Thursday have a list of EIPs that are ready to go or that, you know, your team thinks should be included in Glamsterdam. And, you know, my team doesn't have that yet. And if we did put a list together, it would be very low quality because it's hard for us to

reason about all these different categories of gas repricing and how they might interact. That's going to directly translate into a testing burden when we try to ship the hard fork. So, you know, I I I don't find uh I don't find the argument that uh you know, there's no room for fossil because we have to do gas repricing very compelling. And if I had to make my decision today, I would prioritize fossil over gas repricing. Um because I don't I don't really see, you know, yeah, maybe the the the gas pricing today is suboptimal, but I don't know, it's been okay for a long time.

Um, so you know that's that's kind of my perspective. I think that the only arguments that I've heard for gas repricing are that well this is a scaling hard fork and it's thematically consistent. Um, I don't find that compelling. We can do you know multiple things um at one time in one hard fork. Um, and I think scaling has had plenty of developer attention over the last you know three years or so. So uh end rant. Thank you for coming to my TED talk.

>> Thanks. I think that was interesting. Uh thanks for sharing that. Would you Okay. One one thing I need I needed like like maybe some clarification on is like is it true that we like EPBS and BLS like need to be in their let's say final form and and sort of like not shipped on mainet but you know like actually stable uh before we can even consider doing the testing for repricing EIP because you know you you shift the for with with the VBS at least you you you do change the the slot structure and the time allocated to execution propagation and

everything. So if you really want to fully sort of like optimize repricings for for EPBS for example, it feels natural but you'll set EPBS first and then do repricings. Is that the way to to think about it or >> I I don't really I I find those to be pretty orthogonal. I'll defer to POTUS on that. Uh, but I I really don't really see any inter relation to them. I think wanting to do gas repricings after EPBS involves is just a way of saying I want to do gas repricings as soon as possible. I I really don't see any interaction there.

>> Interesting. >> Um, I think in terms of uh block access lists and repricing, there could be quite a bit of interaction there. Um especially like around the testing effort like I think there's a lot of uh very kind of specific EVM edge cases and block access lists that kind of also depend on gas pricing. So I can see that certainly from in terms of testing like that would be a bit complicated though. >> But you don't you don't imagine being able to paralyze a block getting expressed in gas pricing do you?

>> No this is just talking about the sort of block accessless construction part. So kind of separate from the um parallel execution. Um just like uh basically creating the list of all the you know state uh reads access etc. Um and testing that is kind of very interlin with the the gas pricing schedule. >> H okay. I find that not obvious but I'll consider that.

>> Like I'm not saying it's insurmountable or anything. I just think that like there's going to be a for bowels and repricing there's going to be like a big testing effort and there could be some kind of complexities with that overlap. >> Yeah. Um, I mean personally I don't see that as a uh problem for Fossil. I mean like personally I see it as quite a high priority thing. So I I don't mind if it delays the fork by a few months but um we haven't really discussed this as a

team yet so I can't really speak as to what other people think. >> Okay, that makes sense. Yeah, thanks for for sharing. I mean okay there is an alternative world in which um fossil yes it is cross layer but like it's still like mostly lives on the on the CL by far. So I mean yeah if you you know if people end up wanting to include like a lot of uh gas repricing zip and those will actually take time um and fossil mostly lives on the CL maybe that's also an argument to um parallelize efforts between both um but uh

yeah because I I do think fossil is quite minimal on the on the E side of things Um just a dumb question. Um is there a will there be a added complexity coming from a um over overlapped testing surface between bells and fossil? Um, I mean personally I wouldn't think too much between bals and fossil cuz yeah I mean fossil is mostly CL right

and from just off the top of my head like I think the kind of code changes don't touch most of the same stuff. >> Yeah take part please. Yeah. So I have a bunch of like random comments. Uh mostly personal opinion. I myself want to see fossil protocol. It I think it's it's the property that blockchains provide and and we aren't providing sensors resistantship at the moment. So I do think that this is urgent to have in protocol. Uh I also think that uh some some some objective comments uh we it's clear that most core

devs if not all core devs want to have fossil protocol. It's uh also clear that uh it interacts in a highly non-trivial manner with current EPBS for the current fork and uh if there is some kind of consensus in having shorter slot times in the next fork. It also interacts in a highly non-trivial uh way with that actually might be the case that one would make it impossible for the other PR. So I agree with Thomas that uh it is at at a at a point it is just a political decision of whether uh it should be included or not.

[clears throat] Uh so it's really a matter of like saying what are the priorities but it should be clear that it could be the case that having uh shorter slot times makes it impossible to have fossil or it could be the case that having fossil now would make it impossible to have shorter slot times. uh and I think we should realize that this is the situation uh or at least not the numbers that people are talking about we have in six seconds slots. Now as for the complications of implementing and testing this uh I have no clue and I cannot speak for the EL teams. uh what it's really clear is that the the big overhaul of fossil is on the CL side and and it's more than just the

the the gas repricing and these kind of things where the ELES can start working already. On the fossil side, we're very far from starting working already. I just saw the PR open on the EPBS side a few days ago when I saw it. It was just bare bones and was lacking a bunch of things. So, we're in the fossil side. We're really at the drawing board. um we're really at the specking board. Even EPBS, the spec for EPBS is not completely closed. There are some changes to purchase that are still needed to add. Um and so I think it's we are far away from being in a situation where we can actually say yeah this I mean you can you can you can guess 3 months, two months, whatever it is we know that those timings are never going

to work. Uh whatever we say now, yeah, possible is going to delay for two months, for 3 months, it's just out of nowhere. those numbers are out of nowhere. We we have no clue how we're going to start testing these things and especially both EPBS and Fossil are timesensitive. We need to set up some timings and we need to test uh in a decentralized manner. We cannot test on a devet. We need to test on a large test net to even set those limits. And after we test, we're going to find out if it if they actually works. It might be that we we just don't have the space to have this uh these messages floating around.

So, so we need to admit that it's going to be complicated to test. It's going to be a lot of delay not only of APBS but of shorter slow times and we need to be clear about what are our priorities. My priority would be to have fossil uh regardless of any kind of delay. On the other hand, on the political side, I believe that client teams are already working on fossil and they will work on fossil regardless of whether or not So and people are not delayed on this. I mean there's more people there were more people implementing fossil a few weeks ago than people implementing EPBS. So I would expect that whatever happens on ACD Fossil will get implemented on top of EPBS anyways.

So I think it's it can be realistic to continue working on this and whenever we actually have an implementation uh pressure to have it included immediately. Uh I know this is not something that people like but uh but I do believe that this is the thing that has the most chances of passing. >> Okay, thanks. Um I think uh yeah there are a lot of points. Um, one of them was uh that I'm particularly interested in is uh also like why do you think uh six shorter slots uh might not be possible

to ship with the VBS? Uh because I I wrote something that makes it unlikely, but uh I I I was just wondering if you have like more thoughts on this. No, no. In EPBS with EPBS, I think it's possible. Uh it it's harder than with the current slot structure, but I think it's just person perfectly possible. We we did test already with the Nethermind guys uh six seconds slots, and it was more stable with with EPBS than without EPBS. What I believe it's a complication is to add fossil on top of it because it adds different deadlines and we just don't know how those deadlines interact yet.

Okay. Yeah. I mean I I agree but like not knowing exactly how the deadlines will work out but like the thing I shared which yeah I think you you read at the time um means like basically the worst case scenario we can get into between Fossil and EPBS but also between Fossil and and shorter slots is that you might have um transactions in the inclusion list that are already included. So like so not like the freshest inclusion lists ever basically but that would probably be the worst case. Um so it's always best you know to have like

the freshest inclusion list based on like the latest head and whatever. But I I do think that if you even if you reduce sort of like the slot time and you have like tighter deadlines for EPBS and like um how this interact like the worst case scenario you can get into is like not having the freshest which is in my opinion fine like an okay trade-off to have to have but so yeah I just want to make sure like that's sort of like um the right way to think about it because if it's the case it's it's different than I'm not saying, you know, they can't be shipped like one can't be shipped without the other. Um, so yeah.

Okay, nice. Um, cool. Uh, and then about messages going around. Um I I yeah I agree it's hard to predict exactly but like you know like at the end of the day like the whole sort of like inclusion list like 16 inclusion lists make up for like one blob of data that's going through the network. Um and I think yeah nodes can afford that uh for sure. and how far could you reduce slot times without breaking fossil? So what I'm saying is like uh what I think but like yeah I mean we we can spend time on it

and like um iterate a bit more. What I think is like no amount of um slot times will break for because it just it just will mean that you have slots that update faster than you can produce uh fresh inclusion lists. Uh which is not ideal because it just means like the a lot of like transactions in the inclusion list will already be included. But I don't think it's terrible. Um yeah, at one point I do think it might break, but like that's my view on it.

Like I don't think um yeah, I I I don't think like you can break fossil in a way like it just like fossil will be a bit less efficient in a way because it won't only contain transactions that have never been included in in in previous blocks. Um yeah, medie. Yeah, I just wanted to add that um maybe we should not reason with the uh by the [clears throat] time estimation uh and delays. uh maybe we should remind the contributors that uh uh about the the the EIP process itself which uh if I

remember correctly uh was reviewed a few months ago and we said that for an EIP to get testified it should have some working implementation and that's definitely the case today for Fossil we have many CL and DL implementation so that's a good point and another thing uh in my opinion opinion uh delaying fossil would also make it uh harder to uh to include in the future because we will end up having some uh state branches uh and diverging branches and it's already with EPBS it's getting hard like to to rebase everything on top of it. If

we keep delaying it we will just add complexity like on maintaining the for implementation. So maybe we should also uh emphasize that and remind the contributors that yeah fossil checks all the boxes like to to get SFI. >> Yeah, 100%. I think that those are like great arguments too. Um yeah, thanks for sharing and then I yeah I guess I also agree

with that I I mean I I also happen to think that that s like permissionlessness and censorship resistance or like I guess inclusion rights um are basically the one of the super core property is uh blockchains provide generally. So I I feel like yeah we shouldn't make uh we we shouldn't think too hard about this one but uh but yeah I think it's it's great like those are like really good arguments. Um yes.

Oh, I have h a comment a request that surely will not be popular in this crowd, but I think this is the right crowd to make this request. There are some components of fossil uh on the E that uh if ACD decides not to SFI fossil. uh I would want to ask EL clients to any ways implement them and we can adapt uh those components for EPBS if there is a transaction that is actively being censored. I mean that's part of the of constructing the inclusion list. The EL can find a transaction that is being censored and can notify the CL that there is this

transaction that should be included. And EPBS allows for any validator to blacklist immediately all builders when there is such a transaction. So if if I see a builder that uh is not including a transaction that my E is telling me that transaction should have been included vanilla software should be able on EPBS to not call anymore that builder and I think if uh Fossil doesn't get accepted on ACD we should push to have at least this already implemented in the L clients because I believe it's already implemented in the L clients and for EPBS it would only require a change in the engine API.

That makes sense. I don't think that's a controversial statement to make. I mean like everything that can improve sensorship resistance I think is good. The I think one yeah I have to think a bit harder. I I feel like uh the default for a lot of people will just to um I mean we haven't seen like any sort of like big push back when builders started censoring um transactions in the past. So I feel like leaning on reactivity uh for you know big for example validator pools or whatever to to change their behavior might also or

or would you suggest it's like a default thing that triggers automatically like I don't know how you think about it like will you request an actual action from uh the validator that wants to disconnect from a builder or would it be something that triggers is triggered automatically. >> It it it should be something automatic. If you see a transaction that wasn't included then by a build and so because the problem before was that we didn't know who the builder was. So you couldn't disconnect because the relay could be saying uh could be anything could could give the block to anyone. So we had nonensoring relays in which sensoring builders were winning the auction. Uh what changes with the PBS is

that now anyone can see not only the proposer but anyone can see who's built the block and they can know immediately that they built a sensoring block. So if the EL is telling you that builder there did not include this transaction just don't call it anymore. I think this should be the default on clients and yes might people might want to fork it or we might even see push to have a a configuration flag to change this and yes this is not as strong as possible of course but uh defaults stick and I think this is a good default to have anyways.

>> Yeah, I agree. Um yeah yeah know I think those those make sense. I think defaults are sticky as well. Uh which is also why I was pushing quite hard against having like an optin fossil thing. But um yeah, I think that the only other thing you would do lose is like the not having 16 people uh doing that and just like relying on your own sort of view. But yeah, always better than nothing. I don't think it's yeah controversial at all. I think everything that can be done to improve this like current state of things should be done basically but that's something that we can also

try even we go PBS with fossil right even if we don't I mean Like even if we decide to DFI fossil, we can still use this component in the PBS as you described. Replacement. So as a Okay. Right. As a as a as a replacement. You mean? Okay. >> I mean, yeah. I mean, it I I agree. it's not a fossil replacement and it's not as strong at all. But like I mean maybe there could also just be an IP drafted for it. Uh the only problem there is

like obviously won't um be compliant with um some of the arguments that were really good I think and made by by Med that it won't be you know tested or have anything sort of like uh yeah it will be very new and very fresh but also not not that complex. So I don't know Gotcha. >> Was really great to have um Yeah. Um Niko, do you want to share something?

>> Yeah, I just want to know if there's a difference to the current should override builder that we have. I mean, I guess in EPBS you could say, okay, the previous builder was censoring, so you blacklist that one. But what we have right now is we would just fall back to local blocks if the E returns true for should override. But I just haven't seen good adoption from the E side on that. I'm only aware of Nethermind having this behind the feature flag. >> Yeah. So it [clears throat] should be it should be different. It should that that flag there is when you request a payload uh to propose yourself and then the the e tells you there's censorship going on

just build your yourself what I'm thinking is a different one which is already part of fossil itself is when you send a new payload you're syncing a block part of sending the payload the reply instead of like being just accepted or syncing or valid should be uh accepted sync invalid but it was a sensor a sensoring payload and that's it. It's just a boolean and your EL has free rights to decide this payload was sensoring or not and the CL can take care quickly out of that. So you just send your payload when you're syncing get the fact that it was a sensoring payload and you know you you know who's the builder is just blacklist that

builder immediately. So, it doesn't really need an EIP either because it's uh just on the on the engine API. It's not part of C core protocol. Uh we could write I could write an EIP for this, but uh it's just changing the API. All right. It might be a good mitigation we might want to have when we decide to DFI fossil.

Um, so yeah, it's really great to have many opinions and perspective on the table. Yeah, if we decide, uh, let's see how it goes. Um, we're almost heading up 1 hour. Um, does anyone have more comments, feedback, or thoughts to share? Uh no just thinking about produce idea then there would still basically need to uh yeah come up with like a good huristic to determine a transaction with

some sort because um it's also you know it's not an objective criteria. It's not like it's not like a label is attached to a transaction. it's more like it's been pending in the main pool for x amount of time and hasn't been included. So, um there will be tool to to a bit more thought about like the huristic people may want to use but yeah just a thought. Yeah, that sounds like a possible strategy.

Um, all right. Um, do we have any other comments we want to have otherwise I think we can go ahead and wrap up this call. Um, all right then. Uh, thanks for joining everyone. Hope you have a great rest of your day. Um, as always, I'm going to share the summary of this call, but I'm not going to name names on the opinions addressed in this call, so you don't

need to worry about it. Um, yeah, and let's see how it goes in the upcoming AC/DC call, which is on November 13th, if I'm not wrong. and let's see you in two weeks. Thank you. >> What's up?

>> Thank you. [music] Heat.