 Alright everyone, I know it's a little bit early but I'm gonna start a little bit ahead of time because there is a lot of information for me to cover about ring signatures today. So before I begin, can I just have a quick pull of the room? How many of you know what ring signatures are? Perfect. So unfortunately since I have so little time, I'm gonna kind of jump right into ring signatures without an initial explanation. There are a lot of other resources you can use if you want to have an initial explanation about ring signatures. But we're going to be looking specifically essentially why ring signatures suck and what you can do about it. And under which use cases should you be concerned about how ring signatures work and ultimately what sort of entropy they provide with Monero transactions. So ring signatures, they are one of the four primary components of privacy that Monero offers. The ring signatures are used to obfuscate the sender in the transaction or more accurately which output is used in the transaction. It makes it seem as if several outputs are each independently being spent, you don't know which source of funds is actually being used. So we're just going to talk about that one component today. So if you look at a ring signature, it kind of looks like this. First it's important to understand outputs. Outputs are like pots of gold. They're single use pots of gold. When you send a transaction to someone else, you create a new pot for them and you dump whatever gold or Monero you want them to keep. And then you make a new pot for yourself that you dump all the change back into yourself for. That is how Monero money is held. It's held in these outputs. It's really important to understand how outputs just generally work. They're stored as essentially pots of gold, so to speak. And so on the screen here you can see an example of a ring signature. A ring signature contains several of these outputs. The highlighted one, let's say, is the real source of funds you want to spend. If you want to give someone five dollars, you need to give them a five dollar bill. Similarly with Monero, if you want to give someone Monero, you actually need to spend money that you have. That is the output you do control and the output that you are spending in the transaction. These other black pots, so to speak, these other outputs, are called decoys. You do not control these outputs and they're just essentially money other people control, but you select these from the blockchain to make it seem as if these sources of funds are also used in the transaction. Collectively you have this ring of, in this case, seven outputs. Seven is the current minimum ring size for Monero of potential sources of funds that are used in the transaction. These seven potential outputs are the sources of funds that could be used in this transaction. So that's the general idea of a ring signature. Now it's important to also understand the key image. The key image is a reference to the actual output you do control. It has nothing to do with any of the decoys. This is important because otherwise you could just fabricate a transaction with everyone else's money and make it seem like you're spending other people's money. You need the key image in order to actually make sure someone's putting something up for stake. They actually have the right to spend the funds that they say they are spending. But the key image is really important because there are potential attack vectors with how the key image can be used across several different chains. We'll speak about all of that during this talk today. So history of the ring sizes of Monero. Monero was launched in early 2014. When it launched, it had a ring signature feature. But there was no requirement that you actually included decoys in your ring signature. You could create a transaction essentially without using the feature where you had no other decoys, decoy outputs in your transaction. And that was pretty bad. There are several research papers I highly recommend. You read MRL1 and MRL4, which are two research papers on this topic, or else you can talk to either me or Sarang after. And as a result, we decided in order to actually protect the integrity of the privacy really in Monero, we need to have a minimum ring size. And so in March 2016, the minimum was increased to three. And then in September, the minimum was increased to five. In early this year, we learned of a new attack vector. And it was increased to seven in order to provide protection against this attack vector. I'll speak about this vector later. And going forward, we don't have a super concrete set plan. So I'll speak about how we weigh the pros and cons and how we decide what considerations are necessary to increase the ring size. So this is the first attack I really want to cover. And it's really critical to understand the idea of a zero decoy attack. Because every single other one of the attacks essentially replicates the same sort of effect, but just does it in a different way. So once you understand the impact of how zero decoy attacks work, you can pretty much understand anything else. So we have the ring signature there, for example. There's seven outputs in the ring signature. Six of them are decoys. In Monero's past, you could create transactions without any other decoys. This is an example here. Suppose you had a ring with just this one decoy. In this case, there's absolutely no ambiguity. You know that this output was spent in that specific transaction. So if my ring size seven transaction included this output in my ring signature, you would know since that output was known to be spent in that other transaction, it could not have been spent in this ring signature. So instead of having an effective ring size of seven, you're now down to an effective ring size of six, because this one output is known to not possibly be a real one. It's known to be a decoy. And if you repeat this process for several other six outputs, you then are able to determine, OK, well, now that you know that none of the other decoys are the real one, like you know that they are actually decoys, you're able to know that the output that you sent in the transaction, the real money you spent, was actually spent in this ring. And this is where the chain reaction effect comes in. So even though your transaction used a ring signature, since your ring signature was compromised, it actually negatively impacts other transactions which use your output in their ring signature. So as an example here, you have another ring signature, and one of the outputs that they selected was one of yours. Since this output is known to be spent in the transaction on the left, it is known as a decoy for the transaction on the right. You know it is not a convincing possible output that realistically could have been spent. So that's the general idea of the zero decoy transaction. In effect, it's a mechanism to attribute outputs as known to be spent in other transactions in order to ultimately learn more and ultimately break down the ring signatures so you know what real output is actually spent in these transactions. So going over a few other potential attack vectors, this is something that we just essentially discovered earlier this year. It sort of came out of nowhere. Air drops were all the rage earlier this year, and someone decided that Monero is a pretty big coin. I'm just going to do one for Monero. And we're like, oh, that actually has a potential for a lot of damage. And I don't know of anyone who hypothesizes this ahead of time. So we sort of had to adapt to this sort of situation. So if there's a split where Monero might have its existing blockchain and someone forks off, there are a lot of considerations if people spend funds on both of these chains. Because if they spend funds on both of these chains, they have the same output that they have on both of the chains. So if I have my one output of Monero before the split, I have the same output on both chains. So when you would send a transaction on both chains, the key image would be the same. You would have the same key image on both. Now, what you could do is look to say, OK, well, I know that since it's the same key image, I know that each transaction on both chains, if you made a transaction on each of these chains, would contain one output that was spent on both of these chains because the key images are derived from these outputs. So as a result, you can check to see if there are any shared outputs among these different ring signatures. And you can see here, for example, that there's one output that is shared. They have the same TX10 output on both. But all the other ones are different. There's no other overlap in these outputs. So you're able to say, OK, since this is the only possible output that could have been spent in both transactions, I know to eliminate all of the other ones here. Therefore, you have the situation where, since you have the same key image and only one match of the output, that you're immediately able to tell which output is actually spent in this transaction. If instead you use a tool that have been developed in the meantime after we realized this was a potential attack, you could create two transactions on both chains with the same exact ring signature for both. That way, you're able to compare the key images. The key images are the same, but there are several matches of these outputs. All of these outputs are potentially spent on both. Now, it's important to remember that if you are spending transactions on two chains, that you increase your attack surface. Because if on either of these networks, one of the outputs is known to be spent in a different transaction, it reduces the ring size for both of these transactions. For a fork of Monero, it's known that one of these outputs is spent. That also impacts your Monero transactions. It's a really important consideration, and we're luckily able to understand the attack a little bit better now, but this is something we really needed to address. Luckily, this is a tool that is enabled by default. As long as you're using a recent fork of Monero, if there are recent forks, they should include this functionality out of the box. Speaking to another new consideration, the idea of public mining pool data. For the sake of providing transparency to the miners who mine Monero, the miners prefer to know when the pool's mine blocks, and they prefer to know when they receive payments in order to have some transparency for the pool so that they know there's a lower chance of corruption from the pool stealing their hashes or stealing some of their Monero. This is fine from that perspective, but unfortunately, since a lot of transaction data is public, it actually increases, it makes a situation where many of the outputs that they touch might degrade the integrity of these outputs so that you would know that they could not reasonably be used in other transactions. Here's an example for support XMR, which is a common Monero pool, and they have a list of all the coin-based blocks that they mine, and they have a list of all the payments that are made. Unfortunately, you can use both of these pieces of information to determine, okay, well, they mined this block. They have this coin-based output that was generated. If this coin-based output is included in a ring signature somewhere, but it is not on this transaction list, I know that it is a decoy. I know that I can claim that this is fake in this case because otherwise it would have shown up in this transaction list. So to address this, there are several techniques we can use. So first, and so you have the case there where, sorry, there are several techniques we can use. So regarding the coin-based, unfortunately, there's not too much you realistically can do because you know that the pool would just reasonably mine it, but you can, as a pool, you can churn the output. You can essentially create a transaction, several transactions without publishing this on the transaction list, or perhaps even simpler as a wallet client, there could be an option to say, did you mine any Monero with this address? If you just check no, then it will exclude coin-based outputs in your ring signature. That's a pretty simple straightforward mechanism. For the payments made, there's a really unique thing we can do is have a different way of selecting what outputs are included in these ring signatures. And so I'll speak about this one because it's pretty interesting. So pools, when they send transactions to people, receive an output back to themselves as change. So I suppose they mine two blocks, and there's a certain payment threshold such that they're paying three of their miners, but they're not paying out all of the money that they have. They would receive certain ones of these outputs as change back to the pool. And what the pool can do is, for subsequent transactions, select exclusively from the outputs that they created, including the outputs that they sent to the miners. So if, for the example of a transaction here for a pool payout, they pay out to two miners here, and one is a change output back to the pool, they can create subsequent transactions with all of these outputs as potential spenders. And this is great because it preserves the integrity of these change outputs. It makes it so there's no practical difference between the change output and the outputs that are sent to the miners. So in a case here, you can see for a standard transaction that a pool would have going forward, or that someone would have, that it would just look like a standard ring size. You don't need to instead worry about this output because it is not known to be spent in any specific transaction anymore. So just simply by changing the selection algorithm for these pools, we can increase the privacy and preserve the integrity of additional outputs. So the last one I really want to talk about, and this is pretty straightforward too, is the idea of an exchange or a wallet provider touching a lot of outputs, and therefore having high visibility of a large proportion of outputs. If I'm an exchange and I possess a very large amount of Monero outputs, and you include my outputs in your ring signature, since I own that output, I know you did not spend it. So it's like, I know you can't spend my money, so I know it is a decoy. And if you have large players, this is a potential concern, especially if they're able to use this data on top of other public information that's revealed. So if I create a ring signature here, and all of my decoys are used from this attacker's holdings, it compromises the ring signature from this perspective because the attacker knows you could not have spent the money that they have. And so this is another concern going forward. It's a reason why we need, with Monero, we need to make sure that a single entity doesn't control like all of the outputs that Monero has. So what can you do at sort of addressing these concerns? What are general mechanisms you can take to protect yourself more than the ring signature can currently provide? So first you can, what we call black ball or black list, known bad outputs. So if you, like in Monero's early history, you had a lot of zero decoy transactions, you know just don't include those outputs in your ring signature. You specifically avoid them. There is a tool that has been built out so you can do the same thing for two different chains. You can point the tool at the Monero blockchain and a different fork of Monero and say look for any issues with the key images, the key image reuse, and it will black list outputs if they are known to be spent in either of those transactions. And so this is generally just something you can do. Most wallet software will include this. It's currently not intuitive. It still takes additional effort from you to actually use. But generally it's best if you don't accidentally include money that you already knew could not have been a plausible spend for you to make. And so you could use the black, you can use the black ball list to exclude anything. You can include anything in as much that you want. But generally you should include the zero decoy out, the zero decoy transactions, which are no longer an issue with Monero. So it's unlikely you would select them anyway, but you can still blacklist them. You can blacklist the identical key image issue I just explained earlier. You can blacklist public pool data. So if a pool has an API, you could potentially use that to blacklist certain items. And then if you know that like large wallets and exchanges have a certain output list, which is highly unlikely you could blacklist these. Unfortunately this is probably going to be private information you would not have access to. Another thing you can do is called churn. And I don't want you to look or think too much into the actual entropy here. That's kind of a best case scenario. It's not exactly realistic in each case. But churning is the process of sending money to yourself. So in doing so, you're able to essentially have, instead of one transaction with a ring size of seven, you have additional transactions that each have their own entropy. Each have other transactions that reference all of these different outputs. So overall it increases the entropy from your ring signature. Instead of increasing your ring signature size, you can just send several transactions. So that way if one of these ring signatures is compromised, then you're protected by all the others. So in general, it's recommended, these numbers are still essentially being ironed out. We don't have a lot of definitive research here. But if you're worried, you can use churning to protect against different heuristics where people might suspect funds are bad. And in those cases, we would recommend churning between five and eight times depending on your use case. Ultimately, this all comes back to the use case again. And I'll speak about that in the next few slides about, ultimately, what does this mean for you if you're using Monero? And then, so finally, make sure that you spend during good times. Unfortunately, you won't necessarily always know the answer to this. But essentially, if you know that it is a bad time to spend Monero, you should try to avoid it as if possible. So if you know that there's an upcoming chain split for Monero, you should hold off spending funds shortly before or after this chain split because during this time period, there's a higher likelihood that a higher proportion of outputs would be compromised. So you should try and avoid these certain scenarios if possible. But if Monero was under attack right now, you would not necessarily even know that. So it's hard to... You can only do this for things you already know of. So let's talk about the different types of linkability that is available with how these outputs are connected to each other and what you really can do about it. So first is the idea of linking sub-addresses and transactions. There are two very popular, like, Monero ecosystem parts. One of is Moneruio, which is an Android wallet, and one is the Monero art. I have no reason to believe they're connected to each other, but let's suppose you're one person, you control both of these services, but you don't want any association between these two services. With Monero, you have a mechanism called a sub-address where you can publish an address on both of these different websites, and ideally, since there's no link between the sub-addresses at all, that it would keep these identities separate. Unfortunately, it becomes a little complicated depending on your spending habits on the blockchain. So suppose I made a donation to each of these sub-addresses. I did not know that they were linked together, but suppose that later I see that there's a single transaction that includes both of my outputs in two different rings. That would be highly suspicious because it would be incredibly unlikely to happen by chance. It would be unlikely for one transaction to contain both of these outputs. And so this is a situation that is, like, a big concern with sub-addresses because we tell people that this is a good way to keep your identities private, or the different addresses private, but depending on how you use Monero on the blockchain, you have plausible deniability, but you might still look suspicious. And so there's several things you can do. In general, for this sort of case, I would recommend keep the funds sent to each sub-address separate, and you need to churn each sub-address funds separately. And if you don't want to use sub-addresses, it might be simpler just to use two completely different Monero wallets entirely because it might be easier to keep those outputs separate and churned. So if I receive five payments to Monero and someone receives three payments to Monero Art, you should churn each set separately. Just make sure they don't touch each other. Make sure there's additional entropy before you put these funds back together. On the second situation, you have a situation where you're linking sub-addresses or addresses to a real-world identity. So suppose that in this case you need to add additional entropy before you interact with anyone that knows your real-world identity. So it's one thing for your online profiles to be linked. But if it's also linked to you individually, that's a large consideration that many people have. And in that case, especially if you're sending funds to a KYC-AML exchange, you need additional entropy before you send funds to an exchange if you don't want any suspicion of the funds coming from you. So you should churn before sending funds to these exchanges because it will provide you with additional entropy, additional possible sources that these funds could come from rather than just the standard ring signature. And then in the extreme case, you might want to say, every single output I touch should have no connection to any other output. And ideally, you're like, OK, wait a minute. Isn't this essentially fungibility, right, that every output is not connected to each other as no past history? And you're right that ideally under a perfectly fungible system, it would have a situation where every output is completely independent. Unfortunately, that's just not the case at the moment. With Monero currently, you have fungibility through plausible deniability, not through protection against every heuristic. So it still is possible that certain outputs might appear more suspicious than other outputs. And so this is a big consideration you have. And it's something to really keep in mind when you're spending Monero. So in this extreme case, you would have to keep every output separate and add an entropy for each of these outputs independently, which would involve churning each of these outputs independently, which is a lot of work. But it's required if you don't want any sort of on-chain connection or any reasonable on-chain connection between any of these outputs. So what are some of the challenges that we have for increasing ring size in general? So first, there are real costs to increasing the ring size. We can't just make a ring size of, I don't know, a million for every transaction because although that would be great for privacy, you wouldn't really need to worry about any of these concerns anymore. It's just not practical. There are real costs in verification time and real costs in transaction size. And each of these also leads to a cost of additional fees in sending the transaction. So we need to specifically weigh all of the benefits people have from the increased ring size of privacy in Monero against these real costs. So technically from a really strict level, the higher ring size is better. If you're able to increase your ring size strictly, that's better. But when you're specifically trying to weigh pros and cons, it's much more effective if you're able to tie these considerations to specific use cases. So for example, with ring size seven, that was selected specifically to protect against the chain split potential attack. That was a specific threat model that we had in mind. And so ring size seven was selected for that specific purpose. If we were to further increase the ring size, we should similarly justify it in a similar way in order to say we're increasing it for the reason because it has an actual impact that people have. So in summary, we covered four different ways for ring signatures to be compromised. We considered several considerations for the heuristic tests, ways for money to seem more suspicious than not. And we covered some of the best practices for using Monero's ring signatures correctly in a variety of use cases. And we covered the challenges of increasing Monero's ring size. If I had more time, I would talk about the difficulties of Monero's selection algorithm and many other components that go into ring signatures. But ultimately, the bottom line is that ring signatures are the weakest point of Monero's privacy. Unfortunately, they're the only system we have at the moment that provides a sort of trustless privacy for hiding the sending output. And hopefully we can move to a different system or find additional benefits in order to further increase the entropy set for all transactions with Monero. And so bullet proofs are an example of an improvement that we have. We have a real opportunity to reduce the verification time, the transaction cost with Monero. But ultimately, even with these improvements, we still need more in order to protect Monero against these sort of heuristics that might come up. So that's all the information I had. I know it's a lot. I was jumping right into it. We have the standard Monero information on there. More specifically, that's my email in case you need to reach out to me with any additional questions. I'll be around. Again, Serang and I can answer a lot of other questions. I'm going to check on time real quick. I have a few minutes, about seven minutes for questions, so I can take those now. But I appreciate speaking kind of the big concerns with Monero's ring signature mechanism. Yes, instead of the ring signature. So the reason zero-knowledge proofs were not chosen, so one, Monero started before zero-knowledge proofs became a big thing. And two, it's not a trustless system. So you still need to have a trusted party to provide the entropy for that system. No one in the Monero community feels comfortable providing the initial setup required to have this system. So to have a z-case-narc implementation, you need to have a specific group of people that create this entropy, and you need to make sure that they destroy this entropy otherwise the story is essentially toxic waste, as it's called. And if they don't, then they can produce money out of an error. And there's no way to detect that. So with Monero, we don't want that obligation. We want to say, OK, this is what we can do without you having to trust that the Monero team can print money out of an error. And this is currently the best scheme that we realistically have. Yes, absolutely. So the privacy of Monero is provided by the privacy of its users, frankly. And I think this is most, like, clearly evidenced as Monero had an opportunity for you to send a zero-decoy transaction. And at the time, some 70% of transactions did not use any decoys. And the best thing you can really do to approach that situation is make tools readily available. And for the zero-decoy case, it's, OK, we're prohibiting these. You can't send these that hurt other people's privacy. Because, yes, it's fine. You can argue that it's nice for someone to have the choice of being public. But if that hurts other people's transactions, realistically, you have to make the requirement. For change splits, there's a possibility for some better mechanisms going forward. But by default, the wallet clients that currently exist will use the same ring set on both. So there's a much lower risk. And based off the current ring size that we have, if there ever was an issue where a large proportion of outputs were being compromised, we would be able to at least have a high probability of detecting that before it would cause any major issues if we could at least warn people. So you're right that it definitely comes back to you need to make sure other people are spending funds in a not completely absurd way. And we just need to do our best to make sure that that's how people are generally spending their funds. Yes. So in some ways, yes. So mixing with Bitcoin, it's the idea is you take several sources of funds, you send it to a specific party, they jumble up who's-is-who, and then they send outputs back to each person. And you don't necessarily know which outputs were allocated to which persons. For Monero, it's similar in some ways because you make it seem as if you're spending other funds. The ring signature is most similar to a mixer. The big difference is you don't need to trust a person to provide this functionality. You could sign the ring signature offline just with a copy of the blockchain and then broadcast it later to the network. So in some ways it's a fair comparison. In other ways, there are significant differences in how it's actually implemented. Yes. Realistically no. In order to make something mandatory, ultimately you need to make something, a requirement on the consensus layer. I don't know of any way that that would be realistic. And I think that churning is not necessarily something that most people even have in their threat models. Unless you are highly concerned, unless you are like someone with a really high consideration for your privacy, like if you live in North Korea or something, then you would, like churning is important to you then, but if I'm just making a simple transaction, I still have plausible deniability under any reasonable circumstance we can come up with now. So the reason we can't really make it mandatory though is because churning transactions by definition or they look exactly the same as any other transaction. And so you can't really force people to make transactions necessarily. That's the sort of requirement it would take. Okay, so I think I'm going to take one more question and then I can hand it off to the next speaker. Did you have one? Yeah. Yeah. Okay, so that's definitely a big consideration. And I think it manifests itself mostly in two ways. So I didn't really talk about the input selection algorithm, but the selection algorithm is not consensus driven, so that is up to the wallet to decide which outputs to select. And if your wallet selects outputs really poorly, then it really harms you and the network. So, and especially if the wallet was widely used, if it was a widely used wallet, suppose an exchange when they had payouts purposely chose bad outputs to sabotage people. So that's an important consideration there. There are some changes you can do to consensus to make sure that X percent of outputs are from a certain percent of days to make sure people are generally honest, but that's currently not implemented. And currently there are no wallets I know of that have that sort of like undermining situation. My Monero used to have a different selection algorithm, but they have updated to the latest Monero selection algorithm. And then the second one is just a different ring size. Ultimately, if you have a different ring size, you have a different piece of metadata that stands out in the network. And so there are some discussions to move to a fixed ring size. Okay. Well, thank you. I'm always here to answer questions later. And I appreciate you coming to hear about ring signatures. Let's give S&P a hand. Thank you so much.