In segment 1.5, we're going to move
from talking about cryptography and
we're going to move on
to cryptocurrencies.
Now I know that many of you showed up here
for the cryptocurrency stuff, and trust
me there will be a lot more cryptocurrency
material in future lectures.
Unfortunately, we needed to eat some
of our cryptographic vegetables
in order to have the background
to talk about crypto currencies.
And now you'll see, when I start
talking about crypto currencies,
how these pieces fit together, and
why the cryptographic operations,
like hash functions and
digital signatures are actually useful.
All right.
So in this section,
I want to talk about some simplified
Crypto currencies that give us ideas
about how systems like BitCoin work.
Of course it's going to require about ten
more lectures in order to really spill out
all of the implications of how
BitCoin works and what that means, but
let me talk about some very simple crypto
currencies to get the discussion started.
And first let's talk about GoofyCoin.
GoofyCoin is about the simplest
crypto currency we can imagine.
And it works kind of like this.
There are just a couple
rules of GoofyCoin.
The first rule is that
Goofy can create new coins.
Goofy can make a new coin whenever he
wants and when he makes a new coin,
it belongs to him.
So when Goofy makes a coin, it's
represented by a data structure like this.
Here you have the create
coin operation and
there's a unique coin ID
that Goofy generated.
And then there's a digital signature
that was put on it by Goofy
which anyone can verify.
So anyone being given this can verify
that the signature is valid and
that it's a signature of this statement.
And new coins belong to Goofy,
by definition, because those
are the rules that Goofy made.
So, that's the first rule,
Goofy can create new coins.
The second rule of Goofy coin is that
whoever owns a coin can pass it on
to someone else, they can spend it.
So, for example, here we have
the coin that I showed you before,
that Goofy created, and now we're going
to take a hash pointer to that coin, and
we're going to create a statement.
Goofy's going to make a statement
that says pay this to Alice,
Alice is being named by a public key here.
Pay to public key Alice the coin that
is represented by this hash pointer and
this is also signed by Goofy.
Now Goofy is the one who
owned that coin and so
Goofy has to sign any transaction
that spends the coin.
And once this has happened,
now Alice owns the coin.
Alice owns the coin and Alice can prove
that she owns the coin, because she can
present this data structure here,
which is validly signed by Goofy and
points to a coin that was
validly owned by Goofy.
So the correctness of this coin
is self evident in this system.
Now, Alice can move on and
she can spend the coin as well.
So here we have the coin we had before.
Down here at the bottom, we have
the creation of the coin signed by Goofy.
Now Goofy paid the coin to Alice via
this hash pointer and he signs that.
Now Alice is the owner of the coin.
Now, she can create a statement like this,
that says pay this coin
to Bob's public key.
And here's a hash pointer to the coin.
And now Alice signs that.
So because Alice was the valid owner of
the coin which we could verify by walking
this chain.
Now we know that this is valid and
the coin belongs to Bob.
So Bob is now the owner of this coin.
So those are all the rules of Goofy coin.
Goofy can create new coins by simply
signing a statement that he's making a new
coin with a unique coin ID.
And then whoever owns a coin
can pass it on to someone else
by signing a statement saying
pass on this coin to person X.
And you can verify the validity of
the coin by simply following the chain and
verifying all the signatures
along the way.
That's Goofy coin.
Alright, now there's a problem though.
There's a big security
problem with Goofy coin and
we can see it in this structure here.
So look at this coin here,
this is the coin that Goofy made and
then paid to Alice.
Alice was the owner of that coin.
And there's a problem.
Alice paid this coin onto Bob.
But now Alice makes another
data structure like this which
pays to Chuck the very same coin,
and this is signed by Alice.
Now if Chuck doesn't know about
this thing up in the upper left,
this data structure,
let's say Alice just gave that to Bob and
didn't tell Chuck,
now Chuck will look at this and
he'll think that this is perfectly valid
and now he's the owner of the Coin.
Chuck has a valid looking claim
to be the owner of this coin, and
Bob has an equally valid looking claim
to be an owner of this coin, and
that's a problem, because coins
are not supposed to work that way.
This is called a double-spending attack.
It's called double-spending because
Alice is spending the same coin twice.
And double-spending attacks are one of
the key problems that a cryptocurrency
has to solve.
Goofy coin does not solve
the double spending attack and
therefore Goofy coin is not secure.
So although Goofy coin is simple and
we understand its rules,
it won't cut it as a cryptocurrency
because it allows double spending.
So in order to build the cryptocurrency
that is going to be workable,
we need to have some solution
to the double-spending problem.
And indeed the double-spending problem is
the main design challenge that we face
in designing a cryptocurrency.
So we need to somehow
improve on GoofyCoin.
And we'll do that by designing another
coin, which I'll call ScroogeCoin.
ScroogeCoin is going to be rather like
GoofyCoin, except it will solve the double
spending problem in a particular way,
and this coin was created by Scrooge.
Okay, so this is a little bit more
complicated in terms of data structures,
but here's one of the key ideas.
That Scrooge is
going to publish a history of all
the transactions that have happened.
This will be a block chain, that data
structure we talked about before, and
it will be digitally signed by Scrooge.
And it looks like this of course,
a series of blocks, data blocks.
Each block will have
one transaction in it.
This block has the transaction
with transaction ID number 73.
And it has the contents
of this transaction, and
there's a hash pointer to
the previous block in the history.
And then Scrooge will take the hash
pointer which represents this entire
structure, and
he'll digitally sign it and publish it.
Now anybody can verify that Scrooge really
did sign this hash pointer, and then they
can follow this chain all the way back and
see what is the entire history of
all the transactions in the history of
Scrooge coin, as endorsed by Scrooge.
Okay?
Now I said here we put one transaction
in each block.
We do that for simplicity of explanation,
but in practice as an optimization we'd
really put multiple transactions into
the same block, as Bitcoin does.
So you can bare in mind as
I talk about Scrooge coin.
But that's the way we
really do it in practice.
So Scrooge publishes this history.
What does the history do?
Well the thing that history does for us is
it allows us to detect double spending.
Because assume Alice owns a coin and
she's going to pay that coin on to Bob.
And she's then later going to try and
pay that coin on to Charlie.
Charlie's going to notice that something
is wrong, because Charlie will be able to
look into the history and see that
Alice already paid that coin to Bob.
In fact, everyone will be able to see
that Alice already paid that coin to Bob.
So if she tries to pay that coin to Chuck,
then everyone can see that's a double
spend, and they'll be able to reject it.
Scrooge will reject it and
everyone else will reject it and
know that they really
shouldn't trust Alice.
All right, so in ScroogeCoin,
there are two kinds of transactions.
The first kind is a create
coins transaction.
What it does is create new coins,
that's like the operation Goofy could
do in GoofyCoin that makes a new coin.
But here, we're going to allow multiple
coins to be created in one transaction.
So here's what a CreateCoins
transaction looks like.
It has transaction ID number 73,
let's say in this case,
its transaction type is CreateCoins.
And then down here,
there's a list of which coins are created.
Each coin is going to have a serial
number within this transaction, 012, etc.
Each coin has a value.
It's worth a certain number of Scrooge
Coins, and each coin has a recipient,
which is going to be a public key,
who gets that coin as it's created.
So this transaction type creates
a bunch of new coins and
assigns them to people as initial owners.
Now we're going to have a concept
in Scrooge Coin of a coinID.
That refers to a particular coin.
So this particular coin here is
coin ID 73 paren zero, because it
was created in transaction 73, and it
was number zero within that transaction.
Similarly we have 73 paren 1,
73 paren 2, and so on.
So every coin in Scrooge coin has
a coin ID that we can use to refer to.
A CreateCoins transaction is always valid.
Why is it valid?
Well because Scrooge said so, and
they call it Scrooge coin for a reason.
If Scrooge puts this into
the history of which he signs,
then it's valid by definition.
We don't worry whether Scrooge is entitled
to create coins, just like we didn't need
to worry in GoofyCoin about whether Goofy
is entitled to create coins, the rules of
the system which were created by Scrooge
simply say that if Scrooge wants to make
coins, then that's valid, so anything
he puts into the history is valid.
The second kind of transaction we're going
to talk about is a PayCoins transaction.
And this is a transaction that
consumes some coins and destroys them.
And creates new coins of
the same total value but
which might belong to different people.
So over here on the left we have
an example of what a PayCoins
transaction looks like.
This is transaction ID number
seventy-three, let's say.
It's type is PayCoins.
We have here a list of the coins
that this one consumes.
All of these coins are being consumed and
destroyed by this paycoin transaction.
So we're going to add up all the values of
those coins and then we're going to create
a bunch of new coins down here zero,
one, and two etcetera.
Just like before in
the CreateCoins transaction.
Each one will have a value and
each one will have a certain recipient.
And those new coins had better add up to
the same total value as the coins that
we consumed.
And then at the bottom we have
a set of digital signatures.
This transaction has to be signed
by everyone whose paying in a coin.
So if you're the owner of one of the coins
that's going to be consumed in this
transaction, then you need to digitally
sign the transaction to say that you're
really okay with spending this coin.
The rules of Scrooge coin say that
a PayCoins transaction is valid
if four things are true: first,
if the consumed coins are valid,
that is they really were created,
in previous transactions.
Second, that the consumed coins were
not already consumed in some previous
transaction, that is that
this is not a double spend.
Third that the total value of
the coins that come out of this
transaction is equal to the total
value of the coins that went in.
And finally,
that the transaction is validly signed by
the owners of all of the consumed coins.
If all of those things are true,
then this paycoins transaction is valid,
Scrooge will accept it,
he'll write it into the history,
into the block chain, and everyone will
see that this transaction has happened.
One thing to note about this scheme
is that coins are immutable.
Coins are never changed, they're never
subdivided, they're never combined.
All they are is created once
in one transaction, and
then later consumed in
some other transaction.
But you can get the same effect as
being able to subdivide, or pay on, or
combine coins by using transactions.
For example,
if you want to subdivide a coin,
you could just create a new transaction
that consumes that one coin, and
then produces two new coins
of the same total value.
And if you want, you can give those
two new coins back to yourself.
That's a way that you can
subdivide a coin that you own.
Similarly you can combine coins or
you can pay on a coin in effect by
just creating a chain of transactions,
each of which pass that value on in
the form of a new coin to someone else.
So although coins
are immutable in the system,
it has all of the flexibility of a system
that didn't have immutable coins.
Okay.
Now we come to the core
problem with Scrooge Coin.
Scrooge Coin will work,
people can see which coins are valid,
it prevents double spending because
people can look into the block chain and
see that all of the transactions are valid
and that every coin is consumed only once.
But the problem is Scrooge.
Scrooge thinks this is fine.
Right?
Scrooge says, don't worry I'm honest.
But the fact is,
if Scrooge starts misbehaving,
then we're going to have a problem.
Or, if Scrooge just gets bored of the
whole Scrooge coin scheme and stops doing
the things that he's supposed to do,
then the system won't operate anymore.
And so the problem we have
here is centralization.
But although Scrooge is happy with this
system, we as users of it might not be.
So the central technical challenge that
we need to solve in order to improve
on Scrooge coin is can we
descroogify the system?
That is can we get rid of that
centralized Scrooge figure?
Can we have a cryptocurrency that operates
like ScroogeCoin in many ways, but
doesn't have any central
trusted authority?
In order to do that, we're going to need
to figure out how to provide the services
that Scrooge provides, but
do it in a decentralized way,
in a way in while no particular
party is particularly trusted.
That means we're going to need to figure
out how everyone can agree upon a single
published block chain,
that is the agreed upon history of
which transactions have happened.
We need to figure out how people can
agree which transactions are valid and
which transactions have actually occurred.
And, we need to figure out how
we can assign IDs to things
in a decentralized way.
If we can solve all of those problems,
then we can build a currency
that is very much like BitCoin,
which is like ScroogeCoin, but
without a centralized party.
But in order to do that,
it's going to take a few more lectures and
we hope you'll stick around and
watch them.
Thanks.