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.
