All Core Devs - Execution #89

Transcript

[Music] [Music] [Music]

[Music] [Music] [Music] [Applause]

[Music] [Music]

[Music] [Music]

Hudson Jameson: hi everyone and welcome to aetherium

core dev meeting number 89 I'm your host hudson and we're gonna jump into the first agenda item which is the berlin EEI peas integration update the first link is clickable and brings you to a Google spreadsheet that shows some updates from different client teams

that let me open it real quick yeah that showed four different clients and what's gonna the latest on there so I'll pass it over to James who can give an update on that so the update there is actually the Ollo network is syncing for most

clients I'm just getting to the list oh you're right on I the I was going through out of mind which ones can you give an update on two three one five and two five three seven sure for another month oh wait I thought you said me I was like I guess I don't know I don't know if you're here on the call Thomas but I just saw your messaging or if you can talk I think they just joined along

here it's it's not merged yet I'm sure I haven't updated that page and I'm not sure it's working progress okay and and that's for both

can you give updates on

two three one five and two five three seven demo work in progress okay and Basu yours you are emerged in sinking on Yolo correct yes and open aetherium as well

Artem Vorotnikov: yes

and get yeah I mean yeah obviously has there been any updates I'm assuming Greg

is not here attorney

Hudson Jameson: can give an update oh yeah is that Jason I mean look yeah I think that it would be Jason if you're able to talk

as far as I know they're all working progress okay I think that's it then for that item yeah yeah I'd like that that's

thinking well and I think there'll be some updates on that we can talk about later yeah item three is the yellow test net updates so we can talk about how it actually didn't live once and other things so

Hudson Jameson: the second agenda item there was a call to discuss pre-compile repricing specifically the VIPs 2046 and to 666 and I think that meeting happened and James I think you organized that if you want to talk a little about it or pass it over to someone to give a update

I did did a Alex or Alex want to give an update on that

oh yeah many Alex is here I can make a short summary in the form that an initial proposed like a proposal to be priced at equal to exactly zero gas was kind of rejected soon as it was I posted us in a github issue linked to the latest research and how it should be actually priced based on benchmark from existing clients Martin made a test for gas and I have ran tests for open soon and it looks like fur gasps static ball should be priced around 40 guests and

four open soon and can be made around City most likely it still doesn't take off to six six six from the list and also it may be put it would be necessary to change prices of B and add and B and move in case if 20:46 is accepted with some even sound nonzero value but small like forty but it still can depreciation prophecy yes

Martin Holst Swende: another thing that we agreed upon is to try to assemble around a set of good

test vectors for benchmarking so that each client can try out the set of benchmark vectors and see and which one's perform the worst in their implementation and then base their do their analysis based on the worst performing one and see would we still be well could we could we handle the proposed lowering a prices if you know blocks were filled at least in these vectors and instead of trying to like compare every client against every

client just that each client give us a thumb up or thumb down basically if they can manage this supposed repricing and now I'm talking about the actual pre-compile it's not the not the threshold to to the static holes quick advice but the actual individual precompiled and Alex rasping Alex blah so has been collecting these good vectors into CSV format I made a PR put some JSON format and I think they're like four or five different pre compiles with vectors and I think blah so it's

they're working on something some other vectors for the remaining picking parts and the stuff after that would be that yeah the client teams do their own benchmarking and yeah tell us the status

or base you

Tim Beiko: at least that would be super valuable like we've we just didn't have the bandwidth to set up the benchmarks to do something like this so if if something is up were obviously happy to do the work to make basically compatible with it and run it and report back but having someone else kind of set up that infrastructure is really a big help

for us yeah so it's not

Martin Holst Swende: it's not actually setting up an infrastructure

because I mean both rust and go and another mine guys the language has

kind of built in benchmarking capabilities so so what we're doing is that it's just collecting the input vectors

Tim Beiko: got it thanks

Alex Beregszaszi: I also think on the call we kind of agreed that for Berlin we we target the statical repricing and maybe we don't focus on repricing every pre-compiled and just get this one change in and then then we should have this process set up

to to do the repricing in further

Adwords

yeah I remember it being is focused on static call and then identify any outliers through testing that also need to be addressed through that chain through the static call change and then have a net and target those for being in Berlin and afterwards addressing other freaking piles that are that could be reprised this is kind of an open question but at what point would we consider making a change for you a version of Yolo net to include like eggs like down to 40 or 50 or something

Martin Holst Swende: I

personally don't see and a real problem with doing it pretty shortly because it's kind of a trivial change but maybe maybe we should let the Ola live for a little while longer so the people can actually interact with it

do other clients have thoughts on them

norman's are kidding the benchmarks for restarting cholera pricing shall be able to most likely tell you the results today

okay so we get let's make it a point to talk next week about next all

quartets call about and decide basically you have any thoughts on that I don't know if you it is there benchmarking in Javas that like something that becomes easy in the same way for the testing static call in your client like the real cost of static call yeah your mic is a little bit raspy I

can understand you though I'll follow up with different teams about about this over the next week and then we could talk about it and operatives get er and then maybe next week we can have we can include it in the

yellow yeah it's better what it's really quiet oh great oh I

still need to get you that call oh I'll get that to you today

Rai Sur: thank you

he was a little bit quiet so I'll repeat

just what he said for everybody else that the call that they've merged a tool recently for doing this kind of profiling and so they'll be able to get something pretty soon back to us I think that's good for that Hudson unless anyone has though the other updates

Hudson Jameson: sounds good to me thanks everyone

the next one is the yellow test net update I don't think Yolo was launched since we last had our call so could someone one

one more thing first I'm happy to do more of these VIP

specific calls so someone has something that they think would fit for that please reach out to me and I can keep making making those as we need them I really like the format and it helped progress the IP very well but we should do that we should tend to do that as often this makes sense

Hudson Jameson: yeah I agree I think that's great that you're willing to step up on that and it helps us do better time management for these coordinate calls so we're not spending a large amount of time discussing specific e ip's all the time okay next up is the yellow test net update I don't know if we've had a call since we launched it so if someone could give a brief overview

of how the launch went any problems we've run into and where we're at right now with it

Péter Szilágyi: yes so essentially we've launched we've put together yellow and I think launched it on Monday give or take and there have been a few problems one of the problems was me trying to be overly zealous and I just pushed every single component onto a single machine and Martin set up the Machine and gave it a beefy hard drive and obviously didn't notice the beefy hard drive so I could everything on the root partition so after about three days the whole thing blew up because it went out of disk but we did fix that since then

however we've seen something quirky tomorrow you started pushing a lot of transactions of the BLS test transaction junk transactions trying essentially he had a fuzzy corpus and just tried to push all the the entire corpus into transactions and shove them into the network and the interesting thing that happened is that essentially the signer went off on its own little world and the signer is creating blocks and not even guest is accepting the blocks created by the gap designer so something was really working there and originally I had a hunch that somehow maybe something got corrupted although it should really not

happen anyway I restarted the I just nuked the I mean I saved the state of designer for for debugging and i nuked it and started recent it and started signing again and it took about six blocks until it blew up again and yellow again the signer is in its little own world and no other node in the network except it so so that's that's that kind of means that there is some really quirky fault in gas in the gas signing where something essentially the sign of does something that is not accepted by normal blood processing so I need to check that apart

from that however and maybe March it has a bit more details as far as I know Mario's managed to actually he was running both an opening theorem note and Basu note I think or another mind I'm not sure which one of the two on on the yellow test net and I think both of them forked off at an earlier point so essentially we managed with three clients we managed to do a four-way split

of the yellow Network I think that uh I'm not sure actually I'll put him actually synced to forty four two one five block to the same one as gas clients stopped sinking with this kind of his own world signer so actually open

assuming and guess at least I built open assume from master the same point okay I should also get here that this behavior can be nothing to do with B LSP compile because tomorrow I mean after my race has Dom Falls the backhauls of test transactions just a smart contract and smart Kentucky is I mean I know the core of the contract I deported we at least I did and I see pls poster for guests did we both tested on different combinations like be like yes using assembly engine and another in the counterparty using

brass implementation and there was no divergence in results I mean it can be nothing to devious be like speaking polish yeah of course so I

Péter Szilágyi: my point wasn't that it was the be a speaking polish the one at fault here it was just internal status update of you know that this thing happened and we don't really know why and what's the cause of it so I don't know about the other Forks maybe maybe Martin has a bit more information about where the other clients diverged if they diapers maybe it's the same issue

I don't have any more information for basil

Karim Taam: it was the same we stopped at the same block of

get

and furniture

Péter Szilágyi: okay maybe just the error messages were different cool anyway so that is kind of the status of yellow it it works it just for some reason designer really likes to screw it with everybody else and I have no idea why because it's not something that we've ever seen before

okay thanks for the update Peter and everybody anybody else have anything on yellow or questions there's

an observation from watching discussions around Yolo as I've I've seen it been really helpful driving some more more

development conversations just watching the awkward EV skitter and people talking about it so I it's something we should consider doing more and possibly consider adding pseudo officially to the process of for getting things to mein that does things just have moved a lot smoother since

getting could there yet

Tim Beiko: two things I wanted to add one just so I understand the signer issue Peter does that mean once you you fix the bug in the signer will have to restart

yellow or can you just kind of swap [Music]

the sign will just discard that few blocks which is which designer created and nobody accepted those just go to the garbage can and otherwise the network goes forward

Karim Taam: yes I can see basically it's okay without restarting

Hudson Jameson: okay anybody else

Tim Beiko: yes sir this was James second point about multiple ephemeral test nets I think this is something we'll probably be looking at for 1559 as well once we get a little bit more settled on the speck they get this

launched basically as soon as possible to get some feedback on it because yeah it seems like a good way to get people actually using it then and to see what breaks in in in like a live environment

Hudson Jameson: um I actually have a question on 1559 real quick cuz it's not on the agenda but Tim or do you or anyone else know if there's like anybody working on I've heard seen on Twitter people are saying like we need mathematical analysis or like economic analysis on it is that something that's happening

yeah

Tim Beiko: good point not that I'm aware of I think the closest thing we have right now is Barnaby from the EF working on different simulation models that's yeah

we don't have like a full theoretical analysis and I know Nick Nick Johnson has been pushing for that a lot I'd like so I guess this is a call if that's your background and you want to work on 1559 please be me and I'll make sure to put you in touch with the right people to get this started we also have a discord channel on the R&D e server and and yeah I think I'd like to follow up with Nick a bit more and maybe have the next 1559 call at a time if he can attend is so that we can really capture his concerns there

mm-hmm

that's a good idea

okay

Hudson Jameson: we can go to the next item on the agenda

this is the EFI EIP review a I pee 2565 repricing the EIP 198 mod exp precompile Kelly

yeah they're just

Kelly Olson: some final changes made being made to the EIP draft so it won't change there's nothing really substantial we're just working through some some final benchmarking to make sure that there are no issues with the pricing for any of the test vectors my my estimate is that that will be complete early next weekend and final and we'll submit a PR to the VIP repository at that point

Hudson Jameson: okay great

so Kelly because it said that you have the

test vectors and since over the weekend we set up this benchmarking for a gift for another mind and my thing alex has something for party can you share the test vector so we can run them yeah absolutely so we I guess we have two sets so we have the current set of I believe I think it's eight to ten test factors that are used for the originally IP 198 right now and then we an expanded set of test vectors which like maybe an additional hundred with just random parameter values is one of those better to share with you guys then then the other and you want the expanded set or do you just want the the ones that are are used by the clients today I mean I

would it would be creative fluids expanded set to serve a positive which had helped us also just factors so I regenerate them once like manually once again with some another junkie data fantastic yes then we will is it is it best where is

Kelly Olson: the best way to put that is it best to put like a gist file in the EIP directly or is it better to

Tomasz Stańczak: I think that make it just as simple as possible just just shared a text file single text phone with the inputs and will be enough because Alex's format is it's just one of the format's and not necessarily the best one sir we can all just it if you just gave they the inputs that you're testing and

you don't even have to get the results because it just performance testing

Kelly Olson: Oh perfect great and in two miles what's the best place to to share that is that

on the Gator or

Tomasz Stańczak: wherever you feel it's best I can get there would be good or I can just set up some quick repair that it can be shared

wave form okay fantastic yes then we will will absolutely do that

another question out of my curiosity what did you decide on existing performance of open soon at least because I think you have spent some time to find

the solution for mod expand opens here and in Rastan general I think was a little bit slow or you're replacing yeah so so unfortunately be

the solution that

Kelly Olson: we arrived at with open aetherium is just to modify the pricing formula without changing the underlying library so i artem did try I believe you know the GMP version for rust but unfortunately there are some compilation issues on windows so there actually are no major changes to the underlying library for any of the clients it's going to be just a pricing formula change to better reflect the complexity I believe there was a small version bump done to open aetherium recently but yeah no no major changes to the library

Oh anybody else okay thanks Kelly next up item number five oh

I was I was talking in oz on mute oh go ahead as so is there so the consensus is to go with option two or has there been a or is that now off is option one then now on the version that they're doing yes option option two is is correct which is yes yeah so unfortunately option one we couldn't go with because open aetherium had had to slope and implementation and so we are going with option two okay and then you'll make a an edit on the on the EIP to show that

Kelly Olson: exactly yeah that should be an early

neck umm.we

I feel like we should move this

in the EFI because of the way the conversation has been going it's already in the

FI it was yep

I don't know if we all right cool 25 if we ever had actually motion to have it happen

Hudson Jameson: we did I forgot what's meeting but yeah no it's it's in the FI okay well you know what actually I'm looking at it right now the EIP is outdated but I we need to just look at old meeting notes and see if it's motion to go in but I swear we did we did at some point

I remember bringing it up last time saying but we wanted to bring it up later but then it's never like that we we haven't

actually had the emotion of doing it we just talked about the motion of doing it

ah does anyone object to having it

Hudson Jameson: - does anyone object to having this EIP as an e fi meaning that it has the go-ahead to be continued to be worked on and could make it into a hard fork likely okay I don't hear any dissent and we've been following this one for a while so and there's been a lot of good cooperation it's a really well-written EIP so I think that it's fine to go to EFI so that motion passes

I guess we're calling it motions now oh yeah that's a good name for it I guess I I just I just don't remember ever calling it that and yeah so just let's put it in EFI sounds good awesome next up we have Alex Stokes talking about an update for the eath 2.0 deposit proxy contract that utilizes EIP 2537 the BLS curve operations Alex you can go ahead

Alex Stokes: yeah everyone pretty straightforward there's an initial sort of v1 of the contract I'll go ahead and drop this in the chat here

for those who aren't aware there's basically a really critical smart contract for eath to the deposit contract and basically that's how you enter into this new system is that put in at a positive eath along with some credentials into this deposit contract there's a bit more sort of rationale and it's read me that I just put in the chat but basically there's some verifications that don't happen in that contract in order to kind of keep it you know easier to get correct just given its importance so this contract is another one that wraps it this proxy contracts and the important thing here is that uses the Berlin pre compiles so it's kind of a client of the pre compiles which i think

is pretty nice to have ahead of time so generally just wanted to let people know about the contract I'm looking for any review so if you want to look at it for Mike a security standpoint please get in touch I'm working to deploy it to Yolo although yeah with the seiner issue we talked about earlier been having a little trouble but it's on my to-do list and then also working to integrate it with the eath to deposit tooling so that you know either every validator uses this right as sort of an extra insurance or they had the option to do so or something like this so yeah that's pretty much it and if anyone has any questions or anything I'm happy to take them

ok

Hudson Jameson: anyone have any questions

so

assuming I guess

Tim Beiko: just to make sure I understand this is really a proxy contract and not a verify you're right where you actually send the funds through that contractor that relays them to the deposit contract rather than just verifying your inputs right

Alex Stokes: right so yeah there's different ways to break it up right now with the contract does is you send the full deposit along with the eath and so when I say full deposit I mean like their credentials that end up going into the f2 system so all of that data plus the eath goes to this contract this contract verifies the BLS signature to make sure that's correct because that's what we've been seen is that basically you know there's been some incorrect you know signature creation and then that leads to an invalid deposit and

then the eath is basically lost so this contract helps because then when it does is check the bill a signature if that all passes and it looks good and then does a call for you to the deposit contract itself so it wraps it in a sense if it turns out that like it takes too much gas to do this way or something we could actually yeah split it out so that the verification lives sort of you know alongside but then the actual call to the deposit contract is you know done by yourself separately

Tim Beiko: great ok that's that's really valuable and I guess my other question is is there a plan for like a formal audit I don't know who added the deposit contract for like the original one but

is there a plan for like a similar security audits by the same

four right

Alex Stokes: yeah I mean especially if we move ahead integrating this with like sort of the more formal is to deposit tooling then yeah we'd want to you know look that pretty seriously there's not currently a plan there could be a plan I think run time verification I believe did the initial deposit contract so we might reach out to them but yeah really anyone who'd want to look at it right I think the upside is it's like pretty simple and straightforward so it's not not that

while all right

Hudson Jameson: other questions there is

a telegram channel it's dedicated to this contract and looking for gas optimizations and bugs it already has a handful of people in there from the solidity and security community looking at it but it's very ad hoc right now and so we could definitely use more help just looking over it and if you're interested yeah reach out to myself or Alex and we can add you to that or if you are listening in on the call and want to help reach out to us especially if you're someone who could do an audit for it it's stuff like that so thanks for the update and we can move on to the next item on the agenda number six

account abstraction research update with we'll go right ahead everyone I just want to quit give a quick update on our progress the initial spec that batalik had put together which has some limitations we actually we just finished putting an MVP or putting that together and death so we've passing tests an internal a test net right now additionally we have a tool that is propagating the transactions through and used as a measurement tool so we're collecting metrics right now and cleaning up and doing everything around that so we we

plan on starting a bit more communication with the community soon around this will likely have a have a call and we'll be doing a write-up in the next in the next couple weeks especially looking at the data and the metrics that we get from this one thing to stress this is overall a feasibility study we you know like to explore the possibility of bringing this into eath and to ether 1x but right now this is a feasibility study and of course there's no guarantee until we get a bit more people involved in discussing but we are I guess we we believe we're showing a strong feasibility this current time and

so we'll be expanding this shortly to go beyond what the initial proposal was and support multiple transactions per account but we will be doing a bit more research and some write ups and some updates on that soon so just want to keep you guys on today on what we've been doing I think we'll have a bit more meat for people to process and digest here in the next couple weeks and hopefully that should spark good discussion overall

you okay

Hudson Jameson: any questions or comments on that anybody we've also been exploring how that intersects intersects with the the

general discussion and meted transactions as well and how Account abstraction overlaps with that we've been involved in the discussion on e3 search recently we kind of see it all under the same similar umbrella as well so we've also been putting effort and time into

that

did you see the updated version of the oil and gas proposal from Alexia that talks about meta transactions we did we responded that and then we posted a new post on e3 search that continues to expend some of those discussions as well great

all right

Hudson Jameson: and if anyone wants to go back over what we'll just discussed or go to any of the links for the spec

or the discussion on e3 search it's the in the agenda it's the latest comment that was posted about half an hour ago I think that also includes oh can you post a link in the agenda or in here to the spec you made in death well or to the implementation you made it your Fork of death oh yeah we we were gonna put up a yeah I can I can put a link

in one moment

Hudson Jameson: perfect all right thanks for that and if there's nothing else we'll go to the next update this is James he made a calendar let's let's talk about it

I made a calendar it started as

being for the all core dev calls and then has since expanded to include eat to calls and the IP IP stuff and it's a public we follow Abel calendar managed through Google but you can also use other clock like there's you can use other clients to do it so anyone who wants to follow or be added on the list so you get emails to remind you to attend calls I am happy to add you

Hudson Jameson: okay thanks for that next up we have item eight testing updates anyone have anything testing wise that they want to discuss about their clients or the

ecosystem

yeah so one thing I would like to mention is that it would be really nice if we can do cross testing on using state tests instead of shoving things to Yolo and I'm not really sure about clients have implemented some state has support for Yolo Jeff house I'm not sure about the other clients but it would be real nice you guys can do that a lot more efficient I was

what would it take to do that

good question so state tests have well they basically encapsulate a transformation from one state to the next and they have the pre state they have the transactions that should be applied to send free State and they was contain something called well they they expected post state hash but we don't care about that for passing because we look at the actual instructions executed and compare them one by one and in order for so the state test besides these things it also has little string where it says what rules it wants to be applied and these rules can typically be Constantinople frontier

or bicenthium and in-depth so I made a proposal I think maybe two years ago but clients should should accept names on the form Constantinople plus twenty three fifteen and I'm quite certain that no one actually implemented that aside from us but second best alternative is yeah if we just add Yolo one so we can have a status but network name is Joel obi-wan or yellow one or whatever preferably the same thing that gets passed because otherwise things get messy and then just yeah the Yolo chain rules are active at that

transition so if you already have implemented status and it should be fairly trivial to do this okay

Hudson Jameson: anyone else have questions or comments

and I just wanted to add that we'll be there probably quite soon because we wanted to finalize this hive work to execute the consensus test from hive and when I will be able to entertain the new tests for the new IPs I'm not sure if I've added this support for any additional he I please but we

can add it as well I think thinking of the code he thats not yet there mmm say I hope that soon we'll have state test results for you [Music]

Martin Holst Swende: much appreciated thanks

I think we should add some of that language and to the yellow AIP perhaps Martin something we could follow up on writing writing those out and then parenting tracking state tests based on client

client for client okay

Hudson Jameson: anybody else

all right next up we have review previous decisions made in action items the notes have been merged if you refresh the page it should work the link to the notes so for decisions made last time 88.1 is the state test for yellow v1 should be regenerated under that name and should not carry the berlin name an 88 point she was the opcode change proposal to be implemented that's a little vague we might want to be a little more specific about that one I forgot which one that would even was for last meeting

but we can move on 88.1 this is on actions required James Hancock to continue to update the Berlin and yellowy ip's including commit hashes that's been ongoing right James

yep that'd have been a femoral test Nettie IP to be merged 88.2

that has happened

8.3 James to follow up with open etherium AXA command martin to discuss AIP 2315 after the call yes 88.4 access to make a PR to update op codes for EIP 2315 i believe that happened - did that happen Alex axe ik the PR to update the

op codes for 2315 yes that's right

Hudson Jameson: 88.5 James Hancock to coordinate with axe ik and interested parties about precompiled gas cost changes call that happened eighty eight point six Kelly to continue working with open appear a theory Imani IP 2565 that has been resolved in the e IP will be updated right Kelly

Kelly Olson: correct

okay

Hudson Jameson: I didn't do a great job of writing down the decisions made in actions required today but it sounds like what was one of the was the one that was on the tip of my tongue

the efi for yes yeah lie for a I P 2565 to be moved to EFI officially and the EIP to be updated that was the main one following up on state tests for clients and how that relates to Yolo

okay and is that something for Martin you or someone else that's something for me to follow up okay with Martin and others okay episode James Hancock to follow up with Martin and other clients on state transit state transition test was that what it was yep the next call look at adding the

pre-compile gas cost reduction to Yolo okay next call at gas cost pre-compile of reduction to yellow reevaluate it or evaluation then yeah sure other people is

there any decisions made or actions required for this meeting the people have

yeah I think there were two testing things so there's the state test but there's also the test vectors for the pre compiles and those are two different things right yes as pre compiles going to who was it that requested those that you base you yeah so well yeah we'll

Tim Beiko: need to look into

those and we'll probably reach out as we're doing it

Hudson Jameson: okay that's another one anybody else okay does anyone have any final agenda items that we haven't gone over things they want to say before we in the call super early

I'm on vacation next week so I'll likely get to this when I get back

Hudson Jameson: cool

get to a lot of these things

Tim Beiko: enjoy your vacation

thank you

Péter Szilágyi: very quick update on you know so I mean I've been digging into what this might be and it

turned out that a century designer was not Yolo enabled so it was running an old version of gasps and apparently for some reason DNS resolution doesn't work currently on on that machine and that's why docker actually failed to pull a fresh version of yeah so fun fact that's why the signer went off on its own little world because if it's actually didn't have the yellow quartz enabled so we're trying to fix that

this is super strange because if it didn't have the yellow enabled at all and both me and virus what we did which is frantic contract which calls the pre compiles

which apart is a yellow and we also taken their output data from the Cole and comparison to expected output to the free compile and those tests passed so maybe it did use some older version of like pre compiled code or yellow features but if if it didn't have yellow features enable at all I would expect those transactions to fail immediately yes the signer run originally I deployed it I deployed it to my own custom build

then when the whole thing went out of disk it switched back to the default version of GAF which was all done didn't have it enabled so that's why it started failing after 45,000 blocks if you are running own version of gap that is already enabled in any new version of campus you have locally running it's only about assignment which is running an ancient Persia guess happens to be on the machine oh okay so the switch to the version which have your features happen at some point not as the start as a chain

Péter Szilágyi: no it was in middle when the whole network got stuck and we rebooted designer then it switched to the old version because then I I did I didn't occur to me that the gap version on that machine is ancient

and since for some reason DNS resolution doesn't work on that machine docker didn't manage to pull a fresh one it's a bit of a well I just wanted to say that

there's nothing about oh well then let's explain perfectly at least what it was a normal behavior

Hudson Jameson: okay anybody else have anything final

it's a good reminder like Def developers shouldn't be looking at Yolo to test their things unless you are more actively working on the EIP s helping evaluate them or a client integration

testing cool

Hudson Jameson: and you're just saying that

so people don't deploy their daps and think it'll stick around right

yep yeah I'm just sending it out many times so eventually everybody understands

yep

Hudson Jameson: that's why we call it an ephemeral test net which is a very meta name okay it sounds like that's everything the next meetings gonna be June 26 1400 UTC thanks everyone for coming this is a great meeting

everyone have a great day bye alright thank yous [Music] [Music]

[Music] [Music] [Music] [Music] [Applause]

[Music]

Speaker names adapted from ethereum/pm, CC BY-SA 3.0.