Goofy Coin

There are just a couple rules of GoofyCoin:

1. Goofy can create new coins whenever he wants. The new coins, at the beginning,
belong to him. So, there’s a CreateCoin operation, a uniqueCoinID and a Digital
Signature that Goofy puts on new coins, that everyone can verify;

2. Whoever owns a coin can pass it on to someone else: the coins can be spent. For
example if Goofy wants to pay Alice, he will:
1. Take a hash pointer to that coin
2. Make a statement that says that he wants to pay the coin to Alice. And he
refers to Alice through her public key
3. The statement is signed by Goofy
4. Now Alice owns the coin and can prove it. She can present the following data
structure, which is validly signed by Goofy and points to a coin that Goofy
owned.
5. Alice can go on and use the coin however she wants, for example can make a
payment to Bob using the same datastructure, and so on.

So Goofy can create new coins with a simple 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. It is possible to verify the validity of a coin
by simply following the chain and verifying all the signatures along the way.

Limitations : Double spending problem:

There's a big security problem with GoofyCoin, shown in the diagram below.
 1. Goofy makes a transaction to pay Alice
2. Alice makes a transaction to pay Bob
3. Then Alice makes another transaction to Chuck, sending the same coin

Now, both the last transactions are signed by Alice. If Chuck doesn't know that Alice has
already sent the money to Bob, he will think that he's the owner. Both the claims of Bob and
Chuck to be the owner are equally valid, since they can follow the chain till Goofy. That's a
problem because coins are not supposed to work that way. This is called double-spending
attack, because Alice is spending the same coin twice.

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 it is not secure. In order
to build a usable Cryptocurrency, we need to have some solution to the double-spending
problem.

Scrooge Coin

So let's design ScroogeCoin, that is going to be like GoofyCoin, except it will solve the
double-spending problem in a particular way. The key idea is that Scrooge is going to publish
the history of all the transactions in a blockchain, that will be digitally signed by Scrooge. So
anyone can check the data blocks. Each block will have one transaction in it and a hash
pointer to the previous block in the history.

Then Scrooge will take the hash pointer, which represents this entire structure, digitally sign
it and publish it. Now anybody can verify that Scrooge really signed this hash pointer. And
then they can follow this chain all the way back and see the entire history of all the
transactions of ScroogeCoin, since the beginning.

Solution to double-spending problem

The history allows us to detect double-spending. Assume Alice owns a coin, and she tries to
pay that coin both to Bob and to Charlie. Charlie will notice that something is wrong, because
he can look into the history and 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 spending and they'll be able
to reject it.

Transactions types

In ScroogeCoin there are two kinds of transactions:

1. CreateCoins transaction: in Scrooge Coin it is possible to create multiple coins in

one transaction. Every coin will have a serial number, a value and a owner (a public
key of the initial owner). So this transaction type creates a bunch of new coins and
assigns them to people as initial owners. Each coin will have a unique ID (i.e. ID
73(0): first coin created in transaction 73, ID 73(1), 73(2), ... other coins created in
transaction 73). A CreateCoins transaction is always valid, because Scrooge said so. If
Scrooge puts this into the history, which he signs, then it's valid by definition.

2. PayCoins transaction: consumes some coins and destroys them, and creates new
coins of the same total value, but which might belong to different people. So, we will
have a list of the coins that are going to be destroyed. Then there's a creation of a
bunch of new coins, whose total value must add up to the total of destroyed coins. Just
like before in the CreationCoins transaction each one has an Id, a value and a owner.
This transaction must be signed with all signatures of the owner of one of the
destroyed coins.
Check transactions validity:

This transaction is valid if four conditions are met:

1. the consumed coins are valid: they were really created in previous transactions
2. double-spending check: the consumed coins were not already been spent in previous
transactions
3. the total value of the newly created coins is equal to the total value of the destroyed
coins
4. all the digital signature of previous owners are valid

In this case Scrooge will accept it and insert this block into the blockchain, so everyone can
check it. In this scheme the coins are immutable, they are just created with a specific owner
and then destroyed. But every operation is still possible. For example to subdivide a coin, is
enough to create a new transaction that consumes a coin and produces two new coins of the
same total value.

Limitations: Centralization Problem

In this case the problem is Scrooge. Right? Scrooge says don't worry, I'm honest. But 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.

The problem we have here is Centralization: although Scrooge is happy with the system, the
users of it might not be. In order to improve on ScroogeCoin is necessary to decentralize the
system.

order to do that, we need to figure out how to provide the same services of Scrooge, but in a
decentralized way, in which no particular party is the only trusted one. We need to figure out:

 how everyone can agree upon a single published blockchain, on which transactions
are valid and which transactions actually occurred
 how we can assign IDs to things in a decentralized way