Now let’s move from cryptography to cryptocurrencies. Eating our cryptographic vegetables will start to pay off here, and we’ll gradually see how the pieces fit together and why cryptographic operations like hash functions and digital signatures are actually useful. In this section we’ll discuss two very simple cryptocurrencies. Of course, it’s going to require much of the rest of the book to spell out all the implications of how Bitcoin itself works.
GoofyCoin
The first of the two is GoofyCoin, which is about the simplest cryptocurrency we can imagine. There are just two rules of GoofyCoin. The first rule is that a designated entity, Goofy, can create new coins whenever he wants and these newly created coins belong to him.
To create a coin, Goofy generates a unique coin ID uniqueCoinID that he’s never generated before and constructs the string “CreateCoin [uniqueCoinID]”. He then computes the digital signature of this string with his secret signing key. The string, together with Goofy’s signature, is a coin. Anyone can verify that the coin contains Goofy’s valid signature of a CreateCoin statement, and is therefore a valid coin.
The second rule of GoofyCoin is that whoever owns a coin can transfer it on to someone else. Transferring a coin is not simply a matter of sending the coin data structure to the recipient — it’s done using cryptographic operations.
Let’s say Goofy wants to transfer a coin that he created to Alice. To do this he creates a new statement that says “Pay this to Alice” where “this” is a hash pointer that references the coin in question. And as we saw earlier, identities are really just public keys, so “Alice” refers to Alice’s public key. Finally, Goofy signs the string representing the statement. Since Goofy is the one who originally owned that coin, he has to sign any transaction that spends the coin. Once this data structure representing Goofy’s transaction signed by him exists, Alice owns the coin. She can prove to anyone that she owns the coin, because she can present the data structure with Goofy’s valid signature.
Furthermore, it points to a valid coin that was owned by Goofy. So the validity and ownership of coins are self‐evident in the system.
Once Alice owns the coin, she can spend it in turn. To do this she creates a statement that says, “Pay this coin to Bob’s public key” where “this” is a hash pointer to the coin that was owned by her. And of course, Alice signs this statement. Anyone, when presented with this coin, can verify that Bob is the owner. They would follow the chain of hash pointers back to the coin’s creation and verify that at each step, the rightful owner signed a statement that says “pay this coin to [new owner]”.
To summarize, the rules of GoofyCoin are:
- Goofy can create new coins by simply signing a statement that he’s making a new coin with a unique coin
- Whoever owns a coin can pass it on to someone else by signing a statement that saying, “Pass on this coin to X” (where X is specified as a public key)
- Anyone can verify the validity of a coin by following the chain of hash pointers back to its creation by Goofy, verifying all of the signatures along the
Of course, there’s a fundamental security problem with GoofyCoin. Let’s say Alice passed her coin on to Bob by sending her signed statement to Bob but didn’t tell anyone else. She could create another signed statement that pays the very same coin to Chuck. To Chuck, it would appear that it is perfectly valid transaction, and now he’s the owner of the coin. Bob and Chuck would both have valid‐looking claims to be the owner of this coin. This is called a double‐spending attack — Alice is spending the same coin twice. Intuitively, we know coins are not supposed to work that way.
In fact, double‐spending attacks are one of the key problems that any cryptocurrency has to solve. GoofyCoin does not solve the double‐spending attack and therefore it’s not secure. GoofyCoin is simple, and its mechanism for transferring coins is actually very similar to Bitcoin, but because it is insecure it won’t cut it as a cryptocurrency.
ScroogeCoin
To solve the double‐spending problem, we’ll design another cryptocurrency, which we’ll call ScroogeCoin. ScroogeCoin is built off of GoofyCoin, but it’s a bit more complicated in terms of data structures.
The first key idea is that a designated entity called Scrooge publishes an append‐only ledger containing the history of all the transactions that have happened. The append‐only property ensures that any data written to this ledger will remain forever. If the ledger is truly append‐only, we can use it to defend against double‐spending by requiring all transactions to be written the ledger before they are accepted. That way, it will be publicly visible if coins were previously sent to a different owner.
To implement this append‐only functionality, Scrooge can build a block chain (the data structure we discussed before) which he will digitally sign. It’s a series of data blocks, each with one transaction in it (in practice, as an optimization, we’d really put multiple transactions into the same block, as Bitcoin does.) Each block has the ID of a transaction, the transaction’s contents, and a hash pointer to the previous block. Scrooge digitally signs the final hash pointer, which binds all of the data in this entire structure, and publishes the signature along with the block chain.
In ScroogeCoin a transaction only counts if it is in the block chain signed by Scrooge. Anybody can verify that a transaction was endorsed by Scrooge by checking Scrooge’s signature on the block that it appears in. Scrooge makes sure that he doesn’t endorse a transaction that attempts to double‐spend an already spent coin.
Why do we need a block chain with hash pointers in addition to having Scrooge sign each block? This ensures the append‐only property. If Scrooge tries to add or remove a transaction to the history, or change an existing transaction, it will affect all of the following blocks because of the hash pointers. As long as someone is monitoring the latest hash pointer published by Scrooge, the change will be obvious and easy to catch. In a system where Scrooge signed blocks individually, you’d have to keep track of every single signature Scrooge ever issued. A block chain makes it very easy for any two individuals to verify that they have observed the exact same history of transactions signed by Scrooge.
In ScroogeCoin, there are two kinds of transactions. The first kind is CreateCoins, which is just like the operation Goofy could do in GoofyCoin that makes a new coin. With ScroogeCoin, we’ll extend the semantics a bit to allow multiple coins to be created in one transaction.
Figure 1.12 CreateCoins transaction. This CreateCoins transaction creates multiple coins. Each coin has a serial number within the transaction. Each coin also has a value; it’s worth a certain number of scroogecoins. Finally, each coin has a recipient, which is a public key that gets the coin when it’s created. So CreateCoins creates a bunch of new coins with different values and assigns them to people as initial owners. We refer to coins by CoinIDs. A CoinID is a combination of a transaction ID and the coin’s serial number within that transaction.
A CreateCoins transaction is always valid by definition if it is signed by Scrooge. We won’t worry about when Scrooge is entitled to create coins or how many, just like we didn’t worry in GoofyCoin about how Goofy is chosen as the entity allowed to create coins.
The second kind of transaction is PayCoins. It consumes some coins, that is, destroys them, and creates new coins of the same total value. The new coins might belong to different people (public keys). 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 ScroogeCoin say that PayCoins transaction is valid if four things are true:
- The consumed coins are valid, that is, they really were created in previous
- The consumed coins were not already consumed in some previous That is, that this is not a double‐spend.
- The total value of the coins that come out of this transaction is equal to the total value of the coins that went That is, only Scrooge can create new value.
- The transaction is validly signed by the owners of all of the consumed
If all of those conditions are met, then this PayCoins transaction is valid and Scrooge will accept it. He’ll write it into the history by appending it to the block chain, after which everyone can see that this transaction has happened. It is only at this point that the participants can accept that the transaction has actually occurred. Until it is published, it might be preempted by a douple‐spending transaction even if it is otherwise valid by the first three conditions.
Coins in this system are immutable — they are never changed, subdivided, or combined. Each coin is created, once, in one transaction and later consumed in some other transaction. But we can get the same effect as being able to subdivide or combine coins by using transactions. For example, to subdivide a coin, Alice create a new transaction that consumes that one coin, and then produces two new coins of the same total value. Those two new coins could be assigned back to her. So although coins are immutable in this system, it has all the flexibility of a system that didn’t have immutable coins.
Now, we come to the core problem with ScroogeCoin. ScroogeCoin will work in the sense that 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 — he has too much influence. He can’t create fake transactions, because he can’t forge other people’s signatures. But he could stop endorsing transactions from some users, denying them service and making their coins unspendable. If Scrooge is greedy (as his cartoon namesake suggests) he could refuse to publish transactions unless they transfer some mandated transaction fee to him. Scrooge can also of course create as many new coins for himself as he wants. Or Scrooge could get bored of the whole system and stop updating the block chain completely.
The problem here is centralization. Although Scrooge is happy with this system, we, as users of it, might not be. While ScroogeCoin may seem like an unrealistic proposal, much of the early research on cryptosystems assumed there would indeed be some central trusted authority, typically referred to as a bank. After all, most real‐world currencies do have a trusted issuer (typically a government mint) responsible for creating currency and determining which notes are valid. However, cryptocurrencies with a central authority largely failed to take off in practice. There are many reasons for this, but in hindsight it appears that it’s difficult to get people to accept a cryptocurrency with a centralized authority.
Therefore, the central technical challenge that we need to solve in order to improve on ScroogeCoin and create a workable system 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?
To do that, we need to figure out how all users can agree upon a single published block chain as the history of which transactions have happened. They must all agree on which transactions are valid, and which transactions have actually occurred. They also need to be able to assign IDs to things in a decentralized way. Finally, the minting of new coins needs to be controlled in a decentralized way. If we can solve all of those problems, then we can build a currency that would be like ScroogeCoin but without a centralized party. In fact, this would be a system very much like Bitcoin.
