1
00:00:00,000 --> 00: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.

2
00:00:11,380 --> 00:00:12,320
Strang-Noether.

3
00:00:12,480 --> 00:00:14,640
So to start, I would like to have Dr.

4
00:00:14,640 --> 00:00:16,280
Strang-Noether introduce himself.

5
00:00:16,280 --> 00:00:21,400
Before we get started, I think it would be useful to set expectations for what this session is.

6
00:00:21,580 --> 00:00:23,760
It's very casual on purpose.

7
00:00:24,040 --> 00:00:28,120
We are here such that we can answer your questions, mostly it'd be Mr.

8
00:00:28,120 --> 00: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.

9
00:00:39,880 --> 00:00:42,500
So yeah, we're here to answer anything you have.

10
00:00:42,500 --> 00:00:45,760
So how about, Strang, can you introduce yourself please?

11
00:00:45,800 --> 00:00:47,600
Sure, so I am Dr.

12
00:00:47,600 --> 00:00:48,380
Strang-Noether.

13
00:00:48,380 --> 00:00:55,060
I'm a cryptographer and mathematician who is a research contributor to the Monaro Research Lab.

14
00:00:55,120 --> 00: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.

15
00:01:06,220 --> 00: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.

16
00:01:21,460 --> 00: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.

17
00:01:34,800 --> 00: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.

18
00:01:49,560 --> 00:01:54,600
So I guess I'm using whatever, you know, media you, I guess, have access to.

19
00:01:54,600 --> 00:01:57,420
Justin, you said you're watching the Discord on YouTube, is that right?

20
00:01:57,680 --> 00:02:02,720
Well, yeah, so for any questions that people have, you know, go ahead and shoot them off to us there.

21
00:02:02,720 --> 00:02:04,120
We can talk about them.

22
00:02:04,420 --> 00:02:05,720
Otherwise, I'll sit here.

23
00:02:06,680 --> 00:02:07,260
Perfect.

24
00:02:07,260 --> 00:02:08,360
I brought my coffee.

25
00:02:08,360 --> 00: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.

26
00:02:16,000 --> 00: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?

27
00:02:27,380 --> 00: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.

28
00:02:35,620 --> 00:02:36,300
I don't know.

29
00:02:36,300 --> 00: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.

30
00:02:41,880 --> 00: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.

31
00:02:51,260 --> 00: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.

32
00:03:00,960 --> 00: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.

33
00:03:06,440 --> 00:03:11,540
You know, it's like a sign of, I guess, being motivated and dedicated to what you're learning.

34
00:03:12,600 --> 00: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.

35
00:03:21,600 --> 00:03:22,780
What are you going to do?

36
00:03:23,840 --> 00:03:24,820
Yeah, I guess.

37
00:03:25,280 --> 00:03:28,300
Any questions or any topics of any kind?

38
00:03:28,380 --> 00:03:33,180
At the moment, there are no questions and no topics of any kind, but of course it's open.

39
00:03:33,180 --> 00:03:35,480
I mean, we can also talk a little bit about those, I guess.

40
00:03:35,740 --> 00:03:39,320
Yeah, I was thinking one way we could do is sort of troll the answers out of people.

41
00:03:39,320 --> 00:03:43,000
We can just start saying like, well, what do you think about this obnoxious thing?

42
00:03:43,000 --> 00:03:44,980
Just to get people all riled up about it.

43
00:03:45,100 --> 00: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.

44
00:03:50,880 --> 00: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.

45
00:04:13,480 --> 00:04:14,980
It's called MLSAG.

46
00:04:15,200 --> 00:04:19,680
I will say that in hindsight, I really regret us not giving it a cooler name.

47
00:04:20,760 --> 00:04:22,860
What would have been a cooler name for that?

48
00:04:22,860 --> 00:04:23,780
I have no idea.

49
00:04:23,780 --> 00:04:26,060
If anyone has any ideas, you should tell us.

50
00:04:26,060 --> 00:04:28,760
I mean, we ended up getting a pretty cool CLSAG logo.

51
00:04:28,960 --> 00: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.

52
00:04:37,320 --> 00:04:49,900
But it's not quite as easy to market as something like Halo or Arcturus.

53
00:04:50,260 --> 00:05:01,100
So prior to the confidential transaction model, the linkable ring signature scheme was won by some other authors.

54
00:05:01,100 --> 00:05:05,140
It was called LSAG, Linkable Spontaneous Anonymous Group Signatures.

55
00:05:05,380 --> 00: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.

56
00:05:20,120 --> 00:05:21,640
That was called MLSAG.

57
00:05:21,640 --> 00:05:25,980
It was a multi-layered, linkable, spontaneous anonymous group signatures.

58
00:05:25,980 --> 00: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.

59
00:05:33,680 --> 00: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.

60
00:05:51,720 --> 00: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.

61
00:05:58,140 --> 00: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.

62
00:06:06,100 --> 00:06:08,360
So the scaling on that, you know, is not very good.

63
00:06:08,360 --> 00:06:11,760
It scales as, you know, the anonymity set per transaction goes up.

64
00:06:11,760 --> 00:06:12,720
It scales that way.

65
00:06:12,880 --> 00: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.

66
00:06:19,060 --> 00:06:21,380
One for signing keys and one for commitment keys.

67
00:06:21,580 --> 00:06:29,620
And so the kind of new hotness now is CLSAG, which is concise, linkable, spontaneous, anonymous group signatures.

68
00:06:30,060 --> 00:06:32,900
So it is what it is.

69
00:06:32,900 --> 00: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.

70
00:06:39,220 --> 00:06:40,620
Can't really rename it.

71
00:06:40,640 --> 00:06:42,320
So people already knew about that.

72
00:06:42,320 --> 00:06:44,340
We didn't want to make everything more confusing.

73
00:06:44,340 --> 00: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,

74
00:06:59,320 --> 00:07:03,260
someone can't kind of maliciously go through and run a forgery on the signature.

75
00:07:03,600 --> 00:07:08,600
And basically do the same thing that MLSAG signatures do.

76
00:07:08,600 --> 00:07:13,680
Both show in a signer -ambiguous way that you're signing a message on behalf of one of the unknown keys.

77
00:07:13,680 --> 00:07:16,660
I guess one of the set keys, but you don't know which one it is.

78
00:07:16,660 --> 00:07:20,680
But also basically signing with this other commitment key that you need to prove balance.

79
00:07:20,680 --> 00: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.

80
00:07:27,440 --> 00: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.

81
00:07:34,080 --> 00:07:38,440
So the benefits to this are that it's basically a drop-in replacement, so that's great.

82
00:07:38,860 --> 00:07:41,240
You know, everything involving key images sticks around.

83
00:07:41,240 --> 00:07:44,760
Everything involving the way that these keys are structured gets to stick around.

84
00:07:45,260 --> 00:07:50,000
But the benefits, this benefits that you get for it, are that first the signatures are much smaller.

85
00:07:50,000 --> 00:07:57,500
So effectively the signatures you get for CLSAG are about half the size as for MLSAG.

86
00:07:57,500 --> 00:07:58,740
That's just a signature alone.

87
00:07:58,740 --> 00:08:01,760
Transactions include more than just a signature.

88
00:08:01,980 --> 00: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.

89
00:08:09,980 --> 00: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.

90
00:08:16,880 --> 00:08:21,340
And now you can effectively do them at the same time and you can optimize that away a little bit.

91
00:08:21,340 --> 00:08:25,820
So the benefits there are that you end up with about 20% faster signature verification.

92
00:08:26,380 --> 00: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.

93
00:08:37,780 --> 00: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.

94
00:08:55,160 --> 00:08:56,340
So that's pretty good.

95
00:08:56,340 --> 00:08:58,400
There's really no downsides to this.

96
00:08:58,600 --> 00:09:02,000
Of course we want to make sure that the security model for this is very strong.

97
00:09:02,200 --> 00:09:08,860
So the security model basically just says what properties do we want this construction to have?

98
00:09:09,100 --> 00:09:17,140
And for our particular purposes, we want there to be these properties involving forgeability and non-slanderability and linkability.

99
00:09:17,140 --> 00:09:22,020
And there's kind of this list of them that you want this linkable ring signature construction to have.

100
00:09:22,020 --> 00:09:26,660
So what you do is you basically build this kind of hypothetical model of an imaginary attacker.

101
00:09:26,840 --> 00:09:30,300
And you kind of give this attacker different powers to do things.

102
00:09:30,300 --> 00:09:37,140
So you might give this imaginary attacker like the power to convince honest users to hand over their private keys.

103
00:09:37,140 --> 00: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.

104
00:09:45,360 --> 00: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.

105
00:10:00,640 --> 00:10:05,260
So you basically say, aha, this hypothetical attacker can't exist, and therefore we're okay.

106
00:10:05,680 --> 00: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.

107
00:10:12,580 --> 00: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.

108
00:10:17,740 --> 00:10:18,760
So that's pretty good.

109
00:10:18,760 --> 00: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.

110
00:10:25,640 --> 00:10:27,280
It was considered to be pretty straightforward.

111
00:10:27,860 --> 00:10:32,700
Do you know of anyone else that is actually using MLSAG in a sort of production like Monero is?

112
00:10:33,300 --> 00:10:36,220
Like, is there any other application that's widely used for this?

113
00:10:36,780 --> 00: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.

114
00:10:51,780 --> 00:10:55,300
But I'm not aware of any other direct applications.

115
00:10:55,760 --> 00: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,

116
00:11:11,440 --> 00:11:14,520
but also some ambiguity among the set of possible voters.

117
00:11:14,600 --> 00:11:16,520
I don't think that that's actually been implemented yet.

118
00:11:16,520 --> 00: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.

119
00:11:23,040 --> 00:11:26,940
And so I just got to finish up too.

120
00:11:27,220 --> 00:11:34,400
The Monero community commissioned an external audit of both the paper, but should be very careful to say pre-print.

121
00:11:34,400 --> 00:11:37,280
This pre-print is still technically a pre-print.

122
00:11:37,280 --> 00:11:41,500
So that means it hasn't undergone any other peer review aside from what I'm going to talk about.

123
00:11:41,500 --> 00: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.

124
00:11:51,720 --> 00:11:52,900
So that was done.

125
00:11:52,900 --> 00: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.

126
00:12:06,180 --> 00: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.

127
00:12:13,520 --> 00: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.

128
00:12:21,540 --> 00:12:25,300
And those didn't actually require any other changes to the scheme itself.

129
00:12:25,300 --> 00:12:29,020
So the construction itself, and therefore the code, didn't change as a result of that.

130
00:12:29,020 --> 00:12:32,820
But we're now much more confident in the way that the security model was arranged.

131
00:12:32,820 --> 00:12:36,960
Some of the definitions, the cryptographic hardness assumptions, and things like that.

132
00:12:37,000 --> 00:12:37,740
So that's great.

133
00:12:37,740 --> 00:12:41,980
Those changes have been made and that's now up on the IACR ePrint archive.

134
00:12:42,320 --> 00: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.

135
00:12:50,100 --> 00: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.

136
00:12:59,600 --> 00: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.

137
00:13:08,260 --> 00:13:11,160
So yeah, so the report's available.

138
00:13:11,160 --> 00:13:13,820
There's a blog post up on getmonero.org about it.

139
00:13:13,820 --> 00: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.

140
00:13:19,800 --> 00:13:20,600
Awesome.

141
00:13:20,700 --> 00:13:24,480
Yeah, so that's scheduled to be deployed in the October network upgrade.

142
00:13:24,500 --> 00:13:27,940
So all you need to do is just keep your software updated.

143
00:13:27,940 --> 00: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.

144
00:13:40,060 --> 00:13:44,380
So if you use those, make sure you keep your firmware updated as well and you'll be good to go.

145
00:13:44,380 --> 00:13:45,720
Very cool.

146
00:13:45,720 --> 00:13:47,920
We had a question come in from Andres.

147
00:13:48,000 --> 00: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.

148
00:14:00,900 --> 00:14:05,540
So I guess there's quite a few things that I know are involved in this question.

149
00:14:05,540 --> 00: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.

150
00:14:22,300 --> 00:14:29,020
So I guess given the current situation, what is the approximate timeline forward?

151
00:14:29,020 --> 00: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.

152
00:14:50,900 --> 00:14:56,460
Yeah, so really the question seems to be kind of about per transaction anonymity sets.

153
00:14:56,880 --> 00: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.

154
00:15:14,840 --> 00: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.

155
00:15:23,420 --> 00: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.

156
00:15:30,820 --> 00: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.

157
00:15:39,900 --> 00:15:42,000
That's not the only way to do it though.

158
00:15:42,100 --> 00:15:48,920
So it is possible to build limited anonymity set transaction protocols that use, for example, specialized zero-knowledge proving systems.

159
00:15:49,000 --> 00: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.

160
00:15:59,920 --> 00: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.

161
00:16:08,520 --> 00: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.

162
00:16:28,280 --> 00: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.

163
00:16:36,320 --> 00:16:38,720
So you're really kind of stuck there.

164
00:16:38,740 --> 00:16:45,280
And there's been some proposals for ways to use different kinds of specialized zero-knowledge proving systems.

165
00:16:45,440 --> 00:16:52,440
Some examples of that are OmniRing is one of them, Atlantis is another one, RingCT3, Tryptic, Torus.

166
00:16:52,620 --> 00:16:55,260
There's probably other ones that I'm just not thinking of right now.

167
00:16:55,260 --> 00: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.

168
00:17:09,980 --> 00:17:13,760
So verification time is unfortunately kind of the sticking point for this.

169
00:17:13,760 --> 00: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.

170
00:17:23,480 --> 00:17:25,380
Like we know how to do that already.

171
00:17:25,540 --> 00: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.

172
00:17:35,040 --> 00:17:36,920
But verification time is always a sticking point.

173
00:17:36,920 --> 00:17:44,620
So with those particular kinds of protocols and proofs, you do need still like a almost linear verification time.

174
00:17:44,700 --> 00:17:46,200
That'd be the sticking point.

175
00:17:46,280 --> 00:17:50,080
So that's kind of the limitation that exists.

176
00:17:50,080 --> 00:17:51,460
There are options.

177
00:17:51,460 --> 00: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.

178
00:17:58,500 --> 00:18:03,020
Some of them involve changes to multi-signature operations.

179
00:18:03,480 --> 00: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.

180
00:18:10,580 --> 00: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.

181
00:18:14,880 --> 00: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.

182
00:18:24,020 --> 00:18:29,260
Obviously, we'd like verification to be as low as possible because that means faster operations.

183
00:18:29,580 --> 00:18:34,060
But that has to be balanced against what kinds of analysis and attacks you want to be able to protect against.

184
00:18:34,380 --> 00:18:39,200
So ideally, what we'd love to do is move to something that isn't that full anonymity set.

185
00:18:39,300 --> 00: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.

186
00:18:51,380 --> 00:18:57,340
And what that effectively does is effectively gives you a full anonymity set within that pool, absent external information.

187
00:18:57,660 --> 00:18:58,720
That would be ideal.

188
00:18:58,720 --> 00: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.

189
00:19:09,140 --> 00:19:13,200
Right now, you can't really have everything if you don't want to have centralized trust.

190
00:19:13,200 --> 00:19:16,740
And of course, you know, there's also other issues with that.

191
00:19:16,880 --> 00: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.

192
00:19:26,600 --> 00:19:29,680
Yeah, I think it's probably one of the next speakers, I assume.

193
00:19:30,440 --> 00:19:33,740
But um, yeah, anyway, right now, like, that's kind of the limitation.

194
00:19:34,000 --> 00: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.

195
00:19:44,280 --> 00:19:48,600
And so there's still questions about, you know, how do you end up choosing those anonymity sets?

196
00:19:48,640 --> 00:19:52,920
There are definitely ways you can do it that I think provide improvements over the way we do it now.

197
00:19:52,920 --> 00: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.

198
00:20:01,680 --> 00:20:05,800
And that can mitigate certain kinds of heuristics involving common ownership.

199
00:20:05,820 --> 00: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.

200
00:20:13,880 --> 00:20:15,800
So there's a lot of interesting stuff you can play with.

201
00:20:15,800 --> 00: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.

202
00:20:22,700 --> 00:20:28,060
Yeah, in my experience, you know, we have, we have code that can do this now.

203
00:20:28,240 --> 00: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.

204
00:20:36,460 --> 00: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.

205
00:20:43,740 --> 00: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.

206
00:20:54,340 --> 00: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.

207
00:21:02,860 --> 00:21:09,100
And then it's applied to like, you know, it's typically the way things are currently, right?

208
00:21:09,100 --> 00:21:13,700
So limited anonymity looks like a Monero's case, right?

209
00:21:13,760 --> 00:21:18,240
And that, in many cases, people think that that just can't even really change.

210
00:21:18,240 --> 00:21:24,220
They don't really think about these limited is just, you know, anything less than the full pool.

211
00:21:24,220 --> 00: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.

212
00:21:30,120 --> 00:21:36,780
And then people are like, yeah, it also depends on what exactly your threat model is, right?

213
00:21:36,780 --> 00: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.

214
00:21:49,700 --> 00: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.

215
00:21:58,200 --> 00: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.

216
00:22:05,980 --> 00: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.

217
00:22:13,960 --> 00:22:15,880
It is like an absolute trade-off.

218
00:22:16,040 --> 00:22:21,740
And we all look forward to the day when we can do something that's trust-free.

219
00:22:21,740 --> 00: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.

220
00:22:36,800 --> 00: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.

221
00:22:44,960 --> 00: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,

222
00:22:55,860 --> 00:22:58,280
and those for which it might not be as much of a problem .

223
00:22:58,940 --> 00: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.

224
00:23:10,500 --> 00: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?

225
00:23:21,920 --> 00: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.

226
00:23:32,340 --> 00: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.

227
00:23:43,280 --> 00: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.

228
00:23:49,180 --> 00: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.

229
00:23:59,400 --> 00: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.

230
00:24:18,000 --> 00: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.

231
00:24:23,660 --> 00:24:29,140
You know, a lot of folks want general zero-knowledge proving systems that are trust-free and efficient.

232
00:24:29,860 --> 00:24:33,760
And, you know, that would, I think, be like the ideal, you know, checking of all the boxes.

233
00:24:34,420 --> 00:24:36,720
And it's interesting to see what different projects do, right?

234
00:24:36,720 --> 00: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.

235
00:24:49,860 --> 00: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.

236
00:24:59,320 --> 00: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,

237
00:25:11,280 --> 00:25:13,000
or are you not okay with that?

238
00:25:13,060 --> 00: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.

239
00:25:25,100 --> 00:25:31,000
So, so many questions in this space, and so many trade-offs.

240
00:25:31,960 --> 00:25:37,940
I feel like a lot of cryptography is basically just like the precise study of mathematical trade-offs.

241
00:25:39,160 --> 00: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.

242
00:25:46,920 --> 00: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.

243
00:25:54,960 --> 00:25:57,380
Wouldn't solve everything, but I think you'd get improvement.

244
00:25:58,600 --> 00:26:00,800
So that's on the tip for October, right?

245
00:26:01,040 --> 00:26:01,800
Kidding.

246
00:26:01,820 --> 00:26:03,200
Not for October.

247
00:26:03,880 --> 00:26:06,820
So, I mean, there's other interesting things, you know, on the horizon too.

248
00:26:06,820 --> 00:26:10,080
Ideas for making range proofs a little bit more efficient have come up.

249
00:26:10,080 --> 00:26:14,380
There was a preprint that came out on improvement to bullet proofs called Bullet Proofs Plus.

250
00:26:15,840 --> 00:26:22,200
The plus actually means taking away a few proof elements, but Bullet Proofs Minus doesn't sound as good.

251
00:26:22,660 --> 00:26:24,140
So, I don't know.

252
00:26:24,480 --> 00:26:26,920
There was a proposal to do an implementation of that.

253
00:26:26,920 --> 00:26:27,840
It's really new.

254
00:26:28,280 --> 00: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.

255
00:26:37,420 --> 00:26:41,200
And it would let us, you know, take a few dozen bytes off of transactions.

256
00:26:41,560 --> 00: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.

257
00:26:50,740 --> 00:26:56,400
So really, the question about whether or not it is worth moving to that is worth the effort.

258
00:26:56,420 --> 00:27:00,400
And the possible risk of something that's a bit newer has yet to be determined entirely.

259
00:27:03,220 --> 00:27:09,960
Were there any other questions that came up besides the one that got us into a very long discussion about protocols?

260
00:27:10,160 --> 00:27:11,760
Yeah, there's one.

261
00:27:11,980 --> 00:27:15,540
It's still a protocol-related question, so it is going to be a follow-up, though.

262
00:27:15,540 --> 00:27:23,080
It says, so the ideal solution for Monero would be zk-SNARKs-like thing that doesn't require a trusted setup?

263
00:27:23,400 --> 00:27:27,100
And I believe you basically said yes, but also needs to be efficient.

264
00:27:28,180 --> 00:27:28,940
Yeah, yeah, yeah.

265
00:27:28,940 --> 00: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.

266
00:27:41,360 --> 00: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.

267
00:27:52,500 --> 00:27:54,780
You could do that with bulletproofs, for example.

268
00:27:55,220 --> 00: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.

269
00:28:02,440 --> 00:28:06,340
The scaling is, you know, in terms of verification, is not as good.

270
00:28:06,340 --> 00:28:07,520
Just absolutely not.

271
00:28:07,840 --> 00:28:13,900
But what it lets you do is it lets you prove things about circuits in a trust-free way.

272
00:28:14,000 --> 00:28:15,800
So that is trust-free.

273
00:28:16,420 --> 00: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.

274
00:28:23,440 --> 00:28:24,800
And you get rid of trust.

275
00:28:25,020 --> 00:28:26,340
And the size would still be pretty good.

276
00:28:26,340 --> 00:28:28,880
The estimates and the size, like, it'd be competitive.

277
00:28:29,500 --> 00:28:31,820
Not quite as good, but still pretty competitive.

278
00:28:32,000 --> 00:28:35,320
But the verification would be, no, it wouldn't work.

279
00:28:35,920 --> 00: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.

280
00:28:39,660 --> 00:28:42,260
It's like, yeah, but then you got to do that, like, a million times.

281
00:28:42,660 --> 00: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.

282
00:28:51,000 --> 00: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.

283
00:29:09,080 --> 00: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.

284
00:29:17,180 --> 00: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.

285
00:29:27,520 --> 00: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,

286
00:29:41,140 --> 00:29:42,580
I guess, okay with the security of.

287
00:29:42,580 --> 00:29:44,220
I don't really know a great way to say that.

288
00:29:44,480 --> 00:29:45,560
But that is risky.

289
00:29:45,560 --> 00:29:51,760
You know, I mean, like the Sprout multi-party computation that started Zcash, for example, did have a soundness problem.

290
00:29:51,860 --> 00: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.

291
00:29:58,180 --> 00:30:04,840
So like there's a real non-trivial risk involved, even to something like such a multi-party computation.

292
00:30:04,860 --> 00:30:06,420
So that's not without risk either.

293
00:30:06,740 --> 00:30:11,640
And it makes the trust situation a little bit more tricky.

294
00:30:13,540 --> 00: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.

295
00:30:21,680 --> 00: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.

296
00:30:28,320 --> 00: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.

297
00:30:36,840 --> 00: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.

298
00:30:42,680 --> 00:30:48,080
So it's definitely kind of like this different like threat profile and ideally we want to minimize that.

299
00:30:50,610 --> 00:30:51,570
Got it.

300
00:30:53,370 --> 00: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.

301
00:31:01,390 --> 00:31:03,330
Like, what if you wanted to put the Lightning network on Monero?

302
00:31:03,330 --> 00:31:05,570
What if you wanted to put this, that, or the other on Monero?

303
00:31:05,570 --> 00:31:12,870
What if you wanted to put a, you know, a like zk-snark-mixer on Monero, like as an optional thing?

304
00:31:12,870 --> 00: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?

305
00:31:22,550 --> 00:31:27,270
Yeah, yeah, which is a really cool new thing that's still in progress.

306
00:31:27,270 --> 00: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,

307
00:31:45,810 --> 00: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.

308
00:31:58,820 --> 00:32:04,240
And that gets really tricky because Monero does not have inherent scripting capability.

309
00:32:05,110 --> 00: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.

310
00:32:13,950 --> 00:32:19,650
So given that, the question is, well, okay, so what could you do for something like atomic swaps?

311
00:32:19,750 --> 00: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.

312
00:32:31,950 --> 00: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.

313
00:32:40,850 --> 00:32:42,190
So that was not ideal.

314
00:32:42,490 --> 00: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.

315
00:32:57,310 --> 00: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.

316
00:33:09,610 --> 00:33:11,250
It's pretty darn interesting.

317
00:33:11,630 --> 00: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,

318
00:33:24,690 --> 00:33:25,310
if anything?

319
00:33:25,310 --> 00:33:27,510
What's the worst case scenario that could occur?

320
00:33:27,730 --> 00: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?

321
00:33:39,390 --> 00: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.

322
00:33:50,290 --> 00:33:52,750
So, you know, that kind of is a central storage kind of risk.

323
00:33:52,850 --> 00: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.

324
00:34:02,010 --> 00:34:04,610
And if that's a risk for you, then you don't really want that.

325
00:34:04,690 --> 00: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,

326
00:34:16,930 --> 00:34:18,910
like what kind of analysis could still happen?

327
00:34:20,670 --> 00:34:23,630
It's not nothing, because metadata always exists.

328
00:34:23,630 --> 00: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.

329
00:34:33,530 --> 00:34:37,290
There were some other ideas for stuff like payment channel networks, even within Monero.

330
00:34:37,750 --> 00:34:43,610
My DLSag was another signature construction that some other researchers came up with.

331
00:34:43,610 --> 00:34:49,930
And we looked at it, and unfortunately had like this tracing problem that would have required this whole self-spend thing.

332
00:34:49,930 --> 00:34:54,930
And it was, it kind of got messy, and there wasn't really a great solution for it, unfortunately.

333
00:34:55,270 --> 00: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.

334
00:35:06,110 --> 00:35:07,490
Got it, got it.

335
00:35:07,490 --> 00:35:09,590
I know this isn't the DLSag names.

336
00:35:09,590 --> 00:35:11,650
Yeah, let's go through every letter.

337
00:35:11,650 --> 00:35:15,610
Something involving a DLSag construction, just for even more confusion.

338
00:35:18,320 --> 00: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.

339
00:35:32,660 --> 00:35:40,360
He was going to look at the initial scope of what basically challenges Monero needed to address going forward.

340
00:35:40,360 --> 00: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?

341
00:35:48,000 --> 00:35:50,960
Yeah, so this is work that's ongoing.

342
00:35:51,400 --> 00:35:54,400
I believe we're going to work on it for three months.

343
00:35:54,400 --> 00:35:56,560
We're about done with the first month, I think, of that.

344
00:35:56,840 --> 00: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.

345
00:36:00,460 --> 00: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.

346
00:36:11,440 --> 00:36:13,240
If so, how far into the future?

347
00:36:13,880 --> 00: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?

348
00:36:23,780 --> 00: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.

349
00:36:34,980 --> 00:36:40,600
To what extent would different parts of the chain be considered at risk?

350
00:36:41,300 --> 00: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.

351
00:36:49,080 --> 00: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.

352
00:37:04,960 --> 00:37:12,140
It's pretty well understood that given a sufficiently advanced quantum computer, that map would be reversible efficiently.

353
00:37:12,400 --> 00:37:17,360
So at that point, spend anyone's funds, which I know that's a problem right now.

354
00:37:17,500 --> 00:37:21,640
But to some extent, it's not necessarily just a problem for Monero.

355
00:37:21,960 --> 00:37:24,400
This is kind of a broadly applicable problem.

356
00:37:24,400 --> 00:37:28,300
The entire internet runs on these one-way maps right now, to a large extent.

357
00:37:28,460 --> 00: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.

358
00:37:33,100 --> 00: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.

359
00:37:38,620 --> 00:37:43,960
But even beyond that, looking at things like, what would that allow you to do to ring signatures?

360
00:37:44,000 --> 00: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.

361
00:37:58,600 --> 00: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.

362
00:38:05,300 --> 00: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.

363
00:38:12,640 --> 00:38:19,480
There's some other questions right now involving things like, what could you determine about stealth or one-time addressing operations?

364
00:38:19,980 --> 00:38:23,460
And that's still, I think, a little bit ambiguous right now.

365
00:38:23,540 --> 00: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.

366
00:38:32,100 --> 00:38:39,760
Maybe I can't just use that transaction to, for example, figure out what the wallet address of the recipient was.

367
00:38:39,760 --> 00:38:43,600
Because remember, in Monero, wallet addresses never appear directly on-chain.

368
00:38:43,600 --> 00:38:45,980
They're used to derive these one-time addresses.

369
00:38:46,440 --> 00: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.

370
00:38:54,580 --> 00: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?

371
00:39:03,040 --> 00: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?

372
00:39:15,860 --> 00:39:22,180
And again, the address space in Monero is, like, the possible wallet address space in Monero is, you know, unfathomably huge.

373
00:39:22,180 --> 00:39:26,780
And, you know, a quantum computer doesn't just mean, like, can do everything fast automatically.

374
00:39:27,120 --> 00:39:31,940
There's particular algorithms that we know that can be used against things like the discrete log problem and stuff.

375
00:39:32,220 --> 00: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?

376
00:39:46,120 --> 00:39:48,660
You know, that's likely not going to be directly possible.

377
00:39:48,720 --> 00: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?

378
00:39:55,940 --> 00: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.

379
00:40:01,100 --> 00: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.

380
00:40:17,440 --> 00:40:24,120
I guess one problem with a lot of algorithms and constructions that are conjectured to be post-quantum secure is efficiency.

381
00:40:24,120 --> 00:40:29,800
They often tend to be much more inefficient than, I guess, would be reasonable to have on-chain.

382
00:40:29,900 --> 00:40:33,560
You know, right now, if, like, post-quantum signatures, for example, can get pretty large.

383
00:40:33,560 --> 00:40:38,540
And there have been some ideas for how to do some constructions, like linkable ring signatures, even.

384
00:40:38,660 --> 00:40:39,860
But they're very large.

385
00:40:39,860 --> 00: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.

386
00:40:49,540 --> 00: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.

387
00:40:55,120 --> 00: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.

388
00:41:02,100 --> 00: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.

389
00:41:07,920 --> 00:41:11,360
I mean, research in this area is always ongoing.

390
00:41:11,620 --> 00: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.

391
00:41:24,820 --> 00: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.

392
00:41:40,840 --> 00: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.

393
00:41:50,440 --> 00:41:55,740
So, I mean, like, Monero would be, you know, at least to some degree not immune to this.

394
00:41:55,740 --> 00: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.

395
00:42:05,340 --> 00:42:07,220
It's really interesting work.

396
00:42:07,700 --> 00: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.

397
00:42:17,180 --> 00: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.

398
00:42:26,640 --> 00:42:31,020
And, I mean, I'm not even close to an expert enough in that area to be able to even hypothesize.

399
00:42:32,660 --> 00:42:33,860
Yeah, I got it.

400
00:42:34,120 --> 00: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?

401
00:42:48,820 --> 00: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.

402
00:42:58,780 --> 00:43:06,040
So, I mean, right now we use very specific zero-knowledge-proven systems in different projects for different purposes.

403
00:43:06,040 --> 00: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.

404
00:43:12,820 --> 00:43:15,220
However, that's just one application.

405
00:43:15,220 --> 00: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,

406
00:43:32,640 --> 00:43:36,340
like, a witness that ends up satisfying the circuit without revealing what that witness is.

407
00:43:36,480 --> 00:43:40,540
And, like, that's kind of the general form of, like, a general zero-knowledge-proven system.

408
00:43:40,540 --> 00: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.

409
00:43:56,480 --> 00:43:58,520
So, Bulletproofs can do that.

410
00:43:58,740 --> 00:44:04,500
The different proving systems that are used, you know, in stuff like Zcash protocols can do that.

411
00:44:04,500 --> 00:44:06,840
There's a lot of stuff involving, like, zkstarts.

412
00:44:07,160 --> 00: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.

413
00:44:13,960 --> 00: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.

414
00:44:23,340 --> 00: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.

415
00:44:30,340 --> 00:44:34,900
Like, just the fact that there's so much fascinating work going on relating to this is really interesting.

416
00:44:35,280 --> 00: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.

417
00:44:47,760 --> 00:44:50,780
You know, right now, the whole trust thing seems to be a pretty big sticking point.

418
00:44:50,920 --> 00: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.

419
00:45:04,420 --> 00: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.

420
00:45:16,560 --> 00: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.

421
00:45:27,960 --> 00:45:28,940
It's not today.

422
00:45:28,940 --> 00:45:30,320
Hopefully, it's not too far off.

423
00:45:31,260 --> 00:45:33,720
There has been a lot of work in that area.

424
00:45:33,720 --> 00:45:34,220
It's been shocking.

425
00:45:34,220 --> 00:45:35,140
Oh , it's insane.

426
00:45:37,440 --> 00: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.

427
00:45:47,120 --> 00:45:51,720
Like, as with all projects, including Monero, like, I think it's important to talk about limitations and trade-offs.

428
00:45:51,720 --> 00:45:55,000
Like, if you've tried to do things like this, you're breaking Monero.

429
00:45:55,380 --> 00:46:00,460
But it's still good that, you know, those different kinds of applications are also furthering more research.

430
00:46:05,860 --> 00:46:09,920
Sorry, I'm also helping some other later speakers come through.

431
00:46:09,920 --> 00:46:11,220
Okay, so you have another five minutes.

432
00:46:11,220 --> 00:46:14,800
There aren't any other questions that have come in, sadly.

433
00:46:14,800 --> 00:46:16,400
Just the two from Andres.

434
00:46:17,780 --> 00:46:20,000
So, thank you, Andres, for answering those questions.

435
00:46:20,000 --> 00:46:21,180
We appreciate them.

436
00:46:21,720 --> 00:46:22,440
Um,

437
00:46:29,570 --> 00:46:32,870
no one else came to the office hours.

438
00:46:33,330 --> 00:46:35,230
They're true office hours.

439
00:46:38,310 --> 00:46:39,570
No, that's okay.

440
00:46:39,570 --> 00: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.

441
00:46:46,610 --> 00:46:47,690
I mean, research is interesting.

442
00:46:47,690 --> 00: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.

443
00:46:53,630 --> 00: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.

444
00:47:08,870 --> 00: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.

445
00:47:19,410 --> 00:47:22,570
And there's not really any security trade-offs.

446
00:47:22,570 --> 00: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.

447
00:47:29,350 --> 00: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.

448
00:47:37,090 --> 00:47:38,810
So, if anything, it's not really a trade-off.

449
00:47:38,810 --> 00:47:43,070
It's just, you know, kind of an increasing stack of benefits.

450
00:47:44,330 --> 00:47:48,670
You're saying that it would be weird a little bit with whatever comes next.

451
00:47:48,670 --> 00: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.

452
00:47:57,970 --> 00: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.

453
00:48:07,770 --> 00: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.

454
00:48:14,790 --> 00:48:22,010
Oh, I mean, the early Monero chain is, you know, a fantastic source of material for analysis.

455
00:48:22,010 --> 00: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.

456
00:48:32,950 --> 00: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.

457
00:48:42,430 --> 00:48:45,830
You know, not, again, not based on wallet addresses or anything.

458
00:48:46,630 --> 00:48:50,170
But, and I think that that's kind of still influences work that goes on today.

459
00:48:50,170 --> 00:48:53,950
Like, there's still parts of the protocol that have some optionality in them.

460
00:48:54,430 --> 00: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.

461
00:49:05,390 --> 00: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.

462
00:49:18,230 --> 00: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,

463
00:49:35,450 --> 00:49:37,470
you know, limiting the protocol.

464
00:49:37,990 --> 00:49:42,890
And there's still, like, there's still things to do in terms of that.

465
00:49:42,890 --> 00: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.

466
00:49:53,050 --> 00:49:56,370
You know, like the protocol always have like the old chain to deal with.

467
00:49:56,570 --> 00: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.

468
00:50:09,510 --> 00:50:10,310
Understood.

469
00:50:10,710 --> 00:50:12,270
Andreas asked the last question here.

470
00:50:12,270 --> 00:50:15,230
Are there any projects working on voting based in Monero?

471
00:50:15,230 --> 00: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?

472
00:50:21,530 --> 00:50:22,730
Yeah, it was.

473
00:50:22,810 --> 00:50:25,630
Yeah, I don't know if that ever actually got implemented.

474
00:50:25,630 --> 00:50:27,090
I don't think it did either.

475
00:50:27,750 --> 00: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.

476
00:50:44,050 --> 00:50:49,150
And if you think you found out all the ways it could go wrong, it will always surprise you.

477
00:50:50,690 --> 00:50:51,710
So, I don't know.

478
00:50:51,710 --> 00: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.

479
00:50:59,070 --> 00:50:59,990
And who knows?

480
00:50:59,990 --> 00:51:08,770
You know, it's presumably something involving, you know, good signer-ambiguous proofs going forward, you know, might be beneficial.

481
00:51:08,850 --> 00:51:09,910
Who knows?

482
00:51:10,770 --> 00:51:11,790
For voting.

483
00:51:11,790 --> 00:51:16,730
But, you know, I don't think that, like, LSAG or CLSAG would be the thing to use.

484
00:51:16,730 --> 00: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.

485
00:51:27,030 --> 00:51:29,590
Like, I don't... that isn't going to scale reasonably well.

486
00:51:29,930 --> 00: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.

487
00:51:45,510 --> 00:51:48,610
It's... I haven't thought about this in years enough to be able to speak well to it.

488
00:51:48,610 --> 00:51:50,550
So, just keep rambling.

489
00:51:50,870 --> 00:51:51,650
Yeah, understood.

490
00:51:51,650 --> 00:51:53,250
Okay, well, that's the time that we have.

491
00:51:53,250 --> 00:51:54,570
Thank you so much, Sereng Noether.

492
00:51:54,570 --> 00:52:00,970
If people want to follow Monero Research Lab, there's always the monero-research-lab channel.

493
00:52:01,510 --> 00:52:05,490
Sereng's always there, of course, 24-7 manning this.

494
00:52:06,010 --> 00:52:08,070
Yeah, there's definitely the IRC channel.

495
00:52:08,070 --> 00: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.

496
00:52:16,650 --> 00: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.

497
00:52:27,210 --> 00:52:29,870
So, folks want to see, like, what people have been talking about.

498
00:52:30,230 --> 00: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.

499
00:52:37,990 --> 00:52:41,390
So, yeah, a lot of great contributors, not just me by any means.

500
00:52:41,390 --> 00: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.

501
00:52:50,370 --> 00:52:52,610
So, thanks to all the other contributors.

502
00:52:53,690 --> 00:52:55,850
Well, thank you so much, Sereng Noether, for joining us again.