 All right, welcome to the, what is it? September 25th, the Non-Praise V2 working group meeting. Super excited to hear about Hyperledger Labs Agora, which is an implementation and more of an Non-Praise 2.0. So Mike's gonna present that. We are recording the call for those that are unable to make it. Looks like I'm missing a Zoom link, which I'll add in a bit. This is Linux Foundation Hyperledger meeting. So the Linux Foundation Antidress Policy is in effect and the Hyperledger Code of Conduct is in effect. Please be good to one another, but you can read the details in that link. I've got to add now to the related repositories, the Agora code base, but we'll talk about that and we'll see how best to do that as part of this. Announcements, first anyone want to introduce themselves? Whoops, that's not what I wanted to do. Uh-oh, what have I done? There we go. Anyone want to introduce themselves? I haven't been here for a while or just wants to say what they're doing in the community? Sure, I can say hello back. Hey, I'm Hakan and yeah, I work with Steven and some couple others like Enoncretz V1 specification, but then I changed my employer. Now I'm working for Accenture, but working for different working groups also in the OpenVolus Foundation and Trosova IP Foundation. I am looking forward to listening about Enoncretz 2.0 and how it is looking right now. Awesome, welcome back, good to see you again. I've seen your name a lot lately and wondered, I would hope to catch up at some point. Likewise. Steven, I'll just say that I am not actively working on Enoncretz at the moment, but I sort of want to keep in touch with what's happening. Good, good to have you back here. Thank you. Other announcements to make the Enoncretz Rust, there's been a lot of updates being made to the implementation of Enoncretz. Here is what has changed in the 020 version. We have upgraded to the CL signatures implementation replacing ERSA with the Enoncretz CL signatures implementation, so that work has done all of the updates that went into CL signatures, which were significant, are in there. And then plus a number of other cleanups and wrapper updates and so on for the JavaScript wrapper and so on. So that is available now. That was released last week and we're moving those into the various frameworks. It's lots of fun that CL signatures gets updated, then Enoncretz gets updated and then the various repositories that include Enoncretz get updated it does take a while for it all to move into the main stream but we're getting there on all fronts. With that, I will turn it over to the agenda and I will turn it over to Mike. I assume, Mike, you wanna share the screen? I can, yeah. Please. Go for it. Yeah, so Hyperledger Agora, Labs Agora is a project where I wanted a safe place to be able to put all of my cryptography code that they've written over the years. A lot of it is for Enoncretz 2 but not all of it is solely for Enoncretz 2. So there will be other cryptography code that I'm putting in there that has nothing to do with Enoncretz 2 but just in general. It probably could be used for Enoncretz like Xeronolge proofs and stuff like that but it doesn't have to be. So the two big ones I'm gonna start with is this one that it's been out for a while called unknown order. This is something that actually the Enoncretz Rust implementation could use. This is a wrapper around all big number libraries including and I'm about to publish this a constant time crypto big int implementation. But if you don't want that one, it wraps the GNU big num open SSLs and then the pure Rust one and then obviously the fourth one is the cryptography. Everything's constant time. So basically all you have to do is say which backend you want and away you go you don't even have to worry about anything else. So you can try different things out for timings and it doesn't matter what the license is because three of these are appropriate. The only one that has a pretty prohibitive license is the GNU one but most of the time people don't care about that one. Anyway, all you have to do is just say what feature you want and away you go. So like for example, the CL signatures would needs a generic big number library. So you could just stub this in and say which backend you want. So if you're like the issuer, you probably want the crypto backend that is all constant time. If you're the verifier, you actually don't care. And so you may want one of these other ones just for speed purposes. And if you're the client, it probably it doesn't matter either. So away you go because there's no secrets once you have the signature. So that's the first one that I'll be putting in there. And this one is why unknown order, please. Oh, I came up with the name unknown order because basically when you're dealing with say RSA type fields or PyEar encryption, whoops. Those require groups of unknown order where you don't know the order unless you have the secrets. So like for example, in many MPC protocols, especially the ones that do assigning, they use PyEar encryption, which relies on a group of unknown order. RSA relies on a group of unknown order. CL signatures rely on a group of unknown order. So thus I came up with the name unknown order because it deals when you have variable length numbers that are just incredibly large. Because if you're using elliptic curves, you don't have this problem. So this is purely when you're using things outside of elliptic curves. The other reason is there's this new class of cryptography called, well, I guess it's not new, but it's starting to see the light of day now, is called class groups. Class groups think of them as they're large fields, but you don't have to do any pregen of random numbers or trusted setup or anything like that, like you would for RSA or CL signatures. And so if you basically just say, I'm gonna use this class group and you're off to the races and they are considered quantum safe. So you could think of a way, if you could do CL signatures in class groups, then they are automatically quantum safe. So this library is also meant to facilitate that research. Pyre encryption, like I said, this is very commonly used in homomorphic encryption, as well as like a lot of MPC signing protocols. So like if you wanna do threshold ECDSA, most of the popular signatures rely on this, as well as some other protocols. So that's another one. The main one you'll probably most be interested is this one called Blissful, mostly because of the BLS signatures. This is a library that encapsulates everything you can think of in terms of BLS signatures, but it also supports a lot of what you can use for a non creds too, including accumulators. And some of the short group signatures can just wrap this, which I will also be putting in a GORA. But the main thing that you will probably mostly be interested in is all the cool stuff you can do with it. So it does all of the BLS stuff that you can think of. So signing, verifying, this handles threshold signing and recombining. It offers a few other features called Elgamol encryption and Elgamol proofs. This is like when you wanna prove you've encrypted a key share and without revealing what that key share is. So in many protocols, you may want to say, I wanna be able to prove I have a valid key share so I can sign, but I wanna tell you what my key share is because that key share doesn't produce a valid signature by itself. So that's where this could come in. Elgamol proofs are also used for range proofs, if you wanna do certain things with it. So that's where that's helpful. Think of verifiable encryption, that's what this is for. There's multisig, there's also a signature proof of knowledge. So a very simple example of this would be if you wanted to do the verifiable credential and you just wanted to hide the signature but nothing, but you don't wanna do selective disclosure or anything like that. That's what this could be used for. You could just hide the signature and the zero knowledge proof is incredibly small. It's only 96 bytes. So it's a very simple way to do that. Proofs of possession is just part of the BLS protocol. I've also implemented sign encryption. So sign encryption is an operation where it encrypts the data and signs it as a single operation. And then when you go to decrypt it, it verifies the signature and decrypts it as one operation. So it's a really handy feature to have. I labeled it time-crypt, but it should be more accurately labeled identity-based encryption. So that's what this is. It was first kind of proposed a simple scheme in the time lock encryption paper, but it's really just identity-based encryption. So all of that is in here. The other cool thing that is in here is this is a wrapper around the Intel's BLAST library as well as the raw Rust implementation that I've heavily optimized. So you don't have to worry about having a super fast BLS library. I also expose the raw curve implementations, but basically what you can do is, given the certain features, by default it picks the nice BLAST one, which is all assembly code. But if you can't use that one because of certain architectures you're targeting, because BLAST only allows x86 and ARM, if you're going to anything else, then you might just need the optimized Rust version. So that's what it's for. So this hides that away from you, so you don't need to worry about it. I try to just pick the best one for with the architecture that you're going for. So this is a really fast BLS 1231 library. So that is necessary for a lot of the short group signatures and the accumulators that are used in a non creds too. So you can literally just call this as a dependency and implement the other stuff which I will do and it will go really fast. And as you can see, the license is already permissive, which is really good, because this all will be going into Agora. This is already open source, but I'm donating it to Agora. So anyway, those are the three main ones to start. There's obviously going to be a lot more. This is another one I will be donating. It's called the Genaro's distributed key generator. This can do it for any elliptic curve. This is a distributed key gen. So if you wanted to set up some nodes where you distribute the keys among a bunch of different nodes and then have signing operations, then it's all built in there and it's pretty, it's robust. Hart Montgomery has reviewed this, you know, the CTO of Hyperledger. So it's received a semi-audit, not from an official third party, but a lot of cryptographers have looked at it. And the same with this one. So they've already reviewed it. The next thing that I will be donating is, let me get it here, is this one, which is it's labeled credentials exchange, but I'm going to be breaking it apart into the individual components. This has the Poncheville Sanders signatures. This has the accumulator that can be used for revocation. This has the verifiable encryption. This has range proofs. It has all of it for a non-creds too. For you to play around with and try things out and handle various things. So all of this will be in Hyperledger Agora. I'm happy if people take a look at it and offer feedback. And then we can hopefully move the spec forward. So the reason I want to break it into individual components is that way they can each be audited separately and improved individually, which helps kind of with agility in terms of like, one might be vastly improved while without affecting the others. Oliver Sanders, one of the authors of the Poncheville Sanders signature, which I think is what we should use for non-creds too, but BBS Plus can also be used. He's offered to audit this Rust implementation and also helped me write the IETF spec for it. And then after we get the elliptic curve-based one out, we will move on to the quantum secure version of his signature that he presented at crypto just a few months ago. With that, any questions or comments? First question for me. You mentioned in the CredEx there was the PS signatures in there. Is the BBS Plus signatures as well in there? Or is that to be added and there's a... That'll be added. The spec was changing a lot, so I wanted to wait till it kind of settled down before I touched it. Okay. But it will be in there. And the idea there just to be clear is you will use the implementation and implementation. You're not doing an implementation or something like that. You're going to bring in a dependency of BBS Plus and just make use of it. Is that correct? Well, hyperledger agora, I'm going to write one and put it in there. Okay. It'll be an implementation. The other goal of agora was to not be Rust specific. So if someone wants a .NET implementation, I was going to write one. In fact, I already have like three companies willing to pay me to do that for .NET as well as Golang. So there will be Rust, .NET, Golang and Java. So native versions, not like thin wrappers around Rust. So the wrappers around Rust is the easy one. Going 100% .NET is a little more difficult, but that's okay because they're paying me to do it anyway. So that's just how it's going to work. So picking a specific language, programming language, implementations shouldn't be a bottleneck anymore, which was one of the problems that we had with Ursa. Okay. Other questions from others? It's a lot. So Michael, I think last Euro Crypt, I think this BBS, there was an improved BBS Plus signature presented, which I think is going to be standardized, which only has, I think, shortens the signature. So I think it gets it off instead of three elements, it just gets it down to two elements. Are you like, are you planning to put in that one? Because it's very new. I think it's just last year. Yep. Yeah. That'll be in there. There's some improvements that Oliver Sanders has for his signature as well. So I'll be putting in there and then standardizing it with ITF. So the goal is we'll have two implementations, right? Whichever people are more comfortable with. The reason I like the punchable Sanders signatures is two reasons. One, it, the math is simpler on it. Which enables threshold signing a lot easier. Like to do BBS Plus requires some complex protocols to do threshold signing, whereas punchable Sanders does not. And two, there is going to be, well, there already is a hot swappable post quantum version. So I think it's going to be the best option for BBS Plus. No such alternative exists. They see hackens. Got his. Sorry. Thanks, Mike. So there is an implementation of BBS Plus also coming from matter, but my current knowledge or my latest, when I checked it, it wasn't able to do predicates and it wasn't able to do non-correlatable holder binding, like link secret, like binding. Is the one that you're working on for an encroach 2.0, will it tackle these issues as well? Or is there any kind of limitations here as well? No, well, predicates can't be done by the signatures anyway. So that, that's not an option. Holder binding is a separate problem. But I can make it very easy to do. Yes. Because the idea is it's going to be open source. So, you know, the BBS Plus is a popular demand. So why not add it? But as far as predicates go, the signature doesn't support that other than selective disclosure. Right. Okay. You have to group it with other stuff to do predicates. Okay. That's what the credits library does. Okay. Okay. So. BBS Plus underlying the credits library gives us predicates and the other zero knowledge proof features. You were talking about, right? Mm hmm. Okay. Everyone get that. So. The BBS Plus library. Is that what I'm understanding? Yeah. Yeah. Yeah. You have to glue them together. Exactly. And. And. PS signatures is the same, correct? Or not. Well, it gives you the, yes. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Correct. Well, it gives you the, yes, it gives the same as BBS Plus, but you don't have as many restrictions. As you do with BBS Plus. Okay. Right. The security for better for it than BBS Plus. Like right now. The, a lot of cryptographers are telling me the BBS Plus security proofs are actually broken. You know, I think it's probably not relevant to your library, but in general for an encroach 2.0. There were attempts to also consolidate or bring at encroach closer to the W3C VC data model. I think it's also still an ongoing effort, but wanted to ask like how does. It. Console. With. these claims individually, which is not really a part of the VC data model itself, per se, because it has like a container for the content itself, for the verifiable credential content, then there's like a proof that signs it all. Is there any kind of roadmap for it and how we want to tackle this? Well, to me, the VC data model is just that. It's a data model. It's just a data format. So you can encapsulate it however you want. So in my mind, there should be a simple mapping from saying in an on-creds too, this is how we sign the data. And then if you want to go to the data model as like a transport format or a presentation format, here's how. Yeah. It should play really nicely. I've freed up a lot of legacy crap that we used to deal with. So it would be more of this like an abstraction layer, VC data model, so transfer data. Okay. Oh yeah, that's how I see it. Hakan, I don't know if you've seen what has been done, we always use the term we, but I really mean the work Andrew did in mapping it, but basically it just literally moves JSON elements around. It is JSON-LD, we can, gotta stop putting my thumb up in front of my camera. It does not do the N-quads handling, it simply uses the elements of the JSON in select ways, but then puts the overall signatures into the proof section and does it in a way that you can add multiple proofs so you can have an non-creds proof and a data integrity proof with a NIST signature on the same credentials. So that's the approach there. And well, I've not seen yet the non-creds too, credential on what it looks like. The anticipation is it's exactly the same, that we simply move things around. We have a plan, right now we use, oh shoot, what's that term? I'm forgetting the term, but that allows you to just say anything that's not default to JSON-LD, so you've got a way to do it, but also to add a specific context. So if you don't have a context for the credential itself, you can use the vocab, I believe it's called, so that it picks them up as undefined in a JSON-LD friendly way, but if you have an actual context that's possible, the plan is to provide a way that a non-creds issuer can define a context for the credential itself. So I think that should be covered. Awesome, thanks. Yeah. We're planning to add implementations of the post-quantum signatures like dilithium and kyber, so that we can just have it in one place, because there's implementations all over the place, and I'd like to have it as part of the Agora project as well, so that we can do key exchanges and other things as part of the non-creds. So the idea is that Agora will be a one-stop shop for all your non-creds too needs, but I'm also working with some other cryptographers on some other protocols that are gonna be really cool. One of them is called Bingo, which was actually proposed for one of the MPC post-quantum algorithms. It is what they call an asynchronous verifiable secret sharing scheme. So once I get that in place, you won't need the Genaro crate per se anymore. It's basically a one-round DKG, which is really cool. Mike, you mentioned that didn't Genaro, but anyway, the MPC-related code. Is Allisaur part of this code base, or is it separate? Does it lay on top of this? Oh, Allisaur will be an implementation, yeah, on top of the Blissful library. Okay. Yep. Okay. And if you don't wanna deploy any of these yourself, I'm working with a company called Lit Protocol that is doing basically the MPC as a service. Right. So they will be offering the Poncheville Sander signature as a service, the Allisaur as a service, and they build in all of the authorization rules and stuff, and then all you have to do is use your standard ECDSA or 8519 signatures to talk to them. Okay. Oh. I've got another question, shoot, keep going. Anyone else with questions, comments? Oh, I know I was. Blissful contains some, reading from the Angora comments that were put in from the reviewers, the lab stewards. There's some places where you've included fixed or extended versions of existing libraries. Yes. Do you wanna mention that? Oh, sure. So the Zcash library has the pure Rust BLS1231. And so I've obviously extended that with like some of products, hash to curve stuff and some other optimizations and some formatting. So you can pick whether you want big Indian or little Indian, whereas Zcash one, you get one choice. I also have convenient hex formatting and that kind of stuff. I have already submitted that as a pull request to Zcash and then talking to them, they said it'll probably be at least a year or two before they can even merge it. So thus that's why it's out. Yeah. The other one is similar optimizations to the Filecoin library, that's the BLAST one. So same implementations, but it brings it so that both the Rust one and the BLAST one are identical and thus that's what Blissful uses. So I can go between the two without having to worry about it. And Filecoin said, well, we're not gonna merge and I have a PR to them and they said, we won't merge it until Zcash merges theirs. So I'm two years out from either of those. Thus, once Zcash merges those, then I can just archive my version but it's going to be at least a year, maybe two before that happens. So that's all it is. Okay. Hi Mike, the question for me, you mentioned the name multiple times. Maybe I missed the beginning of the meeting. You mentioned Adora project. So. Adora, yeah, like the old Greek, Agora. You know. Agora. So what it is, what it encapsulates, is it down to Hyperledger or what is Agora? Hyperledger, Agora is a new labs that I just created under Hyperledger. So the same benefits that Hyperledger already provides. So is it something like, is Agora a non-credits 2.0 or is it something? It's not just a non-credits 2.0 but it will have a bunch of primitives for, it'll have basically all the cryptography you would need for a non-credits 2.0. Okay. So I can think of it somewhat as a Ursa. Is that right? It's a better version of Ursa in my mind because Ursa was originally designed to be the cryptography library for all of Hyperledger, which at the time was a good idea, but I was the only implementer of it and kind of maintain it for a while. And so it kind of died out. I had to disappear for, you know, to go make money somewhere else. And then I've just been coding a bunch of cryptography libraries on the side over the years. And earlier this year, I had a company that tried to sue me to take some of those libraries from me. And I thought, well, you know, I mean, I was able to get it dropped, but you know, in talking with Hart Montgomery, he said, well, why don't you just create a labs project here at Hyperledger? And then you can donate all of your cryptography there. You can still be the principal maintainer of it, but then obviously the Linux Foundation owns it. And so no one, well, they'd have to sue the Linux Foundation to take it. And I was also wanting it so that if I disappear for whatever reason, other people can still be maintainers of the same code. So people can have higher confidence in the libraries that it's not just, you know, a single developer. I mean, it'll probably be me just me for a while, but I see Andrew Whitehead's on here and he's always got fun things to say about my awful code, just kidding. But that way, you know, others, it's open. They can feel like their contributions will be, you know, not just for me, but will be towards a higher purpose. So the idea of Agora, you know, was, you know, if you look in Athens, there's a bunch of those, they call open forums for people to come and contribute. So the mission is different than Ursa was. So Ursa, like, that was meant to be the cryptography library for all of Hyperledger, this isn't. This is just meant to be like an open forum of cryptography libraries. And, you know, I tend to collaborate a lot with academics on cryptography code. And so I've got two that I wanna work with and I'll put them in Agora as well. One of them is like a nice, it's called silent threshold decryption. So you'll probably see that one coming out for Q1 of next year. I see. It's a one round threshold decryption system, which is really cool and it's supposed to be post-quantum as well. So what I'd like to see, and we'll see how this goes, but my goal is to, you know, build on the credex component of that into a non-creds too. So to remind people what a non-creds too is the flexibility, the existing capabilities, the existing flow. So from a high level, you are doing more or less the same things, but getting more flexibility and more capabilities. So the big things are you're getting the underlying signatures, the PS and the BBS Plus in particular that we're interested in. Sounds like out of the gate, we would have PS. The objects are the same. There's a schema, there's a cred def, there's a credential, there's a presentation. So all of those are the same and the interactions are the same, but what the extended schema, the biggest, the most impacted object is the schema because it provides, it includes more information like for those familiar with non-creds, the schema is simply just a list of attribute names. Now it will have details of how those attributes are formulated, rules around what they can contain and because of that enable the flexibility and the signatures underneath and then as well in added zero-knowledge capabilities. So things like range proofs and so on. So the encoding is defined and allows us more capabilities. So the idea would be with this code in available, we as a community can start building on it to create a non-creds to an implementation of a first draft implementation of a non-creds too that exposes these capabilities. So that's what we're looking to do. And so what I'm hoping is we can build on this. Mike is currently in the process of transferring repositories. So that'll take a little bit, I don't know a week or two, Mike, is that accurate? I hope, I hope one of the people at hyperlensure was gone. Sean would know when he's back, but I know he was out last week. Yeah, so we'll get, Mike will get those transferred over a review and sort of will occur. And then my hope is that in around IIW time, we can start to put together a plan that says, okay, here's how to move forward in getting there and what other pieces would be around it. A big piece obviously would be to do a revocation and how that will look. So we've mentioned Alisar, Andrew's got a revocation scheme that I'm hoping Andrew can do over the next while to sort of see how it might mix with credX and an non-creds too capability. Could be able to, because my mind, a non-creds too is all about just building blocks, right? You just structure them the right way. So Alisar is just one revocation scheme. You could use the list, what is it? 2021 or whatever it is, revocation is. You could use that one. You could use his, it doesn't matter. Whatever suits your purposes. Next part of Andrew's is it enables both this 2020 and, and this would or would allow it fairly easily, I think. Okay, any other questions from anyone? Yeah, just to add on. So I take it that I guess this underlying crypto libraries, they don't assume necessarily a single revocation scheme, but that would be something that's gonna be decided on the credX library implementation, is it right? Yeah, correct. Yeah, credX, credX is basically where you pick your revocation scheme. Agora will just provide the various components. So Agora is just gonna be a suite of cryptographic libraries. And non-creds is where I see you glue those together. That way I can work with the individual cryptographers that have created these components to standardize them and they can also, and a lot of them have said they're willing to do the audits for free. So like, for example, Anna Lasinskiya, the L in the CL signature, she's already kind of auditing the credX library as I've got it right now with two PhD students. Yeah, that's part of the work we're really gonna wanna see. That would be huge. With that, I can put my thumb up and see what happens. Nothing. Only what I don't want it to, does it happen? One more thing, perhaps leaking out out of scope a little bit, but Steven, you touched on the extended schema. So I guess, how is that gonna apply with Indie Ledger? And I'm saying this is probably out of scope here, but is this gonna be, do you see the extension of the current Indie Ledger or is that we're talking about Indie 2.0 kind of thing? So the nice part of it, I think would be from a, Indie as it is today, is it has, the schema still exists, but it has different content. And so my expectation is the implementation of it would be pretty straightforward. So the schema, the credDef are definitely gonna have different content, but the same objects exist. I think Mike has an extra object still that in his credX implementation that I'm hoping we can avoid just because of all of the change that it would bring. So Mike has the idea of a, essentially a repository of attribute types. So a given name has these capabilities and then a schema is a collection of those attributes. But a schema, I believe in Mike's mechanism can be standalone, it doesn't need to, it can be fully defined on its own. And so my thought for an Indie implementation is you're basically gonna have the schema, you're gonna have the credDef, just they are different implementations and that should be a pretty easy modification on Indie just to say, oh, this is the V2 version. I believe there's versioning on both schema and credDef. So both of them would be a fairly simple step. Yeah, I designed it to be backwards and forwards compatible. So if you need to go from 2.0 back to 1.0, that's a very simple thing to do, but you will lose some of the fancy stuff. But if you're bringing from one to two, that's a very simple transition. Yeah, but it goes both ways. Took a lot of thinking to get that. I'm curious what the BBS proof issues you mentioned, if you could add in some of that. Some of that. Yeah, so DFINITY just said the security proofs of BBS are broken and need to be redone. Now, what are the implications of that? They said, well, we don't really know what that means. They just said, no one trusts the security proofs currently. Does it mean anything? They don't know. Sometimes they're just weird security proofs that like, I mean, all the security proofs do is help us give assurances of A in these specific scenarios, it's supposed to be secure. Could we add that to the BBS group, maybe? Well, the DFINITY cryptographers are hard to get a hold of, but specifically like Manu drivers and John's groth are the two that I talked to. Okay. So they're the ones that said, yeah, they're broken, but we don't know if that really means anything. So I'm just wondering if this is a good proof for the drought because working on... I don't know if they will, I asked them to, but DFINITY is super busy. But they can just throw statements like that. That's not good. That's not playing well in the community, I wouldn't think, but okay. No, it's not. I asked them if they had a paper coming and they said not unless someone pays them for it, but they won't touch it. They said the closest thing you can see is a paper that they wrote in 2020 that has John Komenich as one of the co-authors. They talk about a little bit of it in there. I'll see if I can find it. I think it's like the ePrint 2020 016, I think is what the number is. Okay. And then the, I mean, the illegal issues on his repositories, you think that's all resolved now? Is it specific repos? The only two that were under, they were trying to take from me was Blissful and the Genaro one, but all the legal issues have been dropped. Okay. Is this, are they just claiming it's worked for hire or? No, they're claiming, they were claiming that because I was doing contract work for them that, and I was, because I was working on those on the side, even before I went to do some contracts for these folks, they were claiming that because I was contracted for them that all work was theirs. Right. Okay. The lawyers were able to say, well, it wasn't even part of your core business. And he had these prior and he can prove that he worked on it on a separate computer that was completely unrelated to what he was doing for you. So ultimately that's what it came down to. Aura. So they can't claim something I already had prior to working with them, but they tried. And so to prevent that from, you know, or to hopefully prevent that from happening again, that's why Aura was created. My thinking of e-print on the PS Lattice work, post quantum work, is that a 2020 e-print? Is that the document for that? Somebody was asking you about that. Is there anything more recent? Is that what they presented at crypto and... That is what they presented at crypto. Let's see. 2022 something. Yeah, give me a second. I'll see if I can find it. Okay. For those, that's the post quantum version of the PS signatures. So what Mike described is hot swappable in the implementation he has. You could get post quantum, a post quantum signature on what we're looking to have for an on-creds V2. Yeah, the name of, let's see, it's 2022-509. Yeah, that's the one. Thanks. They have a major revision. It was part of the crypto proceedings. They just presented it. So they have a revision related to the crypto proceedings? Yeah, well, because obviously they get feedback. Yeah. But it's in the, like, if you go into the one at e-print, it even says this is the revised one, so it's fine. Oh, okay, good. Good, thank you. They updated it. Yeah, got it. So that's the one that I plan to implement after we get PS signatures standardized. Does that just make the lattice work that much easier? Because we can just say this is just the same thing. We just change the underlying math. Yeah. And hope our key sizes don't blow up the blockchain. Yeah, really? I don't know how well 9 megabyte keys sit on blockchains. 9 megabyte public keys. Well, that's what it currently is. And they think they've found a way to knock it down even more. So by standardizing PS signatures first, they can continue that research and hopefully make it even more efficient. Yeah. Now, when you say knock it down even more, 9 megabytes to 8 and 1 half? No, they're talking about like cutting it in half. OK, sounds good. Probably still being the megabytes, but we're talking like 3 or 4 megabytes versus 9 to 10. Yeah. I mean, the signature sizes aren't bad. They're just they're in the kilobyte size. Or even I think the proof size was just like 2 kilobytes. So that's so that's not bad. And the signature, I think, was 900 bytes, but the keys themselves are large. Yeah. Sorry, I think I missed a train here. What are these 8, 9, 8 megabyte keys? Where? That's the post quantum version. So what Mike has got in the credits is called PS signatures. And the developers, the creators of PS signatures have a post quantum version. And of course, what what comes about with post quantum is much slower and much larger elements, including the big one is the public keys themselves are currently 9 to 10 megabytes. Yeah, the private keys are even larger, but those aren't published anywhere. So usually not the problem. So so you you were referring to PS signatures, is it right? I'm not sure what is the leader points to Val Sanders signatures. So is there a definitive paper for the the PS signatures themselves, Mike, that we should reference? Well, the original one is 2015. But then there's been three improvements to it since. Is there is there one document that we should point people to if they're interested? Yeah, probably the main one. Let me see if I can find it. If you could find that, that would be helpful. You can send it to the after, but I'd like to put it in the notes. Yeah, I think I just wanted to ask you what about this BBS plus broken security proof? It would help if there is any draft available. I mean, I'd like to see if the assumption are the challenging the assumption or the challenging the reduction. I mean, that has to be something to. Oh, I know. Because yeah, because there was a recent to your paper on the enhancing BBS plus those. Right, very curious. I mean, what's wrong with it? Well, like I said, if you have them to publish something and they said, well, he did. And I'm like, where's the paper? And they said, oh, it was that six, the one from 2020. And I'm like, OK, well, if he's hurt and surrounded in there, I don't really find it. So that that should be a that should get the best paper at any conference if they have a decent break, right? Yeah, I'm very curious. But if yeah, we get to hand on something, maybe you can circulate it through. Well, I've asked for it. So as soon as I get it, you'll be the first to know. Yeah, I mean, I tried searching on Google. I couldn't find anything. So the little secret, I guess. Yeah. Yeah. I'm just publishing. I'm putting in chat for you all the. All the versions of the punchable Sanders signature that I've been able to use. OK, good. So that's why that's why we wanted to standardize it, right? Because if you look, I just put four in there. And he says he has another one coming. And so I'm like, OK, well, we need to standardize it because you obviously have found different ways to improve it. And then there's also the post quantum one is twenty twenty two five oh nine. Yep, exactly. OK, excellent. OK, any other questions? We're almost at time. I was a ton to go over. Thank you so much, Mike, looking forward to it. And we will. Definitely begin to formulate the plans and anyone who's interested, please, you know, let me know, let Mike know that wants to participate more in the evolution of this. Both from a spec and a implementation perspective. If you've got interest, let us know. And with that, we'll wrap up. Thanks all. Thank you very much. Thank you, Mike. Bye. Thank you. Bye.