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. 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 $5, you need to give them a $5 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 are 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. That is the general idea of a ring signature. It is 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 are spending other people's money. You need the key image in order to actually make sure someone is 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 will speak about all of that during this talk today. A 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 decoy outputs in your transaction. That was pretty bad. There are several research papers I highly recommend. You read MRL 1 and MRL 4, which are two research papers on this topic,

or else you can talk to either me or Sarang after. As a result, we decided in order to actually protect the integrity of the privacy in Monero, we need to have a minimum ring size. In March 2016, the minimum was increased to 3. In September, the minimum was increased to 5.

Early this year, we learned of a new attack vector. It was increased to 7 in order to provide protection against this attack vector. I will speak about this vector later. Going forward, we don't have a super concrete set plan, so I will speak about how we weigh the pros and cons and how we decide what considerations are necessary to increase the ring size.

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.

Once you understand the impact of how zero decoy attacks work, you can pretty much understand anything else. We have the ring signature there, for example. There are 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 is absolutely no ambiguity. You know that this output was spent in that specific transaction. If my ring size 7 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. Instead of having an effective ring size of 7, you're now down to an effective ring size of 6 because this one output is known to not possibly be a real one. It's known to be a decoy. If you repeat this process for the other six outputs,

you then are able to determine, now that you know that none of the other decoys are the real one, 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.

This is where the chain reaction effect comes in. 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. 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. 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 signature so you know what real output is actually spent in these transactions. 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. Airdrops were all the rage earlier this year, and someone decided that Monero was 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 hypothesized 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, okay, 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, okay, 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. And therefore you have a 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 has 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. Because if for a fork of Monero, it's known that one of these outputs is spent, that also impacts your Monero transactions. So 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 pools 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 pools stealing their hashes or stealing some of their Monero. And 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. So here's an example for Support XMR, which is a common Monero pool, and they have a list of all the Coinbase blocks that they mine,

and they have a list of all the payments that are made. And so, unfortunately, you can use both of these pieces of information to determine, okay, well, they mined this block. They have this Coinbase output that was generated. If this Coinbase 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. Regarding the Coinbase, unfortunately, there is not too much you realistically can do

because you know that the pool would just reasonably mine it. As a pool, you can churn the output. You can essentially create 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 Coinbase outputs in your ring signature. That is a pretty simple, straightforward mechanism. For the payments made, there is 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 will speak about this one because it is pretty interesting. So pools, when they send transactions to people, receive an output back to themselves as change. So suppose they mine two blocks, and there is a certain payment threshold such that they are paying three of their miners, but they are 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 could 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 is 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, that someone would have, that it would just look like a standard ringsize. You don't need to instead worry about this output because it is not known to be spent in any specific transaction anymore. 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. I know you can't spend my money, so I know it is a decoy. If you have large players, this is a potential concern,

especially if they are able to use this data on top of other public information that is 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.

So, this is another concern going forward. It is a reason why with Monero we need to make sure that a single entity does not control all of the outputs that Monero has. So, what can you do at addressing these concerns? What are general mechanisms you can take to protect yourself

more than the ring signature can currently provide? First, you can what we call blackball or blacklist known bad outputs. In Monero's early history, you had a lot of zero decoy transactions. You 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 blacklist outputs if they are known to be spent in either of those transactions. So, this is generally just something you can do. Most wallet software will include this. It is currently not intuitive.

It still takes additional effort from you to actually use. Generally, it is best if you don't accidentally include money that you already knew could not have been a plausible spend for you to make. You can use the blackball list to exclude anything. You can include anything in this list that you want.

Generally, you should include the zero decoy transactions which are no longer an issue with Monero so it is 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 large wallets or 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. I don't want you to think too much into the actual entropy here.

That is kind of a best-case scenario. It is not exactly realistic in each case. But churning is the process of sending money to yourself. In doing so, you are 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 are protected by all the others. So, in general, it is recommended. These numbers are still essentially being ironed out.

We don't have a lot of definitive research here. But if you are worried, you can use churning to protect against different heuristics, where people might suspect funds are bad. 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.

I will speak about that in the next few slides. Ultimately, what does this mean for you if you are using Monero? Finally, make sure that you spend during good times. Unfortunately, you won't necessarily always know the answer to this. Essentially, if you know that it is a bad time to spend Monero,