KZG Ceremony Breakout #2

Transcript

all right welcome everybody to the second kcg breakout call um nothing too huge on the agenda other than just going over what we talked about last time and getting some incremental updates from people so i guess the first topic is timelines and um let's see where do we want to let's work backwards in time here um so the intent is to have this ready in advance of shanghai shanghai is the next upgrade after the merge you know let's say q2 of

2023 optimistically depending on what goes into it so i mean that's more than enough time to complete a ceremony and uh actually you know make sure that we run it well i'm sorry i'm distracted for a second there's some noise in the background um so yeah working backwards from shanghai we have more than enough time um oh right so there's audits that we have slotted in for august and october one with sigma prime sigma prime is in october around defcon and the other is in

august with sec bit and those are also obviously these are kind of key milestones that we have to hit have the spec tuned up ready to go for them to review um carl do you want to talk a little bit more about what you want to deliver together review yeah sure so um the if we assume the current hot fog schedule um then the earliest we could see this hitting hitting main net uh would be would be in march uh sort of mid-march and we would need a minimum of two weeks before then of

like just have everything finalized um so these constants can be baked into clients um which means sort of the start of march would be a good timeline or a good point to aim for um as sort of the the end of participation for that um then i think like that the idea is to have like special specialized participation as and we can do some uh fun and wacky things um and uh that that i think we should leave around a month for which takes us back to february um and if we allow three months for like

general participation um that takes us back to uh the the start of november of november so i think that would be a good timeline to sort of aim for um in terms of having a fully audited uh and robust uh set of implementations for all of this and so the ceremony going flat out um three months is i think the minimum i'd like to allow for for general participation um particularly given that some of this would be over the the end of your holiday period so i think that still gives us enough time that no one can really complain that

they weren't they weren't included um or were unable to participate um and then this this this lines up nicely with the the august audits uh which would be sort of like uh so sorry um audits and if if we we aim to have everything ready by the start of october uh then we have devcon audits in the first three weeks of october and then we use the last week to implement any changes suggested in the audits um so i think that's sort of a a good rough timeline for and that would be the sigma prime audit the what what my current thought process is here is to try have try have the two

audits target slightly different aspects of the protocol so using the the first the first orbit or audit in august um as an audit of the sort of stuff happening on the crypto side of things uh make sure that like the idea being that we have this like isolated crypto api that would be used by um the the coordinator software and the sort of default implementation of a participant and we check that like sort of sanity check that this pass does all the things in the specifications um and that uh

basically the the the crypto stuff is compliant with with with the specs i've written um and then the second order in october we use to target the the coordinator to itself and make sure that it's not doing things like censoring um and then there aren't any obvious deadlocks um and and those kinds of things and we just assumed at that point that the the crypto has been correctly audited so this is sort of my what i have roughly in my head right now for for these targets yeah that makes sense and i think probably we should just write it down somewhere um and adjust if anything does change it in that in that timeline i was gonna say when you first said you

know three months to run it my first instinct was like wow that's incredibly long for given given what i've read about and uh the projects that i've participated in three months is like an eternity it feels like um but on the other hand it um you know this is a pretty significant change um i don't think ethereum has had a trusted setup like this put into the base layer so yeah i guess we definitely do want to give enough time like you said make sure people have uh or at least the developers have um can point to this and saying look we gave a pretty significant amount of time um i think when i was doing research you know ceremonies typically ran for like

two weeks to a month um that was my general understanding from the ones that i looked into but yeah three months should be more than enough time and um and then there would be another month on top of it for these specialized ceremonies yeah so i i agree agree with all of those things um i think what's what's what's different here is i'd like for just many more participants and i like i'd like it to be such that people can forget that we're doing this and then sort of be reminded and still being able to come in later and participate i don't want it to be like oh i must i miss this this particular month or these two weeks uh i want it just to be basically on

stress for everyone uh but also gives us more time to sort of include and help sell the narrative to to more people so i think that's uh that's a better way of doing it also if our cues queues start to get long then people can come back at a later time if that works better for them so overall i i i prefer to leave it as running as long as possible uh also just to sort of minimize that from from another perspective the other thing is that uh in terms of what the clients need they like they can just import this as uh information right at the last the last minute before they before they push out a client release so [Music] the week we can really run this right up until the moment when they need that

they need this from us just like we we said ttd constants and that kind of thing so for us as long as possible is fine um and in fact i would say we should even start running it before we finish all the orders uh particularly of the sort of the the coordinator audits uh we can start running things before before that on a smaller scale not the get anyone to get involved but like a bit of stress testing it and that kind of thing internally and start getting our participation going positively a month a month before before we open it to the public yeah definitely i think that's something very suggested as well yeah does anybody else have any comments

or thoughts they wanted to add to the general timeline it's all good all right um okay so then we can just move into general updates about the rest of the things listed there i guess we can start with kev if you have any changes from two weeks ago with the the rust implementation or you're kind of sitting waiting for waiting for some other things to be concluded what what's up on your end uh yeah sure so there's no changes on the rust implementation um i've just been going over the uh hackmd with this

specs in anticipation to push some changes um i'm not sure when i'd push them to be honest what sort of changes uh are you like working with carl on this or is this something that you're looking at on your own uh yeah i was just looking at it on my own but i can contact carl uh about it uh his mercy just changes to like add um just like typos and add add more stuff to the readme this is all that document you've been maintaining right uh no it's on the specs reaper the the specs that i wrote

yeah kzg dash ceremony yes okay yeah yeah yeah cool uh yeah that'd be that'd be great um different to clean some things up um the um i guess i'm front-running the the order of the um the agenda here but uh um i'd like to include some of the like a little bit more of the rationale and explanation of like why certain decisions have been made and why we're doing things this way um as as a separate document which i think would be important to include in the specs soon um this yeah there's that they're they're design decisions which which are being made and uh

um like kev kev kev came up with some of them in the beginning and uh now i just think we need to justify them i've had some discussions with other cryptographers who um just like they had an idea of how this would go just based on what they've seen in the past and that's slightly different to what we're doing here so i think we should we should make some effort to explain that um so that should be going up soon and then the other thing is uh the checks for um a secret being common across all of the um the the sub-ceremonies uh the the the uniqueness of pub key i'm going to remove those checks so i know i

know maurice uh uh did some work on looking at at this and we had some discussion in the chats but uh that i'm gonna remove that check because i don't think it's adding anything i created a new set of test cases by hand that can pass these checks mario is the tester always come in clutch did you share that in the channel yet or is this something you're you're working on still in the repo i pushed it to our repo oh but i didn't share it um yeah but uh yeah if we don't do that

then i think the best idea would be to start with just the generators as it's right now for the yeah yeah start with generators but remove this check entirely the the check only complicates things on the coordinator side and it doesn't change our trust assumptions right it's all single honest participant so we're not adding anything and it doesn't help detect faults either because you can you can subvert this check if you are trying to be malicious marius did you want to share what you

wrote in the chat just for the recording um i just calculated that if we were to allow a new participant every 10 seconds then the transcript for one day would already be 50 gigabytes um i don't know if you guys have already thought about this oh specifically meaning like the the transcript would get pretty large over time or you're just doing math for the fun of it no no the trans no not the um like the the overall ceremonies right yeah yeah yeah

and yeah i'm i'm i don't know if this is an issue because we want people to be able to verify the ceremony at the end yes yes that their stuff is in um so i think that we can remove the intermediate powers of tao um and we just need to store sort of one srs yeah we we we shouldn't be we shouldn't be storing the intermediate powers um my specs also

don't require that so the the it should basically just be growing by one g one point and one g two point per participant wait i think which would which on your your math would be like one megabyte a day for the 8 000 participants we can squeeze in if we're doing 10 second contributions uh the transcript okay i think marius got this because in the ceremony class it shows a list of transcripts and then the transcript has a powers of tau um field yeah i don't i don't mean the transcript i mean the

overall transcripts that's really overall ceremony yeah right so all the submissions yeah we'll just collapse we'll we'll just collect them on a big server somewhere and make them public and everything but yeah just allow enough terabytes to store all that uh wait wait wait you need to start yeah uh with sort of the newer sort of um papers that have come out you don't need the older intermediate transcripts um

you sort of just need like the witness uh but carl i think uh when i look at the specs it seems that it does sort of imply that we need the old powers because it says ceremony um which is a list of transcripts and the transcripts holds like a list of g1 and g2 powers in the powers of term that that's not the transcripts that i mean um the the i i mean the overall list of uh of ceremonies i mean there should only ever be four

items in there right one for each of the the four sub yeah yeah that's something that's the like the different sub ceremonies so the sub ceremonies are called transcripts in the in the spec what i mean is the overall transcript of the whole ceremony which has a lot of this sub-ceremony sorry of these ceremonies trucks that we have and so uh that and that shouldn't be the case right well yeah but you need to for for like in this verify submission uh

function you need to do the witness con oh wait the witness continuity check that doesn't really that only verifies against the previous witnesses which are all contained within the later ceremony and we don't need to do that after the fact right if we want to verify this that the ceremony was was done correctly we we no you basically you just need the the

lists and the witness to do that verification i must clarify things on the spec then there should only ever be like four transcripts within the ceremony and each of those transcripts should only grow by one g one point and one g two point um which are both in the witness for every participant and that's it yes but the way i understood it was that you

need all the different ceremonies um to verify that everything was correct all the different ceremonies um so i think the way it's written there's one ceremony and it just has four different sr four different um transcripts yeah but you have to like if i update the ceremony then that's a different ceremony and i sent this different ceremony to the server and they store the server only stores the latest version

okay you only need the latest version to verify that everything that was correct yes that was my question yeah so we the the the checks basically work the the some checks were checked that the witnesses consistent and correct which basically means that the latest person who contributed didn't cheat and it's built on top of all the previous participants and then there's a separate set of checks which basically check that the uh the powers are actually consecutive piles of of tower and if we check both of those things then it doesn't really matter what happened in the past because the the witness checks sort of verify that although the previous participants are correct we know the structure is correct

now for that we got back from the latest participant as well so everything should should only be growing by like one point in each of the lists of the uh the witness in each of the transcripts yeah that's also what we what we saw in our implementation okay so overall the growth per participant is 576 bytes uh it was more because it's jason

yeah yeah okay plus plus plus encoding plus encoding overhead yeah 1k or something okay that's that sounds about right to me yeah one thing we'll definitely want to do is make sure that is part of the website or the interface that there's also a a clear path for people to explore verifying the transcript and maybe like a couple different levels of explanation for what it is and how

people can actually verify it themselves but we're a little early for getting into the ui stuff i guess jeff do you have any um i guess while we're on the topic do you have any uh past experience with people verifying transcripts in the ceremonies you've run or anybody else i guess yeah well we we just um collect each contribution and put it on a server and make it available that includes the witness and then so the witness can be retrieved from the

final file which has a complete history so they can see they're in there and they can see their individual contribution that's probably overkill okay so yeah we would be doing something similar then just um post it on a server would that change when the coordinator changes or would this be a persistent you know whoever's uh it could just be the same same server each time um [Music] it can be the same students got it uh carl another thing which came

to mind about the ceremony is um i think we should probably have some like you said we'll be doing testing iteratively as you know before a big public launch would be can we coordinate any of this around defcon and have maybe like some some space on the main stage to introduce the concept and i guess formally kick things off and maybe even uh one thing that would be really cool is to include some sort of uh if if not um i guess what would be really awesome is as a way to incorporate some randomness from the crowd either like a photo i i don't know if i guess the interface would have to support this i've seen some setups where

you do like mashing of a keyboard and then that gets that's your your source of randomness is there any way we could do something a little bit special where we like take a photo of the crowd and uh pull some randomness out of that or i don't know some other some other media input and if that's you know not within the realm of possibility can we do um at least some sort of contribution live just to get people aware of it yeah totally uh this is definitely a part of the plan um the getting up on stage taking photos uh or recording stuff uh exactly it's uh

it should be very much a part of a part of this um and uh just hashing a photo or something like that should should be like perfect a perfect way of doing this that's uh yeah we should expect to do that um and uh yeah could definitely drop some some some some exciting things uh i think we can have some some discussions offline to try to decide exactly how we do this to get as much like crowd involvement excitement as as possible uh but i think that'd be a good starting point uh for for all these things um at that point hopefully a few of us have participated already in the background and maybe we can collect some some people's uh participation already at devcon

um while they're there um i think that'd be yeah a good a good reference uh point for all of this and maybe maybe useful to use as like an intermediate output for testing for all the clients uh moving forward as well like we have at the end of devcon like here's our output that we're we're including for everyone to to use in testing yeah i just remembered that i mean i don't wanna we're still super early but i'm already like thinking ahead to these these exciting bits where we actually start getting contributions but i i know defcon isn't having sponsors this year and instead they're having like community project booths um and it might be really cool just to have a booth throughout the whole week where people

can come and do contributions and learn about it um but yeah i'm getting ahead of myself here but it's good to hear that we can we can do something like this a lot of fun yeah yeah and like from a technical side of the technical standpoint is is pretty easy to do so it's uh it's just more the coordination with with the dev team to do this in a fun and interesting way that i think we need to think about awesome yeah i'll um make sure to drop a line early to skyler and the team there just to be like hey we need like 15 minutes the main stage whenever there's a kickoff or closing whichever might be nice that sounds good all right uh we kind of jumped around

the agenda a little bit but we can does anybody else have any updates um have already talked i guess one thing that's sort of uh near in time would be the any any updates on the circum side of things i know i think carl you mentioned that someone had started talking to jordy and they were able to contribute to this or maybe that's kev i don't know yeah a little bit a little bit of discussion there um the that's that's mostly just needing a a crypto library for for all jeff stuff to plug into

um we had some discussions earlier about exactly what that looks like uh right now the snook js stuff is just too slow uh well i mean it's fine we can make it work but uh it's it's slow than expected as and it takes multiple minutes for just for participation um and a like decent multi-threaded wars and blob should be should be fair but quicker than that um so um we need to explore our options on on that front in terms of speeding things up uh with with harumi wasm or blast or something like that to get to get the participation numbers

down um i think jeff did you have numbers for the single threaded rust versions rush version yeah yeah so i i've booked case code and put in the wasm build code uh and got it got a building to wasm um and but only with a single threaded model haven't got multi-threaded it's compiling but it's uh it's not working in the browser um but i'm sure that can that can be got going um and even with single threaded it's

like one minute muslim uh so uh that's still faster than snuck js should get down to 10 seconds something like that which uh wasn't implementation is this that you that you think sir this is kev's uh kev's kids rush code with the artworks um okay libraries doing that yeah yeah okay thanks yeah i think we should we should

definitely do some some some benchmarking of the various libraries um what's different in comparison to most of the benchmarks that already exist uh is that most of them are favoring like how long it takes to do pairings and what we care about is like uh scalar multiplication i mean obviously there's a lot of multiplication that happens within a pairing but uh that's not quite the the direct comparison there so i think we need to do some of our own looking into to how that that works do you mean just uh benchmarking just multi-scale and multiplication scale scale and multiplication algorithms

for each library or yeah pretty much just like how long does it take to do the multiplication for your secret right okay yeah that makes sense um why not benchmark the full contribution yeah we we can do that too that's that that's also okay just also yeah that's that's fine i guess that the other thing we we care about in these these implementations is how quick they can do the uh uh the subgroup checks right and there could be large variants here based on what the implementation looks like on the background the back end whether it's the naive for more complicated ones and i don't know what what the existing libraries use

um yeah i think i did some benchmarks in the beginning so from multi-threaded it i think it was around 10 to 12 seconds um i did i didn't do a naive scalar multiplication i sort of did a bit of pre-computation um i think it was on the fly where i might have recoded this scalar i can double check but yeah doing it with like windows non-adjacent form it gave it quite a bit of a speed up um and maurice does york does your

contribution to subgroup checks yes so i just i just ran the contribution against our ceremony which is still running and this is doing the subgroup checks in [Music] sequentially and the scalar multiplication [Music] uh on all the course okay

yeah thanks right yeah so it uses windows non-adjacent form and it just does it in parallel um i think i think snarky js didn't do a subgroup check for all of the points uh last time marx jordy he said he only does it for one point maybe the first or the last do they then do pairing checks for the rest of it how do you verify the rest of the points are not part of some low order sub group right so they just they just do the

pairings check to verify that um so the powers are in consecutive order and then they yeah they sort of say that if one if one of them is inside of the group then and they're all multiplication of it yeah um okay um i mean that should i mean currently has written i'm not performing those checks and i imagine it's a little faster not to perform okay that's what i was about to ask which pairing checks uh right now our participant doesn't do any pairing checks yeah exactly oh i see yeah that's why it's four

seconds um but the pairings checks for the consecutive um sort of powers you you just need to do like a multi-scale multiplication with a random element so it's just like yeah yeah yeah well what what one pair one pairing plus one multiplication and one addition per uh per power e so two multi-scale multiscaler multiplications yeah okay yeah yeah yeah uh yeah i mean that's that that's that's also fine um i guess yeah i must look at which is which is more expensive

uh i think the multi scaler would be multiplication would be uh cheaper okay how long would it take because just doing like a bunch of pairings is gonna be a lot more expensive i think yeah no no like sure obviously that i'm saying relative to doing individual subgroup checks oh i see um yeah i think the individual subgroup checks are going to be more expensive since you multiply by the group order or the product the largest prime order yeah

okay um you may be correct on that in which case you must switch over yeah we can benchmark it as well um just so we have actual numbers to rationalize everything yeah um and i'm not familiar enough with the uh the optimized subgroup checks to to comment on what that looks like under the hood to know whether that is actually faster or not oh yeah that's a good point i forgot about um the optimizer i was thinking of doing it the naive version um yeah we should probably check if how fast the endomorph endomorphism is yeah

okay it sounds like you and i have some discussion work to do on those those fronts to check all of that out yeah sure great thanks anything else on that not from my end [Music] all right uh go ahead yeah sorry just mario saying uh that they they only check the elements on the

curve yeah that's that's not sufficient uh we do we yeah that was that was the spec i'm just saying ah and that's the mistake of my spec [Music] sounds like we're getting our first audit right now oh hell yeah um good job mario thank you do i not call the like bls.g1. is in g1 as like from my yes doesn't that only check

that it's in g1 yeah but the the the group and the curve are different things yeah oh sorry sorry i mean the subgroup in the curve no we check that it's in the so we check p dot to a fine dot ng one that's that that's that's all right then um i don't know this ng one i don't know either because the um uh

the documentation of blst is doesn't really tell us that yeah this is one of the things i sort of hand waved over in my specs where i'm like this does the subgroup check um but i'm not sure how well that maps to blst sorry kev oh i was gonna say if it's just in the group then that i don't think that might be enough because um the group doesn't need to be prime order yeah okay but i'm not sure what that function actually is doing is in g1 it might be doing the subgroup sure well you did write that it's g1 subgroup check so i think

that's my get out of jail free card there okay yeah that makes sense i'll probably look what that function does but yeah that makes sense yeah uh so i i don't think it's a bug on the spec but uh it certainly could be clearer and we should definitely check what's happening under the hood in uh blast right right all right so we'll get that fixed in the spec sounds like

um all right we i guess we're coming close to the end of the hour things we haven't touched on yet are the the non-spec stuff really so i guess the queuing identification stuff that jeff you've been working on is there any update on that end or you're i guess you also mentioned you were working on some other stuff over the past week um anything you want to update with regard to that yes yeah so queuing i think we've we've settled on a simpler queuing mechanism in talking about it with carl um yeah we we've found some simplifications it should be a very simple just just simple queue none of these time slots or

anything because we're getting because the contributions uh uh going to be pretty quick so we can it'll we can get through uh participants pretty quickly can you give me a question quick summary of like what the differences are oh so uh the document as it stands has uh time slots being allocated um and then participant would request the time slot and that that they'd come back at that time and then would in advance of it and be ready for their contribution so uh that's yeah so

i don't think we need to that complication we can just have a simple cue and the queue should clear pretty quickly because we're doing lots of contribution for our um yeah and and it's important to keep the the api as simple as possible because then it's going to be easier for implementers to um implement it correctly gotcha sorry i kind of jumped in in the middle of something you can just keep going with wherever you were i did um what else so yeah other than that i was looking at that rust

that rust thing so that's all good um [Music] as far as anti-several proposal is [Music] checking knots on mainnet um insist that the nance is scrotum-free if they have an ens name we'll use that otherwise we'll just use the raw ethereum address uh talking to carl before we talked about the idea of having and having github as a sign-in mechanism as well [Music] so if anyone has any thoughts on that we like to hear them

um it means that someone could participate with their ethereum address and then sign on with with their github and do another contributions but um and they end up doing you know a small number of contributions i don't think that's a serious um problem as in they could do two separate contributions for the same yeah oh okay yeah and we we can't tell that we can't tell it's just it's the same person but they can do that within the theory with the theory of accounts anyway right they've got more than one with with sufficient uh sufficiently high

nonsense yeah so we're not like we're not trying to have this perfect simple resistance system here it's just that we can't be dust it's the goal so if you if if like someone wants to put in the effort to figure out a way to participate five times then that's okay um as long as like not everyone does that and you can't like spin up bots to do it then that's all right um the other the other thing i think it's the reason i think it's important to do github is i'd like to be able to include community members that aren't a part of uh that they don't use ethereum right now or don't have ethereum accounts um and i think it's it's sort of easier to extend beyond like out that our direct vicinity using

github or something similar in addition to all the ethereum stuff [Music] how many if you had to guess how many people were you considering with this because it seems like it'd be pretty small the venn diagram here people that are interested in this but don't have an ethereum account or an ethereum wallet on a browser or something um that's a good point not that we shouldn't do it but i'm just yeah like the if it ends up you know so we had to choose if i had to choose i would always use the github one i'm just not comfortable signing

anything with my key that i use in mainnet so you and i think i mean it could be it doesn't have other people are in a similar vicinity it's just like i don't know i'm not going to to take out my my uh cold wallet from storage and you don't you don't have like a hot wallet that you just use for i have one but i want to participate multiple times in the ceremony okay well then you can just spin up a random address in metamask and have nothing of okay i guess you'd have to send a few transactions ahead of this yes um yeah i i think it's it's very important for us to also have like

a way a non-ethereum native way to contribute it's also very important to have an ethereum native way to contribute but i think we should also have and we can i don't know this this sign in with ethereum it already uses oauth right and so we could use this oauth with yeah that's that's how it's being implemented i mean joe can speak more to it but basically once you signed in it's verified that you have enos sufficient loans do you have anything to add there jeff

or are we good no yeah that's all good okay and then i guess my only other question is it it could be either or you're not required to do github and sign in it could be one or the other okay either one yeah got it uh just quick question to marius uh why did you want to contribute more than once um just if like somehow my uh contribution gets revealed on some on one device i want to be able to also contribute from another device so that i'm i'm sure that my contribution

is not being revealed right and i think like we should design it in a way that we can contribute as many basically as many times as we want to yeah i think right yeah i mean assuming that we're not running into bottlenecks with like length of cues and participation time then absolutely um i mean hopefully your one contribution is sufficient you shouldn't need to contribute more than one times but if you have any reason to doubt the security of your setup then i'd welcome a second participle like a second entry from someone and if we like if we take this 10 second

slot time for contributions for the three months we have seven hundred seven seven hundred seventy seven thousand six hundred slots um so like yes a quarter of a million slots this is one of the things i'm really excited about and that's that we like this might be one of the ceremonies where we have more participants than we have uh powers which is truly ridiculous that'd be pretty incredible mario what was that number again [Music] seven seven nice

wow yeah so i think marshall's saying roughly 700k i mean i'm not expecting to get that many um but if we like i'd definitely like to achieve the smallest a smaller set of powers is 4096 i certainly like to achieve more than 4096 participants that's a good goal aim for like i would i would i would love to write a bot that would take up all the remaining so if some like if someone did not contribute then i want to contribute with my bot okay my goal is not to block mario's bot [Music] adversarial bot games

cool yeah that'll be pretty pretty incredible um all right minutes left any final i guess we should just go over what people are going to be working on over the next week uh i'm going to talk to skyler i mean again this is like we're early we're very early on this but i'll make sure that they're they reserve us a slot at the beginning of defcon and start to talk about um having a booth where we can explain what this thing is over the course of devcon and uh maybe get some contributions from people um

that'll be something that i make sure to do over the next week or i guess it'll be two weeks let's call us every two weeks carl what are you gonna be up to uh i'd like to if we can start to put the the spec out there a little bit more um if you don't think we're ready that's fine but um i think we should start moving towards that of like publicizing it and sending it to some of the other teams that have done trusted setups to get start to get their eyes on it unless you've already done this uh yeah sure so um i might start on a publish like timelines so that everyone's on the same page on what's been done when the stuff i was discussing at the beginning on the spec side the one or two little

cleanups i want to do uh let's say today tomorrow and over the weekend so on monday we can start publicizing things that's that sounds good to me um i want to write some of the clarifying documentation i was talking about so that when people approach this they can understand where our desire is coming from and what the different decisions we've made are um and then some discussion with with kev on first bls implementations and where we're going from there awesome and this um all this stuff is is that going to live in your kcg specs repo or somewhere else uh so the stuff i've discussed now will be in the the kdg specs repo i'm starting to think that if we have

like it depends on how complicated the the api is but i'm starting to think the api might be worth having in a separate specs repo uh jeff and i were having some discussions uh earlier today on exactly what like what that looks like and and how we achieved that uh i was really pushing for the most simplified possible api but uh if if we end up with long queues that might might not be uh so so friendly um and it might make it worse like having to i was trying to get entirely a restful api but that might make things worse so jeff jeff once was proposing to go with uh amqp uh which i'm not familiar enough with the comments but that's one of the things i'll look into uh over the next few days

awesome so we had a well we have a pretty clean uh rest api for for our ceremony so so i don't know like that that that works and is what i'm pushing for but uh the concern jeff was raising with me and i think it's valid is what happens when someone shouts loudly on twitter about all of this and then you have like suddenly a few hundred people jumping in the queue then how do you how do you handle that nicely uh when the queue starts extending beyond uh a short enough time and my initial proposals just to kick people if the queue gets longer than say three minutes but maybe that's not not the right way of doing this particularly we have hundreds of people all of a sudden

well yeah i'm not i'm not keen on booting people out i'd rather just put them in a long queue and if it's an hour i think it'll only be an hour or two the queue anyway and they can they're happy to stay online for that length of time and that that is possible with with our rest api right okay i must try to pull apart your api but then because i'm definitely like keen on keeping it very simple and basic rest would be great yeah let's check that out so um i would like to create some more test cases just for

the crypto side of things um cool thing about about go is you can you have like this code coverage built into the test cases so we can easily figure out which which code is tested and which code is not tested at least in our code not in the libraries um but um yeah so we can create some test cases where like i don't know the subgroup check checks fail or um i don't know something with with this happening and i would like to create some of those

uh for the that'd be cool and i'd like to then like murder like any cool test cases you come up with i'd like to have in a fold on on our repo um unfortunately we don't like for the the subgroup check in particular i don't think we we know any uh low order or non-prime group elements to to fail that check but uh [Music] jeff um what are you going to be up to over the next week uh or two i was i was going to start writing writing down an api spec

and play a bit more with that rust implementation see if i can get multi-threading to work about it great um kev if you have anything you can jump in yeah i was just basically gonna look over to specs um [Music] uh yeah i don't know if there's it's probably better to sort of fix up the specs first and then uh modify the code after and just yeah to speak with carl if there's anything we can discuss moving forward right

okay great uh one thing which just came to mind is at what point jeff did you typically start looking at the uh interface the website should i start reaching out to i know the the ethereum.org team has done some stuff for like they've spun up some websites for other like affiliated teams should we reach out to them and sort of uh get a slot in their in their workflow for setting up a site for us or what what's your experience there oh um uh yeah yeah i'm happy i mean we've we've just done really crappy simple websites before so having a nice one would be

great um yeah if you guys uh if your guys have access to infrastructure and everything um that would work well otherwise i i'd have access to our pse infrastructure guys okay yeah i think this is definitely something where we'd be able to ask for you know a couple people to work on this and help us create a nice looking site yeah like get a designer involved here yeah definitely yeah okay um

happy for you to go ahead with that if you want for sure yeah i can do that just wanted to make sure that um you weren't already talking to people and uh that was the direction we wanted to go seems good i've worked a lot with them on the launch pad side of things so i'm also like happy to to reach out with you awesome the fog team yeah great i think that's it um thank you everybody for keeping working on this quietly while it's still quiet eventually it'll be uh pretty big and we'll look back fondly on

these small calls with five people but uh yeah thanks for the work everybody's done and um i guess we'll talk in the chat and then in two weeks for the next update thank you see ya all right see ya bye it's all