Hello, and welcome to a screencast about finding all the zeros of a polynomial. So I have a third degree polynomial here, f of x equals 3x to the third minus 14x squared minus 7x plus 10. And the way I always like to start off these problems is, you know, taking a look at our polynomial, making sure I have all my terms in there. So I've got a third degree here, a second degree here, a linear term here, and then my constant term here. Okay, so that's no problem at all, because if you're missing a term, sometimes I can throw things off. All right, next thing I want to do is go to my calculator. So let me put my calculator into the screen here. And in my y equals, I'm going to go ahead and put this polynomial. So 3x to the third minus 14x squared minus 7x. Sorry, my calculator is a little pokey here, and then plus 10. Okay, now if we're lucky, we will actually be able to, we do a zoom in number six for my standard window. If we're lucky, we can actually see some of these zeros. And sure enough, I see it's crossing my x-axis here one, two, three times. Okay, so we need to figure out what those three zeros are. Let's take a look at the table and see if we get lucky and have any of them occur at integers. Okay, so I see one down here at five zero, because a zero means that your y-value is zero. So I know that one of my zeros is going to be at x equals five. Okay, bring that calculator back up. If I, let's see, it looks like those numbers are going to be getting big. So let me scroll up and see, sure enough, at negative one, here's another zero. So I have one there, but I need three of them, because it's a third degree polynomial. And it looks like that one's getting really big in the negative direction. Oh, and they're just going to get worse. Okay, so it looks like there must be something here between zero and one, because my sign changes from positive to negative. Okay, so this is where we're going to want to use synthetic division to then help us keep knocking back this polynomial. Okay, so I'm going to set up my synthetic division with my zeros. So five is one of my zeros, and my coefficients are three, negative 14, negative seven, and positive 10. Okay, bring down your first number, and then we're going to be adding. So bring down our three. Now we're going to multiply, three by five is 15. We're going to add these, so we get a positive one. One times five is five, negative seven plus five is negative two. Negative two times five is negative 10, and that gives me a zero for remainder. Good, so that's kind of my gut check. I want to make sure that I don't have anything left over, because if I did, then five was not an actual zero. Okay, so that means my polynomial just got knocked back to 3x squared plus x minus two. Okay, so this is where you now have options. This is a quadratic. You can use a quadratic formula. You can try to factor it, but since we're practicing synthetic division, I'm going to do synthetic division again, so I'm going to use my other zero here of negative one, and I'm going to now just use this new polynomial here that I have for my quadratic. So my coefficients are going to be three, one, negative two. And if you're really savvy, you could actually put these two pieces of synthetic division together, but since I have limited screen room, I'm just going to do them side by side. Okay, again, we're going to bring our three down. Now let's multiply. Three by negative one is negative three, and then we're going to add one plus negative three is negative two. Multiply negative two by negative one, we get a positive two, remainder of zero. Okay, so that means that my last factor here is 3x minus two. But remember, we're trying to find our zeros, so if I set this equal to zero, I can go ahead and solve for x. So move our two over, 3x is two, divide by three, x is two-thirds. Okay, so my zeros are, let me list them out over here nicely, five, negative one, and two-thirds. Thank you for watching.


A memorial service to say goodbye, hundreds gathered at the Camp Pendleton Flight Line March 2 to honor six of the seven aviation marines with Marine Light Attack Helicopter Squadron 469 lost in a Hilo collision during a training exercise near Yuma, February 22. A final roll call for Lieutenant Colonel Thomas Pedreco, Captain Michael Quinn, Captain Benjamin Sonegula, Sergeant Justin Everett, Lance Corporal Corey Little and Lance Corporal Nicholas Elliott, gone but obviously not forgotten as those left behind received their awards to be cherished with their memories.


Let's say I will assign the cost 10. Now the template is ready. And we need to set up quotas. So we have another CR, cost of template quota. I already have one where I'm allowing two instances of the DEF CONF cluster and the budget for this name space is 25. And I want to add another one. So I will allow just one instance of the demo template that we just created. So this is where the admin flow ends. And everything is ready for the users to use our template and so they can provision their new clusters. So now I can log in as a user on this cluster. And I think I'm already logged in. So let's check. OK, yeah. So that's my username user. And this user has very limited permissions on the cluster. So if I try to do OC getBot, I will be rejected if the internet will start working. OK, finally. So you can see I cannot get bots. But I have one project within which I can operate. And that's the debuser namespace. And the only things that I can do is that I can explore what cluster templates are on the cluster. So we have these three templates. The demo template is the new one that we just created. And every template has a cost. I can explore what kind of quota is in my namespace. I can take a closer look. So I can see that as a user, I can create two instances of this DevCon cluster and one instance of the demo template. And in the status, I see that I already spent 10 budget, right? And I have 25 maximum. And then what kind of clusters I already have. So I have one DevCon cluster and zero of the demo template. So let's try to create a cluster from the demo template. I need to create a cluster template instance. So I already have a cluster template break out. So every cluster template instance, in the spec, we have a cluster template reference. So this should reference the template that we want to use. So I need to change this to demo template. And then I can provide the parameters for the template, right? Because the admin allowed me to use whichever version I want. So I will use the 411.12. So let me change the template. It's called demo template. And let me apply it. All right, so the request to create a cluster template instance was successful. I can again check the quotas. And I can see that in the status, I have a new demo template and the count is 1, right? And the budget spent is 20 because the cost of the cluster template was 10. So if I would try to create another one, I won't be allowed to do it. Because there is a webhook, which is checking whether we are within the quota that was specified. So the cluster provisioning is running. We can check that. So in the cluster template instance that we created in the status, we will see how the provisioning is going. So we have conditions here, which are basically showing all the progress of the cluster deployment. So the first condition that we have here is the cluster definition created, which is true. So that means that we created the application and the Argo CD is taking care of the HelmChart deployment. Then it shows whether the cluster installation was successful. That's true. So it already created a cluster because it's a hypershift cluster, so it was very fast. Yeah, and then when we create this cluster, we add the cluster to Argo so Argo can manage that cluster. So that was already done. And then Argo will apply the cluster setup, so it will start creating the Kafka on the new cluster. And after all is done, I will get the access to my cluster. So there is admin password and also the URL of the API. So I can grab my password, this one. And I can take my API URL, I can log in. OK, so now I'm logged in to my new cluster. Let's try whether the Kafka that I wanted to have deployed on that cluster is running. So they just grabbed these commands from the example of the Kafka cluster. So I will run a Kafka consumer here and in the another terminal, Kafka producer. And once that is running, I will be able to type something into the Kafka producer, so full. And it should appear in the Kafka consumer. OK, so that's it. Do you have any questions? Oc get notes on what? On that window, I need to write. Oh, sure. Yeah, so the question was whether I can show the notes on the newly provisioned cluster. OK. So and another question. Can you please celebrate a little bit about that agent platform within hypershift config? Sorry, can you repeat? So you have a CR for hypershift, and you have a platform agent there. So could you elaborate a little bit what this is? Oh, yeah, sure. So how agent platform works is that you will create an infrastructure environment, which is the CR, and that infrastructure environment will provide you with the ISO.  So I already did that, because I didn't want to spend time on that. So you have an agent in that infrastructure environment. And when we take a look at the Helm chart that we created in the Notebook, it says that in the hosted cluster, it says that the infrastructure environment that I want to use is called DevConf Infra. So I'm picking agents from that DevConf Infra. And in the Notebook, I can say what kind of agents I want. So you can specify. You can pick them by the label. And I just said that it can just pick any agent from that infrastructure environment. OK, any other question? Maybe we'll show that later. But what is this project? Is it bundled with something, or is it a standalone operator? Where can we find more info about that? How can we install it? OK, so this project is very new. We don't even have a first release yet, but we are working on that. So hopefully next week, we will have something. But currently, it's a standalone operator. It should be available on the operator app soon. And maybe later, it will be part of that MCE project. That's why I started with it. Because at the time when I was writing this presentation, we wanted to include it in the next release of the MCE, but then it was decided that we will postpone that. So it will be from the beginning, it will be a standalone operator available on the GitHub, but later it will be part of the MCE, probably. And where you can find it is, so on my last slide, there is a repository which you can check out. And right now, you can just build it yourself and run it, or just wait a week or so, and it will be on the operator app. And about the Ergo CD, you install it as a dependency, or you expect it's already installed on cluster? Yeah, it needs to be installed by you. And the same way for HyperShift, right? Yes, so you can either install MCE, which will bring the Hive and HyperShift, or you can just install those separately if you don't want the whole MCE package. Thank you. Okay, so that's all I have. Is there any other question? Yeah, another question about underlying infrastructure for provisioned cluster. So is there any cloud integration, like managing load balancers, service wire services, and that kind of stuff? Or it works just like a bare metal, and you need to figure out it yourself. I mean, you can deploy your cluster on AWS or GCP, or on anything that the Hive or HyperShift is using, because that's what we use to deploy the clusters. Yeah, so... So that basically depends on underlying HyperShift capability. Exactly, yeah. Okay, thanks. Is there any other question? Okay, cool. So thank you. Questions? Thank you. Thank you for asking us a lot.


We are recording. So, hey everybody, welcome to 1559 implementers meeting number six. I just shared the agenda in the chat. A couple people joined in sense, so let me reassure it just in case. So first thing on the agenda was just client updates on the test net. Maybe we can start with another mind. I know, Thomas, you just posted an update on the discord. Yeah, sure. So we're fully saying to validating blocks. So Abdul Hamid mentioned that there is some some problem with filling the blocks I believe at the moment. The issue with synchronization that we've seen last week. So when I looked at it was very small thing. So I love the code that was comparing the available block space for both the old style transactions and the new style transactions and since we merged them together in the transaction plan in the blocks, it was no longer important. So when the old style transactions appeared, we treated them as beyond the space in the block for them, and we rejected the block but after removing that code that checks it's all fine. Cool. Yeah, Abdul, do you want to give an update on the base you said. Yeah. So nothing really new on the corretarium client except some new fields added to some RPC endpoint lacks like the get blocked by number and get blocked by hash endpoints to basically return the base fee. So corresponding to the three API I wrote about aiding the 1559 fields to the existing RPC endpoint, for example for endpoints that return block fields. And yeah, we are working on the tooling, but we have a specific item on the agenda about that. So I'll talk about that later. And Rick or Ramil, do you want to get an update from the get side. Yeah, I can provide updates. So we completed updates and guess code to be aligned with largest version of the IP. And also we tested synchronization guess to guess and guess to be so and it works well. And now we are working on testing guess to never mind. Got it. And when you say test you ran your local network or have you been thinking on the network that that we've been using with letter mine. No, it's a local network. Okay, got it. Yeah, I would suggest to skip that step and test directly on the test net because we are in sync with net our minds or if you that works with business that should also work with net our mind. But it's up to you. Just saying. Yeah. Yeah, I have questions about this network. How can I join to that. Okay, so we can talk about that later because I have a point point about that during the day. Yeah, yeah. Okay, one important thing is that most likely you'll have a person joining on the research press development side part time specifically involved with the IP 1559 only for net our mind. Yes, most likely it's happening next week. That's that's really good news. Cool. So yeah, I guess this is kind of from the client side. Maybe it makes sense. I know Barnaby you had a new notebook as well that she released this week or last week I forget. Do you want to give a quick update on on that before we dig more into the test that stuff. So whatever you prefer I can do it after the test that as well. I guess I'm just concerned we end up getting bogged down in the test that we don't have time. So, yeah. Yeah, is it. Wait, so first, so I released this new notebook which looks at the combination between 1559 and the escalator so this idea that you can have 1559 to have like a nice default market price for the transaction. And meanwhile, users can use this kind of incremental beat strategy to to increase their beads over time. Let me just post the link here. Right. Today's share my screen. Sure. Yeah, go ahead. Right, so in one of my previous notebook I kind of show that whenever demand is shifting quite fast. Increasing users have the incentive to become strategic and to kind of try and overbeat each other, which is what we see currently in this first price auction mechanism that we we currently live in. And so this idea of the escalator was coming to say well, many people are doing this resubmission pattern on the wallet.  And the idea of the escalator is to take that pattern and put it in the protocol and allow you to decide on how low your bid is starting from and how high you are willing your bid to go. And over time your bid is just increasing between these two, these two bounds. And it's kind of a neat idea but the main, let's say problem was that it has a lot of parameters like you have to decide your start bid you have to decide how high you're willing to go. You have to decide how fast you want to go as well. And the nice thing about 1559 is that we actually get kind of this default price which is your being quoted this entry price to the transaction gas market. So, so the idea of combining the two is to at least remove that one parameter which is how high you should start your bid like you should start it at what the base fee is currently. And then, in this notebook I was trying to investigate let's say different strategies. So, I look at two strategies. And I show like, okay this picture kind of shows you in blue here you have a base fee, which is moving around. So here, you assume that it's increasing maybe because the demand is increasing. And you have two players like Alice and Bob, and Alice is kind of in a more of a hurry than Bob is. So she would set the heartbeat to rent faster than Bob does. So what happens with this mechanism is, you kind of track the base fee. So your bid looks like is varying the way the base fee is. But over time you keep adding a bit more to your bid, and you keep saying hey minor, my bid is getting higher and higher so now maybe you want to include. And so that's that's that may be helpful in these cases where the demand is is increasing and users would rather try and compete against each other, rather than take the base fee as a as a market price. So really like the escalator is, it's more expressive and plain vanilla 1559 is, but the question is, do we care about this expressiveness at all like what do we gain from having this more expressive bidding language. And so what I try to introduce in the notebook is this idea of efficiency which is how we look at, let's say the performance of a mechanism in in game theory. So we really care that users which have very high value for their transactions going first, or at least, or going as fast as possible. And so I'm looking at these two different strategies so this one is a strategy where I have let's say very high costs. I don't want to wait I'm trying to arbitrage this transaction and so I want to get in as fast as possible so I look at how much costs I have to for waiting, and I set my escalator to ramp about as fast as my cost is so the more it pains me to wait the faster I'll get my escalator to increase. And maybe I'll let you like read through it. I'm also planning to release videos and I haven't gotten around to it but I think it'd be nice to have a bit of an audio description as well. All right, no I don't want to get into this, but the second strategic sort of encodes a different behavior which is sometimes I don't really care that my transaction goes in as fast as possible I just wanted to go in at some point. So I'll just tell myself okay I'm willing to wait for 10 blocks, and I'll keep increasing my bid escalate my bid overtime until these 10 blocks are done. So hopefully I get in by by the time these by the time of these 10 blocks. So the interesting thing is that when the users in your transaction market use these different strategies. You really see like different, let's say behavior of the market as a whole. So, even visually, not going to go into the details but visually you see that it's kind of very different. So the user's as dots, and the color of the dots is the wave of users that are progressively coming in. And I think it's, it kind of gives some intuition. It's definitely like an introductory work because there's a lot more work to do on, let's say figuring out these strategies. In game theory we like to know that okay is this an equilibrium or not like what should I do as a user what is my best strategy. So yeah, this is kind of still on the roadmap to figure out something I actually hope to do with a team here in Singapore. So yeah maybe more detail on this at a later point but read through it and let me know if you have like any questions or thoughts or if it's helpful at all. Thanks. Does anyone on the call have any thoughts questions. Okay. In that case maybe Abdullah makes sense for you to take also a couple minutes to walk through some of the tooling you've been working on. Sure. So to give a bit of background so we can see that this IP introduces a lot of breaking changes. In terms of UX and all of those stuff with new block header field and the new transaction fields. So that impacts wallet providers block explorers. So almost all the chain. So we decided to implement some tooling around 1559 to make it easier for users to interact with the test net. Also for client implementers that will join after that will be easier for them to do to do their implementation and to validate it. So yeah, I will show you some of the tooling. Let me share my screen. Okay. So first we have standalone components that have the rest API. So we have open API documentation. So this is pretty standard documentation. So we have some RPC not RPC so we have some rest API is to to basically submit transaction using legacy style on the new format style. And yeah, another thing is likely we will have to change the format of the transaction again when we will use the type transaction envelope. So if we already have this tooling we will change only one tool and that will be profitable for everyone. So yeah, some API to play with transactions and some API to basically retrieve the base fee because this is not yet integrated in the current RPC endpoint. So you can try directly using this interface. I have to choose the right endpoint. And yeah, you can get the base fee so if you don't specify the block number it retrieves the base fee of the latest block and you can get the base fee for at a given block. Here it is. And yeah, so this is a standalone HTTP service say and on top of that we also built web interface to make even easier for users to play with it. So yeah, we obviously there is an issue there because you have to specify the private key because MetaMask and all other wallet providers don't have the new format transaction. So I'm planning to add the white list mechanism to accept only private keys from the genesis and this is already what I do in the web interface for example, you can choose among a list of accounts that is loaded directly from the genesis. So the UI provides some links to the specification, work updates. Also we have a block explorer for the testnet and network stages. So we can see the three Bezo nodes and the MetaMask nodes. So if anyone needs the credentials for the head start, let us know in the Discord channel. And we started also to write a wiki guide basically to join the testnet. So this is why I'm gathering information from MetaMask and get as well about the branches to use. I would need also the genesis file and the configuration file and the scripts to launch the different clients. So if you need the genesis you can click there and you will have the Bezo genesis. So that will be great if you could provide me the MetaMask genesis and get genesis as well. Same for the CLI option or config file will be even better. And yeah basically let's do a quick demo. So you can specify all the transaction fields. So I'm in legacy mode so I have only the already existing fields. And set autonome so it will retrieve the nodes using the head transaction endpoint. I can choose the recipient, the value, the unit, gas limit and gas price. So this will be a legacy transaction that will be automatically converted to any 1559 transaction. So you have the link to the explorer. So the transaction has not been mine. Here it is. So you can see the information of the transaction. So we have not updated yet the explorer to integrate the 1559 fields. So this is why you can see the gas price set to zero. And yeah, if I switch to 1559 I can see two new fields and the gas price is not available anymore. So the minor bribe and the FICAP. So the minor bribe will be added on top of the base fee. I have a helper button estimate that basically take, it sets the minor bribe to one way. The value is configurable for the settings. And it also add a margin on top of that. And also it retrieves the latest base fee. And there is an addition with all those three things to have a work in FICAP. So obviously you can play with different settings, but this is just to have an easy to do settings. And basically you can submit the 1559 transaction the same way. Okay, it has been mined. And yeah, that's it. And about the tooling, we also have a tool that basically stress test the network and try to fill blocks. So let me show you one block, for example, that have been created 20 minutes ago. There is nearly 2000 transaction in that block for gas used near 40 million. So we almost reached the maximum block elasticity. So yeah, and this tool is a command line tool. So all those tools are open source. And yeah, I will provide the links of the repositories in the Discord channel. And yeah, that's pretty much it. Cool. Thank you for the demo. Any other thoughts, comments on it? Okay. Oh, sorry. I say it's really cool. Great job. Thanks. Sweet. So I guess the next kind of big thing to figure out is what are the next step for the test nets. So it seems like we have, you know, basu and Nethermine kind of 95% there, get and basu seems like it's pretty much there. And we still need to see what get the Nethermine. How much more time do you people think we need to spend on the POA network? And then is it worth starting to look at proof of work in parallel, whether people feel is like the best next step here. It'd be nice to agree on if we're going to do 2017 or not. So we can get that in one. Okay. Yeah, maybe we can start there. My, I guess opinion on 2017 is I would implement it once it's actually kind of scheduled for a hard fork block on main net. I'm just scared that like, I don't know, it gets pulled out at the last minute or kind of changed or whatnot. So even if it, even if it's not scheduled with 2930, then it will be scheduled with 1559, I believe. Like I think the, the plan is is 2718 will go out with the next new transaction type, whatever that is. If that's not 2930 in Berlin, then 1559 is a good candidate for the next. I don't believe anyone really wants to release a new transaction type without it. It's the impression I've gotten at least. I guess my, yeah, my only concern is it feels like it's not really a blocker to add 2718 support, right? Like we know we can do it and it's pretty straightforward.  It's just one of those things that needs to be done sometime before 1559 launches. Yeah. And if we are waiting for someone to implement, like if we wait to do 15 or 2718 until later, then it means open Ethereum and guess have to implement something and then change it. Whereas maybe it will encourage them to implement if they have money name or complete spec. It's one of the problems that I know we're having is trying to get other people to implement. Like maybe that's contributing. Yeah, I think open Ethereum, my hunch is they probably won't implement anything until it's actually scheduled for main net. Turbo get said that they don't really have an issue with implementing 1559 but they're just not in a rush to do so. I personally would be a bit biased towards trying to test proof of work before just to make sure that there's no actual issues there but yeah I'm curious. I don't know. Thomas and, and Rick, do you have any strong opinions on that. My opinion is not very strong, but my preference would be to implement. 2718 is that what it is. Yeah, yeah, to implement it sooner rather than later. Okay. I just don't see any. I mean the work has to get done either way. And I think I'm not entirely clear. What is where the total roadmap is frankly so once we. I do believe the plan is to move to the single transaction type and, and, and once we've done that there's no two pools anymore there's just one transaction type. Once that's done. Is there anything else that needs to really be done. I mean besides the enormous amount of testing. I think I think 2718 is the last kind of major spec change, like, and after that, yeah, I think it's testing both proof of work and just like dealing with a large state, which is something we're starting to do on the basic side. But yeah, I think in terms of like big changes to the, the actual eep itself 2718 would be the last one. I'm sorry when you said large state you mean just the fact that the blocks are bigger so there's more state. No so one thing we're trying to work on it base you is to see the performance impact of 1559 on a network that has kind of a state comparable with my net so we're going to start building, you know just local test nets, first to have you know 10,000 accounts 10,000 a million and whatnot and see if there's any like major performance impact of 1559 on those. But that is something we can do in parallel and I'll probably take a couple weeks at least to get going. Okay. Two questions for me one request suggesting two polls and we already have one poll on me on the IP 1559 and like there is no need for for introducing two polls because they to transaction types they very nicely. Yeah, it's we're already at one pool. Okay, great. That was the last major change I was aware of but it's already been done. And then I mean center student team they you say to check the state size how would you IP 1559 even affect the state is there like it doesn't really change the behavior of the existing system so there is. Okay, yeah. Yeah, I just wanted to say, this is because people are already worried about the actual state and the pace goes up and effectively 1559 won't. Because of the block elasticity, some people are worried about the negative impact it can have. How can you how can you just. I mean, what was there to compare like between the IP 1559 and the existing state that's just the state will be growing potentially like, I think, and person faster but it's only temporary. So the fear is there's some, there's some super net super linear issue with gas per block, and a single block that is twice as big. When interacting with a large state network like main net could have super linear costs that are not like that's exactly it so I think if we can at least run this, you know, have a test net which has 100 million accounts and a smart contract with 100 million costs, we can run it both on 1559 and not and just see you know is anything kind of much worse under the 1559 case where the blocks are twice as big. I really really the test we need could be done without 1559 just having a 4040 million gas block against a large state network. Simply fork off main net set the block gas limit to 40 million and then fill a bunch of blocks and see if anything crashes. So team instead maybe instead of faking this network big network let's just work main net and that will be better test and faster achievement of just. For private distance with we can use any accounts that we want to create just able signature checking. Yeah. Go ahead up though. It will be harder to have accounts with large value of it. Not really though you can add that in the hard fork right. Okay, yeah, okay, okay, yeah, okay, that makes sense. So you can use the table signature tracking and then you could use any account you wanted. As part of the fork that way you could test with any account that has any arbitrary real world situation going on. There is nothing like signature checking it's just the extraction of the address so this is a bit harder. You just have the signature like the, you just have the R value is just treated as an address. Whatever the R value is use that address, like just as part of the fork, if one wanted. But then but then the formative transaction is different. So it seems like a bit more work. Yeah, then just adding your list of accounts, like adding your list of Wales basically as part of the hard fork. Yeah, this is super simple. That's what I say the same simple and the other one is just requiring new transaction format which. I assume we can also change that in a hard fork but we could change the hash rate as well, right like just lower the hash rate back down to basically zero. Yeah, you want to set the difficulty to zero so that way you can mine on your three difficult laptops. Just as a slight side note, in general, I think that this being able to fork mainnet and test would be very useful for many people in many situations. So if you guys do do this, add this feature into your clients, it'd be awesome if you kind of formalize it at least a little bit just so like someone can use like a config file that does this in the future. I know I've wanted it many times in the past during testing. You can share it in the mind to change back for such a chain and then you can sync to it. So if we if we launch a public testnet on it and then people will be able to start testing it will be great actually, because practically everyone who has they may not may not if can just use a different chain ID for signing transaction and start experimenting on it. Yeah. You're saying there's existing tools like that, Rick. Yeah, like hard hat apparently claims to do that. I haven't tested it. Nice. It used to be called builder but now it's called hard hat. Apparently it will fork from mainnet. You can share a link to that Rick in the in the discord. That would be great. Yeah, yeah. Thanks. Yeah, so this, I guess, just from a testnet perspective. Does it make sense then to go from this proof of authority test that we have now to that, like fork of mainnet do we want like a smaller proof of work testnet in between or should we go just to fork in mainnet. Anyone feel like we shouldn't do that. Test and prod, basically. And I guess if we get it, if we get 1000 bugs for key mainnet, maybe we can try something easier. I think it will be very useful for the future as well just like mainnet working for testing different DIP's like imagine for every single EP will be able to create a separate fork and people will be able to use their accounts that they are used to to check if their contracts work fine. Yeah, I think that's it. That's a good idea. So then, okay, so I think it's still worth kind of just ironing out the details on the proof of authority testnet to make sure we're actually all kind of compatible with each other. Should we implement 2718 before we fork mainnet so like when we do the fork of mainnet should that be a new version of the 1559 spec. I would prefer not to. Okay, so just go to mainnet ASAP. Yeah, same. Okay, and then once we've once we've forked mainnet and we see that it, you know, generally works. Then, then we can add the change for 2718, right. Yeah, we've got to have it for 2930 pretty soon so I think the one big time difference but just wouldn't like to say that we have to have 2718 to just do the fork of this test. Okay. Let me know when it's when. Sorry, go ahead, Micah. Just let me know when you guys are ready to do 2718 and I'll update the AP 1559 with it. I've been waiting until you guys are ready. I didn't want to have the AP. Once again, out of sync with what's actually live since that had problems before. Okay, so yeah, let's do that. Let's try and like, you know, a finish like the proof of work at proof of authority work we have right now. In parallel, I think us, you know, at the basic team we can start looking at like just the hard fork for mainnet and what what that would look like and share that information. And so hopefully, by the time that's done, we have everyone kind of agreeing on the spec on POA, and then we can we can do the fork on with multiple clients on on the mainnet. And then after that, assuming everything goes smoothly, we can add the spec for 2718 as part of it and and we'll already have this mainnet size testnet. Does that generally make sense. Yes. Anything else on test nets or just next steps in terms of testing. If not just lasting. I think I wanted to go over is just this mainnet readiness checklist to make sure it's still roughly up to date based on this conversation I'll have to change it. But just also useful for people tuning in it's kind of where we keep track of things that needs to be done. So the client teams have been changed, I guess not the mind, you did hire somebody so we can remove this. Yeah, I cannot yet confirming 100% but mostly yes. Okay, yes. Okay, so I'll leave it up for now and pay me when you want it to move. In terms of issues, the OS risks, I mean this is kind of separate from from this EIP itself. So I, you know, I don't think we can do much except kind of working mainnet like we just talked about and that maybe give some interesting data. And then coding decoding will wait for 2718 but do that afterwards replaced by fee I think is the other thing we haven't like fully sorted out. And, and it's kind of related to transaction for sorting, but like how do we actually sort transactions and replace them in a transaction pool without creating denial of service risks. I know Barnaby. Sorry, go ahead. I think we kind of assume that we would have to prioritize new format transaction because we have removed migration period. So, if we don't do that there will be no incentive to use a new format. Right. So, so the incentive to use a new format is you get a refund on your feet cap. Oh yeah, that's true. Yeah. And we should probably prioritize the transactions. So you're saying 1559 style transactions. Do what in the transaction pool or in the block to get prioritized. They just, they just both. They just get prior either. Well, you don't have to, if you don't. I mean, if they're prioritized in the block that's pretty much the same thing as saying they're prioritized in the pool. The more it's a stricter prioritizing, right? Yeah. So, well, I agree that like altruistically prioritizing would be good. It's in a minor's interest to choose the ones going to pay them the most regardless of what we suggest they prioritize and therefore clients who want minors to use their clients will write code that minors like, which means I don't think we can really enforce that. I work with minors. I don't really, I don't know that I'd necessarily buy that narrative minors. You know, we think they'll use whatever we write. Yes, we all just, if those of us in this room agreed to just write the same thing and those use that same thing. Yeah, yeah, and I don't really see the downside. If, if minors do choose to rewrite, I'm not, I mean, I think, I guess my thinking is the social consensus should be that we're all moving towards 1559 style transactions. I mean, that's where kind of on this call trying to, you know, through this bizarre process figure out what the social consensus is. I think we should be pretty assertive in actually, you know, we should assert that these new transaction types are the preferred type, and we should do that by telling the clients to sort them, you know, insert them first. And if someone wants to write their client, they can do that. There's not only minors, but also the users who may not have access to the tools for some of the operations that I'll be executing. So not all of the users will be able to switch quickly. And it doesn't feel like there is a such a requirement to prioritize the new transactions very rapidly. So they will all work very nicely side by side. We plan to prioritize based on the fee paid to minors as a resulting from the discrepancy between the gas price gas fee max cap and so on. I think it would be risky to create two different markets without because we removed the transition but also if we started doing some kind of prioritizations it will create two markets it would be completed not on the same basis and we don't have any analysis of the favor of such market and some users could be just removed from that market just because they cannot use some tooling. So how do you expect people to stop using the traditional transactions. There will be more tools will be using them, and they will be like if they if they 1559 is solid enough and if it saves for users they predictive predictability of the gas prices as we all prove that it does by simulations then users will be moving towards those better tools. But in that case, maybe wallet providers won't do the implementation. If they can do. They will because they compete on the market to be the best all available on the market for the users. So they want to have their users be able to see a P1559. I, so, um, I, I mean, let's know I don't know that competition in the, I guess philosophically philosophically that seems inconsistent to me. So either we are deciding what the new transaction type is, or we're going to allow people to choose. I don't think we can split the difference. I feel like the, the way we've been moving is though, to allow people to choose right because by removing the transition period we're basically saying, you know, yeah, so go ahead. Yeah. I didn't mean to interrupt sorry I thought I heard a break.  So just to be clear, this will this prioritization will only come up in full blocks right so if our estimates are correct like 5% of the time will actually have prioritization matter. What's your reaction that I guess the time it will come up is like right after the hard fork, right like they'll be, but this is not like a huge deal. I made for like 10 for like 15 minutes. Yes, because we are expecting like what while we're working but then after that the, I believe the expectation is is we should not see really prioritization have any effect and to accept for an overfill blocks meaning more than 2x demand increase. So, so I think whichever route we choose, it doesn't matter too much because of that. Yeah, so my assumption is that no one is going to change with, I mean, the incentive, as I understand it now is that they get or there's a discount on the 1559 transactions. How big is that discount. So the, I think the reason wallets will change, I actually have a blog post that I'm going to post probably tomorrow about this, but I think the reason wallets will change is because it solves a major support headache for them. Coinbase wallet is the kind of canonical example because they do not allow the user to set the gas price they set it for them because they have determined that setting gas for gas prices is too complicated for their users. And so the problem is, is that this works great, except for when there's increasing congestion, at which point, Coinbase users all simultaneously suffer because all of them end up stuck. It's pending transactions and those pending transactions compound the spells because the user don't know how to deal with it. And so they just send more transactions thinking, oh, that one didn't work. Let me just refresh the page and try again. And then they end up with like 15 transactions stuck and then they need to give specialized support to help them get out of that. The Coinbase wallet doesn't actually let you solve that problem yourself. You have to switch wallets to solve it. So you switch over to MetaMask or just wait. And so Coinbase, for example, I strongly suspect and I haven't talked to them, but just based on having to support their users, like they are bleeding users to MetaMask. Every single time congestion happens because every support channel and then says to people, oh, stop using Coinbase wallet. Whereas with 1559, they can just set the base fee to like two or three times the current base fee. And their users will basically never get pending transactions, like unless we have some crazy ramp up in gas prices. And so I think for wallets, that's the big sell. It solves a major user UX problem that causes heavy support load. And then I think users will just follow their wallets. That's my theory. We of course can't know for sure. If we look at the transactions, the way they are treated, they all become EIP 1559 they just come in more efficient or less efficient as the gas prices defined either as a max fee and gas premium, which actually can give you some discount or as a gas price, which always pays maximum potential gas premium. So they all EIP 1559, we are totally free to support them indefinitely after transition to EIP 1559. EIP 1559 by itself, it solves the problem, whether you make everyone start using new transaction type or not. And the users will, because of how good it will be in simplifying their pricing mechanism and saving them some of the gas fee, they will transition to the tools with EIP 1559. So I think you're making, I agree with your argument, even though I don't think it's ontologically. Look, you're basically saying, when you use users, you mean wallets, you're saying that wallets will because if basically if I use this other old wallet that doesn't update my gas fees are going to be higher by using the old wallets so the wallets will change. Because the users, the whole problem here is the users don't have this like, we all know so much more about how the system works than a normal user the users aren't going to know what's going on all the users going to see is that if they use wallet a their fees are whatever percent cheaper than if they use wallet wallet B so they're going to stop using wallet B and so my own and that's a perfectly fine model, but then my question is how big is that discount. It depends. So I think the way to think about that discount is almost more in the engineer time you spend on your gas estimation algorithm, because in theory, if you got. So if you use the legacy transaction format and you estimated things just right where like your fee cap, or you sorry your gas price is equivalent to the base fee plus one way. And you get that estimate just right your discount might actually be zero right like you might be able to like sneak in at the right 1559 price using your legacy transaction. But the challenge is like that's just a hard estimation to do, whereas under 1559 it's kind of trivial. So I feel like the discount is more like. Yeah, the engineering effort you spend on your estimation algorithm, which will not be kind of perfect. Does that make sense. Yeah, yeah. The problem that you're solving with VIP 1559 is that people have trouble to actually calculate this perfect pricing so. Exactly. The minimum discount will be zero but it will be never will be never paying less with the old style transactions. Yeah, users I don't mean only wallets. I mean also many users that build their custom tools custom. I'll go trading tools or whatever that are actually generating transactions with the custom built solutions based on the client code. And there are probably plenty of users like this and it might be very big cost for them to have to transition tools and some risk potentially. And we want to avoid that risks. I'm talking about users in general whoever is signing transactions generating transactions. So by volume, do you which group do you think represents the majority of, I mean I guess. I think that that's, I understand what you're saying there. I think that those are that's a very different model for who the chain is for right if you are making millions of dollars a day. Running your art box, then you can figure out how to patch your code. Right I don't, I'm not I'm not worried about those people. They're all very savvy and very capable. I'm more worried about the broader base of people that are represent the larger numeric number of people not the value on chain right I mean at some point. Why are we doing this if we're doing it to facilitate arbitraging, then you know there's no point in even having this call if we're trying to increase adoption and make more applications viable on Ethereum, then that's when these sorts of changes become important. The broader base of user would be the one that is using the most common tools and the most common tools would be the ones who would be implementing the IP 1559, like Metamask or Coinbase wallet. So, yeah, I think it's, it's okay to think like this but I do see that there is an incentive for let's say the major wallet that the non power users are using to shift to 1559. So I think my opinion on the why shift, why switch is is not for the fee saving, like I don't, I don't think Coinbase wallet's going to add the code to save fees for their users and I don't think Metamask is going to add the code to save fees for users. I really do think both of them will change because it saves, it improves the UX for their users pretty significantly in certain situations, and those situations are a support nightmare. I currently have a team running support in Uniswap and the number one problem that Uniswap users have like 100 questions every single day scammers are number one. Number two is my transaction is stuck pending. Like this is the support load for decentralized apps and decentralized wallets. Like the number one question after I got scammed is why is my transaction pending? What is a gas fee? Why is, why do I have 17 Q transactions? Like what happened? How do I fix this? Like these are all like this is where support comes costs come from. And so I think 1559 makes it so that should only happen incredibly rarely. Like when you have, you know, six blocks in a row that are all double full, which we expect to be an incredibly rare event. And so I'm of the opinion that the gas savings, the fee savings is not the big deal. Like, I don't, I agree with Rick that people will not switch for that gas savings because it's fairly minimal in the end, but I do think people will switch for that UX improvement. Like, and, and I think that's where I disagree with Rick at least a little bit is just that I do think people will volunteer or wallets will voluntarily move, which will cause users to move because users will follow the wallets, just because the support burden is so high for this issue. I guess to take a step back about the transaction pool sorting, you know, this is not something we can enforce in consensus without major changes to the spec. Yeah, I personally would be pretty opposed to doing that just because this is already a hugely complex deep and and like trying to enforce ordering in every single block feels like you're adding another. I don't, I don't think there's even a known, known solution to that problem right now. Yeah, so in that case, basically, you know, the transaction pool is outlet consensus. We don't necessarily have to have a solution on that now, right, like I think it's, and it's also something we can update in like we don't need a hard fork to update it right we can update it in like a, you know, bi-weekly release of gas or basic or whatever. If we see that there's an issue, obviously, that's not like 100% true because, you know, miners won't have to update their notes then and they will add the hard fork. But I guess I'm just, you know, it feels like kind of a pretty big rabbit hole that we might not get resolution on right now and we can fix. I agree we don't need to agree on it. But I do think there's value in making sure at least every client knows what they're going to do. Like make sure everybody has a plan and that we kind of talk to each other and share what our plans are so that way no one's left like having to think solve this problem yet again while someone else already solved it. And same thing with the replace by fee, like everybody has to solve the replace by fee problem. They can solve it differently, but it'd be nice to at least share our potential solutions with each other. Yeah, and replace by fee, I guess to me is a bit different because we talked about it on the discord, I think it was like a month ago. And it seemed like there were a bunch of solutions that were vulnerable to potential denial of service risks. So I think this is something where maybe yeah, having a canonical formula that's like different clients all use that we know is somewhat safe. Actually has like a pretty big benefits rather than the ordering you have 1559 versus non 1559 transactions. And obviously there's overlap right like the replace by fee might change how you do the ordering, but yeah, I think that's one more having a common solution is higher priority. Yeah, I agree. We saw that recently with guests where they their semantics for transaction ordering resulted in some problems because they're the dominant minor. Yeah. Yeah. And I know, I don't know if I'm remembering this right but I feel like Barnaby you had put together a formula or something for the replace by fee that was like decent. Is that correct. Okay, it was just a way to make sure that you never can replace for free where by for free. I mean, you can do it indefinitely just spamming the network and you never get accountable for it. But you need to increase, like the minimum between the minor bribe if I remember correctly, the between the minor bribe and the fake up, like the minimum of the two has to increase with every replaced by probably has to increase by like 10% or something but but that's the only way that you don't get into edge cases where I'm resubmitting with a different minor bribe, but it doesn't really matter anyway because I'm maxed out on my fake up or the other way around. So, yeah, it's it's we've discussed it a bit. I don't think it was very optimal but it seemed that there wasn't any other option that didn't like protect you from spam. Is there, I don't know what's like the right place to just like store that or save that so that there's like a proper discussion on it because yeah I remember like discord messages. I write something. Yeah, if you could write something up that would be that would be really valuable and then all the client teams can kind of look at it and give feedback and I think even getting like you know Peter and Martin and from guests to look at it could be could be really valuable. Awesome. Yeah. Cool. Okay, and so yeah, I think yeah for the transaction pool sorting we can just keep the conversation going and shares would make progress but it feels like there's a lot of different options and we don't necessarily need to resolve it now. Well, it sounds like they don't need to be sorted at all. Right. I mean, am I missing something I mean basically Yeah, it doesn't sound like you need to do any different sorting than what's already been done, because there's only one transaction type. Effectively if you depend on how you code it. I mean you could like have a flag on on your transactions that get memory. And then you say this one was originally a legacy transaction so we're going to be prioritized or prioritize so it would be possible. But if you code it such that like when the legacy transaction comes in you basically do an in memory conversion, and then you drop it into a pool with everything else. You could very easily design it such that you forgot that it was a legacy transaction originally. I think this is, I mean, I'm sorry, I don't want to beat this dead horse but I think for me the issue is having these different code paths for something as used as broadly in the geth code base as transactions is a risk. But if other implementers or implementers are comfortable, just, you know, absorbing that risk and perpetuity that you'll have to transaction types with no cut off for when you'll support the old type. That's, that's fine with me, but I just seem it just seems like it'd be better to plan that than not plan it. I think the last I remember we talked about this there was the tentative plan for deprecation. If we decide to go forward with it was to introduce a basically legacy transaction tax that if you submit a legacy transaction you would be taxed a little bit and that tax rate would increase over the span of like two years or something. The major counter argument against any kind of deprecation is people who have signed transactions from a paper wallet from three years ago that they cannot resign for whatever reason. We want to make sure their transactions will always be valid and submitable to the chain even in 10 years. I think that's the main contention that I've heard is just do we deprecate it all? Yeah, that's a perfectly fine argument. I think that, you know, I met my experience in working with geth, which is limited, but my experience in working with geth is that's ultimately going to be some sort of, you know, recipe for an event in the future where things go sideways but if that's the desired user experience that's that's fine with me. Is that worth maybe just adding as like a security consideration in the EAP? Like, I don't know. I think that's worth it. Because what kind of risk is suggesting that actually this sorting mechanism is working, I mean, we still will have to define how exactly this conversion is done. I think that's a good point here, because the gas price to FICAP conversion or like to premium conversion is different and different block. We are just discussing today in that in mind that when you sort, like then historically would sort and that sorting order would be unchanged from block to block. If you start sorting by gas price including the legacy and EAP-1559 transactions and EAP-1559 change their gas premium based on the block by block because of the FICAP being there. So the sorting order may change even without new transactions arriving or not. So sorry, I'm missing something. Why would the sort order change? Like certain transactions will no longer be eligible. We cannot determine the actual value of transactions because it depends on the block. Yeah, because if your FICAP is reached, you may end up with a lower minor bribe than the previous block. Yeah, I see it. Okay. That's unfortunate.  Yeah, so I think that when we talk, maybe we should just sort of change this bullet point to say, instead of transaction pool sorting, transaction pool eviction, right? If I'm understanding that is actually an issue. Is that what you were just saying, Thomas? I mean, it's good to keep the discussion and maybe write down how everyone decided to do that because maybe we just assume that we'll do it the same way, but we won't. Yeah, definitely. I agree with your comment here, Rick, that it may go wrong if we at least don't describe it so everyone can read it and feel confident. And I think the account abstraction EEP actually did that quite well. They posted in all core depths this week and I was reading it, but they, as part of the EEP they have like suggested behaviors for the transaction pool, right? And that's not obviously part of consensus, but they still specify it in the EEP and explain the rationale why. So I think that's probably something we'd want to do as well. There was some talk a while back and I just realized not on this agenda about actual eviction strategies. Again, not a consensus issue technically, but there was discussion of what if we just say your transaction is evicted if the base fee goes path up, like passes up your fee cap, like you just flat out getting evicted, need to resubmit. The idea being that we can keep the pending pool cleaner, like thinner, the disadvantage being that it could result in more gossip if the base fee is fluctuating heavily. So we were thinking to keep even the negative, negative, sorry, trying to find the, you call it minor bribe, okay, negative minor bribe in the pool if it's still in the top X transactions is if you assume that the pool holds 4,000 transactions and some of them towards the bottom are actually having different negative values, we still want to keep them and drop them in better transactions arrive. The bigger question for us was what if we drop transactions that actually after the base fee falls would become a bit more minor friendly afterwards, but we think that's not a very big issue, but it might be so I'd prefer to have it on paper. Yeah, there was, there's an argument I think Vitalik made it where there was some, I'm trying to remember if someone else remembers please jump in. There's some potential advantage we get by evicting people evicting transactions. Because it solves some kind of nuisance problem that we've had in the past. Anyone remember, if not, I'll bring it up later. It's actually interesting scenario where users. Go ahead. Okay, it was the idea that you could send your transaction with a fee that was too low. Let's say lower than base fee currently is so that you just wait for it to be included when base fee becomes lower and I think the argument was that you shouldn't be using the network as your like transaction pending transaction queue, your personal pending transaction. Right, it was basically don't peers should not accept transactions with base fees that wouldn't be included in the current block. Like if you get someone gossips you something and it's not can be included just reject it and say yeah don't don't tell me about that please. It's a waste of gossip. Yeah, a softer rule to say, if your transaction is 10% below the current base fee. Okay, then we accept but if it's, if you're just sending it in the hope that base fee gets halved at some point, then we shouldn't be looking at it because it's too, too much to handle. Yeah, I'm a fan of that it reduces the gossip of the network and like you said, it keeps you from using the network as their personal storage effectively. I think it would be intuitive and problematic for some of the wallet users but I'm not very against it, but I think it's not necessary that we already have all the clients holding top x best transactions and even with it 1559 we still be able to tell which transactions are best. So there is no need to specifically evict them different way. I think the idea is with 1559, the pending pool actually should be empty most of the time. Right. If we are evicts people that base fees too low, or if we don't accept people base fees too low. Like so the whole idea of like historically we've always had if any pool it's always full. We're saying that hey we don't have to do that anymore, we can now run clients with basically empty pending pools almost always because your transaction either is included right away, like within a few blocks, or it's not going to be included at all. Like those are the two scenarios. And so we don't need to have like, you know, 50 megabyte pending pool anymore. If we if we don't, if we decide we don't want to gossip that stuff. Okay, so does it make sense to keep discussing this, like, yeah, to discuss the different options and more details I feel like personally I just need to think through it more. I do think there's value in discussing and at least having every client document what they do for replaced by fee, what they do for eviction what they do for accepting gossip of do transactions, and what they do for transaction pool sorting. Like I think knowing what each of the clients do for those four is valuable. And I suspect, once each client gets to implementing it, they're going to have a quite it's going to come up as a question and they're going to ask what are other clients doing. And so I think just having that documented and talking about it is valuable. So replace eviction sorting. And what was the fourth and gossip acceptance around with the word for that. Yeah, what what do you what does your client accept this gossip as a valid transaction. And what do you not accept this gossip and then also this is actually very important. What will you kick people out of gossip for like someone gossips you something that you think is just outright wrong. You probably are going to blacklist them. So we want to make sure clients are in blacklancing each other. So we need to at least agree on that much. And what's the worst the best place to like actually write that down probably not in the eep itself, but it feels. I don't want to have a suggestion. I agree not to eat. I can start a hack MD document I'll link it in there. I'll link it in this in this page and I'll just add a section for every client. And then people can, can, can just add their behavior there. I'm sorry just needed to shut. I'm not sure an informational. I wouldn't do an utter eep until we're actually like settled on some best practices. And maybe once we are settled on some best practices we can add it out it's I don't know like some appendix to this eep or something, but just now. Yeah. Okay. So testing reference consensus tests. I don't think we're quite there yet, especially given that like the 2718 change still hasn't been done. It's probably a bit too early. Community testing, like I think we're starting to do this. And, you know, Abel's tool can kind of help people interact with the network. We'll keep improving on it. And then I think the public test that applications can use this is basically our fork of mainnet that we discussed earlier so it seems like it's going well.


What's up guys Mike Dakota here. I haven't done a spodge video in a long time So I'm gonna do this one of the problems I solved. It's like the next problem. I think it was the arithmetic progression I don't think I did that yet. I'm kind of like jumping over one after the other one. Yeah Complete the series. All right. So basically, um, you have an arithmetic progression arithmetic progression is basically like if you add you're just adding the same same number over and over again So in this case like one three five seven nine here. We're just adding two every single time, right? So one plus two is three three plus two is five five plus two seven seven plus two to nine Right. They all have a common difference Okay, so now our job is simple. Um, you're given the third term and Then the third to last term and then the sum of the series So now you need to print the length of the series and the series So you have to print the length of the series and the series. So here we have three eight fifty five so the The third to last the third term is three. So we have one two three The third to last term as you can see in the end is eight. That's right So that's eight and then the total sum is 55 Right, so then that's the sum of all these numbers 55 So basically our job is just given these third term third to last and total sum We're just gonna reconstruct the whole array So we just have to print the the length of the array and then the whole array All right, so I'm just gonna explain my solution because Kind of got a seed in the first Half so it's not that difficult. Yeah, I just brute-forced. All right So here I read in the number of test cases and I did t minus minus So here I'm gonna read in x y and z. So x is the third term y is the third to last z is the Total sum right so what do I do first? Well first I'd subtracted the Third to last term from the third term. So I did f is equal to y minus x, okay? And then I had this number called n is equal to six So that's just six and then what I did was I had a number a one is equal to zero So this is gonna represent like the first term. Okay, so then what I do I basically just brute-forced every single Possible number common difference that you could possibly have right so like from like I don't know up to One million right so I'm just like going through all the possible Difference common differences you could possibly have right and then what am I gonna do all right? So I'm gonna take the difference between the six so the difference between the third to last term in The third term and then divide it by n minus 5 and why do I do that? So I could actually show you guys why I do that Trusty here Real quick If you like if you if you look at it, you'll understand why so like let's say we had like six numbers 1 2 3 4 5 6 right and Let's see actually, let's go back. Let's go back to the example. Okay Okay, so let's say we have three which is the third term There's ten numbers right three and then third elastases Was a three eight eight? So one two three four five six seven eight Nine ten actually, let me just clear this one. So one two three four five six seven eight nine ten So this is eight is third elast and this is the third term. Okay, so what am I gonna do? Let's go back to my solution That I did Which is kind of a lousy solution, but it does work. All right, so here What I'm gonna do is I'm going to brute force all the possible possible Common differences that you could possibly have for each between each number. So between each adjacent number We check this and this right so I'm gonna brute force every single possible Combination I could possibly have so here. Um, what I'm going to do is I'm going to take the difference between the third till Third elast term and the third term. So y minus x So what does that do that takes this third to last term eight and then I'm gonna so this third to last term Eight as of track the third term, which is three which gives us five, right? Then what am I gonna do? I'm gonna take this number and I'm gonna divide it by n minus five So what does that do? So if I take this number five and I divide it by n minus five so currently there are there are The common difference that you possibly have here currently is That we have here is Let's see. I Think I did it because Yeah, okay, so I did did n minus five because So originally I put six because six is like Let's say we're guessing that six and then we're just going to go through like all the possible numbers from like the common differences between six to like a Million right so then the reason why I do n minus five is because if you take five and divide it by five You get one so that's gonna give us the common difference between these two these two these two So right so this will be plus one plus one plus one plus one plus one Right, so that gives us one that gives that because it gives us that common difference And then I'm gonna set my Third term and I subtract two times this difference. So what does that do? So this third term right? Three minus two times the common difference of one so two times one is just gonna bust one So this is gonna give us the first term right So if I take have the third term and I subtract by two times the common difference, I'm gonna get the first term So that's what helps you right? Okay, now what I'm gonna do is I'm going to check the Summation and see if it actually equals to the total sum so I know this is kind of really strange but this is like a decent equation so like a You might think that this is like really difficult, but this is basically what I'm doing is I'm just plugging into the formula so I'm doing like two times by the first term plus n minus one times by D so this is gonna give us the Summation of the Yeah, so it's basically I'm doing n times I'm basically doing this equation that does the common difference given the common difference and you just check it You can actually search it up. So some of arithmetic progression formula So yeah, this is a this is the formula When the last term is not given so what are you doing is you're taking the first term two times by the first term plus n minus one which is like the number of Numbers you have and then multiply by the common difference D You add them up and then you multiply by n you divide by two. So that's like the summation formula So I'm just checking that to see if that works Right. So if this does work and it's equal to the total sum of Z So remember Z is the total sum that they gave us so that's works and I just break and when I break I just print out the number and I just print out each common difference So print out n with the number of numbers and I just gonna I'm just gonna loop through from one to n And I'm just gonna add by the common difference. So that's basically what I'm doing here is that Once I have like the common difference, I'm just loop from here to the end of n Right, and I'm just gonna add one every time. So I have one and I'm a plus one So that's gonna be two and I plus one and I get me three plus one get me four so on and so forth. It's how I reach n So that's basically how I did this problem What I'm doing is I'm just going to go boot force and go through every single possible number of values of n to infinity You get the common difference by dividing it by n minus five, right? Because if you're going to assume you divide by n minus five from third to third to last term you get each each the common difference here Right, and then what I'm doing is I'm just gonna find the first term by subtracting two times the common difference from the third term So three two three minus two times common difference the first term is going to give us the one and then from there on I'm just going to just check if the this whole equation is right Like the summation of arithmetic progression is actually equal to our and some if it is I break and I just start Printing out the common difference again, but otherwise I just yeah, that's it So in the end you should be able to get your value if you go through every single possible number of values of one to six to Infinity or not six infinity six to two a million because the constraints are a million. Yeah This is how I did the problem. It's kind of messy. You might find a different a better way to do this problem But yeah, very calm scribe. I'll check you guys later. Peace


Hi, my name is Jennifer Root. I'm a physical therapist at Whitman, Michigan Health. I'm here today to provide you with more knowledge on managing your joint pain. Let's look very briefly at normal anatomy to help you understand what can go wrong. This picture is of a normal hip. The hip joint consists of two bones, the pelvis and the femur or thigh bone. These two bones join together to form a ball and socket joint. This joint allows for a lot of movement in many directions. The surfaces of both bones are covered with articular cartilage where they come together. This protects the bones from friction. The stability of the hip is provided by several ligaments that are not pictured here. These ligaments are deep, short and strong, so it is very difficult to strain them. To protect the tissues that are close to the bones, we have what are known as bursa. These are fluid filled sacs that sit over the bony prominences and prevent the muscles and ligaments from rubbing on the bones as we move. One of the most commonly irritated bursas sits over the greater trochanter, which is the large bone you can feel on the outside of your hip. This is a picture of a normal knee. The knee is made up of four bones, the femur or thigh bone, the tibia or shin bone, the fibula, which is the small bone on the outside of your leg, and the patella or your kneecap. The knee is a hinge joint, which basically means that it has two motions, bending, reflection, and straightening or extension. There are two kinds of cartilage in the knee. The first is articular cartilage, like in the hip, which covers the ends of the bones and protects them from friction. The second is fibrous cartilage, which in the knee is called a meniscus. These provide cushion and shock absorption for the joint. There are two menisci in the knee, a lateral, which is on the outside, and a medial, which is on the inside. There are also four major ligaments that provide stability in the knee. First, the medial collateral ligament and the lateral collateral ligament are on each side of the knee. These prevent too much side-to-side movement of the joint. On the inside of the knee, we have the anterior cruciate ligament, or your ACL, and the posterior cruciate ligament, or your PCL. These ligaments prevent too much front-to-back movement or twisting. There are also bursa in the knee. These are fluid-filled sacs, like we saw in the hip. One of the most commonly irritated ones is under the patella. Osteoarthritis is also known as degenerative joint disease, or DJD, or it's known as wear and tear. It occurs as the articular cartilage of the joint surfaces gradually wears away over time and becomes rough and gets little holes in it. You may hear the term bone-on-bone. This means the cartilage protection is worn away and the two bones directly contact each other. Osteoarthritis causes the joint to become stiff and painful. Symptoms of osteoarthritis include limited motion, difficulty walking, pain, stiffness, and swelling. But not all joint pain is arthritis. There are many things that can go wrong with a joint, and just because you have pain does not mean you have arthritis. Some of the common things that can go wrong are as follows. Bursitis is an inflammation of the bursa. It is usually caused by repetitive movements or a new activity. Tendonitis is more common in the knee than in the hip. Like bursitis, it is usually caused by repetitive movements or a change in activity. Tendonitis is an inflammation of the tendons, which connect muscle to bone. Ligament tears are usually due to a traumatic injury and again are more common in the knee than in the hip. Most commonly these injuries occur with sudden forces such as being hit in the joint or with twisting motions. Muscles can be injured or overused or are injured with trauma such as a fall. There are many muscles around both the hip and the knee joint. A meniscus in your knee can be torn easily, especially with a twisting injury. And finally, sometimes what you think is hip or knee pain is actually caused by irritation to the sciatic nerve in the low back, buttock or back of the leg. This nerve runs down the outside of your leg and can give you pain into the hip or knee. Looking at all these types of injuries, sometimes it's difficult to determine what is wrong because the symptoms are all very similar. Most of these injuries result in pain, swelling, limited motion or difficulty walking. It's important to see your doctor so that you can get an accurate diagnosis. These injuries can be treated conservatively with rest, medication, physical therapy and sometimes injections. However, sometimes surgery is necessary. I want to speak a little more in depth about the management of arthritis. Although arthritis cannot be cured, that does not mean you have to live with the pain. There are many options you have to help manage the symptoms and live a full and active life. We're going to cover the importance and implications of diet, supplements, exercise, medication, injection, surgery, physical therapy and what you can do to protect your joints. When someone says the word diet, the first thing that most people think of is losing weight. Although this may be necessary, it is also important to remember that a well-balanced diet with good nutrition and tissue hydration is vital to your health. Further, by reducing your weight, you will decrease the amount of stress that is placed on your joints. Along with good nutrition comes supplements. Diet supplements are not regulated by the FDA and this means that manufacturers can make claims about the effectiveness that are not independently evaluated. This also means that different brands do not necessarily contain the same proportions of the active ingredients. You should always contact your physician or pharmacist before beginning any regimen of supplements to make sure that they will not interact with any other medication that you are taking. Glucosamine chondroitin is a well-known supplement that claims to reduce arthritis pain by increasing cartilage and making it stronger. Approximately 50% of people taking this supplement report that they have a decrease in pain after about two to three months. MSM is another common supplement. It is found in most foods as sulfur, but it is destroyed in most forms of cooking and preparation and therefore supplementation may be beneficial. It is claimed that this supplement helps in reducing inflammation, strengthening cartilage and supporting healthy joints. Cod liver oil has also been suggested to slow down cartilage degeneration and also to reduce the chemicals that cause pain and inflammation. Exercise is important as it keeps our joint lubricated, our muscles strong, and helps to keep your weight under control. Sometimes, however, it is hard to exercise because it can make your joint pain worse. There are many different forms of exercise that you can try. Aquatic therapy takes all the weight off your painful joints and the warmth of the water can be very soothing. Low-impact activities such as walking or bike riding can be helpful to increase joint motion and strength without excessive weight-bearing. If you can tolerate it, some form of weight-bearing or resistance exercise is very beneficial in strengthening and can also help to improve bone mass and reduce the risk factors of osteoporosis. If exercise is difficult, then sometimes physical therapy can help you to get started with a carefully designed program to meet your individual needs. Physical therapy can be beneficial to those that do not require surgery and also pre- and post-operatively. There are many types of therapy that can be used. These include exercises to stretch and strengthen your muscles. Modalities such as ultrasound and electrical stimulation can be used to ease pain and stimulate healing. And manual therapy can be used to increase joint motion and reduce tissue tension. Gate training is important to improve the quality and safety of mobility both at home and in the community. And aquatic therapy is used to improve strength and mobility using buoyancy to reduce weight-bearing on the joints. There are many different medications that your doctor may prescribe to help manage your symptoms. These can be broken into two groups. The first group would be anti-inflammatory medicines. These include ibuprofen, naproxen, and Celebrex. These all have side effects, and as you may be aware, the use of anti-inflammatory drugs has been significantly reduced in recent years due to the risk of heart-related side effects. Your physician would be able to discuss the risks and benefits of any medication that they prescribe for you. The second group of medications would be pain medications. They can be over-the-counter, such as Tylenol or acetaminophen, or aspirin. Other prescription pain meds can include acetaminophen-opiate combinations, such as Lortab, Vicodin, Tylenol with codeine, or long-lasting opiates such as Oxycontin. Again, your physician can discuss the risks and benefits of each medication. Injections can be used to deliver medication directly to the joint. These are commonly used in the knee, but rarely used in the hip. Corticosteroids are used to reduce inflammation and pain in the joint. They can be given alone or combined with a painkiller to give more immediate pain relief. They can be given once or sometimes in a series, and their effects last anywhere from one week to about six months. Sinvisc and suparts injections are performed only for the knee. These injections are designed to increase the lubrication of the joint and therefore reduce pain. This is sometimes mistakenly referred to as artificial cartilage injections, where in reality the injection stimulates the body's production of joint fluids, which increase the cushioning in the joint. These injections are given in a series of three to five injections spaced over several weeks. There are several forms of surgery that can be performed to ease joint pain. The least invasive of these is arthroscopic surgery. This is often performed to debride or clean out arthritic joints and also repair or remove torn cartilage or meniscus. This is commonly performed on the knee and less commonly on the hip. Joint resurfacing is performed primarily for arthritis of the hip. It is a relatively new procedure that leaves more of the original joint intact than a total joint replacement. The recovery time is less than for a total joint replacement, but not everyone is suitable for this surgery. Your orthopedic surgeon would be able to discuss the most appropriate surgery for you. A partial replacement can be performed in knee joints. This is typically indicated if one portion of the joint is severely damaged, but the rest remains relatively healthy. Again, the recovery time is less than for a total joint replacement, but not everyone is appropriate. Here we have pictures of a total hip replacement and a total knee replacement. Looking at the hip, you can see that there are two primary components to the prosthesis. The surgeon replaces the ball of the joint by removing the bone and then drilling a hole down the center of your thigh bone, where the shaft of the prosthesis is placed to hold it in place. The socket is then shaved down and a cup is put into place. In a total knee replacement, both joint surfaces are ground down and then a cap is tapped into place. A spacer is placed in the joint to act as the cushioning. The prosthesis in either case can be made of several different materials. Each surgeon has their own preference. However, some of the options include stainless steel, titanium, ceramic, and polyethylene. Following joint replacement surgery, some form of rehabilitation is necessary. For total knees, this tends to be a little more intensive and lengthy than for total hips due to the muscles involved in the design of the joint. Finally, there are many daily activities that we perform that cause general wear and tear or stress on our joints. By adjusting the way that you perform basic activities, you can protect your joints from further damage and help to reduce pain and increase function. You should be careful to avoid static holding positions such as holding up the newspaper when reading. Try laying it on a table. Make sure that you use good posture. Always use good lifting techniques and make sure that your shoes fit correctly and have good support. The key takeaways for optimal joint health are number one, eating a balanced, healthy diet and staying hydrated. Number two, engaging in a regular exercise. And number three, identifying the source and cause of your joint pain so that it can be treated properly. As you can see from everything we have discussed today, the hip and knee are not simple joints. There are quite a few things that can cause you pain, loss of motion and difficulty walking. There are also quite a few things that can be done to treat your problem. The key is identifying the root cause of your symptoms and then designing a treatment program to address them. Some options for taking the next step in managing your joint pain are number one, take our free five minute online joint pain assessment and then discuss those results with your doctor. Or number two, for more information on our comprehensive orthopedic and rehabilitation services, visit www.midmichigan.org backslash bones and joints. I hope that you found this information on managing your joint pain helpful. At MidMichigan Health, we celebrate the power of health throughout life with you.


So trauma, or a traumatic event, is really almost any kind of situation that happens to a child where the child is not prepared to deal with that event. It might be because they're too young to cope with it, or for some other reason they don't have the skills to manage that. And that can be damaging to a child as they develop. It turns out that children who have suffered trauma can have lifelong health effects from that. And these effects can be physical health effects as well as mental health effects. And so it's important that we determine how to reduce trauma that children suffer, and also how to help them with traumas that they have already suffered. It's so important to address trauma in children because Kaiser Permanente, we pride ourselves in leading in prevention and thrive. And this is the largest unaddressed public health threat facing our nation today. So KP, leading in thrive and prevention, it absolutely has to be top of mission, top of mind. I know what it's like not to have a trauma addressed because it just, it destroyed everything. You know what I mean? I felt like there was no hope. I felt like I lived a very, very dark world by myself. So I went to, the only thing I knew was the streets and drugs, and I stayed out there for 19 years. It was really amazing. 14 years ago I was able to get help with my trauma, and I never had a disease I already used drugs again. And if I had that at age nine, just think at age nine if somebody finally asked me what happened to me, instead of what's wrong with me, like they did 14 years ago, all the things that could have been prevented. If we don't address trauma in children now, we know that when they grow up, the likelihood of them being able to hold down a job is harder. Their health outcomes are different. We also know that if we don't address trauma in children, the likelihood of them growing up and having disciplinary problems their whole life is highly likely. So we need to address the whole child and really teach them resiliency. I think we don't listen enough to students. I think they know if we're being truthful with them or not, or if we care. I talk to students all the time and ask, do you have a caring adult in your life? And when kids say no, I think that's an important piece that we as adults have to spend and pay more attention to the youth and listening to their voices. I think that they are key to our future, to the future of this country and the world, and we need to be very diligent in supporting them and really listening to what some of the struggles that they are dealing with as a youth. We need to address the trauma that children experience in order to help them become more whole people. One of the speakers today explained we need whole children to build whole communities and it takes the whole community to help support the children with the experiences that they have. So bringing the collaboration together, talking about the issues openly and encouraging each other is incredibly valuable.