All Core Devs - Consensus #40

Transcript

[Music] [Music] [Music] so

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

[Music] [Music] [Music] hey joseph hey raul hey alex we are getting started

right now howdy okay i believe we're live um here is the agenda no surprises okay um testing and releases uh we released v012 0 last week um this took me a lot longer than i thought it would i apologize for any delay there um upgraded bls to latest itf standard some fixed rewards and penalties as well as a slight rewards and penalties modification to ensure that if you are performing optimally during a leak

you don't lose anybody as was intended um other than that some networking changes uh based off of kind of continued feedback loop with the nets and clients i know y'all are working on this let me know if you have any issues um i hope there's a big refactor in the rewards and penalties and how they are tested just in a much more granular fashion i really we found some bugs in uh serenity when proto is updating that i i do think that we have much better coverage at this point um so hopefully uh we won't see any whereas the penalties works but uh if we do we'll handle it um okay so that uh we also have alex's um from tcrx for choice tess i did not end up getting

those into the v012 release but they are at the top of my list to get into a v0121 1 and so those are coming they look good it's just a matter of figuring out the proper way to combine this like external repo with the testing flow release vectors so that's coming um i don't have a good update on stethoscope the network testing that was being worked on proto do you have any updates there uh no backup tracks really um so well um we have these two different paths so rumor of tooling for network testing which

is you can already use more advanced and then the stethoscope project which tries to tie it together into test factors and integrated clients this is like a bigger effort to attack some markline okay um i'm hoping we can get something out to y'all relatively soon uh i know there was a number of last minute bugs some around genesis and some around some just basic networking uh prior to the witty watch which we can talk about in a minute um a couple days ago so any type of this network testing right aid oh hey electron um just wanted to know status of stethoscope if there's any progress there and what we might expect

if you are there all right well um we'll get okay hey hey hello sorry i think we're like we can't we can hear you now okay um not much of an update i've been on vacation for the last week and a half or so um but uh uh yeah nothing much stopped it down past the last networking call update yeah okay thanks um i was saying that we we did run into some last minute bugs launching the witty test net um so getting some of these success factors out relatively soon would be i think really useful um but thank you yeah we can talk offline

um other testing and release updates or any questions about the release great um i'm going to swap client updates and test nets and go ahead and let afri talk about uh witty and others to bring up any questions or comments about test nuts and stuff okay sure um i give a shot we did a couple of ten of attempts to relaunch the schlesi test net the schlizzy testnet

revealed couple of issues and eventually lost the finality and we i have shut down my last validator today so the schlezzy testnet is officially dead now um and i did a couple of attempts to relaunch a new test net the difference between witty and chlis is that we have now three clients instead of two clients in genesis so this was yet another dimension more difficult to launch [Music] so there's a steku lighthouse and prison and guinnesses with each two validators in the beginning we had some hiccups once again we had a different genesis

time for two clients [Music] and uh in the end it figured we figured it out and we had just launched yesterday night i believe and we even had to deploy a last minute hot fix on one of the clients but in the end we have almost perfect liveliness on the network and yeah we have this network up now and people are encouraged to um break it and yeah that's the state of videos of today yeah cool um i think client teams are generally curious as to the plan in the coming weeks and months i would think maybe you and i can work on a

at least just some bullet points on what the plan is i guess with test net restarts doing larger test nets and that kind of stuff before we we do a larger public launch yeah so i can um so i envision that we try to launch as many test nets as possible whenever we we see a reason to launch a new testnet either because the old one fails or we have a new version of the spec or we can let's have rather more small and fast failing test nets before going into the more stabilized fast phase sorry great um one item came up if anyone wants to take a look here uh

it's primarily it's a adding the ability to tune when what time of day genesis happens um if afree continues to launch test nets with main net configuration it will happen at 2am constantly at his end i know australia that you're really happy that it happens at 2am every time uh but for the sanity of of aphro we might consider adjusting it take a look at that issue um but yeah we'll we'll get some more concrete notes out on the test net trajectory or at least the tentative test that trajectory that was alliteration um okay cool any other thoughts on this before we move on thank you afri uh there's a heroic heroic last minute

effort on your your and and many of the client teams to get it working but it looks good now okay great client updates we will start with lodestar hey all so past few weeks let's see um we published a new version of our bls library that uses the updated harumi uh code compiled to wasm so hopefully if you needed that it's available and now we're basically just going through the 012 updates

um working on updating gossip sub as well to v 1.1 and i guess i'll be kind of curious to hear what if everyone else is working on that awesome issue as well but uh yeah that's that's basically it for us yeah and i know age has been looking into it um we can talk about that a little bit after in the networking section if people want to share some notes on that thanks thanksgiving nimbus hi so on the networking side we have been investigating and solved interrupt issues with lighthouse

we had the prototype passing issues we and we published this morning we updated the multinet script in the multinational repo so that you can create a network with a split of 50 50 lighthouse and members validators to investigate more easily interrupt issues we also add the snappy fixes and we also realized that gossip sub assumes that we can validate an attestation immediately when we receive it but in reality we have to wait for the block uh to be available and sometimes attestations are received before the blocks

uh otherwise uh regarding test nets we have a make witty added to the makefile so now you can connect to it easily and we were investigating thinking band in schlesi but we are moving to viti to investigate that and also one of our test net investigation is regarding the few peers issue where nimbus only had a couple of peers while thinking compared to other clients on the course back side we have the bs changes merged in a crypto backend and we have a toggle so we can now switch between v 0.11.3 or v 0.12

for a test net of fusing purposes and we had in at the beginning of the week we received all the audit proposals from auditing firms so we are right now selecting vendors for audits and that's all nice exciting um and does nimbus currently run into the same sinking bug on uh woody um i don't know yet because we started to use witty just this morning thank you very much

but basically the thinking one of the singing bug is that uh as when we are within the last 100 blocks we changed thinking algorithm and uh and we stayed behind got it okay taku hey that's me um so we've started doing official releases of techo every two weeks with release notes um tecu's been updated with options to run on the new woody testnet with respect to v0.12 the gossip sub v 1.1 jvm lib pdp implementation is almost done and the bls updates are under review

our open api schemas have been updated to work more easily with code generation tools um we've updated our eth1 data handling logic so that we no longer need to query for world state data so that means we can run again against fast synced eth1 nodes without worrying about missing world state we've added peer filtering based on you know e and our fields there's some ongoing work to improve attestation processing and we fixed some uh jvm lib pdp issues related to handling large stream packets and that's it for me great thank you and prism

hey guys uh from prism here uh yeah we are complete with 0.12 we've been running test nets uh so far so good seeing 100 participation on uh different testing configurations for v 0.12 so uh hopefully planning a test net restart for topaz with that config version um working next on releasing a lot of memory improvement features into master so we have a lot of experimental features that have different degrees of stability that we're trying to get really solid and make those become defaults also working on optimize at the station aggregation the our slasher has making good progress it's been become playing a lot nicer with beacon node so uh previously it would overwhelm beacon nodes make it difficult for them to you know to also handle validators but

now things are getting better for on that front uh fuss testing uh is going well uh and our audit from quan snap is in progress it's also going pretty well so we're excited to see some preliminary results from the audits uh yeah that's it from us cool um do you know the range of history that you can find slashable attestations with slasher i knew it was on the order of a few days i was wondering if that's longer now just curious yeah so we've been working a lot on the look back we're able to do historical detection just fine so we're able to just go all the way back from genesis and really find slashable offenses so that's been going pretty well we're actually finding some trouble with real-time detection dealing with kind of making sure we get

all the right attestations from the beacon nodes and that sort of stuff but historical detection has been going really well okay yeah cool thank you lighthouse hey everyone um so we've been we've on our consensus code we've started uh an order with trailer bits um so we have we've got the the audits kind of being done in two parts which is the consensus code and then the networking code um we've delayed the networking code because it still needs to we still need to kind of do it uh finish some of the underlying protocols and um harden it before we actually get an order of it so that's going to be a little bit delayed

um we've been kind of doing a lot of debugging with the witty testdown launch um expanding some of our apis to kind of help with some of the metrics and logging in lighthouse um with the witty test now we found that uh our disk v5 implementation is chewing heaps of cpu um so we've started kind of like a structural rewrite of of the rust dsp5 implementation to to fix that we've started working on rust gossip sub 1.1 we're still working on like an internal peer reputation system and updating to version 12. that's pretty much it from us a quick question on on uh on the rusty of b2b stuff

like how much has it diverged between your branch basically and um i guess parities uh in the pcb yeah so we were maintaining our own fork and using that because it had got some subfixes and causes up changes uh as well as disk v5 so one of the issues with just v5 is that it was architected to be built inside of lib p2p um so what we've done recently is ripped out disk v5 so it's now like its own standalone thing which allows us to kind of rebuild it to be more concurrent use more cpu cause it will be a bit nicer so it's not it's not actually going to be put into the video anymore so we've ripped that out um and all the gossip sub stuff has been merged down into master

apart from the new gossip sub 1.1 which is still being developed so fundamentally at the moment lighthouse uses the the official the pdp rust the b2b um everything on master from that anything else we've used is either in its own repair or something or somewhere else so we don't diverge at all is the answer that's good news because we've been thinking which one's the target for you know basic rust interrupt testing yeah yeah just use use the official one cool trinity hey everyone uh let's see the big thing is we've added a full-time

contributor i think grant might be on the call uh so that's exciting to help move things along a little faster uh the the latest sort of code update is we merged in a big networking pr to implement the latest old p2p protocols uh so that was a bunch of bug fixes to to pilot ptp itself and then general improvements to stability and then you know all the gossip sub and the sort of the rest uh request response protocols there the next step will be working to sync witty along with some spec updates to get up to version 11 3 and then looking to version 12.

cool thank you um and from another mind uh slides built code code for attestations and this is now pending merge into master uh tomas has built the code for connecting with database the merkle trees uh previously we're only testing things in memory um tomas is also testing multiple validator onboarding soon with the numerical tree code uh so i think this is like remarkable markle-backed uh state and other items um they're still updating some code for v011 um moving a junior dev full time at eth2 to ensure the tests are running properly and they're expanding the mother of for c sharp wrappers have better control over the connections they have a senior

dev who has experience of both rust and c sharp so may be looking at the improvements uh in june um tomas is working on adding another mine heath wand another on e2 connectivity for whole flow and but probably won't be able to join woody before the end of june we'll see maybe thank you tomas doing god's work on the 1559 call cool um great so we will move on to research updates does anyone have anything they want to talk about um we'll go for txrx um so uh this past uh since we met last time

um dimitri has completed two uh write-ups on um uh discovery v5 the first one is called comparing discovery advertisement features for efficiency uh enr attributes and topic advertisement real sexy titles uh discovery peer advertisement efficiency analysis great write-up set um uh cover and simulate some of the um efficiencies and uh inefficiencies of discovery v5 and uh those one of them is an e3 search post the other one is a hack md probably going to be an e3 search post um coming soon uh for that but the heck md is available for y'all um last time i misspoke about ontol

um this is alex is developing ontol which is a pi spec transpiler it's not used for transpiling fork choice tests but um he is working on fork choice tests as well um like separate from that effort um and so he's been moving on that it's been transpiling into uh kotlin code so it's taking the pi spec and transpiling that and mikhail is integrating that um transpiled uh ontol kotlin code um into tekku in our tx rx repo um not into the uh teku uh master right or worth branch um

uh he uh johnny's done some test nut analysis uh he had like a pretty entertaining tweet that shows kind of like some of the uh breakdown of the topaz network um and uh he's kind of created a uh prototype tool for test net analysis that is auto generated with the c uh ci job so yeah that's all based around the purple and network monitor work he's been doing um and right now uh we're working on upgrading the network agent to uh age manning's uh disk v5 code so that the crawl will be more efficient

and we also released right up on probabilistic uh crosshard transaction simulation uh and it shows some interesting results on the effects of network throughput um i'll drop a link to that in the zoom chat this uh the research for that is gonna um keep going but we're gonna use analyze some eth1 data which we're in process of doing uh to make the simulations for crosstalk transactions more realistic and kind of moving towards working on an alpha alpha cross chart spec um in the next coming weeks

that's it i'll drop a link for that cool thank you cool i'll i'll go next uh so quilt has been working on exploring account abstraction um and so this has been there's kind of explained this in the past but it's kind of twofold um one we're doing the the work on geth right now um and one of the one of the things is that one we'd like to get this into either one if if it doesn't move forward on each one because the changes are too heavy uh the idea is to bring this as one of the guiding structures of the account model that is built

for eth2 as a whole and so uh we've been doing this um with respect to eth1 to get some tangible data in what we currently have so right now we are actually integrating all the pieces and we should have a uh basic mvp the basic mvp that the talakan specked out finished uh pretty soon um so that that's within the next uh next couple weeks um next week or two and uh part of that too is we've done work on building a tool to dos uh to dos the design so we can begin looking at how how the transaction for mempool

if we explore an abstraction um can stand defensible um in in regards uh to some of the you know some of the new constraints that are added with that so that's where we're at great thanks well if there's nobody else um yeah please i would also give some update from the iwasm team there would be i think two relevant um updates i can give to it too so we continued a bit of work on the e1x 64. and the next step there is to look into yanking and what we have

done so far is we tried implementing yanking as a layer two solution on top of of the ethon x64 variant one um so what that means is um on the sender side the contract itself would serialize itself because it can read its own storage and would send all that data through uh through the receipt model and on the receiving side um there there would be a need for a factory um which then can create this contract and set the the storage recreate the storage um the reason we did this we wanted to see whether there's a need for protocol level support for yanking

and it seems that if uh if we indeed want to have yanking to be useful then then there is a need for protocol support because there's so many overheads um one of the main overheads here apart from the need to to read the storage one by one in evm is that one needs to serialize everything into memory keep it in memory and then save it as a receipt and memory is quite expensive on avm um yeah we do plan to prototype the protocol level yanking support and then publish this this variant too which talks about yanking and then another piece of work we have been looking into is regarding caching and so this is basically on on phase

two if there would be some kind of a standard witness format then there could be a potential to introduce what we call a shard committee cache where there would be a cash for the transaction businesses so whatever is incoming there would be a short-lived cash uh a few epochs long cash which would reduce the transaction witness size but the block witness included in the shard blocks those won't be bothered by the cash those would be always full witnesses so that means the impact of this caching would be restricted to block proposers and it wouldn't affect any anyone

outside of that especially nobody on the beacon level right and specifically transaction broadcasting and or potential like if there was a third party providing a block to them yeah i think only transaction processing so we had just a rough idea sketched out and we we uh bugged danny to give some feedback and um they got some great feedback from denny um but we haven't finished updating um this this rough idea to make it you know more useful based on that feedback but we do plan to you to share it um soon um yeah these are the two things i can i can mention cool yeah yeah i that does look like a based off of my

reading an effective place to put a cache i guess my main question would be the overall reduction in bandwidth that we might achieve through it uh which i guess with some experimentation we can figure out yeah yeah also um after this discussion we also realized that maybe this idea could be applied in some different fashion to e1x or stateless ethereum so probably we can also look into that cool thank you um on the spec side now that these are 12 is done um charway myself and a couple others on our team are spending a lot of time making sure

that phase one is well tested uh well structured and has all the components that you need to do prototypes and implementation this includes finishing the work in progress validator dock adding much more test coverage uh working through any bugs so you don't have to work through them and even building out the base of the network spec so this is top priority on our team and stuff you can see a lot of movement on very soon cool any other research updates great um next is networking we have a networking call in a little bit i might

consider doing one soon if there is demand um as cayman mentioned there's a few people working on a b11 implementations of gossip sub um is there any questions anyone had to post the group or any particular learnings or gotchas that we run into that are worth sharing i guess the question to decide is whether we should support 1.0 or not at all like even though in theory they're compatible right uh the current networking specs says 1.0 for example does it i can't remember if i put a monster may on there

all right last week at the microscope gotcha yeah i think if anything there's an allowance for oh yeah clients must support gossip sub v1 including the v11 extension because v11 is really just additional components on top so i the intention was to write it in such a way that you must support this um i can clarify that if there's any confusion in the way it was written um the for the time being i think we're gonna see at least on the test nets for the next few weeks uh a mix which is a reasonable test uh but there's no need i think to go to production without it

now you know what now that i pulled the heat as well yeah there could be there could be a second must in there that would make it very clear yeah based on the testing results by protocol labs um it's a no-brainer to require it yeah cool um use the networking chat in the discord or you know one-on-one chats if you um have questions and things as it comes up david from protocolab is also very willing to

help if there's any issues on the v11 upgrade um is anyone does anyone have v11 running on testnets prism i guess would be the only one do you all have that integrated on the current woody if you don't know then just let me know after we can talk about it i'm just curious okay any other networking items i can go so yes yeah uh we've been uh discussing uh a change to the this v5 uh wire protocol on over and on on discord and i made a very

detailed proposal for it and the idea is to redo the outer layer wire encoding one last time before finalizing the spec basically so that's the that's that's that's one thing i have received a lot of thumbs up on this proposal but we haven't really made a decision yet so i would like to get a decision in pretty soon because uh yeah i kind of want to release the final version sort of of the like the initial final version of the spec um so if everyone could please uh state your their opinion one more time or just

like let's just find come to a decision there and then the other thing is that i've been looking into the uh proposal uh from the what's his name again i keep forgetting it's uh zil on github but i always forget his real name uh it was already linked by joseph earlier and uh we are still sort of discussing things out there so the the mechanism that he proposed uh based on basically reading dmitry exactly uh reading other notes condemn your tables using special operation which can sort of like pre-filter the notes on the server side

uh the proposal is kind of a short-term game i guess but we still need to answer the fundamental fundamental question whether this is really a sound proposal or not so one thing that we are still that i'm still worried about there with this proposal is that it cannot give um like there's an issue with it because it cannot really uh give you like you cannot find 100 of notes with this you can only find a certain percentage of the network and that percentage grows lower uh the larger the network gets which is kind of uh yeah i don't know like it's it's it's very efficient and when it

works but it's not theoretically sound like at least not 100 so we're still trying to figure out how to get move forward or how we can turn this into a sound proposal got it thanks felix um one is is a blocker on this wire protocol the discussion of quick yeah that's one of the things right now where basically like i mean i i heard that it's going to have the uh there's this idea to uh reuse the quick packet format and uh i haven't heard back uh so i don't know if like this is still

this discussion is still ongoing or if yeah we're investigating it we should get back to you like tomorrow at latest yeah i mean it's not i'm not in a super big hurry it's more like i just kind of want to make a decision on like how to move forward with the basic wire protocol this week because i still need to update the the actual spec with all the changes and track the implementation and so on so it's like really only the first step now and i kind of wanna but thanks yeah we're kind of reading the quick spec right now to figure out whether um whether it's feasible so one of the reasons we don't have quick supported in uh implementations all implementation is a little pdp right now

networking spec is um at least last we checked tls 1.3 support is there's not a lot of like widespread cls 1.3 support um across many different languages and so that is something that we're interested in integrating into the pdp spec over time but that was the main blocker was the tls 1.3 so that might be a similar issue um with requiring quick on the discovery today so it's not really that like the plan is not as far as i understand to run the discovery over quick because the quick does way too much for that it's more like to basically encode the discovery packets so they look like quick packets so basically master is

coping traffic as quick because it would mean that we don't have to worry so much about it getting i don't know blocked by a firewall or something although i still think that like this whole firewall discussion is a little bit of a um yeah i'm not really sure what to think about it to be honest yeah okay i understood uh i have one more thing though so um we are working we are starting to work now uh in the guest team on a sort of official like test suit for the discovery and i'm hoping we'll have it done in like two or three weeks so we'll have like a basic sort of test you that you can run against like any client to see if it like to cover some common scenarios

because we've already seen some implementation issues in the current testing that'd be badass i've got two questions um the first one is there were other changes that i that you were talking about a while ago one was uh if i recall correctly in the find notes request instead of doing like multiple requests to get all the buckets just to group them and just have like multiple distances in the fine node request is that still on the table yes so the the changes that are coming to the pro to the final version uh are going to be one sec i can give you the list real quick so um the idea is that uh in the final initial version whatever

we want to call it like version one like 5.1 or whatever we're gonna have a complete description of the session cache um there's gonna be a change to the version number which will be version number one instead of five um there will be this multi-distance final request uh we will have the uh connection pre-negotiation uh request uh for now it is called talk rec this thing is totally like if you don't use it it's basically gonna be five lines to implement like it's not it's not a big change uh but we need it for another protocol so that's why it's gonna come in uh the topic discovery stuff is gonna be marked as a draft in the spec still but everything else is not going to be a draft anymore and we're going to have the new encoding

and that's pretty much it like these are the plan changes okay from the people from what i've seen i i think a lot of people are on board um so it sounds like we we should just make a pr to the the f2 specs to match that version number and so that's the discrete path we're using um yeah so basically i i will i will yeah sorry what yeah the other question that i had i don't want to kind of derail you is um if f1 is moving across to disk v5 are you in f1 are they going to be in order to connect peer peer-to-peer use using enr's so i know that we've had this discussion but enough kind of potentially causing a bit of havoc in in usability uh-huh so the question is in f1

in order to connect two f1 nodes uh if you're using disk v5 do you use enr's so in you mean as in typing in eons on the command line oh what's setting up boot node or if i have one node i want to connect a one node to another node oh i see oh yeah that discussion so uh i mean in general i know that the enr is not the most like readable format for humans that's totally true uh for at the moment uh we mostly just use the uh dns based uh in our distribution mechanism that we have for bootstrapping and uh that basically means that like we just have a reference to that dns name and it's public key in the source

code and then basically the boot nodes and stuff are just fetched by dns and um when we will move to the this v5 basically is gonna be the same i mean there's we're definitely gonna have the like we're definitely gonna keep the dns uh we're gonna set up probably gonna set up a new dns tree for the v5 to find the entry points uh and um in general you can still use the old like enode url format which is great but inflexible and you as well you can use the enr text form if you want but i know that it's not the most convenient if you want to just like type

something in yeah so so fundamentally my question is just that you will be using enr's fundamentally um yes so we are using enos now with the version four even yeah so there's no trick where you connect via just like an ip address and then download the you know you actually have to type you have to actually have the e right well there is a way to like connect if you have the public key in the ip address and the port and that's the eno url format but we could make another version of that or just support multi-adder or something if you need a readable representation yeah and they're unsigned correct yes i mean they can't be signed like that's

the thing like yeah they have the pub key but they are not signed and so the thing about this is like the enr is not the greatest when it comes to you know like says admin stuff because they are signed you cannot change the content of the enr ever um this is like very nice for certain things and it's definitely good when there's machines talking to each other but if you just want to type in the ip address then you can't do that and i know that it's i know there was this discussion and it's it can be annoying if you have to yeah so but my recommendation for e2 would be to go with a multi-adder because you are already kind of using that anyways and it has a text

representation as well so long term we should probably all agree on multi adder as the readable format but when it comes to pasting nodes into code or something i would still go with the enr because it allows you to basically prove to everyone else also that you are not cheating and this note is really who it is they give you this info and so is there anything that we actually need to change on the spec to support enode or multi-adder for initial connection as in once you connect once you connect and you know the pub key they're going to give you their updated enroll anyway you don't i don't think you need to change anything in the spec because it does the spec doesn't say

that the client has to you know provide a way to enter an enr to connect uh this is totally up to the clients right i think to make that okay so a standard a standard multi-header that ensures that it has the pub key satisfies our requirements yeah you must have the public key uh i am also thinking about but this is more like a long-term item and i don't want to hold up a call too long i am thinking about um um adding a uh an enr identity scheme using et25519 uh keys because it's gonna be much faster during the handshake so if anyone's interested to talk about that then you just like hit me up

got it we didn't invest we actually tried to implement the initial version of discovery v5 to accept both mode rather multi address and you know records but this is proved to be too difficult it's a little bit hard for me to cite the reasons but you just need to have the enr the sign dnr record of all the notes that you are talking with it you need need them in order to reply to some of the messages in the protocol yeah so it's true when you implement the protocol you need to support you know you cannot you know skip on the enr implementation

but the discussion we had is more like when you are entering a node address on the command line or something it's probably more convenient to put that as a yeah yes exactly that's what i'm talking about as well but what i need what i envision here is that perhaps it would be necessary when you connect to the bootstrap node to ask it about its own enr record which will be signed because if you don't know the signed in a record of the any note you're talking with you run into these issues so that you cannot reply properly to some other messages so what i'm saying is that if you connect with

much other or enough you should be able to ask the other note to present a valid yenna record right does this not already happen yeah i'm trying to think of the reason as well i i agree with you i i think i tried to do it as well like off the top of my head we we send like a a random packet and then responding to um i think responding to the who are you you need to know their enr at some point that's the signed version and you run into trouble well you don't need you don't really need to know theirs it's more like you need to send yours well i guess we can explore this in an issue because our

very interesting yeah if there's any problem in the spec you know basically preventing you from using the the the multi adder to for the initial connection then we should fix yep cool um we'll check that out the next day or so uh and again that multi-editor must have the pub key associated with their discover identity okay cool anything else here new design goal make sure that we can have a multi-adder on the command line to initiate these conversations on discovery avery will be very happy

okay any other networking items cool uh general spec discussion i know you all are working on v012 um please don't hesitate to reach out on issues or in direct conversation if you have any issues here um but any any other questions or comments here okay great uh general open discussion anybody have anything they want to talk about cool thank you everyone um really appreciate it excellent work

on all the test network um and talk to you all very soon bye guys see you guys thanks bye [Music] guys [Music] [Music]

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

so [Music] [Music] so [Music] [Music]

[Music] you