All Core Devs - Execution #24

Transcript

check-check okay see can you hear me I didn't see you come in yeah here yeah excellent alright it looks like we're up welcome everybody here is a link to the agenda resting serious face the first item subtleties or questions we need to work out yo Ichi you were you put something in about VIP 96 is that still warranting any discussion so when I swing to the pretty place to

contain the three different programs three different hex codes and one of them should be deployed well so one is do you need to code ID I don't have to think about this but there are different code in the request I think I know which one is the right one but the other one should be moving let's okay hold on I'm gonna check myself so yuuichi are you talking about the like word says cash contract code assets you above apply and then down

below again it says something about the my code in the VM in it code exactly exactly okay hold on so let me just I'm gonna compile the Serpent's and see what that gives you Oh

and while the talipes looking that up is there any other implementations that need to be checked as their a solidity one uh no this is the only implementation Pawel add some comment there about being a sign comparison okay yeah oh so these young code at the top is just like something old incorrect and I'm just gonna ignore that or I'm gonna edit that

rather I'll do this right now thank you okay great I think that resolves that right sure it's a minor Victoria issue mmm great okay the next item is VIP 603 Matthew d4 ought a has a comment and the agenda that kind of explains his reasoning for implementing a different curve so oh of a talk were you gonna say something yeah I was just gonna say that I'm in carousing Lyon I am more a bit more in favor of this and I was the last

time basic we're just because of seeing that we don't have or just seeing how inefficient the other curve is so yeah let's have let's have Matt who's on the line explain it to everybody and then we can we can go through the pros and cons but it does it does seem like a needy IP so Matt if you want to go ahead sure thanks yep okay cool I mean yes I mean the the EIP itself is just kind of like a copy of the other one but the comment goes into the detail of I mean generally for me the the biggest reasons are the fact that it's like widely supported

widely implemented curve and people don't want me to roll their own you know implementations of things going forward I mean you know like all guinness relatively new name yeah it's inefficient if you use the alt swan right the the real efficient one version of that curve requires like keep execution which is disabled on the vast majority of things beyond that like yeah you know it's the ability to check manipulate curve points on on nature transactions in fact that like tons of other coins use native-like SEC PTO today six-second P 256 K 1 is native you know like allows you to do nice pegs between chains on that and I mean the

biggest the biggest thing I see is that like you know using that curve securely is is less trivial than using SEC p2 66k one right there's only one group on that curve and you can't you can't really mess it up as if you know if you use if it issues like the normal core operations or is whereas on on the all TN well um bein 256 anyway the curve there's two groups they have slightly different properties if you choose the wrong one you break the CDH is easy if you don't realize that there's two groups you know you there's way more mistakes there like you know generally the stronger support is the community support and the fact that so much sports

256 K one and it's way way faster but you know so that's my my rationale and you know it seems silly to add a curve and not also add the curve that you know it's at least the one supported natively I I don't have anything I don't have anything to say that I haven't said before well is this the same curve that's in Bitcoin yes okay yeah I mean this seems like a good idea does anyone have feedback or any opposition or questions not to say accept it immediately just like look this is obviously not growing not going

into Byzantium but but let's see there is okay one just question I have is them how easy like for if anyone's in here has experience with the sexy libraries so like the stuff some people that we already here's four of the ec recover how easy or difficult is it to call specifically the the parts that you look the Corvette again multiplying so I've implemented this in guess like you know on my own it's it's very easy yeah it's like a five lines but like five lines of code for off code really okay and you're thinking that be the

same across different bindings for different languages yeah because this so there's two different ways to add this to go there's you can use the you know the C bindings which again those are you know portable across languages there's also the BTC HD which is yeah which is also like a clear go implementation if you know people want to use that for priority as well I mean it's has the same exposes the same clinics it's easy recovery kind of requires like at that level of acts to the bindings anyway okay any other feedback what I'm thinking is if there's no opposition

this will be something that will come up in a future a future quartet meeting potentially the next view and we'll make sure that that EIP is up to standards have one of the editors review it and then reappropriation opal anyway I think I might have heard someone speak up was there anyone else no okay great the next thing we have hope I think yo

Ichi dropped off for a second Google's been having some problems this morning I think they updated YouTube and dropped everybody who was logged on to it at like 858 at least all my screens refreshed so maybe that's what's happening updates to testing so this would be Martin Jared Casey and yo Ichi if he comes back Martin what is the summary for testing unless someone else wants to take that so uh HG back as well yeah it's also felt that their testing yeah you each we

were just going over testing and we were saying if anyone wants to give kind of an overall update I'm not sure who's been most active in it because I don't think Dimitri's here right now to give a solid up or to give like a full summary okay so now on high C beta numbers for bathroom we have less than ten minutes that's nice for CPP and we've seen somehow 700 errors but I cannot reproduce them in Opera so it might be just some pretty close to mastering CPP but not much the tests of something that that could be reasoning I mean III

haven't been able to reproduce this and then I which I started to receive many so many people pointed out mistakes in tests in this week so that's a good sign I think it's getting to ship in shame against everybody else so we envision B okay great so the next thing would be and basically agenda items BC and well what's coming up as C part two are about gas prices and client implementations so

I think unless someone has a better idea we'll just go with the client updates first for implementation of VIPs and then go through the gas price gas pricing for the opcodes so we'll start with death it looks like they're done with all their a IP is Peter do you have an update yeah so we are the same place as two weeks ago so essentially we are mostly done as far as I know all new tests that have been added are still passing then the only eight failing tests that we currently have anything investigative but there are some known issues with some tests so I'm I'm not sure whether they're these AIDS failures are because the tests are wrong or

something else is wrong but a friendly we're mostly done so we're just trying to do a cat sure parody I think that would be our kitty I'm also working on fixing test issues I think there is only a couple of tests state tested currently not pass him and also need to implement watching tests I think we'll be ready in two or three days okay I think each year Martin mentioned something about the parity test or Martin you were just speaking up go ahead yeah so I'm wondering if it's possible if it's have you it's a

disabled mal so that it's not possible to configure parity to run on Byzantine rules because it's failing all but on the Byzantium tests and hi yeah it would be to use a branch okay well thank you branch name perfect thank okay great next we have CPP aetherium who's in here I know that Christian couldn't make it it looks like or yuuichi actually yeah yo Ichi I think you might be up to date on that no laundry Oh Andre sorry the Andre go ahead now

well it's actually mostly taken care of president Jim updates now in so I know there was several minor fixes during these two weeks so yeah I'm looking at the meta implementation progress PR and the CPP aetherium repo and it looks like 86 has a few 100 has a few and 211 has a few from the Google Doc that's kept up but yeah that doesn't seem too that doesn't seem too bad looks like Jared and yo eg covered a lot of them cool let's see a theory MJ and welcomed

McHale this is his first meeting he's from the etherium jteem yeah thank you guys we have implemented to all the APIs and we are passing blockchains state and transition tests successfully and now I'm working to bring you up to date we M tests and transaction tests over should should be ready in two days I guess we just need to check that we are passing them - so I'm dating then bringing them to new format enough in our code so we can support new format at this those tests so we can run and check

how how it works so that's it so I forgot is aetherium J compatible with hive or has been compatible with hive some time ago when I we learn done with the test checks I'm going to do work and hive to make it fully compatible we make a pair MJ compatible hive great definitely talk to the hive guys about that reach out if you need me to get you in a getter channel or anything like that ok alright thanks for the update atheria may s I think that would be KC yep as of

this morning we merged the elliptic pairing Cree compiles and almost all the state tests are passing now thanks to the great I've heard sup recently joint contributors still have a couple of loads about a dozen failures to to debug and blockchain tests even or I have progress on those so expect to be passing on the blockchain test pretty soon too okay great thank you let's see yellow paper any relevant

updates on that yo Ichi yes this morning line notice that we pointed out one ape is missing on the that he was correct difficulty palma today and the property water change this was I had forgotten about it so I added opinion about today okay awesome thank you paya app metallic not really not really any progress since last time okay and I don't see any other clients on the call I need to reach out to the Haskell team I think they're the

only ones that are missing that are actively kept up with me as I believe Ruby is deprecated okay so the next one is determining the gas prices and opcodes that was tasked last time with Arkadiy and Martin and I saw that Martin keeps up with a repository called benchmark and the etherium I'm gonna post the link to it but Martin you can go ahead with your overall update any issues or just the summary yeah so in summary we had a chat about this earlier in the week me and Katie and Vitalik and so based on the on the benchmarks there's an analysis with some

suggestions and we've made some concrete suggestions based on that and basically let me just find that the analysis here so the current suggesting that we would suggest is that for addition we would keep the current cost which is a 500 reasoning being that even if we increase the file some it doesn't really matter because there's a 700 call cost which we can count in on that so the total cost would fill be 1200 so we can David mod X

they analysis suggested which is multiply it by around 1.5 or maybe two but then it turned out that both parity and CPP use quite an optimized version of mortix I think the Tallaght we are just multiplying it by five instead that write the tonic um for mod X yes and my reasoning is that by multiplying it by 5i but like other people feel free to check this but I believe that the exponentiation of 4096 bit numbers by three year would that still only cost

something like five thousand gas which is still like not very high and continuing on scalar multiplication we analysis warmed up somewhere in the range of 30 to 50 K and yeah I think you said 40 K for it to be usable and in the hope that it would vary could be further optimized and clients and for pairing case your italic you guys having notes

about bid said about pairing um I remember that I think we had decided that the one that the current schedule that was in PI ethereum so 100,000 based on TV thousand four points is like is so fine and we should just not change it yeah because that would leave us about a factor of two away from easily multiple for for is Ramez recover but still were they unacceptable like a gas per second ranges for the for the hardware work

that we do in the past you know okay so looking at this what is left to be benchmarked or are we comfortable starting to make some decisions about the gas price for Bicentennial so I would hope that we can today just decide yes we'll use that scheme and that's my hope to if during the coming weeks we find or someone finds that there's another service with vulnerability with specific

input vectors then we might have to go back on that in some kind of emergency roll back or change but I yeah hopefully enough that's hope enough can happen so I don't think we need to do any more benchmarking the four to make a decision we'll make it a session and hope we don't have to go back on okay that sounds good what's the best sorry if there's noises that is my cat playing with the mouse that squeaks so what is the best way to organize making these decisions should

we use the benchmarking repo they're not just small enough to just talk about it over get her I think we can just I mean everyone who has had an interest in these things has been invited to see themselves read the analysis I talked about it on all product so I'm I prefer just else does anyone in this call object to the proposed figures and unless someone speaks up I think we should just put in the numbers in the eeks and then no find out for those that piece each has now been updated asymptomatic and then we just throw it

out in the tests see city were strong science passes or not okay that sounds good to me anybody have any comments or objections no I kind of agree at this point you should just because whatever number we're currently at and think they are reasonable and then just roll with it because it's way to date already sounds great okay the next item on the agenda review the time estimate for testing and release as far as that goes some of the thinking behind that

was that if we felt that testing was close enough to being finished or finished we could set a test net block number maybe even today and just shoot for that so that we can stay on target for something after which as we get closer to the test net or at the start of the test net we can set a block number form a net depending on how well the test net goes we would put that in there with the caveat that if testing if - if while on test net we find a vulnerability or something we need to fix we can delay what does everyone think of that let's find a new so today

is September 8th and a week will be the 15th two weeks will be the 22nd I think block times are gonna hit above 30 seconds mid month I think they're gonna hit 30 seconds at the end of the month rather but I can check again yeah yeah it's community it's I'm pretty sure it's gonna be at the end of the month but I will oblige with another four to five one nine three six let me just get

the timestamp and they can run like the piece of code I've run way too many times one more time great and while we're getting that how long a so the caller says that we are gonna hit a girl from go up to a 30 seconds on the 22nd and it's we are going to go up to a 39 seconds around October 27th okay so is as far as testing goes Oh awesome welcome Demetri and actually Demetri able to hear me yeah awesome we were just talking about if testing what if

the testers from the testing team and the client teams felt like they were comfortable declaring a test net block number today that we could do that and then we could declare a main net block number sometime after the test net starts or right before it starts and then if test net goes well we'll keep the main net block number otherwise we can delay it if we find some issues in your opinion Demetri where are we in terms of testing and are we comfortable enough to launch the test net and the next week or two yeah I think we comfortable to manage the test net but still we have don't have any news from Paraty client or

other client the just that only get is working on a highest consensus issues that they are having right now I think I talked recently I talked to Arkady and Arkady is it still the case that you believe in the next week or less at this point I guess 7 to 10 days that parity will be passing most of the hive tests should be personal tests some of these ok that sounds good so if that's the case then I think that doing something like having the test at 10 days from now so something like the 18th might be a good idea what's everyone's

opinion and on doing something like that hmm that's good sooner the better yeah I agree and I mean the reason for that is it's a Monday I feel like Mondays are better to launch things because you don't have to work the weekend if you launch it on a Thursday or a Friday and things go wrong or anything happens so it looks like let's see if we do that on the 18th and then we were on the test net for two weeks we could launch on October 2nd how long should the tests that be run for

cuz I've heard figures between two and four weeks I know there's some period of time where you know it doesn't really make a difference how long you run it after a while we just kind of know it's gonna be good or bad what's what's the opinion based on previous experience with this so this is how long we run the test that before the switch over to the main Network correct that's the question okay um so my answer is probably still gonna be around 3 to 3 to 4 weeks okay Peter did you have an opinion I saw you

talk for just a second no I just want to say that basically if things go wrong I can imagine that they will go wrong pretty fast I guess I would have said 2 to 3 weeks doesn't really matter but yeah I don't make sense to run it for much because things break it will break ok well the good news is we don't have to decide on a main net number today but it sounds like the main that number may be on the second or the 9th of October so something like that would make everyone feel comfortable it sounds like also doing it on the 18th would give us 10

days to finish up testing so that that's getting give us a little more time than we need probably from what it sounds like we can personally I'd perform the ninth over the second but no okay yeah I don't see why we should you know playing it safe sounds better yeah and so like in yeah so the block number will probably ends up being like either four point three five million or four or four point somewhere between nine and four point four million if it ends out budge written dragging on later and that's from Maine that right yeah forbid note okay and then uh just was like no last means not besides the final block

number before the test nut forks because I think for for the homestead relief we picked a number which was only a preliminary number and then we kind of delayed it and that resulted in actually apparently they had release with the old number and then they did a new release with the new number and some of the clients worked over because they haven't updated and they thought that they already have the correct block number so if possible let's try to see the main test network first and then finalize the main that okay so as far as the test that number what's a good number for that that would fall roughly around the 18th yeah the eighteenth one note about the

chestnut/black number is because the difficulty is very low especially relative to the main net if more hashing power comes online and then starts mining on the test net then it can accelerate the the data or time when the when the block number is reached so should probably allow for one to two days target at one to two days later than the intended date that way if if the hash rate goes up by 100 X then it at least it doesn't the you don't reach

the block number earlier than intended mmm-hmm okay so what would you recommend I guess I'm not doing a that would be doing a block number that is a bit ahead of the 18th I guess or am I am I thinking of this backwards yeah that's right I haven't um done the numbers myself but I can work on it real quick here yeah no problem we still have some other agenda items so we can kind of come back to this at the end whoever wants to try to come up with a nice clean number for that time I

would like to suggest I mean since the test that can be easily influenced wouldn't it be better to if we say today that 40 Testament on the 18th and set the block number we don't decide that your block time today decided later there's less variance yeah I'm okay with that what would be the minimum amount of time before before a test net is released that a client would need to be released with these with these numbers they're already pushing the limit yeah I guess what I'm saying

is like if we decide the number of three days before then everyone will have to update their clients which is okay but I don't know if that would cause problems if a lot of people stay on the old client and keep keep running Rob stone some clients will definitely be on the old Robson there's already a lot of clients on on various Forks of reps and anyway the important thing is is the hash power that pointed at that the hash powers updated that they so that the miners update more than all clients okay so something like deciding the block

number on the 13th of the 15th would that be a combination of enough lead time but avoiding a lot of variance in the block number beforehand yeah okay next Wednesday sounds good because it's midweek so if there's any complications we can deal with it let's say the 13th anybody opposed or want to push it to the 15th I don't know enough about you know how fast these things can change to really make a determination I'm just kind of throwing out numbers I think I do know they change quickly

by the way this price effect to this as far as my prison yeah so yeah right the price going down increases the likelihood that mining power goes down which makes block x be a longer but well it has the long term so mix walked on some longer and so it does have the one kind of happy side to it which is that it's what it's slightly delays the next the next two having's yeah won't mention it on this channel just everyone check get her real quick but basically there's a rumor that would

potentially decrease the price so that's kind of why I'm thinking not just a rumor looks like it's in from everything I see inside the Chinese channels very likely true yeah so basically due to that information that I won't say because it's just rumor at this point that would kind of make things weird anyways man that is interesting basically let's decide it next Wednesday then I guess unless does anyone have any opposition for deciding the test net block next Wednesday just for an estimate the testament

Rapson is currently at one point six three million so if we do ten days then we'd be about one point six nine million unless I'm mistaken and so one extra day would be one point seven million which is a nice round number okay that sounds good one point seven one point seven million would be a nice round number okay I have that noted just Shh oh my cats freaking out as far

as the main net test block so just basically what I'm wondering is yeah if the price drops dramatically what does that affect the block time is the thing I'm wondering because that's what a lot of people in the community would be wondering um how does what affect the walk time the price dropping how that affects the I guess oh yeah so in like basically because because it makes the difficulty defective the difficulty bumps like much stronger but that's only if mining if hash power really drops in our previous experience even large hashmap one price drops have not in the short swords and mining power drops okay great so it sounds like the risk isn't that high for the economic factors here

yeah cool alright so we have that block number done what's the next item on the agenda any other comments on the block numbers and stuff in summary something around 1.7 million is an estimate for the block number on Rob's tonight it next Wednesday to see how the vary or to see how difficulty and other things change and robson between now and then and we're tentatively trying to hit September 18th for the tests net block number at which point we would start deciding on a main net block number that would hopefully be two to three or sorry three weeks after rob stone which would put us at October ninth that is an

unofficial number for all the coin media that keeps saying September it's not September so the October 9th potentially unless there's something goes wrong with the test net so item number two on the agenda is the snappy compression for dev p2p that's the Ayatollah caustic oh go ahead yeah so on when we decided that since number could we please just make it quick yeah some folks suggest them to the oil core dev channel and get her those who posts can raise their hands oh yeah I think that's a good idea we're not gonna have a call next Wednesday I should I should have made that more clear it would just be a getter chat

great yeah it would just be a get er chat because we already have somewhat of a number and if things change we can just adjust that number for the block number I should say cool any other comments probably just to get her chat up they at the same time as the regular scheduled calls here yep you're talking about next Wednesday right yeah yep so same time as the regularly scheduled call so 1400 UTC we would have a discussion on the Gator channel about the block number I'll put that in my notes as well so 1400 and Wednesday okay so the next item is a IP 706 this is a

snappy compression for dead p2p Peter came up with this it reduced the sink bandwidth by 60 to 80 percent and would affect the network layer of the protocol I've reached out to swarm developers I think Daniel who works on swarm has already commented a little bit on it and we've received more comments since then in the EIP let me post it here so Peter if you can just give a quick summary and then we can discuss sure so the crux of the IP is that previously a few I think when Experian launched we had some plans to extend that beauty beer basically that's the base that's working the RFA theorem so that it employs compression because currently just encrypts whatever

upper layer that work protocols throw at it and just transmits it that way and we had this idea but nobody ever pursued it because it was kind of bashed together with some other changes and and the last few days I was running some benchmarks to see what what furfle basically how compression would impact performance and it's quite staggering so in using the etherium to do a fast sink on main that it produces download traffic from 34 gigabytes to 13 so basically that's about the 60% saved and on rinkeby down it reduces from 2.6 device to about less than 500 megabytes so on rinkeby it's more spectacular

because it's quite full of spam oh but but the idea is that the compression really can do an enormous save on on the East protocol so so I created I try to I try to figure out how how much code or how much effort it would take to actually implement that be compression or I mean compression in general for for a deaf-mute appear and eternal that it's really simple so it all it takes is whenever so before a message actually gets to be encrypted and put on the wire we can do a compression round on it and similarly when when it's a decrypted from the wire we can do a decompression and and basically I managed to the whole

code for this in GUI streaming in the go code is about thirteen eight lines so I think it's it's worthwhile addition and I kind of brought up the cipa to discuss it ethical wise the EIP consists of bumping the version number of deaf-mute appear to from four to five and basically whenever handshake arrives client if the handshake contain special number five and clients and sorry clients should do snappy encoding from that point onward they're having some discussions with corner cases and yeah IP can't find it on listed there so one of the first questions is whether people feel confident about rolling out such a change or not I've heard one concern

about this change from from the fight game team that's Leah from Piper Miriam he was saying that Python itself doesn't have a cure Python implantation of snappy so this would entail I thought having to actually wrap the C++ library they are a bit reluctant as I know all other clients I mean all other languages go rust JavaScript you have your implementations for snapping so this the only concern was that one open question is whether we want to have compression mandatory or whether we want to as a maybe a compatibility flag and enticed

signal whether they want to confess Allah so with the basic micro two questions one is whether their general interests do include something like this and two whether we want to if there is interest whether we want to make mandatory or optional mm-hmm is there some like a wide wavy or specification of how has snappy works so I linked a Wikipedia article I am personally not familiar with how stuff you wasn't gonna I'm not sure what any some information I think he may have looked into it sorry I'm asked a question so the question is whether you have any knowledge about how

complex snappy is internally at guessing miles on thirty people I looked at briefly before we're not in great detail and then relatively straightforward if I recall correctly and of course there's the most compression algorithms if you really wanted you could um commute to dummy one that license which doesn't comprise anything I think so in in a sense it's important to note that the deaf people so the the IP proposal is backward compatible in that a client may choose to run version four and not do any encryption so it is perfectly fine for some clients to upgrade now and some

clients to upgrade in two weeks or in four weeks or whenever they feel like upgrading the clients can do this completely another form another I think it's a good idea pending more discussion so this would not require a hard fork because it's part of the networking layer so the clients would just have to implement this correct yes if not I mean I'm how much more discussion do we need I guess I think or do we just we just answered Piper's question didn't we I guess I was unsure if Piper's question

was effectively responded to also and I guess the other thing is like Andre and a few other people had a few sub questions like to enforce the 16 megabyte limit on compressed size and a few different things oh never mind I see okay Carol okay Peter you commented a couple hours ago about updating the spec for replacing lazy with 16 Meg okay yeah so so currently this bag states that the decompressed size is limited to 16 months and this essentially has the same limits enforced at the current that beautiful so this is nice because you don't need any extra effort around lazy

decompression and we can basically we can use the same who's as we currently have so if the message the plain text messages they decompressed messages larger than 16 max then it's just gone out okay Arkadiy do you want to elaborate on a comment you just made about having this be a sub protocol level yes I've just said two comments suggesting that it should be negotiated for each the protocol because some protocol might not did all that and why would they want to disable that is that for different sub protocols that would be implemented within the client well yeah because some

of them are already well at least I have the one parity that already uses compression on a different level and we don't want to compress everything twice well so so one of the problems it is that it all of a sudden this means that I explicitly mentioned this scenario in the VIP in the discussion I mean in the fact that the problem with doing this on a sub protocol level is that all of a sudden if I roll my every single sub protocol officer needs to be aware of a nice to hear about compression and so that's that's already getting murky and regarding the speed as Nick was pointing

out that that's not be essentially if Hannah almost as fast as mem copy it doesn't actually compress so the go-go implantation of snappy you actually make it compress to JPEG images which are probably not really compressible can compress of this a with about 15 gigabytes per second on a single core so those numbers I am wondering whether it matters if it does a round or not so I'm not suggesting completely taking it to these a protocol implementation so it's still handled ways in their PDP but that's the protocol will just declare

one bit in one compression or not that's it well yeah but I mean who needs a heavy update because all the capability is all the handshake message needs to be so currently the handshake message can be extended the extra fields but I'm not sure whether the capabilities field itself can be further expanded I don't think that Provost force that which means that do such a thing it would require a major update the deputy your updates new version anyway well sure but if it requires a ton of update from everybody that is much less likely to be implemented by anybody

supporting compression also requires an update from anybody right yeah but adding 20 lines of code your code is much simpler than adding 200 I mean the question is is it with complexity because snappy is ridiculously fast and it's gonna be a big game in most cases is it worth complicating things for I could schedule an HTTP regularly you know gzip compression stuff it's incompressible and it just works because it's why 800 Hz because Heather's the most don't know if that's what I'm saying I don't practice a lot of service

simply serve everything compressed and gzip is although more extreme to that snappy sure my point is about giving choice but do we need the choice like is it actually important well given that snappy is almost as fast as just copying it and your processor and and memory bandwidth or what is it makes you faster than your network I don't think yeah I think I think Arkadiy the thing is like if there's nothing if there's nothing currently remotely faster than that then implementing it is a sub protocol would only complicate things rather than

having everyone go with the same thing that for the most part shouldn't be superseded for a long time if there's something already implemented that's faster than snappy that everyone can come on board with that that sounds like it would be better is there something that's implemented on a sub protocol level that could be implemented everywhere and a that would be faster than snappy that's not my point I'm not suggesting alternative to snapping we're already using snappy and show that they don't want to compress the data twice with snapping I mean I understand that that's a bit of a code smell but given that it's not actually going to have a meaningful impact on performance doesn't matter I don't think it will be more than another - anyways good ok so it

sounds like what you're saying is it's doable Arkadiy it does add a little bit more complexity to your to your client though [Music] well its complexity to everyone's crime not just Harrison's crime alright know what I should say is complexity what would they be having to change their sub protocols to not compress things twice that's how I understood it I don't think it's on the table to change the parity protocol yeah it's not the problem of the network gives the same problem well yeah anyway we can discuss anything github issue yeah I'm okay discussing it further and the github issue and getting

a few more opinions and then the next chord that meeting let's bring it up again I think by then there will also be some more people who utilize that p2p who might might have some other opinions on it so but that's not a problem also we can get kind of better descriptions because I think there's just a little bit of confusion with what the arguments are about so well we'll talk about it more on the IP that's a good idea our Katti Thanks so let's see is there any other topics or agenda items ok great think of anything yeah I'm good too

it looks like the estimate is around the 18th we will be doing a test net fork potentially that is block number 1.7 million but that is obviously can change at 1400 UTC this Wednesday we're gonna have a getter chatroom discussion on what block number the test net will be and then after the test net after the test net happens then we will decide on a main net block number that will hopefully be like this is super early but we'll decide on a block net number between the 9th and the 16th I guess just some something in early October

basically the the 9th has been thrown around as a date but that's nowhere near official so the main that block number will be after we start the test net it sounds like although we might have some recommendations beforehand thanks everyone for coming unless there's anything else everybody have a great day your so Cheers