KZG Ceremony Breakout #1

Transcript

awesome all right so we can kick it off this is the first uh of what will probably be i think fortnightly or bi-weekly every two weeks i think is what we'll stick with as long as it's productive but this is the first call for uh coordination around the kcc ceremony so thanks everybody for coming um [Music] you guys are doing all the work i'm just just helping to coordinate so i'm very happy that we have such big brains on board here um i guess let's start with an overview of where we're at let me grab the agenda too if you haven't seen it

um jeff why don't you start with uh an overview of sort of the things you're working on and um what you're going to be working on for the next few weeks hey or actually i can start with the big thing which maybe everybody is aware of or i guess the audit chat is private so um we'll work backwards from there so we have two audits tentatively scheduled uh one in one in october with sigma prime and another in august uh with sekbid so i think they've both committed to audit

both implementations so rust and javascript um but that's sort of what we need to work backwards from and the good thing is we've already started on a lot of this and we're building off of uh existing a lot of existing work so i hope that makes our job easier um but that's sort of the context that we're working in uh jeff do you want to just give a summary of what you've been up to for others in the group maybe give an intro because maybe maybe hackspot if you don't know anybody feel free to to ask but i guess we'll just give intros just to start sorry go ahead jeff yeah okay i'm just doing a sound check because uh

i've i'm finding you trying to uh breaking up a bit and it's probably my crappy internet connection so can you hear me yeah you're coming through is my audio good for other people no issues with english okay cool so yeah jeff if you want to go ahead and give just just intro yourself and then um yeah yeah okay yeah so um

uh the things i've been working on um i put in sign in with ethereum uh switched over from uh using github uh oauth um so that is uh that's working um i um another little change to experiment with how we present witness uh or contributor witnesses in a succinct manner and that's using a blocky to um as a like a visual check

to make a quick check that one contribution change onto the next one um uh and i just use the normal blockies that you see used with ethereum accounts that's kind of a placeholder in case we get something more exciting down the track um uh at the moment i'm working on cueing just putting together some architecture there i mean the cueing can um we could run with with the cueing mechanism we we've used in the past

but uh we uh we we've got room to improve on those so um so i'm looking at that um [Music] uh just putting all right kyle didn't catch that oh sorry uh how did the queuing work previously when you say we could run with operation in the past what was that oh um so it was just one cue uh when we got if we got 500 people joining the queue the q would be 500 long and it would last for a week um and yeah um

we did that with the last big ceremony we did and we had like 3 000 contributions but if if a lot well a lot of people joined the queue and then dropped because they didn't stay on live for a week um so you know you would have got another 30 or so from that number if we had a better killing okay um and then you you're talking about auth and uh ddos stuff um what how does what does that look like on your side like how how does like what tokens are using how's that being passed around um because i'd like

to standardize this as well like you're talking about github auth versus [Music] does that get you into the queue and then you have a token or what what does that look like sorry uh you you didn't catch it is this on my side or on jeff's side i think it's that job side um maybe if you want to write it in the

chat or something okay zoom this three for some reason jeff if you see the chat he wrote it in the chat

yeah what does the auth technique look like on the q side um we're talking about uh so the authorization is done when when a participant first first signs in so they have to do that before they join the queue that's the anti-civil mechanism so if they pass the anti-symbol test the then just click a button and join the queue and we do have a token that that can be reused at any time so they can go offline and come back on with the center and and get a

token okay i'd like i'd like to turn that into a standard um if you can have like the possibility for multiple implementations then i i think we need to have this properly defined um so yeah yeah then i think we should we should sync up and see if we can add that to the to the specs which i guess we're getting to a bit later anything else jeff

um i really know cool thanks for the update um i think carl if you want to talk about the spec a bit maybe maybe so carl is going to be the general update is carl is going to be helping me uh organize the technical side of this because this is clearly out of my my uh domain my typical domain i'm not usually running technical projects like this so he's going to be helping me on that side um and the big thing he's been working on is the specs i wanted to talk about carl how generally how you see

the management of this going um what sort of goals you want to have timelines uh when you hope to have certain things completed by like your best and worst case scenarios thinking about when we have these audits coming in and um and then you can jump into the spec about that um okay cool sure um i just i think first time i started the law was the philosophy of what what i'm trying to go for with these specs um one is that um i'm trying to keep them as as simple as possible uh like the idea being that anyone can write up their own implementation and participate

so trying to use standard like restful apis and like uh json files and that kind of thing just to just to make things very easy um it's not going to be the fastest um out there but we'll prepare to make some of it well i'm i'd like to make some of those sacrifices in order to enable all of this um and uh yeah so uh the the the the the principal goal here is is is just to have this be like the the minimal set of things that need to be implemented in order for you to participate um in terms of timelines uh i think one thing i'm realizing all of a sudden on this call is that jeff and i have been working past each other a little bit um i think

jeff jeff's implementation is running quite concurrently to this um so i think i'll be able to give a better a better update on that when i uh when we think a little bit better on this [Music] the specs themselves maurice is going to write an implementation of them this weekend at least prague so i think that'll help flesh out some of the the more idiotic bugs um which which are definitely in there um and uh i i i'd appreciate people putting some eyes on it um i i don't know if you have a few free cycles kev um and uh it sounds like hobie's taking a look at it so hopefully we can we can flush out some of the more obvious things in the

next few days um maybe by the the end of next week have some idea of uh what the basics are gonna look like um [Music] then i think it'll probably take another maybe two weeks to to like harden it um the i think the big thing that the based on experience with the uh ethereum consensus specs the networking and apis take much longer than you think so i i guess again syncing with with with jeff on all of this and and trying to implement uh implement all these things is going to be important um and uh yeah then i i'm not really sure where we lie on uh

on the implementations ahead ahead of the audits but i guess that would that will tie into that next does that really touch on what you're hoping to get through the uh trend yeah no that's great yeah um yeah i think i think that's that's because the pretty much the the the updates there um the i'm one of the other things i think it's i'm trying to remove is is much of the verification okay yeah okay uh for the um i'm assuming there will be one or more reference implementations are there any plans to write a reference reference implementation that is optimized for

readability rather than performance so one that's specifically written so that it's very easy to read but it probably is dog slow um i'm not really familiar with any um but i mean that would that would be very cool um are we are you talking about in this case an implementation for a participant or for the uh the con the coordinator for a participant i think is the more important one so that way if someone wants to write their own um participant implementation which we want to encourage it's easy for them to have something to work from that doesn't have all those as soon as you start adding optimizations the code becomes very hard to follow and read very quickly

and so if you have one that's you know optimization free for the most part like just enough that it will function um i think it'll encourage more people to get involved with writing their own participant implementations okay well if if that's the goal of that particular implementation then i think the specs are actually a good place to go um it's written in like mostly their python sections which okay i explained what needs to happen in text first first of all then there's uh python like scripts that basically explain what needs to happen um and it's almost at the point where it's executable in and of itself um so i think i think that should make things very doable uh the specs are also written in like two parts one is things are explained once

uh using like cryptographic mathematical terms uh and then again in code and uh i think the the hope there being that no matter what your background is you can understand and approach this or pop a sponsor in it so hopefully that that enables that um again part of minimizing the verification that i get the that i get participants to do is to try and make it simple for participants to to be able to to participate in so uh right now you don't you don't need even need pairing checks to to be able to do this uh one of the interesting things is that uh we don't have like a standardized bls api um and by the way that's i mean the like curve for

all the functions we need so i just assume that exists and i think this is one interesting thing for various participants they need to consider is all the the components available that they need and typing into this a little bit a question for jeff on the benchmarks what proportion of time were the subgroup checks taking relative to all the pairing checks in uh in your benchmarks so um the the verification was very fast a few seconds

yeah compared to minutes for the for the actual computation interesting uh that doesn't line up with my expectations right because you should have to do one pairing per uh per group per power and it's one multiplication per power until your multiplication is much faster than um wait you don't need to do one pairing per power there's a way to batch the checks together okay yeah um you also don't need to do a subgroup check i think as well per group element you just need to check one of them and then the

um [Music] i think you call it a continuity continuity check that sort of implies that all of them are in the group if one of them is um yeah okay all right yeah i'll update to remove remove the unnecessary ones there um yeah so that basically saying back by using the the correct construction or consecutive powers there that if we know the first ones of an element of the group then all of them are uh yeah exactly um cody's said something sorry kobe said something uh about checking one ratio i'm not really sure

what uh he means there uh is this the latest message he sent uh yeah i think he said you just need to check one power i'm not really sure what that i think he said one power i'm not sure what that means actually i'm also rather unsure [Music] if it means you only need to verify like participants only need to verify the the output as opposed to the intermediate steps then sure i i guess that's what guarantees do the uh parties the prints need to ensure before they before they update the srs

is what i'm thinking like is do they just need to check that the um the srs they received all the elements are in the correct subgroup for do they need to do more than this it seems that it sort of differs by by ceremony okay um i mean the the the hmm yeah in in in in this case his his low order subgroup as uh attack would work uh with without subgroup checks so i guess we do need to do need preventive preference against that i

just opened up a branch that addresses that right yeah yeah i'm not not familiar enough with other ceremonies to comment on why or why not that these checks weren't included elsewhere uh [Music] yeah i think oh sorry i was just thinking for the check that they are all the correct powers can't

you just do a polynomial evaluation or something like that like simply use kcg to check right something like that should be possible that you can do it with like two pairings or something and a couple of multi-explanations i think that's i think that would work but the batching check i think it does it with one pairing and you just do yeah i guess the yeah maybe

because for kcg it sort of assumes that srs is correct while this if you use kzg to commit to something yeah yeah yeah so you cannot prove the reverse i mean obviously it's not directly kdcg but there's like you can prove that if you do a certain random polynomial check then the srs must be correct okay right right something i would have to figure out but i would bet that you can easily get something like that but the attack you have might already be just as efficient like just thinking out loud yeah like and that should be pretty fast like that even locally you can probably do that

[Music] i mean what are we yeah about here uh right what what's our longest 2 to the 15 right so in total 2 to the 16 yes 16 okay yeah still it's still some computation yeah yeah it's still nice to avoid it if we can [Music] um yeah i was just thinking about the eb the strongbow implementation and rust um i think yeah so the new planck implementations they basically don't have this

transcript linking feature while the schombo implementations the graph16 ones do and i believe he wrote a comment about this saying that they could avoid some checks by just making sure the transcripts linked so maybe that's why i can't remember exactly what i was reading what do you mean by trans transcript linking um so in the graph 16 ones they they need this sort of non-malleability check uh a proof of knowledge with plunk the it's quite simple you just provide the private key but with um graph 16 you sort of need to hash every previous transcript as well

the proof of knowledge is a bit more complicated and i think he said that once you sort of do this non-malleability check you don't need to do another check but i can't remember exactly what it is like that was a difference that i saw between the gross 16 ones and the plunk ones okay um when you when you find out what that is you can check in on let me know about that i'll be interested guys yeah sure and in terms of the implement the specs

is it following the graph16 version or is it following the newer plunk versions i don't know um so do we use a hash function um in the ceremony anywhere no not not just oh no yeah um [Music] so i guess the only place would be for signing over your participation okay i think that's the yeah that sounds like the plonk version

um yeah it's a lot simpler that way okay cool i'll just check over the the specs that you wrote and then if i have any questions i'll just ask great thanks so kev you're working on a modified version of this and rust how much work maybe you can give an update of where you're at on that and then like how much work do you think it would take to match carl's spec once it's done um

currently it's finished but it matches the plonk version um so if carl spec is doing the plonk version i think it might just require like a few changes here and there uh it's um i think it's mostly like some small encoding encoding things here and there uh more than anything else but uh yeah it does my specs line up fairly closely with your repo okay cool that sounds good yeah that's good to hear

um anything else you can just keep going on the the agenda i guess the circum stuff is next um one per one important person who's not on this call is jordy and i guess what we've talked about is that he will need to make some updates to circom and he's at least agreed to do this uh handshake deal kind of thing but um do we need to at what point do we actually need to get him to do that is that just before the ceremony or does it need to happen much further in advance to match the spec what do we why why socom what do we

what what's their involvement here i'm i'm okay yeah i i can't hear you jeff you're breaking up too much but i think jeff might say that their involvement is because he's using snarky js or snot js which was written by dummy [Music] okay um but it's possible to just basically have someone else rewrite the the

javascript version and following the specs instead of needing geordi explicitly yeah that might be easier okay sorry uh so to summarize we don't necessarily need jordy but there will need to be some library modification right it certainly needs to be modification to to agree to align with kyle's specs um

so uh the approach we thought because we i i don't personally know the internal the internals of snapchats um so we were hoping to work with item three to to to make a line to aspects is that to make it align the current implementation align or do you mean to add a new implementation that aligns with carl's specs [Laughter]

a variation not it's an iteration on the existing one that yeah right because i think they'll probably want to have a brand new version instead of iterating on the existing one because the existing one is for graph 16 and maybe they still want to have it there they they want to have it yeah that they could build on it and quit and make it a kcg version right i think that makes sense so they'll have two versions essentially in the repo yeah right

right well let's stay in the same repo [Music] [Music] it just seems like the easiest path to get there from where we are um but there are alternatives we could write it from scratch or start with you've what you've got give uh yeah it'd be good to know what sort of api is currently being exposed using the javascript implementation to see

how much we could sort of just change the internals without messing around with what you're doing yeah that's the issue so all those web workers and the messages they're passing the web brokers are for the multi-threading dawson yeah right but the competition is broken up you see so you have to feed each individual

section the right information i i don't know maybe if it's just the rust library i was using but the web workers were fairly straight forward i'm not sure maybe if rust has a library that just made it work good okay you should check it out yeah yeah i think it's by google chrome labs uh rust wasn't rust rayon wasn't buying gen or something just to be clear these libraries aren't

described anywhere in the spec there's nothing blocking work on that continuing no um yeah okay very good it only affects implementations well only but yeah and clarify something for me so we've been bouncing between this past implementation that i think um jeff was using as a reference and then kev has a newer modified version have we settled on whether we're going with the modified version or the previous version

where is the third is there a third version um i mean i'm not familiar enough with with the the jeff's implementation to be able to to comment on this um and also who who would like do all the the upkeep and further work on kevs on cabs one um the i i i guess there's a fairly large difference between where it stands now which is sort of implementing everything and then uh handling all the the surrounding things around cueing and auth and and all of that um and i don't know if i guess i have to keep i don't know if he's prepared to

implement one of that so it's the third it's a third version technically or there's there's three ideas for how this could look sorry go ahead kev oh i thought carlos again um yeah so i think there's currently two versions and cars one lines up with the rust one more um is what i understand at the moment um and i'll just basically modify it to match whatever carl puts in the specs i think it might yeah so with the version that jeff is using it's going to

take a bit more modification since it differs by quite a lot um in terms of doing the coordinator stuff uh i'd probably prefer not to to be honest i can definitely expose the right api for the coordinator to be implemented by someone in in javascript for example um but yeah i'd probably prefer not to mess around with the github off and stuff like this yeah that's that seems reasonable yeah i think i need to look at your

stuff kev and think more about what it would take to integrate that and it is it's more than just you know getting it up and running in a in a browser it's the whole you've got to have the have it running in the back end so that there's got to be the verification side and then we want a file that anyone can verify so um yeah so we need like to to make that public um the nice thing about doing this snark js is it's it's a commonly used uh library

anyone knows where to find it and they can just verify the files that we export yeah that's true um i think the verification code is quite like simple enough that people can sort of just re-implement it in any language yeah yeah i would fully expect we're going to see verification code implemented in all of the consensus layer clients for example yeah so i'm a little bit less worried about about that for now um i i think part of this is the slight disconnectors to the like end users or like the the people expect to be actually verifying this

um and that's that's less people implementing snarky things and more kcg like this like very specific tailored kcg use case but i mean i i guess one one alternative that satisfied both is to to as someone could could quickly write something that a a tool that transfers between the two formats but yeah yeah that's right if we got that it all sort of fits together um to jeff's point uh i think yeah we probably need to standardize the file format that's going to be um

sort of outputted at the end of the ceremony is that already in this specs carlo or was he thinking about editing it yeah so um i define a ceremony file uh which is basically because we've got four sort of sub sub srs being generated they're four sub transcripts in there uh and that's basically just a json file with all the points in there um i don't think we should bother editing it between that and the the final output um so there's a little bit of extra information that will be contained in there uh from all the participants along the way but uh i don't think i don't think it's

it's worth creating a separate version and then um kept trying to keep track of that uh also in case we ever want to uh run another round uh where we we we build on top of this positive tower in five ten years down the line right okay yeah that makes sense and you said because there's going to be multiple ceremonies does the coordinator reject a participant's contribution if he uses the same randomness in all four ceremonies yeah uh so the randomness has to be uh your yeah like pub key i've been calling it but basically your randomness uh is checked against uh all other participants in this particular ceremony

and in all other so this particular trans transcript and all other other ones right needs to be unique across all of that which i guess is quite a different check from the normal things you'll see in positive ceremonies okay right okay that makes sense so we have an extra additional check by the coordinator yeah i mean this is this is important for us to make sure that we don't have the same like we don't have the same or people who know all the like powers of tower beyond the the degree that which we we care about right right so that's right optimization yeah we i guess we could allow it and then the random beacon that's added at the end

could just be different for all uh four of them are we adding a random beacon oh no i'm not sure because the random people is public right yeah so then you can still compete with more powers using the same beacon like you need to limit it inside the ceremony yeah everyone has to use different secrets for each of them so that every single like once even one single participant doing this correctly and not computing any extra powers will limit the different ceremonies you can't do it at the end you have to do it like

yeah it's basically four different ceremonies wouldn't it be the same if every participant depart from one of them contributed different randomness so everyone did the same randomness for all four of them and then just one person said i'm gonna do the honest thing and do different randomness for each right yes but you're there yes but i mean but everyone should do different one otherwise relying on the honesty of that one particular person yeah right so you can just use a random beacon that's different for each for all four of them at the end and then you use this the setup after the random beacon

i don't the random beacon is sounding yeah you're not adding anything right still just relying on that one person whether you add the render beak or not has no effect you use this srs after the random beacon so uh it'll be different if you use different like public randomness for each one yes they will be different but that allows anyone like because the beacon is public you can compute higher powers so that's not enough to limit the powers if if you are the one participant who was like who actually had different uh secrets

then you sort of know the relation between all of these and you can take one of the the longest the longer setups uh run it through the uh beacon for the shorter setups and now you know extended sets of powers oh i see right right right yeah that makes sense yeah yeah yeah exactly yeah so this check is necessary [Music] have we covered most things at this point is there anything else something

uh something someone wanted to bring up feel free to jump in um what are we seeding [Music] uh the the ceremony with i had assumed the file coin output but i i don't know why i'm assuming that maybe danny mentioned it once yeah i i have thought about it and actually um it almost adds nothing to to do the firecoin thing because we want to like it would have the full powers so for the degree check we would still rely on our own secrets so we might as well start

from nothing it's like that's a tiny layer security yeah um a little bit one is that you could if you did the largest you sort of split up their powers and you put the the largest set up with if you line it up with the first set of powers and then you use a higher power as the starting point for the second largest setup you actually run out of powers oh oh right oh yeah that's something you could do oh that's that's an interesting suggestion okay we can use it and basically we set so i don't know let's say they have 30 powers yeah and we want 15 then instead of using tau as our first power we use tau to the 15 yeah for the seconds yeah okay okay

so yeah so we could do it yeah we could use it for all of them we just use the appropriate so for the 14 we use 16 for the 13 we use 17. okay that makes sense okay then it actually adds security this works except for the way i've currently oh but then then but then you know that works for the degree proof but now you can do fractional proline yes like that have roots in them [Laughter] yeah okay i mean it's still like me yeah i don't know i don't know basically questions does it add anything yeah should we just start from like one

yeah i guess it's more of a social security that it adds when you say we're continuing from file coin so [Music] now the malicious person needs to have um corrupted both the file coin ceremony and the new yeah but that's not necessarily true because we're relying on extra assumptions basically because like that would be true if filed coin had done this degree limiting thing and had given us exactly 12 13 14 15 powers all right basically the the assumption that either like that you have compromised all of

the ethereum and all of the file coin participants is not true it might be enough to just compromise all of the ethereum file participants and be able to do some some trick with the file coin setup to break it yeah so and in addition addition to this they all have the same uh tau across all of all of the the inputs right so that fails the check we're just talking about where there's a different tile for each of the sub-ceremonies right so because of this uh degree check that you guys want to do we can't really use anybody else's um ceremony

well we could but it doesn't it doesn't it wouldn't add much yeah um and and you've got to do a hack to get around the fact you've got you you have to mix in some public randomness to to to get around the fact that all the tiles are the same otherwise you failed the checks initially i mean basically it all comes down to the question uh failing this the degree check check like does the ceremony actually have any security at all and i the i think the answer might be no and then starting from the file coin security adds nothing yeah if there is some security properties

that are preserved even without this degree check then then it adds something but i'm not sure if that's true basically but wait so what would you start off with because if you start from scratch then you could just start with the same generator yeah start with the generator in the specs now it's just the generator or you can start power yeah step out to something some public randomness and start from there that's also possible i don't know if it matters right are there other previous ceremonies that would work if we had to for some reason we had to use

one there's no i don't think there would be any ceremony that would have done this degree limiting to the degrees that we want yeah it's very unlikely okay and public sources something like d-rand would that qualify randomness yeah it's not adding anything yeah okay so that wouldn't be useful not not really well i mean that's the way you would what you would use for a random beacon to randomize the outputs but yeah that's a given yeah there's

nothing new here okay so it sounds like we're going to start fresh yeah well i think it's sensible i think like it's just gives a full sense of security to style from firecoin in a way just pretending there's something maybe yeah i mean yeah it's not worse yeah there's no no downside yeah so so i might also be no upside but yeah very

likely yeah i'll have a look at including it with the the i'll have a look at including it as the starting point so yeah if it doesn't detract then may as well kind of thing right if it if it doesn't actually include a benefit if it's net zero then it doesn't make sense to include it just for show i guess yeah yeah well but we could include it and then just not shout about it eventually somebody will be like why

did they include this this doesn't work and then you'd be like well we just did it just because it doesn't instill confidence in our cryptographers right [Laughter] yeah um okay yeah that makes sense um i did have one more question that was on the note uh roughly it was basically i was saying that uh the attestation uh what about making it a two-step phase because uh me just saying that i have a

that i've participated uh i i could have participated and i haven't checked that it's been included for example attestation do you mean like a public tweet saying like this is my entry or is this something more technical uh yeah so it's like a public tweet but uh this doesn't mean that i've actually checked that my thing has been included inside of the final srs so um i was saying that maybe we should add a two-step phase here you attest that you've done it but then you also later on maybe a test that has been included um i mean if

if you just publicize what your what your contribution was right the blind the blinded version of your your contribution then that should be fine right when you when you initially do it then then people can can check it's been included i'm not against this proposal i just i'm uh yeah i see what you're saying yeah i think i think there's there is value in encouraging people to run the check themselves and after the whole ceremony is done and verify that the final output didn't include their stuff even though someone else could check that from their earlier commitment

i think there's value in just encouraging and you know from a social standpoint just encouraging as many people as possible to actually run the validation step at the end because i know with the aztec ceremony from correctly like i don't think anyone except for aztec actually ran the validation at the end like you know you had a bunch of people participate and then everybody walked away at that point and no one came back to check it so i think just having like you know this some meme value in saying hey i checked it and i'm posting on social media and i'm telling the world that i also verified this is valuable okay i was going to say is this something that happens after the ceremony or can it happen concurrently like can they be checking progressively

um and then doing this second tweet or it doesn't have to be after the ceremony you'd want to make sure that the final thing um did include you and it wouldn't fork some way along the way and exclude you and so i think you want to do it after the ceremony is over yeah okay that that's a good consideration and it's definitely like i guess we didn't go over like the the meta goals because i assumed everybody is um [Music] at least up to speed on things but like we want this to be the largest ceremony ever um and it has to be uh it has to be airtight basically has to be perfect because you know we don't

want to be we don't want any sort of question about something that ends up in the in protocol we don't want people to have any sort of uh shims to [Music] ask questions by so that means yeah large number of participants and the verification is also crucial i think that's i i'm not aware of other ceremonies that have emphasized this aspect as much i've only ever seen and the ones i participated in do the i just participated in x ceremony but there's never this second step after so um definitely that'd be something i'd be interested in doing like after the

ceremony's done there's a whole another social campaign about like i just verified x ceremony okay so what's the the easiest way for for us to do this well i'm assuming it doesn't it doesn't actually require anything of you right it would just be the social coordination at the end and having a mechanism for people uh yeah i guess actually i don't even know what verification actually looked like did somebody download a file and run it is it just they somebody can host a website that that that's sort of what i'm trying to get at here is like if you like tweeted about something in the past right then the information in the tweet or like how how do we get those information back into the the whatever

system is doing this checking um like if you encourage people to download a file that contains like the little proof of their their contribution then uh they people are going to lose that and like it it's not important it's all it's like the the information is all out there it's just we it's it's we some some thought needs to be put into how do we re like encode this information to to check it um information in a way that they can pull it up you know a week or a month later right yeah i mean if if if we had like a standardized tweet then we could have something with like paste your tweet in here and it will like verify that that

that works and then they tweet the output from that tweet check herself yeah okay yeah re retweet it or whatever so like you could you could do something like that um but i mean if if people are doing other things like signing with the pgp keys or whatever then it's i'm assuming we would also want um multiple people to write verifiers i think it's a little less important than multiple people writing the participation code right but it does seem like there is value in having not just a single reference implementation of the verifier just in case there's a bug in the verifier

um yeah that seems good but again the the the thus i'm fully expecting to be in every client and um i i think we have so many implementations of this it'll be ridiculous maybe not not ones with nice pipelines into twitter but uh uh things that just sort of return true right all right we've got one ish minutes left let's um talk about so specs going to be done tomorrow or today completely done

absolutely sent in the mail yeah exactly uh well i mean at least so somebody's gonna hack on it this weekend and we'll tell you if there's any issues um i'm sure they'll find some marius is working on it um what what's gonna happen over the next two weeks really quick before we meet next uh on my side well on the spec side i'm going to squash those bugs there's quite a lot of other things to to build up and explain why things are necessary uh and why they're uh sufficient for for for the safety we require

and why we have these requirements i think is also something that's rather left out so there's there's there's quite a bit of just content to put in there um then the the api it needs needs a lot of work uh as in it's non-existent right now i just assume someone will have that there so i would like to think of jeff jeff on all of that so that's that's what's gonna happen on my side from respect yeah i guess the specs are the key focus right now um and then what would follow is the implementations kev will like figure out what differences exist and then uh make modifications to match yeah i'll probably just be looking over

the specs while carl is modifying it all right jeff you want to i mean i have a pretty good idea you'll probably just keep working on this stuff but if you want to jump in feel free yeah no i'm definitely going to take a look at kev's um code and think what it would take to to integrate that uh get us a get a better idea of where we're heading with that awesome yeah and i mean kobe jumping in is is a huge uh help but is there anybody else who wants a review that i could pull in

carl i think previously someone mentioned uh mary i don't know if that's still a person we want to review the spec or uh other people i could help you forget um i mean i tried chat a bit about it on internal cryptography teams and get whoever has some free cycles so take a look if they don't mind okay that's probably the best spot yeah i'd like to clean things up a little bit more before i before i do that otherwise i'm going to get lots of you idiot yeah uh they're like one or two sections where there's a there's a header here and i have a notebook full of issues which i haven't opened as physical issues on the repo yet so um it's a little bit early for that

store all right so you're telling me i should find these people anyways just to give you a little bit of pressure exactly and pay them lots of money so awesome all right yeah we can we can wrap here thank you everybody for chatting and showing up um i didn't have like huge notes so i don't even know if that'll be useful but that the agenda has a good overview of what we went over um but yeah this recording will be available on like the uh ethereum cat harder's youtube but yeah i'll see everybody in two weeks and bring a friend next time if if you think they could be helpful to something like this yeah fantastic great

see thanks guys see everyone