TG ZKP Task Force Meeting - 2026/08/18

Hi, how are you? >> Hey. Hey. I'm good, thank you. On your side. >> Doing well, thank you. >> Good. Just a sec. >> Hey. >> Hi. >> How we doing? Dennis and I are well. How about you? [laughter] Oh, >> good. >> It's finally getting cooler in the UK again, which is nice. >> Uh like marginally or enough that you are >> enough that it's not like heat wave and there are some sprinkles in the air >> which is quite nice. Yeah. It felt like most people were feeling like they were in a brick oven. >> Yeah. So, are we do we waiting for somebody else today? >> I thought it was Drummond's triumphant return today. >> Got it. Got it. But maybe just a couple more minutes. >> Mhm. Uh meanwhile, I shared the link to the let's say like the P or like the the RO prototype or about the probabilistic trust which I mentioned like >> initially. Uh yeah like it's just it just like pro P at this point but it's just proof of concept. So and right now it's including actually everything. So it's including the uh circuits itself the flow like everything but yeah but it's it's just not polish version just for the proof of concept like to to to get some numbers how it's long it takes and like all the stuff. >> Awesome. Looks like Drummond is here. Yes, cool. >> Nice. >> I have join I have rejoined. Yes, I am back in Seattle after my travels uh down under. >> And uh eager to catch up. Um, this task force always was always already referenced like five times in the uh credential editor's call that just took place. We now have three straight hours of task force calls on Tuesday mornings my time. >> Wow. >> Well, they're they're all important. It's like the task forces are where all the work gets done. And uh yeah, and it was just it was it was great because the uh the editors are going, "Oh yeah, we got to bring up this with the CKP bill uh the CKP task force." So um some of them I think will, you know, will start coming to this call. Um I don't I don't know how many will today, but uh um yeah. Anyway, and I'm just going to say I was not able to pay much attention to a whole lot of things. It was all engrossing uh my time in New Zealand and Melbourne. Um so um I just am going to listen and get up to speed uh with uh where things are. I have done some reading of uh repos and messages but not not completely. >> Cool. Well, welcome back. Um, let's see. I will officially kick this off by noting the antitrust policy notice. Uh, I'm already starting taking notes in earnest. Um, and we have David Condre here who we have not seen before. So, happy to to welcome you, David. Could you introduce yourself? >> Uh, yeah, sure. Um, I'm David Hondry. Um I'm building writerslogic.com which is proof of process evidence for writers. Um I'm incorporating uh CKP into this application. Um so I'm just uh attending meetings right now trying to learn as much as I can. >> Cool. >> It's a super cool application. I'm telling you right now as a writer I plan to be using it. So >> yeah if I can ever get finished. Well, that's, you know, always a challenge, David, but, you know, I'm I'm I'm a a big supporter because, uh, >> yeah, I I'm I'm got a lot of writing ahead of me uh in my um post decentralized identity uh uh phase and and I I want to prove it's all real. >> Fair enough. >> Yeah, that's that's quite interesting. There's something I've been working on which it's kind of like an agent runtime auditing chronicle system. So that might be relevant. And I've already been folding in some of the um like CKP construction stuff into into that work. Um so everything is hashed and that sort of thing. So perhaps I can do a specific convergence with writer's logic um with you David on that. >> Okay. Sure. Sure. >> Yeah. In many ways what David's explained to me about how writers logic work it is very much like an agent you know watching and uh recording and uh attesting to what you as a human are doing. >> Yeah. It's just, you know, we can't really prove one where we can't really prove definitively, you know, whether or not a human was involved or not, but we're just ra kind of raising the cost of forgery as much as I can. Then, you know, so I'm incorporating a lot of different um like C2PA and open badge open badges and did and and um skit and like a mill a million different things trying to just increase the cost of forgery as much as possible. And then based on the hardware that your computer has, you know, there's going to be different trust tiers how that So >> fascinating. >> That makes sense. I think the one piece that I would add is you can also increase the cost of forgery by like hashing the content when the human writes it. So then if an agent then goes over it and changes it and mixes it up, the human knows that um the hash just changes the bites change. >> I I've actually got a proposed um a proposal in the proof of effort um Linux um lab as well if you want to take a look. It's a um for um proof of sequential memory execution which is just something I came up with. Uh, I don't know if it's I need I need somebody stronger in cryptography to really check take a look at it. Uh, and let me know if it's sound or not. I don't know. >> Yeah. Yeah, this rings true. I'm writing a blog post right now which is competence without history. You enter by understanding and you leave with competence, not exposure. >> All right, >> that's the that's the concept. So, um, but yeah, diverge a little bit. Back to you, Scott. >> Cool. I think uh Mitchell and David have a lot to explore. Very cool. >> Um let's see. So the recap from the last call, two big things. Uh Sankeran produced a full V0.4.0 of the requirements doc which I am happy to walk through the call outs on that today for y'all to respond to. Uh and the verification registry that Mitchell put together got a first full external run from none other than Glengore. All three test suites passed and were accepted through the discipline unchanged and that is exactly the kind of independent check that we were energizing. I guess it was two weeks ago. Um yeah and uh we also ratified the lane three ceremony gate and the entropy rule on the record. And Mitchell, it looks like you have a recap that you added as well. I think this was you. >> Yeah, if you if you wanted to I can share my screen with the HTML. You can just open it up. It's got like just a little bit of a a measure. >> I'll give it to you. I'll give it to you. >> Okay. That was that uh firstly this is the hosted page of the verification registry of the lab circuits the where we now have Glenn and Affinity that's ratified that on his Mac machine he was able to reproduce the exact same circuit and sort of the hashes of those uh gates and compression of the credentials into proofs that I did. Um, so I guess to to reiterate again what this is, it's like I tried putting the existing credential spec into a circuit, ran it on my machine. And this system here is allowing other machines to reproduce that and observe that. Not for them to like build the circuit themselves, but for them to like do my work again and ratify that my work was as it said it is. And I sort of see this as like a primitive to a trust task for the ceremony that a non-syncing uh zero knowledge proof circuit needs where you have this trusted setup. So we all kind of do the setup and then we or one person or a group does the setup and then everyone ratifies the setup with this sort of agent verification run system. Then when we get to critical mass we can do the the ceremony depending on what the purpose is. Um that then goes here and it was really neat uh the interaction Glenn and I had on this cuz it was interesting. He he ran it and then there was a piece which gets to the human in the loop which was intentional where there was like an open field where he was able to assign um a seat and that seat was something that I had to assign which is sort of this accepted run but that's kind of that sort of human in the loop assigning a seat. he was able to write his details down of the seat um and do the circuit and run it all himself. But then to be listed on this page as a verification registry that was sort of my um merge and push onto this page um once he had completed that. Uh Dennis, you've got a a question. >> Um yeah, it's it's not a question but just probably just a note something. So like it's about this mage rep like which coins the lab probably correct. Uh so I check the JS scripts which is actually about like this uh ceremony trust yes about the compilation all the stuff like for the circuit for the circum circuits like it's it's important for the just and since it's still JS infrastructure this what I want to mention that like exists z kit z kit uh and this is kind of the framework or lip like it's calling the framework but still it's kind of the lip which actually everything is already exists there. uh in terms of the it's lip um sorry circus compilation uh even the test even again there you know like some kind of case does not matter in our context but uh verification uh of such proof on the solidity like on the blockchain uh just this is what I want to mention like there is a tooling framework which is like kind of really known and many folks using that it's it's tested and like It's good enough and it's have all this. You got it. Yeah. So like it's good framework a library to use just to compilation like >> okay >> and and it's already and it's also include this uh trust ceremony uh for the development etc etc. Just a note here. [clears throat] >> What is that what is that infrastructure called? >> Yeah zit let me put it zkit. Got it. Okay, lower hand. >> That's great. >> So, yeah, these are the high level updates from the last call. We've got the one that um Scott was mentioning. uh Glenn did the circuit uh using this the the mage architecture and then there has been some mention on the um biometric specific dependency in the comments or on the uh discussions there was something I wanted to update there's a sort of a oh yeah Drummond >> yeah I was just uh Yeah, I'm again I'm I'm coming back to this back if you back up. Um I just wanted to understand that last one. Positions being filed through the position protocol. Um and this is really dumb question. What what positions we talking about and what's the position protocol? >> Yeah. So I think this is some agentic language here but the positions are the um like stances that we've taken uh within uh some of the values. So the uniqueness nullifiers the decisions we've made and the >> Okay. So we're talking about positions uh relative to issues in the task force. >> Yeah. >> Okay. And the position protocol is just so I know how the task force is handling these. >> So the I think the positions protocol is yeah I I'm genuinely unsure. Uh this is like a gentic languages. [laughter] So um I will audit that and double check what a position protocol is. But I think there it probably aligns it's probably an expression of the drafting agreements that we came to in the root registry. Um >> that's all cool too. It's I just wondered if a new protocol was emerging and I was like wait a minute I need [laughter] to know about this. >> Yeah I don't know it's um most likely >> yeah no that's questions answered. All good. So I think there's a um file here on the drafting rules. I would say it's related to the drafting rules is what the agent expressed as a protocol. >> Okay. >> Um okay. Uh >> very helpful. Thanks. So, uh, one thing that I'll just quickly throw in here before passing back to Scott is, um, just like a in the news research update, uh, Ethereum Foundation did a whole bunch of research into Poseidon as their sort of hashes and they've moved away from that and they're moving to Snarks and that was announced on August 13th, so uh, Wednesday or something last week. Um, and there's a few reasons for that that Justin gave. And I've written this as like a chronicle note in um our repo. It's just kind of like a news flash style thing. And if we want to have that interropability longterm on the Ethereum proof proving system, they'll move away from Poseidon encryption into using doing snarks. It's related to the PQC transition as well. um around yeah hashes being easier than ladder space cryptography. >> Yeah, just as note because like this all the snarks system mostly based on the elliptic curves which is not resistant for the postquantum break. Yeah, [clears throat] I put in my hand just to um it just to flag something that I'm I'm this may be obvious to you, but this task force is going to be dealing with uh more than any other task force we have dealing with um you know issues in cryptography and cryptographic engineering um that are way deeper than a lot of the other you know many of the other things credential design trust task uh flows these are things that are you know relatively easy to understand even if getting down to the details of the you know at the code level is is hard but this task force and what you're tackling is going to to many folks even on our uh on the working group going to feel like well this is the black magic task force right? You guys are, >> you know, how is anyone going to understand this? So, I'm just flagging there's no nothing to do about it right now, but it will be important when we get to, you know, sort of specifications and deliverables to to figure out how we're going to, you know, have explainers. Not that everyone has to understand all the black magic, but just how we're going to explain why there should be confidence in this work. um because we just on the editor's call we were discussing how you know for privacy of certain things that you know in these credentials we're relying on ZKP. Um, so anyway, just just pointing that out that everyone, you know, as as as you're working along, if you're thinking of there's a good analogy for explaining how this actually works to a to a muggle as uh I don't know if we have Harry Potter fans on it, but an ordinary, you know, internet user that doesn't have these superpowers, it will be important. Um, I'm constantly trying to learn about these things. Okay, enough said. Thanks. I'm probably a good canary in the coal mine like to test that too because >> good I can be buddies on that. >> I'm happy to nod along a lot but I would love to understand better. C could could I just take one minute uh just as a note like when I trying to uh explain for the engineers uh overall like how to think about the ZP uh I'm like usually comparing with the smart contracts like [laughter] but need to understand the smart contracts at least at some level yeah like the blockchains so I'm telling that like the smart contracts uh we could trust because like we could see the code and we could and like buy the system guarantees you that exactly this code will be executed and if you like understand and trust this code you could trust this smart contract kind of that one like the logic is clear and uh how to think about the ZKP circuit actually like what I'm talking like to think about also as a as a code as a program which you also could check the code itself like like comparing like similar to the smart contract yeah and if you could trust that code and you know that this This uh this proof is was related by like compiled by this circum means this program ZP program you could trust this proof but this one not required any other infrastructure as a blockchain. Yeah. It's just cryptography itself. So kind of like [clears throat] >> yes um I I I've more or less digested the ZKP idea of a circuit. Um um and and what you just explained Dennis is is exactly what I understand. Um, and I think that's a good that is a good way to to to explain it. Um, I know that ZKP um, folks understand they just the whole idea of circuits. I mean, when I talk to Hart Montgomery, for instance, it's just like every third word out of his mouth. Um, >> and I'm like, you do you every so often I want to Hart, you do understand that the ordinary, you know, muggle or human has no idea when you say circuit. They're like, "What? My light switch?" You know, what are we what are we talking about? You know, um so the the ZKP idea of a circuit is is really uh sort of this critical um you know, mental uh but I'm certain at this point Scott can explain exactly what a circuit is, right? >> Yeah. [laughter] >> The the circuit to me is a p like a deterministic path through numbers. That's that's that I like that too. Yeah, it's uh Anyway, I didn't mean to derail. I was just uh you know, being fresh back from being gone, I'm like, "Oh, this is you know." >> Yeah. And I think that's also why um part of the initiative at least um through my perspective is to try and make this as a first as possible because you do get that confidence when a model tells you that oh this is something that you may not understand but it works. And I know that that's a like a thin line to tread um in terms of trusting the model and trusting these sorts of things, but that I think is one of the advantages of using and making this AI first because it is a lot of maths and um yeah these sort of models will get good at that. >> But but as I mentioned like just for the high level understanding cir circuit means program. Yeah. just just code just program that's it like under the hood is more like like linear algebra equations but [laughter] for the engineers just programs to like to work >> that's good that's good that really helps me uh Dennis I have to say Mitch it's a little bit fascinating to say hey we're going to trust >> that AI says we can do it when you know I'm just uh near the end of the fantastic biography of uh Deis Asabis you know the founder of deep Um, and just, you know, I' I've heard it the story, I think, four different times about, you know, developing Alph Go and when it finally beat, right? >> Yeah. >> Yeah. Exactly. Um, but but the Habis and his team admitting at that point they did not understand how Alph Go actually did that, right? They were surprised themselves. And that was what 5 years ago, right? So to say that AI models that we don't understand are going to give us confidence in the ZKP that we don't understand, it's just a little [laughter] bit. >> Yeah, it's a stretch. >> Yeah, it's a I do get it and I I think you've got a good point, but I like it. De works for electricity. Yeah, >> it's crazy. That actually happened in October 2015 when it pulled out the move on the champion player that a human had never done before. >> Wait a minute. It was 2015. >> Yeah. >> Oh my god. >> I read about it. I read about it in an article of The Atlantic like that year and it became like this talking point about AI blackbox systems where you want to have like an audit trail in X. >> Yes. >> Because they were like, "What the just happened?" And they go back to their hotel room and try to figure it out and be like, "Oh, it found that during selfplay, huh? Wow. >> Yes. 2015. That means that's 11 years ago. Huh. Oh my god. No wonder where AI is where it is. All right. I'm going to stop uh stop screwing up the agenda here. >> Cool. Well, next I didn't mean cool to say you were screwing it up. Uh Cole just acknowledging we're moving on. Um the next thing was Oh Let me share. I hope these Linux Foundation transcriptions skip my swear words. Um, here we go. We are now at uh a walkthrough of the V0.4.0 requirements draft that Stalker Sean uh provided. So, he can't be here today obviously. Um, I'll walk through a high level of what he built and things for the group to react to and we'll happily feed that back to him. Um, this is a genu Oh, let me put it in the chat here too so you all have it. My god. Uh, the idea being genuine visa.4 and it answers the document relation question we opened. Um, the requirement stock is a semantic source of truth. The decision doc operationalizes it. The register records the implementation view. Uh three points to note. He answered the document relationship question. Um the requirements doc is a semantic source of truth for predicates and boundaries. The decision document operationalizes it. The predicate register records the implementation view. Uh that resolves the parallel docs problem. Uh it's thorough and honest. So a full catalog of stable requirement ids, three separate freshness clocks, a structured verification result instead of a bare true false life cycle and postquantum guardrails. Uh it keeps the assurance line sharp. Um the biometric points that I brought into it are included. So section 14 says a nullifier only gets anti- civil force from the enrollment behind it and issuers are not independent just because they are separate legal entities when they share a model vendor or data. Um the then there's a decision for the group the one thing um for us to decide or give direction on how do we want to bring this upstream. Uh we could adopt the whole thing as the official v0.4 four or we adopt the semantic core upstream and keep the deeper implementation machinery in Sankan's implementation guide structure. Uh he he flagged this himself for our guidance. So uh happy to take notes. I'm thinking about the trade-offs on that. >> Yeah, I agree with the three clocks that was proposed. Um, we were discussing that prior and it was included. So, I'm happy about that inclusion. Um, in terms of directionally, I also uh think that yeah, this should just become 0.4.0 zero. Um if possible because it has like it it ev like you can tell um it's listened to a lot of the discussions um that we've had and answered many of the questions. So yeah, it's probably not a 1.0 in terms of receiving refinements. >> Um but it is definitely a um upgrade to the draft. Cool. And Dennis, you concur with the thumbs up. >> Yeah, like just plus one. >> Cool. >> Uh, awesome. And on the construction level requirements, uh, the algorithm and nullifier detail would want to defer to Dennis, um, Nicholas if he circles back and then the Berkeley team when when and if they engage with us. >> Yeah. Yeah. >> About like let me know what was the proper time. Uh I like so I checked this uh in the Mitchell uh repo uh Z3 circuit and the nullifier it was one of them. Yeah. And like I review them like from the uh from the cryptography perspective it's quite simple. So like not like nonissue from the from the cryptography perspective there everything is clear and good. Uh but the question like but my question here is mostly you know um about the um let's say usability or real flow or something like that. So for example uh nullifier the issue with the like [clears throat] the nullifier circuit have not the issue but my questions about the about [clears throat] the secret cuz actually the secret this is the key which was like related to some person or some identity or whatever. Yeah, like which actually prove um again that that non farm circuit and the issue with that one that it's kind of uh really abstract. This is a good point that it's abstracted but from another perspective uh probably it should be as a sign in key or something else or like but my point is that just to prove that you know some secret which you could produce some nullifier it's not uh it's not tied to some identity uh there is no like strict or direct way how to link that secret to your VC for example verifiable credential issue to your idea or whatever or like to your identity like hopefully my my my point is clear. Yes. And there is a several way how to solve it. But my point is that probably we should think about this nullifier circuit or nullifier uh schema or program or whatever uh combined or together with this like how this secret or like how we will call it will be linked with your identity or with your VC or something like that cuz this is this is uh this not really could be separated uh because of some reasons cuz if you will fully separate it then we will be really limited in the solutions. This is this is my I I I'm not sure if my point is clear but hope hopefully it is. Yeah. So like uh I really like that it's really abstracted like all the complexity go away. It's really simple blah blah blah but the really key point from my side it's how to link that secret with your identity and this is and yeah and this is the change in the how that that circuit should looks like cuz like right now this is just a uh point on the field uh which could not really be the signing key or something like that because the signing key is because if that secret will be the signing key this is the most straightforward way how to link them together But this circuit for example right now it's not the case. But I'm does not saying that it should be only the sign in key. It could be another path to solve it. Okay, I'm shut down because I'm telling the same thing like one and one around and this is one point and about all like other secret for example dual dual issue yeah like when we want to Mitchell should should know I hope uh where we where we should prove the similar proof or similar uh question >> uh but for the two issues yeah like uh it's good but the problem with such circuit that is from my understanding could not exist as it is because that circuit supposed to have as input the secrets of both issues means both issues should participate in some at one place both secrets hopefully it's clear yeah so my point they could not separately you know like just calculate that proof on the device and then some and after that somehow combined this is this is a safe way yeah but that could like require just to put the both secrets on the input and this is not something which will work in real world for example. Um >> yeah that makes sense. I thought that the dual issue would be would cause some like structural problems but I wanted to attempt it first. Um and >> yeah and mostly that's it what I wanted to say about the circus like overall them good but just you know like just not not the cryptography but you know like kind of implementation of real world uh issues which need to be solved >> and I think the previous point that is the trade-off space it's like the shape of the nullifier >> I think that's almost also something that gets into the um the governance piece of who is creating the the circuit um depending on the type of trust or verifiable trust community uh if that makes sense. So like how on a ratio of how public or private they would like that um like the signing key to be >> and the last point probably which I want to mention about that one Mitchell like I saw the numbers like the constraints is like I saw the number about the circus against in your like it's posted so the constraints is clear but the timing it's um timing also is clear but it's based on the JavaScript ecosystem like which probably your agent or like whatever was measured and posted there. uh but just and I saw that like it's around like 600 milliseconds no 700 millconds for 11k constraints in the circuits u but in the real world uh on the device for example I I know cuz cuz I doing that from time to time uh on on the devices mostly does not matter is it flatter or you know like even JSON uh like react native or whatever uh or native uh builds um if you using the related um witness calculation there on the device uh in the C++ or Rust then the timing will be much better. So from my persp like from my uh knowledge around like 11 like 10k till like 12 20 like 1020 in this range constraint it will take around like 200 to 300 millisecond. So it's much faster like it's like three times faster mostly ju just to notice. Yeah that's it. >> [clears throat] >> Yeah, that makes sense. I think ideally it goes to Rust, but yeah, as you said, it was just >> just want to mention that the real numbers will be much better like [clears throat] >> Cool. Uh Mitchell, would you like to jump on the verification registry milestone in lane two? Can I quickly ask just just before we jump off of that just this really again a muggle question which is when I see dual issue um of of of secrets is can someone just explain what why are there two secrets is it is it that I just just want to understand that that one piece there >> Mhm. Yeah. So the there's a separation between the witness and the verifier and um the different roles. >> Okay. Okay. The witness and the verifier. Okay. Got it. That's it. >> Well, is that your understanding Dennis as well? Is that this like frankly saying I did not fully I mean like I got that like there is could be a number of the use cases for that one. I'm not sure if that's supposed to be the uh you know like that one of the proof type which we will put on the draft or whatever because like nullifier for sure. Yeah. But this one it's kind of uh from my understanding it's more like you know like variation of the nullifier circuit something like that it's possible not sure if that's supposed to be there or not but but again could be could be could be different use cases I believe. So that's why >> the and the purpose and the root of that logic is that if we are going to get models to do this, they will save the information in their inference. So it shouldn't be the same model that does um the secret of the witness and the verifier because then um in the future if those traces get retraced or harvest now decrypt later aspects occur. >> Um the preference would be that they're always going to be two separate information systems. So then you can't have the witness and the verify collude in the future with more um compute. >> Got it. Okay, that's very helpful. >> And and this is thank you Mitchell that remind me like one more thing which I want to say about the circuit about the nullifier one. Uh so you it's proposed that way that we um you know like that we have the miracle free of the participants already. Yeah. So like you you just you do not just like prove that you know the secret like to produce such nullifier but you also like inside the same secret you also uh prove that you you actually you nullifier or your secret there is a part of some commitment which like uh which was produced before correct so uh the logic is clear and like the use case is clear as well but you know like from another perspective it's kind of limited cuz you know like this means that I could not prove to you. So I always need to precommit to some Merkel free to be there to be after that to use that nullifier and means that Merkel free or at least root should be always stored somewhere for such domain for such domain actually domain separator and this is this is it's clear but you know like it's from my understanding it's a little bit like limit their [snorts] limitation as well. This is what I want to say. Uh >> and it it like assumes other architecture. >> Yes. >> Yeah. So, and I mean like it's fine if we agreed on this limitation like Zen Z then is cool like and blah blah blah but like like this is my question like do we okay with that or not on like we want to avoid this you know like pre-existment uh with some trust of like registry with that root of commitments and stuff like that cuz like this will require a whole separate infrastructure should be I think we should be updated the root when you know new leaves is adding and all the stuff you know like so uh cuz I believe the root solution like we could invent some solutions where it's not required like of course like always there is tradeoffs but like yeah it's just a question are we okay with that or not [clears throat] >> yeah I think um the connection it has to verifiable trust registry um work in them hosting the Merkel tree. Makes sense in in my head is that there will be like particular maintainers that have um that ability to sort of initiate the ceremony and the circuits which then can host that information in the Merkel trees. Um but yeah, I agree with you. It's something that we have to consider as a trade-off and not everyone will necessarily want to have these um it's kind of like a trust registry layer above. Yeah. like like from my head like yeah like this implementation is good but you know like from what it bother me a little bit cuz we kind of like I'm thinking from the privacy preserving internet yeah and kind of decentralized and here we need kind of centralized way for that this trust registry it's okay I know like this is [laughter] it's always a trade-off but like in many cases but yeah just want to highlight that like that it will be clear for everybody and that's >> [clears throat] >> Um I think we've we have already addressed the verification registry milestone in lane two where um Glenn ran the circuit on his MacBook and that was updated on the page. Um I can add that page to the chat again. So it's in the transcript. Yeah, this is just that hosted page of the the mage run circuit and you can see Glenn's at the bottom there. Um, and yeah, it it worked. So, that's the that's the update um in that sense. And I also worked out a way to do um synonymous seat admissions as well to this um because I kind of wanted to like have like I did it from two different instances on the machine on the same machine that I have uh to see if that would work initially and then I just wanted to record that. So I made one of them me and one of them synonymous. still open to more people doing uh that runtime and then issuing the I think it's a you follow like an issue flow to then be included in the page and yeah I'll do a overlap with Zkit um over the next week and see that convergence and whether or not the tooling is can be improved So we can sort of move in that direction instead. Cool. Uh on the next item, Berkeley Hart, etc. We've had multiple inquiries. They've confirmed they will weigh in soon. We're still waiting on that input. Uh, and that ties most into the construction level questions. Uh, and we have an item floating from the point Jeff Turk raised a couple weeks ago about credentials, spec, identity linkage and being able to talk about that cross task force whenever whenever the time is right. So, just so you know, that's um Jeff just brought up that same issue with the credentials task force. Um and we'll bring it up on the on the working group call tomorrow. Um and and it's just a matter of, you know, syncing up on the expectations from the credentials task force. Sorry, [clears throat] still getting used to the uh working off the time jet lag. Um [clears throat] and uh yeah, there's nothing nothing necessarily specifically uh to do other than to, you know, keep aligned on the expectations when we're saying, "Oh, this type of disclosure will be protected with the ZKP proof." um making [snorts] sure that those requirements that or those expectations are aligned with what this task force is covering. That's all. Scott, you're one of the fastest notetakers I've ever seen. >> Oh, if there's a contest for it, I would love to enter. [laughter] >> Be careful what you ask for. Yeah. Yeah. Yeah. Um it's also more exciting if I'm walking on my treadmill when I do this. I don't know if I've done that on this call yet. Um I don't know. Drum. Oh, sorry. >> That's skill type. >> Yeah, it's been like six years of treadmill activities and I've only I've only like truly fallen off like twice, so it's not that dangerous. Um, Drummond, I I guess I'm curious any uh any thoughts on getting getting this engagement over the line? It's it's been a while. We've had I think four people have three people, Martina in addition to Mitchell and you have reached out, but nothing's come of it yet. >> So, I have one update there, which is uh Dr. Sanengar, who heads up that team at Berkeley, did um ping me on Signal. Uh it was right when I was coming back from uh from um uh my New Zealand trip last Friday and it was basically sort of checking in going, hey, what's you know, what's happening first person project and uh uh DTG? And I was a little surprised cuz I thought, um, hasn't Hart been talking to you about, you know, and I I I quickly, you know, I think I was still in transit on the light rail or something and I just quickly answered, hey, you know, the EKP task force is up and running and they are they're dying to, you know, connect with you and your team and [laughter] hasn't Hart been talking to you about this? And his initial response was, "No, I haven't haven't heard about that." Then um I think it was a few hours later the next day he came back and said, "Oh, wait a minute. Hart was here. Hart codes over to visit with them in person every so often. Uh it's just the other site. It's, you know, Hart lives in San Francisco and they're over in Berkeley." So he said, "Oh, he was here in person." And he did explain that. He just Sanjum didn't put the names together and understand that what Hart was discussing was this group, this task force. Um, and uh, and so he acknowledged that Hart had brought it up with them, but didn't say anything further at that point. And I didn't know, I was not sure what connection had been made, so I didn't say anything further. Um what I be happy to do is pop back on that signal channel I have with Sanjim and just say hey the task force would love to I well actually you tell me what you would like me to tell him. Do you would you like him to you know invite him to one of these meetings? Uh would you like you know what is it that you would like? I think an invite to one of these meetings would be great and we can be prepared um for for that >> from my sides. Uh I could say like since we considering that document like which they posting about like the solution in yeah like which we take in an account it will be yeah it will be great is they will uh be present at least in one session where we will where we will be able to talk about the like [laughter] what I want just talk with them little bit about the document because I have like some questions like to like I believe I understood but still you know like it will be good to to have some discussion about the document. >> So fantastic. I have it it just suddenly occurred to me the thing I could do um is connect um Sanjim and Hart with uh I I would suggest Scott you and Mitchell um uh on Signal. So I could just say hey you know I can use the excuse just back from a trip just attended the the ZKP uh task force meeting uh Sanjum you'd asked you know what what there is you know how to proceed I want to connect you directly with the chairs and then that way I can get out of the uh um you know introduction and and he can you can coordinate directly with him what meeting would work is he able to make it do we need to you know create you a special call, whatever. Right. Just use that. Um so so I can take that action item. Um like uh well, I've got one more task force meeting here, but I can get that done this morning. How's that sound? >> Great. Thank you. Yeah. And I think uh taking a look at 0.4 is probably the highest value if there's a document to be shared along the way. >> Yeah. Um, once we publish that, >> by the way, I just reminded uh [clears throat] Mitch that um I I needed to send an email introduction to somebody and I didn't couldn't find the email address to use for you. So, let me know what email you want me to use for you when I need to do that. I'm going to do this other stuff on signal, but just uh >> my my sy email is good. Just make sure. >> Okay, the syllabus one. >> Solus. Yeah, that's the one attached to calendars. >> The calendar stuff. Yeah, that's when it was. Okay. Let me make sure I have the >> syllabus. Okay. Yes, I do have that. Um did we want uh Dennis did you want to share just uh noting the time of the uh probabilistic sampling? >> Uh let me yeah like I I added the link. Yes. So like everybody like would would be happy like to to to somebody like check this repository but like just to uh just as a as a high level uh think of that that like as as I mentioned for example I'm using the the kit like for the uh for this circuit compilation etc etc like the okay let me probably share could I share my screen here okay give me just a second uh Sure. Sure. Okay. Uh sorry, you know, like I do not let me let me rejoin because I do not I added the uh preferences and I need to reload the uh Zoom right now. I will rejoin in a second. Okay. Sorry folks for this delay. You know like I just do not use in the zoom usually. That's why my system was not like approved for the screen sharing here. Uh let me share my screen. I just will Hello. Okay. Sure. Um okay here this is this is what I want to share that it's about um yeah like ju just just a reference. So uh the circuit itself is here like it's in on the top level. Uh it's quite simple but but but probably not so simple but but you know like I use some solution which we kind of invent and using. So probably that's that's why not will everything will be really straightforward. But here in this circuit uh actually we solving the several issues. It's not only about like you know like some uh how to say this properly uh nullifier or something like that. This is circuit contain all the things. So it's proof that you know like that it's proof uh it's proof that you have the some connection we see with a uh you know like with the verification of the signature also it's proves that that connection we see was even was issued by the issuer which is unique by the set of the issue which we will present and it's also proves that um that issue have special another VC with some predefined list of the or some specific defined issue as a like some trust registry issue who issuing the identity credential or something like that. So actually it's solving all the problem which was in the uh one person project uh document. So like it's kind of it's it's ro but it's complain but it's contain all that you know like requirement and all the logic. So the circuit itself is here and here we have you know like just a flatter prover. This is just you know like some implementation for the which could be easily tested on the emulator like iOS emulator or whatever your device have uh or even real device just in terms of the timing. So you will have you could have some numbers like how in the real world this uh this will take you know like to prove all that stuff and um what we have more here and also we have some uh scripts which actually like explain this explain and implement that probabilistic flow step by step like generate credentials u after that you know like just binding the ids binding the ids after that verifier select that um from the whole list of the ids select some like random ones. After yeah actually this is verifier select. After that the holder generates a proof for that selected one and after that verifier like verify all that proof uh from the uh from the verify the ZP proof of that one and uh check all other stuff to make sure that all the requirement is covered and just to and just to have some notes yeah like this is what I mentioned uh when we talking about the connection amount of the credential connection credential around like like 1k or 8k around the take 10k. Uh this means that we could use uh with a confidence 95% and the bad um bad fragment like not more than 10%. with like it's these numbers could be changed but I just want to share some particular numbers uh for this for this setup uh proving hold that thing it's around the 29 selected such credential from the several thousand like which which should be enough according to the formula uh and it's taking around the six second on the real device to prove that whole thing just to just to just to have some numbers and some understanding what the things it is but it's about like to prove that kind of complex zikip circuits which actually contain all that requirements that you really have that connection VC which issues by some specific issue and that issue have another VC issued by some like identity trust registry etc. Uh so this is a number everybody who is interesting in the flow like you you could check this just step and also welcome to check the circuit itself. Uh if will be any questions I'm happy to answer and I believe we are on the time right now. [clears throat] >> Yeah I just want one quick note. So this is kind of like setting being able to set a threshold for like how much of the credentials should fit within the circuit for me to have confidence and trust. >> Yeah. Yeah. So it's it's worked a little bit another way. So like uh like we have in these steps we have a formula. So as a input you have the number of the credential we shared with you like so like for example it's 10 or 5k and you as a verifier could select this coffee scent like the uh coffee um confidence level you could select like whatever you want but like in this hardcoded 195 but you could set the 99 for example you got it here and you could also change the bet fraction right now it's 10 or 11% you could change it and and it's calculating how many Z credentials should be selected automatically. Hopefully it's clear. Yeah. [clears throat] >> Yeah. I actually think this is almost like an interesting like probabilistic folding frontier that we could set where we play around with these percentages um to work out like whether or not we get the same result with less or more um of those sampling sizes of the person's trust graph. Um, and that to me is actually kind of something exciting that people can throw a computer um, and sort of run these sort of different experiments of the edge um, >> both in efficiency but also in like size like if you want to get it all in all 10,000 um, credentials or something like that. I will probably will work on the rhythmi. I like to to have the more details and like we everything will self-explanatory. Probably right now it not not fully but yeah I will I will extend it. >> Yeah I think I cannot I can one of the things that I've been working on um independently is like a harness that tries to do frontier research where it keeps folding words actually. So you get a document with a,000 words and the harness tries to fold it down to 700 to 500 to like deterministic words. And I think that that we could use something like that for the folding of the credentials where you would have credentials that would all rhyme like they they all are issued from the same authority or something like that. So that could reduce the number because you have one from the government for example and that folds the whole um amount of credentials required. So it's probabilistic sampling with like a steer in a way is kind of what I'm thinking about. But yeah, >> we'll see. >> Cool. Well, thank you very much everyone. Uh see you next time and I'll be in touch on various channels to capture what we said. Thank you. That's all.