Lecture 17: Anonymity, Coinjoin and Signature Aggregation

• Download English-US transcript (PDF)

The following content is provided under a Creative Commons license. Your support will help MIT OpenCourseWare continue to offer high-quality educational resources for free.

To make a donation or to view additional materials from hundreds of MIT courses, visit MIT OpenCourseWare at ocw.mit.edu.

TADGE DRYJA: OK, so today I'll talk about CoinJoin, signature aggregation, well before that privacy, but privacy, CoinJoin, CoinShuffle, signature aggregation, and how these all connect.

It's a little bit of a leap to put these both in the same class, but not really. They're connected. But they are somewhat separate things. Today, I'll talk about privacy, CoinJoin, and various ways to do that, and then aggregate signatures, so Schnorr multi-signatures, and then aggregation, and attacks on the system.

OK, so the idea is privacy. And there's a bunch of terms we can use here, like anonymity and fungibility. And whatever the term for this, I don't need any, because I have nothing to hide.

So I don't need any privacy. I don't need any anonymity. I'm a good person. I don't break the law. I'm a boring guy. I don't do anything crazy.

I'm joking, but-- no, I'm not joking about being boring and not doing anything crazy.

That is actually pretty true. I mostly just work on this stuff.

But, yeah, that's a fairly common thing that people say. And the sort of clearest example is if you don't have anything to hide, you don't have any bitcoin, because literally, if you don't hide your private key, someone will just immediately take your bitcoin. So you do have secrets.

Your secret is your private key and your password. And if bitcoin and these types of systems really take off, potentially most of your money and a lot of your wealth could be tied up in what is a secret. So if you're not able to keep your secrets you could lose a lot of money. And larger, I sort of think that going forward-- this is very thought leader, future kind of thing.

But going forward, it seems like sort of all you have is your secrets. To the extent that you can own anything, the thing that you really have control of, you're like, OK, I got these things in my head that no one else knows. And maybe I own my car. But that's also sort of property rights, and legal systems, and maybe you can get repossessed.

Maybe I own this land. But, again, that's sort of this thing with the state. But I definitely really have the stuff in my head. And I can at least try to keep that.

So even if you think you have nothing to hide, you do have your private keys to hide. And that's sort of the obvious one. But larger, you want privacy because, in general, you don't want to reveal stuff about your coins. This is specific to bitcoin.

But my philosophy is I generally don't want to reveal stuff ever. And it's a lot of times at stores. I remember like Radio Shack, when it was still a thing when I was in high school, they would always ask you your phone number when you bought anything. And when I was little, I would just tell them my parents phone number at my house, because they asked.

But then once I was in college, I was like, wait, no I'm just going to make something up. And now I do that all the time. And it sometimes gets annoying for other people, because I would like go to a restaurant. They ask to put my name down. I'll say I'm Fred.

And then my other friend comes. And she was like, wait, you're not listed. And then she put her name in. I'm like, no, I'm already there. I'm Fred, and confusing things like that.

And I hope, and I sort of think that we're starting to see this kind of thing. Like, there's like Facebook hearings now. And people are all shocked that the company Facebook can read everyone's messages and see everything. Well, yeah, that's how it works. You're giving it all to their servers.

So I think it's starting to be, like where before companies would all be like, we just want to get all the user data possible, hopefully going forward data will be seen more as a liability and less as an asset. We're not there yet, because the companies who get sort of hacked and lose all this user data don't really get punished. So the Equifax thing, and all these different data breaches, there's not a ton of consequences yet.

Maybe there will be in the future. And maybe companies will start to not want all this data. But it's not as clean cut as, well, I didn't do anything wrong, so I don't want to hide anything.

Sort of default hide is my stance. And there's so many conflicting interests where every time you're on the websites, it's like, this website wants your location. And you're like, wait, how do I always disable that? I don't know the settings. But everyone wants this stuff.

So another reason, specifically in the case of money, is what's called fungibility. And it sounds like a weird word. It just means that every bitcoin is the same, or every dollar is the same.

So dollars are fungible, in that, physically, this $20 bill and this $20 bill are worth the same. And different denominations, so I will give you a 20 for two 10's. And anyone will do that. They're worth the same.

You don't have, well, this dollar is not worth quite as much. And sometimes that happens, even with dollar bills. Like in other countries, I think in the Philippines when the new $100 bills were issued that have the like little blue shiny thing, people didn't like them.

And people were like, no, I won't trade my old $100 bill for your new $100 bill. I don't trust this new one. Eventually, they got used to it.

But there's things, that even money can be not fungible. So the classic example is, OK, gold is fungible. Diamonds are not. Diamonds, I have little experience with diamonds they seem kind of silly, but they're all unique.

They've got different grades, and different cuts, and different sizes, and carrots, and little inclusions, and imperfections. And you've got this whole industry, where people with these little eye things look at the diamonds, and figure out, oh, this is a good one. And this one is so, so.

Whereas gold is, sort of also has essayists, and good delivery standards, and all these things for the gold bars. But it's much more of a standard. There's no judgment calls.

It's like, OK, this is gold. It's 99.95% pure. It weighs this much. This is how much it's worth. And you can chop gold up and-- sorry, divisibility is different than fungibility.

So if diamonds were all identical but not divisible, they could still maybe function as money. You would just need a lot of little diamonds. But the fact that gold is also divisible is really is a bonus. But the fungibility is really what's nice about it, and what makes it sort of used as money.

Currency's fungibility is actually-- I'm not a lawyer, but I hang out with them. It's enforced by the law itself. So there's an interesting case, Crawford v. The Royal Bank, in Scotland a couple hundred years ago, where there was a guy.

And he wrote his name on a 20 pound note. It's like Crawford. This is his money. And I think he was trying to mail it someone. He lost it.

Years later, the note shows up at a bank. And he's like, no, see that was my money.

I lost it. And he demands the money back.

I lost that money. This is my property. Give it back. It's got my name on it. I can prove it.

And then the court says no, no, no, that's not how money works. The bank has the money.

You can't just write your name on money and then have it be yours.

And this is very different from property. So if you steal a bicycle, and then you go go sell it on-- sorry, if someone steals a bicycle, sells it on Craigslist, and you buy it, and you didn't know, it was just, whatever, some guy's selling a bike on Craigslist. The police show up, and say, hey, that bicycle was stolen. We're taking it back.

And you're like, well, I didn't know. I just bought it on Craigslist. I paid a couple hundred bucks. Police are like, sorry, you're not in trouble. We're not going to charge you with a crime.

But these are stolen goods. We're taking them back, giving it to the rightful owner. And that's how the law works. You can try to complain about it, but they're taking it.

Money is different. If you're running a pizza store, someone comes in, gives you a 20, and buys a pizza, and then presumably eats it or whatever, and then a couple hours later the police come in and say, hey, that guy stole that $20 bill. And we're taking it back, and giving it to its rightful owner.

As the shopkeeper, you're like, I don't even know which $20 bill. Even though there are serial numbers, and the police could say, it was this $20 bill. We're taking it back, or returning it to the person he stole it from, legally they can't do that.

So this is from talking to lawyer people. So money's different. Money is not property, in the same sense. And the fungibility is enforced by the state.

And the divisibility and fungibility are enforced by the banks. The US dollar isn't worth anything.

The government and the banks don't have to give you anything for $1.

They used to sort of have this agreement, where, OK you give us $35. And we'll give you an ounce of gold. That agreement is longer is in place. But they do have to give you a change.

So they do have a duty where if you have a bunch of old, beatup $20 bills, the bank sort of does have to honor those and give you new $20 bills. And that's one of the things that the Bureau of Engraving and Printing, and the Fed, they all have this system. So they maintain the currency, in that sense.

So there's all these things that like you don't really think about in that how money operates. But fungibility, divisibility, those are really important. And most of it is enforced by the legal system.

Bitcoin does not have these legal protections. If want bitcoin to work, even where it's not legally recognized as being money, and our goal is to make it like money. So if they're stolen bitcoins, and you can trace them, the law enforcement can say, no, those bitcoins are stolen. We're recovering them.

So it's not treated as a currency. It's also not controlled as fungible. So in the absence of these sort of protections from the legal system, the software needs to help enforce the fungibility and divisibility of these things. So you can sort of treat the bitcoin software and ruleset as sort of a legal-- it's not a legal system.

But it's a system of rules that governs how the bitcoin transactions work. And so the fungibility has got to be in the system. Right So gold, for example, they don't have-- I don't want to say they don't have rules about gold. There's probably all sorts of old laws about gold.

But you don't really need a law enforcing the fungibility of gold, in that you can sort of melt it down, and it's untraceable. If you have this old gold coin from this empire, and this other gold coin from this empire, you melt the gold, you put it into a new coin, no one can tell. So, similarly, bitcoin needs to enforce fungibility that way.

OK, so any questions so far about these definitions or objections? I don't think bitcoin should be fungible.

AUDIENCE: So bitcoin is more like gold than diamonds. But, in a sense, right after your transaction happens, the probability that it-- say it's only one block deep. I don't think it's actually treated this way.

But someone could potentially, oh, I'll just consider that 90% of one bitcoin, because the probability or whatever-- TADGE DRYJA: They're not valued the same, because they haven't been fully confirmed.

Yeah, that's an interesting way to look at it. I'm not talking about sort of the time-based things here, because I guess in many cases you say, OK, I'm going to wait a day.

If it's got 100 confirmations, it's good. I'll consider it full value. But, yeah, there could be things where you look at the probability of a double spend, and then sort of assign value to it, increasing as time passes or something. That's sort of a unique thing to bitcoin, where the sort of finality of the transfer increases with time, which is not really the case with gold or dollars, where you're like, oh, I got it.

The fact that I've had it for one minute or 10 minutes doesn't really change that I've got it. So that's an interesting point. I'm not really addressing it here.

In this conversation, just assume you wait a day. And then all the probability of it going back is sort of negligible. But it's more the fungibility in that you can trace where it came from, and so assign values to different coins based on that.

So there's a real world example of this. I don't want to name specific names. But customer buys some coins. You go to exchange. You send them a couple hundred bucks.

You say, I want to buy some bitcoins. And the customer buys the bitcoins, and then transfers the coins to a betting shop, a betting company in the UK, and bets on a soccer game, for example. And he wins.

Great, so he bought a coin, sent it over to this UK gambling company, bet on a soccer game, or football I guess they call it, wins. Now, he has two coins. Transfers those two coins back to the US exchange.

And he wants to sell them. Before he can click sell, his account is closed. And the exchange website says, no, you violated our terms of service. We're closing your account.

Take your bitcoins. We've sent all your dollars back to your bank. Withdraw your bitcoins.

We're out.

This happens. So whether you agree with gambling being legal-- so in the UK, however, there's no law violated. And as a United States-- so this is sort of the gray area. I'm pretty sure that if I'm a US citizen, I take a plane over to London, I go to a-- I don't know the lingo, punters shop, betting shop? And then I bet on something, and I win.

Well, I'm pretty sure I have to pay capital gains on those winnings to the US, IRS. But I haven't broken a law, because I'm not in the US when I'm doing this thing. So, similarly, if casino gambling is illegal in Massachusetts, sort of, I can go to Las Vegas. I can gamble.

And I can come back to Massachusetts, and it's OK.

So this is probably a gray area. I don't know if there's actual court cases about this, where you're still sitting in Massachusetts at your computer. But you've sent your money to the United Kingdom. I don't know. I don't know of anyone who's gotten in trouble for this.

I don't know if there's been prosecution against UK betting shops for this kind of thing. But this happens. A lot of companies run betting shops like this.

But I have seen that US exchanges will shut down accounts because of this. And they say, look, you can buy bitcoins. But if you're using these to gamble, we don't want to get involved. It's just more risk for us.

And so they close the accounts. So the problem here is-- what did I say next? From the perspective of the legal system, for the user it's obviously a problem, because it's annoying.

What's the problem for bitcoin here? Why should bitcoin care about this, like as people working on bitcoin? Why do I care?

AUDIENCE: Two reasons. It's the usability of bitcoin, that bitcoin is not usable that's public and private. So that's the different between fiat currencies, that can be like government, state. But, two, is then what happens to these two bitcoins? Do they just get burned?

They're suspended until there's some decision as to what to happen. They're not owned by the exchange.

TADGE DRYJA: They gave them back. But, yeah, the real thing is these two bitcoins are sort of worth less than two other bitcoins. Now, you've got a sort of different value for these, where these two bitcoins are hot. And I need to get rid of them, and launder them, or something.

AUDIENCE: That happens with $100 bills too.

TADGE DRYJA: Really? OK, well.

AUDIENCE: I had a suitcase full of them in Bogota.

TADGE DRYJA: You had a suitcase full of hundreds, and you just walk to the Bank of America, and say, here, I want to deposit this, probably you've got some problems.

AUDIENCE: [INAUDIBLE] 1% into the banking system, to move it from fiat to digital, digital fiat.

TADGE DRYJA: Yeah, like actual physical currency notes.

AUDIENCE: That's not money laundering.

TADGE DRYJA: So, yeah, so now you've got the sort of money laundering that now people are going to try to do using bitcoin. It would be preferable if-- so the way that they can tell about this, is that people reuse addresses. Bitcoin is not inherently as fungible as, say, gold.

Dollar bills have these serial numbers. And I don't know to what extent people track these things. But bitcoins are much more like the dollar bills with serial numbers. And it's all on the internet. It's all on the computer. So it's really easy to track things this way.

AUDIENCE: [INAUDIBLE] could just simply transfer them to a new address, and no one would know it was still him until it was spent.

TADGE DRYJA: Well, yes and no. So you say, OK, I'm at the exchange. They've got a giant pool of addresses. I transfer to the casino.

And then the casino, in many of these cases, reuses addresses extensively. So it's really easy to see that this is the casino. And then from the casino, goes to the exchange again.

Exchange flags that and says, hey, we know where this came from.

Instead, you say, OK, I go to User A. And then I go to the exchange. In some cases, that might-- if their algorithm is, hey, just look at where it came from, sure. But if you say, wait, there was one output. This transaction is one input, one output.

So we know exactly where it came from. You can trace it back that way. So it depends.

Would the coins be worth less? This is un-money like.

And since legal tender is a whole other thing. And I'm pretty sure bitcoin will never be legal tender anywhere, in terms of debts can be settled. But at least fungibility, we want.

So we want to make bitcoin more money like, how do we fix this? The first, and simplest, and possibly the biggest is, address reuse. So if the casino keeps using the same address over and over, it's really obvious.

And so things like vanity addresses, so a lot of them will use vanity addresses. A vanity address is when you continually perform computations to try to get a human readable address. The addresses are random numbers.

So for example, I ain't rich. So Greg Maxwell has this address, which is 1gMaxwellbo8. So you can see that the first part of that addresses is Jim Maxwell.

And you get that just by continually attempting millions and millions, or billions, of different keys, and seeing which turn into the address you want. So people do that. People spend a lot of resources on making cool addresses.

And then the casino can say, OK, this is my address. But that really hurts the fungibility and privacy, because now it's clear when a customer sends to that address, everyone in the world can see. Yeah?

AUDIENCE: Does the casino just do this, because it's cool? Because it's not like it's easier to type in, because-- TADGE DRYJA: You still have the stuff. It's branding, vanity address, it cool I guess.

But, yeah, Satoshi Dice does this too, right? Or did.

So the Satoshi Dice address is-- yeah, it always starts with one dice. So branding, I guess, makes it easier for-- it does make it easier for people to recognize. If they have a list of the addresses, they're like, oh, that's the casino address. I want to deposit to the casino, and just copy and paste that in there.

So it does help usability. And that's one of the issues in bitcoin. It's like, having these giant, ugly addresses that you have to get right, and not sent to the wrong, it's not a great user experience kind of thing. So I can see that vanity addresses do improve the user experience a little bit.

But it really hurts the privacy of the system. And address reuse is a problem, because people keep using it. It looks cool. Also web explorers, so if you look at blockchain.info. This is advanced mode, enable, disable.

Even with advanced mode, it'll give you a link to the output. So no one is going to click that. Anyway, so the idea is this shows, oh, here's a transaction. It's coming from two addresses, sending to two addresses.

And it even gives you a helpful, hey, this is Greg Maxwell. And I'll give you a link to-- where does this link go? You're being redirected. OK, well, go for it. Gmax-- OK, so it's Greg's account on bitcoin talk. Interesting.

So you guys know enough about the system now, that this is not true. If you click on an address, and now it gives you all the transactions, way too many, that were involved in this.

But if you click on a transaction, it's not spending from addresses and to addresses.

It's spending from transaction outputs, and spending to addresses that can later be consumed.

So the way that web explorers-- and it'll show a balance. If I click on an address, it says, hey, here's the number of transactions involved. Here's the final balance. And you can look at the current balance, and things like that.

But that's not actually how the system works. And it hurts privacy and vulnerability, to have this idea of, oh, this is sort of my account. And it's got a balance that can increase and decrease, because then that implies that I'm going to keep using it. Whereas, really, if they're one-time use, that really makes it harder to trace things.

So another aspect that hurts this, if you want to trace things-- so if it's one input, one output, right here, it's real easy. But even if it's not one input, one output-- so, for example, imagine a transaction where the input has 10 coins in it. There's output a, which is one coin, output b, which is 8.9997 coins.

Which do you think is the change address? They're all different addresses. But OK, whoever is doing this, they're sending one coin. And the remainder, minus the fee, is this.

So it's often pretty clear, even though looking at it, all the addresses are different. OK, are any of these change addresses? Is it just a sending to b and c? Is it a sending to b, and back to a? Often, it's pretty easy to figure out.

And you're guessing. But you can get the guessing pretty good. OK, so what we're going to talk about now-- anonymity sets.

So bitcoin is not actually anonymous. There are sort of identities attached to these things, in that you have addresses. The addresses are not your name.

But you can think of them as a pseudonym. And you can create a bunch of pseudonyms.

But there are these keys. There are these publicly known addresses.

And so we want to expand an anonymity set. And so the idea of an anonymity set is, how many possible different identities could be the owner of these coins? And the idea of expanding your anonymity set-- so even if bitcoin were perfectly anonymous, in terms of the anonymity set was everyone who had Bitcoin, that's still actually not that many people.

So if you see a bitcoin, you're like, well, I don't know who owns it. But I know that the person who owns it, owns bitcoin. And, actually, there's not that many people who own bitcoin. So I've just eliminated 99% of the people, my suspects, just by doing that.

So just having more people using bitcoin makes it more anonymous, in that sense. If it's very niche kind of thing, and then the police say, OK, well whoever did this crime, they're a bitcoin user. Well, now you can find-- there's not that many bitcoin users. So you want to try to increase your anonymity set for a specific transaction.

So the traditional-- I don't want to say traditional-- the way you do this is basically money laundering.

It's a bitcoin mixer. And these mixers still exist. I'm pretty sure, right? They're still around?

They're still around. I don't know why. But a lot of times they use Tor. I mean, I know why. But it's like, there's so many better ways to do this.

So you've got coins at address A. And you say, OK, I'm going to send 10 coins to the mixer, which has address me. And then later, some different, not from that output, but somewhere else in this sort of giant mixer account, four coins get sent to address C, and six coins to address D. So you basically pool all the coins into this mixer, which uses lots of different addresses, and then split it up over time, different amounts.

And it gets really hard to figure out where the coins came from.

So your anonymity set is bigger. The problem is mixers were well. Potential anonymity set is all the other users of the mixer, if it's well designed. The problem, the mixers disappear with everyone's money, very consistently.

The mixers are certainly not publicly regulated companies. I'm pretty sure you couldn't do that. So they're just sort of these anonymous, like, hey, I'm a mixer, bitcoin cloud, or bitcoin fog, or whatever. And a lot of times they're on Tor. So you don't even know where the mixer exists. And you sort of hope for the best and send your money. Yeah?

AUDIENCE: Do they take a transaction fee?

TADGE DRYJA: Yes, of them take fees. The big fee is when they keep all your money and don't give it back. But a lot of times, they will take a small cut. But it's not actually hard.

The cost is pretty minimal. Need some kind of Tor service. And then you just have some software that just runs this, and allows deposits and withdrawals.

The conference in Puerto Rico, Financial Cryptos, there was a talk about a-- what was the word they used? Not traceable, a mixer that you could prove defrauded you. So you could have these proofs that, oh, I can prove that they stole my coins, which is I thought was kind of useless, because the whole idea is they're anonymous.

And maybe you can prove that they ripped you off. But they still ripped you off. OK, so then the better idea than a mixer is I taint rich was a blog post from Greg. That's why I've got this up.

In 2013, and it was kind of fun. Ever since I was a wee lad, I had a dream, a dream of being incorrectly assessed as impossibly rich by a braindead automated analysis. Now, with your help, I can be.

So he wanted to mix inputs from different people within the same transaction. So you could have two different people in the same transaction. And in bitcoin, this is secure, because the signature signs the whole transaction.

So you say, OK, I'm user A. I have my 10 coin input. I'll match up with user B, who's got his two coin input. And we both sign this whole transaction, which sends two coins to C, and 10 coins to D. So now, you can't trace where these coins went right. Right? Well, you sort of can.

But if you just look at the graph of transactions, it's not as obvious. So the first transaction is really fun. I remember seeing this.

So there's three inputs, 40,000 bitcoins, 0.1337 bitcoins, and 1 bitcoin from Greg, and then 40,000, and 31337, and then 0.82. For some reason, it was even more-- yeah, 40,000 bitcoins is pretty good today. It was no less impressive at the time in 2013, even though I guess it was only worth about half a million dollars at that time.

But it was like-- it was pretty cool. And then Greg was like, wow, I've never seen that much money. Yeah, so the guy who posted the 40,000 coins, he's called loaded. And nobody knows who he is. But he shows up from time to time, and has a lot of money.

So, yeah, then Greg made a transaction with Loaded. I've handled pricey assets before, the most I've ever moved on a single key press. So it's pretty cool. This was very manual.

That was on a message board, sort of goofing around. But there's no risk. You're not sending money to someone, and then getting it back. You're just saying, I'll sign off on this transaction. And then transactions are atomic.

You can't say, oh, I'm going to cut off this bottom part, and only have 10 coins going in, and two coins come up. The whole transaction is the thing that gets signed. OK, so what's the problem with this model?

Any way to get a mapping from C and D, to A and B? There's one really obvious one on this screen. It's an x, right? Yeah, well, gee, I think it's A goes to D, and B goes to C, because the amounts are completely different. And, actually, we'll talk about amounts next week.

But how about this? Well, you've got 10 coins coming in, two coins coming in here. And I've got address C, D, E, and F, 1, 7, 1, and 3. Better, maybe? No, nice try. You can still easily.

The 7 goes to the 10, the 7 to 3, the 1 and 1. I don't think there's any way it could be anything else. How about this?

Address C has two coins. Address D has two coins. Address E has eight coins. Well, now, that actually works, right? It's not clear if C is from A or B, same with D.

These two have some anonymity, in that you're not sure which user it's from. E, on the other hand, is obviously from A. But B's coins are now sort of-- the anonymity set has doubled.

You don't know whether it's C or D. B's address is now unclear.

So that's kind of cool. How do we scale this? Well, have more users, and a bigger anonymity set. So one issue with this is, as you scale to more users-- let's say you do 10 different users, where they all put in their inputs.

They all put in their set of outputs. And now, you've got this big transaction, where it's hard to tell what the mapping is. The problem, as you gain numbers of inputs, numbers of users, the users themselves know the mapping, because someone's actually doing the, I put in my thing, you put in yours.

So there's a user that knows the mapping. And they can leak that info. And that hurts the anonymity. So maybe just the transaction graph itself won't tell you, but somebody knows.

And they can reveal that at a later date. So that's not good. So there's a really cool protocol called CoinShuffle, so pre-CoinJoin messaging to shuffle the inputs and outputs.

And this allows you to have 10, 20, 30 different people doing it. And if at least two participants are honest, then the mapping cannot be determined. The way it works-- this is super quick, because I don't have time.

Everyone has their inputs that they want to put into the transaction. And they also have the output addresses that they want as their outputs. So they make a new set of public keys that they're not going to use on bitcoin at all.

They're just making public keys for encryption purposes for this game. And they also tell everyone, here's my inputs. My input is A. My input is B. So the inputs are known to the people participating.

And then the idea is, OK, I know everyone's publicly that they've given. So I encrypt my output. So I've got an input I've told everyone. I've got my output.

And I encrypt that, the address itself and the amount, with everyone's public keys sequentially.

So, for example, I use encryption on key C to encrypt the thing on encryption on key B, encrypt the encryption on key A of my output. And then I hand this to user A.

So this is like onion routing, sort of onion encryption, where you take a plaintext, encrypt it, encrypt it again, encrypt it again. So I receive these encrypted outputs. I shuffle them. I receive one from A, one from B, one from C.

Actually, I receive the whole set. I shuffle the order. And then I use my key to decrypt one layer. It's still going to be encrypted, because I just see, here's a bunch of encrypted data.

I decrypt it. It's still encrypted with the next person's key. And then I hand it to them, and they shuffle, and decrypt. So the final user gets the outputs.

And the final user-- so in this case, user C, can decrypt. And now, he's got my output.

But it's been shuffled around with everyone else's output, at every step of the way.

So they can't tell who's went to whom. And then they have this final transaction, which has all the outputs in some random order, because everyone contributed to randomizing the order of the outputs. So this is really cool.

As long as two parties are honest-- if there's only one honest party, it doesn't work, because then every dishonest party colludes, and says, well, we know everything but the honest party's output. So we can figure out which one it is. But if there's two users actually doing this, then you can't determine the order.

So that's pretty cool. I think it's being used for Join Market. Do they use something like this? I don't know.

So there's cool techniques for this kind of. Thing OK, real world, though, some people use this. Join Market exists. I don't know how popular it is.

Problem, which people use this. Who uses this? It's got a limited anonymity set of the people who really want anonymity, which is not the anonymity set the people who want anonymity want, which is kind of confusing. But the idea is, I don't want to just be in this group of people who want anonymity, because those are the people I don't want to be associated with.

I would rather associate myself with the people who don't particularly want anonymity. This is a big problem. People don't care about privacy. People don't want to do these kinds of things.

And this costs money too, in this case. If you're doing these transactions, this isn't really a payment. This is just superfluous transaction to turn your money around to get some more privacy. This is one of the big issues with, OK, we want anonymity.

But if anonymity is opt in, it's not very useful, because then it's sort of like Tor, where if I'm using Tor, everyone's like, why are you using Tor? And so at this point, encryption is now sort of ubiquitous. And it's like the standard. But yeah?

AUDIENCE: Given that most transactions happen on exchanges, why not just lobby a few exchanges to try and implement this?

TADGE DRYJA: Well, wait, most actual bitcoin transactions are in and out from exchanges?

I don't know-- AUDIENCE: If that's true.

TADGE DRYJA: There's a lot. But I don't know if it's a majority. I think it's a decent percentage. But I think it's less than half. But, yeah, there's a lot.

It'd be awesome. So exchanges are actually uniquely positioned, where something like CoinShuffle, you could really easily do an oblivious withdrawal. Where you say, I want to withdraw my coins. And I'm not going to tell you where to. But I'll give you this encrypted thing that gets shuffled around with different users.

And then at the end, I sign off on it. And the exchange can say, well, we're fulfilling all our customers' withdrawals. But we don't know where the coins are going. You could totally do that. That's not a conversation that happens at any exchange. Yeah?

AUDIENCE: I also think that the bulk of exchanges are now getting caught up in some regulatory, in Japan, soon to be in the US, for know your customer, anti-money laundering. So for the exchange business model, they're going to have to give this Coinbase to the FBI some data.

TADGE DRYJA: Yeah, and whether that data is, here is this user's name, and address, his house home address, and his social security number, and here's what he bought and sold.

Versus, does that also have, and here's where the addresses where he withdrew his coins to? I don't think the IRs-- the IRS thing, I think it was mostly we want to get people for not reporting their gains.

AUDIENCE: That's the IRS point, but the other part-- TADGE DRYJA: Right, FinCEN.

AUDIENCE: Financial Crimes Unit, FinCEN would want the addresses.

TADGE DRYJA: FinCEN would want to map bitcoin addresses to human names, so they could see who did what. IRS just wants to know who sold and didn't report gains. By the way, this weekend, if you sold any coins last year, you got to tell the IRS. I've actually got to pay a little bit of tax on that.

Yeah, so anonymity is tricky. Like, you could try to go through exchanges, probably not the best. They're not going to do it. It's hard to do even research on this kind of stuff when you're a company.

There's a lot of sort of chilling effects and stuff. That's sort of why I like working at MIT, in that if I want to research crazy anonymity stuff, totally fine. Whereas if I'm working at a VC-funded company in San Francisco, and I'm like, hey, we're making these anonymity protocols. Are you sure you want to do it?

It can be an awkward conversation, in some cases. So people don't care about privacy.

It's sort of an externality. If you say, I'm reusing addresses. But that only hurts my privacy.

That's actually not true. In the simplest sense, you're reducing the anonymity set for everyone else. So if I I say, OK, where are James' coins? Well, I know they're not at 1Gmaxwell909, because that's Greg Maxwell's coin.

So when you use publicly identifiable addresses, and vanity addresses, you're actually reducing the anonymity set for everyone else. It's sort of an externality, where the people who say, I don't care about privacy are not paying the cost of harming the people who do care about privacy. So this is a tricky problem.

And there's no solution. But one cool thing, one way forward, is, well, everyone likes cheaper transactions. Everyone likes saving money.

So can we make it cheaper to improve anonymity? And so privacy and scalability, in some cases, are at odds. So in things like ring signatures, which I don't think I have time to go-- but Monero is a sort of privacy focused currency that uses ring signatures where, where you can point to-- a ring signature is, I can point to two public keys.

And say, OK, there's public key A and public key B. I'm signing message M on one of those two public keys. But I'm not telling you which. And you can verify that, OK, one of these keys signed. But I don't know which.

And the signer had to have one of the private keys, or both. If you have both keys, you can obviously make a ring signature. It doesn't have to be two. It can 5, 10, whatever. You pick a bunch of public keys, sign with one of them.

So that's pretty cool. That expands the size of signatures, I believe, with like 0 of n.

So if you have 10 keys you're pointing to, and you make a signature on one of them, the signature actually gets bigger.

So for Monero, they use all these different systems. And scalability is one of the biggest problems with there-- I mean, it's a problem with bitcoin as well. It's a problem with everything.

But it's even worse in Monero because of the choices and the different algorithms they use. So in some cases, privacy and scalability are at odds. But in some cases, it works together, where you can say, we just want to have less information about these transactions. So if you have less information to store, there's less information to link the users to their coins.

So an idea here is aggregate signatures. So, currently, when you sign, you have this input.

And you say, OK, here's user's A signature, here's user's B signature. And you're doing this ineffective CoinJoin thing here.

The goal would be we want to aggregate these signatures. So we don't have a signature for this input. We just have a single signature on key C, which is just, somehow, the combination of A and B's signature.

And then you can save space, because there's only one signature that stays the same size, but still prove that both A-- so this is not a ring signature. This is aggregate is A and B both signed, and produced a single signature together. And that can validate the whole thing.

OK, so how can we make this signature? We know pub keys A and B. They're both signing the same message, which is really important. There's other terms for these things.

There's multi-signatures, aggregate signatures, key aggregation. And no one agrees on-- like, I've had discussions with people. And I'm like, wait, that's what you call it? I was calling it something else. And there's not really good terms for this.

But in this case, what we want is we're signing the same message. So that makes it easier.

We're not trying to combine different signatures on different messages from different pub keys and combine it to the same signature. That's even harder, although that is possible in some ways.

But in this case, A and B are signing the same message with their two different keys.

And they need one signature. And the signature is going to be R and S.

So the equation that we had, that we've done a couple of times, the signature is k, some random number, minus the hash of the message, and k times gr, times the private key. And to verify, r minus the hash of the message and r, times the public key. Now, if you share the private keys with each other, it's kind of easy.

Alice just say, here's my key, Bob. And then the Bob can compute everything. You can do that with ECSA. But you really don't want to share private keys, because as soon as you give someone else your private key, maybe they don't sign this aggregate signature of the thing you want to sign, they sign something else, giving them all the money. So you want to be involved in this process.

So the simplest sort of multi-signature system for Schnorr signatures-- first, you want to share an r value. So this r is also going to have to have contributions from both users.

Who comes up with what here? If c is the combination of both Alice and Bob's public key, the message we have already agreed on. But this r value is the question.

So the idea is, Alice comes up with k sub a, computes r sub a, and gives it to Bob.

Bob makes k sub b, computes r sub b, and gives that to Alice. Then both of them can say, OK, well, we know the real r that we're going to use for the signature is the sum of r sub a and r sub b.

Then, they want to compute their own s's. So for Alice, s sub a is going to be equal to k sub a, that only she knows. She shared r sub a, but not k sub a, with Bob. Minus the hash of the message, and this aggregate, this summed r, times her private key.

For Bob, it's s sub b, equals k sub b, minus the hash of the message, and r, times little be. And then they give each other a really-- only one party needs to do this, right? Either Alice gives s sub a to Bob, or Bob gives s sub a to Alice. But they don't have them both do it, because then the final step is you just add the s's.

So this aggregate s is s sub a, plus s sub b, which is k sub a, plus k sub b, minus the hash of m and r, times a, minus the hash of m and r, times b, which is, you can call this k. That's the discrete log of r, because they summed it. And then you can factor out the a and b here.

And so this is the sum of their private keys. This is the sum of their k values. And then this single verification step will work. And that works. Awesome. OK, questions about this?

Basically make sense? There's all sorts of minefield caveat sort of watch out things.

For example, if they learn your k value, they will learn your private key, once they get this. Normally, you make deterministic k values, where you compute k as the hash of your message being signed and your private key. That's dangerous to do in this case, because they might get a k value from you, and then give you a different r value, and get another k value, and find your private key.

So there's all sorts of watch out things. So the idea is, OK, now cool, we've got output, which needs a signature from a. We've got an output which needs a signature from b.

We'll use those as inputs, and just have this sum c signature. And that shows that both parties signed.

So we're good. Now, we have way less data. These signatures are like 65 bytes. So instead of having it twice, you just have one that covers the whole transaction. Great.

And it doesn't have to be two. You can see how this would extend to three, four, or five different people. They would all have to compute their own k value, give it to everyone else, everyone computes this combined r value, and then does their own s's, and then sums them all up. And this would work with any number of participants.

Problem-- you've got a bunch of coins, that 40,000 coins from before. And then one day, you see, wait, I'm user A. User B came up with a user A and B signature and sent it all to address E. I never signed anything. I didn't do this process with him.

How did he steal all my coins? This is bad. So any idea of how you could do this with the equations we?

OK, so what you do is you say, hey, here's key A on the network. And, normally, you see pub key hashes. But a lot of times you see pub keys. And, anyway, you definitely see the pub key once people try to spend it.

So maybe you have to do this quickly. But you can do this real quick. So you say, OK, I'm going to make Q, a random private key, compute q times G to be big Q. And then I'll compute key B, which is q minus A. Then I will send some coins to B.

And now, note that I don't know the private key for B. The private key for B is going to be this little q, minus little a. I don't know little a, so I don't know what little b is.

But that's OK. I don't send too many coins to key b. And, anyway, I'll get them back.

I don't know b. I can't sign with it.

However, I want to spend from b and a together. I don't know a little b. I don't little a.

I don't know the private key for either. But I do know the private key for both, which is sort of confusing.

But the idea is, well, C, is going to be a plus b, which is a, plus q minus a, which is just q. So in this case, I can observe a key, make this rogue key, and then spend from both of them, without knowing the actual key that I wanted to steal from. So this is a huge problem. You can't have this. This would make signature aggregation completely insecure. What are some ideas of how to fix that?

So the interesting thing is in all the literature about multi-signature, this problem sort of still persists. And the new papers about how to use this in bitcoin are the ones that are actually addressing it. So the general idea was, well, make b sign. Make b prove that he actually can sign with key b.

Before you start doing these things, have Alice and Bob talk to each other. And Bob says, OK, here's a signature with key b. And Alice says, OK, here's a signature with key a. And, now you've proven that they actually can sign, and they're not doing these kinds of rogue attacks.

So that's the straight straightforward way to do it, where, OK, if you don't know b and can't sign, we're not going to continue with this process. That's interactive, though.

So make b sign a message before combining keys. Easy, that's what people sort of thought about for years.

But the whole point here is to aggregate signatures. And so if you require b to create a signature and post it into the transaction, you've just eliminated all the gains, all the space saving, for this technique. So we can't have that. We want it to be non-interactive.

We want any existing keys to be usable in this system, without pre-committing to anything.

You can also make it interactive, where-- well, anyway, there's actually a better way to do it. You de-linearize the signatures. So you redefine the signatures.

You still send to, for example, key a or key b. Your outputs are still pub keys. But when you require a signature, you don't require a signature from that pub key. You require a signature from that pub key, times the hash of that pub key.

So you say, OK, I'm sending to a. But when normally I have sig a, signature from key a. Instead, I say, no, I want a signature from a, times the hash of a. So anyone who knows the private key for a will know the private key for this, because this is public.

Everyone can see what the hash of a is.

And then so it's just little a, times the has of little a. This is a scalar multiplication.

So the scalar multiplication works the same for the-- sorry, this is the point multiplication.

And it works the same for the scalar down here.

So this doesn't hurt. It doesn't make it any harder to sign. You just have to perform a hash operation and a multiplication, which is quick. But what it does is it prevents this kind of attack.

So instead of signing with a plus b, sign with a, times the hash of a, plus b times the hash of b. Since, in this case, in bitcoin, you can see what public keys are being signed and aggregated, so you say, OK, well I'm going to try to do this technique again. c is a, times the hash of a, plus b times the hash of b.

The private key is going to be a, times the hash of the pub key, plus little b times the hash of pub key big B. I know b, which is q minus a-- sorry, I don't know b. I know q. And I constructed sort of this b is q minus a. But I don't know it.

So c is now going to be a, times the hash of a, plus q minus a, times the hash of q minus a. That's what b is. I can't cancel out this little a anymore, because it's got a different coefficient. Maybe it's easier if you sort of move them on the other side.

I've now got these coefficients in front of my private keys that are not the same, and won't cancel out anymore.

Before, the system is times 1. So the idea was a, times 1, plus q minus a, times 1. Since the coefficients are the same, 1, I can factor them out, and now apply these, and remove the a.

So if the coefficients are the same-- if it was a, times the hash of a, plus q minus a times the hash of a, I'm good. I can still factor out that coefficient and cancel out a. But now, the coefficients are different. And so I can't do that subtraction. And now, I'm stuck. I cannot sign with this little c, just from knowing q. Questions about this?

AUDIENCE: So how do come up with q?

TADGE DRYJA: In this attack, q is just any random number. But the idea is here, q being any random number doesn't help you, because you've sent money to b. You're trying to sign with q minus a. But you don't actually know the private key, q minus a. So you're stuck.

Even if you did, in this case, it wouldn't help, because you still have that either.

So this prevents that kind of straightforward attack. You can't get rid of the a times h term.

This actually is not enough. There's a paper called Wagner, Wagner's paper, some guy at California, UC Berkeley, I think, a generalized birthday problem. And it's a hard paper to read. But if you're working on these kinds of things, it's a good paper to read, because it comes up again and again with these kinds of attacks.

Collisions-- I don't think we ever talked about. So the idea of colliding, for example, a hash function, or in this case a public key, usually it takes half the work that you-- the reason it's called a birthday paradox is because-- do people know this birthday thing. Like, how many people need to be in a room before two people have the same birthday?

And it's like 22 or something.

It's really low. And it's surprising, because you think, well, maybe 365 divided by 2, so like 180 or something. But it's actually 22, I think, because of the way like for every new person added, there's a possibility they collide with every already existing person's birthday.

And so the collisions are more common than you think. So in the case of colliding a hash function, even if the hash function is 2 to the 256 bits, you only need 2 of the 128 attempts to collide and find two that are the same. And that's if you store all the old hashes.

And so keep coming up with new ones after the square root of the number of attempts, you'll find it. And then there's some techniques with cycle finding, where you don't have to store them all, things like that. So usually, you think, OK, 2 to the n over 2 time to find a collision. But that's a collision between two things.

And Wagner's attack is sort of, yeah, find a and b, such that a equals b, kind of the normal collision. Now, find a0, a1, up to ai. So find i things on this side, and j things on this side, such that the sum of a equals the sum of b. And in the case of elliptic curve points, it would actually be the sum. You'd do addition.

In the case of hashes, it might be xor, or some other operation. But the idea is if you have a lot of different things that you can pick and choose on both sides, you can potentially find collisions with much less time. And in the case of these elliptic curve points, it probably would be practical. You'd need dozens, 20, 30, 40, different keys.

But you could potentially say, OK, there's a key with a lot of coins. I'm going to find a set of a whole bunch of keys, such that that I can cancel that key out, even with this multiplying by a different coefficient, because I've got so much search space. It's a cool paper. You should look through it, if you're interested.

But that's a problem. You can sort of make progress, is the basic idea. I can keep getting closer and closer to canceling this thing out.

So instead, we have this improved delinearization. And this is talked about in the paper from like January. You take the hash of all the keys concatenated together, in some specified order. So you sort the keys some way. And you say OK, z is the hash of a and b, or if there's more keys a, and b, and c, just all concatenated.

And then you sign with a, times the hash of z, and a 0, plus b times the hash of z, and a 1. So you make the coefficients distinct. But you also make the coefficients commit to every single part of the set. Every key in the set needs to be in this coefficient.

And the MuSig sort of explains why that works. So the attack in this case is, well, I've got these different coefficients. But the coefficient here only depends on this key here.

So maybe I can find a bunch of different keys with different coefficients, such that these coefficients will cancel out, or these coefficients will sum, or multiply, or sum up to hash of a. So it seems hard. I can't find different hashes that will equal the hash of a. That's a hash collision.

But if I have any number of different things, I may be able to. And so the idea is, if you do this, now every time I'm adding or removing a key from my attempt, I have to change z.

So I can't leave this here, and start adding things, and try to work on it that way, because every time I add a c or d, z changes.

And so I have to start over from scratch. So anyway, that's my general intuition of how the delinearization works for MuSig. And then, yeah, it used to be like z, and then put a in here, because now that makes it unique. But you can actually just number them.

You just need them to be distinct. And since it's hash, function just say like 0, 1, 2, 3, 4, is good enough. OK, any questions about this?

I realize it's kind of complicated, and the software is kind of crazy. But the idea is that it prevents a bunch of these attacks so that you can securely use aggregate signatures.

Questions?

And you wouldn't have to program it. Yeah so you could say, OK, it saves face. The first use case will be in single wallets. It's interactive. So you have to do that thing where I come up with different k values, I share the different r values. I come up with the s values. I add those up, sure.

If it's all doing it yourself, where it's just there happened to be two different pub keys that you control both of, you can basically skip all of that. And you can just say, no, I'm just going to add the two points here. And I'll use the same k value. That's just me.

So this happens a lot in bitcoin wallets, where you're making a transaction with multiple inputs. They're all controlled by you. But you might have two coins here, and three coins there, and you want to send someone four coins. So you've got to use both of these inputs.

Currently, in bitcoin you're going to have multiple signatures. With this new signature aggregation, you can say, OK, I'm picking these two inputs. I'm signing for all of them with a single signature. And in the case of it all being years, you don't even have to do the two operations and add them, because you know the all the keys. So that's going to be the first use case.

And that's much easier to program, because it's all just within the same computer. And this is easy. That's cool.

And then a cooler use is, OK, use it with CoinJoin, where users A, B, C, and D all contribute.

They all have an input with the same amount of coins, great. And they're doing CoinShuffle to shuffle the order of these outputs.

So A knows, oh, mine is G. But I have no idea about E, F, and H. I don't know the mapping other than my own. But, hey, my output is in there. So whatever everyone else is doing, I don't care.

But I'm good with this transaction. And they can contribute their own k value on their own s value. And then, finally, you put the signature at the bottom. And it verifies that all these participants have signed.

And this is really nice because it's smaller. This would be 250 bytes worth of signature data. Now, it's just 65 bytes sorts of signature data at the bottom. So you save on fees. You save on space.

Everyone likes this. Yeah, it's cheaper than a solo transaction. And so that potentially helps scalability and privacy, in that if people say, I want to do something cheaply, I will connect to other people and aggregate my signature with theirs.

And so we'd save some space and save some money. And maybe I don't really care about the anonymity thing. Maybe I'm entering into a transaction, and there's some people doing shady deals in this transaction. But I don't care.

My thing gets in and out. And I save money. So the extension of this would be, what if you had just one giant transaction in every block, which is all the inputs and all the outputs, and there's a single signature? That would be really cool.

There are techniques to do that. Maybe next time. So the issue is it's interactive, in that you have to know about all the other inputs and all the other outputs.

So if it were non-interactive, then I could say, oh, well there's this transaction where D is sending coins to H. And there's also this other transaction where C sounds going to G. And they've got their own signatures.

I'm not either of these people. I didn't do anything with these signatures. But if I could take those two things and combine the signature non-interactively, then I could just basically take all the transactions in my meme pool, squish them into one transaction with one signature, and put that in my block. That would be really cool.

But the issue there is, one, the signatures have to be interactive. And, two, they're on different messages. So in the case of C sending to G, it's a message of C to G. And then D sending to H, It's on that message.

There are techniques, though. So BLS signatures do allow you to do this, so non-interactive aggregation of signatures. Which would be really cool, because then a block would only need one signature. And then BLS signatures themselves are a single point, not a point in a scalar. So it would just be 32 bytes.

Well, you'd probably use a different curve. You'd have to. But, yeah, the idea of having these tiny signatures that's satisfy proof for the entire set is really cool.

So this is a cool idea. So you saying there isn't software? Or it's not on GitHub?

OK, so the idea is, there is a bunch of software for this that mostly SIPPA-- or Peter Wool, his name on the internet is SIPPA. And he told me what that stood for. And it was some like super cheesy thing he made when he was in middle school.

Anyway, he has been working on this kind of software. So has Greg, that guy who five years ago wrote about this stuff. A couple of people have been working on this.

It's not publicly available code, which is kind of weird. But the reason is that they're working on Schnorr signatures and aggregation. And it was on GitHub in like a branch of lib sec p, the repo they're using. And then all these altcoins were taking the code, and putting it into their altcoins, and saying, hey, we support Schnorr signatures.

So for example the rogue key attack, it was the simple version, which didn't have this multiplied by the hash of the pub key. And they were like, wait, no, don't, we're working on this software. But we know all of these problems with it.

You can't actually use this for signature aggregation. We're just sort of playing around, and trying different things. And so they actually pulled it from GitHub.

And so I have seen it. You can see the old stuff. Yeah, the three years ago stuff that doesn't have any of this delinearization, or this thing that prevent Wagner's attack, all of that stuff is not in there.

AUDIENCE: That's something that sounds really cool. But that's something [INAUDIBLE].

TADGE DRYJA: No that's not what they-- OK, maybe that's a cool attack. But they were like, oh, shoot, no. But it said in their repo, do not use this. This is research code.

Do not use this in production. There are known vulnerabilities.

But people are like, whatever, people didn't care. Well, yeah, there's some esoteric edge case vulnerability, but I'm going to solve that, because xyz. So they actually pulled the code.

They are working on the code. I mean, the code works. I've seen it. But they are very sort of like, we don't want to put it publicly until we're sort of saying, OK, here's our final version that we want to put in bitcoin, because they know as soon as they sort of put it out there for review, all these altcoins will take-- I mean, you've implemented this in-- yeah. Not in vertcoin, in crypto kernel. And you do use the u sig?

AUDIENCE: I will do now.

TADGE DRYJA: Oh, OK, cool, let me know. So they know that people are going to use this, because it's a cool signature scheme. And I've talked about this multiple times before.

Once you have this Schnorr signature equation, there's all these other cool things you can do with your addresses and things like that.

And so the idea here is scalability is one that, OK, now we can combine things, make it smaller. And also, we can hopefully help privacy this way, in that people who are not particularly concerned with their anonymity will say, yeah, I still want to use it, because I can save $1 on fees. So, yeah, I'll join this transaction with a bunch of other people.

And then you've got the people who actually want anonymity are like, great, these are exactly the people I want to be associated with, the people who don't particularly care about anonymity. So it seems like a win-win.

Right now, all the software requires a regular old signature. So, for example, if these are outputs that are currently being used, and you do this, I'd validate the output one at a time.

And I say, OK, I'm looking at this output, looking at this input, there's no signature at all, fail. OK, the whole transaction fails. So you need a new output type, which says, OK, I'm using this new aggregate signature. So, actually, look at all the inputs. Don't validate them at all, and just validate at the end at the bottom.

So that's going to be some different code. And you can't retroactively say, OK, all the existing outputs we can now spend with this new signature scheme. You can't really do that. So we'll have to make new addresses.

And the new addresses will be bc1v, instead of q, new address type. And then we send to that. And now, you're allowed to spend from it using aggregate signatures. So all that software is mostly there.

But it might take a while. You've got to get everyone on board. I'm curious to see what people will complain about. Segwit was a little bit more like, there's a lot to complain about.

Even I don't like parts of Segwit. There's a lot of parts I don't like and won't use.

But this seems like a sort of clear win, where it's like, great, you can aggregate signatures, do all these cool things. I'm guessing there will be people saying, this is bad. And saying, no, because Satoshi's vision is one signature, one input. A coin is a chain of signatures.

And this coin has no signatures.

I'm guessing. I don't know what'll happen. Or maybe it might be smooth, and everyone is sort of like, yeah, this is obviously better, great paper, great math, great idea. Let's all activate it and use bitcoin this way. Who knows?

So we'll see. It's pretty cool software, though. And you can use it in other projects. So Crypto Kernel is using Schnorr signatures, probably a bunch of different coins who are sort of more agile, in that it's easier to make changes, will probably start using this.

Ethereum is still ECDSA though, right? There's no coins that are actually implementing this yet. Monera uses ED25509, which is essentially a Schnorr signature. And I think Ripple can use ED25509. So there's some different schemes that are more similar to this, but still don't have the definitions for aggregation.

So, anyway, so this is cool stuff. Next time, I will talk about-- next one, I'm not looking forward to making slides, because it's like a really complicated one that I don't even understand. Like, I sort of get it, but it's like, wait, how? OK, but how to mix different amounts.

In this case, hey, it's great. But in many cases, you can see, I said the reason it doesn't work is because it's really obvious. But what if you could hide the amounts, but still enforce that the amounts were correct?

So that's the idea of confidential transactions, which I'll talk about next time. And then it leads to MimbleWimble, which is even more complicated. I'm not going to promise that I'll explain the whole thing. But I'll touch on the ideas.