1. Cryptocurrency Intro
OK so the motivation that we’re going to use for the first third of the course is going to be cryptocurrencies. We’re not going to be discussing the merits of different cryptocurrencies, nor should any of these be interpreted as any kind of endorsement of cryptocurrencies as an investment. But the technology backing/enabling cryptocurrencies is interesting and broadly applicable to other problems. Along the way we’re going to be talking about hashing, digital signatures, consensus algorithms, and more.
But for starters, let’s spend some time getting a broad outline of what a cryptocurrency is and generally how they work.

2. Cryptocurrency: what is it?
Fundamentally, it’s a ledger.
Alice owes Bob $10
Alice owes Charlie $20
Charlie owes Bob $50
Bob owes Deborah $90
Deborah owes Alice $15
Fundamentally, cryptocurrencies are a ledger. For a real world example, imagine you and your friends all have a spreadsheet to track who pays for what each month. Now you don’t have to worry about splitting every dinner bill or worry about who pays rent or anything like that. Everyone adds the expenses they made to the spreadsheet, and at the end of the month everyone can tally up what they owe and figure out how to settle up the expenses so everything evens out in the end.
So basically when people are talking about Bitcoin or Ethereum or any other cryptocurrency, what they’re really talking about is a ledger tracking different what transactions people are making with each other. Evaluating the ledger at any given time tells us who owes money and who is owed money - or alternatively how much money everyone would have after all the transactions are settled.

3. Cryptocurrency: what is it?
It’s public.
Issues that arise:
Privacy?
How do we know both parties agree to a transaction? And how do we know people aren’t impersonating others?
Digital Signatures -- more on this later!
How do we know everyone will pay their debts?
Don’t allow people to go net negative.
Another important feature of cryptocurrencies are that they are public. The benefit of this is that anyone can add anything to the ledger (i.e. there’s low friction to “using” the currency), and that everyone can inspect the ledger to verify transactions and validate the amount of money they have and how much others have (since there’s a full transaction history). So you might see some privacy issues with this, which is fair, but we’re not going to be dealing with that as a problem and just sort of assuming that if you want to use a cryptocurrency you’re buying into the public ledger’s usefulness outweighing the need for privacy.
Some issues do arise from this though… first of all: how do we know both people involved in a transaction agree to it? For example, surely Bob can’t just put on a transaction on the ledger that says “Alice owes Bob $20” without Alice agreeing to it. So we’re going to need to make sure Alice has some way of agreeing to the transaction and saying “yup, it’s true that I owe Bob $20”. But even if we added that security, we need to make sure that Bob cannot impersonate Alice and nefariously agree on Alice’s behalf. For both of these issues, we’re going to lean on “Digital Signatures” which is something we’re going to go into more detail on in a later lecture.
A second issue that arises from making the ledger public is one having to do with trust: namely, how do we know everyone will actually pay their debts? Maybe Alice will owe a bunch of people money on the ledger, and then just say “eh, this whole crypto thing is nonsense, I’m not going to settle up” and now all the people that were owed money are left holding the bag. This is where our earlier example about some friends with an expenses spreadsheet breaks down a bit. That example of a ledger relies a lot on your friends all trusting each other that everyone will settle up at the end. But we can’t really scale that trust to the public because bad actors may try to take advantage of the system.

4. Cryptocurrency: what is it?
It’s public.
Alice has $100
Bob has $120
Charlie has $50
Deborah has $10
Alice owes Bob $10
Alice owes Charlie $20
Charlie owes Bob $50
Bob owes Deborah $90
Deborah owes Alice $15
The solution to that problem is a little simpler. Instead of settling up at the end, we just have everyone put money into a pot at the beginning. So our ledger is going to start with how much money everyone starts with, and from there all the transactions are applied onto it. Since we have a full transaction history, we can ensure whenever someone adds a new transaction to the ledger that the payer actually has the funds to settle the transaction. So in the example above, the transaction of Deborah paying Alice $15 would be rejected from the ledger because we can see that she doesn’t actually have the funds to satisfy that.
So up until this point we’ve been using US dollars in our ledger examples, but that’s not actually the case in real cryptocurrencies.

5. Cryptocurrency: what is it?
It’s not tied to any other currency.
CornellCoin Ledger
Alice has 100CC
Bob has 120CC
Charlie has 50CC
Deborah has 10CC
Alice owes Bob 10CC
Alice owes Charlie 20CC
Charlie owes Bob 50CC
Bob owes Deborah 90CC
In reality, cryptocurrency ledgers are not tied to any other currency but instead track transactions in their own currency. Rather than endorse any real cryptocurrency, we’re just going to invent a new one that we’re going to call $CornellCoin$. So in our example we’re now going to use CC to represent the CornellCoin values. Everything about the ledger is exactly the same. So people start with a certain amount of CornellCoin, and then we can track transactions of who owes who CornellCoin.
As an aside, this is the reason that the value of cryptocurrencies fluctuates. Buying a Bitcoin for $1000, for instance, is fundamentally the same as buying a Euro for $ it’s just a currency exchange rate. Now a question you might ask about CornellCoin is “how does anyone get any CornellCoin to start with?” since we can’t just throw our existing dollars into the pot for transactions. Unlike traditional currencies like the dollar or the euro, new CornellCoins are not minted by a central authority. Why not? Well, that brings us to another key fact about cryptocurrencies.

6. Cryptocurrency: what is it?
It’s decentralized.
Alice
Bob
Charlie
Deborah
Cryptocurrencies are decentralized. This means there’s no single centralized entity that keeps track of all the transactions. In other words, everyone is keeping track of the ledger themselves, and broadcasting/listing to everyone’s updates.
So for contrast, this is unlike a bank for instance. A bank keeps a ledger on your account, adding money whenever your employer direct deposits into your account and subtracting whenever you use your debit cards to pay for goods. In that scenario the bank is a centralized entity that is the source of truth for a ledger.
But for CornellCoin, there isn’t any central bank or entity that acts as the source of truth, instead decentralizing the truth among all the participents.

7. Cryptocurrency: what is it?
It’s decentralized.
Issues that arise:
What is the source of truth? How do we know that everyone has the same ledger?
Need to guarantee some kind of consensus.
How is new money introduced to the system? And when? And to who?
“Work” -- more on this later!
So this raises a few issues… who or what defines the source of truth of what the state of the ledger is? Or phrased another way, how do we know that everyone has the same ledger? If people have different transactions on their ledgers, than the validation step of whether people have enough money for transactions would get out of sync, and there’d be no clear answer to how much money any individual has in the system. So if we want our ledgers to be decentralized, we’re going to need a way to ensure that there’s some way for all our participants to come to a consensus on what transactions are in the ledger. A few lectures from now we’re going to talk about some different algorithms that can be used to reach consensus.
And then there’s also the problem that we discussed earlier: how is new money introduced into the system? If there’s no centralized authority, who or what is empowered to create new CornellCoin and distribute them to the participants? And when should new money be created? If everyone can create new money arbitrarily, than they’ll make as much as they want and the currency will become worthless, so there needs to be some way to constrain how much CornellCoin is out there. It would also probably be nice to give the new CornellCoin to participants that are actually providing something to the system (rather than just distributing it arbitrarily) so that there is some intrinsic value to the currency and participants are motivated to be good actors. It turns out that sort of like being paid money for working in real life, we’ve going to use a notion of “work” for generating/distributing new CornellCoin as well. We’re going to go into more detail on what kind of “work” I mean in a future lecture.

8. Cryptocurrency: what is it?
It’s a ledger.
Alice owes Bob 10CC
Alice owes Charlie 20CC
Charlie owes Bob 50CC
Bob owes Deborah 90CC
Alice has 100CC
Bob has 120CC
Charlie has 50CC
Deborah has 10CC
CornellCoin Ledger
It’s public.
It’s decentralized.
So to recap, the three main things that define a cryptocurrency are that it’s a ledger of transactions, it’s public, and that it’s decentralized. That’s the end goal that we want to reach, and we’re going to talk in more detail about a few of the problems that we’re going to solve on our way there. The first thing we’re going to talk about is digital signatures, to solve some of the problems we talked about arising from the fact that our ledger is public. But first, we’re going to take a quick diversion into hashing to build up a foundation.

9. Digital Signatures

10. Digital Signatures Goal: Identify a particular person digitally
Verifiable by a third party
Not forgeable
So what do we mean when we’re talking about digital signatures? Much like a handwritten signature, we want it to be something that identifies a particular person (i.e. your signature is YOUR name, and the signature style is reasonably unique to you), we want it to be verifiable by another party (i.e. your signature is “legible” or matches the one on your driver’s license), and we don’t want it to be forgeable (otherwise what’s the point?).

11. Digital Signatures Why is this hard? Alice 011101100011101… Alice Bob
Charlie
Alice
This is a tricky problem, and there’s a reason why it’s not obviously possible to design a digital signature at all.
Let’s say we just did something really simple like literally digitize a handwritten signature. In this situation, let’s say Alice and Bob are making some sort of agreement, and Alice needs to sign Bob’s contract digitally. When Alice signs the document, she’ll make this signature available to Bob so that he can verify that it’s actually her. But at this point, Bob also just has all the bits that make up Alice’s signature. So there’s nothing stopping Bob from nefariously stealing Alice’s signature and impersonating her in a contract with Charlie. This would obviously be a massive problem for online commerce, as Alice will soon find out when Charlie comes looking for payment on the loan Bob took out in her name. In fact this forgery would be even worse than classic handwritten signature forgery insofar as that the forgery would be literally perfect (it’s exactly the same bits as if Alice had sent the signature).
So, we need to be clever to get around this forgery issue. There are two key insights we need to have in order to figure out how to handle this. First, one weakness of this basic (broken) signature is that the recipient (Bob) gets full information about the signature. If we don’t want him to be able to impersonate Alice, we need Alice to be able to keep some element of the signature or the signature generation process secret so Bob cannot reproduce it. Second, the signature in this first example has nothing to do with the contract being signed, so Bob can just pass it along in a completely different context. Ideally, Alice should be able to sign a particular document without giving the recipient the ability to use that information to sign arbitrary other documents.

12. Digital Signatures Key Generator
Produces a Public Key and Private/Secret Key
Example: RSA
Sign(message, private_key) -> signature
Not reversible (without private_key)
Output should appear uncorrelated with input
Verify(message, signature, public_key) -> boolean
Note: doesn’t involve the private key!
OK so given those insights, here’s what our digital signature algorithm is going to need. First, we need a key generator which will product a public key and a private key (which is sometimes called a secret key). In our example, Alice would broadcast the public key to whoever she’s making agreements with (more on that later), while the private key she will keep to herself. This private key is how we’re going to address that first insight about having some information Bob doesn’t have but would need in order to forge Alice’s signature.
Secondly, we want a function that takes a message and a user’s private key and produces a signature that represents signing the given message. So in our original example, the message would be the contract between Alice and Bob and the private key would be a secret that Alice keeps to herself and Bob never knows about. Note that both the message and the final signature will be available to Bob, so we need to make sure that whatever way we chose to generate the signature is not reversible so that Bob can back out the private key (sound familiar?). Ideally, even if Bob had access to the Sign algorithm, we’d want to make it so that the best way he has of figuring out Alice’s private key is to just brute force try every possible key along with the message to see which one produces the signature that he received (sound familiar??). If the size of the key is sufficiently big, this could be computationally “impossible” bits is generally sufficient (sound familiar???). To make sure that this isn’t reversible even with the algorithm at hand, we’d want an algorithm that makes it so even small changes to the input message create massively and seemingly random changes in the output signature (sound familiar????). For those who haven’t guessed it yet, this Sign algorithm is going to involve some cryptographic hashing.
Third, we need a Verify function that takes the message, the signature, and the public key and returns whether or not the signature is valid. This is important, as without it there would be no way for Bob to validate that the signature he was given actually represents anything at all, let alone Alice’s unique signature on their contract. Also note here that Verify doesn’t require or leak any information about Alice’s private key. All the information that Bob needs to run Verify are all things that were either already public or that Alice has intentionally made public.

13. Digital Signatures Bob Alice: pk pk Gen() -> pk, sk Alice Alice: pk
Charlie
OK so now what’s going to happen is that first Alice is going to use her key generator to create a public key and private key, and then she’s going to broadcast her public key to the world. Note here that not only is Bob hearing the public key but so is Charlie (which will be important later). At this point you might ask “well, how do Bob and Charlie know that it’s actually Alice who is sending them that public key?” which is a good question that we’ll get back to a bit later. For now let’s assume that Bob and Charlie both receive the public key and are confident that it’s associated with Alice.

14. Digital Signatures m pk,sk Alice: pk Alice Sign(m, sk) = s Bob
Verify(m,s,pk) = true
So now, when Bob sends Alice a message “m”, Alice can respond with a signature “s” which is the result of running the Sign function on the message and her secret key. When Bob receives “s”, he can use the public key earlier broadcast by Alice to verify that the signature he received was actually generated by Alice and that the signature is for the message that he had originally sent. So far so good: Alice has signed the document, and Bob can verify that fact.

15. Digital Signatures m2 Alice: pk Bob Alice: pk s Charlie “Alice”
Verify(m2,s,pk) = false
Now let’s look at Bob attempting to nefariously impersonate Alice. Remember that Charlie knows Alice by her public key, so if Bob wants to impersonate Alice he’s going to have to deal with the fact that Charlie will be using Alice’s public key to verify signatures. In this situation, when Charlie sends a message to Bob (note: a different message than the one Bob sent Alice), what does Bob do to impersonate Alice? He doesn’t have Alice’s private key, so he can’t just sign this new message and create a new signature. And since the message is part of the signing and verification process, he can’t just send along the signature that Alice had sent him earlier because it wouldn’t pass validation (since it’s the wrong message). So Bob isn’t able to forge Alice’s signature -- success!

16. Digital Signatures CornellCoin Ledger Alice owes Bob 100CC
Signed by Alice
Except… what if Charlie sent the exact same message that Bob had sent Alice? In that case the signature would be valid, since the parameters to Verify would be the same as they were in the intended signature flow between Alice and Bob. This is actually a real problem in the context of something like $CornellCoin$ where our messages are going to be items on a ledger. Let’s say Bob wants to add an item to our $CornellCoin$ ledger that says Alice owes him 100 $CornellCoin$. For that entry to be valid, he needs Alice to sign the message proving that she agrees she owes Bob 100 $CornellCoin$. However…

17. Digital Signatures CornellCoin Ledger Alice owes Bob 100CC
Signed by Alice
Alice owes Bob 100CC
Signed by Alice
Alice owes Bob 100CC
Signed by Alice
Alice owes Bob 100CC
Signed by Alice
Alice owes Bob 100CC
Signed by Alice
... what’s to stop Bob from now duplicating that same message and signature an arbitrary number of times in the ledger? The signature for each message will still be totally valid, despite the fact that Alice only ever intended to sign the first message and none of the subsequent ones.
The solution to this problem?

18. Digital Signatures CornellCoin Ledger 1. Alice owes Bob 100CC
Signed by Alice
2. Alice owes Bob 100CC
Signed by Alice
3. Alice owes Bob 100CC
Signed by Alice
4. Alice owes Bob 100CC
Signed by Alice
5. Alice owes Bob 100CC
Signed by Alice
Simple - just include a unique id on each ledger entry and include it as part of the signed message. Now, even though the “body” of the message is the same, the unique identifier that changes for every ledger entry is enough to invalidate the signature for subsequent entries, requiring Bob to get Alice to sign those entries independently (or have them not be accepted onto the ledger). The CornellCoin protocol itself will be responsible for ensuring that each ledger entry has a unique identifier.

19. Digital Signatures: Implementation
Implementation is for fun!
Presenting a (simplified) version of the RSA implementation
Prime numbers
Modulo arithmetic
Reminder: this is getting the remainder after division
10 mod 4 = 2
15 mod 5 = 0
Goal: Find e, d, n, such that (me)d ≡ m (mod n)
Should also be tricky to determine d given e, n, m
Examples taken from Wikipedia
OPTIONAL MATERIAL

20. Digital Signatures: KeyGen Implementation
Choose two prime numbers: p, q
Should be chosen randomly
Compute n = pq
Compute λ(n) = LCM((p-1, q-1))
Choose 1 < e < λ(n), such that e and λ(n) are coprime
Solve for d: d*e = 1 mod λ(n)
Public key: (n, e)
Private key: (n, d)
OPTIONAL MATERIAL

21. Digital Signatures: Implementation
Reminder: Find e, d, n, such that (me)d ≡ m (mod n)
Public key: (n, e) Private key: (n, d)
Sign(m, sk): md mod n
Verify(m, s, pk): se mod n == m
OPTIONAL MATERIAL

22. Digital Signatures: KeyGen Implementation Example
p = 61, q = 53
n = pq = 61*53 = 3233
λ(3233) = LCM(60, 52) = 780
Choose e = 17
Solve for d: d*17 = 1 mod 3233 → d = 413
Public key: (3233, 17)
Private key: (3233, 413)
OPTIONAL MATERIAL

23. Digital Signatures: Example
Bob
Alice: (3233, 17)
pk: (3233, 17)
pk = (3233, 17)
sk = (3233, 413)
Alice
Alice: (3233, 17)
Charlie
OPTIONAL MATERIAL

24. Digital Signatures: Example
pk = (3233, 17)
sk = (3233, 413)
Sign(m, sk) = md mod n mod 3233 = 588
Alice: (3233, 17)
Alice
Bob
Verify(m,s,pk) = (se mod n == m) mod 3233 == 65
OPTIONAL MATERIAL

25. Public/Private Key Encryption
pk = (3233, 17)
sk = (3233, 413)
Alice: (3233, 17)
Alice
Bob
m = 92
Decrypt(c,sk) = cd mod n mod 3233 = 92
Encrypt(m,pk) = me mod n 9217 mod 3233 = 2910
OPTIONAL MATERIAL

26. Digital Signatures Unanswered questions: Why on earth does this work?
How do Bob and Charlie know that the public key they received is actually from Alice?
Practically… not a technical solution. Certificate Authorities do the job.
Can the blockchain be used for this?
How do Bob and Charlie know that the public key they received really belongs to Alice? To be clear, they know that if the signature passes validation that the person on the other end must have the associated private key. But I’m talking more in the literal sense of how do they know that Alice is the person holding that public/private key pair, as opposed to Deborah? Well… the solution to this isn’t actually a technical one. In practice, Certificate Authorities exist as the source of truth for these associations, and real-world validation is required before Certificate Authorities validate the association between keys and real-world entities. An interesting thing to think about, though, is whether Certificate Authorities are another type of centralized “ledger” of sorts that can be decentralized on the blockchain. There are some blockchain implementations that try to serve this need, but they haven’t gained widespread use yet.