start	end	text
0	7920	Okay, hello everyone and welcome to the Monaro Research Lab office hour with me,
7920	12320	your host Justin, and the person you actually want to see, Dr. Strang-Noether.
12480	16740	So to start, I would like to have Dr. Strang-Noether introduce himself. Before we get
16740	21400	started, I think it would be useful to set expectations for what this session is.
21580	27300	It's very casual on purpose. We are here such that we can answer your questions,
27300	29620	mostly it'd be Mr. Strang-Noether answering your questions,
30480	34280	and yeah, so I will be paying attention to YouTube, I'll be paying attention to Discord
34280	39220	just to relay questions over, but otherwise this is really your time to make of it what you would
39220	44640	like. So yeah, we're here to answer anything you have. So how about, Strang, can you introduce
44640	52280	yourself please? Sure, so I am Dr. Strang-Noether. I'm a cryptographer and mathematician who is a
52280	56840	research contributor to the Monaro Research Lab. The Monaro Research Lab is a research and
56840	60440	development work group, it's not the only one, but it's a research and development work group
61880	66960	that conducts, you know, research and development for the Monaro project. So that ends up being
66960	73500	stuff involving protocol research, some of the math, prototyping, coding, all sorts of things,
73500	79620	to kind of push the Monaro protocol and privacy preserving digital assets forward in general from
79720	84980	a technical perspective. And like Justin said, the purpose of this office hour is to give an
84980	91420	opportunity to just kind of very informally give a video forum, in this case, in order to, you know,
91420	96120	answer any questions that come up, topics that people want to know more about. So this could be
96120	102720	Justin and I sitting here in the quiet for an hour, like often happens in kind of standard university
102720	107640	in-person office hours, you know, or it can be, you know, really whatever sort of technical aspects
107640	113980	that folks want to talk about. So I guess I'm using whatever, you know, media you, I guess,
113980	118600	have access to. Justin, you said you're watching the Discord on YouTube, is that right? Well, yeah, so
118600	123120	for any questions that people have, you know, go ahead and shoot them off to us there. We can talk
123120	129320	about them. Otherwise, I'll sit here. Perfect. I brought my coffee. You know, I haven't had a lot
129320	134720	of coffee with my actual coffee chats recently, but I feel like I've doubled down on the coffee
134720	140120	the last few days. Were you the type of person in high school, well, maybe high school depending,
140120	144120	but in college that went to office hours, were you the type of person that would usually go or
144660	149100	is this something you did not go to that often? I had to go to office hours, you know, when I
149100	156840	had questions and later as a TA and even later as an instructor. I don't know. And then I had
156960	160880	a new appreciation for the nature of office hours when I was the one, you know, running the office
160880	166160	hours. But I did discover that oftentimes it was like this really cool combination of, you know,
166160	169820	folks who came because they really wanted to understand something that they didn't,
169820	173200	you know, prior to that. But there were also a lot of students who really did know what they
173200	176820	were doing and they were just really interested in making sure that they, you know, kind of had
176820	182200	as much face-to-face time to kind of go over new problems as they could. So one thing I like is
182200	186560	it was like, oh, this is not some kind of sign of weakness to go to office hours. You know,
186560	191540	it's like a sign of, I guess, being motivated and dedicated to what you're learning.
192600	195920	But there were still many times when I had no one show up to office hours
196460	199840	and then it was just reading books for an hour.
201600	208300	What are you going to do? Yeah, I guess. Any questions or any topics of any kind?
208380	213180	At the moment, there are no questions and no topics of any kind, but of course it's open.
213180	215480	I mean, we can also talk a little bit about those, I guess.
215740	219740	Yeah, I was thinking one way we could do is sort of troll the answers out of people. We can just
219740	223740	start saying like, well, what do you think about this obnoxious thing? Just to get people all
223740	228200	riled up about it. But before we do that, how about you tell us, talk about what you've been
228200	232480	doing with the Minerva Research Lab the last month or so. So I would say probably like the
232480	236200	most interesting thing that people might care about, or hopefully at least they'll care about
236200	247620	the effects of it, is going to be CLSAG, which is a linkable ring signature construction that was
247620	252300	intended to be a drop-in replacement to the linkable ring construction that the Minerva
252300	257340	protocol used to use. It's called MLSAG. I will say that in hindsight, I really regret
257340	262860	us not giving it a cooler name. What would have been a cooler name for that?
262860	266060	I have no idea. If anyone has any ideas, you should tell us.
266060	271660	I mean, we ended up getting a pretty cool CLSAG logo. Basically, the community came together and
271660	275380	we had a few ideas that were pitched, one of which we ultimately went with in the blog post,
275380	286060	and they're credited at the bottom. But it's not quite as easy to market as something like Halo
286060	289900	or Arcturus.
290260	298500	So prior to the confidential transaction model, the linkable ring signature scheme
298500	305140	was won by some other authors. It was called LSAG, Linkable Spontaneous Anonymous Group Signatures.
305380	310020	From that point on, moving into the confidential transaction model,
310020	315300	where we replaced unclear amounts, commitments to amounts, and then we moved to one that was
315300	321640	developed by Shen Norther and others, more of an in-house kind of thing. That was called MLSAG.
321640	326840	It was a multi-layered, linkable, spontaneous anonymous group signatures. The idea there is
326840	331720	that you had both information in the signature that dealt with both signing keys, but also
331720	337720	certain commitment keys. And by kind of cleverly setting up and arranging how you do that signature,
337720	344980	you could both show this kind of signer-ambiguous signature model you're looking for, but also throw
344980	351460	in a proof of balance, which is very important, but also completely in a signer-ambiguous way.
351720	355540	The downside to the MLSAG signatures, of course, is you basically kind of have two sets of data
355540	360340	floating around in the signature itself. You have some sets of data that deals with the signing
360340	366400	keys, and a kind of a separate set of parallel data that deals with the commitment keys. So the
366400	370760	scaling on that, you know, is not very good. It scales as, you know, the anonymity set per
370760	375860	transaction goes up. It scales that way. But at the same time, every time you're adding on, you know,
375860	379880	new ring members, you're actually adding on two pieces of data, effectively. One for signing keys
379880	387500	and one for commitment keys. And so the kind of new hotness now is CLSAG, which is concise, linkable,
387500	394520	spontaneous, anonymous group signatures. So it is what it is. There was a name that was chosen and
394520	400620	thought about changing it, but then we're like, ah, you know, we've already named it. Can't really rename it.
400640	405640	So people already knew about that. We didn't want to make everything more confusing. But the idea
405640	411440	there is to kind of take this information involving this data for signing keys and this data for
411440	417480	commitment keys, and it turns out you can combine them together in this weighted fashion that, you
417480	422340	know, hash functions to ensure that, you know, someone can't kind of maliciously go through and run a
422340	429720	forgery on the signature. And basically do the same thing that MLSAG signatures do. Both show in a
429720	434460	signer-ambiguous way that you're signing a message on behalf of one of the unknown keys. I guess one
434460	439460	of the set keys, but you don't know which one it is. But also basically signing with this other
439460	443100	commitment key that you need to prove balance. So it's more or less a drop-in replacement, but now
443100	449120	effectively you only have to have one set of data involved. So one piece of information per ring
449120	453240	member and then some additional auxiliary information that's used just to make the algebra
453240	458440	work. So the benefits to this are that it's basically a drop-in replacement, so that's great.
458860	462380	You know, everything involving key images sticks around. Everything involving the way that these
462380	467440	keys are structured gets to stick around. But the benefits, this benefits that you get for it,
467440	474140	are that first the signatures are much smaller. So effectively the signatures you get for CLSAG
474140	479900	are about half the size as for MLSAG. That's just a signature alone. Transactions include more than
479900	486360	just a signature. So they're smaller in that sense, but they're also faster to verify,
486360	489980	because it turns out you can do some optimization with the way that these operations take place.
489980	495260	Because before you had to do some cryptographic operations on like the linkable side of the data
495260	499220	and on the commitment side of the data. And now you can effectively do them at the same time and
499220	503820	you can optimize that away a little bit. So the benefits there are that you end up with about 20%
503820	510100	faster signature verification. So transactions that spend multiple inputs, which most transactions
510100	514800	spend between one and two inputs and generate some other outputs, but for every one of those spent
514800	520060	inputs you need a separate signature. And so it turns out that for the most common forms of
520060	525020	transactions, like a two input two output transaction for example, you end up seeing
525020	532480	overall about a 25% decrease in the transaction size and overall probably about a 10% speed up
532480	537420	in the overall transaction verification. So that's pretty good. There's really no downsides
537420	542000	to this. Of course we want to make sure that the security model for this is very strong.
542200	547840	So the security model basically just says what properties do we want this
547840	552580	construction to have? And for our particular purposes, we want there to be these properties
552580	558300	involving forgeability and non-slanderability and linkability. And there's kind of this list
558300	562940	of them that you want this linkable ring signature construction to have. So what you do is you
562940	568280	basically build this kind of hypothetical model of an imaginary attacker. And you kind of give
568280	572760	this attacker different powers to do things. So you might give this imaginary attacker like
572760	578060	the power to convince honest users to hand over their private keys. Or you might give this
578060	583520	imaginary attacker the power to persuade honest users to build arbitrary transactions
583520	588860	on the attacker's behalf. And then you show that even if the attacker had these powers, it still
588860	594280	can't go and like generally break these properties that we wanted to have without also breaking
594280	599400	some computational problem like the discrete logarithm problem that we assume is computationally
599400	604320	feasible to do. So you basically say, aha, this hypothetical attacker can't exist, and therefore
604320	609620	we're okay. And so we decided to kind of beef up the security model that was used for CLSAG
609620	615700	compared to like LSAG and MLSAG. And in doing so, ended up with, I would say, like a pretty
615700	619980	good model for how we want it to work. So that's pretty good. We're pretty sure that the same
619980	623980	security model would equally apply to MLSAG, but you know, we didn't go back and kind of
623980	628720	retroactively do that. It was considered to be pretty straightforward. Do you know of anyone
628720	633980	else that is actually using MLSAG in a sort of production like Monero is? Like, is there any
633980	639240	other application that's widely used for this? Oh, I mean, besides like projects that, you know,
639240	646720	use it for the same purpose, you know, like CodeWorks or, you know,
646720	650820	you know, different digital assets that have at least like the same or a similar protocol,
650820	657200	presumably use it. But I'm not aware of any other direct applications. So originally LSAG, one of
657200	663420	the, in the original paper that originally introduced LSAG, you know, one option that was
663420	668700	listed was like voting schemes, for example, you know, where you want to be able to ensure that
668700	673660	someone can't vote twice for a particular issue, but also some ambiguity among the set of possible
673660	677320	voters. I don't think that that's actually been implemented yet. I mean, secure voting is really
677320	683040	hard for a lot of reasons, but it happens to be really good for the purposes that we use it for.
683040	690860	And so I just got to finish up too. The Monero community commissioned an external audit of both
690860	696500	the paper, but should be very careful to say pre-print. This pre-print is still technically
696700	700440	a pre-print. So that means it hasn't undergone any other peer review aside from what I'm going
700440	706240	to talk about. But we decided to have the pre-print externally audited, as well as
706240	712900	the implementation for the upcoming October network upgrade audited. So that was done.
712900	718120	There were two auditors who were commissioned to do that, and that was in kind of in consultation
718120	722720	with the Open Source Technology Improvement Fund, which is a non-profit that does support for these
722720	727760	kind of things and supported by Monero community donations. And the auditors had a lot of really
727760	734600	good suggestions for how to improve the overall CLSAG security model and pre-print. So ended up
734600	739980	changing a few of the proofs around and generally just improving how the security model and proofs
739980	744060	were structured and run. And those didn't actually require any other changes to the
744060	748500	scheme itself. So the construction itself, and therefore the code, didn't change as a result of
748500	752940	that. But we're now much more confident in the way that the security model was arranged. Some
752940	757400	of the definitions, the cryptographic hardness assumptions, and things like that. So that's
757400	762740	great. Those changes have been made and that's now up on the IACR ePrint archive. And then the
762740	768800	implementation surprisingly didn't require any real changes for security, which I feel like usually
768800	773760	you get some in there. There were a few kind of informational ideas for how to simplify the code,
773760	777700	but we considered that changing those, they would have been fairly extensive in how we
777700	781960	handle certain key structures and such. And it was thought that it was probably more likely to
781960	787220	introduce risk if we made kind of these big sweeping, more informational changes than if we
787220	793280	were to just leave it. So yeah, so the report's available. There's a blog post up on getmonero.org
793280	797200	about it. You can read the full report, take a look at the pre-print, look at the code if that's
797200	804660	your thing. Awesome. Yeah, so that's scheduled to be deployed in the October network upgrade. So
804660	810260	all you need to do is just keep your software updated. If you use a hardware wallet like a
810260	816340	Trezor or Ledger, that's in process as well, getting their firmware and apps updated as well
816340	820500	to make sure that that's good to go kind of day-in-day-out when we're ready to go to it.
820500	824380	So if you use those, make sure you keep your firmware updated as well and you'll be good to go.
824380	831680	Very cool. We had a question come in from Andres. He asked if there's any plans to, in the future,
831680	836840	move past ring signatures to something that is not just hidden between other decoys,
836840	841200	but has additional protections beyond just a decoy level protection. So I guess
841200	846980	there's quite a few things that I know are involved in this question. One is we have
846980	852420	the current decoy selection, which per transaction has a relatively small number of decoys per
852420	858220	selection, which provides reasonable mass surveillance protection, but less so good
858220	863420	targeted surveillance if someone knows information about particular transactions. So I guess given
863420	871320	the current situation, what is the approximate timeline forward? Not necessarily the timeline, but
871320	880260	the set of potential improvements forward for whether or not ring signatures are sort of the
880260	886520	right approach for the future, and how you've approached dealing with the core problem of the
886520	893380	relatively small per transaction decoy levels. Yeah, so really the question seems to be kind
893380	900120	of about per transaction anonymity sets. I increasingly dislike the idea of using the
900120	905860	term ring signature to purely mean a limited anonymity set, just because while it has been
905860	911120	the case so far that our ring signature construction does have a limited anonymity set,
911120	916020	I don't think it's necessarily the correct term to use. So it's possible to build
916020	921840	transaction protocols with limited anonymity sets or full anonymity sets, and you could probably do
921840	925540	all sorts of other things. I mean, we know that there's transaction protocols that have no anonymity
925540	932180	sets, but those are typically not the ones we're interested in. So what we do right now is we do
932180	936900	in fact use a linkable ring signature as kind of a building block in a limited anonymity set
936900	942360	transaction protocol for the Monero protocol. That's not the only way to do it though. So it
942360	946620	is possible to build limited anonymity set transaction protocols that use, for example,
946620	951120	specialized zero-knowledge proving systems. So I really don't like the whole idea of zero-knowledge
951120	955720	meaning full anonymity and ring signature meaning not, because that tends to be
956640	960640	certain implementations now, but it is not generally true. I mean, those things have
960640	966080	much more technical meanings involving proof and signature constructions, but
966780	974100	using them the way that we do today. So it's possible to kind of migrate over to a still
974100	980180	limited anonymity set construction, but one that permits much larger anonymity sets for
980180	986100	reasonable transaction sizes and times, but in a way that ideally would help against certain
986100	991500	other forms of analysis or attack. Because again, right now, the way that the transaction
991500	996320	protocol signatures scale is that they scale linearly with the size of the anonymity set.
996320	1001320	So you're really kind of stuck there. And there's been some proposals for ways to use
1001320	1006600	different kinds of specialized zero-knowledge proving systems. Some examples of that are
1006600	1013440	OmniRing is one of them, Atlantis is another one, RingCT3, Tryptic, Torus. There's probably other
1013440	1021740	ones that I'm just not thinking of right now. But all of these essentially allow a transaction proof
1021740	1027260	along with possibly some other auxiliary proofs that scales much better in terms of size and
1027260	1032760	scales a little bit better in terms of time. So verification time is unfortunately kind of
1032760	1037300	the sticking point for this. So if you want a trust-free, like a non-centralized, you know,
1037300	1043060	trusted setup style proving system and transaction protocol, you can make those proofs very small.
1043480	1048720	Like we know how to do that already. They're not as small, for example, as like the proofs,
1048720	1052800	not the transactions, the proofs in say Zcash, but they're still quite small for the size of the
1052800	1057480	limited anonymity set you can get. But verification time is always a sticking point. So with those
1057480	1064620	particular kinds of protocols and proofs, you do need still like a almost linear verification time.
1064700	1071460	That'd be the sticking point. So that's kind of the limitation that exists. There are options.
1071460	1076380	They've all got some trade-offs in terms of, you know, what you can do with things like tracing
1076380	1081320	and how the construction works. Some of them involve changes to multi-signature
1082300	1086320	operations. There's changes to the way that linking tags work, which is kind of require
1086320	1091760	almost sort of like a pool migration that can still be done safely. And so which one of these,
1091760	1095500	if any, should be the one going forward is kind of up in the air right now. A lot of it depends
1095500	1099480	on what trade-offs people are willing to accept and also what trade-offs people are willing to
1099480	1105060	accept in terms of mainly like transaction verification times. Obviously, we'd like
1105060	1110060	verification to be as low as possible because that means faster operations. But that has to
1110060	1114060	be balanced against what kinds of analysis and attacks you want to be able to protect against.
1114380	1119200	So ideally, what we'd love to do is move to something that isn't that full anonymity set.
1119300	1123820	Kind of the classic example of that right now is something like the Zcash protocols,
1123820	1128740	where different anonymity sets that are involved there are basically enforced using proofs that
1128740	1133840	do things involving Merkle tree proofs. And what that effectively does is effectively gives you
1134160	1138720	a full anonymity set within that pool, absent external information. That would be ideal.
1138720	1142100	But right now, all the proposals that are kind of on the table for doing that
1143060	1148960	suffer a lot in terms of either centralized trust or in terms of, say, proof size or time.
1149140	1153200	Right now, you can't really have everything if you don't want to have centralized trust.
1153200	1156740	And of course, you know, there's also other issues with that.
1156880	1164620	You know, for example, in many of the protocols, in many of the pro... hang on here,
1164620	1168180	there's someone else drawing the room here. Yeah, I think it's probably one of the next
1168180	1173740	speakers, I assume. But um, yeah, anyway, right now, like, that's kind of the limitation.
1174000	1179360	So under the assumption that, you know, the project and its community are unlikely to move
1179360	1182540	to something that would require centralized trust, you know, right now, there has to be
1182620	1186460	a limitation of limited sets. And so there's still questions about, you know, how do you end
1186460	1190800	up choosing those anonymity sets? There are definitely ways you can do it that I think
1190800	1195260	provide improvements over the way we do it now. As you get bigger anonymity sets, you can do
1195700	1201680	kind of, you can do certain kinds of binning with the outputs in those anonymity sets.
1201680	1206900	And that can mitigate certain kinds of heuristics involving common ownership. And, you know,
1206900	1212680	the source of where those outputs came in terms of transactions earlier on the chain,
1212680	1216040	as well as timing analysis. So there's a lot of interesting stuff you can play with. But I don't
1216040	1220160	think there's a really good understanding right now of what exactly those precise trade-offs
1220160	1226800	people are willing to make are. Yeah, in my experience, you know, we have, we have code
1226800	1231580	that can do this now. But I think it's a matter of kind of the community and researchers and
1231580	1237280	developers kind of getting into agreement on what those trade-offs should be. So, and again,
1237280	1241760	hopefully, you know, eventually we get to something that is efficient and trust-free,
1241760	1244740	which would kind of check all the boxes for everyone. And from there, you could, you know,
1244740	1249840	very likely build a protocol that uses such a system and does, in fact, give you effectively,
1249840	1252480	you know, full anonymity, which presumably would be enforced.
1254340	1259780	In my experience, when people talk about full anonymity or limited anonymity,
1259780	1266640	it's, it's sort of in an academic only way. And then it's applied to like, you know, it's
1267060	1273220	typically the way things are currently, right? So limited anonymity looks like a Monero's case,
1273220	1278300	right? And that, in many cases, people think that that just can't even really change. They
1278300	1284220	don't really think about these limited is just, you know, anything less than the full pool.
1284220	1288380	And that could be a, you know, a larger number than the entire size of the pool of enough
1288380	1295560	different network, theoretically. And then people are like, yeah, it also depends on what exactly
1295560	1300080	your threat model is, right? You know, are you concerned about knowing various after,
1300080	1304940	you know, making a bunch of controlled purchases, and then examining the possible transaction tree
1304940	1308740	between you and like, you know, I don't know, an exchange with whom this person or entity is
1308740	1315200	colluding. So, you know, given that, you know, that it's very difficult to get, I would say,
1315200	1319180	practical anonymity, you know, in that particular circumstance. And there's plenty of other
1319180	1324040	circumstances that you can dream up, where under certain threat models, limited anonymity just,
1324040	1328540	you know, won't work for you. So it's one of those, like, it's one of those infuriating,
1328540	1333960	it depends kind of ends, where, you know, it's like limited anonymity right now is a trade-off.
1333960	1341060	It is like an absolute trade-off. And we all look forward to the day when we can do something that's
1341060	1345360	trust-free. And, you know, frankly, like if your particular threat model is going to require,
1345360	1350260	you know, a more full anonymity scenario, you know, then, you know, you might have to consider
1350260	1355280	whether or not going to like a trusted setup sort of scenario is something that you need to do.
1356800	1361820	That may come with its other trade-offs, you know, based on things like ecosystem availability,
1361820	1367020	and, you know, a host of other questions. But it's absolutely a trade-off, you know,
1367020	1369000	and I think it's important to acknowledge that, you know, we have things like the
1369000	1373160	Breaking Monero Series where, you know, we kind of try to tease out some of the particular scenarios
1373160	1377960	under which limited anonymity can be a problem, and those for which it might not be as much of a
1377960	1383260	problem. But it's, I feel like, no, it's not fun to like sit down and try to enumerate and think
1383260	1387880	about the specifics of a risk model, but, you know, it's something that unfortunately right
1387880	1394500	now we kind of have to do. We haven't had a Breaking Monero Series in a while, so I guess,
1394500	1401260	given that we haven't, what episode ideas would you like to see there be episodes for?
1401920	1405620	Oh man, I think it'd be interesting to do one that talks about,
1406440	1411480	I guess, some more specifics on things like churn and self-send operations.
1412340	1415840	So I would say things like that, something involving things like output merging would be
1415840	1419860	very, very interesting, you know, where outputs from different transactions end up being pulled
1419860	1424480	into different anonymity sets into the same later transaction. I'm looking at ways to possibly
1424480	1428180	mitigate that, you know, larger anonymity sets with good output selection can mitigate that
1428180	1432860	example. The churn example is a bit tougher because you could look at things like, you know,
1432860	1439000	possible chain history sizes and distributions and look at, you know, what happens with that.
1439400	1444340	I think it's, yeah, there's a lot of interesting things to talk about, but I think it's important
1444340	1448420	to do them in a way that doesn't end up kind of just rapidly devolving into, you know, confusing
1448420	1460700	graphs and, you know, irritating math. But at the very least, I think I'm really happy at least to
1460700	1464840	see that there's a lot of interesting research into this area. You know, a lot of folks want
1465620	1469140	general zero-knowledge proving systems that are trust-free and efficient.
1469860	1473760	And, you know, that would, I think, be like the ideal, you know, checking of all the boxes.
1474420	1477640	And it's interesting to see what different projects do, right? You know, I mean, things
1477640	1484520	like Zcash and related projects get, you know, efficient proofs that are very fast to verify,
1484520	1488860	and you can do things like effective with full anonymity set transaction protocols,
1488860	1494700	in theory, ideally. Zcash kind of has their whole optionality part to it, but are willing to
1494700	1500200	sacrifice trust to a degree to like multi-party computation, you know. And there's always kind
1500200	1503800	of the question of, like, for your personal use case and how you tend to view multi-party
1503800	1509500	computation, you know, do you think that a multi-party computation setup kind of diffuses
1509500	1513180	the trust out enough to where you're okay with that, or are you not okay with that? You know,
1513180	1518420	because in the theory that does provide like a guaranteed, you know, this is how the soundness
1518420	1523860	of this operation could fail scenario, if that multi-party computation were, you know, misused,
1523860	1532900	for example. So, so many questions in this space, and so many trade-offs. I feel like a lot of
1532900	1539580	cryptography is basically just like the precise study of mathematical trade-offs. But, you know,
1539580	1543640	no, I don't really have a good timeline for when, you know, we might be able to move to something
1543640	1548800	that is, you know, what you consider full anonymity. But there are options for increasing
1548800	1552440	the anonymity set, which lets you do a lot of other cool things, hopefully mitigate some
1552440	1557380	analytical heuristics. Wouldn't solve everything, but I think you'd get improvement.
1558600	1564820	So that's on the tip for October, right? Kidding. Not for October. So, I mean, there's other
1564820	1568480	interesting things, you know, on the horizon too. Ideas for making range proofs a little bit more
1568480	1572560	efficient have come up. There was a preprint that came out on improvement to bullet proofs
1572560	1580320	called Bullet Proofs Plus. The plus actually means taking away a few proof elements, but Bullet
1580320	1586420	Proofs Minus doesn't sound as good. So, I don't know. There was a proposal to do an implementation
1586420	1590980	of that. It's really new. It's kind of a, it's an extension of the way that the Bullet Proofs
1590980	1597400	inner product protocol works in this cool, does this cool weighting operation with it.
1597420	1601200	And it would let us, you know, take a few dozen bytes off of transactions.
1601560	1606220	In theory, they'd be like very, very marginally faster to verify, but, you know, in practice,
1606220	1611100	it would pretty much be a wash, I think, in the grand scheme of things. So really,
1611100	1616400	the question about whether or not it is worth moving to that is worth the effort.
1616420	1620400	And the possible risk of something that's a bit newer has yet to be determined entirely.
1623220	1626680	Were there any other questions that came up besides the one that got us into
1627920	1633360	a very long discussion about protocols? Yeah, there's one. It's still a protocol-related
1633360	1637240	question, so it is going to be a follow-up, though. It says, so the ideal solution for Monero
1637240	1645120	would be zk-SNARKs-like thing that doesn't require a trusted setup? And I believe you basically said
1645120	1650380	yes, but also needs to be efficient. Yeah, yeah, yeah. And, you know, and specifically
1650380	1656640	saying, like, zk-SNARKs specifically, you know, it's... there are different ways to... there are
1656640	1659700	different building blocks you can use to construct protocols, and I think it's important to consider
1659700	1666100	it at a protocol level. So, for example, like, you could basically build something akin to,
1666100	1672500	you know, like the zcache sapling protocol, for example, but without using zk-SNARK construction.
1672500	1677840	You could do that with bulletproofs, for example. I don't think it's actually been done, but I know
1677840	1681340	that there were some estimates made to say, okay, you know, bulletproofs is a zero-knowledge
1681340	1686340	prudent system. The scaling is, you know, in terms of verification, is not as good.
1686340	1691060	Just absolutely not. But what it lets you do is it lets you prove things about circuits
1691980	1697940	in a trust-free way. So that is trust-free. And so, in theory, you could take, you know,
1697940	1701860	the circuit that's using zcache sapling and some of the other constructions, and you could build
1701860	1706420	that in bulletproofs. And you get rid of trust. And the size would still be pretty good. The
1706420	1711820	estimates and the size, like, it'd be competitive. Not quite as good, but still pretty competitive.
1712000	1717200	But the verification would be, no, it wouldn't work. Estimates I saw are, like, still on the
1717200	1720260	order of a second, which you're like, well, a second, that's pretty fast. It's like, yeah,
1720260	1724680	but then you got to do that, like, a million times. So you can, like, amortize that down
1724680	1730580	with batching and stuff, but, you know, it seemed like it was not quite doable at this point.
1731000	1737720	So I would say something that would let you do, like, the whole Merkle proof kind of thing that,
1737720	1743740	you know, effectively lets you do a full anonymity set-based protocol would be ideal if, you know,
1743740	1748100	we could make it mandatory, which other projects have shown you can do that to ensure optimal
1748100	1754060	privacy. But also, I think, ideally is making it trust-free or, you know, at least infusing the
1754060	1757940	trust and the soundness out to the point where everyone is satisfied with it. And I think it's
1757940	1763720	the general view of, you know, a lot of folks who support the idea of Monero to just reduce
1763720	1770180	that trust down to nothing. You know, whereas for other projects, they've decided that they're okay
1770180	1775460	with, you know, kind of delegating that soundness risk off to a large enough, you know, set of
1775460	1780860	participants in a multi-party computation that they are safe, you know, secure enough that they
1780860	1785140	are, I guess, okay with the security of. I don't really know a great way to say that. But that is
1785140	1788520	risky. You know, I mean, like the Sprout multi-party computation that started Zcash, for
1788520	1794260	example, did have a soundness problem. And there was a kind of a whole deal where they had to end
1794260	1798180	up taking down the proof transcripts and hoping that no one was able to figure out and abuse that.
1798180	1803960	So like there's a real non-trivial risk involved, even to something like such a multi-party
1803960	1810820	computation. So that's not without risk either. And it makes the trust situation a little bit
1810820	1817640	more tricky. So I guess I am personally of the opinion that, you know, I like the idea of,
1817640	1822740	I guess, kind of minimizing the possible soundness problems. You know, a soundness
1822740	1826940	problem for something that involves like a trusted setup is the trusted setup and a
1826940	1831400	multi-party computation. You know, for something that, for anything that uses, for example,
1831400	1835400	Peterson commitments, which Monero does, other projects do too, Zcash does, you know,
1835400	1838880	minimal level-based assets do. You know, in theory, if you could break Peterson commitments,
1838880	1844460	that's a problem with, you know, something akin to soundness as well. So it's definitely
1844460	1848080	kind of like this different like threat profile and ideally we want to minimize that.
1850610	1856350	Got it. Something that was discussed quite a few years ago, but I don't think has really
1856350	1861890	come up super recently is the idea of second layer networks on Monero. Like, what if you
1861890	1864690	wanted to put the Lightning network on Monero? What if you wanted to put this, that, or the
1864690	1871150	other on Monero? What if you wanted to put a, you know, a like zk-snark-mixer on Monero,
1871150	1875950	like as an optional thing? Like, so I guess what sort of building blocks need to happen
1875950	1880990	to allow greater compatibility, knowing that right after this we also have a talk about
1880990	1886550	atomic swaps for Monero too? Yeah, yeah, which is a really cool new thing that's still in
1886550	1891550	progress. But yeah, so there's some other researchers who were looking at the possibility
1891550	1897170	what would it take to do, say, you know, atomic swaps between something like Monero and, you know,
1897170	1902810	something like Bitcoin, for example, where in Bitcoin there's a lot of stuff you can do because
1902810	1910310	Bitcoin has both scripting capability, but also, you know, some different kind of setups in
1910910	1918170	how its protocol works and in how it runs things like signatures and the like.
1918820	1924240	And that gets really tricky because Monero does not have inherent scripting capability.
1925110	1930850	Adding inherent scripting capability would be pretty awful for fungibility, so I tend to view
1930850	1936270	that as probably a non-starter on the Monero side. So given that, the question is, well, okay, so what
1936270	1943430	could you do for something like atomic swaps? And one idea that maybe talked about in the next
1943430	1948830	talk, so I won't try to give too much away, involved a particular zero-knowledge proof that was
1948830	1953270	kind of unspecified at the time in the write-up. In theory, we could have done it with something
1953270	1958290	like bullet proofs, but it would have involved hash functions, and that kind of gets messy to do in,
1958870	1964850	you know, in circuits. So that was not ideal. But then, you know, they came up with another idea
1964850	1970850	that uses this clever cross-group proof, where you basically prove that across two different groups,
1970850	1975090	which are, you know, otherwise basically algebraically incompatible, and you can show a
1975090	1979870	quality of like an unknown discrete log. And it turns out if you can do this, you know, you can
1979870	1984830	very cleverly kind of build it into this protocol involving some Monero transactions and some
1984830	1991990	Bitcoin-style transactions in a way that could let you do atomic swaps. It's pretty darn interesting.
1991990	1996810	You know, there's still some kind of open, ongoing questions about, you know, how you need to
1996810	2000890	those transactions, just to make sure that, you know, if one or more of the parties that are
2000890	2005310	involved in this doesn't follow the protocol, you know, what are the risks to funds, if anything?
2005310	2009410	What's the worst case scenario that could occur? And even then saying, well, okay, suppose that
2009410	2014330	the protocol does work exactly as you'd expect, and the swap does happen, you know, what information,
2014330	2020730	if any, does that leak across, you know, one or more of those chains? So, I mean, for example,
2020730	2025390	if you use a centralized service to do swaps right now, like that can obviously have some risk,
2025390	2029790	because that entity knows presumably where assets came from and where they're sending them to.
2030290	2034430	So, you know, that kind of is a central storage kind of risk. But also you can do different kinds
2034430	2039110	of timing analysis and other amount analysis across different chains to try to determine,
2039110	2043030	you know, what's going on and what funds are moving where. And if that's a risk for you,
2043030	2048270	then you don't really want that. So I think the question of what, if anything, about that kind
2048270	2052190	of analysis would transfer from the current setup, which is like, you know, use a centralized service
2052190	2056930	to do my exchanges versus saying, well, I'll just do it atomically without a central service,
2056930	2063630	like what kind of analysis could still happen? It's not nothing, because metadata always exists.
2063630	2068490	But I think the question of to what extent does it happen and, you know, is that something that
2068490	2074150	you want to do, I think are still open, but very interesting nonetheless. There were some other
2074150	2080450	ideas for stuff like payment channel networks, even within Monero. My DLSag was another signature
2080450	2084890	construction that some other researchers came up with. And we looked at it, and unfortunately
2084890	2090810	had like this tracing problem that would have required this whole self-spend thing. And it was,
2090810	2095830	it kind of got messy, and there wasn't really a great solution for it, unfortunately. So that
2095830	2100010	kind of ended up being dead in the water for that purpose, at least, which was really unfortunate,
2100010	2104070	because DLSag would have opened the door to some interesting stuff.
2106110	2111650	Got it, got it. I know this isn't the DLSag names. Yeah, let's go through every letter.
2111650	2115610	Something involving a DLSag construction, just for even more confusion.
2118320	2123160	So I know this isn't your work directly, but I know Isthmus recently opened a community
2123160	2130580	crowdfunding system proposal to look into potential limitations in Monero
2130580	2134660	related to quantum computing. He was going to look at the initial scope
2134660	2140940	of what basically challenges Monero needed to address going forward. Can you speak a little
2140940	2146980	bit about what this general work is doing, and then also speak about Monero and quantum computing
2146980	2153780	generally? Yeah, so this is work that's ongoing. I believe we're going to work on it for three
2153780	2158400	months. We're about done with the first month, I think, of that. So again, I'm like not directly
2158400	2162480	working on this, so I don't want to try to speak for them or anything. But their idea was, okay,
2162480	2167760	under the assumption that someday quantum computers would exist, and there's definitely
2167760	2172140	debate on to what extent people think that this would be a problem in the future. If so, how far
2172140	2179520	into the future? And if all of that, what actions would we want to take now in the protocol to try
2179520	2185420	to mitigate the possible future effects of quantum computers? They want to look at different parts of
2185420	2193440	protocol, of range groups, and ring signatures, and the one-time addressing construction,
2193440	2199720	and all of this stuff. To what extent would different parts of the chain be considered at
2199720	2206360	risk? The way the Monero keys work, there's a private key and public key, and they're related
2206360	2212520	by this algebraic group operation. And it's pretty well understood that the one-way map right now,
2212520	2216700	from private key to public key, where we assume that it's computationally feasible to determine
2216700	2223060	the signing key just if you see a key on the chain, we assume that that's very difficult right now and
2223060	2228200	it's a one-way operation. It's pretty well understood that given a sufficiently advanced
2228200	2234760	quantum computer, that map would be reversible efficiently. So at that point, spend anyone's
2234760	2239860	funds, which I know that's a problem right now. But to some extent, it's not necessarily just a
2239860	2245680	problem for Monero. This is kind of a broadly applicable problem. The entire internet runs on
2245680	2250380	these one-way maps right now, to a large extent. So it's kind of one of those, well, your house is
2250380	2255460	on fire, but the rest of the world's on fire too. Doesn't make your fire any less bad, but it does
2255460	2260860	mean that there would be a lot of problems to worry about. But even beyond that, looking at
2260860	2266800	things like, what would that allow you to do to ring signatures? So as one example, since the
2267380	2274100	key images or linking tags work within the Monero protocol, it would allow you to look at
2274580	2278480	different outputs that are part of a ring and determine which of them is the signer.
2278600	2282640	Because of the way that the keys work right now, they involve private keys and you can basically
2282640	2287640	do a guess-and-check testing operation. So again, under the assumption of a
2287640	2291640	hypothetical quantum computer, and this is impossible today as far as we know, you could
2291640	2295600	figure that out. There's some other questions right now involving things like, what
2295600	2301400	could you determine about stealth or one-time addressing operations? And that's still, I think,
2301520	2307480	a little bit ambiguous right now. One question that I have that I know is not unique to Monero
2308080	2313760	is saying, well, okay, suppose that I will have a transaction here. Maybe I can't just use that
2313760	2320000	transaction to, for example, figure out what the wallet address of the recipient was. Because
2320000	2324660	remember, in Monero, wallet addresses never appear directly on-chain. They're used to derive these
2324660	2330260	one-time addresses. So right now, I mean, without external information, you can't just use
2330260	2334460	on-chain information to link those one-time addresses back to the wallet addresses.
2334580	2338760	So the question might be, even with the quantum computer, could you take a transaction and
2338760	2344360	determine its recipient wallet address, just kind of with no external information? Or if you, for
2344360	2349640	example, had a candidate list of possible recipients that you think it might be because, you know, maybe
2349640	2353340	you have a hunch or some other external information, are there ways that you could go and basically
2353340	2358120	check those to determine which it would be? And again, the address space in Monero is, like, the
2358120	2363300	possible wallet address space in Monero is, you know, unfathomably huge. And, you know, a quantum
2363300	2368680	computer doesn't just mean, like, can do everything fast automatically. There's particular algorithms
2368680	2373300	that we know that can be used against things like the discrete log problem and stuff. So, you know,
2373300	2378620	even if you had a hypothetical quantum computer, you know, saying, well, couldn't it just go through,
2378620	2383560	you know, all possible addresses and see which it is and figure out, you know, what recipient
2384100	2388660	is linked to what transaction? You know, that's likely not going to be directly possible.
2388720	2394540	But the question of, you know, what could such a computer do if it had, like, a small known list
2394540	2398140	of possible addresses? So questions like that, I think, are still kind of up in the air and
2398140	2401980	are part of the subject of the research that they're working on. And I do know that they're
2401980	2408360	also looking at kind of what current directions my protocol development take that could more
2409420	2416700	efficiently, I guess, work on trying to, like, mitigate the effects of a future quantum computer.
2417440	2421900	I guess one problem with a lot of algorithms and constructions that are conjectured to be
2421900	2427980	post-quantum secure is efficiency. They often tend to be much more inefficient than, I guess,
2427980	2431980	would be reasonable to have on-chain. You know, right now, if, like, post-quantum signatures,
2431980	2436640	for example, can get pretty large. And there have been some ideas for how to do some constructions,
2436640	2441360	like linkable ring signatures, even. But they're very large. And even if you were to integrate
2441360	2446480	them into the protocol, you know, we still deal with today's computers that, you know, still have
2446480	2452700	to store things and do a lot of processing. And if it gets to be too large of a transaction that's
2452700	2458600	too slow, no one's going to use it. So, you know, ideally, we'd like to migrate the protocol
2458600	2462840	immediately to something that's conjectured to be post-quantum secure. But there's a lot
2462840	2466280	of parts of the protocol that it's really uncertain if there's anything at this point
2466280	2473160	that's efficient enough. I mean, research in this area is always ongoing. So, obviously, what's the
2473160	2476460	state-of-the-art today is almost certainly not going to be even close to what the state-of-the-art
2476460	2480460	is, you know, in 10 years, 20 years, you know, further down the line, where maybe we have a
2480460	2485600	better understanding of the likelihood of seeing a practical quantum computer. So I think one thing
2485600	2489280	that they're trying to do, and, you know, I don't, again, I don't want to speak for them, but just my
2489280	2493740	understanding of the work that they're doing is to, you know, look at what are at least some directions
2493740	2498920	in research that might give us an indication about what could be efficient down the road for
2498920	2505040	protocol improvements. I mean, I guess the general thing is, like, to some extent, like, in the
2505040	2509480	age of, you know, post-quantum computers, like, a lot of the internet's kind of screwed in terms of
2509480	2515740	security. So, I mean, like, Monero would be, you know, at least to some degree not immune to this.
2515740	2519040	The extent of which different parts of the, I guess, previous chain's history
2519040	2523820	could be known, I think the exact nature of that is what they're trying to determine now.
2525340	2530160	It's really interesting work. Whether or not you think that it's going to be applicable in,
2530160	2535320	you know, your lifetime or the lifetime of people you care about, I think that's also very much
2535320	2539060	kind of a contentious issue right now. I don't think that there's really universal agreement on,
2539060	2544480	you know, when, if ever, folks might end up seeing a practical quantum computer that would affect
2544480	2549120	projects that they use. And, I mean, I'm not even close to an expert enough in that area to be able
2549120	2560220	to even hypothesize. Yeah, I got it. So, switching gears, what research have you seen outside of what
2560220	2565220	you've specifically done for Monero, I would say, that has been, not necessarily useful,
2565220	2570560	but just really interesting and really surprising? I would say, I think, just, like,
2570560	2576680	the extensive work that's been done on general zero-knowledge-proven systems, I think, is really
2576680	2585020	cool. So, I mean, right now we use very specific zero-knowledge-proven systems in different projects
2585020	2588580	for different purposes. I mean, Bulletproof, for example, is a zero-knowledge-proven system that
2588580	2593440	does, like, one particular thing involving Peterson commitments really well. However,
2593440	2597900	that's just one application. There's kind of a variant form of Bulletproofs that you can use
2597900	2605120	to take different algebraic statements, kind of mess them into this particular circuit format,
2605120	2612240	and then build a proof over the circuit arrangement in order to prove that you know,
2612240	2616340	I guess, like, a witness that ends up satisfying the circuit without revealing what that witness is.
2616480	2620540	And, like, that's kind of the general form of, like, a general zero-knowledge-proven system.
2620540	2624060	So, if you have a protocol that you really want to implement, if you can put it into this form
2624060	2628700	and do this kind of representation, then there's all these different tools that you can use right
2628700	2637460	now to prove things about statements relating to this language that you built. So, Bulletproofs
2637460	2642980	can do that. The different proving systems that are used, you know, in stuff like Zcash protocols
2643500	2648660	can do that. There's a lot of stuff involving, like, zkstarts. And, you know, there's a whole
2648660	2653660	host of really interesting research on how to do this and what the different trade-offs are.
2653960	2659500	And, like I said before, like, kind of the, I would say the holy grail for this is trust-free,
2659500	2664840	small, and efficient to generate and verify proofs. And, ideally, also stuff involving things
2664840	2669200	like batching that lets you kind of amortize the cost of verification over multiple proof
2669200	2673540	verifications. Like, just the fact that there's so much fascinating work going on relating to this
2673540	2678360	is really interesting. And, unfortunately, none of it that I've seen, I think, kind of
2679000	2686760	applies directly to the Monero protocol based on what folks want from it right now.
2687760	2690780	You know, right now, the whole trust thing seems to be a pretty big sticking point.
2690920	2694700	You know, like I said, you know, for users who decide that, you know, they need a protocol
2694700	2698080	that does more than what Monero can offer, like, you probably, at this point, are going to have
2698080	2706840	to sacrifice that whole, you know, where is the trust lie question. But, at the same time,
2706840	2711020	the fact that the research is ongoing and has undergone so much improvement over a pretty
2711020	2714860	short period of time, I think, speaks really highly to where that area of research is going
2714860	2719340	to go in the future. So, I mean, I think it would be great to be able to move to a general,
2719340	2723800	idealized, future zero-knowledge proving system that lets us build really cool protocols that
2723800	2730320	give us everything we want. It's not today. Hopefully, it's not too far off.
2731260	2734220	There has been a lot of work in that area. It's been shocking.
2734220	2740780	Oh, it's insane. Yeah, and to be clear, like, I'm really glad that other projects are
2741700	2747540	doing research in that and, you know, putting that kind of stuff into practice. Like,
2747540	2750940	as with all projects, including Monero, like, I think it's important to talk about limitations
2750940	2755820	and trade-offs. Like, if you've tried to do things like this, you're breaking Monero. But
2755820	2759580	it's still good that, you know, those different kinds of applications are also furthering more
2759580	2770480	research. Sorry, I'm also helping some other later speakers come through. Okay, so you have
2770480	2775340	another five minutes. There aren't any other questions that have come in, sadly. Just the
2775340	2781180	two from Andres. So, thank you, Andres, for answering those questions. We appreciate them.
2781720	2795230	Um, no one else came to the office hours. They're true office hours.
2798310	2803290	No, that's okay. No, I mean, it's good to kind of, I guess, recap, like, how stuff has gone and
2804410	2807890	hypothesize as to where it might go. I mean, research is interesting. You know,
2807890	2811710	you never know what's going to come up, what's going to work, what's not going to work.
2813630	2819290	I think the upgrade in October is going to be exciting, because, you know, Bulletproof was,
2819290	2823350	I think, a cool example of something where transactions got smaller and faster,
2823350	2831250	and there were really no big trade-offs that folks had to consider. And I think CLSAG is another
2831250	2837250	example, where, you know, the transactions get a little smaller, they go faster, and not to the
2837250	2842650	extent that Bulletproof's did. And there's not really any security trade-offs. You know,
2842650	2846590	if anything, working with CLSAG helped to kind of improve the way that we understand
2847290	2850790	linkable ring signature security models. So, if anything, like, I feel like there's
2850790	2855810	more confidence now about the security of the setup that we're going to have.
2857090	2860430	So, if anything, it's not really a trade-off. It's just, you know,
2860430	2863070	kind of an increasing stack of benefits.
2864330	2869670	You're saying that it would be weird a little bit with whatever comes next. Because with RingCT,
2869670	2876010	for example, it was an absolutely necessary change to get to hide the amounts of transactions,
2876010	2882570	and all the other benefits came with them. And I think the issues with denominated Monero were not,
2882570	2888250	they still continue to not be well-documented in, I think, like, a very clear way. We know
2888250	2894790	they're bad, but also, I don't think we've had many research papers yet showing how bad they were.
2894790	2902010	Oh, I mean, the early Monero chain is, you know, a fantastic source of material for analysis.
2902010	2909770	You know, I mean, it's well understood that the effects of, you know, a lot of optionality and
2909770	2915590	protocol has always been problematic. You know, a huge number of early transactions,
2915590	2919190	were effectively, I would say, denominized in the sense of,
2920030	2925830	like, Ring-based signer ambiguity. You know, not, again, not based on wallet addresses or anything.
2926630	2930250	But, and I think that that's kind of still influences work that goes on today. Like,
2930250	2937190	there's still parts of the protocol that have some optionality in them. And, you know,
2937190	2941870	it's, you know, you can argue that it's good to have some flexibility in the protocol to allow
2941870	2946810	for alternative use cases that you might not anticipate. But at the same time, like a lot of
2946810	2951650	the work that especially folks like Isthmus and his group have done has shown that the optionality,
2951650	2955190	you know, can lead to fingerprinting if you're not using standard software or using a service
2955190	2961410	that does something in a strange way. And I think there, I think that a lot of folks are coming
2961410	2968070	around to a better appreciation of the fact that limiting the protocol to, you know, improve
2968070	2974350	uniformity and decrease fingerprinting is very much like a one-sided, increasingly lopsided
2974350	2981190	argument toward, you know, limiting the protocol. And there's still, like, there's still things to
2981190	2985750	do in terms of that. And I think the more that we understand about some of the early protocol
2985750	2991130	decisions and how that optionality was bad, I think the more that that can influence better
2991130	2995790	decisions going forward. You know, like the protocol always have like the old chain to deal
2995790	3000130	with. And I think the best to do, the best thing we can do is try to make good decisions going
3000130	3007110	forward to, you know, improve uniformity that can decrease risk and improve safety.
3009510	3014270	Understood. Andreas asked the last question here. Are there any projects working on voting
3014270	3018470	based in Monero? I know, like, that one Italian government wrote up that one thing about how they
3018470	3024110	maybe were... Yeah, that was, that was a political party, right? Yeah, it was. Yeah, I don't know if
3024110	3030550	that ever actually got implemented. I don't think it did either. Voting is, I mean, I'm by no means
3030550	3036970	an expert on voting, but everything that I know, and I mean, folks who do different villages at
3036970	3044490	DEF CON involving voting probably know way more than I do that electronic voting is tricky. And
3044490	3049150	if you think you found out all the ways it could go wrong, it will always surprise you.
3050690	3055350	So, I don't know. I mean, I thought it was cool to see in the original LSAG paper an application
3055350	3060270	to voting just kind of as a, like, a fun academic thought experiment. And who knows? You know,
3060270	3067370	it's presumably something involving, you know, good signer-ambiguous proofs going forward,
3067370	3073710	you know, might be beneficial. Who knows? For voting. But, you know, I don't think that, like,
3073710	3078630	LSAG or CLSAG would be the thing to use. I mean, there's enough efficiency problems that, you know,
3078630	3082290	trying to scale that out to the... because, again, like, the whole idea was that you basically
3082290	3086290	have, like, all the different possible voting entities as, like, part of a ring or the entirety
3086290	3090750	of the ring. Like, I don't... that isn't going to scale reasonably well. And, you know, the trust
3090750	3095630	model is so much different for voting that, you know, you could probably get away with something
3095630	3102950	that ends up trading certain kinds of trust for... yeah, I don't know, maybe it's trading that kind
3102950	3107510	of trust for better efficiency. It's... I haven't thought about this in years enough to be able to
3107510	3113050	speak well to it. So, just keep rambling. Yeah, understood. Okay, well, that's the time that we
3113050	3117730	have. Thank you so much, Sereng Noether. If people want to follow Monero Research Lab, there's always
3117730	3125490	the monero-research-lab channel. Sereng's always there, of course, 24-7 manning this.
3126010	3131310	Yeah, there's definitely the IRC channel. If folks don't want to be on IRC, you know,
3131310	3135050	posting questions in rmonero, there's a lot of folks there who are good at research and
3135050	3142470	development who can answer. On the monero-projects meta repo, on the issues there, you can see
3142470	3147070	when all the meetings are and logs from those meetings are always posted as well after the fact.
3147210	3151150	So, folks want to see, like, what people have been talking about. Yeah, and everyone's welcome into
3151150	3155430	the meetings if they happen to have anything that they think is interesting or useful research
3155430	3161390	the group might like to see. So, yeah, a lot of great contributors, not just me by any means.
3161390	3166750	A lot of really great researchers and folks who are interested in protocol improvements and, you
3166750	3172610	know, improving privacy in the digital asset space. So, thanks to all the other contributors.
3173690	3175850	Well, thank you so much, Sereng Noether, for joining us again.