[00:00.000 --> 00:07.920]  Okay, hello everyone and welcome to the Monaro Research Lab office hour with me,
[00:07.920 --> 00:12.320]  your host Justin, and the person you actually want to see, Dr. Strang-Noether.
[00:12.480 --> 00:16.740]  So to start, I would like to have Dr. Strang-Noether introduce himself. Before we get
[00:16.740 --> 00:21.400]  started, I think it would be useful to set expectations for what this session is.
[00:21.580 --> 00:27.300]  It's very casual on purpose. We are here such that we can answer your questions,
[00:27.300 --> 00:29.620]  mostly it'd be Mr. Strang-Noether answering your questions,
[00:30.480 --> 00:34.280]  and yeah, so I will be paying attention to YouTube, I'll be paying attention to Discord
[00:34.280 --> 00:39.220]  just to relay questions over, but otherwise this is really your time to make of it what you would
[00:39.220 --> 00:44.640]  like. So yeah, we're here to answer anything you have. So how about, Strang, can you introduce
[00:44.640 --> 00:52.280]  yourself please? Sure, so I am Dr. Strang-Noether. I'm a cryptographer and mathematician who is a
[00:52.280 --> 00:56.840]  research contributor to the Monaro Research Lab. The Monaro Research Lab is a research and
[00:56.840 --> 01:00.440]  development work group, it's not the only one, but it's a research and development work group
[01:01.880 --> 01:06.960]  that conducts, you know, research and development for the Monaro project. So that ends up being
[01:06.960 --> 01:13.500]  stuff involving protocol research, some of the math, prototyping, coding, all sorts of things,
[01:13.500 --> 01:19.620]  to kind of push the Monaro protocol and privacy preserving digital assets forward in general from
[01:19.720 --> 01:24.980]  a technical perspective. And like Justin said, the purpose of this office hour is to give an
[01:24.980 --> 01:31.420]  opportunity to just kind of very informally give a video forum, in this case, in order to, you know,
[01:31.420 --> 01:36.120]  answer any questions that come up, topics that people want to know more about. So this could be
[01:36.120 --> 01:42.720]  Justin and I sitting here in the quiet for an hour, like often happens in kind of standard university
[01:42.720 --> 01:47.640]  in-person office hours, you know, or it can be, you know, really whatever sort of technical aspects
[01:47.640 --> 01:53.980]  that folks want to talk about. So I guess I'm using whatever, you know, media you, I guess,
[01:53.980 --> 01:58.600]  have access to. Justin, you said you're watching the Discord on YouTube, is that right? Well, yeah, so
[01:58.600 --> 02:03.120]  for any questions that people have, you know, go ahead and shoot them off to us there. We can talk
[02:03.120 --> 02:09.320]  about them. Otherwise, I'll sit here. Perfect. I brought my coffee. You know, I haven't had a lot
[02:09.320 --> 02:14.720]  of coffee with my actual coffee chats recently, but I feel like I've doubled down on the coffee
[02:14.720 --> 02:20.120]  the last few days. Were you the type of person in high school, well, maybe high school depending,
[02:20.120 --> 02:24.120]  but in college that went to office hours, were you the type of person that would usually go or
[02:24.660 --> 02:29.100]  is this something you did not go to that often? I had to go to office hours, you know, when I
[02:29.100 --> 02:36.840]  had questions and later as a TA and even later as an instructor. I don't know. And then I had
[02:36.960 --> 02:40.880]  a new appreciation for the nature of office hours when I was the one, you know, running the office
[02:40.880 --> 02:46.160]  hours. But I did discover that oftentimes it was like this really cool combination of, you know,
[02:46.160 --> 02:49.820]  folks who came because they really wanted to understand something that they didn't,
[02:49.820 --> 02:53.200]  you know, prior to that. But there were also a lot of students who really did know what they
[02:53.200 --> 02:56.820]  were doing and they were just really interested in making sure that they, you know, kind of had
[02:56.820 --> 03:02.200]  as much face-to-face time to kind of go over new problems as they could. So one thing I like is
[03:02.200 --> 03:06.560]  it was like, oh, this is not some kind of sign of weakness to go to office hours. You know,
[03:06.560 --> 03:11.540]  it's like a sign of, I guess, being motivated and dedicated to what you're learning.
[03:12.600 --> 03:15.920]  But there were still many times when I had no one show up to office hours
[03:16.460 --> 03:19.840]  and then it was just reading books for an hour.
[03:21.600 --> 03:28.300]  What are you going to do? Yeah, I guess. 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.740]  Yeah, I was thinking one way we could do is sort of troll the answers out of people. We can just
[03:39.740 --> 03:43.740]  start saying like, well, what do you think about this obnoxious thing? Just to get people all
[03:43.740 --> 03:48.200]  riled up about it. But before we do that, how about you tell us, talk about what you've been
[03:48.200 --> 03:52.480]  doing with the Minerva Research Lab the last month or so. So I would say probably like the
[03:52.480 --> 03:56.200]  most interesting thing that people might care about, or hopefully at least they'll care about
[03:56.200 --> 04:07.620]  the effects of it, is going to be CLSAG, which is a linkable ring signature construction that was
[04:07.620 --> 04:12.300]  intended to be a drop-in replacement to the linkable ring construction that the Minerva
[04:12.300 --> 04:17.340]  protocol used to use. It's called MLSAG. I will say that in hindsight, I really regret
[04:17.340 --> 04:22.860]  us not giving it a cooler name. What would have been a cooler name for that?
[04:22.860 --> 04:26.060]  I have no idea. If anyone has any ideas, you should tell us.
[04:26.060 --> 04:31.660]  I mean, we ended up getting a pretty cool CLSAG logo. Basically, the community came together and
[04:31.660 --> 04:35.380]  we had a few ideas that were pitched, one of which we ultimately went with in the blog post,
[04:35.380 --> 04:46.060]  and they're credited at the bottom. But it's not quite as easy to market as something like Halo
[04:46.060 --> 04:49.900]  or Arcturus.
[04:50.260 --> 04:58.500]  So prior to the confidential transaction model, the linkable ring signature scheme
[04:58.500 --> 05:05.140]  was won by some other authors. It was called LSAG, Linkable Spontaneous Anonymous Group Signatures.
[05:05.380 --> 05:10.020]  From that point on, moving into the confidential transaction model,
[05:10.020 --> 05:15.300]  where we replaced unclear amounts, commitments to amounts, and then we moved to one that was
[05:15.300 --> 05:21.640]  developed by Shen Norther and others, more of an in-house kind of thing. That was called MLSAG.
[05:21.640 --> 05:26.840]  It was a multi-layered, linkable, spontaneous anonymous group signatures. The idea there is
[05:26.840 --> 05:31.720]  that you had both information in the signature that dealt with both signing keys, but also
[05:31.720 --> 05:37.720]  certain commitment keys. And by kind of cleverly setting up and arranging how you do that signature,
[05:37.720 --> 05:44.980]  you could both show this kind of signer-ambiguous signature model you're looking for, but also throw
[05:44.980 --> 05:51.460]  in a proof of balance, which is very important, but also completely in a signer-ambiguous way.
[05:51.720 --> 05:55.540]  The downside to the MLSAG signatures, of course, is you basically kind of have two sets of data
[05:55.540 --> 06:00.340]  floating around in the signature itself. You have some sets of data that deals with the signing
[06:00.340 --> 06:06.400]  keys, and a kind of a separate set of parallel data that deals with the commitment keys. So the
[06:06.400 --> 06:10.760]  scaling on that, you know, is not very good. It scales as, you know, the anonymity set per
[06:10.760 --> 06:15.860]  transaction goes up. It scales that way. But at the same time, every time you're adding on, you know,
[06:15.860 --> 06:19.880]  new ring members, you're actually adding on two pieces of data, effectively. One for signing keys
[06:19.880 --> 06:27.500]  and one for commitment keys. And so the kind of new hotness now is CLSAG, which is concise, linkable,
[06:27.500 --> 06:34.520]  spontaneous, anonymous group signatures. So it is what it is. There was a name that was chosen and
[06:34.520 --> 06:40.620]  thought about changing it, but then we're like, ah, you know, we've already named it. Can't really rename it.
[06:40.640 --> 06:45.640]  So people already knew about that. We didn't want to make everything more confusing. But the idea
[06:45.640 --> 06:51.440]  there is to kind of take this information involving this data for signing keys and this data for
[06:51.440 --> 06:57.480]  commitment keys, and it turns out you can combine them together in this weighted fashion that, you
[06:57.480 --> 07:02.340]  know, hash functions to ensure that, you know, someone can't kind of maliciously go through and run a
[07:02.340 --> 07:09.720]  forgery on the signature. And basically do the same thing that MLSAG signatures do. Both show in a
[07:09.720 --> 07:14.460]  signer-ambiguous way that you're signing a message on behalf of one of the unknown keys. I guess one
[07:14.460 --> 07:19.460]  of the set keys, but you don't know which one it is. But also basically signing with this other
[07:19.460 --> 07:23.100]  commitment key that you need to prove balance. So it's more or less a drop-in replacement, but now
[07:23.100 --> 07:29.120]  effectively you only have to have one set of data involved. So one piece of information per ring
[07:29.120 --> 07:33.240]  member and then some additional auxiliary information that's used just to make the algebra
[07:33.240 --> 07:38.440]  work. So the benefits to this are that it's basically a drop-in replacement, so that's great.
[07:38.860 --> 07:42.380]  You know, everything involving key images sticks around. Everything involving the way that these
[07:42.380 --> 07:47.440]  keys are structured gets to stick around. But the benefits, this benefits that you get for it,
[07:47.440 --> 07:54.140]  are that first the signatures are much smaller. So effectively the signatures you get for CLSAG
[07:54.140 --> 07:59.900]  are about half the size as for MLSAG. That's just a signature alone. Transactions include more than
[07:59.900 --> 08:06.360]  just a signature. So they're smaller in that sense, but they're also faster to verify,
[08:06.360 --> 08:09.980]  because it turns out you can do some optimization with the way that these operations take place.
[08:09.980 --> 08:15.260]  Because before you had to do some cryptographic operations on like the linkable side of the data
[08:15.260 --> 08:19.220]  and on the commitment side of the data. And now you can effectively do them at the same time and
[08:19.220 --> 08:23.820]  you can optimize that away a little bit. So the benefits there are that you end up with about 20%
[08:23.820 --> 08:30.100]  faster signature verification. So transactions that spend multiple inputs, which most transactions
[08:30.100 --> 08:34.800]  spend between one and two inputs and generate some other outputs, but for every one of those spent
[08:34.800 --> 08:40.060]  inputs you need a separate signature. And so it turns out that for the most common forms of
[08:40.060 --> 08:45.020]  transactions, like a two input two output transaction for example, you end up seeing
[08:45.020 --> 08:52.480]  overall about a 25% decrease in the transaction size and overall probably about a 10% speed up
[08:52.480 --> 08:57.420]  in the overall transaction verification. So that's pretty good. There's really no downsides
[08:57.420 --> 09:02.000]  to this. Of course we want to make sure that the security model for this is very strong.
[09:02.200 --> 09:07.840]  So the security model basically just says what properties do we want this
[09:07.840 --> 09:12.580]  construction to have? And for our particular purposes, we want there to be these properties
[09:12.580 --> 09:18.300]  involving forgeability and non-slanderability and linkability. And there's kind of this list
[09:18.300 --> 09:22.940]  of them that you want this linkable ring signature construction to have. So what you do is you
[09:22.940 --> 09:28.280]  basically build this kind of hypothetical model of an imaginary attacker. And you kind of give
[09:28.280 --> 09:32.760]  this attacker different powers to do things. So you might give this imaginary attacker like
[09:32.760 --> 09:38.060]  the power to convince honest users to hand over their private keys. Or you might give this
[09:38.060 --> 09:43.520]  imaginary attacker the power to persuade honest users to build arbitrary transactions
[09:43.520 --> 09:48.860]  on the attacker's behalf. And then you show that even if the attacker had these powers, it still
[09:48.860 --> 09:54.280]  can't go and like generally break these properties that we wanted to have without also breaking
[09:54.280 --> 09:59.400]  some computational problem like the discrete logarithm problem that we assume is computationally
[09:59.400 --> 10:04.320]  feasible to do. So you basically say, aha, this hypothetical attacker can't exist, and therefore
[10:04.320 --> 10:09.620]  we're okay. And so we decided to kind of beef up the security model that was used for CLSAG
[10:09.620 --> 10:15.700]  compared to like LSAG and MLSAG. And in doing so, ended up with, I would say, like a pretty
[10:15.700 --> 10:19.980]  good model for how we want it to work. So that's pretty good. We're pretty sure that the same
[10:19.980 --> 10:23.980]  security model would equally apply to MLSAG, but you know, we didn't go back and kind of
[10:23.980 --> 10:28.720]  retroactively do that. It was considered to be pretty straightforward. Do you know of anyone
[10:28.720 --> 10:33.980]  else that is actually using MLSAG in a sort of production like Monero is? Like, is there any
[10:33.980 --> 10:39.240]  other application that's widely used for this? Oh, I mean, besides like projects that, you know,
[10:39.240 --> 10:46.720]  use it for the same purpose, you know, like CodeWorks or, you know,
[10:46.720 --> 10:50.820]  you know, different digital assets that have at least like the same or a similar protocol,
[10:50.820 --> 10:57.200]  presumably use it. But I'm not aware of any other direct applications. So originally LSAG, one of
[10:57.200 --> 11:03.420]  the, in the original paper that originally introduced LSAG, you know, one option that was
[11:03.420 --> 11:08.700]  listed was like voting schemes, for example, you know, where you want to be able to ensure that
[11:08.700 --> 11:13.660]  someone can't vote twice for a particular issue, but also some ambiguity among the set of possible
[11:13.660 --> 11:17.320]  voters. I don't think that that's actually been implemented yet. I mean, secure voting is really
[11:17.320 --> 11:23.040]  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:30.860]  And so I just got to finish up too. The Monero community commissioned an external audit of both
[11:30.860 --> 11:36.500]  the paper, but should be very careful to say pre-print. This pre-print is still technically
[11:36.700 --> 11:40.440]  a pre-print. So that means it hasn't undergone any other peer review aside from what I'm going
[11:40.440 --> 11:46.240]  to talk about. But we decided to have the pre-print externally audited, as well as
[11:46.240 --> 11:52.900]  the implementation for the upcoming October network upgrade audited. So that was done.
[11:52.900 --> 11:58.120]  There were two auditors who were commissioned to do that, and that was in kind of in consultation
[11:58.120 --> 12:02.720]  with the Open Source Technology Improvement Fund, which is a non-profit that does support for these
[12:02.720 --> 12:07.760]  kind of things and supported by Monero community donations. And the auditors had a lot of really
[12:07.760 --> 12:14.600]  good suggestions for how to improve the overall CLSAG security model and pre-print. So ended up
[12:14.600 --> 12:19.980]  changing a few of the proofs around and generally just improving how the security model and proofs
[12:19.980 --> 12:24.060]  were structured and run. And those didn't actually require any other changes to the
[12:24.060 --> 12:28.500]  scheme itself. So the construction itself, and therefore the code, didn't change as a result of
[12:28.500 --> 12:32.940]  that. But we're now much more confident in the way that the security model was arranged. Some
[12:32.940 --> 12:37.400]  of the definitions, the cryptographic hardness assumptions, and things like that. So that's
[12:37.400 --> 12:42.740]  great. Those changes have been made and that's now up on the IACR ePrint archive. And then the
[12:42.740 --> 12:48.800]  implementation surprisingly didn't require any real changes for security, which I feel like usually
[12:48.800 --> 12:53.760]  you get some in there. There were a few kind of informational ideas for how to simplify the code,
[12:53.760 --> 12:57.700]  but we considered that changing those, they would have been fairly extensive in how we
[12:57.700 --> 13:01.960]  handle certain key structures and such. And it was thought that it was probably more likely to
[13:01.960 --> 13:07.220]  introduce risk if we made kind of these big sweeping, more informational changes than if we
[13:07.220 --> 13:13.280]  were to just leave it. So yeah, so the report's available. There's a blog post up on getmonero.org
[13:13.280 --> 13:17.200]  about it. You can read the full report, take a look at the pre-print, look at the code if that's
[13:17.200 --> 13:24.660]  your thing. Awesome. Yeah, so that's scheduled to be deployed in the October network upgrade. So
[13:24.660 --> 13:30.260]  all you need to do is just keep your software updated. If you use a hardware wallet like a
[13:30.260 --> 13:36.340]  Trezor or Ledger, that's in process as well, getting their firmware and apps updated as well
[13:36.340 --> 13:40.500]  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.500 --> 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:51.680]  Very cool. We had a question come in from Andres. He asked if there's any plans to, in the future,
[13:51.680 --> 13:56.840]  move past ring signatures to something that is not just hidden between other decoys,
[13:56.840 --> 14:01.200]  but has additional protections beyond just a decoy level protection. So I guess
[14:01.200 --> 14:06.980]  there's quite a few things that I know are involved in this question. One is we have
[14:06.980 --> 14:12.420]  the current decoy selection, which per transaction has a relatively small number of decoys per
[14:12.420 --> 14:18.220]  selection, which provides reasonable mass surveillance protection, but less so good
[14:18.220 --> 14:23.420]  targeted surveillance if someone knows information about particular transactions. So I guess given
[14:23.420 --> 14:31.320]  the current situation, what is the approximate timeline forward? Not necessarily the timeline, but
[14:31.320 --> 14:40.260]  the set of potential improvements forward for whether or not ring signatures are sort of the
[14:40.260 --> 14:46.520]  right approach for the future, and how you've approached dealing with the core problem of the
[14:46.520 --> 14:53.380]  relatively small per transaction decoy levels. Yeah, so really the question seems to be kind
[14:53.380 --> 15:00.120]  of about per transaction anonymity sets. I increasingly dislike the idea of using the
[15:00.120 --> 15:05.860]  term ring signature to purely mean a limited anonymity set, just because while it has been
[15:05.860 --> 15:11.120]  the case so far that our ring signature construction does have a limited anonymity set,
[15:11.120 --> 15:16.020]  I don't think it's necessarily the correct term to use. So it's possible to build
[15:16.020 --> 15:21.840]  transaction protocols with limited anonymity sets or full anonymity sets, and you could probably do
[15:21.840 --> 15:25.540]  all sorts of other things. I mean, we know that there's transaction protocols that have no anonymity
[15:25.540 --> 15:32.180]  sets, but those are typically not the ones we're interested in. So what we do right now is we do
[15:32.180 --> 15:36.900]  in fact use a linkable ring signature as kind of a building block in a limited anonymity set
[15:36.900 --> 15:42.360]  transaction protocol for the Monero protocol. That's not the only way to do it though. So it
[15:42.360 --> 15:46.620]  is possible to build limited anonymity set transaction protocols that use, for example,
[15:46.620 --> 15:51.120]  specialized zero-knowledge proving systems. So I really don't like the whole idea of zero-knowledge
[15:51.120 --> 15:55.720]  meaning full anonymity and ring signature meaning not, because that tends to be
[15:56.640 --> 16:00.640]  certain implementations now, but it is not generally true. I mean, those things have
[16:00.640 --> 16:06.080]  much more technical meanings involving proof and signature constructions, but
[16:06.780 --> 16:14.100]  using them the way that we do today. So it's possible to kind of migrate over to a still
[16:14.100 --> 16:20.180]  limited anonymity set construction, but one that permits much larger anonymity sets for
[16:20.180 --> 16:26.100]  reasonable transaction sizes and times, but in a way that ideally would help against certain
[16:26.100 --> 16:31.500]  other forms of analysis or attack. Because again, right now, the way that the transaction
[16:31.500 --> 16:36.320]  protocol signatures scale is that they scale linearly with the size of the anonymity set.
[16:36.320 --> 16:41.320]  So you're really kind of stuck there. And there's been some proposals for ways to use
[16:41.320 --> 16:46.600]  different kinds of specialized zero-knowledge proving systems. Some examples of that are
[16:46.600 --> 16:53.440]  OmniRing is one of them, Atlantis is another one, RingCT3, Tryptic, Torus. There's probably other
[16:53.440 --> 17:01.740]  ones that I'm just not thinking of right now. But all of these essentially allow a transaction proof
[17:01.740 --> 17:07.260]  along with possibly some other auxiliary proofs that scales much better in terms of size and
[17:07.260 --> 17:12.760]  scales a little bit better in terms of time. So verification time is unfortunately kind of
[17:12.760 --> 17:17.300]  the sticking point for this. So if you want a trust-free, like a non-centralized, you know,
[17:17.300 --> 17:23.060]  trusted setup style proving system and transaction protocol, you can make those proofs very small.
[17:23.480 --> 17:28.720]  Like we know how to do that already. They're not as small, for example, as like the proofs,
[17:28.720 --> 17:32.800]  not the transactions, the proofs in say Zcash, but they're still quite small for the size of the
[17:32.800 --> 17:37.480]  limited anonymity set you can get. But verification time is always a sticking point. So with those
[17:37.480 --> 17:44.620]  particular kinds of protocols and proofs, you do need still like a almost linear verification time.
[17:44.700 --> 17:51.460]  That'd be the sticking point. So that's kind of the limitation that exists. There are options.
[17:51.460 --> 17:56.380]  They've all got some trade-offs in terms of, you know, what you can do with things like tracing
[17:56.380 --> 18:01.320]  and how the construction works. Some of them involve changes to multi-signature
[18:02.300 --> 18:06.320]  operations. There's changes to the way that linking tags work, which is kind of require
[18:06.320 --> 18:11.760]  almost sort of like a pool migration that can still be done safely. And so which one of these,
[18:11.760 --> 18:15.500]  if any, should be the one going forward is kind of up in the air right now. A lot of it depends
[18:15.500 --> 18:19.480]  on what trade-offs people are willing to accept and also what trade-offs people are willing to
[18:19.480 --> 18:25.060]  accept in terms of mainly like transaction verification times. Obviously, we'd like
[18:25.060 --> 18:30.060]  verification to be as low as possible because that means faster operations. But that has to
[18:30.060 --> 18:34.060]  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:43.820]  Kind of the classic example of that right now is something like the Zcash protocols,
[18:43.820 --> 18:48.740]  where different anonymity sets that are involved there are basically enforced using proofs that
[18:48.740 --> 18:53.840]  do things involving Merkle tree proofs. And what that effectively does is effectively gives you
[18:54.160 --> 18:58.720]  a full anonymity set within that pool, absent external information. That would be ideal.
[18:58.720 --> 19:02.100]  But right now, all the proposals that are kind of on the table for doing that
[19:03.060 --> 19:08.960]  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:24.620]  You know, for example, in many of the protocols, in many of the pro... hang on here,
[19:24.620 --> 19:28.180]  there's someone else drawing the room here. Yeah, I think it's probably one of the next
[19:28.180 --> 19:33.740]  speakers, I assume. But um, yeah, anyway, right now, like, that's kind of the limitation.
[19:34.000 --> 19:39.360]  So under the assumption that, you know, the project and its community are unlikely to move
[19:39.360 --> 19:42.540]  to something that would require centralized trust, you know, right now, there has to be
[19:42.620 --> 19:46.460]  a limitation of limited sets. And so there's still questions about, you know, how do you end
[19:46.460 --> 19:50.800]  up choosing those anonymity sets? There are definitely ways you can do it that I think
[19:50.800 --> 19:55.260]  provide improvements over the way we do it now. As you get bigger anonymity sets, you can do
[19:55.700 --> 20:01.680]  kind of, you can do certain kinds of binning with the outputs in those anonymity sets.
[20:01.680 --> 20:06.900]  And that can mitigate certain kinds of heuristics involving common ownership. And, you know,
[20:06.900 --> 20:12.680]  the source of where those outputs came in terms of transactions earlier on the chain,
[20:12.680 --> 20:16.040]  as well as timing analysis. So there's a lot of interesting stuff you can play with. But I don't
[20:16.040 --> 20:20.160]  think there's a really good understanding right now of what exactly those precise trade-offs
[20:20.160 --> 20:26.800]  people are willing to make are. Yeah, in my experience, you know, we have, we have code
[20:26.800 --> 20:31.580]  that can do this now. But I think it's a matter of kind of the community and researchers and
[20:31.580 --> 20:37.280]  developers kind of getting into agreement on what those trade-offs should be. So, and again,
[20:37.280 --> 20:41.760]  hopefully, you know, eventually we get to something that is efficient and trust-free,
[20:41.760 --> 20:44.740]  which would kind of check all the boxes for everyone. And from there, you could, you know,
[20:44.740 --> 20:49.840]  very likely build a protocol that uses such a system and does, in fact, give you effectively,
[20:49.840 --> 20:52.480]  you know, full anonymity, which presumably would be enforced.
[20:54.340 --> 20:59.780]  In my experience, when people talk about full anonymity or limited anonymity,
[20:59.780 --> 21:06.640]  it's, it's sort of in an academic only way. And then it's applied to like, you know, it's
[21:07.060 --> 21:13.220]  typically the way things are currently, right? So limited anonymity looks like a Monero's case,
[21:13.220 --> 21:18.300]  right? And that, in many cases, people think that that just can't even really change. They
[21:18.300 --> 21:24.220]  don't really think about these limited is just, you know, anything less than the full pool.
[21:24.220 --> 21:28.380]  And that could be a, you know, a larger number than the entire size of the pool of enough
[21:28.380 --> 21:35.560]  different network, theoretically. And then people are like, yeah, it also depends on what exactly
[21:35.560 --> 21:40.080]  your threat model is, right? You know, are you concerned about knowing various after,
[21:40.080 --> 21:44.940]  you know, making a bunch of controlled purchases, and then examining the possible transaction tree
[21:44.940 --> 21:48.740]  between you and like, you know, I don't know, an exchange with whom this person or entity is
[21:48.740 --> 21:55.200]  colluding. So, you know, given that, you know, that it's very difficult to get, I would say,
[21:55.200 --> 21:59.180]  practical anonymity, you know, in that particular circumstance. And there's plenty of other
[21:59.180 --> 22:04.040]  circumstances that you can dream up, where under certain threat models, limited anonymity just,
[22:04.040 --> 22:08.540]  you know, won't work for you. So it's one of those, like, it's one of those infuriating,
[22:08.540 --> 22:13.960]  it depends kind of ends, where, you know, it's like limited anonymity right now is a trade-off.
[22:13.960 --> 22:21.060]  It is like an absolute trade-off. And we all look forward to the day when we can do something that's
[22:21.060 --> 22:25.360]  trust-free. And, you know, frankly, like if your particular threat model is going to require,
[22:25.360 --> 22:30.260]  you know, a more full anonymity scenario, you know, then, you know, you might have to consider
[22:30.260 --> 22:35.280]  whether or not going to like a trusted setup sort of scenario is something that you need to do.
[22:36.800 --> 22:41.820]  That may come with its other trade-offs, you know, based on things like ecosystem availability,
[22:41.820 --> 22:47.020]  and, you know, a host of other questions. But it's absolutely a trade-off, you know,
[22:47.020 --> 22:49.000]  and I think it's important to acknowledge that, you know, we have things like the
[22:49.000 --> 22:53.160]  Breaking Monero Series where, you know, we kind of try to tease out some of the particular scenarios
[22:53.160 --> 22:57.960]  under which limited anonymity can be a problem, and those for which it might not be as much of a
[22:57.960 --> 23:03.260]  problem. But it's, I feel like, no, it's not fun to like sit down and try to enumerate and think
[23:03.260 --> 23:07.880]  about the specifics of a risk model, but, you know, it's something that unfortunately right
[23:07.880 --> 23:14.500]  now we kind of have to do. We haven't had a Breaking Monero Series in a while, so I guess,
[23:14.500 --> 23:21.260]  given that we haven't, what episode ideas would you like to see there be episodes for?
[23:21.920 --> 23:25.620]  Oh man, I think it'd be interesting to do one that talks about,
[23:26.440 --> 23:31.480]  I guess, some more specifics on things like churn and self-send operations.
[23:32.340 --> 23:35.840]  So I would say things like that, something involving things like output merging would be
[23:35.840 --> 23:39.860]  very, very interesting, you know, where outputs from different transactions end up being pulled
[23:39.860 --> 23:44.480]  into different anonymity sets into the same later transaction. I'm looking at ways to possibly
[23:44.480 --> 23:48.180]  mitigate that, you know, larger anonymity sets with good output selection can mitigate that
[23:48.180 --> 23:52.860]  example. The churn example is a bit tougher because you could look at things like, you know,
[23:52.860 --> 23:59.000]  possible chain history sizes and distributions and look at, you know, what happens with that.
[23:59.400 --> 24:04.340]  I think it's, yeah, there's a lot of interesting things to talk about, but I think it's important
[24:04.340 --> 24:08.420]  to do them in a way that doesn't end up kind of just rapidly devolving into, you know, confusing
[24:08.420 --> 24:20.700]  graphs and, you know, irritating math. But at the very least, I think I'm really happy at least to
[24:20.700 --> 24:24.840]  see that there's a lot of interesting research into this area. You know, a lot of folks want
[24:25.620 --> 24:29.140]  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:37.640]  And it's interesting to see what different projects do, right? You know, I mean, things
[24:37.640 --> 24:44.520]  like Zcash and related projects get, you know, efficient proofs that are very fast to verify,
[24:44.520 --> 24:48.860]  and you can do things like effective with full anonymity set transaction protocols,
[24:48.860 --> 24:54.700]  in theory, ideally. Zcash kind of has their whole optionality part to it, but are willing to
[24:54.700 --> 25:00.200]  sacrifice trust to a degree to like multi-party computation, you know. And there's always kind
[25:00.200 --> 25:03.800]  of the question of, like, for your personal use case and how you tend to view multi-party
[25:03.800 --> 25:09.500]  computation, you know, do you think that a multi-party computation setup kind of diffuses
[25:09.500 --> 25:13.180]  the trust out enough to where you're okay with that, or are you not okay with that? You know,
[25:13.180 --> 25:18.420]  because in the theory that does provide like a guaranteed, you know, this is how the soundness
[25:18.420 --> 25:23.860]  of this operation could fail scenario, if that multi-party computation were, you know, misused,
[25:23.860 --> 25:32.900]  for example. So, so many questions in this space, and so many trade-offs. I feel like a lot of
[25:32.900 --> 25:39.580]  cryptography is basically just like the precise study of mathematical trade-offs. But, you know,
[25:39.580 --> 25:43.640]  no, I don't really have a good timeline for when, you know, we might be able to move to something
[25:43.640 --> 25:48.800]  that is, you know, what you consider full anonymity. But there are options for increasing
[25:48.800 --> 25:52.440]  the anonymity set, which lets you do a lot of other cool things, hopefully mitigate some
[25:52.440 --> 25:57.380]  analytical heuristics. Wouldn't solve everything, but I think you'd get improvement.
[25:58.600 --> 26:04.820]  So that's on the tip for October, right? Kidding. Not for October. So, I mean, there's other
[26:04.820 --> 26:08.480]  interesting things, you know, on the horizon too. Ideas for making range proofs a little bit more
[26:08.480 --> 26:12.560]  efficient have come up. There was a preprint that came out on improvement to bullet proofs
[26:12.560 --> 26:20.320]  called Bullet Proofs Plus. The plus actually means taking away a few proof elements, but Bullet
[26:20.320 --> 26:26.420]  Proofs Minus doesn't sound as good. So, I don't know. There was a proposal to do an implementation
[26:26.420 --> 26:30.980]  of that. It's really new. It's kind of a, it's an extension of the way that the Bullet Proofs
[26:30.980 --> 26:37.400]  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:46.220]  In theory, they'd be like very, very marginally faster to verify, but, you know, in practice,
[26:46.220 --> 26:51.100]  it would pretty much be a wash, I think, in the grand scheme of things. So really,
[26:51.100 --> 26:56.400]  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:06.680]  Were there any other questions that came up besides the one that got us into
[27:07.920 --> 27:13.360]  a very long discussion about protocols? Yeah, there's one. It's still a protocol-related
[27:13.360 --> 27:17.240]  question, so it is going to be a follow-up, though. It says, so the ideal solution for Monero
[27:17.240 --> 27:25.120]  would be zk-SNARKs-like thing that doesn't require a trusted setup? And I believe you basically said
[27:25.120 --> 27:30.380]  yes, but also needs to be efficient. Yeah, yeah, yeah. And, you know, and specifically
[27:30.380 --> 27:36.640]  saying, like, zk-SNARKs specifically, you know, it's... there are different ways to... there are
[27:36.640 --> 27:39.700]  different building blocks you can use to construct protocols, and I think it's important to consider
[27:39.700 --> 27:46.100]  it at a protocol level. So, for example, like, you could basically build something akin to,
[27:46.100 --> 27:52.500]  you know, like the zcache sapling protocol, for example, but without using zk-SNARK construction.
[27:52.500 --> 27:57.840]  You could do that with bulletproofs, for example. I don't think it's actually been done, but I know
[27:57.840 --> 28:01.340]  that there were some estimates made to say, okay, you know, bulletproofs is a zero-knowledge
[28:01.340 --> 28:06.340]  prudent system. The scaling is, you know, in terms of verification, is not as good.
[28:06.340 --> 28:11.060]  Just absolutely not. But what it lets you do is it lets you prove things about circuits
[28:11.980 --> 28:17.940]  in a trust-free way. So that is trust-free. And so, in theory, you could take, you know,
[28:17.940 --> 28:21.860]  the circuit that's using zcache sapling and some of the other constructions, and you could build
[28:21.860 --> 28:26.420]  that in bulletproofs. And you get rid of trust. And the size would still be pretty good. The
[28:26.420 --> 28:31.820]  estimates and the size, like, it'd be competitive. Not quite as good, but still pretty competitive.
[28:32.000 --> 28:37.200]  But the verification would be, no, it wouldn't work. Estimates I saw are, like, still on the
[28:37.200 --> 28:40.260]  order of a second, which you're like, well, a second, that's pretty fast. It's like, yeah,
[28:40.260 --> 28:44.680]  but then you got to do that, like, a million times. So you can, like, amortize that down
[28:44.680 --> 28:50.580]  with batching and stuff, but, you know, it seemed like it was not quite doable at this point.
[28:51.000 --> 28:57.720]  So I would say something that would let you do, like, the whole Merkle proof kind of thing that,
[28:57.720 --> 29:03.740]  you know, effectively lets you do a full anonymity set-based protocol would be ideal if, you know,
[29:03.740 --> 29:08.100]  we could make it mandatory, which other projects have shown you can do that to ensure optimal
[29:08.100 --> 29:14.060]  privacy. But also, I think, ideally is making it trust-free or, you know, at least infusing the
[29:14.060 --> 29:17.940]  trust and the soundness out to the point where everyone is satisfied with it. And I think it's
[29:17.940 --> 29:23.720]  the general view of, you know, a lot of folks who support the idea of Monero to just reduce
[29:23.720 --> 29:30.180]  that trust down to nothing. You know, whereas for other projects, they've decided that they're okay
[29:30.180 --> 29:35.460]  with, you know, kind of delegating that soundness risk off to a large enough, you know, set of
[29:35.460 --> 29:40.860]  participants in a multi-party computation that they are safe, you know, secure enough that they
[29:40.860 --> 29:45.140]  are, I guess, okay with the security of. I don't really know a great way to say that. But that is
[29:45.140 --> 29:48.520]  risky. You know, I mean, like the Sprout multi-party computation that started Zcash, for
[29:48.520 --> 29:54.260]  example, did have a soundness problem. And there was a kind of a whole deal where they had to end
[29:54.260 --> 29:58.180]  up taking down the proof transcripts and hoping that no one was able to figure out and abuse that.
[29:58.180 --> 30:03.960]  So like there's a real non-trivial risk involved, even to something like such a multi-party
[30:03.960 --> 30:10.820]  computation. So that's not without risk either. And it makes the trust situation a little bit
[30:10.820 --> 30:17.640]  more tricky. So I guess I am personally of the opinion that, you know, I like the idea of,
[30:17.640 --> 30:22.740]  I guess, kind of minimizing the possible soundness problems. You know, a soundness
[30:22.740 --> 30:26.940]  problem for something that involves like a trusted setup is the trusted setup and a
[30:26.940 --> 30:31.400]  multi-party computation. You know, for something that, for anything that uses, for example,
[30:31.400 --> 30:35.400]  Peterson commitments, which Monero does, other projects do too, Zcash does, you know,
[30:35.400 --> 30:38.880]  minimal level-based assets do. You know, in theory, if you could break Peterson commitments,
[30:38.880 --> 30:44.460]  that's a problem with, you know, something akin to soundness as well. So it's definitely
[30:44.460 --> 30:48.080]  kind of like this different like threat profile and ideally we want to minimize that.
[30:50.610 --> 30:56.350]  Got it. Something that was discussed quite a few years ago, but I don't think has really
[30:56.350 --> 31:01.890]  come up super recently is the idea of second layer networks on Monero. Like, what if you
[31:01.890 --> 31:04.690]  wanted to put the Lightning network on Monero? What if you wanted to put this, that, or the
[31:04.690 --> 31:11.150]  other on Monero? What if you wanted to put a, you know, a like zk-snark-mixer on Monero,
[31:11.150 --> 31:15.950]  like as an optional thing? Like, so I guess what sort of building blocks need to happen
[31:15.950 --> 31:20.990]  to allow greater compatibility, knowing that right after this we also have a talk about
[31:20.990 --> 31:26.550]  atomic swaps for Monero too? Yeah, yeah, which is a really cool new thing that's still in
[31:26.550 --> 31:31.550]  progress. But yeah, so there's some other researchers who were looking at the possibility
[31:31.550 --> 31:37.170]  what would it take to do, say, you know, atomic swaps between something like Monero and, you know,
[31:37.170 --> 31:42.810]  something like Bitcoin, for example, where in Bitcoin there's a lot of stuff you can do because
[31:42.810 --> 31:50.310]  Bitcoin has both scripting capability, but also, you know, some different kind of setups in
[31:50.910 --> 31:58.170]  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:10.850]  Adding inherent scripting capability would be pretty awful for fungibility, so I tend to view
[32:10.850 --> 32:16.270]  that as probably a non-starter on the Monero side. So given that, the question is, well, okay, so what
[32:16.270 --> 32:23.430]  could you do for something like atomic swaps? And one idea that maybe talked about in the next
[32:23.430 --> 32:28.830]  talk, so I won't try to give too much away, involved a particular zero-knowledge proof that was
[32:28.830 --> 32:33.270]  kind of unspecified at the time in the write-up. In theory, we could have done it with something
[32:33.270 --> 32:38.290]  like bullet proofs, but it would have involved hash functions, and that kind of gets messy to do in,
[32:38.870 --> 32:44.850]  you know, in circuits. So that was not ideal. But then, you know, they came up with another idea
[32:44.850 --> 32:50.850]  that uses this clever cross-group proof, where you basically prove that across two different groups,
[32:50.850 --> 32:55.090]  which are, you know, otherwise basically algebraically incompatible, and you can show a
[32:55.090 --> 32:59.870]  quality of like an unknown discrete log. And it turns out if you can do this, you know, you can
[32:59.870 --> 33:04.830]  very cleverly kind of build it into this protocol involving some Monero transactions and some
[33:04.830 --> 33:11.990]  Bitcoin-style transactions in a way that could let you do atomic swaps. It's pretty darn interesting.
[33:11.990 --> 33:16.810]  You know, there's still some kind of open, ongoing questions about, you know, how you need to
[33:16.810 --> 33:20.890]  those transactions, just to make sure that, you know, if one or more of the parties that are
[33:20.890 --> 33:25.310]  involved in this doesn't follow the protocol, you know, what are the risks to funds, if anything?
[33:25.310 --> 33:29.410]  What's the worst case scenario that could occur? And even then saying, well, okay, suppose that
[33:29.410 --> 33:34.330]  the protocol does work exactly as you'd expect, and the swap does happen, you know, what information,
[33:34.330 --> 33:40.730]  if any, does that leak across, you know, one or more of those chains? So, I mean, for example,
[33:40.730 --> 33:45.390]  if you use a centralized service to do swaps right now, like that can obviously have some risk,
[33:45.390 --> 33:49.790]  because that entity knows presumably where assets came from and where they're sending them to.
[33:50.290 --> 33:54.430]  So, you know, that kind of is a central storage kind of risk. But also you can do different kinds
[33:54.430 --> 33:59.110]  of timing analysis and other amount analysis across different chains to try to determine,
[33:59.110 --> 34:03.030]  you know, what's going on and what funds are moving where. And if that's a risk for you,
[34:03.030 --> 34:08.270]  then you don't really want that. So I think the question of what, if anything, about that kind
[34:08.270 --> 34:12.190]  of analysis would transfer from the current setup, which is like, you know, use a centralized service
[34:12.190 --> 34:16.930]  to do my exchanges versus saying, well, I'll just do it atomically without a central service,
[34:16.930 --> 34:23.630]  like what kind of analysis could still happen? It's not nothing, because metadata always exists.
[34:23.630 --> 34:28.490]  But I think the question of to what extent does it happen and, you know, is that something that
[34:28.490 --> 34:34.150]  you want to do, I think are still open, but very interesting nonetheless. There were some other
[34:34.150 --> 34:40.450]  ideas for stuff like payment channel networks, even within Monero. My DLSag was another signature
[34:40.450 --> 34:44.890]  construction that some other researchers came up with. And we looked at it, and unfortunately
[34:44.890 --> 34:50.810]  had like this tracing problem that would have required this whole self-spend thing. And it was,
[34:50.810 --> 34:55.830]  it kind of got messy, and there wasn't really a great solution for it, unfortunately. So that
[34:55.830 --> 35:00.010]  kind of ended up being dead in the water for that purpose, at least, which was really unfortunate,
[35:00.010 --> 35:04.070]  because DLSag would have opened the door to some interesting stuff.
[35:06.110 --> 35:11.650]  Got it, got it. I know this isn't the DLSag names. 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:23.160]  So I know this isn't your work directly, but I know Isthmus recently opened a community
[35:23.160 --> 35:30.580]  crowdfunding system proposal to look into potential limitations in Monero
[35:30.580 --> 35:34.660]  related to quantum computing. He was going to look at the initial scope
[35:34.660 --> 35:40.940]  of what basically challenges Monero needed to address going forward. Can you speak a little
[35:40.940 --> 35:46.980]  bit about what this general work is doing, and then also speak about Monero and quantum computing
[35:46.980 --> 35:53.780]  generally? Yeah, so this is work that's ongoing. I believe we're going to work on it for three
[35:53.780 --> 35:58.400]  months. We're about done with the first month, I think, of that. So again, I'm like not directly
[35:58.400 --> 36:02.480]  working on this, so I don't want to try to speak for them or anything. But their idea was, okay,
[36:02.480 --> 36:07.760]  under the assumption that someday quantum computers would exist, and there's definitely
[36:07.760 --> 36:12.140]  debate on to what extent people think that this would be a problem in the future. If so, how far
[36:12.140 --> 36:19.520]  into the future? And if all of that, what actions would we want to take now in the protocol to try
[36:19.520 --> 36:25.420]  to mitigate the possible future effects of quantum computers? They want to look at different parts of
[36:25.420 --> 36:33.440]  protocol, of range groups, and ring signatures, and the one-time addressing construction,
[36:33.440 --> 36:39.720]  and all of this stuff. To what extent would different parts of the chain be considered at
[36:39.720 --> 36:46.360]  risk? The way the Monero keys work, there's a private key and public key, and they're related
[36:46.360 --> 36:52.520]  by this algebraic group operation. And it's pretty well understood that the one-way map right now,
[36:52.520 --> 36:56.700]  from private key to public key, where we assume that it's computationally feasible to determine
[36:56.700 --> 37:03.060]  the signing key just if you see a key on the chain, we assume that that's very difficult right now and
[37:03.060 --> 37:08.200]  it's a one-way operation. It's pretty well understood that given a sufficiently advanced
[37:08.200 --> 37:14.760]  quantum computer, that map would be reversible efficiently. So at that point, spend anyone's
[37:14.760 --> 37:19.860]  funds, which I know that's a problem right now. But to some extent, it's not necessarily just a
[37:19.860 --> 37:25.680]  problem for Monero. This is kind of a broadly applicable problem. The entire internet runs on
[37:25.680 --> 37:30.380]  these one-way maps right now, to a large extent. So it's kind of one of those, well, your house is
[37:30.380 --> 37:35.460]  on fire, but the rest of the world's on fire too. Doesn't make your fire any less bad, but it does
[37:35.460 --> 37:40.860]  mean that there would be a lot of problems to worry about. But even beyond that, looking at
[37:40.860 --> 37:46.800]  things like, what would that allow you to do to ring signatures? So as one example, since the
[37:47.380 --> 37:54.100]  key images or linking tags work within the Monero protocol, it would allow you to look at
[37:54.580 --> 37:58.480]  different outputs that are part of a ring and determine which of them is the signer.
[37:58.600 --> 38:02.640]  Because of the way that the keys work right now, they involve private keys and you can basically
[38:02.640 --> 38:07.640]  do a guess-and-check testing operation. So again, under the assumption of a
[38:07.640 --> 38:11.640]  hypothetical quantum computer, and this is impossible today as far as we know, you could
[38:11.640 --> 38:15.600]  figure that out. There's some other questions right now involving things like, what
[38:15.600 --> 38:21.400]  could you determine about stealth or one-time addressing operations? And that's still, I think,
[38:21.520 --> 38:27.480]  a little bit ambiguous right now. One question that I have that I know is not unique to Monero
[38:28.080 --> 38:33.760]  is saying, well, okay, suppose that I will have a transaction here. Maybe I can't just use that
[38:33.760 --> 38:40.000]  transaction to, for example, figure out what the wallet address of the recipient was. Because
[38:40.000 --> 38:44.660]  remember, in Monero, wallet addresses never appear directly on-chain. They're used to derive these
[38:44.660 --> 38:50.260]  one-time addresses. So right now, I mean, without external information, you can't just use
[38:50.260 --> 38:54.460]  on-chain information to link those one-time addresses back to the wallet addresses.
[38:54.580 --> 38:58.760]  So the question might be, even with the quantum computer, could you take a transaction and
[38:58.760 --> 39:04.360]  determine its recipient wallet address, just kind of with no external information? Or if you, for
[39:04.360 --> 39:09.640]  example, had a candidate list of possible recipients that you think it might be because, you know, maybe
[39:09.640 --> 39:13.340]  you have a hunch or some other external information, are there ways that you could go and basically
[39:13.340 --> 39:18.120]  check those to determine which it would be? And again, the address space in Monero is, like, the
[39:18.120 --> 39:23.300]  possible wallet address space in Monero is, you know, unfathomably huge. And, you know, a quantum
[39:23.300 --> 39:28.680]  computer doesn't just mean, like, can do everything fast automatically. There's particular algorithms
[39:28.680 --> 39:33.300]  that we know that can be used against things like the discrete log problem and stuff. So, you know,
[39:33.300 --> 39:38.620]  even if you had a hypothetical quantum computer, you know, saying, well, couldn't it just go through,
[39:38.620 --> 39:43.560]  you know, all possible addresses and see which it is and figure out, you know, what recipient
[39:44.100 --> 39:48.660]  is linked to what transaction? You know, that's likely not going to be directly possible.
[39:48.720 --> 39:54.540]  But the question of, you know, what could such a computer do if it had, like, a small known list
[39:54.540 --> 39:58.140]  of possible addresses? So questions like that, I think, are still kind of up in the air and
[39:58.140 --> 40:01.980]  are part of the subject of the research that they're working on. And I do know that they're
[40:01.980 --> 40:08.360]  also looking at kind of what current directions my protocol development take that could more
[40:09.420 --> 40:16.700]  efficiently, I guess, work on trying to, like, mitigate the effects of a future quantum computer.
[40:17.440 --> 40:21.900]  I guess one problem with a lot of algorithms and constructions that are conjectured to be
[40:21.900 --> 40:27.980]  post-quantum secure is efficiency. They often tend to be much more inefficient than, I guess,
[40:27.980 --> 40:31.980]  would be reasonable to have on-chain. You know, right now, if, like, post-quantum signatures,
[40:31.980 --> 40:36.640]  for example, can get pretty large. And there have been some ideas for how to do some constructions,
[40:36.640 --> 40:41.360]  like linkable ring signatures, even. But they're very large. And even if you were to integrate
[40:41.360 --> 40:46.480]  them into the protocol, you know, we still deal with today's computers that, you know, still have
[40:46.480 --> 40:52.700]  to store things and do a lot of processing. And if it gets to be too large of a transaction that's
[40:52.700 --> 40:58.600]  too slow, no one's going to use it. So, you know, ideally, we'd like to migrate the protocol
[40:58.600 --> 41:02.840]  immediately to something that's conjectured to be post-quantum secure. But there's a lot
[41:02.840 --> 41:06.280]  of parts of the protocol that it's really uncertain if there's anything at this point
[41:06.280 --> 41:13.160]  that's efficient enough. I mean, research in this area is always ongoing. So, obviously, what's the
[41:13.160 --> 41:16.460]  state-of-the-art today is almost certainly not going to be even close to what the state-of-the-art
[41:16.460 --> 41:20.460]  is, you know, in 10 years, 20 years, you know, further down the line, where maybe we have a
[41:20.460 --> 41:25.600]  better understanding of the likelihood of seeing a practical quantum computer. So I think one thing
[41:25.600 --> 41:29.280]  that they're trying to do, and, you know, I don't, again, I don't want to speak for them, but just my
[41:29.280 --> 41:33.740]  understanding of the work that they're doing is to, you know, look at what are at least some directions
[41:33.740 --> 41:38.920]  in research that might give us an indication about what could be efficient down the road for
[41:38.920 --> 41:45.040]  protocol improvements. I mean, I guess the general thing is, like, to some extent, like, in the
[41:45.040 --> 41:49.480]  age of, you know, post-quantum computers, like, a lot of the internet's kind of screwed in terms of
[41:49.480 --> 41:55.740]  security. So, I mean, like, Monero would be, you know, at least to some degree not immune to this.
[41:55.740 --> 41:59.040]  The extent of which different parts of the, I guess, previous chain's history
[41:59.040 --> 42:03.820]  could be known, I think the exact nature of that is what they're trying to determine now.
[42:05.340 --> 42:10.160]  It's really interesting work. Whether or not you think that it's going to be applicable in,
[42:10.160 --> 42:15.320]  you know, your lifetime or the lifetime of people you care about, I think that's also very much
[42:15.320 --> 42:19.060]  kind of a contentious issue right now. I don't think that there's really universal agreement on,
[42:19.060 --> 42:24.480]  you know, when, if ever, folks might end up seeing a practical quantum computer that would affect
[42:24.480 --> 42:29.120]  projects that they use. And, I mean, I'm not even close to an expert enough in that area to be able
[42:29.120 --> 42:40.220]  to even hypothesize. Yeah, I got it. So, switching gears, what research have you seen outside of what
[42:40.220 --> 42:45.220]  you've specifically done for Monero, I would say, that has been, not necessarily useful,
[42:45.220 --> 42:50.560]  but just really interesting and really surprising? I would say, I think, just, like,
[42:50.560 --> 42:56.680]  the extensive work that's been done on general zero-knowledge-proven systems, I think, is really
[42:56.680 --> 43:05.020]  cool. So, I mean, right now we use very specific zero-knowledge-proven systems in different projects
[43:05.020 --> 43:08.580]  for different purposes. I mean, Bulletproof, for example, is a zero-knowledge-proven system that
[43:08.580 --> 43:13.440]  does, like, one particular thing involving Peterson commitments really well. However,
[43:13.440 --> 43:17.900]  that's just one application. There's kind of a variant form of Bulletproofs that you can use
[43:17.900 --> 43:25.120]  to take different algebraic statements, kind of mess them into this particular circuit format,
[43:25.120 --> 43:32.240]  and then build a proof over the circuit arrangement in order to prove that you know,
[43:32.240 --> 43:36.340]  I guess, 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:44.060]  So, if you have a protocol that you really want to implement, if you can put it into this form
[43:44.060 --> 43:48.700]  and do this kind of representation, then there's all these different tools that you can use right
[43:48.700 --> 43:57.460]  now to prove things about statements relating to this language that you built. So, Bulletproofs
[43:57.460 --> 44:02.980]  can do that. The different proving systems that are used, you know, in stuff like Zcash protocols
[44:03.500 --> 44:08.660]  can do that. There's a lot of stuff involving, like, zkstarts. And, you know, there's a whole
[44:08.660 --> 44:13.660]  host of really interesting research on how to do this and what the different trade-offs are.
[44:13.960 --> 44:19.500]  And, like I said before, like, kind of the, I would say the holy grail for this is trust-free,
[44:19.500 --> 44:24.840]  small, and efficient to generate and verify proofs. And, ideally, also stuff involving things
[44:24.840 --> 44:29.200]  like batching that lets you kind of amortize the cost of verification over multiple proof
[44:29.200 --> 44:33.540]  verifications. Like, just the fact that there's so much fascinating work going on relating to this
[44:33.540 --> 44:38.360]  is really interesting. And, unfortunately, none of it that I've seen, I think, kind of
[44:39.000 --> 44:46.760]  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 --> 44:54.700]  You know, like I said, you know, for users who decide that, you know, they need a protocol
[44:54.700 --> 44:58.080]  that does more than what Monero can offer, like, you probably, at this point, are going to have
[44:58.080 --> 45:06.840]  to sacrifice that whole, you know, where is the trust lie question. But, at the same time,
[45:06.840 --> 45:11.020]  the fact that the research is ongoing and has undergone so much improvement over a pretty
[45:11.020 --> 45:14.860]  short period of time, I think, speaks really highly to where that area of research is going
[45:14.860 --> 45:19.340]  to go in the future. So, I mean, I think it would be great to be able to move to a general,
[45:19.340 --> 45:23.800]  idealized, future zero-knowledge proving system that lets us build really cool protocols that
[45:23.800 --> 45:30.320]  give us everything we want. It's not today. Hopefully, it's not too far off.
[45:31.260 --> 45:34.220]  There has been a lot of work in that area. It's been shocking.
[45:34.220 --> 45:40.780]  Oh, it's insane. Yeah, and to be clear, like, I'm really glad that other projects are
[45:41.700 --> 45:47.540]  doing research in that and, you know, putting that kind of stuff into practice. Like,
[45:47.540 --> 45:50.940]  as with all projects, including Monero, like, I think it's important to talk about limitations
[45:50.940 --> 45:55.820]  and trade-offs. Like, if you've tried to do things like this, you're breaking Monero. But
[45:55.820 --> 45:59.580]  it's still good that, you know, those different kinds of applications are also furthering more
[45:59.580 --> 46:10.480]  research. Sorry, I'm also helping some other later speakers come through. Okay, so you have
[46:10.480 --> 46:15.340]  another five minutes. There aren't any other questions that have come in, sadly. Just the
[46:15.340 --> 46:21.180]  two from Andres. So, thank you, Andres, for answering those questions. We appreciate them.
[46:21.720 --> 46:35.230]  Um, no one else came to the office hours. They're true office hours.
[46:38.310 --> 46:43.290]  No, that's okay. No, I mean, it's good to kind of, I guess, recap, like, how stuff has gone and
[46:44.410 --> 46:47.890]  hypothesize as to where it might go. I mean, research is interesting. You know,
[46:47.890 --> 46:51.710]  you never know what's going to come up, what's going to work, what's not going to work.
[46:53.630 --> 46:59.290]  I think the upgrade in October is going to be exciting, because, you know, Bulletproof was,
[46:59.290 --> 47:03.350]  I think, a cool example of something where transactions got smaller and faster,
[47:03.350 --> 47:11.250]  and there were really no big trade-offs that folks had to consider. And I think CLSAG is another
[47:11.250 --> 47:17.250]  example, where, you know, the transactions get a little smaller, they go faster, and not to the
[47:17.250 --> 47:22.650]  extent that Bulletproof's did. And there's not really any security trade-offs. You know,
[47:22.650 --> 47:26.590]  if anything, working with CLSAG helped to kind of improve the way that we understand
[47:27.290 --> 47:30.790]  linkable ring signature security models. So, if anything, like, I feel like there's
[47:30.790 --> 47:35.810]  more confidence now about the security of the setup that we're going to have.
[47:37.090 --> 47:40.430]  So, if anything, it's not really a trade-off. It's just, you know,
[47:40.430 --> 47:43.070]  kind of an increasing stack of benefits.
[47:44.330 --> 47:49.670]  You're saying that it would be weird a little bit with whatever comes next. Because with RingCT,
[47:49.670 --> 47:56.010]  for example, it was an absolutely necessary change to get to hide the amounts of transactions,
[47:56.010 --> 48:02.570]  and all the other benefits came with them. And I think the issues with denominated Monero were not,
[48:02.570 --> 48:08.250]  they still continue to not be well-documented in, I think, like, a very clear way. We know
[48:08.250 --> 48:14.790]  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:29.770]  You know, I mean, it's well understood that the effects of, you know, a lot of optionality and
[48:29.770 --> 48:35.590]  protocol has always been problematic. You know, a huge number of early transactions,
[48:35.590 --> 48:39.190]  were effectively, I would say, denominized in the sense of,
[48:40.030 --> 48:45.830]  like, Ring-based signer ambiguity. You know, not, again, not based on wallet addresses or anything.
[48:46.630 --> 48:50.250]  But, and I think that that's kind of still influences work that goes on today. Like,
[48:50.250 --> 48:57.190]  there's still parts of the protocol that have some optionality in them. And, you know,
[48:57.190 --> 49:01.870]  it's, you know, you can argue that it's good to have some flexibility in the protocol to allow
[49:01.870 --> 49:06.810]  for alternative use cases that you might not anticipate. But at the same time, like a lot of
[49:06.810 --> 49:11.650]  the work that especially folks like Isthmus and his group have done has shown that the optionality,
[49:11.650 --> 49:15.190]  you know, can lead to fingerprinting if you're not using standard software or using a service
[49:15.190 --> 49:21.410]  that does something in a strange way. And I think there, I think that a lot of folks are coming
[49:21.410 --> 49:28.070]  around to a better appreciation of the fact that limiting the protocol to, you know, improve
[49:28.070 --> 49:34.350]  uniformity and decrease fingerprinting is very much like a one-sided, increasingly lopsided
[49:34.350 --> 49:41.190]  argument toward, you know, limiting the protocol. And there's still, like, there's still things to
[49:41.190 --> 49:45.750]  do in terms of that. And I think the more that we understand about some of the early protocol
[49:45.750 --> 49:51.130]  decisions and how that optionality was bad, I think the more that that can influence better
[49:51.130 --> 49:55.790]  decisions going forward. You know, like the protocol always have like the old chain to deal
[49:55.790 --> 50:00.130]  with. And I think the best to do, the best thing we can do is try to make good decisions going
[50:00.130 --> 50:07.110]  forward to, you know, improve uniformity that can decrease risk and improve safety.
[50:09.510 --> 50:14.270]  Understood. Andreas asked the last question here. Are there any projects working on voting
[50:14.270 --> 50:18.470]  based in Monero? I know, like, that one Italian government wrote up that one thing about how they
[50:18.470 --> 50:24.110]  maybe were... Yeah, that was, that was a political party, right? Yeah, it was. Yeah, I don't know if
[50:24.110 --> 50:30.550]  that ever actually got implemented. I don't think it did either. Voting is, I mean, I'm by no means
[50:30.550 --> 50:36.970]  an expert on voting, but everything that I know, and I mean, folks who do different villages at
[50:36.970 --> 50:44.490]  DEF CON involving voting probably know way more than I do that electronic voting is tricky. And
[50:44.490 --> 50:49.150]  if you think you found out all the ways it could go wrong, it will always surprise you.
[50:50.690 --> 50:55.350]  So, I don't know. I mean, I thought it was cool to see in the original LSAG paper an application
[50:55.350 --> 51:00.270]  to voting just kind of as a, like, a fun academic thought experiment. And who knows? You know,
[51:00.270 --> 51:07.370]  it's presumably something involving, you know, good signer-ambiguous proofs going forward,
[51:07.370 --> 51:13.710]  you know, might be beneficial. Who knows? For voting. But, you know, I don't think that, like,
[51:13.710 --> 51:18.630]  LSAG or CLSAG would be the thing to use. I mean, there's enough efficiency problems that, you know,
[51:18.630 --> 51:22.290]  trying to scale that out to the... because, again, like, the whole idea was that you basically
[51:22.290 --> 51:26.290]  have, like, all the different possible voting entities as, like, part of a ring or the entirety
[51:26.290 --> 51:30.750]  of the ring. Like, I don't... that isn't going to scale reasonably well. And, you know, the trust
[51:30.750 --> 51:35.630]  model is so much different for voting that, you know, you could probably get away with something
[51:35.630 --> 51:42.950]  that ends up trading certain kinds of trust for... yeah, I don't know, maybe it's trading that kind
[51:42.950 --> 51:47.510]  of trust for better efficiency. It's... I haven't thought about this in years enough to be able to
[51:47.510 --> 51:53.050]  speak well to it. So, just keep rambling. Yeah, understood. Okay, well, that's the time that we
[51:53.050 --> 51:57.730]  have. Thank you so much, Sereng Noether. If people want to follow Monero Research Lab, there's always
[51:57.730 --> 52:05.490]  the monero-research-lab channel. Sereng's always there, of course, 24-7 manning this.
[52:06.010 --> 52:11.310]  Yeah, there's definitely the IRC channel. If folks don't want to be on IRC, you know,
[52:11.310 --> 52:15.050]  posting questions in rmonero, there's a lot of folks there who are good at research and
[52:15.050 --> 52:22.470]  development who can answer. On the monero-projects meta repo, on the issues there, you can see
[52:22.470 --> 52:27.070]  when all the meetings are and logs from those meetings are always posted as well after the fact.
[52:27.210 --> 52:31.150]  So, folks want to see, like, what people have been talking about. Yeah, and everyone's welcome into
[52:31.150 --> 52:35.430]  the meetings if they happen to have anything that they think is interesting or useful research
[52:35.430 --> 52:41.390]  the group might like to see. So, yeah, a lot of great contributors, not just me by any means.
[52:41.390 --> 52:46.750]  A lot of really great researchers and folks who are interested in protocol improvements and, you
[52:46.750 --> 52:52.610]  know, improving privacy in the digital asset space. So, thanks to all the other contributors.
[52:53.690 --> 52:55.850]  Well, thank you so much, Sereng Noether, for joining us again.