All Core Devs - Execution #20

Transcript

e e e hey guys can everybody hear me

okay hey Perfect all right cool it looks like oh uh one more thing I got to fix okay someone from the conference call try talking again that wasn't right uh let's see this might work okay uh try one more time one more time ah we got it it's

working thank you guys all right I'll just make sure this people K Kore cool so this is gonna be a short meeting um so yeah we have Jan uh in the back we have metalic sorry CH Chung Woo God I'm so sorry all right and then we have Casey um so yeah we're at Cornell right now uh doing a weekl long boot camp and uh yeah that's pretty much what's going on uh let's see oh it's fine now okay volume up a

little bit more trying to deal with the troll block complaining about audio I heard hey guys T please help us um why why should I help you the troll box is fine okay so yeah first item uh Metropolis so we were I've talked to like the testing team I've talked to some of the devs and people are saying that EIP um 8628 should be um uh should be changed to two hard Forks uh so I just wanted to get

everyone's opinion on that um um just to see like what everyone thought so um I think uh let's just start with this room so what do y'all think um it seems I for me personally it seems like it seems like a very reasonable idea cool uh Casey um yeah I'm in favor of of deferring it and getting something more like E 101 next one which is

101 I should add that to the on oh that's freaking Poss for being in arithmetic AKA which is probably you yeah Casey just said EIP 101 so that's like 86 but like actually before 86 I just posted it to the agenda oh perfect okay um on oh let's see oh that EIP um Serenity currency and crypto abstraction okay um what was without the

currency abstraction part just the crypto abstraction oh right right right yes yes yes okay right which is since then turned into a86 which is since then turned into ap28 and so which parts of 86 would we take in Metropolis and which parts would we defer um I could see I me the one part that I could see us taking in is the is the um create to op code but like even that I uh and I do have the probably wants to get other people's

opinions on this because like create 2 does introduce this like contract contract code meability and like just in case like some clients are designed in such a way that handles that like handles that terribly in a way that might lead to a consensus failure that's um like basically I just want to make sure there's enough test cases for it um especially since like the the one thing that made me a bit more concerned is that in the process of implementing EIP 98 in Python which is the media um intermediate State rout removal I ran through I I ran across one bug that I didn't have before which arised from basically from the facts that an account

like if you um don't um commit if you don't commit the state from P ethereum's cash every time a transaction ends then an account could get suicide and then revived and like pther didn't handle that well so like basically I'm I mean like I do think e98 is very important because this is a significant performance Improvement but I do want to make sure that there's like enough testing on that particular side of things so like one partic one way to do this testing would be to turn off committing the state during uh after every transaction for existing clients and just make sure you can sync the entire blockchain so but so the the only thing that could

make it into Metropolis from from 86 is create 2 is is cre 2 use so much useful on its own on its own not too useful although I mean like I do it I could see it being a better way to create contracts in some cases because like now so like one so one particular way in which a create to a superior to

create for example is that if you um have a contract on the ethereum chain and you accidentally send Etc to address then I know that doesn't work because DC is not going to support create Tu like if it did then it would be easier to like do the it would basically be easier to recreate the exact same contract in uh on another chain if you wanted to well that's a fairly small benefit I think only including create two might be harmful because that allows an easy way to C address collisions and the client behavior when address Collision happen

is one of the under tested W and different clients behaved very differently until like three days ago and I haven't got enough confidence I be fine with like basically Deering all of the AP 86 yeah I think that it's better it seems cleaner to not subdivide 86 through different hard Forks because that just seems complicated mhm that unless organizationally at least for me yeah so if we were to not do 8622

208 what we would be doing is the rest of the eips which include all of The cryptographic Primitives for uh ZK snarks um the 9 wait 96 and 98 so are 96 and 98 are they like pretty much done like or is there any complications with that um so 90 98 should shouldn't be too hard except for like as I mentioned the testing just testing is just in case the 96 um all we need so I wrot based for that you would need the hunk of code that you would stick into the blh contract and I wrote a version but then Nick went came in one and said that he

could make a better version and I've been pretty much waiting for that ever since so if that I mean if that's done then we could use it but if that's not done then I could the other option is to just go ahead and use the one I gave okay so that's so Nick uh what's the status on that uh we I discussed that in previous allore divs and somebody else was keen on taking it over and it slips my mind momentarily who that was I'm just going to look up the relevant EIP if anyone can remember what number that is uh you said 96 right yeah that's block has refactoring so yeah on the main yeah okay so this is something that really should be doable within like an

hour or two so I'd recommend we just like get together and get it done today okay that that's perfectly fine so but that sounds like um and what I'm looking for when I'm going through these eips is there is there anything else similar to 86 that has very outstanding questions um because basically by hopefully the end of the meeting I want to say these are at an EIP level formalized and accomplished right um okay removal of intermediate State routs um so I remember there was an EIP where we wanted to I think Nick wanted to replace the state route with something else so I think the idea the latest yes I I just updated the PLL request earlier today to propose uh what valal the conclusion valal I came to which was

that we should only store the status code uh in that field so basically like you would in that um in that field you would store a one if the transaction if the um outermost call in that transaction return success and zero for return failure yes uh also to go back to the uh block hash thing uh pull request 643 uh is parel's um attempt at uh refactoring the block has stuff I've just linked it on the chat okay great 643 yeah okay

96 okay so it's just a few it's just a few changes to the original EIP or is this a totally new EIP I think I got lost it's a new pull request based on an existing EIP got it I'm trying to pull it up oh I I didn't go to the latest one and I I don't know I actually like um the 10 line solidity thing that Nick

did a while back even more than either of these do Nick do you remember what I what I'm talking about like there was one that just like did a did this like Loop yeah I do remember yeah um I mean if you want to uh reason I like that is just because it looks simpler than like either of these serpent things because it just like properly does a loop instead of like having lots of different like if statements yeah I agree um you mentioned earlier just getting together and doing it do you want to PE code it afterwards uh sure this will end early enough we'll have some time mhm okay interesting all right yeah so we y'all can get together after that and

um Paul's uh solution here does it seems complicated but is it more efficient potentially or not to the point where it would matter matters yeah great okay so we'll have Nick and vitalic and people stick around after to with that anybody else who wants to help uh so where was the list of the IPS here we are okay the next one would be I think we've gone through all the other ones is there any others uh that anyone sees that may have some outstanding things I think 214 and 211 are finalized uh everything else looks finalized um Can anyone pull up the list

and if just everyone can take a minute does anyone have know of any other outstanding things with these most of them are implemented already in clients go through all of them okay so 86 we're deferring 96 we can do 98 is just like removing commenting out a line and then making sure you pass tests 100 I think it's done 140 is fine 196 197 198 which I think we have tests for MH um and what is the status of the C++ tests for like all for um all three pre compiles which compile the 196 1 197 198 this is the elliptic curve and big in stuff so no um after after cpps passed test from Bic there's been no other

progress no additions I remember the one thing that we got stuck a bit on is that for modular exponentiation like some people wanted to do use like katuo for determining gas costs um uh I remember one thing but that one thing was solved a long time ago how was that solved a long time ago I'm looking through right now and I think is so long time ago that I don't remember what it yeah I think it was was this the one where D this was Daniel Nagi yeah it was a June 2nd comment and then he said that carrot subba method mhm and

then I don't know what we just I I I think Robert from parody might have done some estimation after that to compare is what it's looking like uh D told me that he began generating some tests and um but he actually never actually showed me the test themselves but as far as I know he did write a test generator and a test suit maybe so I wrote this big function where I wrote is uh I have a couple of proposals and then I have like this sub piece wi quadratic function then something else and then I'll paste the comment in the chat yeah sure yeah and this follows what we've been

just talking about M all right the one thing that concerns me is that like between all of the kind of bits like the bit based pricing and the yes I feel like the gas schedule for 198 is getting a bit complicated like it's literally more complicat than the actual exponentiation like I don't know this seems slightly concerning something to not is Daniel did thumbs up your comment yeah since he's not here to say I know just like the facts that like the gas schedule is getting this big just makes me a bit uneasy are there other comments like Peter

Christian or anybody about um gas schedule nope okay know I feel like this is the other thing we might want to like talk through today and finalize for for 198 for 198 okay yeah so then we're fine with 186 187 can we go back to the yeah let's run through um I think I might have just G A Different Page yeah 211 return data size return data copy and 214 static call and I think we're all fine there those were those were finalized yeah okay okay and then I think we're fine okay uh anybody

else have anything from the accepted eips list again we highlighted 86 as being deferred to a sec quote second Metropolis Fork 96 and 98 being basically finish today as well as 198 getting through concerns about um how we're going to be doing it okay uh let's see what the next thing is um do we have the gas cost specified for the TIC C addition and multiplication oh right yes

so this is the other thing that we were supposed to talk about that there was like a bunch of benchmarking that happened and this was supposed to feed into like gas cost for all these pre compiles so Martin did some gas estimation I believe it was based on gu and I believe arade also did some based on parody I'm not sure it was for that particular that particular um op code but Martin said I'll try to consolidate the GU benchmarks for op codes later on not much need to report since last time okay so he's just run more tests and then the parody team's on a retreat uh and they don't have any updates they said so um what we can ask them later for the gas cost estimations but that's something that is less vital to find out

today or does that affect some of the things guess just the number like it's probably safe to change it even two weeks before okay sounds good uh let's see I pasted in a link with Martin's numbers that he generated about I think two weeks ago so I'm not sure how relevant they are I figur I'll just share it thank you I'll pull it up okay I think if we get benchmarks for and I think this has been discussed

before that if we get benchmarks for death and parody those are the two primary ones we can compare compare I guess to try to get it as close as possible and I mean would this be something where we could change this on hard Fork 2 if we find out that it has been miscalculated or misestimated um totally okay great then that's less of the deal mhm okay we've gone through this EIP list um any other comments about this particularly no great so uh section B in the agenda is updates to testing um I think yoichi is the only one in here who

okay yeah um somehow the focus is ah okay so the interesting thing is now F implemented state general state test in go and he found many many things that can be improved in the test formats and the testing infrastructure so uh the the efforts and the focus is uh somehow shifted to the infrastructure in these weeks in this one or two weeks just like a bit on that so Felix

was working for last week or so together with the C++ team to uh to Port all the test Su it over to go ethereum so that we can actually run it as part of our CI infrastructure which entails rewriting mostly all of our consensus test infrastructure and uh it's mostly done I think but they are kind of ironing out the quirks and the trying to figure out the weird Corner cases that are really hard to Port over to other projects sorry for inter no no problem so now it's great that the go client can run the general state test format

um and with respect to adding new test cases for metrop police when I see the Google spreadsheet of test cases it's 70% or 88% of the lines are already green saying implemented okay that's very promising so so and that's is that just for General state test or across all of the Metropolis tests across all of the Metropolis tests but yes we have more progress in the General State tests that involves only one transaction we are not so the the progress on the more complicated cases

involving mpal transactions this is not as good M okay great um any other updates with regards to testing yichi no not from me okay thanks a lot um it's really helpful let me see welcome Jan okay um the next is the updates from the client teams um parody's done uh gu uh it look I think you're according to the pr you're all done did you have any comments or questions

Peter uh so um basically we have a follow-up PR which uh which we began just to polish up and even after that uh we decided to split up the the different eips into separate PO requests so we're current currently working on separating them and U just making sure that each of them looks okay on their own uh as far as I I personally would start merging in already the the finalized dips um but we agreed with Felix that we're kind of waiting for tests to to make sure that it kind of looks like it passes all the tests so it's um we're in the phase of if we consider that the tests are looking good and the our code

passes the test and we are starting to merging so that's that's our update great do you mind um in the comments of the agenda posting I if they're if the PRS aren't organized don't worry about it but if they are some of the follow-ups you were talking about if he could post that that that would help me keep up with it sure thank you all right um CPP ethereum any updates worth mentioning there are some minor bugs being discovered during Des y you fix them these weeks you cut out on the last part Andre

could you say that again I'm saying that apart from several minor fixes we did these two weeks there's no many updates Metropolis we mostly done okay perfect and I see that in your PR you've ALS um PA actually added the Google Docs link to each test that you are implementing so that's nice um yeah that probably dimitry was who who added that oh great cool uh so the next thing is uh yellow paper yoichi I think you said there was just like one outstanding issue last time um no that that that was just the

gas cost and then after that e 86 changed a little bit I reflected the change so it's up to date okay great um pyth app that would be the tallic or Jan or both I think mhm uh any updates worth mentioning or nothing too worth mentioning except just that I mean we did release P ethereum 2.0 a while back so it's um more modernized and just like cleaned up a bunch of tests um as far as implementing Metropolis goes we've basically just been waiting until

C++ tests kind of stabilized more so if they have stabilized enough actually no the thing that you want to wait for also is just finalizing EIP 996 and EIP 90 um the 198 gas schedule and once we have that then we can just like run through all the test and make sure we're still passing them back when I was checking I remember uh we were passing most of them except for a few and the few of we were were not passing was because C++ had some bugs in it um although I think Yosi had been working on them fairly recently so now I'm seeing many errors on hive even before Metropolis so I'm um I want

to clean this up because otherwise yeah problems would be hidden among many other problems so yeah I want some cleaner state would someone like Piper from the pth team could work with Y or something uh yes yes I Leed about this uh his debuging oriented client so yes it's interesting thanks okay great is that pretty much the end of the pth app updates yeah sweet uh no other clients are in the

room I don't think um so that ends the updates from the client teams um the other so another agenda topic is determining the gas price for new OP codes and pre- compiles Martin left a note saying I'll try to consolidate the GU benchmarks for op codes later on not much to report since last time and then uh Ary from parody said no updates we'll get that information from parody in the next meeting uh and hopefully compare metrics um are there uh any other comments on the gas price for the new OP codes great so the last part review time

estimate for testing and release uh we've been kind of going with an August or September like very rough estimate um since we are delaying 8 six um I think that's going to help either speed things up or keep us on track um does anyone have any opinions on the timing of when things should happen I guess now that we' delayed 86 what I still don't know is uh now how how many of the metropost Met police

tests uh can go and part run with success and how much Pia are there I that I'm missing okay so that's something where we'll be able to have a more concrete estimate once they are passing the test would that be Hive yes so some outstanding number of failures and the speed of the decrease in the number of radias um this would be kind of indicate this will be an good some indication of

the our Readiness okay sounds good um so ideally let's I'd say August or September but obviously that's going to be pending all of the testing changes so we'll just just keep that in mind for now mhm um any other comments on that okay cool I want to post a link I did oh go ahead a quick question so uh I'm guessing the test if we decides to postpone the account test would be updated accordingly and also I'm wondering do we want uh mix proposal mix EIP about the

adding the the success code or failure code to an transaction receipt do will we do that for Metropolis for the first for metropolis and if yes when can we expect tests for it which EIP is that or is it more of something that would be added to one so it's Mi EIP I'm oh so the modifications to 98 um I'd say you should just bring that into m us part one or part two part one okay if that's the case we need some to jump on that and get that um EIP updated to talk about adding that um and then we

can plan to get test for it I don't know how extensive that is well my point being that uh if we modify the receipts then basically it means we're modifying the block hashes which means all of the tests are invalid currently that's true um it's not much work for General State tests and can run General state test already um feding all blockchain tests however take some substantial amount of time maybe in the counts of days but General State tests can be update

totally even if the transaction receipt format change okay so is that something that now that we've delayed 86 would be something you'd be in favor of yichi as I mean it would be additional work in the grand scheme of things yeah with this additional work I still prefer the delay of 86 oh yeah no I'm I'm specifically talking about how much extra work would be put on for the changes to the um the block hash that you were just describing or to the hash okay the change of the

transaction receipt um but we we already are changing receipt formats and we have been we have updated the tests in face so it's not a block okay um that sounds good uh in that case who should be responsible for editing that EIP to add that that that was uh 98 correct yeah I think that might be vitalic yeah I can do that hold on okay and like

I think it's already in a comment from Nick or someone um can just add um literally edit this right now and I'll basically say I actually wrote 615 as a replacement to 98 so I think with 615 we don't need 98 let's Che 16 you said 615 yes okay no hold on 615 is sub routines and static jumps sorry one oh 658 oh 658 so it's literally a copy of 98 but

with your additions um pretty much I mean 98 just just suggests removing the um intermediate State field and 658 suggests replacing it with stat code so it should be possible to just obsolete 98 and replace it 615 sorry 658 yeah 98 replace with 650 you said 6508 uh yes okay great um I think vitalic might be just adding it to 98 since everyone's kind of already gone there I think you implemented some of the so we'll do either one it really

matter yeah it's the content that matters not the number yeah so um either way we all agree on that and we'll just add it to one of them and then P push it forward if we obsolete it I'll make note of that in the read me I see so Nick you have a single bite whereas um I'm the way I'm writing it up is we have 32 bytes 32 32 bytes of zeros with or or 31 bytes zeros into one pretty much yeah okay um I guess there's there's trade-offs there one is that having the padding it like that reduces the migration hassle for clients um but it also introduces 31 bytes of pointless

overhead right but in the long term the 31 bytes of pointless overhead is going to have to be removed once we add some kind of proper Network protocol compression yes yeah and and which we have to do anyway because like the gas schedule dep kind of assumes that we would assumes that we had had Network protocol compression since day one yes I mean it won't entirely elic be overhead but it will reduce it at least yeah so is there a problem with just doing one um no just basically if you have if you keep it in 32 bytes then like the format of the like the data types just like totally unchanged okay so I'd be interested to hear what Peter and and others think of the two

two alternatives yeah yeah okay uh to be honest I'm unsure so I see the benefit of one of them is that you clients become a bit simpler if you don't if they don't have to care about two different formats on the other hand retaining 31 Z bytes till Infinity also seems a bit wasteful of course they it will be compressed in a database and hopefully soon soon or but then later it will be compressed Network wise too so it's not such a huge issue I don't know to be honest I I can see the advantages of both I mean I guess uh clients are going

to have to Branch to determine how to treat that field depending on which block it's included in anyway so the overhead of of decoding it differently may not be high uh well um yes and no so in theory uh so if I'm running for example a CL Cent so I just attached to a remote and I want to it would be nice if I didn't have to care about the block number so from that perspective May better keep 31 on the other hand it's not such a big difference so uh Andre or Christian do you all have

an opinion on this yeah I know not really cool anybody else okay so yeah um what do you say italic I yeah that's good enough for now okay so just you're saying do the one bite or not do the well do oh oh you mean um the one bite versus 32 B thing yeah that's the only thing we could talk about pretty much I I like personally I don't care and from a python perspective either one is Trivial but like and see what get and parity

think I mean I guess I'd say if everyone's ambivalent about it then go for one bite because it's at least marginally better yeah and I mean we're getting a lot I don't know like we could say like we can fix that later but why not now right okay sure one bite it is all right one bite for that one cool uh I lost track what were we doing that's why we have an agenda where' it go I have too many tabs guys I don't know where my agenda is oh here it is okay so uh oh yeah so as far as the timeline

goes um the other thing that kind of goes with this agenda item is if we do so we are doing two hard Forks we're taking out all of 86 for the first one and that's going to go in the second one what and this is super early so we don't have to go into a lot of detail on this but what other eips would we consider for the second Metropolis Fork which in my opinion should probably not be till 2018 uh just with the next few months and us getting Metropolis out um we can I mean if anyone wants to do it faster that's fine but we'll be going pretty hard and then there's Devcon and stuff so maybe January or February would be ideal for the next one but um any any thoughts on

that just initially know once we're once the first hard Fork looks like it's being close to finalized we can figure out like exactly how much we want to do in this next one like what and what what what it'll entail [Music] me it would be a pretty significant change to like a bunch of FAL L infrastructure so it's worth thinking more about kind of yeah what could go along with that to kind of help or yeah exactly okay and there's also some other interesting ones like minor reward which I feel like that being changed in the second hard Fork makes more sense if we're going to change it no the minor reward it makes the most sense to change

it at the same time as we cut off the bomb and the bomb has to get cut off in the first one okay I forgot where we landed on doing that for this hard forks no there was an EIP somewhere um it's a pretty trivial one is it 186 no well was um hold on might even be one of the the IP 100 because basically IP 649 it's AP 649 and pull request 669 that's the that's just the

difficulty bomb right yeah I we're talking about the minor oh yeah the reward reduction I didn't know where that one was and the reason for that would be that uh oh so yeah the reason for the minor reward reduction happening at first is because the difficulty bomb wouldn't change and so doing it on second hard Fork would make less sense well I mean it is that's assum that the miners would Revol right yeah in general it just seems like like in my opinion it seems weird to just like let block rewards be

really really high for two months and then like cut it back down yeah any implementation wise they're both fairly straightforward yeah can someone figure out how much to reduce it and all that other stuff cuz there's been so many debates on it I can't really keep up anymore I think the informal consensus was to reduce it to like roughly so that the rewards per second or roughly unchanged when the bomb gets uh defused I think it was the the most recent suggestion I heard was three is per box yeah three is like the good approximation okay so limit or do we want to calculate it

based on whatever the forkit I think it's much cleaner to just set an integer number of e personally fair enough okay I you know un Le we want to make it pie ye or something let's make it half a pie or three qus of a pie yeah depending on how hungry we are you can make it three4 or a whole pie yeah well it would lead to some great write articles on coin disc wouldn't it py talk Reigns an allore Dev meeting um okay so that's straightforward so

between now and next time let's just make an EIP for that um I'll put that on my to-do EIP for uh minor reward reduction that's pretty universally liked by the community um okay the other issue with this it would be nice to finalize it fairly quickly because again it impacts all the tests I mean all does oh okay yeah um I can just write a comments to was 669 the difficulty bomb delay no the yeah just like the for issue how to add an issuance reduction yeah yeah that can go with the bomb delay one okay yeah that's actually a good pairing to have

both uh and that's an EIP that can be quickly finalized but at least we'll have the spec in there if you write that in right now that'd be great and that'll just have a day or two to for people to discuss but it's pretty much been decided in previous meetings let's see um I did a Reddit thread the other day where I said dap developers what is the maximum time that the block time could be before it affects your daps and I was trying to aim toward getting stuff like Casino daps and other ones that rely on low block times to kind of let me know what you know daps that are in production what they're doing right now and the wide consensus is that most of

the daps are favoring us doing Metropolis right versus getting the you know the uh the Ice Age fixed faster I guess or like putting in the hard for more quickly and there's more there's few apps that rely on block times being under 45 seconds if anything it just makes it a little bit annoying for many daps um so above 45 seconds it starts to get a little bit more difficult for some some of them um especially the ones that deal with like casinos and um like ether Delta decentralized exchanges because a lot of people can put up their um wow their question yeah so um I'm a big I'm not

not sure how relevant this is what so so I can imagine a few apps that it would be smoother if the if the block times are 15 seconds zero guarantee that your transaction will get in the next block you still have to count with that annoyance yeah all I was doing by doing this thread was to say you know if Metropolis goes out and like we have problems and then it gets pushed in October where it could I haven't run the calculations but I think it could get to 40 45 seconds by October um how much would that affect the network as a whole and it's sounding like it wouldn't be

the end of the world so I go ahead so basically if we go from seconds to 45 seconds but at the same time we triple the gas limit then in theory we at the same yeah yeah that would be that would be in theory depending on also you know if the network with all the you know I like the coin distributions recently like how many transactions are filling blocks that's slowed down a lot though and so no one can predict the future but I would I would reckon that we don't have like huge like full block delays like we've

had with recent coin offerings um beyond the end of the year or before the end of the year so yeah and then I guess the miners can just yeah adjust the block gas limit uh what were you saying Nick I was about to say exactly what Peter said great so y just wanted to throw that tidbit in there do you have any numbers vitalic or anyone else on block times like between September and October I'm sure I can run that script um let me just rerun this the execution I did about two days ago great and while that's happening I can just wrap this up

we're pretty much done okay so we can expect we can expect uh block times to hit 21 uh 22 seconds at the end of July then we can expect them to go up to 27 seconds on August 26th and then we can expect them to go up to 35 seconds on September 27th okay so that sounds like it'd be 40 to 45 within October um let sh it goes up to 45 on November 6th oh all right yes because like as the block time gets longer the periods also get longer so the Block in the long run the blog time

increase is actually linear oh okay that's actually even better than I thought so this isn't going to be as much of an issue we we there shouldn't be any way that we would get Metropolis out l L than November and it should be well before then okay um cool that was the last item uh is there any other comments topics stuff like that okay great um so I have a list here um we basically need to do 96 wait sorry 96 yeah 96 98 and and 198 are the ones with outstanding problems that I wrote

down um the people who were going to help with that after this meeting were Nick and vitalic um other people can stick around if you want I'll probably turn off the live stream um but yeah specifically 198 for the gas schedule and then uh why are we oh we're just finalizing 96 and 98 with a few different things um just making it specific uh so yeah let's get to that um cool yeah there's other comments um good meeting and just everyone who wants to stay on the call stay on the call and we will uh work through those 3D IPS cool all right thanks everybody

um I still have to see what it means to really help um I'm just interested okay dang I mean