>> Patrick Longa Pierola: Good afternoon everyone. Thanks for coming to this invited talk. It is my
pleasure to introduce Matthew Green. He is a professor at Johns Hopkins University. His main research
interests are on applied cryptography especially focusing on private to preserving cryptographic
protocols. Well, today he will be talking about Zerocoin. So please let’s welcome Matthew Green.
>> Matthew Green: Okay, thank you. So this is a talk on electronic cash. I subtitled it this sort of odd
subtitle. I think hopefully it will become clear what this is all about as I get a little deeper into the talk.
But this is some joint work with my grad students Ian Miers, and Christina Garman, as well as Avi Rubin
at Johns Hopkins. We’re going to be presenting this at Oakland in the next month, so, anyway.
There’s this really dorky intro to this talk I might skip by quickly. But I gave it to some bankers on
Monday and I wanted to have some kind of fake Econ or finance background to this, so I’m going to give
my little spiel. In the beginning of this kind of exercise you know as I was making these slides and went
and I typed into Google and then later Bing because I was going to be here, you know some basic
questions about what are, what is money? This is what Bing tells me money is. Money is basically bank
notes, dollar bills, gold. It’s sort of not a very useful definition except for the fact that it tells me that
money is referred to as dosh in greenbacks which I thought was kind of cool, but not a particularly useful
thing.
So I wanted to get a slightly better definition so I was getting ready to go to the library and find an Econ
textbook maybe and get some primary source. But then I realized the library like 15 minutes away and it
was kind of hot. So I went to Wikipedia and I got the basic definition which tells us that money is a
medium of exchange, a unit of account, and a store of value, which to me thinking about this as an
engineer tells me that it has to meet some of these basic properties. It has to be, you know there has to
be some limited quantity of money, meaning you just can’t make it arbitrarily. It has to be widely
accepted by a group of people for some reason. Then more importantly this medium of exchange idea
means it has to be easy for people to transfer from one person to another.
Okay, so this is what money looks like to most people. This is what money looks like in science fiction
where you have things like the Hitchhikers Guide to the Galaxy. I thought it was a great example of a
medium of exchange that was not easy to exchange. This is called the Ningy it’s a coin that is sixty-eight
hundred miles across and made out of rubber. So there’s all kinds of different examples of money in the
world and in the literature.
So the problem were going to address here is a little bit more concrete. We’re going to look at the
problem of building electronic money. Again, a lot of these things are probably things that you’ve all
thought about in the past. But when you think about how do you build electronic money you kind of
arriving at two possible directions. One is very difficult if you go down that direction and the other is
actually very easy. The very difficult one is to sort of take the idea that money as we think of it today is
essentially information. It’s ink written on a piece of paper with a serial number for example. The
analogy there in the computer and network world is it’s a file. So we’ll just translate this into a file and
then we’ll use computer networks to exchange it.
Of course you’ve all probably thought about this for at least a few minutes and you know that this is a
terrible idea. That all kinds of bad things will happen to you when you start trying to exchange money
like this, not least of which is that the difference between me handing you a twenty dollar bill and me
sending you a electronic twenty dollar bill is at the end of the first transaction I no longer have the
twenty dollar bill which clearly is not going to be the case with electronic money. So this turned out to
be possible but very difficult.
Much more obvious approach is just stop trying to treat things as traditional money and just do what all
modern banks do, which is create a centralized ledger that just says Alice has fifty dollars, Bob has sixty
dollars, Charlie has ten dollars. Whenever somebody wants to transfer money from one to the other
just subtract something from one account and add something to the other account. This approach
when you think about it is essentially when you move it to a digital model is the basis for all of the
money that we really use today with a few exceptions. All the way down from the Federal Reserve, to
credit cards, even to these you know little cash out tickets that you get when you go to a slot machine in
a casino. Somebody is maintaining a database somewhere that has amounts. It’s highly, highly
centralized.
So the problems with this approach are obvious. I mean they’re problems to me at least. The biggest
one is that you need to trust somebody to be your bank and that person is going to have to be
centralized. You’re going to have to have one of those people or maybe a small number of people who
work together to be your bank. There are so many different things that can happen, obviously if they’re
someone at the level of like the Federal Reserve or a currency issuer they can just go bust. So not only
are they creating the money but then they stop backing the money and it goes away. Maybe at a lower
level we’re much more use to the things like this, for example banks going out of business we don’t
panic about that very much in modern economies because we have legal and regulatory backstops to
this but it does happen and it happens actually surprisingly often. So this is kind of an issue.
Before I get to privacy, the other thing that I would mention here is that yes we’re use to things failing.
But when you think about the problem with requiring a central bank the real issue is not that it will fail
it’s that nobody will bother to set one up in the first place, because you won’t be able to find somebody
who’s going to take on that role. So for every bank that’s failed there have been a hundred people who
probably could’ve used a bank but just weren’t able to get it together to find a person to fill that role in
the first place.
The other problem that you get in these centralized account-based currency systems is a privacy issue.
Which is that of course your credit card number, credit card company sees every transaction you make,
everything you buy, everybody you interact with. All of that information gets kept. It’s available to law
enforcement, it’s available to marketing people, and who knows what goes on, you know who knows
how secure these systems are. So they could leak out later.
I was talking to Arvins Norian I think is how you pronounce his name. He suggested that there was kind
of this Zooko’s triangle of what an ideal currency should be. He was saying that well it’s kind of a
triangle and at the three points of the triangle you have the notion that a perfect electronic currency
would be completely decentralized. You wouldn’t have to have a bank. On the other point you would
have that it’s secure which encompasses all the things you need for money like you can’t counterfeit it
and you can use it properly. On the third point you would have privacy that you can use it anonymously
and you wouldn’t have to worry about people tracking your transactions. Then he said to me you know
isn’t there some folklore result that this is impossible. So I went and I looked on the internet and I
couldn’t find that folklore result but I’m just going to go ahead and put this up here anyway because I
think it’s a useful way of thinking about things.
Can we build an ideal currency that meets all three of these goals simultaneously? Which brings us to a
currency that’s gotten very popular over the past few years, and that’s Bitcoin, how many of you guys
know how Bitcoin works? Okay, so how many of you guys like could sit down right here and explain to
me how the Bitcoin block chain works?
>>: Need a bigger whiteboard.
>> Matthew Green: Okay, ha, ha.
>>: Yeah.
>> Matthew Green: So Bitcoin, before I go on this sign I found this on the front door of the University of
Maryland Computer Science Department. This is how you know you’re entering a Computer Science
Department and not say like a Political Science Department. So this was there but this was during the,
when it was two hundred and fifty dollars for a single Bitcoin phase a few weeks ago. So Bitcoin is an
electronic decentralized currency. It was proposed back in, I think, two thousand eight by a guy, or a
group of guys for all we know, or a group of girls named Satoshi Nakamoto. Nobody knows who this
Nakamoto person is because they only interacted electronically and sort of anonymously with
everybody else.
It was proposed as a paper but it was also given as a real practical implementation with software. You
can see their citations in the paper and it really is clearly an extension of some previous systems that
existed, one is b-money and the other is something called bit gold that had a lot of the features that
Bitcoin has today. But not all of them there in one package and Bitcoin kind of polished that up and got
everything together and made it all work.
So the basic notion behind Bitcoin is that it’s a way for a bunch of people to get together and without
having a single trusted party allow for the creation of currency, the exchange and transfer of currency,
and to do this all in a completely peer-to-peer setting where it all works, as long as most of the peers or
a good chunk of the peers are behaving honestly, or some definition of honestly.
The really amazing thing about Bitcoin which takes it away from just being, you know kind of a, some
goofball on the internet proposed this idea, is that people actually value this Bitcoin stuff for real
money. I don’t know why. But when I wrote this, which is a few days ago the total market
capitalization, meaning the value at least at the current price of Bitcoin of the entire economy was one
point three eight billion dollars. Now admittedly that’s down from two point two five billion dollars
which is what it was two weeks before. But it seems to have value and you can actually buy things with
Bitcoin which is pretty surprising.
So I’m going to give the world’s quickest explanation without computers of kind of how you might build
something like Bitcoin. I’m going to do through this quickly. So, yeah, I was trying to find alternative clip
art so this is our Alice. Okay, so I want you to start just from the assumption that we have some mass,
master bank. We’re going to get rid of this bank in the end but just imagine that we have some bank
that is issuing a cashier’s check and the cashier’s check belongs to Alice. Everybody trusts this bank and
so we can know that Alice really has this money just by looking at this check.
Okay, so Alice has a problem which is that Alice wants to give some money to Bob. Alice could obviously
go and cash the check or deposit it and write another check. But that would require a lot of time and
difficulty. So really what Alice wants to do is just take this check as is and transfer the money directly
over to Bob. Well, an easy way to do that for Alice is just to flip the check over and on the back do this
thing that we’ve all done at least at one point in our lives just sign the check over. Say pay this check to
the order of Bob and then put a signature on, right below that which authenticates it. Now anybody
who gets this check from Bob can look at the front, say I trust this, flip it over. Say okay this is a valid
signature therefore Bob really owns this check now. So we can move forward with this to another
person. So Bob can now pay Charlie just by appending a little bit more information and then signing it.
So now we have a mechanism by which we can transfer these kinds of files or digital tokens from one
person to another. So the question is how do we make this electronic and how do we make it secure?
Well the first thing you obviously will observe is that we shouldn’t use handwritten signatures. What
we’ll do is we will actually replace Alice’s name with Alice’s public key. We will simply use digital
signatures to authenticate these transfers. So now the check is a file, the file says Alice has this thing, if
we trust the original file then we can simply chain on ownership transfers by using digital signatures in a
pretty obvious way.
The problem is that this gets us back to this double spending problem that we originally had. Which is of
course now Alice can take that check, make two copies of it, send one to Bob, send one to Charlie, they
both think that they’ve got the same amount of money except that Alice has now doubled his or her
amount of money. If Alice really takes this to an extreme she can do this, or he can do this a thousand
times and then you end up with a currency that doesn’t work. So how do we solve this? Well the simple
answer is we go back to our centralized database idea. We have a central database that simply keeps
track of all the spending that’s occurred on the network. So every time Alice transfers to Bob that item
gets registered in the database. Bob can check that this has never been transferred before therefore
there’s no double spending and so on. We know how to do this with databases, it’s easy but the
problem is we don’t want to do it this way because we’ll lose all of our decentralized capability if we go
this way.
The way that Bitcoin addresses this is to use a kind of a distributed consensus approach. So instead of
having a central database that keeps this information we divide this database up and have many, many
different parties at a peer-to-peer network replicate the same information. So that’s at least a start.
That means that we don’t have a central database that’s trusted to store it. But now we have other
problems. How do we make sure that everybody has the same view of this database? How do we
update this database in a way that makes sense? So one thing that we can do at least to try to tie the
database together, one of the things I should mention is the database just for convenience is going to be
broken up into blocks each of which consist of a number of transactions. Now the blocks are ordered,
the transactions inside of the blocks don’t have to be. So basically what Bob can do if there’s a transfer
is he can say, okay I want to put a transfer in this block, has, you know that same money been spent in a
previous block, and that’s what allows him to detect double spending.
So the question is how do we tie these different blocks together? Well, that’s easily done too. We can
use hash chaining. We can simply put at the bottom of each block a hash of that block and all previous
blocks, which means that if I trust block N then I will know that all previous blocks are somehow
consistent with that block and everybody else, if we all agree on block N then we all agree on the
previous blocks.
Okay so a harder problem is how do we trust this distributed network to group up and add transactions
to this ledger, to this block chain? Well the way we do it is first we set up a distributed broadcast
network essentially. Where any party who wants to can broadcast out that they’re doing a transaction
that they want to put a transaction on to the block chain. Now we can simply appoint a central party to
be the one who gets to add things onto the chain and we all trust that person. But that means that
party is again another place where the system can break down because they could selectively add
transactions or do all kinds of things to hurt the network.
So instead what we want to do is distribute the ability to add blocks to the chain. The way we do that is
we have all of the different nodes compete with each other in a kind of a lottery where only one node is
going to win that lottery for each given time period. That node is the one that then gets to output a
block which will of course be chained onto the end of this. Everybody who sees that node will then trust
that to be the most recent node in the block chain and then the process repeats. So the particular
lottery that we’re going to use is called a proof of work. The proof of work that’s used in Bitcoin is a
very simple one. What we do is we hash the block which includes, you know another hash of all
previous blocks. We essentially construct a block such that the hash of that block ends with a certain
number of zero bits. Now the number of bits is adjustable, it could be one, it could be thirty, it could be
anything. That’s a dial that gets adjusted over time. But what this means is that at any given time
period you have a bunch of different nodes all in its network putting together what they think should be
the new block that’s added to the system. Then they compete to be the first one to find a proof of work
to find a block that satisfies this particular condition, which is it hashes to this structured value. The
minute that somebody finds that value that particular block they output it to the whole network.
Everybody can immediately check that that’s a consistent block, they make sure the transactions are
okay, the hash chain checks out, and if all of those conditions are met they drop whatever they were
working on and they adopt that to be their new block. So then they try to chain on the next block on
top of that and this happens every few minutes in Bitcoin.
The idea behind this is if we assume that everybody in the network has roughly the same computational
power that should, because of this process there’s essentially a notch that can be incremented inside of
these blocks. That’s what allows you to try many different values. We can assume that the person who
wins this will hop around the network. Now obviously not everybody in the network has the same
computational power. Some people will be able to hash more, compute more hashes in the given time
period so there’s going to be a bit of a race to see who can deploy more computational power. But if we
assume that hopefully a majority of the, at least the computational cycles in the network are controlled
by honest parties, a lot of big assumptions in here.
We can hope that most of the time honest nodes will be winning this competition which means that the
damage that a bad node can do is pretty limited. Because anything bad that they do will either be
detected by the honest nodes and rejected or you know if they’re just blocking transactions well, my
transaction might get blocked by this bad node but the next honest node who gets it will not be trying to
keep me out of the block chain.
So this is a very quick description of kind of how Bitcoin works, doesn’t cover all the possibilities that can
come up, and I recommend you read the paper or the papers that are on this if you want to know more.
But does this kind of make sense for the moment? Yes?
>>: Can you say a little bit about how race commissions are handled?
>> Matthew Green: Oh gosh, Oh gosh, not well.
>>: [inaudible] almost exactly the same then…
>> Matthew Green: So what will happen is that, gosh, in that case you can actually have situations with
a view of the network splits. You have one group of nodes who believes this is the most current block.
This is a very unlikely case. It could happen. This is the most current block and this other block is the
most current block. So then the network is now split. What’s going to happen now is a competition is
going to begin were each half of the network starts to try and chain a new block onto the rest. There is
a merge protocol where ultimately, hopefully the network will, doesn’t always work very well but
ultimately one of those chains will get longer. The idea is that the nodes are supposed to look at all the
chains that are out there. When they see a fork like that they will ultimately resolve on the chain that is
longest and drop the one that is shortest. I can’t tell you if it actually works but this is the…
>>: That’s what happened…
>>: About a month or two ago, right?
>> Matthew Green: Yes.
>>: Maybe a few months ago a split happened…
>> Matthew Green: Yeah…
>>: And they did resolve it, so.
>> Matthew Green: Well, yeah…
>>: I’m not saying it was awesome but I mean it was figured out.
>> Matthew Green: So there are two kinds of splits. There are the kind that happen because
everybody’s participating properly and then it’s just bad luck, right, and that just happens. The other
kind of split is where there’s a bug in one half of the software and they disagree on what makes a valid
block. That’s what happened is there was a version zero point seven and a version zero point eight of
the client and they disagreed about how many transactions could be in a block which caused a bunch of
the nodes to say well this block is totally invalid it has too many transactions because it was being made
by newer software. Then the network diverged and what actually happened was the Bitcoin people got
up and they jumped up and down and they said everybody stop using that software. Then ultimately
one of the things got, so it was not a great case. But this is a case where the protocol didn’t work
because there was actually bug, a bug in the client.
>>: [inaudible] third class [indiscernible] where an adversary finds a coin and sits on it until the first sign
of somebody broadcasting new coin and then broadcasts to [indiscernible] create a collision, a race
collision.
>> Matthew Green: Yeah, so there are definitely things that can happen like that. However, you have to
be careful about that because if you miss that timing…
>>: Yeah, but [inaudible]…
>> Matthew Green: First of all it’s hard to do it, if you miss that timing then you’re hosed and you may
not be able to get the correct block in the next time…
>>: If my goal is to upset Bitcoin…
>> Matthew Green: Yes.
>>: Rather than to just get a coin.
>> Matthew Green: Yeah, there are many ways you could probably upset Bitcoin. I’m definitely not
going to say that this is a perfect system. But the amazing thing is despite all that it’s managed to work
in a very adversarial setting for several years now, so. Yeah?
>>: What’s used as the broadcast channel?
>> Matthew Green: It’s a peer-to-peer kind of fill flood network essentially where you put stuff on there
and it gets sent out to all the other nodes. I’m not too familiar with the details of that channel. But it
goes out and then everybody gets to see it and then they decide these nodes that make the blocks
themselves are called miners. There’s a reason they’re called miners aside from doing the actual work
of solving these proofs of work there’s a reason that they do this work. I’m, I assume most of you know
when you actually solve a block you get rewards. One of the rewards is that you are entitled to mint
yourself a brand new twenty-five Bitcoins. So what happens is in addition to doing the transactions you
gathered up off the network you get to make one more transaction that says I assign myself twenty-five
Bitcoins. Then of course later on you can spend that Bitcoin. So that’s how currency is created. The
currency starts essentially at zero and then overtime you make more and more of it and you fill up the
system.
Now this reward has gone down. It started at fifty, it’s now at twenty-five, it’s going to go down to
twelve and half in a few years, and ultimately according to the protocol as written today it will go down
to zero. At that point a second mechanism of incentive is supposed to take over. Which is that nodes
can also when you send out a transaction you can include what’s essentially a tip, like a transaction fee.
You can say the node that puts us into a block will get thirty-five cents or thirty-five; you know
hundredths of a Bitcoin or something like that. Then nodes can basically look and miners can say well
you know maybe that transactions not giving me enough of a tip I’m not going to bother to put it in my
block. So you end up with this kind of market solution where I put out nodes that have low transaction
fees, nobody includes them, I put them out with higher transaction fees they get included very quickly,
and we’ll see if that works. It’s very hard there are a million game theory papers to be written on how
Bitcoin works because who knows what the incentives are right now. They’re probably all misaligned
but it works. Yes?
>>: So it’s [indiscernible] centralized [indiscernible] that he used the software or [indiscernible].
>> Matthew Green: Well, yeah, I mean there is this Bitcoin Foundation which does make some of the
clients and then they make decisions about the protocol. But there are lots of different
implementations so it’s not really completely centralized. The first version was but after that people
have made Python implementations, Java implementations. So it’s not completely centralized and you
have the ability to dump it. That leads to the software compatibility issues so that’s kind of risky. But
that part I’m not too worried about, maybe.
Okay, so let’s look at the Bitcoin, the triangle that we had before and see where Bitcoin falls into it.
Okay, so first of all it’s decentralized for some reasonable definition of decentralized, it definitely meets
that criteria. It’s secure with the exception of certain things that we might hope are not going to happen
to the block chain. It’s reasonably secure and it seems to work but is it private? Do we have any kind of
privacy guarantees in this network? Well, not really and the reason that Bitcoin is not private and kind
of very famously not private is that the block chain is, you know both its best feature and its Achilles
heel in terms of privacy. It has every single one of these transactions that has to be replicated and
available to the public. I have to be able to startup a Bitcoin client and be able to download this all from
another node, which means that the history of every single thing that’s ever happened in Bitcoin is
entombed inside of this block chain.
Now there’s some mitigating factors, one of which is that we don’t use names, it’s not Alice and Bob it’s
public key A and public key B, and moreover there’s no need to actually register these public keys with
the network you just generate them and start using them. So I could make a thousand of them, I could
make ten thousand of them. So what this really is is a pseudonym system not an anonymous system.
So is that good or bad? Can we break the privacy in these things? The answer is yeah probably because
we know how to extract information from graphs like this. There’s some really stupid things that
happen now that are just trivially bad.
So let me give you an example. I went on Twitter and I said because I’m giving this talk I want
somebody, please give me a few cents, give me a few satoshi worth, a satoshi is a Bitcoin divided by
eight decimal places or something. Just send me a few so that I can show what it looked like to get a
Bitcoin. So someone actually sent me sixty dollars which is awesome. But then this person sent me
twelve cents which was cool to. Let me show you…
[laughter]
>> Matthew Green: Let me show you what’s happening here. So Bitcoin addresses are actually the hash
of a public key so that’s what these numbers are here. I know it’s a little hard to see back there. But
this is the sender address, ends in MvM. Here we have the amount so this is a previous transaction that
was worth two dollars and forty-three cents, this has been converted into dollars. So the previous
transaction was worth two dollars and forty-three cents. This person wants to send me and I’m the guy
who ends with CkW, twelve cents of that. So that means that there’s two dollars and twenty-five cents
left over, where is that money going to go? Well the person could send it to somebody else who
happens; you know they happen to owe someone else two dollars and twenty-five cents. But most
likely they’re going to send it back to themselves.
Well the way most Bitcoin clients work today is to create privacy they automatically generate new public
keys all the time, so you may have dozens of public keys and the idea is this is good for you, you have
lots of these sorts of identities. The problem with a lot of Bitcoin clients is they don’t realize that when
you do a transaction like this where you’re sending somebody some money and you have change left
over you probably shouldn’t send the change to one of the other public keys that is supposed to be the
key that’s, you know your other pseudonym that’s protecting your identity. Because this binds those
keys together and shows me these two identities are the same person. So here I can poke and say this is
me. This person who has a totally different ID is almost certainly the person who sent me that money.
From here forevermore I know that these two identities are the same. So if the first one sends some
money to his grandmother and the other does a drug deal then I know that, you know they’re the same
people. So that‘s kind of worrisome.
Maybe we can fix that but it turns out that even if you kind of fix a paper over some of these bugs a lot
of people are now looking at this problem and saying how do we get information out of Bitcoin? There
was at least two papers in Financial Crypto two thousand thirteen and these are kind of the beginning
works, I think. There are going to be more, some people have done other work like tracing batches of
stolen Bitcoins throughout the network and done very well at figuring out what happened to them after
they were stolen.
This one is the reason that I gave a subtitle in my talk. So a few days ago somebody on the internet, this
guy Sergio Lerner went through the historical block chain data. He was not looking at transactions that
people were making, he was looking at miners and how well they were doing and making money early
on in the, in the evolution of Bitcoin. So Bitcoin really started out around January of two thousand nine.
This data goes through January of two thousand ten. Each of these dots on the screen represents one
miner making fifty Bitcoins, succeeding in getting a block in getting fifty Bitcoins. Now you notice that
some of them are red and some of them are black.
Anyone know what the black ones are? Okay, so the black ones are, well let’s see, they’re a single
mining rig and we know this because they actually each of the Bitcoin blocks includes a nonce. That
nonce field increments and so we can see that these are linked, they’re increasing at the same rate. We
can see that these are the same person succeeding and, you know mining block, each time fifty Bitcoins.
Did I mention that Bitcoins are currently worth over a hundred bucks? So this person is making fifty
Bitcoins each time they do this and they’re making a lot of them.
Much more interesting is that the, this black chain here starts at the very first Bitcoin block. So this
person is Satoshi Nakamoto. This person is the guy who authored or guys who authored Bitcoin. You
can see what they’re doing is they’re mining some Bitcoin, rebooting their computer, mining some
Bitcoin, rebooting their computer, and so on. Now how many, in dollars how many Bitcoin are
represented on this graph right now? Any guess at how rich this guy is now, at least if you believe the
current price of Bitcoin?
>>: [indiscernible] millions.
>> Matthew Green: A hundred million dollars just in this graph so far. So he’s a very rich guy but here’s
the crazy thing, none of this Bitcoin has ever been spent. This guy disappeared in two thousand eleven
or so, has never been heard from since, and if this is him he’s either dead or maybe he lost his wallet
which means he can’t spend it, or else he’s waiting out there with his hundreds of millions of dollars and
just going to see what happens. But let’s say you’re this guy and you want to spend your money, how
do you do it? The minute you go and you start to cash in some of these Bitcoins everybody’s going to
know who you are and they’re going to be at your door asking for money, or whatever it is that people
do when you have a hundred million dollars in a crazy crypto currency. So he has no really good way of
getting this money out at least without revealing himself. So that’s, you know, we need anonymity for a
whole bunch of reasons, this being a particularly extreme one.
Okay, sorry this is not too helpful. Okay, alright, so I’ve covered a lot of, sorry was there? So, I’ve
covered a lot of stuff and I haven’t actually gotten to the technical content of this talk. But let’s just give
a couple of more things you need to know before we go forward. So what privacy solutions are in
existence today for Bitcoin? Well, one solution is be careful which means get better clients that don’t,
you know link your keys together. This is the current way that the Bitcoin Foundation people are going
is just trying to avoid these trivial mistakes. But that’s not going to be enough. It’s not going to be
enough because the current attacks that we know on privacy are all passive attacks. You think about
active attacks where somebody puts marked Bitcoins into the network it’s going to be much worse.
Another solution is to use something called a laundry service. A laundry service is exactly what you guys
think it is, it’s a mix where you get a bunch of people together, they put their coins together, the laundry
service randomizes them, and then hands out the coins, and we all hope that the trail goes dead
because you can’t deanonymize the eight people who got together and did this. But in reality it’s
probably not going to work very well, at least with the trusted mixes that exist today because you don’t
know if they’re doing it right, they’re, you have to trust them. You don’t know if you’re going to get your
money back and the volume is pretty low, so not great solutions.
The other solution which is the classic solution is we all implement, you know e-Cash. Let’s, we have this
great e-Cash system. Let’s get David Chaum out here. Let’s get him to start up, you know DigiCash
again and what he’ll do is he’ll set up a server and it will issue blind signatures and, you know I know
that people here know a lot about this, and Microsoft might be in a great position to do this. Fine, so
you do all this but again this is not consistent with the Bitcoin network model because again all of these
systems are based on blind signatures, and blind signatures implies a signer, and a signer implies
something central. You might use threshold cryptography to distribute that a little bit but let’s, you
know it’s not going to work. So that’s not such a great solution either.
So again the triangle doesn’t work so well for the decentralization. So I have until about two twenty or
so and then plus questions or?
>> Patrick Longa Pierola: [inaudible] forty-five minutes.
>> Matthew Green: Okay, alright I’m shooting for forty-five minutes so if I end early that’s what it will
be. Okay so this is a new approach. So we spent a little bit of time thinking how do you add
cryptographic e-Cash, real cryptographic e-Cash to Bitcoin without adding trusted parties, or doing crazy
things? How do you just do it with the existing system? Well we came up with this thing called
Zerocoin. Zerocoin uses some actually pretty standard techniques in crypto. It’s based on a technique,
now I say it’s based on a technique that was originally introduced by Sander and Ta-shma. We did not
know this until a week before we submitted the paper. So we had never heard of this technique. We
came up with an approach and it seemed great and then we found out that there was some similarities
in an older paper by Sander and Ta-shma. But they had two problems, one of which is that they didn’t
have Bitcoin. The other one is that they actually had a very inefficient construction that would not have
been realizable.
So what we have is this new protocol which is actually implemented into Bitcoin really at the protocol
level, does not require a trusted party just changes to all the Bitcoin clients that are out there. It uses,
what it does basically is it doesn’t create a fully, full e-Cash system, instead it creates what we call a
decentralized laundry. The idea is I can take real Bitcoins, I can transfer them into the Zerocoin thing
and I can pull back Bitcoins with exactly the same property you’d expect from a laundry, except that we
don’t have to have a laundry doing that work.
The only thing that our protocol requires beyond the crypto, I’ll get to explain what that means. But the
only thing that we need as an assumption is we need the existence of a trusted, trustworthy, append
only transaction log. Wonderfully it turns out that Bitcoin gives us a transaction log essentially for free.
We can just leverage the Bitcoin block chain.
So here’s the intuition behind how Zerocoin works all using very standard components. So first of all
Zerocoins themselves are obviously just information, they’re numbers. The first thing we do to make a
Zerocoin is we pick a random serial number which is just a large number. Then we use a commitment
scheme with some parameters and I’ll come back to where those come from in a second. But we use
just a standard commitment scheme to commit to that serial number. So now we have this
commitment, there’s nothing computationally hard in making this so they’re not really worth anything
at this point. You don’t want to go spending them because anyone can make them in a fraction of a
second.
What makes these things have value is the fact that you have to put them on the block chain. You’re not
going to just be allowed to put them on the block chain for any reason at all. In order to be allowed to
put one Zerocoin on to the block chain you have to spend a Bitcoin. The denomination here is
essentially fixed; all Zerocoins are worth one Bitcoin. Could be a hundred Bitcoins just, we pick one
Bitcoin for this example. So you introduce a transaction that says it’s just like a traditional Bitcoin
transaction, it says I have some previous Bitcoins from this source and I’m going to instead of giving an
output, instead of saying it goes to this person I’m just going to attach a blob of data, pretty small blob
of data, and that goes onto the block chain.
Now I have a Zerocoin. No the information that I keep private here is two things; one is obviously the
serial number itself. It’s just a commitment that I put up and of course I also keep the randomness that I
used in making that commitment. That becomes my trap door essentially when I want to go spend that
Zerocoin again. Now how do I get these back? Well the first thing that I’m going to do is at some later
point, maybe a hundred blocks later I’m going to redeem this using a different transaction. What I’m
going to do first is I’m going to form this transaction by just including the serial number that I generated
in the, when I made the Bitcoin, so that’s simple enough.
Then I’m going to give a proof. The proof is going to tell me two things; it’s going to tell anybody who
verifies the non-interactive proof, it’s going to tell people first of all this serial number, actually, sorry.
Let’s try again, so it’s going to tell first of all I know a Zerocoin that is on the block chain. Everybody has
a consistent view of the block chain so I know one of these things, that’s easy. Then it’s going to say I
also know the randomness that causes that Zerocoin commitment to open to the serial number I just
gave you, it’s very simple.
When I give you that proof I also say, and by the way I would like you to now deliver me one Bitcoin to
an address, another Bitcoin wallet, another Bitcoin identity of my choice. Hopefully it’s a new Bitcoin
identity and not linked in any way to the previous one. So it’s a laundry, I’ve just gotten one Bitcoin
back. Now the question is where do the Bitcoins come from and where do they go? The answer to that
is actually really simple. What happens is that whenever I redeem a Zerocoin remember every time I
put one of these things in the Bitcoin that I used to create it just sits there on the block chain, it’s not
going anywhere. So I take one Bitcoin, I introduce a transaction that says this Bitcoin that I have; that I
control is now going essentially into a kind of an escrow pool. What that means is now nobody, there’s
no semantic, there’s nothing you can introduce that allows somebody else to spend it. It is now sort of
locked up in the block chain. Unless they introduce another message that allows them to take back one
of those Bitcoins that was locked up in the block chain. Of course that is the Zerocoin spend transaction
with that proof.
When they give that proof they’re allowed to go through the entire block chain, find some other
Zerocoin that was created and identify, it could be created by some other party, and they say okay I
want those Bitcoins back, and they can just pick one at random. Does all this make sense? I’m not sure
if my hand waving is helping or hurting. Okay, good, yes?
>>: What’s the complexity of randomness? I guess what I’m asking is how, what would stop someone
from brute forcing that unique randomness?
>> Matthew Green: Okay, it’s a very, it’s a long number.
>>: Oh.
>> Matthew Green: It’s an element in; you know it’s the exponent in a [indiscernible] group. It’s a big
number.
>>: Okay.
>> Matthew Green: And it’s adjustable obviously. You can make the security level higher or lower
depending on how you configure the parameters. Okay, so you have this thing and so you’re able to
take back these things. Now obviously the next step is just to take that proof, that non-interactive proof
and make it a non-interactive zero knowledge proof. Which means all we’re proving is these two
statements and there’s no actual way for me to link the specific spend transactions to the mint
transaction that created it. So now we kind of get this, you know we’re creating the equivalent of kind
of an ideal laundry. Which gives us the same guarantees, not perfect anonymity guarantees obviously,
but, yes?
>>: Doesn’t something, the proof have to have a freshness to where also that the random number is not
one of the ones in previous proof?
>> Matthew Green: So that actually is not part of the proof. Once we’ve said, you know this is the serial
number and this is a valid serial number then the semantics of the transaction do actually, I’m sorry I
should have mentioned that you would of course in verifying this check that that serial number has not
appeared in a previous spent transaction. So what we’re doing here is proving that the serial number is
a legitimate Zerocoin serial number. That’s with the zero knowledge proof proves. Then it’s just a
question of making sure that serial number has only been seen once and it’s not a double spend. So,
yes, I think you’re saying the same thing. But it’s not part of the zero knowledge proof of course.
>>: [inaudible] if it’s not zero knowledge isn’t it linkable then?
>> Matthew Green: The serial number is not because the serial number is never revealed. We have this
commitment to a serial number. We never reveal the randomness, we prove knowledge of the
randomness, and so now as long as everything works the commitment is binding and the zero
knowledge proof works. Then we know that you can’t double spend, obviously, you know with all but
negligible probability. Then you adjust how strong you want that to be.
Okay, so that’s the basic protocol. Yes?
>>: So what you’re proving is actually the, this commitment that you know of being one of, all of the
[indiscernible]?
>> Matthew Green: Yes, yes, that’s essentially it so. I’ll get to the details of that which will involve
accumulators. But that’s right, so we assume that when I do this proof I have a view of all previous
transactions including all Zerocoins thus far made. I’m proving that I know one of them and I know the
opening to that particular one. So, yeah again, you can then ask, well what is the anonymity that gives
me? That answer is more complicated because of course if you’re the only person putting a Zerocoin in
the block chain it gives you no anonymity. If there are attack scenarios where somebody malicious puts
a lot of them on but is trying to deanonymize you, but you can’t really do much better than that. These
are kind of just basic limitations of an anonymous kind of laundry system.
Okay, so zero knowledge proof. I don’t even know why I have a citation to Goldwasser; Micali for zero
knowledge, but whatever, so we do. Okay, so, I’m just think, okay so this is kind of the stuff that I just
said. So the trick is how do we do this proof efficiently? What primitives do we use, how do we actually
tackle this together? Obviously we can do this. It goes without saying that, you know we can prove
anything, but anything in MP. But how do we do this efficiently?
So what you might think of is you might think of using some kind of standard Schnorr type proof which
allows you to do ore proofs. You could do something like this. You could say go through the entire
block chain; identify all of the Zerocoins that have appeared they’re just commitments up until this
point. Then you say, okay we’ll prove knowledge that we have a C such that C is equal to C one, or C is
equal to C two. I can’t tell you how many papers I reviewed that had proofs like this in there. They’re
like it’s an efficient proof but it’s not an efficient proof. It’s linear in N which is maybe a million
Zerocoins that have been minted in the past. You’re not going to fit this proof into the block chain.
So another approach is that what you can do is something it’s, you know a pretty old technique we use,
it’s a very old technique, we use an accumulator. What we do is we go through, before we do this proof
we use a one way accumulator to just gather up all those coins, instead of doing this ore proof we stick
all of those coins, these commitments into the accumulator and now we have the single accumulator of
value, this accumulated thing, this root. Then what we do is we generate a witness for our specific, for
membership of our specific Zerocoin and it turns out that it’s much easier to do this.
Now I wasn’t sure what audience I was going to be speaking to so I’m assuming that most of you guys
know quite a lot about accumulators. But the example that was actually given in older work was the,
you know Merkle Hash Tree where you just basically, you know put the coins down at the leaves, you
hash them up into an accumulator and then you have this nice kind of log N proof of membership.
That’s great in the sense that, well it’s great for a bunch of reasons, except that it’s really terrible if you
have to do a zero knowledge proof. Because as we know with possibly some exceptions it’s very hard to
do this kind of hash tree proof efficiently. I suppose you could use something like a Peterson Hash or
something like that. Maybe that would be possible but I don’t know how to do it very efficiently.
Fortunately, we have some very efficient accumulators. So let’s just, before I get there actually let me
mention one thing. We need an accumulator and there are lots of accumulators out there. We need
one that has a particular property, which is that when I do the accumulation anybody else should be
able to verify that I’ve done that accumulation properly. There are some accumulators where you can
only do the accumulation if you know a trap door for the accumulator. That’s not going to work very
well because who’s going to hold that trap door?
So we need something that’s kind of publically computable or at very least publically verifiable. There
are a few of these Merkle trees would count but they don’t have the sufficient zero knowledge proof.
So what do we use? Well, we have the, you know, we have this Strong RSA Accumulator. There’s some
bilinear ones too but they actually are not, for other technical reasons particularly good for this
application.
So what we use in our construction is we use the Strong RSA Accumulator which was by Benaloh and de
Mare, which basically is a very simple accumulator. You pick, it does require a trusted setup. You need
this modulus, this N equals P times Q. But you never need the P and the Q again, you can throw them
away. So we can have some trusted party come and generate these things and then we can shoot them,
and then we have just N.
Okay, so now what we do to accumulate, well we just also pick this value U and accumulation is simply
just repeated exponentiation. Computing a witness is basically just doing the same thing but omitting
the value that we want to prove membership of from the list of things that we’re exponentiating, and
then verification is just, you know verifying that this thing raised to the value that we want to prove
membership of is equal to the accumulator value.
It’s a great thing. It’s great for a whole bunch of reasons. One of the reasons it’s great is that Camenisch
and Lysyanskaya in two thousand one made some small changes to the Benaloh and de Mare
accumulator and they were able to show a very efficient zero knowledge proof, which is what we use in
our protocol. The only modification that you have to make here is that you have to make each of these
C values be a prime, not a big deal, okay.
Alright, so here is Zerocoin minting and use in a nutshell. It’s pretty straightforward. What we do is we
first generate a random serial number S which is, you know sum value in ZQ or Q is the order of the
group. We do a standard Peterson commitment with sum randomness R. The only thing that we do is
once we’ve done this Peterson commitment we check to see if the result is prime, if it’s not a prime we
throw it away, we pick a new serial, new randomness, and we start over again. So ultimately this make
take a few iterations but ultimately we wind up with a commitment C that is a prime or at least with
high probability is a prime. We keep S, we keep the commitment, randomness R, and that’s our trap
door for spending this thing.
Ultimately when we want to spend this we go through and we collect all of those C values from
everybody on the block chain, including ours, and we accumulate them all, and we compute a witness,
and then we execute the standard, we reveal S, we prove knowledge of the witness using the Camenisch
and Lysyanskaya proof. Then we also do a separate proof that shows that we know the commitment
randomness. Unfortunately and this is kind of the part that stinks about this, to do this we need to do a
double discrete logarithm proof. That makes it much more expensive than other Schnorr type proofs
would normally be if we didn’t have that double discrete log. So the cost of our proof for reasonable
parameters is about forty kilobytes, which stinks. It could be better, so there are actually some
techniques to shrink that down. But this is probably the big weakness of this system.
Yes?
>>: [inaudible] accumulate all your other clients.
>>: Yeah.
>> Matthew Green: You would think it would be wouldn’t you?
>>: Yeah.
>> Matthew Green: But it’s not.
>>: Okay.
>> Matthew Green: And the reason is that, first of all it’s actually not that expensive period. But it turns
out that this accumulator is incrementally computable. So if I compute the accumulator on let’s say the
set of coins up until time one and then somebody adds another block of, you know a hundred
transactions, I can just take that check point, that accumulator from here put on those hundred
transactions, and then compute another accumulator check point which is what we call it. So essentially
we also modified the client, the miners, to as part of the protocol computer the accumulator as they go
and do it for us. So actually that work is just shunted into the network. We do have to check it, people
have to verify, multiple nodes will have to verify that the accumulator being computed is valid. But
that’s not the end of the world because; you know there’s only a few hundred transactions per block so
it’s not a ton of computational work. So actually that’s great.
So we can get rid of all the work in, not all the work, but we can amortize that work in the, in computing
the accumulator, which turned out to be fairly pricey.
>>: [inaudible]
>> Matthew Green: Yeah?
>>: This is going to be a silly question.
>> Matthew Green: Yeah.
>>: Excuse me, so the prime [indiscernible], what size are you aiming for? Does it matter, is in any
prime number…
>> Matthew Green: It’s…
>>: Or do you have [indiscernible] size?
>> Matthew Green: We’ve been shooting; we actually did different sizes. We have like thousand
twenty-four, two thousand forty-eight, three thousand seventy-two bit.
>>: Okay.
>> Matthew Green: Yeah, so you have to adjust, you have to adjust the actual security level because
since it’s, has, you’re kind of reducing the space of commitments, it weakens it a bit. But only, but not
by, you know, there’s a weakening so you have to sort of dial up your security…
>>: [inaudible], so given there’s a somewhat arbitrariness I guess to the [indiscernible] to get your prime
number C.
>> Matthew Green: U-huh.
>>: And you got, like how long does it take to get that?
>> Matthew Green: I’ll show you in a sec…
>>: Okay…
>> Matthew Green: We have real number so…
>>: Okay, I know I was curious…
>> Matthew Green: It actually is more expensive than you’d think, but, you know it’s not that bad.
>>: [inaudible]
>> Matthew Green: Yeah, no it’s not. I mean when I say more expensive I’m talking like a second or
two, not like two hours and thirty minutes, so, yeah that’s an issue.
>>: [inaudible]
>> Matthew Green: Okay, yeah, so this is the question you just asked. Obviously we have some
optimizations in here; we can do this incremental computation of the accumulator. Another thing that
we can do is because this proof happens to be one of these, it’s an iterative proof where what we have
to do is we, the more executions you do on verification the more convinced you are that this is a secure
proof of knowledge. You don’t have to do them all. If you do half of them, you know for example let’s
say the proof, the guarantee is that with, you know you can forge a proof or given an invalid proof with
one over two to the eighty probability. Well if you do half the executions you might only be assured of
one of two to the forty.
So you could do something where individual nodes will each verify different parts of the proof. There
are different kinds of optimizations you can do to kind of reduce the complexity of verifying the proof.
So things like that will work. Yes?
>>: Can you say a bit why the body of pairings are committed to, can be used…
>> Matthew Green: Yeah, no I want it to be, I want it to be. So there are two problems with the, that
accumulator, one is an efficiency problem. So the, remember that we have to be able to do the
accumulation without a trap door. So the accumulators we have in pairings are very efficient if you have
a trap door. They can be done without a trap door but then what you have to do is you have to reveal
public parameters that are essentially linear in the size of the number of elements you’re going to
accumulate. So if you’re going to accumulate a million coins the parameters are going to be essentially a
million group elements in size.
Maybe that’s not so big a deal you could do windowing where you have maybe multiple accumulators
kind of computed and overlapping windows. You could find some engineering solution to this but that’s
an efficiency issue. Whatever, it’s just; it’s just an efficiency issue there. The real problem we have is
that what we need to do is this kind of double discreet logarithm proof where I need to be able to, so
what we do here is we are essentially accumulating integers. Those integers are commitments. There’s
actually no reason we couldn’t do the same thing except that what we’d have to do is we’d have to
crank up the order of the bilinear group to make it large enough that we could commit to, you know.
So, here’s the thing. So what we ideally want to do is commit, do the Peterson commitment in an
elliptic curve. So we have a nice small or bilinear group. Then we’d want to commit, we’d want to
accumulate those group elements that are the output of the Peterson commitment. The problem is the
accumulators don’t work on group elements, they work on integers. That turned out to be a technical
problem that might be something you can get around but we could not see a, kind of an easy way to do
it.
So you can accumulate integers and then you could do maybe commitments over, you know a ring or
something like that, an integer ring and you could just deal with them that way like we do here. But
then you have to adjust the bilinear group size. So you have a bilinear group of a very large order to
avoid, you know field based solvers that would, does any of what I’m saying make sense? It all makes
sense in my head. I’m not sure that moving my hands rapidly makes it any clearer to you but, you know
we kind of went through all of these different solutions and this one seemed like the most efficient. It
can be done in bilinear groups.
What we really want is the ability to commit to a value in a bilinear group and then accumulate those
group elements. Problem is we can’t do that because as far as I know there’s actually an impossibility
result that says you can’t have an efficient accumulator over group elements. You can have an efficient,
for example hash function that takes in group elements and is, you know actually does this as a set of
algebraic operations and outputs a hash result that is smaller than the inputs. I think that also applies to
accumulators. Any of that…
>>: Roughly.
>> Matthew Green: Roughly, I know…
>>: [inaudible]
>> Matthew Green: I spent a lot of time trying to figure out those…
>>: Because I see…
>> Matthew Green: Yeah.
>>: That you commit, you actually commit the exponent.
>> Matthew Green: Yes.
>>: [indiscernible]
>> Matthew Green: Yes.
>>: And it’s the same for [indiscernible] pairings that commit that which one so commits a, not to
[indiscernible].
>> Matthew Green: Right, if we could just commit, if we could just, but then we have to accumulate,
those things are public. So we have to accumulate these public values.
>>: Yeah.
>> Matthew Green: So I’m not really sure, you know with a commitment here…
>>: Yeah, but you can also commit zero values…
>> Matthew Green: Okay…
>>: [inaudible]
>> Matthew Green: I want to talk to you after this, so…
>>: They don’t have to be public, right.
>> Matthew Green: Okay, no I really do because I’m not completely understanding and if there is a
solution I want to know about it because we have an implementation of this and if we can make it more
efficient in any way I’d like to be able to do it. So, yeah, let’s talk after this.
Okay, so there are a bunch of optimizations. I now I’m keeping you guys late so, alright. I wanted to
show you what performance looks like. So this is performance. These three algorithms, this one over
here is the minting, you can see it’s actually very expensive in the sense that it takes almost a second to
mint a coin. This is at the thousand twenty-four bit size. It’s, over here, yeah, I’m not sure why those
are the same actually but for whatever reason in our implementation it takes under a second to mint
the coins regardless of the size, that that is a little weird.
To spend them is actually very efficient because all we have to do essentially is create this proof, it’s very
efficient. To verify them takes more time depending on the size. But to verify them is actually not
terribly, terribly bad here in this one. So this is actually verifying that the proof is correct. So that’s, it’s
not a terribly inefficient thing. The problem is not computational cost on these proofs. The problem
unfortunately is really the size of the proofs. This is where you get into the, the issue that the thousand
twenty-four bit size proof ends up with being somewhere between forty and forty-five kilobytes in size
and it goes up to about fifty kilobytes as you get larger.
Now we’ve done a lot of optimization. This is not; you know you’d think that you would get like three
times the size if you went to a larger modulus. But what we’re actually doing is we are changing some of
the parameters. We’re moving over into groups that are more efficient and doing some of our work
there. So that lets us be more efficient. Yes?
>>: [inaudible] security level…
>> Matthew Green: Well, you know…
>>: It’s Strong RSA, right?
>> Matthew Green: It’s Strong RSA and also we’re making some adjustments based on the fact that it’s
prime. So I’m not actually sure what the answer is on that so. Yeah, I’m not…
>>: So what’s the size of the other group? So this ten twenty-four is the accumulator modulus?
>> Matthew Green: Yes.
>>: And then there’s the group where the commitments are?
>> Matthew Green: Right, so we use, oh god, I have to look at the paper again to remind myself. But
we use multiple groups; we use one group that is where we put the commitments that are the coin. We
use one group for the accumulator. Then we use a third group when we do the proof we actually
transition things over into another group that happens to be a little bit smaller. The groups where we
can we use Schnorr groups where we have, you know a relatively large P and a much smaller Q or order
of the group so that we can kind of make things very, very efficient that way. So, and again I don’t
remember, we have, there’s a section in the paper that talks about all the parameter details we worked
out. As I’m sitting here right now I can’t remember them all. So I don’t want to tell you something
wrong.
Alright, so this is the upshot. I can take Bitcoins, I can turn them into Zerocoins, I can redeem them, and
ideally nobody with the exception of educated guessing will be able to link them. So in the couple of
minutes that I have left I want to skip this and I want to talk about some extensions that are not in our
paper but we think are just kind of nice, maybe obvious, maybe not so obvious kind of extensions that
we think are cool.
So one thing we don’t do is we don’t have a value associated with these coins, or rather I should say
every Zerocoin is worth the same amount of money. That makes sense from a privacy perspective
because you don’t want to have somebody getting a two dollar and thirty-one cent Zerocoin and then
spending a two dollar and thirty-one cent Zeriocoin and they you have privacy problems. However, you
could if you wanted to make this an extension. These are commitments. You can put anything you want
into these commitments. They could be vector commitments, you could add, you know just an amount
in satoshi of how much this thing is worth. Then what you could do is you could make this divisible.
The way you make it divisible is you simply add new transactions to the block chain. So I have an initial
Zerocoin that I place in that’s work a dollar. Then later on I want to split this into two fifty cent
Zerocoins. I don’t need to do zero knowledge proofs for this I just insert a new transaction that
essentially creates two new commitments, and then reveals the commitment randomness. Don’t even
need to do zero knowledge proof. Just say hey this is linked to this previous Zerocoin and I want to split
it up, and here’s the commitment randomness that allows me to do it. All of a sudden now I have two
fifty cent Zerocoins and then later on when I do the proof I will have to prove value as well. But that’s
not, that’s pretty trivial to do with these proofs. So you can do lots of kind of obvious stuff like adding
parameters to these coins.
>>: [inaudible] anonymously if you want.
>> Matthew Green: Oh, absolutely you could throw zero knowledge proof that just shows that they sum
to one Zerocoin and then just show that this other thing, yeah, exactly, all that’s doable. So that’s
simple. Here’s something that we have a paper in submission we think is cool. I’m trying to convince
other people it’s cool.
E-Cash is essentially very closely related to anonymous credentials. Anonymous credential systems,
what I love anonymous credential systems, I think we can all agree that so far they’ve had a little trouble
getting off the ground. One of the reasons is that right now to run an anonymous credential system you
have the problem of creating identity in the first place. Somebody has to authorize your identity and
your attributes. But then you have to have this credential issuer which has to always be online to, you
know issue credentials and to handle. Then you have to get everybody to use this thing.
There are a lot of applications where all of that work is very heavy. You don’t want to have to deal with
all that and maybe there are peer-to-peer networks that want to do some kind of anonymous assertion,
maybe that I’m a trustworthy node or I’ve done good things in the past. Without identifying themselves
they can’t use these kinds of heavy systems.
So can we extend our existing e-Cash to do that kind of work? Well, it turns out that it’s actually
possible. What we can do is we can, and before I get to exactly how this works I should mention that
there are already systems. How many of you have heard of NameCoin? Okay, so there are already
systems that are actually, Bitcoin like systems that are not so interested in the cash but they’re more
interested in establishing identity.
So for example in NameCoin what’s happening is you have a block chain just as before. But when
somebody wants to, what somebody can do is they can establish ownership of a name, where a name is
just a string. So you can go and you can put a transaction at the block chain and say hey I have Pets.com
and if you’re the first person to claim ownership of Pets.com then you own it. You get to have that
name and bind it to your public key. Then later on you could transfer Pets.com to somebody else if
maybe they pay you some money, or you could establish a different name.
So you have this notion that you can now establish identity. That identity can be arbitrary strings or
collections of attributes and so on. You have a time that you did this so you could prove for example
right there that I have a dot com domain name for building a domain name system and that I’ve had it
for at least five years. So that kind of stuff can easily be done in a non-anonymous way.
Now imagine extending that so that some of these assertions are more interesting. Like let’s say I want
to assert that I’m a peer in some peer-to-peer network and I have a good reputation. Well the nodes
who are building this block chain could actually verify that I really am a peer who’s done good things in
the past. They could imbed some kind of assertion that says you really are into the block chain and then
later on I want to be able to prove that.
There are other things you might be able to do. So like reputation, let’s say every time I interact with a
node I want to be able to say well it’s a good interaction, maybe I gains some reputation from that. I can
update that into the block chain. Well it turns out that you can do all of these things anonymously
simply by having updates to the transaction from the block chain and then doing zero knowledge proofs,
but basically putting your attributes and your information into commitments, putting them into a block
chain and then proving knowledge and proving different statements about the contents of that
commitment.
So it could be anything from I have a dot com domain name to I have a reputation that is greater than
one hundred because I’ve done a whole bunch of transactions with people. Yet you still can’t tell who I
am. So we think this is kind of neat because now it gives you a way to build anonymous credentials
without all of that, you know stuff that’s very difficult of getting somebody to issue them. All you have
to do is have some kind of assertion that you can put into a block chain, you can prove things about it.
So we think that’s nifty. Yes?
>>: You’re still missing the [indiscernible] part, right, so…
>> Matthew Green: Well, it depends. I mean you’re right that there’s a limited amount of stuff that you
can vet and there’s stuff that you can. So let’s say the criteria for getting an identity is that I have to
solve a proof of work, or I have to pay ten Bitcoins. Right, so right there let’s say I have a peer-to-peer
network and it’s, I have a problem which is that people are running Sybil attacks. I can’t uniquely
identify nodes and anybody can create a million identities and run Sybil attacks because there’s nothing
stopping them from doing that. Well now I make it so that it costs me ten Bitcoins to establish an
identity. I’ve already put kind of an expense bound on how many identities you’re likely to create and
therefore limited the number of attacks that you can run. Or if you don’t want to use money we could
have everybody do a very complex proof of work.
So all an identity here is an assertion that I have a unique identity that cost me some amount
computation to establish, and that’s valuable in I think some peer-to-peer applications, and to be able to
do that anonymously prove that without having to have a central party kind of sitting there with who’s
going to appoint that central party. I think just that all by itself is neat. Reputation systems you can do
without any assertions about anything, just interactions between nodes.
Then, yes of course, you could build things where you have like an identity provider that maybe is doing
outside assertions. But you could still use this to do the credential issuing. So you could say that I don’t
get a credential unless the drivers license agency gives me a signature, or my TPM gives me a signature
saying that I have a valid TPM and then I can be in this network. So I think there’s a lot of neat stuff you
can do. We haven’t explored all the applications but I think they exist.
Sorry, I get excited about this. I’m going to wind up now, alright. So can we build, I’m going back to
Zerocoin. Can we build Zerocoin today? Well the answer is yes. So we actually built a version of the
clients. The Bitcoin client is called bitcoind, the C plus, plus version. My grad students Ian Miers and
Christina Garman, I did not touch this so I take no credit. They did incredibly hard work and if you’ve
seen the code quality on this thing you’ll understand why. They did incredibly hard work updating it and
inserting this capability into this client. So it actually works. We’re going to be releasing the code when
we present at Oakland with some clean up.
So it’s a real thing and you can use it. The problem is that in order to use it in a sort of coherent fashion
you need all of the Bitcoin nodes to adopt it, kind of simultaneously, so incremental adoption is hard.
There are some things that you could do along the way where you have temporary trusted parties who
could help you keep, get the system going. Then ultimately you could get rid of them. So we hope that
there’s kind of a solution that people will do it.
The other thing that we have to worry about is that there’s a lot of cost to verifying these proofs. That
has some implications for the stability of the Bitcoin network. But it’s a real system you can actually use.
It’s not just a paper. Anyway so there’s a lot of future, the last thing that I want to cover and then I’ll
stop is what are the ethics of doing this in the first place?
I mean is it, let’s say that we do it. Let’s say that people actually think it’s secure. Let’s say people
implement it. Is it a good thing that we have an electronic and a decentralized currency that is actually
sort of untraceable? Are we facilitating crime by doing this? Or are we creating a world where, you
know everybody in the world can’t see that I bought medication from my pharmacy, which is the way
things are in Bitcoin today? So I don’t really know what the answer to that is. But I do think that there’s
value in pursuing this and then seeing what people make of it.
So that’s it. I don’t think I went too far over but thank you guys.
[applause]
>> Patrick Longa Pierola: Any more questions?
>>: Yeah, so what advantage of Bitcoin as it currently stands is that it’s simple enough to implement so
there are multiple competitions out there.
>> Matthew Green: Yeah.
>>: How simple is Zerocoin to implement? Could you…
>> Matthew Green: It’s just zero knowledge proofs. It’s more complicated and that’s going to be a
problem. So you’re going to have to have libraries and you’re going to have to have people who trust
those libraries, and that’s going to be an issue. The good news is that it’s really one file. I mean all of
the crypto code is in one file. Once you have the transaction semantics and you trust that one file of
crypto that’s it, you’re kind of done, so. It’s more complicated though. The Bitcoin people are scared of
it. We talked to them and they said we understand hashes, we understand ECDSA but I don’t think we
can explain this to the people who actually use Bitcoin today, it’s too much.
>>: So as I remember from the slides the reason for decentralization is that, at the beginning there
would be like no one to set up the central body to do…
>> Matthew Green: Yeah.
>>: Yeah, but now it would be like get some kind of [indiscernible] so I think there would be people
willing to set up some kind of central authority or [indiscernible]…
>> Matthew Green: There is…
>>: [indiscernible] have like similar for the real money where there’s a central banks and...
>> Matthew Green: So the problem is there’s been one attempt to do Chaumian style e-Cash and it
crashed. Somebody started up a company and then it failed, or started up a project and it failed. I think
that in toll a company like that is running for a good deal of time. People may not trust it very much.
They might put their money into it for a little while but they won’t leave it in for very long.
Unfortunately the anonymity properties rely on you kind of letting your money circulate in this pool till
lots and lots of people are also there. So the degree of anonymity you get is based on, you know how
much do you trust this company and are willing to trust them with your money.
So I agree that it could happen. You could have a central company but I don’t see it happening in a big
way and getting widely used any time in the near, near future.
>>: And not only like company but would be on [indiscernible] from government...
>> Matthew Green: Yeah, although I don’t think the governments going to want to help out with the
untraceable currency stuff. But I agree that you are going to have problems with, there are definitely
lots of organizations that could do it. Microsoft could do it. They could build a product to do it but I
don’t think they’re going to, I mean it’s just an issue. I think that it’s, here’s the other thing, the last
thing that it’s a legal problem. Let’s say you build a centralized Chaumian e-Cash company.
Are you crazy, I mean you’re going to get, how much trouble are you going to get in if it’s used for
anything terrorism related? If it’s ever traced that that’s done your company is going to be essentially
either asked to find some way to trace it or you’re going to be shut down. With this system, with a fully
decentralized system you don’t have that problem.
>> Patrick Longa Pierola: Any other questions? So let’s thank Matthew Green again.
[applause]
>> Matthew Green: Good deal.