Lecture 1. Introduction: coordination and Bitcoin.

Coordination

• Centralized entities can effectively make decision on a large scale (government’s policies on military, public education, public healthcare, etc)
• Centralized entities can effectively maintain databases (paypal, facebook)
• Centralized entities can effectively stop people from stealing from each other, by promising to punish them (police)

Collusion

1. A dictator taking advantage of their power, by using citizens’ taxes to enrich themselves/their friends (by signing gov contracts with dictator’s friends), or sending country’s soldiers to a war that is destined to be lost.
2. A lobbyist giving a politician a bribe in exchange for that politician adopting the lobbyist's preferred policies.
3. Companies excessively raising their prices in a monopoly.
4. Discretionary censorship on social media platforms.
5. Facebook and other internet giants not sharing profits with their users, whose data and attention they are selling (if you think about it, this is the special case of 3.)
6. Banks not sharing revenues with depositors, justifying this by low interest rates environment (again, a special case of 3.)

Blockchain = collusion resistant coordination tool

• We cannot all trust each other, because there could be malicious actors. Thus we need our communication to be verifiable, and this leads us to cryptography, namely digital signatures.
• But also, how do we agree on a plan, without central authority? We need to have a consensus protocol.

Digital Signatures

• gen() [output is two strings (priv_key, pub_key)] → (priv_key, pub_key) This is a generating function with no input, which outputs initial pair of strings: Alice keeps priv_key secret, while pub_key represents an “address” of Alice, and is known to everyone. The two keys are connected in a special way, such that the two functions below work as described.
• sign(priv_key, message) [output is a string sig] → sig This function allows Alice (since only she knows priv_key) to “sign” any message with a private key, and outputs a signature string sig. Note that, unlike real life signatures, digital signatures depend on the message
• verify(pub_key, message, sig) [output is True or False] → True, if sign(priv_key, message)=sig → False, otherwise This function allows anyone to verify whether sig was indeed obtained by signing message with priv_key.

• Digital signatures are unforgeable, i.e. no one can generate a signature sig except Alice. This ensures that if the verify function is True, we definitely know that the message was signed by Alice.

Hash functions

• hash(any-length-message) [output = 256bit number (fixed length!)]

• Irreversibility: given y, it is infeasible to find x such that hash(x)=y
• Collision resistance: given x, it is infeasible to find x’ such that hash(x)=hash(x’)
• Uniform randomness: large number of possible outputs, each occurring with roughly the same small probability.

Introduction to Bitcoin

1. Alice tries to send Bob some digital file as an “e-coin”.


Problem: copying this kind of money is very easy.

2. Alice cryptographically signs a message of type “Alice sends Bob 2 e-coins”


Benefit: nobody can do it, except Alice, and also we can be sure that Alice did it.

Problem: what if Alice sends 3 such messages to Bob? Did she send 2 or 6 e-coins?

3. Alice cryptographically signs messages of type “Alice_tx#174: send Bob 2 e-coins”


Benefit: if Alice sends Bob 3 identical messages “Alice_tx#174: send Bob 2 e-coins” then she sent 2 e-coins. If Alice sends Bob 3 messages “Alice_tx#174: send Bob 2 e-coins” “Alice_tx#175: send Bob 2 e-coins” “Alice_tx#176: send Bob 2 e-coins” then she sent 6 e-coins.

Remark: this is a solution used in Ethereum blockchain. In Bitcoin the coins themselves are numbered, not the transactions; see “the UTXO model” secction at the end.

🔴
Key problem: double-spending is possible. Alice, having 2 e-coins in total, can send them first to Bob and then to Charlie. We need some mechanism to monitor the balances.

4. Some trusted centralized entity (bank) is watching the balances.


Bank does two things: (1) Validating txs = checking whether the signature is valid = checking whether the balance allows for the spend (2) Confirming txs = accepting the tx, and updating the balances of Alice and Bob

Benefit: no double-spending.

Problem: banks have an enormous power by controlling people’s balances ⇒ their economic incentives are skewed towards collusion.

Remark 1: in reality we have a much bigger problem:

🔴
Key problem: banks are not simply “watching our balances”, we actually give our capital to them. As such, banks have an enormous power by controlling people’s money.

Even though it seems that banks holding our money are providing services “for free”, this is far from truth — in reality, banks extract quite a lot of value from their clients’ capital, by investing the capital into relatively safe assets like gov treasuries, ETFs, etc. Key idea here is that “being able to manage someone’s capital” has value. This is the reason for why banks often pay their customers, especially to attract new customers. (Since “changing a bank” is an extremely rare occasion in practice, banks do not worry as much about retaining customers.)

Remark 2: even if banks would just maintain a ledger of our monies (”watch the balances” as opposed to “have the balances”), they still would have too much power and therefore heavily skewed economic incentives. (As an example: we will stop watching your balances unless you deposit your money to us.)

5. Substitute bank by a set of nodes: node maintain (validate the signatures/balances) a shared ledger of balances.


Benefit: no centralized control ⇒ no collusion.

Remark 1: since there is many transactions, it is convenient to confirm (=validate signatures/balances) txs in “batches”, or, as we call them, blocks. As a result, we obtain a data structure called block chain. We add in there hashes to make it tamper-evident.



Remark 2: in reality, the division between users / nodes happens by downloading different kinds of open-source software. The fact that it is open-source is extremely important to eliminate security/centralization risks. Another extremely important consequence is that anyone can download and run software, and so therefore anyone can become a node in the network — this makes the system permissionless.

Problem: free-ride problem — people will happily use such a public good type of a service, but why would nodes actually maintain the ledger?

6. Introduce fees: Alice signs messages of type “Alice_tx#174: Alice sends Bob 2 e-coins, and pays 0.1 e-coin as a fee to the node validating this tx”.


Benefit: nodes now have an economic incentive to maintain the network.

Problem: double-spending is still possible for Alice — she, having only 2.1 e-coins, can simultaneously (1) send 2 e-coins to Bob and broadcast it to one set of nodes; (2) send 2 e-coins to Charlie and broadcast it to another set of nodes.



Thus we need a way for nodes to stay in sync. We say that nodes need to achieve consensus.

7. Make nodes do some sort of cross-checking, in order for them to achieve consensus (stay in sync). Achieving consensus means that they all agree on the same set of confirmed transactions.


Benefit: solves double-spending problem.

Problem: since our system is permissionless, Alice can spin up her own malicious nodes, in order to highjack the cross-checking part. Broadly speaking, our system is is vulnerable to Sybil attacks […], which means that anyone can spin more than one node and thus increase their voting power.

Important remark: there are ways to tackle this problem in the permissioned setting (where nodes know each other in advance), but nobody before Satoshi Nakamoto figured out how to build both permissionless and sybil-resistant electronic money. In his ground-breaking paper, he introduced two novel ideas:

1. Longest-chain consensus mechanism (instead of cross-checking idea);
2. Proof-of-work sybil-resistance (made possible by the mechanics of 1.
8. Use longest-chain consensus instead of cross-checking: once a node has a valid block of txs, it simply appends it to the blockchain and broadcasts this new blockchain to others.


Of course, there will be competing blocks (forks), simply because nodes may create blocks simultaneously or because there are some malicious blocks. Thus our data structure is no longer a block chain, but rather is an in-tree.



So the question is which chain of the in-tree is considered “correct”?

🟢
The key idea: the longest-chain is the correct chain, and nodes that create blocks always build on top of the longest chain.


If there is a tie (several longest chains), just wait a bit and one of the chains will start winning. As soon as it wins just a little, all honest nodes start building on it and it starts to win confidently.

Problem: this system still suffers from Sybil attacks, because blocks can be “rolled back” or “reorganized” if malicious nodes build up a longer chain:



So we need to somehow make sure that there is <49% malicious nodes.

9. Use proof-of-work as a sybil-resistance mechanism: make it computationally costly to create blocks. In more detail: - Alice broadcasts “Alice_tx#174: Alice sends Bob 2 e-coins; fee = 0.1 e-coin”. - A node (say David) adds this message to their pending queue of txs. - Then David, after checking if txs add up and valid, first solves the proof-of-work puzzle which requires computational power (see 🟢 below), and only then appends the block to the longest chain.

🟢
Proof-of-work puzzle: a node David, having a potential block B that he wants to append, needs to find a number of n such that hash(n || B) starts with say 30 zeroes. Since hash function is random, such an output is rare, so “finding n such that hash(n || B) starts with say 30 zeroes” proves that David used a low of computational power (probabilistically).

Benefit: the system transforms from “one-node-one-vote” to “one-CPU-one-vote”. So in order to perform the reorg attack, malicious actor would need to have >51% of computational power on the network.

This is a great way to mitigate Sybil attacks, since it is much harder to obtain >51% computational power in the network, rather than >51% of the number of nodes in the network.

Terminology: to mine means to solve the proof-of-work puzzle. This is why in Bitcoin nodes are often called miners.

Problem: why would David waste a lot of his electricity on this mining… Any why is it called “mining”? :)

10. Reward nodes for mining by inflating the total supply of e-coins.


Benefit: miners have the incentive to perform validation / mining.

Problem: we infinitely inflate the total supply of e-coins, and their value depreciates.

11. Make rewards decrease by 50% each 4 years. This way the total supply of e-coins will be capped.

In Bitcoin reward halves every 210,000 validated blocks ~ 4 years. Initially it was 50 BTC, now it is 6.25 BTC.

Remark: whether or not this will work in the future is not clear at all, since currently Bitcoin fees are not enough to make Bitcoin mining profitable.

The UTXO model