 Hello, everybody. Thanks for coming to this talk, Privacy in Ethereum. So today, I'm going to talk about where we are at the moment and where we want to go. So in Ethereum over the last six to 12 months, we've had a lot of new and exciting, zero-notch-proof stuff coming up. Yeah. So for example, we have a bunch of mixers that are coming out. Tornado Cash is live on Mainnet at the moment. MicroMix is in progress. Yeah, Argent Hopper is live on Mainnet 2. And maybe there's more that I'm not saying that I left out. And then we have some kind of other interesting privacy applications, like Aztek, which will be coming out, are about to run their trusted setup. And as well as just doing transactional privacy, we also have private applications to do with private signaling, like semaphore, private voting, private DAOs. There's this really cool PoAp signaling app at this event, where you can get a PoAp token and deposit it into a private pool and then start to make private signals using this, which is pretty cool. And then we also have private voting, where it's impossible to prove that you voted a certain way, which is important for quadratic voting and things like that. So let's start and talk about the mixers first. So there's a bunch of snack-based mixers at the moment. And what they do is pretty simple. So basically, you have some money, you deposit it into the mixer, and sometime later, you withdraw that money. And this question mark here shows that you don't know which deposit is which withdrawal. So there's three of these that I know about. Micromix, Hopper, and Tornado, which is in production. So what are the problems with this? So one of the problems is that there's like a single denomination. You deposit one ether, and you withdraw one ether, and there is no kind of way to do internal transactions. So for example, if you want to send some money to your friend, you have to deposit the money into the mixer, withdraw it, and then send it to your friend, which is kind of annoying, especially because there's like only a single denomination allowed, so you can only ever send your friend 0.1 ether or less than 0.1 ether, which is a little bit annoying. And the third problem is that you need to pay for the gas for the transaction, but we have this kind of chicken and the egg situation. So for example, imagine I have address A and address B, and B has 0 ether, and A has 10 ether. And I want to transfer one ether from address A to address B, but I don't want to link the two together. So the first thing I do is I deposit the money into the mixer, and then I need to withdraw that money to the new address. But I don't have any gas in the new address account, so there's no way for me to withdraw it there unless I send some money there first, which kind of defeats the purpose of putting it in the mixer in the first place, because if you send it from address A to address B, you link those two accounts together. So what we do instead is we come up with some kind of transaction abstraction, where we make it like another network of nodes that will pay the gas for a transaction and also get repaid that gas at the end of the transaction. So those are the kind of three main problems of mixers. And here are some kind of attacks that we can leverage to de-anonymize people. So first of all, one big problem that we have is that there's no metadata. There's no metadata privacy here. So when you go into any of the mixers, there's a user interface, and when you deposit your coin, you have to send information to the blockchain, and that information is sent through. That means you create a transaction, and you broadcast that transaction through Infura. So everybody is able to know who deposited it. So Infura is able to know whose IP address sent which money into the mixer. But more seriously, Infura is also able to know whose IP address withdrew money from the mixer, because when you make a withdrawal, you also need to send some information to Infura. You need to request information from Infura, and you also need to broadcast that transaction. So Infura knows the metadata you're requesting, and you have to be very careful about the metadata that you request. And you have to be very careful about the metadata you request. And the, sorry, just one second. Yeah, you have to be very careful about the metadata you request. And the re-layer knows your IP address when you withdraw. So what can you do to limit this? So you can use Tor. So if you log in with Tor to the mixer, which is totally possible, you can do your deposit and your withdrawal through Tor. But very few users actually do this, and we should try and encourage people to do this as much as possible. So you should use Tor for the withdrawal, but you shouldn't use it for the deposit. And the reason for this is that if you use it for the deposit and the withdrawal, you can break your anonymity set up into two groups. Group number one is the people who use Tor to deposit, and group number two is people who didn't use Tor. And this attack can be quite serious, especially when you have a small anonymity set. So for example, imagine that there's 100 coins in the mixer, and one person deposits a coin with Tor, and then sometimes later, the same person withdraws the same coin with Tor. Or no, someone withdraws a coin with Tor. It seems pretty logical to say that, OK, the person who deposited with Tor is also the person who withdrew with Tor. It seems like that is kind of reasonable, because why would you deposit with Tor and then remove Tor for the withdrawal? It doesn't really make, yeah. So there are these kind of heuristic attacks that you can do that you need to be careful about. Yeah, so in the long run, we should have Tor by default. We should have Tor by default for the deposit and the withdrawal. So then there's also temporal attacks. So imagine that we have a mixer that has this huge amount of ether deposit. Imagine there's 1 million coins deposited into the mixer. And then these funds have been there for a long time. And then one day, someone comes along and deposits one ether in, and then sometimes later, somebody withdraws one ether from the pool. So it seems pretty unlikely that one of the 1 million people who had the money deposited there for a long time suddenly decided to come along and withdraw. I would be pretty confident to say that the person who deposited is also the person who withdrew in that scenario. So you can have these kind of heuristic attacks that you say, OK, the last person to withdraw, the last person to deposit is the next withdrawal. So you have to be careful about the amount of time that you leave your funds in the mixer. So to defend against this, some UIs force you to deposit for a certain amount of time. But there's also problems with that that I couldn't talk about in the questions afterwards if people are interested. And then the third problem is that the anonymity set is quite small. The current most popular mixer has about 200 deposits. At the time that I made the slides, I'm not sure how many it is now. But so this is an anonymity set of 200, which I suppose people don't think of when it's not my level of anonymity to say on one of 200. I think that that's a higher standard. So we need to be careful about the privacy guarantees that we tell people about when we discuss these systems. So OK, so let's talk about how can we fix some of these problems. So for example, how can we get more people to deposit into the mixer? Because that will make a lot of these problems a little bit less severe. Because 200 seems like a very small subset. So one way to do this is to increase people's confidence in the mixer, to increase confidence in the implementations and the crypto components. So that's one thing we could do. Another thing we could do is we could combine multiple mixers together. There's three mixers that are very similar. But there is also very compelling reasons why we should have mixers that are more different. Just from the security point of view, it would make sense to have mixers that are based upon different hash functions, different crypto components. So in the case that one of them fails, there's still other ones that are still working. For example, we find a bug in some of the crypto or something like that. And the third possible thing we can do is to perform an MPC trusted setup. So at the moment, all the mixers in deployment have no trusted setup. They have just a single, well, they have a trusted setup. But they just have a single party that you need to trust in order to be confident of the privacy of the coins. No, to be confident that they won't just one day steal all the money from the mixer, which is a possibility that we need to be careful about. And the fourth thing that we can do is we can integrate with wallets. Because a lot of people don't really worry about their privacy. And if we integrate with wallets, we can help provide these people privacy without them having to explicitly opt in. Because at the moment, you have to go through a series of technical steps that are kind of difficult to perform. Although the user experience of some of the mixers is very nice, it's still like extra work for people to do. So one idea that we were interested in promoting as the first step to integrate with wallets is to create new private address. So similar to create new private tab in browsers, we could have users, when they create their wallet, deposit some money into the mixer. And then later, they have the option to create a new private address where they would draw those ones to their new address. So the first solution is to do the, firstly, we should talk about the trusted setup. So at the moment, we're running a trusted setup. We have had eight participants so far. And we've been running it for about 14 days. I'd like to invite everyone here to participate in the trusted setup if they have time. So we're currently running phase one and we can run phase two, which is circuit specific later. But it's important to remember that both need to be, to contain a single honest participant in order for the resultant circuits to be secure. So here's some links about how you can join the trusted setup, but you can join this email group and share your desire to participate. Yeah, and the second thing we can do is we can audit the mixers. So MicroMixers being audited at the moment by ABDK Consulting. This is including an audit of Circumlib, which will also help some other mixers, specifically Tornado Cache, that use a bunch of components from Circumlib and their mixer. But we still need to audit the Circum compiler and the code for the MPC trusted setup. And both of these needs to be audited before we can start to be really confident about the security of our mixer. Also, we still use some experimental components. For example, the hash function is MIMC. And as far as I know, that's never been deployed before. But I'd like to thank Proof of Authority Network and the Ethereum Foundation for funding the audit of the mixer and the Circumlib components. Yeah, and in order to increase our confidence about the security of the hash functions, we're also announcing a bounty for collisions of the MIMC hash function. Yeah, so there's two rounds, or there's two difficulties. 80-bit security, if you find a collision, you get 10,000 US dollars. And if you break the 128-bit security, you get 20,000 US dollars. So you can make, you can... So here's the link to, with more information about the bounty. And I'd like to thank the Ethereum Foundation and Filecoin for contributing to the bounty on these hash functions. So please, attack it if you like. So there's also been a bunch of ideas that people have proposed for increasing the size of the anonymity set. And some of these, and here's some of these ideas that I think won't work. For example, there's this idea of having an interest rate or paying people to deposit into the mixer. So the idea here is that we have a mixer that has some money in it, and whenever someone deposits their money, we deposit it in the compound where we earn interest. And then we take that interest and we use that to pay other people to put their money into the mixer. Yeah, so it's like a reward to increase the size of the privacy pool. So this seems like an interesting idea, but it's been tried before. So Zcash had a similar idea where they would reward, they would force their miners to deposit their rewards into the privacy pool. And it turns out that this doesn't really work because the miners are only interested in mining Zcash. They're not interested in maintaining the privacy of their coins that they mined. So whenever a miner would mine coins into the privacy pool, they would always withdraw them to the same address. So I don't think that this, so I feel like in this situation, these two cases are quite similar and we should be careful about doing sort of experiments like this. And the reason for this, the reason why I think this will work is that the incentives here are misaligned. That the users want to use the privacy pool to get privacy, but the depositors, the interest or the reward seekers want to deposit to make the reward. But the depositors don't have any interest in maintaining privacy after they withdraw. And for that reason, I don't think, for that reason, I think it's pretty likely that they won't maintain their privacy after they withdraw because they have this capital that they want to invest and as soon as they withdraw, they'll want to put it some more else to make some more, to gain some more interest. But I'm open to changing my mind about this. If we see some experimental results or some use case where it works a little bit better. So also not to talk too much about mixers. Aztec are currently working on confidential transactions that they're starting their trusted setup soon. And here's a link if you want to participate in their trusted setup. And their roadmap includes full privacy as opposed to just confidential transactions. And they're also talking in the future, they're planning to use a universal trusted setup based on Plunk, which is pretty interesting and maybe that will be applicable to the broader privacy community. So what can we do in the future? It seems like we have these mixers that are like very functionally limited. What can we do to improve them? So one idea is that we should add more tokens to the mixer and add more denominations. But I kind of feel like the mixers at the moment are not really fit for this purpose because the privacy set is so limited that if you have people depositing into multiple privacy pools, it's very difficult to tell how many people deposited in Woodru. Oh no, it's very easy to tell how many people deposited in Woodru. And you need to have like a high liquidity in order to ensure privacy or to give people good privacy guarantees. So instead of this, I would propose that we should focus on making general privacy and private transactions. I see the mixers as like a pragmatic first step, but in the future we should try and make a privacy pool where people don't ever withdraw or don't withdraw for a long time. So in order to do that, yeah, so in order to do that, what kind of features should we provide? So firstly, we should provide private atomic swaps. I think that this makes a lot of sense on Ethereum because there's multiple tokens and unless we allow a way to convert between different tokens inside the private pool, then there is no way to join these anonymity sets together. So if we have this kind of atomic swaps inside the mixer, we'll be able to kind of trade between multiple different tokens. So this work has already been started. Some people are working on this. It's largely in the prototyping phase except for Ethereum nine and three quarters, which has, which is, well Ethereum nine and three quarters is a little bit different than what I was proposing. The first two links are a proposal for this and I know that zero pool is actively working on this. Yeah, and nine and three quarters Ethereum nine and three quarters is another interesting privacy private project. Yeah, okay, so conclusions about the mixer. So first of all, I think we should be really careful about the claims that we make about these systems. I feel like we have like a responsibility to sort of be honest and fair with other people when we talk about this and the privacy guarantees that we provide. Because like, maybe someone's life might depend on the security or the privacy that's provided by these mixers. And I think it's really important that we're upfront with people about the guarantees that they get. But the mixers that we have now are definitely better than what we had before. It definitely gives you a much higher level of privacy than we had before. And it's a pragmatic first step and it's a good step in a direction that we need to go. At the same time, these are very new tools. The snark programming snarks and building things with snarks has not been around for a very long time. And there's very little stuff in production. And for that reason, we need to be sort of very careful about using these. I predict that at least one snark app will be hacked before DEF CON next year. And I'm pretty confident about that. And also it's important to support the people who are building these applications and to understand if some sort of mistakes happen. Because the only way that we kind of improve and get better at this is by experimenting and making mistakes. So as well as being very clear with people about the limited privacy guarantees the mixers provide, we should also be very careful about kind of security and warning people to be very careful about using them. Okay, so other important things that are going on. Oh wow, okay, other important things that are going on is like private voting, collusion resistant voting, private resistant voting, censorship resistant, signaling, anonymous logins, anonymous styles. I'm sorry, I'm very close to my time as up. So we also need a lot of help. There's a lot of projects that I listed before that need to be worked on and built. So I'd like to invite people who are interested in working on this to join this telegram group where there's like a nice community of people working on things. Yeah, and I'd also like to thank all these people who contributed and sort of helped and did great work in this space this year. And last year and for a long time. So I'd like to thank all of them. And now I'm done. I have 17 seconds for questions. Thank you.