 Okay, so at any, let's get started, let me drop the agenda in the chat. Okay, so welcome everyone to the Merchant Blamere skill number five. Let me turn off my video first, okay, so yeah, we will try to finish this call like five minutes before the top of the hour to let people have a break before the next call. So yeah, I think we can manage to do this. And let's start with implementation updates. Does anybody wants to, I know that there is no active implementation at the moment after anism? Most of the client developers are busy with the hard forks. So, but anyway, does anybody have anything to share regarding the implementation update? Okay, so I would like to highlight a couple of things. First one is the, there is a PR to get repository. PR by Gary. I'll just drop it here. And yeah, this PR contains some a bunch of changes and what matters like a lot in this moment of time is the transition logic implemented on the catalyst side. So, we can like, if we have like, when we have this logic implemented on the big and chain client side, so we can do some testing locally and do some probably semi-public dev nets and this stuff. Also, there is a work happening on the state sync as well. And this is what I would like to ask a GIF team about. Does anybody can speak on the progress regarding that? What is happening with the state sync implementation? Not really. Peter was working on this, but yeah, he got sick and I guess he got distracted. I'll kick him about this specific topic. Otherwise, yeah, there's the PR by Gary that got tested during rayonism and works. Right, so it should be integrated soon, but yeah, regarding sync, I'll get back to you. Cool, thank you so much. Yeah, sync is not like the top priority at the moment. The top one is the transition process, but it will be a number one priority pretty soon. Okay, if there is nothing else to implementation updates, we can move on to the research updates. And here we have the PR with the transition process. Yeah, this is like, let's say this is the implementation of advanced transition process where we compute the transition total difficulty at the moment of marriage fork. So instead of predefined in this transition total difficulty at the client deployment moment of time. So I would like to, yeah, I'd like to encourage everyone to look into this PR. And yeah, hopefully it will be merged like in a week from now. So it will make sense to start implementing it on the big chain side. There is a bit of debates on how in particular this logic, this total difficulty should be computed, but in general, I think there is the rough consensus around the approach. Yep, does anybody want to ask anything here or add to this topic for the transition process stuff? Did we want to talk about how the difficulty offset is calculated yet? Or is that for later in the call? Yeah, I think we may talk about it here and continue offline. Okay, so the general idea is to compute it at the moment of when marriage logic is enabled and the code on the big chain is been positioned into the marriage fork. Here we have like two ways of computing the difficulty. The transition total difficulty. First of all, we take, we are computing it based on the ETH1 data. We take the block that the recent ETH1 data in the state contains, and take its total difficulty and add in some offset to it. Like the offset will be roughly about a week worth of difficulty contributed to the network. And here we are, we have this number and we are waiting for it to start to kick off the transition process. And yeah, the discussion is happening around how to compute this value properly. So one of the ways is to just take some number and configure and reconfigure it within the client code deployment, like which will happen like a week, probably a month before the computation actually take place. And yeah, do it this way. The other one is to take the difficulty of this particular block that is referred by the ETH1 data in the state and multiply it by the number of blocks that we are expecting to happen in the next week. So these are two ways, like the first one is, yeah, the first one is, to my observation, is like more conservative and we can use our like expert or I don't know, use the information and yeah, our expert opinion and defining what will be the lowest safe or what will be the safe total difficulty of set after the merge that we would, after the merge of work, which we would like to put in this like period of time to the transition process. The other one is to take the difficulty of the network. Yeah, and use it to estimate this period of time. So the one, yeah, the one is like more conservative. The other one is like more predictable. We also want not to have the merge in the weekend or some kind of stuff and to make it like as close to one week as we can. So yeah, Vitalik, do you want to add anything here? Yeah, interesting. I actually consider the second one to be more conservative. But I guess the difference is that for the offset, so this is like the amount, the total difficulty that's going to allow it to happen between the one block and like the terminal group of work blocks or the last group of work block before the chain becomes embedded. Like it's going to get computed based on some formula and the question is like, well, so I think there's two questions, right? So one, the first question is, is that formula going to be a formula that like we just, we ask for developers' views and to come up with a number and then we put the number in the client at the time that we distribute the clients to people. And the second question is then like what formula is that, right? So like a simple, like I think in both cases we would expect the formula to be something like take what we think the difficulty is or is going to be at that time and then multiply it by the number of blocks in one week. So the issue that I see with like pre-calculating it is basically that if you pre-calculated and you just like put the results as a number into client code, then that like you're relying on information that's like at least three weeks older than the actual fork. And so like between that time and the fork, lots of things could happen, right? Like the difficulty could go up by a factor of two, it could go down by a factor of two depending on prices, things could get fairly volatile. So like there are like basically making a decision earlier when you have less information is something that just intuitively seems to have like more risks when making the decision by just putting it in protocol. So the formula executes like at exactly the merge time is more up to date. I guess like the best arguments that I've heard or thought of against my proposal, which is to calculate the offset in real time, it happens if miners manage to coordinate and like they all or most of them turn their miners off for like two days before that particular point of calculation. So and you know they make the difficulty go down by a factor of or I guess you know what they would want to do is they would want to bring in a huge amount of extra hardware temporarily and well they could do either one, right? They could push the total difficulty, the remaining difficulty either down or up and then either make the merge happen very quickly or make it happen slowly. So it's more like having a better estimate versus being more vulnerable to attacks. Like I guess that's where I see this rate off as being so far. There are also hybrid options, right? So like one hybrid option that I suggested for example is the option of like just making it be the minimum of some fixed number, which we can calculate at client deployment time and the difficulty of these one block multiplied by a week. But I get the same time. I don't think I hear extremely strongly about the difference between those three. I think like taking the minimal difficulty at the point of deployment, right? That was what was suggested. Yeah, I think it could also be it also prone to the same issues like the difficulty at the point of merge logic enabling. Right. Well, the attack if we have the minimum of like pre-calculated difficulty and difficulty in real time, then the attack's worse. The thing that seems much harder, like how do you even manage to just like quickly bring in like 200% more hash power? But yeah, another way of doing this minimal is say the difficulty is to put some constant, right? So why am I thinking about the make it constant because we can estimate the or can we estimate the entire hash power that could be put onto the network? And we can get something out of it instead of relying on the network condition on the network in the moment of time. Right. I guess my view is that like we can't do that. But if we have the one that might not just put that formula into the code and so we get the formula and more updated information. Okay, so does anybody want to know? I'm sorry. You've been breaking up, Vitalik. Yeah. You keep cutting that out. You sound like a computer from like the 60s. Am I still okay now? We can hear you now, yes. Yeah. Okay. So I'll just say more advanced formula before coming up with the same issues. Okay. I'll just type. Walk up a taller building. Okay. So does anybody want to add anything to the discussion? And just a quick point of clarification. If the miners hypothetically all turned off for two days, that would move the merge and then turn back on. That would move the merge closer or that would push the merge further away? No, it will move the merge closer because we take the lower difficulty as an estimation. Right. If you dynamically calculate at that point. That's why my point about having like minimally safe difficulties. So we can take the value, we can take like the value from the network at this moment in time. But it can be lower than some safe merging. So if we see like this goes down, the hash rate goes down significantly. We have a cap, we have a lower cap on the lower boundary that we take for estimation just to avoid this kind of stuff when the difficulty, when the hash rate goes down significantly and then goes up significantly. But we already set with these computed total difficulty threshold. So the one problem with that, and maybe this is an acceptable problem, is that it's possible, hard to say possible, that the total hash rate will decrease as the merge approaches as people try to sell off their hardware before the rush of selling off their hardware happens. So it's possible we will legitimately see a crash in the hash rate that does not return before the merge. And so if we go with that, I think we just need to accept that it's possible that we could end up having a very delayed merge because we hit a minimum and hit that minimum value. And then, you know, now we have to wait for that difficulty to be hit, which may take a while because half the merge, half the hash power sold off all their hardware two weeks in advance or whatever. Which would happen if we set an offset anyway. Like if we set an offset, like a fixed offset that was based off of what we thought the hash power was at that point, then it would also do a delay. Can we provide rewards for mining for a few months after the merge? However strange it sounds, can we like delay the time when it stops being profitable to do the hash rate and just execute some something like that chain that just provides the rewards for mining blocks? We talked about this a lot. As I mean, it is an option that would kind of realign incentives a little bit for certain problems. I think most people seem to agree at the time that the complexity of implementing that just wasn't worth the gain. And maybe it's we can reevaluate that. But at the time, at least that was the primary argument was just a lot of complexity and we get a little bit of benefit. I mean, if it gets delayed by like more than a week, then it will also be easy to during that time coordinate like to make it about a week again, right? Yeah. I mean, if you needed to cut new releases that do dash dash transition difficulty and then put a number in, you could. Well, or you could just make it generally like a parameter that's easy to tune. And then just say at some point, hey guys, it's changed. Yes. Like what do you input? So I worry a little bit about a command line parameter that is a consensus rule that we expect people to change just because like for miners, we assume or at least for my pool, we assume they actually know how to do that. I do worry that we kind of, we want Ethereum to be accessible to the average person. And the average person who just double clicks on another mind probably does not know how to configure it via the command line. We can teach them, but they could end up being a pretty big undertaking. So if possible, it'd be nice if we can avoid requiring command line arguments to have emerged to be successful. I mean, to be clear, this would only be like a fallback if the worst happens basically. Hey, that's true. Like if as long as we believe the chance of the fallback being is needed as low, then I guess that's, you know, better to have the safety net there than not. It'd just be really nice if we can try to avoid depending too much on that, like as being a, oh, this will just work fine. Like, I think it should be more like, we have a fallback, it'll probably lead to a bunch of fires and things not working great and things breaking, but it's better than the alternative. I mean, we anyway probably need like a fallback for kind of a forced merger. You just agree on a block in case minus actually do an attack, right? So I feel like the attacks actually have, the fallbacks actually have great advantages in that they really like make it very unattractive to attack when you can tell people, hey guys, like if you do it, it's not going to work. Right. But yeah, it can't recover. We should understand that this way it will not recover the attack outcome. It will just accelerate the merge. I mean, in that case, if you're going to have a parameter, it actually makes sense to make it the other way around that you can't run the software without the parameters that are pre-tested. Otherwise, it will be like one of those things that people think will never get used to don't bother learning it and then if it's needed, nobody will know how to do it. Yeah, I agree with the sentiment that it's, if we make them, that guarantees that we don't have a fork or a degree of chance of having a fork to a very small number. What I worry about is we might drive away those users that we're trying to, like we keep talking about stateless and all these things to attract novice users to running Ethereum themselves rather than relying on inferior and whatnot and adding clan line parameters is a great way to drive away, you know, the mom and pop user that we're kind of at the same time trying to encourage to run the software. And I know we're not doing great at getting the mom pop to run the software, but it'd be nice if we can avoid introducing even more hurdles for them. Yeah, okay. One thing here is that even, okay, if we compute the total difficulty, like on the fly, so we might want to have a mechanism to, like, check this, the computed value. And one of the ways is to communicate the transitional difficulty of chain and to allow for place validators and users to check that this is what they get on their local nodes, just to avoid any kind of failures with regard to wrong computation. Also, okay, with that, like, do I understand you correctly your statement that if we want, if we need to hard code whatever parameter in this formula, then we better fall back to the hard coded transition total difficulty that we have been discussed before. Yeah, sorry. I don't know. I don't really feel like I have to burst. Okay, I see, okay. Well, let's just continue flying. So I encourage everyone to take this PR. Yeah, this is the important piece of the merge. Right, and the tricky one. Yeah, we can actually hear you now. Okay. I guess, no, and I was, I don't know, I don't really feel like I have very strong opinions on this. I feel like it just wants to as long as, you know, users have to be online options that they can just like to use as a that it should be. Sure, I take it to the issue. Okay, I need a conversation there and I don't know something. Yep. Okay, so let's move on. Any other research updates? Okay, so one thing I want to give a heads up about consensus API. We'll definitely get back to this discussion again. But I'd like to prepare some documents or this kind of stuff. I've been thinking about it in my spare time. And I'm leaning towards that we get the duplex communication channel is almost a requirement for this kind of communication. And yeah, we can use web sockets. Yeah, but let's just speak about it later. They're probably like a new type of message that we'd like to introduce into the communication protocol. So this kind of things will happen soon, I guess, after transition process PR is merged. Okay, so let's move to the discussions. Really quick question on the two way communication, the duplex socket. Does it need to be trusted by both sides? Or is it still only one side owns the trust of that really relationship? I mean, like, so yeah, the execution client trusts what has been sent from the consensus, right? But yeah, and we may yeah, I was also thinking about the restore after failures. When the clients exchange messages like what is the, like the hot block at the moment, do they haven't probably like, we can change client will have to rewind some blocks and feed them back to the execution client. And yeah, so yeah, I know, probably requires some trust as well. So we'll see. It also depends on the use case, I guess. If it's like the service that provides the execution client stuff, then yeah, you don't want to trust service or service don't want to trust your consensus node. It says this client. So yeah, need to think about it now. But it definitely a bit more complicated than we have, than what we have now. Okay, let's move to discussions. First, there is a short, there is a proposal by Justin to remove the execution payload header. Justin, do you want to speak about it? Do you have Justin here? No, sorry, what? I think he left any. Okay, so yeah, yeah, I think definitely the current discussion point is interesting in that this in statelessness all of a sudden becomes a much larger object, which I don't know if there's much value in keeping in state, although the most recent header you're probably keeping around. I mean, most recent block you're probably keeping around anyway. But yeah, I don't feel super strongly about it, but I might go would be to just put the header in there. Yep, I understand the sentiment that there is already a lot of block related structures, and block header, block body block, and the pro block header, pro four block header, and pro four block body, and we have execution payload and execution payload header. So the idea is to simplify. It's a bit and have just execution payload, but it implies that the transactions of recent block will distort in the state. So we use the execution payload, we put it inside of the state and it depends. Do we want to make this trade off between simplicity of implementation of the spec and additional space in the state? So currently it's like one and a half megabytes at max. So it's really negligible. By the way, what is the current state size, the weekend state? It's dominated by the alligators, right? So it should just be 150 bytes times the validator count. So it's times about 300,000. So it should get us to about 45 megabytes itself. And then I think everything that's got the validators is it should be a couple megabytes. Yeah, right. So it's like a hundred megabytes if I'm not mistaken, like at the moment. And we'll like five times larger if we have. Right, but it also the validator set does not change a lot state to state. And so if you're deduplicating and you're keeping like say an epoch worth of states in some sort of tree structure, then you don't actually have to duplicate the validator set at a time. Whereas this entire block payload changes every block. And so that would be like something like it's in statelessness like a 10 potentially 10 megabyte, five megabyte diff on each one of these like tree back states. And so all of a sudden you actually have a lot more in memory that you have to store. I can write that in the issue. Right. Are we even going to try to make that even block execution state list though? No, no. This is Justin suggesting putting the entirety of the execution payload in states at each slot. Like he's the most recent rather than some sort of like header. Yeah. You're breaking up, but what you get out of that is you don't have another object, which is actually from payload heather. And you essentially have value by having transactions readily available. But I think that the way the state diff ends, the way you want state and memory, I think is going to probably not make that a good idea. So can I add something here? So the execution payload, if we embed the transactions in these states, they can do these types of transitions that take more than on block. And so if we do end up with some kind of MFE protection, then I think we need this kind of look back to the previous block, or at least this could help. But then regarding state size against us in, it would just add a lot of noise through the begin state format itself that should change every block and would basically just hurt and duplicate a lot of block information. I think especially as Justin's been here, we can just take this to the issue. Right. Yeah, so looking to this PR comment on it, let's discuss and revisit it later. Okay, let's move on to the last point of the agenda. Right, not last, but anyway. Difficulty upcode and randomness after the merge. There are two aspects here. First one is the difficulty, which is like easier to work with. The other one is the block hash. Let's start from difficulty one, and if we have a time, we can discuss the block hash as well. Okay, so the difficulty upcode currently returns difficulty. Obviously, we have already a constant for this, for the difficulty field in the execution block for after the merge. But since it's a constant, and some of existing applications already use difficulty upcode for in their source of randomness. And yeah, usually it's like difficulty plus timestamp probably block hash, but probably some applications use just difficulty. And yeah, by setting this parameter to just a constant value, we'll break the logic of these applications. And what we can do here, there are two ways. First one, which is desirable is to rename difficulty upcode because it's going to be obsolete soon to some kind of, to the random or random, and pass the most recent rundown makes from the big engine side to the EVM. But this is more a long-term solution because it requires the change on the EVM layer on the EVM level, which we're trying to avoid for initial merge. And for initial merge, we can do the following. We can just borrow a few bytes, like eight bytes, first eight bytes of random mix, and put them as the difficulty parameter into a block. And yeah, that's how can EVM access this difficulty as a random, as some random value, not as a block difficulty after the merge. So here we are, here we have like the dilemma, which way to go. So my preference, actually, yeah, I prefer the simplicity. And this is the latter solution, the second one, with the difficulty field set to the rundown, to the value derived from rundown. But probably there are some other opinions on that. Let's discuss, let's think about. Why do we care about people who didn't follow the advice of every security expert in Ethereum since 2016 that said, do not use difficulty for randomness? That's a good question. Do we need to take care about those people? The same we can address to the block cache usage, right? Yeah, it's basically the same argument, people using block cache for randomness. Every single security expert says, do not do these things. It's blog posts, solidity, everywhere. There's warning signs. Don't use these for randomness. And there are still people, of course, who don't listen. We can't stop them. But I don't know if we need to protect them and keep them functioning. I guess that's what's going to cause us to work in pain. Right, but okay. So yeah, the default option is just do nothing and set difficulty to zero or two, one, and to some constant value for the third option here. Why we would, I don't know, we want to give the application, we want to give the ability to have a real randomness like moderately strong randomness, which we have on the consensus layer to the application layer, right? So we have this random stuff. We want to provide it at some point in time in the EVM and like we can, as I said, we can use the difficulty up code, just rename it to Randall. And this first step, I don't know, if we use this interim solution, so this is going to be the first step towards this way. That's just my thoughts. Yeah, although I don't feel like we necessarily need to protect applications that use it poorly, it's not a bad compromise, I think, to rename it and insert something that is pretty random into it. I mean, that would break your things. Yeah, go on. Would the rename actually be a consensus changer? Is that like just like we start calling something different in docs? I think you start calling it something different in docs, and you put a new source of the value, which is the Randall. Gotcha. I mean, if that's from an engineering standpoint, if that's like low cost or easy, I think that's fine. Like my main concern is I just don't want to add extra engineering just to protect those people. But if it's like, hey, we want to give them randomness, and this is a good way to do it, and it's very little engineering effort, then it seems like a good fit. Okay, so if we follow this way that you've just described, so we then we do nothing at the merge, we use constant for difficulty. And then when like EDM changes are coming after the merge, we implement this scheme with renaming difficulty to Randall. All right, I guess the funny part there is that you end up with a not insignificant stretch of time where everything does break. So all the lotteries, all the ERC-20 horse races do break, and then they unbreak. Just for like three or four months. Just don't go to the tracks for three or four months, that'd be okay. I really don't want to break anything, actually. Yeah, I mean, from that perspective, if you have like the stepwise, it's totally broken. I think it's actually maybe better to break it once and don't unbreak it. Like this is deprecated, this is now returns to value one, and then give a new opcode, just because the unintended consequences of having essentially lotteries break and then unbreak is a harder to read about than just then breaking. Yeah, it would be nice if we could reuse opcodes though, like we do have a finite set, and we can extend that theoretically by doing too late opcodes, and we aren't running out yet, like it's not like we've got three left or anything, but it'd be nice if we've got a thing that we're not using anymore to be able to reuse that in a way. Having specialized opcodes, they're just like push the number zero and push the number one, like it's not the worst. It reminds me of how well buyers feel at all. I required incoming transactions to send one way, so they could use the value opcode to push number one and that saved them 500 gas, like if we make difficulties in the number one, and people just have to use it for that, then why not? But then are we saying please, yeah, at that point we need to promise not to change it from being the value one, or are we all of a sudden saying don't use this for value one? That's a good question, because I mean there are people who do exactly that, like they push zero as the first opcode, so that way they can dupe it because it's cheaper to dupe it than it is to push zero, and so if you can save, you know, another three gas by using difficulties to get zero or one or whatever, they will do that. The type people that do that, that being said, the type people that do that are almost exclusively bought authors and their bots, you know, they come and go like weekly, so they're not the worst people to break, because they can upgrade very easily, like they switch contracts regularly. That being said, I'd rather have it return invalid, but then now we're talking about an EVM change, we're going to do an EVM change, why not just throw a random one there? Sorry, Micah, what was your last message? Sorry, like the ideal solution, if we're going to have it be like break it, and we want to reuse the opcode, would be to have it throw or be an invalid opcode during that interim time, but if we're going to do that, I believe that requires an EVM change, and if we're going to do an EVM change with the merge, we might as well put rando in there. Yeah, right. So like our options are put rando in for difficulty, or have difficulty now become the push one opcode. Right, right, right, okay, okay. Yeah, so anything else regarding difficulty? Okay, so the bulk hash stuff, this is just going to be broken. I mean, in terms of the randomness service, it will not be protected by the proof of work after the merge anymore, and we can't do here anything, because the bulk hash has its original semantics, and the semantics might be used by existing applications. Yeah, so we can change it to anything. Yeah, I just want to, if anybody hears us here, here's this recording, and they have the application that depends on the, is there difficulty or the bulk hash as a source of randomness, just reach us out in ether and d, or in other channels, so we can discuss it and see potential ways around it. Anyone know the answer to the first question? I do think that it's important, so I cannot leave these issues open for too long, because that just like risks causing delays because of the spec not being done. Does anyone know what CLIC does with the difficulty opcode? It's hard coded to two for an intent block and one for out of 10, like difficulties actually used difficulty. Oh, that's right, this just came up, right? Yeah, but CLIC is not used in production. And how about other EVM chains? I mean, we share all the tooling, so we better just try and align it. What do you mean? I mean, Ethereum is not the only chain with EVM, so if we mirror other proof of stake or proof of authority chains with these opcodes, that might just be best. Oh, yeah, yeah, good question. So, okay. Yeah, worth checking, definitely. Okay. If we're done with the randomness and difficulty, we can go to the open discussions. If there are no open discussions, so we can wrap up and jump on the other call in 10 minutes. So, what is the plan with block hash? Like with the block hash opcode, just returning the hash of the execution block itself? Yes. Okay, that's fine. Yeah, that's the default plan. Just do nothing. At some point in the future, we are going to have to break all of the old proofs, I think, because at some point, we would want to retire our LP and change the format over to some new SSZ-based thing, and probably at the same time add some more proof verification or pre-components that are more future proof. But I guess, yeah, that not problem does not have to be solved for the merge. Right, right. Before we end this discussion, can someone give a very quick overview of why it's hard, like a two sentence reason as to why it's hard to get Rando into that spot at the merge? To get Rando into the block hash spot, like, in difficulty, sorry. Right, right. So, basically, why we have to break it up, break instead of just immediately saying if block is an embedded block. Yeah. I don't know. In my head, I'm just imagining the consensus client simply sends over to the execution client when it asks it to build a block. It says, hey, and use this for the difficulty. And the execution client then just builds a block with that as a difficulty. Right. If we are talking about just, like, set the execution blocks difficulty field to the something derived from Rando, it's easier than take the whole Rando mix, give it to the execution client, and the execution client will embed it into the EVM and expose it. Why a difficulty of code? Just a quick question. When you say something derived from Rando, like, why not the Rando? Why do we need to do that with deriving? I mean derived, like, difficulty field is obviously six to bit long. And yeah. I guess, like, from a long term perspective, I don't really think it makes sense to have an uproar that returns, like, the last eight bytes of the Rando, because that would just be a redundant with the future uproar that we're going to need anyway that returns the entire Rando. Yeah, that's fair point. So the complexity is just to do anything with EVM at the point of marriage. That's it. Isn't the difficulty 256 bits? In the block header it is, I think. I'm pretty sure. I think it's what we have documented. No? Yeah, it's 64 bits, as if I'm recalling correctly. Yeah, the difficulty of code will return, may return up to 256 bits as in the other code, EVM. What you're saying in the block header, it's 64 bits. Right. Well, in the block header is RLP, right? So it could be any number, or is there a consensus? Oh, really? Is there a consensus for all the code that prevents it from being above 263? I don't remember. I don't think so. I mean, I'm going through my code that does block verification. Yeah. I know that there's other things that have been said to the 64 bit limits that should be, but difficulty sounds like the sort of thing that would do it if we'd be risky to cap, right? Even in the case of echoing, you already need more than two to 64 hashes to make a block. And if Ethereum was proof of work forever, we'd probably get there within a decade or two. If that's the only thing holding us back, then we should probably investigate to find out if the clients actually have that, in which case it may be a consensus issue, because it's possible that not all, like, like Gath, for example, has the nonce is 64 bits internally in Gath, but like consensus-wise, that is not a consensus rule. And so we do have known consensus issues, but they can't be reached. Difficulty is one that may be in a similar boat, but possibly reachable. Which is not a good thing. Yeah. Yeah. And yeah, that's, that's a good way of, that's a good thing to investigate and call. So we probably can just, yeah, drop this whole run down into difficulty field, right? Does that change the argument here? Let's say, hypothetically, that all, it is a 256 bit field, all clients support that. Does this seal the deal? And we just say, okay, put run down there, we're done? Let's say so. No, you mean we are done in the long term? Probably not. That's all right. Meaning we can, meaning we can put the full random mix into the difficulty field and we never have to change the off code again. Right. We can just change the way the rundown makes this transfer into the up code. I mean, yeah. Sure. Like we might have another mechanism of getting there later. That's a little cleaner than having the client send it with a request, but the gist is that off code will just be the random mix from merge on. Right. Now, so it's going to be mixed into the block hash this way, but it doesn't matter much because block hash as a random, as a source, randomness won't be secure as secure as it is now. Okay. Anyway, we have five minutes to the next call. I think we should stop here. Thanks everyone for dragging that out. Yeah, no problem. Thank you for sharing it. Okay, cool. So see you in five minutes. Thanks everyone. Bye bye.