A Simple Cryptocurrency

Loading...

From the course by Princeton University

Bitcoin and Cryptocurrency Technologies

1796 ratings

Princeton University

Bitcoin and Cryptocurrency Technologies

1796 ratings

To really understand what is special about Bitcoin, we need to understand how it works at a technical level. We’ll address the important questions about Bitcoin, such as: How does Bitcoin work? What makes Bitcoin different? How secure are your Bitcoins? How anonymous are Bitcoin users? What determines the price of Bitcoins? Can cryptocurrencies be regulated? What might the future hold? After this course, you’ll know everything you need to be able to separate fact from fiction when reading claims about Bitcoin and other cryptocurrencies. You’ll have the conceptual foundations you need to engineer secure software that interacts with the Bitcoin network. And you’ll be able to integrate ideas from Bitcoin in your own projects. Course Lecturers: Arvind Narayanan, Princeton University

From the lesson

Introduction to Crypto and Cryptocurrencies

Learn about cryptographic building blocks ("primitives") and reason about their security. Work through how these primitives can be used to construct simple cryptocurrencies.

Cryptographic Hash Functions18:42

Hash Pointers and Data Structures8:59

Digital Signatures9:45

Public Keys as Identities5:33

A Simple Cryptocurrency14:04

Meet the Instructors

Arvind Narayanan
Associate Professor
Computer Science

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 lecture.

Unfortunately we needed to eat some of our cryptographic vegetables

in order to have the background to talk about Cryptocurrencies.

And now you'll see when I start talking about Cryptocurrencies 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

Cryptocurrencies 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

spell out all of the implications of how BitCoin works and what that means.

But let me talk about some very simple Cryptocurrencies

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 kinda 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 CreateCoin operation, and

there's a uniqueCoinID 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 is the first rule, Goofy can create new coins.

The second rule of GoofyCoin 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 before that Goofy created.

And now we're gonna take a hash pointer to that coin and

then we're gonna create a statement.

Goofy's gonna 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's represented by this hash pointer and

this is also signed by Goofy.

Now Goofy is the one who own that coin and so

Goofy has to sign any transaction that spends the coin.

And once this has happen, 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 own by Goofy.

And 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, this is 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 signed 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 GoofyCoin.

Goofy can create new coins by simply assigning 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 a coin by simply following the chain and

verifying all the signatures along the way.

That's GoofyCoin.

All right, now, there's a problem though.

There's a big security problem with GoofyCoin 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 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 the 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.

GoofyCoin does not solve the double spending attack and

therefore GoofyCoin is not secure.

So although GoofyCoin 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 a 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 can 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.

So anyone can, and it looks like this of course,

it's a series of blocks, data blocks.

Each block will have one transaction in it,

these block has the transaction with transaction ID number 73.

It has the contents of this transaction and

then there's a hash pointer to the previous block in the history.

Okay? 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 ScroogeCoin, as endorsed by Scrooge.

Okay. Now I said here,

that 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 bear in mind as i talk about ScroogeCoin that

that's the way we'd really do it in practice.

So Scrooge publishes this history.

What does the history do?

Well the thing the 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 to pay that coin onto Charlie.

Charlie's gonna 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 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 shouldn't trust Alice.

All right.

So in ScroogeCoin there are two kinds of transactions.

The first kind is a CreateCoins transaction and

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 lets say in this case its transaction

type is create coins and then down here there's a list of which coins are created.

Each coin is gonna have a serial number within this transaction zero one two etc.

Each coin has a value, it's worth a certain number of ScroogeCoins.

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 gonna have a concept in ScroogeCoins of a coin ID.

That refers to a particular coin.

So this particular coin here is coin ID 73(0) because it

was created in transaction 73 and it was number zero within that transaction.

Similarly we have 73(1), 73(2) and so on.

So every coin in Scrooge Coin has a coin ID that we can refer to it.

A CreateCoins transaction is always valid.

Why is it valid?

Well, because Scrooge said so, and they call it ScroogeCoin for a reason.

If Scrooge puts this into the history,

which he signs, then it's valid by definition.

We don't need to worry about 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 73, let's say, its 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 PayCoins transaction.

So we're going to add up the value of all of those coins and

then we're gonna create a bunch of new coins down here, zero, one, and two, etc.

Just like before in the CreationCoins transaction each one has a value.

Each one will belong to 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 who's 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 ScroogeCoins say that a PayCoin's 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, 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 can 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 this 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 ScroogeCoin.

ScroogeCoin will work.

People can see which coins are valid.

It prevents double spending because everyone 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 ScroogeCoin scheme and stops doing

the things that he is supposed to do, then the system won't operate anymore.

And so, the problem we have here is Centralization.

That although Scrooge is happy with the system, we, as users of it might not be.

So the central technical challenge that we need to solve in order to improve

on ScroogeCoin 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,

a way in which no particular party is particularly trusted.

That means we're gonna need to figure out how everyone can

agree upon a single published block chain

that is the agreed upon history 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.

Explore our Catalog

Join for free and get personalized recommendations, updates and offers.

Coursera provides universal access to the world’s best education, partnering with top universities and organizations to offer courses online.

© 2018 Coursera Inc. All rights reserved.

Download on the App Store

Get it on Google Play