WEBVTT 00:00.000 --> 00:11.380 Okay, hello everyone and welcome to the Monaro Research Lab office hour with me, your host Justin, and the person you actually want to see, Dr. 00:11.380 --> 00:12.320 Strang-Noether. 00:12.480 --> 00:14.640 So to start, I would like to have Dr. 00:14.640 --> 00:16.280 Strang-Noether introduce himself. 00:16.280 --> 00:21.400 Before we get started, I think it would be useful to set expectations for what this session is. 00:21.580 --> 00:23.760 It's very casual on purpose. 00:24.040 --> 00:28.120 We are here such that we can answer your questions, mostly it'd be Mr. 00:28.120 --> 00:39.880 Strang-Noether answering your questions, and yeah, so I will be paying attention to YouTube, I'll be paying attention to Discord just to relay questions over, but otherwise this is really your time to make of it what you would like. 00:39.880 --> 00:42.500 So yeah, we're here to answer anything you have. 00:42.500 --> 00:45.760 So how about, Strang, can you introduce yourself please? 00:45.800 --> 00:47.600 Sure, so I am Dr. 00:47.600 --> 00:48.380 Strang-Noether. 00:48.380 --> 00:55.060 I'm a cryptographer and mathematician who is a research contributor to the Monaro Research Lab. 00:55.120 --> 01:06.220 The Monaro Research Lab is a research and development work group, it's not the only one, but it's a research and development work group that conducts, you know, research and development for the Monaro project. 01:06.220 --> 01:21.020 So that ends up being stuff involving protocol research, some of the math, prototyping, coding, all sorts of things, to kind of push the Monaro protocol and privacy preserving digital assets forward in general from a technical perspective. 01:21.460 --> 01:34.800 And like Justin said, the purpose of this office hour is to give an opportunity to just kind of very informally give a video forum, in this case, in order to, you know, answer any questions that come up, topics that people want to know more about. 01:34.800 --> 01:49.400 So this could be Justin and I sitting here in the quiet for an hour, like often happens in kind of standard university in-person office hours, you know, or it can be, you know, really whatever sort of technical aspects that folks want to talk about. 01:49.560 --> 01:54.600 So I guess I'm using whatever, you know, media you, I guess, have access to. 01:54.600 --> 01:57.420 Justin, you said you're watching the Discord on YouTube, is that right? 01:57.680 --> 02:02.720 Well, yeah, so for any questions that people have, you know, go ahead and shoot them off to us there. 02:02.720 --> 02:04.120 We can talk about them. 02:04.420 --> 02:05.720 Otherwise, I'll sit here. 02:06.680 --> 02:07.260 Perfect. 02:07.260 --> 02:08.360 I brought my coffee. 02:08.360 --> 02:15.920 You know, I haven't had a lot of coffee with my actual coffee chats recently, but I feel like I've doubled down on the coffee the last few days. 02:16.000 --> 02:27.100 Were you the type of person in high school, well, maybe high school depending, but in college that went to office hours, were you the type of person that would usually go or is this something you did not go to that often? 02:27.380 --> 02:34.620 I had to go to office hours, you know, when I had questions and later as a TA and even later as an instructor. 02:35.620 --> 02:36.300 I don't know. 02:36.300 --> 02:41.640 And then I had a new appreciation for the nature of office hours when I was the one, you know, running the office hours. 02:41.880 --> 02:51.260 But I did discover that oftentimes it was like this really cool combination of, you know, folks who came because they really wanted to understand something that they didn't, you know, prior to that. 02:51.260 --> 03:00.700 But there were also a lot of students who really did know what they were doing and they were just really interested in making sure that they, you know, kind of had as much face-to-face time to kind of go over new problems as they could. 03:00.960 --> 03:06.340 So one thing I like is it was like, oh, this is not some kind of sign of weakness to go to office hours. 03:06.440 --> 03:11.540 You know, it's like a sign of, I guess, being motivated and dedicated to what you're learning. 03:12.600 --> 03:19.840 But there were still many times when I had no one show up to office hours and then it was just reading books for an hour. 03:21.600 --> 03:22.780 What are you going to do? 03:23.840 --> 03:24.820 Yeah, I guess. 03:25.280 --> 03:28.300 Any questions or any topics of any kind? 03:28.380 --> 03:33.180 At the moment, there are no questions and no topics of any kind, but of course it's open. 03:33.180 --> 03:35.480 I mean, we can also talk a little bit about those, I guess. 03:35.740 --> 03:39.320 Yeah, I was thinking one way we could do is sort of troll the answers out of people. 03:39.320 --> 03:43.000 We can just start saying like, well, what do you think about this obnoxious thing? 03:43.000 --> 03:44.980 Just to get people all riled up about it. 03:45.100 --> 03:50.800 But before we do that, how about you tell us, talk about what you've been doing with the Minerva Research Lab the last month or so. 03:50.880 --> 04:13.480 So I would say probably like the most interesting thing that people might care about, or hopefully at least they'll care about the effects of it, is going to be CLSAG, which is a linkable ring signature construction that was intended to be a drop-in replacement to the linkable ring construction that the Minerva protocol used to use. 04:13.480 --> 04:14.980 It's called MLSAG. 04:15.200 --> 04:19.680 I will say that in hindsight, I really regret us not giving it a cooler name. 04:20.760 --> 04:22.860 What would have been a cooler name for that? 04:22.860 --> 04:23.780 I have no idea. 04:23.780 --> 04:26.060 If anyone has any ideas, you should tell us. 04:26.060 --> 04:28.760 I mean, we ended up getting a pretty cool CLSAG logo. 04:28.960 --> 04:37.260 Basically, the community came together and we had a few ideas that were pitched, one of which we ultimately went with in the blog post, and they're credited at the bottom. 04:37.320 --> 04:49.900 But it's not quite as easy to market as something like Halo or Arcturus. 04:50.260 --> 05:01.100 So prior to the confidential transaction model, the linkable ring signature scheme was won by some other authors. 05:01.100 --> 05:05.140 It was called LSAG, Linkable Spontaneous Anonymous Group Signatures. 05:05.380 --> 05:20.120 From that point on, moving into the confidential transaction model, where we replaced unclear amounts, commitments to amounts, and then we moved to one that was developed by Shen Norther and others, more of an in-house kind of thing. 05:20.120 --> 05:21.640 That was called MLSAG. 05:21.640 --> 05:25.980 It was a multi-layered, linkable, spontaneous anonymous group signatures. 05:25.980 --> 05:33.340 The idea there is that you had both information in the signature that dealt with both signing keys, but also certain commitment keys. 05:33.680 --> 05:51.460 And by kind of cleverly setting up and arranging how you do that signature, you could both show this kind of signer-ambiguous signature model you're looking for, but also throw in a proof of balance, which is very important, but also completely in a signer-ambiguous way. 05:51.720 --> 05:58.140 The downside to the MLSAG signatures, of course, is you basically kind of have two sets of data floating around in the signature itself. 05:58.140 --> 06:05.880 You have some sets of data that deals with the signing keys, and a kind of a separate set of parallel data that deals with the commitment keys. 06:06.100 --> 06:08.360 So the scaling on that, you know, is not very good. 06:08.360 --> 06:11.760 It scales as, you know, the anonymity set per transaction goes up. 06:11.760 --> 06:12.720 It scales that way. 06:12.880 --> 06:19.040 But at the same time, every time you're adding on, you know, new ring members, you're actually adding on two pieces of data, effectively. 06:19.060 --> 06:21.380 One for signing keys and one for commitment keys. 06:21.580 --> 06:29.620 And so the kind of new hotness now is CLSAG, which is concise, linkable, spontaneous, anonymous group signatures. 06:30.060 --> 06:32.900 So it is what it is. 06:32.900 --> 06:39.220 There was a name that was chosen and thought about changing it, but then we're like, ah, you know, we've already named it. 06:39.220 --> 06:40.620 Can't really rename it. 06:40.640 --> 06:42.320 So people already knew about that. 06:42.320 --> 06:44.340 We didn't want to make everything more confusing. 06:44.340 --> 06:59.320 But the idea there is to kind of take this information involving this data for signing keys and this data for commitment keys, and it turns out you can combine them together in this weighted fashion that, you know, hash functions to ensure that, you know, 06:59.320 --> 07:03.260 someone can't kind of maliciously go through and run a forgery on the signature. 07:03.600 --> 07:08.600 And basically do the same thing that MLSAG signatures do. 07:08.600 --> 07:13.680 Both show in a signer -ambiguous way that you're signing a message on behalf of one of the unknown keys. 07:13.680 --> 07:16.660 I guess one of the set keys, but you don't know which one it is. 07:16.660 --> 07:20.680 But also basically signing with this other commitment key that you need to prove balance. 07:20.680 --> 07:27.440 So it's more or less a drop-in replacement, but now effectively you only have to have one set of data involved. 07:27.440 --> 07:34.020 So one piece of information per ring member and then some additional auxiliary information that's used just to make the algebra work. 07:34.080 --> 07:38.440 So the benefits to this are that it's basically a drop-in replacement, so that's great. 07:38.860 --> 07:41.240 You know, everything involving key images sticks around. 07:41.240 --> 07:44.760 Everything involving the way that these keys are structured gets to stick around. 07:45.260 --> 07:50.000 But the benefits, this benefits that you get for it, are that first the signatures are much smaller. 07:50.000 --> 07:57.500 So effectively the signatures you get for CLSAG are about half the size as for MLSAG. 07:57.500 --> 07:58.740 That's just a signature alone. 07:58.740 --> 08:01.760 Transactions include more than just a signature. 08:01.980 --> 08:09.980 So they're smaller in that sense, but they're also faster to verify, because it turns out you can do some optimization with the way that these operations take place. 08:09.980 --> 08:16.880 Because before you had to do some cryptographic operations on like the linkable side of the data and on the commitment side of the data. 08:16.880 --> 08:21.340 And now you can effectively do them at the same time and you can optimize that away a little bit. 08:21.340 --> 08:25.820 So the benefits there are that you end up with about 20% faster signature verification. 08:26.380 --> 08:37.780 So transactions that spend multiple inputs, which most transactions spend between one and two inputs and generate some other outputs, but for every one of those spent inputs you need a separate signature. 08:37.780 --> 08:54.940 And so it turns out that for the most common forms of transactions, like a two input two output transaction for example, you end up seeing overall about a 25% decrease in the transaction size and overall probably about a 10% speed up in the overall transaction verification. 08:55.160 --> 08:56.340 So that's pretty good. 08:56.340 --> 08:58.400 There's really no downsides to this. 08:58.600 --> 09:02.000 Of course we want to make sure that the security model for this is very strong. 09:02.200 --> 09:08.860 So the security model basically just says what properties do we want this construction to have? 09:09.100 --> 09:17.140 And for our particular purposes, we want there to be these properties involving forgeability and non-slanderability and linkability. 09:17.140 --> 09:22.020 And there's kind of this list of them that you want this linkable ring signature construction to have. 09:22.020 --> 09:26.660 So what you do is you basically build this kind of hypothetical model of an imaginary attacker. 09:26.840 --> 09:30.300 And you kind of give this attacker different powers to do things. 09:30.300 --> 09:37.140 So you might give this imaginary attacker like the power to convince honest users to hand over their private keys. 09:37.140 --> 09:45.360 Or you might give this imaginary attacker the power to persuade honest users to build arbitrary transactions on the attacker's behalf. 09:45.360 --> 10:00.580 And then you show that even if the attacker had these powers, it still can't go and like generally break these properties that we wanted to have without also breaking some computational problem like the discrete logarithm problem that we assume is computationally feasible to do. 10:00.640 --> 10:05.260 So you basically say, aha, this hypothetical attacker can't exist, and therefore we're okay. 10:05.680 --> 10:12.420 And so we decided to kind of beef up the security model that was used for CLSAG compared to like LSAG and MLSAG. 10:12.580 --> 10:17.600 And in doing so, ended up with, I would say, like a pretty good model for how we want it to work. 10:17.740 --> 10:18.760 So that's pretty good. 10:18.760 --> 10:25.500 We're pretty sure that the same security model would equally apply to MLSAG, but you know, we didn't go back and kind of retroactively do that. 10:25.640 --> 10:27.280 It was considered to be pretty straightforward. 10:27.860 --> 10:32.700 Do you know of anyone else that is actually using MLSAG in a sort of production like Monero is? 10:33.300 --> 10:36.220 Like, is there any other application that's widely used for this? 10:36.780 --> 10:51.780 Oh, I mean, besides like projects that, you know, use it for the same purpose, you know, like CodeWorks or, you know, you know, different digital assets that have at least like the same or a similar protocol, presumably use it. 10:51.780 --> 10:55.300 But I'm not aware of any other direct applications. 10:55.760 --> 11:11.440 So originally LSAG, one of the, in the original paper that originally introduced LSAG, you know, one option that was listed was like voting schemes, for example, you know, where you want to be able to ensure that someone can't vote twice for a particular issue, 11:11.440 --> 11:14.520 but also some ambiguity among the set of possible voters. 11:14.600 --> 11:16.520 I don't think that that's actually been implemented yet. 11:16.520 --> 11:23.040 I mean, secure voting is really hard for a lot of reasons, but it happens to be really good for the purposes that we use it for. 11:23.040 --> 11:26.940 And so I just got to finish up too. 11:27.220 --> 11:34.400 The Monero community commissioned an external audit of both the paper, but should be very careful to say pre-print. 11:34.400 --> 11:37.280 This pre-print is still technically a pre-print. 11:37.280 --> 11:41.500 So that means it hasn't undergone any other peer review aside from what I'm going to talk about. 11:41.500 --> 11:51.660 But we decided to have the pre-print externally audited, as well as the implementation for the upcoming October network upgrade audited. 11:51.720 --> 11:52.900 So that was done. 11:52.900 --> 12:06.000 There were two auditors who were commissioned to do that, and that was in kind of in consultation with the Open Source Technology Improvement Fund, which is a non-profit that does support for these kind of things and supported by Monero community donations. 12:06.180 --> 12:13.460 And the auditors had a lot of really good suggestions for how to improve the overall CLSAG security model and pre-print. 12:13.520 --> 12:21.340 So ended up changing a few of the proofs around and generally just improving how the security model and proofs were structured and run. 12:21.540 --> 12:25.300 And those didn't actually require any other changes to the scheme itself. 12:25.300 --> 12:29.020 So the construction itself, and therefore the code, didn't change as a result of that. 12:29.020 --> 12:32.820 But we're now much more confident in the way that the security model was arranged. 12:32.820 --> 12:36.960 Some of the definitions, the cryptographic hardness assumptions, and things like that. 12:37.000 --> 12:37.740 So that's great. 12:37.740 --> 12:41.980 Those changes have been made and that's now up on the IACR ePrint archive. 12:42.320 --> 12:49.940 And then the implementation surprisingly didn't require any real changes for security, which I feel like usually you get some in there. 12:50.100 --> 12:59.600 There were a few kind of informational ideas for how to simplify the code, but we considered that changing those, they would have been fairly extensive in how we handle certain key structures and such. 12:59.600 --> 13:08.260 And it was thought that it was probably more likely to introduce risk if we made kind of these big sweeping, more informational changes than if we were to just leave it. 13:08.260 --> 13:11.160 So yeah, so the report's available. 13:11.160 --> 13:13.820 There's a blog post up on getmonero.org about it. 13:13.820 --> 13:17.940 You can read the full report, take a look at the pre-print, look at the code if that's your thing. 13:19.800 --> 13:20.600 Awesome. 13:20.700 --> 13:24.480 Yeah, so that's scheduled to be deployed in the October network upgrade. 13:24.500 --> 13:27.940 So all you need to do is just keep your software updated. 13:27.940 --> 13:40.020 If you use a hardware wallet like a Trezor or Ledger, that's in process as well, getting their firmware and apps updated as well to make sure that that's good to go kind of day-in-day-out when we're ready to go to it. 13:40.060 --> 13:44.380 So if you use those, make sure you keep your firmware updated as well and you'll be good to go. 13:44.380 --> 13:45.720 Very cool. 13:45.720 --> 13:47.920 We had a question come in from Andres. 13:48.000 --> 14:00.900 He asked if there's any plans to, in the future, move past ring signatures to something that is not just hidden between other decoys, but has additional protections beyond just a decoy level protection. 14:00.900 --> 14:05.540 So I guess there's quite a few things that I know are involved in this question. 14:05.540 --> 14:22.300 One is we have the current decoy selection, which per transaction has a relatively small number of decoys per selection, which provides reasonable mass surveillance protection, but less so good targeted surveillance if someone knows information about particular transactions. 14:22.300 --> 14:29.020 So I guess given the current situation, what is the approximate timeline forward? 14:29.020 --> 14:50.900 Not necessarily the timeline, but the set of potential improvements forward for whether or not ring signatures are sort of the right approach for the future, and how you've approached dealing with the core problem of the relatively small per transaction decoy levels. 14:50.900 --> 14:56.460 Yeah, so really the question seems to be kind of about per transaction anonymity sets. 14:56.880 --> 15:14.840 I increasingly dislike the idea of using the term ring signature to purely mean a limited anonymity set, just because while it has been the case so far that our ring signature construction does have a limited anonymity set, I don't think it's necessarily the correct term to use. 15:14.840 --> 15:23.160 So it's possible to build transaction protocols with limited anonymity sets or full anonymity sets, and you could probably do all sorts of other things. 15:23.420 --> 15:30.480 I mean, we know that there's transaction protocols that have no anonymity sets, but those are typically not the ones we're interested in. 15:30.820 --> 15:39.660 So what we do right now is we do in fact use a linkable ring signature as kind of a building block in a limited anonymity set transaction protocol for the Monero protocol. 15:39.900 --> 15:42.000 That's not the only way to do it though. 15:42.100 --> 15:48.920 So it is possible to build limited anonymity set transaction protocols that use, for example, specialized zero-knowledge proving systems. 15:49.000 --> 15:59.760 So I really don't like the whole idea of zero-knowledge meaning full anonymity and ring signature meaning not, because that tends to be certain implementations now, but it is not generally true. 15:59.920 --> 16:08.520 I mean, those things have much more technical meanings involving proof and signature constructions, but using them the way that we do today. 16:08.520 --> 16:28.060 So it's possible to kind of migrate over to a still limited anonymity set construction, but one that permits much larger anonymity sets for reasonable transaction sizes and times, but in a way that ideally would help against certain other forms of analysis or attack. 16:28.280 --> 16:36.320 Because again, right now, the way that the transaction protocol signatures scale is that they scale linearly with the size of the anonymity set. 16:36.320 --> 16:38.720 So you're really kind of stuck there. 16:38.740 --> 16:45.280 And there's been some proposals for ways to use different kinds of specialized zero-knowledge proving systems. 16:45.440 --> 16:52.440 Some examples of that are OmniRing is one of them, Atlantis is another one, RingCT3, Tryptic, Torus. 16:52.620 --> 16:55.260 There's probably other ones that I'm just not thinking of right now. 16:55.260 --> 17:09.240 But all of these essentially allow a transaction proof along with possibly some other auxiliary proofs that scales much better in terms of size and scales a little bit better in terms of time. 17:09.980 --> 17:13.760 So verification time is unfortunately kind of the sticking point for this. 17:13.760 --> 17:23.060 So if you want a trust-free, like a non-centralized, you know, trusted setup style proving system and transaction protocol, you can make those proofs very small. 17:23.480 --> 17:25.380 Like we know how to do that already. 17:25.540 --> 17:34.920 They're not as small, for example, as like the proofs, not the transactions, the proofs in say Zcash, but they're still quite small for the size of the limited anonymity set you can get. 17:35.040 --> 17:36.920 But verification time is always a sticking point. 17:36.920 --> 17:44.620 So with those particular kinds of protocols and proofs, you do need still like a almost linear verification time. 17:44.700 --> 17:46.200 That'd be the sticking point. 17:46.280 --> 17:50.080 So that's kind of the limitation that exists. 17:50.080 --> 17:51.460 There are options. 17:51.460 --> 17:58.500 They've all got some trade-offs in terms of, you know, what you can do with things like tracing and how the construction works. 17:58.500 --> 18:03.020 Some of them involve changes to multi-signature operations. 18:03.480 --> 18:09.980 There's changes to the way that linking tags work, which is kind of require almost sort of like a pool migration that can still be done safely. 18:10.580 --> 18:14.880 And so which one of these, if any, should be the one going forward is kind of up in the air right now. 18:14.880 --> 18:23.840 A lot of it depends on what trade-offs people are willing to accept and also what trade-offs people are willing to accept in terms of mainly like transaction verification times. 18:24.020 --> 18:29.260 Obviously, we'd like verification to be as low as possible because that means faster operations. 18:29.580 --> 18:34.060 But that has to be balanced against what kinds of analysis and attacks you want to be able to protect against. 18:34.380 --> 18:39.200 So ideally, what we'd love to do is move to something that isn't that full anonymity set. 18:39.300 --> 18:51.380 Kind of the classic example of that right now is something like the Zcash protocols, where different anonymity sets that are involved there are basically enforced using proofs that do things involving Merkle tree proofs. 18:51.380 --> 18:57.340 And what that effectively does is effectively gives you a full anonymity set within that pool, absent external information. 18:57.660 --> 18:58.720 That would be ideal. 18:58.720 --> 19:08.960 But right now, all the proposals that are kind of on the table for doing that suffer a lot in terms of either centralized trust or in terms of, say, proof size or time. 19:09.140 --> 19:13.200 Right now, you can't really have everything if you don't want to have centralized trust. 19:13.200 --> 19:16.740 And of course, you know, there's also other issues with that. 19:16.880 --> 19:26.240 You know, for example, in many of the protocols, in many of the pro... hang on here, there's someone else drawing the room here. 19:26.600 --> 19:29.680 Yeah, I think it's probably one of the next speakers, I assume. 19:30.440 --> 19:33.740 But um, yeah, anyway, right now, like, that's kind of the limitation. 19:34.000 --> 19:44.280 So under the assumption that, you know, the project and its community are unlikely to move to something that would require centralized trust, you know, right now, there has to be a limitation of limited sets. 19:44.280 --> 19:48.600 And so there's still questions about, you know, how do you end up choosing those anonymity sets? 19:48.640 --> 19:52.920 There are definitely ways you can do it that I think provide improvements over the way we do it now. 19:52.920 --> 20:01.680 As you get bigger anonymity sets, you can do kind of, you can do certain kinds of binning with the outputs in those anonymity sets. 20:01.680 --> 20:05.800 And that can mitigate certain kinds of heuristics involving common ownership. 20:05.820 --> 20:13.880 And, you know, the source of where those outputs came in terms of transactions earlier on the chain, as well as timing analysis. 20:13.880 --> 20:15.800 So there's a lot of interesting stuff you can play with. 20:15.800 --> 20:22.160 But I don't think there's a really good understanding right now of what exactly those precise trade-offs people are willing to make are. 20:22.700 --> 20:28.060 Yeah, in my experience, you know, we have, we have code that can do this now. 20:28.240 --> 20:35.500 But I think it's a matter of kind of the community and researchers and developers kind of getting into agreement on what those trade-offs should be. 20:36.460 --> 20:43.740 So, and again, hopefully, you know, eventually we get to something that is efficient and trust-free, which would kind of check all the boxes for everyone. 20:43.740 --> 20:52.480 And from there, you could, you know, very likely build a protocol that uses such a system and does, in fact, give you effectively, you know, full anonymity, which presumably would be enforced. 20:54.340 --> 21:02.860 In my experience, when people talk about full anonymity or limited anonymity, it's, it's sort of in an academic only way. 21:02.860 --> 21:09.100 And then it's applied to like, you know, it's typically the way things are currently, right? 21:09.100 --> 21:13.700 So limited anonymity looks like a Monero's case, right? 21:13.760 --> 21:18.240 And that, in many cases, people think that that just can't even really change. 21:18.240 --> 21:24.220 They don't really think about these limited is just, you know, anything less than the full pool. 21:24.220 --> 21:30.120 And that could be a, you know, a larger number than the entire size of the pool of enough different network, theoretically. 21:30.120 --> 21:36.780 And then people are like, yeah, it also depends on what exactly your threat model is, right? 21:36.780 --> 21:49.340 You know, are you concerned about knowing various after, you know, making a bunch of controlled purchases, and then examining the possible transaction tree between you and like, you know, I don't know, an exchange with whom this person or entity is colluding. 21:49.700 --> 21:57.880 So, you know, given that, you know, that it's very difficult to get, I would say, practical anonymity, you know, in that particular circumstance. 21:58.200 --> 22:05.540 And there's plenty of other circumstances that you can dream up, where under certain threat models, limited anonymity just, you know, won't work for you. 22:05.980 --> 22:13.960 So it's one of those, like, it's one of those infuriating, it depends kind of ends, where, you know, it's like limited anonymity right now is a trade-off. 22:13.960 --> 22:15.880 It is like an absolute trade-off. 22:16.040 --> 22:21.740 And we all look forward to the day when we can do something that's trust-free. 22:21.740 --> 22:35.280 And, you know, frankly, like if your particular threat model is going to require, you know, a more full anonymity scenario, you know, then, you know, you might have to consider whether or not going to like a trusted setup sort of scenario is something that you need to do. 22:36.800 --> 22:44.900 That may come with its other trade-offs, you know, based on things like ecosystem availability, and, you know, a host of other questions. 22:44.960 --> 22:55.860 But it's absolutely a trade-off, you know, and I think it's important to acknowledge that, you know, we have things like the Breaking Monero Series where, you know, we kind of try to tease out some of the particular scenarios under which limited anonymity can be a problem, 22:55.860 --> 22:58.280 and those for which it might not be as much of a problem . 22:58.940 --> 23:08.840 But it's, I feel like, no, it's not fun to like sit down and try to enumerate and think about the specifics of a risk model, but, you know, it's something that unfortunately right now we kind of have to do. 23:10.500 --> 23:21.260 We haven't had a Breaking Monero Series in a while, so I guess, given that we haven't, what episode ideas would you like to see there be episodes for? 23:21.920 --> 23:31.480 Oh man, I think it'd be interesting to do one that talks about, I guess, some more specifics on things like churn and self-send operations. 23:32.340 --> 23:43.060 So I would say things like that, something involving things like output merging would be very, very interesting, you know, where outputs from different transactions end up being pulled into different anonymity sets into the same later transaction. 23:43.280 --> 23:49.020 I'm looking at ways to possibly mitigate that, you know, larger anonymity sets with good output selection can mitigate that example. 23:49.180 --> 23:59.000 The churn example is a bit tougher because you could look at things like, you know, possible chain history sizes and distributions and look at, you know, what happens with that. 23:59.400 --> 24:10.780 I think it's, yeah, there's a lot of interesting things to talk about, but I think it's important to do them in a way that doesn't end up kind of just rapidly devolving into, you know, confusing graphs and, you know, irritating math. 24:18.000 --> 24:23.300 But at the very least, I think I'm really happy at least to see that there's a lot of interesting research into this area. 24:23.660 --> 24:29.140 You know, a lot of folks want general zero-knowledge proving systems that are trust-free and efficient. 24:29.860 --> 24:33.760 And, you know, that would, I think, be like the ideal, you know, checking of all the boxes. 24:34.420 --> 24:36.720 And it's interesting to see what different projects do, right? 24:36.720 --> 24:49.860 You know, I mean, things like Zcash and related projects get, you know, efficient proofs that are very fast to verify, and you can do things like effective with full anonymity set transaction protocols, in theory, ideally. 24:49.860 --> 24:59.320 Zcash kind of has their whole optionality part to it, but are willing to sacrifice trust to a degree to like multi-party computation, you know. 24:59.320 --> 25:11.280 And there's always kind of the question of, like, for your personal use case and how you tend to view multi-party computation, you know, do you think that a multi-party computation setup kind of diffuses the trust out enough to where you're okay with that, 25:11.280 --> 25:13.000 or are you not okay with that? 25:13.060 --> 25:24.700 You know, because in the theory that does provide like a guaranteed, you know, this is how the soundness of this operation could fail scenario, if that multi-party computation were, you know, misused, for example. 25:25.100 --> 25:31.000 So, so many questions in this space, and so many trade-offs. 25:31.960 --> 25:37.940 I feel like a lot of cryptography is basically just like the precise study of mathematical trade-offs. 25:39.160 --> 25:46.780 But, you know, no, I don't really have a good timeline for when, you know, we might be able to move to something that is, you know, what you consider full anonymity. 25:46.920 --> 25:53.720 But there are options for increasing the anonymity set, which lets you do a lot of other cool things, hopefully mitigate some analytical heuristics. 25:54.960 --> 25:57.380 Wouldn't solve everything, but I think you'd get improvement. 25:58.600 --> 26:00.800 So that's on the tip for October, right? 26:01.040 --> 26:01.800 Kidding. 26:01.820 --> 26:03.200 Not for October. 26:03.880 --> 26:06.820 So, I mean, there's other interesting things, you know, on the horizon too. 26:06.820 --> 26:10.080 Ideas for making range proofs a little bit more efficient have come up. 26:10.080 --> 26:14.380 There was a preprint that came out on improvement to bullet proofs called Bullet Proofs Plus. 26:15.840 --> 26:22.200 The plus actually means taking away a few proof elements, but Bullet Proofs Minus doesn't sound as good. 26:22.660 --> 26:24.140 So, I don't know. 26:24.480 --> 26:26.920 There was a proposal to do an implementation of that. 26:26.920 --> 26:27.840 It's really new. 26:28.280 --> 26:37.400 It's kind of a, it's an extension of the way that the Bullet Proofs inner product protocol works in this cool, does this cool weighting operation with it. 26:37.420 --> 26:41.200 And it would let us, you know, take a few dozen bytes off of transactions. 26:41.560 --> 26:50.240 In theory, they'd be like very, very marginally faster to verify, but, you know, in practice, it would pretty much be a wash, I think, in the grand scheme of things. 26:50.740 --> 26:56.400 So really, the question about whether or not it is worth moving to that is worth the effort. 26:56.420 --> 27:00.400 And the possible risk of something that's a bit newer has yet to be determined entirely. 27:03.220 --> 27:09.960 Were there any other questions that came up besides the one that got us into a very long discussion about protocols? 27:10.160 --> 27:11.760 Yeah, there's one. 27:11.980 --> 27:15.540 It's still a protocol-related question, so it is going to be a follow-up, though. 27:15.540 --> 27:23.080 It says, so the ideal solution for Monero would be zk-SNARKs-like thing that doesn't require a trusted setup? 27:23.400 --> 27:27.100 And I believe you basically said yes, but also needs to be efficient. 27:28.180 --> 27:28.940 Yeah, yeah, yeah. 27:28.940 --> 27:41.080 And, you know, and specifically saying, like, zk-SNARKs specifically, you know, it's... there are different ways to... there are different building blocks you can use to construct protocols, and I think it's important to consider it at a protocol level. 27:41.360 --> 27:52.500 So, for example, like, you could basically build something akin to, you know, like the zcache sapling protocol, for example, but without using zk-SNARK construction. 27:52.500 --> 27:54.780 You could do that with bulletproofs, for example. 27:55.220 --> 28:02.360 I don't think it's actually been done, but I know that there were some estimates made to say, okay, you know, bulletproofs is a zero-knowledge prudent system. 28:02.440 --> 28:06.340 The scaling is, you know, in terms of verification, is not as good. 28:06.340 --> 28:07.520 Just absolutely not. 28:07.840 --> 28:13.900 But what it lets you do is it lets you prove things about circuits in a trust-free way. 28:14.000 --> 28:15.800 So that is trust-free. 28:16.420 --> 28:23.400 And so, in theory, you could take, you know, the circuit that's using zcache sapling and some of the other constructions, and you could build that in bulletproofs. 28:23.440 --> 28:24.800 And you get rid of trust. 28:25.020 --> 28:26.340 And the size would still be pretty good. 28:26.340 --> 28:28.880 The estimates and the size, like, it'd be competitive. 28:29.500 --> 28:31.820 Not quite as good, but still pretty competitive. 28:32.000 --> 28:35.320 But the verification would be, no, it wouldn't work. 28:35.920 --> 28:39.660 Estimates I saw are, like, still on the order of a second, which you're like, well, a second, that's pretty fast. 28:39.660 --> 28:42.260 It's like, yeah, but then you got to do that, like, a million times. 28:42.660 --> 28:50.580 So you can, like, amortize that down with batching and stuff, but, you know, it seemed like it was not quite doable at this point. 28:51.000 --> 29:09.000 So I would say something that would let you do, like, the whole Merkle proof kind of thing that, you know, effectively lets you do a full anonymity set-based protocol would be ideal if, you know, we could make it mandatory, which other projects have shown you can do that to ensure optimal privacy. 29:09.080 --> 29:17.180 But also, I think, ideally is making it trust-free or, you know, at least infusing the trust and the soundness out to the point where everyone is satisfied with it. 29:17.180 --> 29:25.220 And I think it's the general view of, you know, a lot of folks who support the idea of Monero to just reduce that trust down to nothing. 29:27.520 --> 29:41.140 You know, whereas for other projects, they've decided that they're okay with, you know, kind of delegating that soundness risk off to a large enough, you know, set of participants in a multi-party computation that they are safe, you know, secure enough that they are, 29:41.140 --> 29:42.580 I guess, okay with the security of. 29:42.580 --> 29:44.220 I don't really know a great way to say that. 29:44.480 --> 29:45.560 But that is risky. 29:45.560 --> 29:51.760 You know, I mean, like the Sprout multi-party computation that started Zcash, for example, did have a soundness problem. 29:51.860 --> 29:58.180 And there was a kind of a whole deal where they had to end up taking down the proof transcripts and hoping that no one was able to figure out and abuse that. 29:58.180 --> 30:04.840 So like there's a real non-trivial risk involved, even to something like such a multi-party computation. 30:04.860 --> 30:06.420 So that's not without risk either. 30:06.740 --> 30:11.640 And it makes the trust situation a little bit more tricky. 30:13.540 --> 30:20.720 So I guess I am personally of the opinion that, you know, I like the idea of, I guess, kind of minimizing the possible soundness problems. 30:21.680 --> 30:28.020 You know, a soundness problem for something that involves like a trusted setup is the trusted setup and a multi -party computation. 30:28.320 --> 30:36.820 You know, for something that, for anything that uses, for example, Peterson commitments, which Monero does, other projects do too, Zcash does, you know, minimal level-based assets do. 30:36.840 --> 30:42.080 You know, in theory, if you could break Peterson commitments, that's a problem with, you know, something akin to soundness as well. 30:42.680 --> 30:48.080 So it's definitely kind of like this different like threat profile and ideally we want to minimize that. 30:50.610 --> 30:51.570 Got it. 30:53.370 --> 31:01.390 Something that was discussed quite a few years ago, but I don't think has really come up super recently is the idea of second layer networks on Monero. 31:01.390 --> 31:03.330 Like, what if you wanted to put the Lightning network on Monero? 31:03.330 --> 31:05.570 What if you wanted to put this, that, or the other on Monero? 31:05.570 --> 31:12.870 What if you wanted to put a, you know, a like zk-snark-mixer on Monero, like as an optional thing? 31:12.870 --> 31:22.550 Like, so I guess what sort of building blocks need to happen to allow greater compatibility, knowing that right after this we also have a talk about atomic swaps for Monero too? 31:22.550 --> 31:27.270 Yeah, yeah, which is a really cool new thing that's still in progress. 31:27.270 --> 31:45.810 But yeah, so there's some other researchers who were looking at the possibility what would it take to do, say, you know, atomic swaps between something like Monero and, you know, something like Bitcoin, for example, where in Bitcoin there's a lot of stuff you can do because Bitcoin has both scripting capability, 31:45.810 --> 31:58.170 but also, you know, some different kind of setups in how its protocol works and in how it runs things like signatures and the like. 31:58.820 --> 32:04.240 And that gets really tricky because Monero does not have inherent scripting capability. 32:05.110 --> 32:13.830 Adding inherent scripting capability would be pretty awful for fungibility, so I tend to view that as probably a non-starter on the Monero side. 32:13.950 --> 32:19.650 So given that, the question is, well, okay, so what could you do for something like atomic swaps? 32:19.750 --> 32:31.630 And one idea that maybe talked about in the next talk, so I won't try to give too much away, involved a particular zero-knowledge proof that was kind of unspecified at the time in the write-up. 32:31.950 --> 32:40.470 In theory, we could have done it with something like bullet proofs, but it would have involved hash functions, and that kind of gets messy to do in, you know, in circuits. 32:40.850 --> 32:42.190 So that was not ideal. 32:42.490 --> 32:56.970 But then, you know, they came up with another idea that uses this clever cross-group proof, where you basically prove that across two different groups, which are, you know, otherwise basically algebraically incompatible, and you can show a quality of like an unknown discrete log. 32:57.310 --> 33:08.630 And it turns out if you can do this, you know, you can very cleverly kind of build it into this protocol involving some Monero transactions and some Bitcoin -style transactions in a way that could let you do atomic swaps. 33:09.610 --> 33:11.250 It's pretty darn interesting. 33:11.630 --> 33:24.690 You know, there's still some kind of open, ongoing questions about, you know, how you need to those transactions, just to make sure that, you know, if one or more of the parties that are involved in this doesn't follow the protocol, you know, what are the risks to funds, 33:24.690 --> 33:25.310 if anything? 33:25.310 --> 33:27.510 What's the worst case scenario that could occur? 33:27.730 --> 33:38.390 And even then saying, well, okay, suppose that the protocol does work exactly as you'd expect, and the swap does happen, you know, what information, if any, does that leak across, you know, one or more of those chains? 33:39.390 --> 33:49.790 So, I mean, for example, if you use a centralized service to do swaps right now, like that can obviously have some risk, because that entity knows presumably where assets came from and where they're sending them to. 33:50.290 --> 33:52.750 So, you know, that kind of is a central storage kind of risk. 33:52.850 --> 34:01.830 But also you can do different kinds of timing analysis and other amount analysis across different chains to try to determine, you know, what's going on and what funds are moving where. 34:02.010 --> 34:04.610 And if that's a risk for you, then you don't really want that. 34:04.690 --> 34:16.930 So I think the question of what, if anything, about that kind of analysis would transfer from the current setup, which is like, you know, use a centralized service to do my exchanges versus saying, well, I'll just do it atomically without a central service, 34:16.930 --> 34:18.910 like what kind of analysis could still happen? 34:20.670 --> 34:23.630 It's not nothing, because metadata always exists. 34:23.630 --> 34:31.990 But I think the question of to what extent does it happen and, you know, is that something that you want to do, I think are still open, but very interesting nonetheless. 34:33.530 --> 34:37.290 There were some other ideas for stuff like payment channel networks, even within Monero. 34:37.750 --> 34:43.610 My DLSag was another signature construction that some other researchers came up with. 34:43.610 --> 34:49.930 And we looked at it, and unfortunately had like this tracing problem that would have required this whole self-spend thing. 34:49.930 --> 34:54.930 And it was, it kind of got messy, and there wasn't really a great solution for it, unfortunately. 34:55.270 --> 35:04.070 So that kind of ended up being dead in the water for that purpose, at least, which was really unfortunate, because DLSag would have opened the door to some interesting stuff. 35:06.110 --> 35:07.490 Got it, got it. 35:07.490 --> 35:09.590 I know this isn't the DLSag names. 35:09.590 --> 35:11.650 Yeah, let's go through every letter. 35:11.650 --> 35:15.610 Something involving a DLSag construction, just for even more confusion. 35:18.320 --> 35:32.660 So I know this isn't your work directly, but I know Isthmus recently opened a community crowdfunding system proposal to look into potential limitations in Monero related to quantum computing. 35:32.660 --> 35:40.360 He was going to look at the initial scope of what basically challenges Monero needed to address going forward. 35:40.360 --> 35:47.780 Can you speak a little bit about what this general work is doing, and then also speak about Monero and quantum computing generally? 35:48.000 --> 35:50.960 Yeah, so this is work that's ongoing. 35:51.400 --> 35:54.400 I believe we're going to work on it for three months. 35:54.400 --> 35:56.560 We're about done with the first month, I think, of that. 35:56.840 --> 36:00.460 So again, I'm like not directly working on this, so I don't want to try to speak for them or anything. 36:00.460 --> 36:11.440 But their idea was, okay, under the assumption that someday quantum computers would exist, and there's definitely debate on to what extent people think that this would be a problem in the future. 36:11.440 --> 36:13.240 If so, how far into the future? 36:13.880 --> 36:23.700 And if all of that, what actions would we want to take now in the protocol to try to mitigate the possible future effects of quantum computers? 36:23.780 --> 36:34.980 They want to look at different parts of protocol, of range groups, and ring signatures, and the one-time addressing construction, and all of this stuff. 36:34.980 --> 36:40.600 To what extent would different parts of the chain be considered at risk? 36:41.300 --> 36:49.080 The way the Monero keys work, there's a private key and public key, and they're related by this algebraic group operation. 36:49.080 --> 37:04.600 And it's pretty well understood that the one-way map right now, from private key to public key, where we assume that it's computationally feasible to determine the signing key just if you see a key on the chain, we assume that that's very difficult right now and it's a one-way operation. 37:04.960 --> 37:12.140 It's pretty well understood that given a sufficiently advanced quantum computer, that map would be reversible efficiently. 37:12.400 --> 37:17.360 So at that point, spend anyone's funds, which I know that's a problem right now. 37:17.500 --> 37:21.640 But to some extent, it's not necessarily just a problem for Monero. 37:21.960 --> 37:24.400 This is kind of a broadly applicable problem. 37:24.400 --> 37:28.300 The entire internet runs on these one-way maps right now, to a large extent. 37:28.460 --> 37:33.000 So it's kind of one of those, well, your house is on fire, but the rest of the world's on fire too. 37:33.100 --> 37:38.180 Doesn't make your fire any less bad, but it does mean that there would be a lot of problems to worry about. 37:38.620 --> 37:43.960 But even beyond that, looking at things like, what would that allow you to do to ring signatures? 37:44.000 --> 37:58.480 So as one example, since the key images or linking tags work within the Monero protocol, it would allow you to look at different outputs that are part of a ring and determine which of them is the signer. 37:58.600 --> 38:05.300 Because of the way that the keys work right now, they involve private keys and you can basically do a guess-and-check testing operation. 38:05.300 --> 38:12.560 So again, under the assumption of a hypothetical quantum computer, and this is impossible today as far as we know, you could figure that out. 38:12.640 --> 38:19.480 There's some other questions right now involving things like, what could you determine about stealth or one-time addressing operations? 38:19.980 --> 38:23.460 And that's still, I think, a little bit ambiguous right now. 38:23.540 --> 38:31.900 One question that I have that I know is not unique to Monero is saying, well, okay, suppose that I will have a transaction here. 38:32.100 --> 38:39.760 Maybe I can't just use that transaction to, for example, figure out what the wallet address of the recipient was. 38:39.760 --> 38:43.600 Because remember, in Monero, wallet addresses never appear directly on-chain. 38:43.600 --> 38:45.980 They're used to derive these one-time addresses. 38:46.440 --> 38:54.460 So right now, I mean, without external information, you can't just use on-chain information to link those one-time addresses back to the wallet addresses. 38:54.580 --> 39:02.760 So the question might be, even with the quantum computer, could you take a transaction and determine its recipient wallet address, just kind of with no external information? 39:03.040 --> 39:15.480 Or if you, for example, had a candidate list of possible recipients that you think it might be because, you know, maybe you have a hunch or some other external information, are there ways that you could go and basically check those to determine which it would be? 39:15.860 --> 39:22.180 And again, the address space in Monero is, like, the possible wallet address space in Monero is, you know, unfathomably huge. 39:22.180 --> 39:26.780 And, you know, a quantum computer doesn't just mean, like, can do everything fast automatically. 39:27.120 --> 39:31.940 There's particular algorithms that we know that can be used against things like the discrete log problem and stuff. 39:32.220 --> 39:45.760 So, you know, even if you had a hypothetical quantum computer, you know, saying, well, couldn't it just go through, you know, all possible addresses and see which it is and figure out, you know, what recipient is linked to what transaction? 39:46.120 --> 39:48.660 You know, that's likely not going to be directly possible. 39:48.720 --> 39:55.840 But the question of, you know, what could such a computer do if it had, like, a small known list of possible addresses? 39:55.940 --> 40:00.820 So questions like that, I think, are still kind of up in the air and are part of the subject of the research that they're working on. 40:01.100 --> 40:16.700 And I do know that they're also looking at kind of what current directions my protocol development take that could more efficiently, I guess, work on trying to, like, mitigate the effects of a future quantum computer. 40:17.440 --> 40:24.120 I guess one problem with a lot of algorithms and constructions that are conjectured to be post-quantum secure is efficiency. 40:24.120 --> 40:29.800 They often tend to be much more inefficient than, I guess, would be reasonable to have on-chain. 40:29.900 --> 40:33.560 You know, right now, if, like, post-quantum signatures, for example, can get pretty large. 40:33.560 --> 40:38.540 And there have been some ideas for how to do some constructions, like linkable ring signatures, even. 40:38.660 --> 40:39.860 But they're very large. 40:39.860 --> 40:49.520 And even if you were to integrate them into the protocol, you know, we still deal with today's computers that, you know, still have to store things and do a lot of processing. 40:49.540 --> 40:54.960 And if it gets to be too large of a transaction that's too slow, no one's going to use it. 40:55.120 --> 41:02.060 So, you know, ideally, we'd like to migrate the protocol immediately to something that's conjectured to be post-quantum secure. 41:02.100 --> 41:07.480 But there's a lot of parts of the protocol that it's really uncertain if there's anything at this point that's efficient enough. 41:07.920 --> 41:11.360 I mean, research in this area is always ongoing. 41:11.620 --> 41:24.300 So, obviously, what's the state-of-the-art today is almost certainly not going to be even close to what the state-of-the-art is, you know, in 10 years, 20 years, you know, further down the line, where maybe we have a better understanding of the likelihood of seeing a practical quantum computer. 41:24.820 --> 41:40.080 So I think one thing that they're trying to do, and, you know, I don't, again, I don't want to speak for them, but just my understanding of the work that they're doing is to, you know, look at what are at least some directions in research that might give us an indication about what could be efficient down the road for protocol improvements. 41:40.840 --> 41:50.260 I mean, I guess the general thing is, like, to some extent, like, in the age of, you know, post-quantum computers, like, a lot of the internet's kind of screwed in terms of security. 41:50.440 --> 41:55.740 So, I mean, like, Monero would be, you know, at least to some degree not immune to this. 41:55.740 --> 42:03.820 The extent of which different parts of the, I guess, previous chain's history could be known, I think the exact nature of that is what they're trying to determine now. 42:05.340 --> 42:07.220 It's really interesting work. 42:07.700 --> 42:17.180 Whether or not you think that it's going to be applicable in, you know, your lifetime or the lifetime of people you care about, I think that's also very much kind of a contentious issue right now. 42:17.180 --> 42:25.780 I don't think that there's really universal agreement on, you know, when, if ever, folks might end up seeing a practical quantum computer that would affect projects that they use. 42:26.640 --> 42:31.020 And, I mean, I'm not even close to an expert enough in that area to be able to even hypothesize. 42:32.660 --> 42:33.860 Yeah, I got it. 42:34.120 --> 42:47.580 So, switching gears, what research have you seen outside of what you've specifically done for Monero, I would say, that has been, not necessarily useful, but just really interesting and really surprising? 42:48.820 --> 42:57.440 I would say, I think, just, like, the extensive work that's been done on general zero-knowledge-proven systems, I think, is really cool. 42:58.780 --> 43:06.040 So, I mean, right now we use very specific zero-knowledge-proven systems in different projects for different purposes. 43:06.040 --> 43:12.480 I mean, Bulletproof, for example, is a zero-knowledge-proven system that does, like, one particular thing involving Peterson commitments really well. 43:12.820 --> 43:15.220 However, that's just one application. 43:15.220 --> 43:32.640 There's kind of a variant form of Bulletproofs that you can use to take different algebraic statements, kind of mess them into this particular circuit format, and then build a proof over the circuit arrangement in order to prove that you know, I guess, 43:32.640 --> 43:36.340 like, a witness that ends up satisfying the circuit without revealing what that witness is. 43:36.480 --> 43:40.540 And, like, that's kind of the general form of, like, a general zero-knowledge-proven system. 43:40.540 --> 43:56.000 So, if you have a protocol that you really want to implement, if you can put it into this form and do this kind of representation, then there's all these different tools that you can use right now to prove things about statements relating to this language that you built. 43:56.480 --> 43:58.520 So, Bulletproofs can do that. 43:58.740 --> 44:04.500 The different proving systems that are used, you know, in stuff like Zcash protocols can do that. 44:04.500 --> 44:06.840 There's a lot of stuff involving, like, zkstarts. 44:07.160 --> 44:13.660 And, you know, there's a whole host of really interesting research on how to do this and what the different trade-offs are. 44:13.960 --> 44:23.340 And, like I said before, like, kind of the, I would say the holy grail for this is trust-free, small, and efficient to generate and verify proofs. 44:23.340 --> 44:30.220 And, ideally, also stuff involving things like batching that lets you kind of amortize the cost of verification over multiple proof verifications. 44:30.340 --> 44:34.900 Like, just the fact that there's so much fascinating work going on relating to this is really interesting. 44:35.280 --> 44:46.760 And, unfortunately, none of it that I've seen, I think, kind of applies directly to the Monero protocol based on what folks want from it right now. 44:47.760 --> 44:50.780 You know, right now, the whole trust thing seems to be a pretty big sticking point. 44:50.920 --> 45:02.640 You know, like I said, you know, for users who decide that, you know, they need a protocol that does more than what Monero can offer, like, you probably, at this point, are going to have to sacrifice that whole, you know, where is the trust lie question. 45:04.420 --> 45:15.900 But, at the same time, the fact that the research is ongoing and has undergone so much improvement over a pretty short period of time, I think, speaks really highly to where that area of research is going to go in the future. 45:16.560 --> 45:26.040 So, I mean, I think it would be great to be able to move to a general, idealized, future zero-knowledge proving system that lets us build really cool protocols that give us everything we want. 45:27.960 --> 45:28.940 It's not today. 45:28.940 --> 45:30.320 Hopefully, it's not too far off. 45:31.260 --> 45:33.720 There has been a lot of work in that area. 45:33.720 --> 45:34.220 It's been shocking. 45:34.220 --> 45:35.140 Oh , it's insane. 45:37.440 --> 45:46.920 Yeah, and to be clear, like, I'm really glad that other projects are doing research in that and, you know, putting that kind of stuff into practice. 45:47.120 --> 45:51.720 Like, as with all projects, including Monero, like, I think it's important to talk about limitations and trade-offs. 45:51.720 --> 45:55.000 Like, if you've tried to do things like this, you're breaking Monero. 45:55.380 --> 46:00.460 But it's still good that, you know, those different kinds of applications are also furthering more research. 46:05.860 --> 46:09.920 Sorry, I'm also helping some other later speakers come through. 46:09.920 --> 46:11.220 Okay, so you have another five minutes. 46:11.220 --> 46:14.800 There aren't any other questions that have come in, sadly. 46:14.800 --> 46:16.400 Just the two from Andres. 46:17.780 --> 46:20.000 So, thank you, Andres, for answering those questions. 46:20.000 --> 46:21.180 We appreciate them. 46:21.720 --> 46:22.440 Um, 46:29.570 --> 46:32.870 no one else came to the office hours. 46:33.330 --> 46:35.230 They're true office hours. 46:38.310 --> 46:39.570 No, that's okay. 46:39.570 --> 46:46.110 No, I mean, it's good to kind of, I guess, recap, like, how stuff has gone and hypothesize as to where it might go. 46:46.610 --> 46:47.690 I mean, research is interesting. 46:47.690 --> 46:51.710 You know, you never know what's going to come up, what's going to work, what's not going to work. 46:53.630 --> 47:08.230 I think the upgrade in October is going to be exciting, because, you know, Bulletproof was, I think, a cool example of something where transactions got smaller and faster, and there were really no big trade-offs that folks had to consider. 47:08.870 --> 47:19.090 And I think CLSAG is another example, where, you know, the transactions get a little smaller, they go faster, and not to the extent that Bulletproof's did. 47:19.410 --> 47:22.570 And there's not really any security trade-offs. 47:22.570 --> 47:29.350 You know, if anything, working with CLSAG helped to kind of improve the way that we understand linkable ring signature security models. 47:29.350 --> 47:35.810 So, if anything, like, I feel like there's more confidence now about the security of the setup that we're going to have. 47:37.090 --> 47:38.810 So, if anything, it's not really a trade-off. 47:38.810 --> 47:43.070 It's just, you know, kind of an increasing stack of benefits. 47:44.330 --> 47:48.670 You're saying that it would be weird a little bit with whatever comes next. 47:48.670 --> 47:57.950 Because with RingCT, for example, it was an absolutely necessary change to get to hide the amounts of transactions, and all the other benefits came with them. 47:57.970 --> 48:07.770 And I think the issues with denominated Monero were not, they still continue to not be well-documented in, I think, like, a very clear way. 48:07.770 --> 48:14.790 We know they're bad, but also, I don't think we've had many research papers yet showing how bad they were. 48:14.790 --> 48:22.010 Oh, I mean, the early Monero chain is, you know, a fantastic source of material for analysis. 48:22.010 --> 48:32.950 You know, I mean, it's well understood that the effects of, you know, a lot of optionality and protocol has always been problematic. 48:32.950 --> 48:42.430 You know, a huge number of early transactions, were effectively, I would say, denominized in the sense of, like, Ring-based signer ambiguity. 48:42.430 --> 48:45.830 You know, not, again, not based on wallet addresses or anything. 48:46.630 --> 48:50.170 But, and I think that that's kind of still influences work that goes on today. 48:50.170 --> 48:53.950 Like, there's still parts of the protocol that have some optionality in them. 48:54.430 --> 49:04.930 And, you know, it's, you know, you can argue that it's good to have some flexibility in the protocol to allow for alternative use cases that you might not anticipate. 49:05.390 --> 49:16.910 But at the same time, like a lot of the work that especially folks like Isthmus and his group have done has shown that the optionality, you know, can lead to fingerprinting if you're not using standard software or using a service that does something in a strange way. 49:18.230 --> 49:35.450 And I think there, I think that a lot of folks are coming around to a better appreciation of the fact that limiting the protocol to, you know, improve uniformity and decrease fingerprinting is very much like a one-sided, increasingly lopsided argument toward, 49:35.450 --> 49:37.470 you know, limiting the protocol. 49:37.990 --> 49:42.890 And there's still, like, there's still things to do in terms of that. 49:42.890 --> 49:52.550 And I think the more that we understand about some of the early protocol decisions and how that optionality was bad, I think the more that that can influence better decisions going forward. 49:53.050 --> 49:56.370 You know, like the protocol always have like the old chain to deal with. 49:56.570 --> 50:07.110 And I think the best to do, the best thing we can do is try to make good decisions going forward to, you know, improve uniformity that can decrease risk and improve safety. 50:09.510 --> 50:10.310 Understood. 50:10.710 --> 50:12.270 Andreas asked the last question here. 50:12.270 --> 50:15.230 Are there any projects working on voting based in Monero? 50:15.230 --> 50:21.470 I know, like, that one Italian government wrote up that one thing about how they maybe were... Yeah, that was, that was a political party, right? 50:21.530 --> 50:22.730 Yeah, it was. 50:22.810 --> 50:25.630 Yeah, I don't know if that ever actually got implemented. 50:25.630 --> 50:27.090 I don't think it did either. 50:27.750 --> 50:43.810 Voting is, I mean, I'm by no means an expert on voting, but everything that I know, and I mean, folks who do different villages at DEF CON involving voting probably know way more than I do that electronic voting is tricky. 50:44.050 --> 50:49.150 And if you think you found out all the ways it could go wrong, it will always surprise you. 50:50.690 --> 50:51.710 So, I don't know. 50:51.710 --> 50:58.710 I mean, I thought it was cool to see in the original LSAG paper an application to voting just kind of as a, like, a fun academic thought experiment. 50:59.070 --> 50:59.990 And who knows? 50:59.990 --> 51:08.770 You know, it's presumably something involving, you know, good signer-ambiguous proofs going forward, you know, might be beneficial. 51:08.850 --> 51:09.910 Who knows? 51:10.770 --> 51:11.790 For voting. 51:11.790 --> 51:16.730 But, you know, I don't think that, like, LSAG or CLSAG would be the thing to use. 51:16.730 --> 51:27.030 I mean, there's enough efficiency problems that, you know, trying to scale that out to the... because, again, like, the whole idea was that you basically have, like, all the different possible voting entities as, like, part of a ring or the entirety of the ring. 51:27.030 --> 51:29.590 Like, I don't... that isn't going to scale reasonably well. 51:29.930 --> 51:44.670 And, you know, the trust model is so much different for voting that, you know, you could probably get away with something that ends up trading certain kinds of trust for... yeah, I don't know, maybe it's trading that kind of trust for better efficiency. 51:45.510 --> 51:48.610 It's... I haven't thought about this in years enough to be able to speak well to it. 51:48.610 --> 51:50.550 So, just keep rambling. 51:50.870 --> 51:51.650 Yeah, understood. 51:51.650 --> 51:53.250 Okay, well, that's the time that we have. 51:53.250 --> 51:54.570 Thank you so much, Sereng Noether. 51:54.570 --> 52:00.970 If people want to follow Monero Research Lab, there's always the monero-research-lab channel. 52:01.510 --> 52:05.490 Sereng's always there, of course, 24-7 manning this. 52:06.010 --> 52:08.070 Yeah, there's definitely the IRC channel. 52:08.070 --> 52:16.430 If folks don't want to be on IRC, you know, posting questions in rmonero, there's a lot of folks there who are good at research and development who can answer. 52:16.650 --> 52:27.070 On the monero-projects meta repo, on the issues there, you can see when all the meetings are and logs from those meetings are always posted as well after the fact. 52:27.210 --> 52:29.870 So, folks want to see, like, what people have been talking about. 52:30.230 --> 52:36.950 Yeah, and everyone's welcome into the meetings if they happen to have anything that they think is interesting or useful research the group might like to see. 52:37.990 --> 52:41.390 So, yeah, a lot of great contributors, not just me by any means. 52:41.390 --> 52:49.610 A lot of really great researchers and folks who are interested in protocol improvements and, you know, improving privacy in the digital asset space. 52:50.370 --> 52:52.610 So, thanks to all the other contributors. 52:53.690 --> 52:55.850 Well, thank you so much, Sereng Noether, for joining us again.