Introduction to Bitcoin

In the previous module, we'd examined the

technology behind a generic blockchain as a

decentralized database. In this module, we

look at a couple of examples of how

this technology is actually implemented

and start to examine some of the economic and

business aspects as well. Will start by looking at Bitcoin, which is really what kicked off the whole blockchain boom. At its core, the bitcoin is a decentralized ledger database. That is, instead of

storing any kind of data, the Bitcoin blockchain

is a very specialized, limited purpose

database that is really designed to accommodate

simple transaction data. In other words, the main data transmitted to and stored on the blockchain is in the format of who paid whom and how much. If we go back in history, you'll find that when it

was launched in 2009, the original vision was quite different than what it is now. The goal was to

serve as a flexible, low-cost payment system

like PayPal that everyone can use on their phones for payments large and small. But, unlike PayPal,

it will replace the bank-based payment rails

like ACH or credit cards, with the peer-to-peer blockchain, cutting out banks altogether. In fact, the designer seemed to have a

profound distrust for existing financial intermediaries

and really envisioned Bitcoin to be a digital

replacement to fiat currencies. Themes like no central

control of the system and total anonymity are often highlighted as the core features. Then over a decade

into existence, we now know that reality

was quite different because of a combination of

technical limitations and economic factors. We'll go over these

in the next videos, but in a nutshell, we realized it wasn't going to be a good payment system because it can't just handle that many, seven payments per

second and max capacity. Also, economically,

people were certainly not that keen on cutting

out the central banks. Consequently, payment

usage decline, and processing fees remain high. Moreover, the consensus

mechanism, while very innovative, is extremely energy inefficient, which ironically resulted in a significant degree

of centralization. Therefore, currently, Bitcoin exists somewhat

like a digital gold or a digital treasure whose

intrinsic value is hard to pin down and a lot of it is

driven by investor sentiment. Technologically, now that we know the generic

blockchain technology, it's very easy to define Bitcoin. Remember, we looked at the blockchain as a decentralized

database consisting of three parts: the user application that maintains user identities

and generates the data, the peer-to-peer network of

nodes that receives the data and "processes" the data

with a consensus protocol, and the database itself, which stores data in a unique chain format using hash pointers

and linked list. Here's the Bitcoin implementation

of this technology. The user application is

called a Bitcoin wallet. If you want to send

or receive Bitcoins, you could write a

script yourself, but more often than not, you'll be using a

wallet app to generate the transaction data and

broadcast it to the network. Sometimes the wallet

app could be used as a identity management tool as well and store your private keys. Second, the nodes of the Bitcoin network

are called miners. They're the ones processing

the transaction data by running some simple validation

tasks like checking your crypto signatures and

organizing the data into blocks following the

so-called UTXO principle, which we'll review shortly. In the Bitcoin network, consensus across nodes

are reached using a protocol called

proof-of-work or mining, which is a major

innovation of Bitcoin. Again, data on the

Bitcoin database is limited to the

transaction records in the form of who paid who, how much, and when

and is stored using the generic hash pointers and linked lists to

facilitate searching. Now, once we move from a generic technology to an actual business

implementation, there are several key concerns

that we need to address. First, we can't just use the generic random

consensus protocol from the previous module. As we saw, it's way too vulnerable to

double-spend attacks. So we need a more

robust consensus. Second, it all sounds

fine and dandy on paper, but how do we actually get

the network up to scale? Obviously, people

are not going to contribute their

computing resources and participate as nodes for free so they need to be

incentivized to do so. There needs to be a reward

structure that encourages nodes to maintain the network so that it doesn't

fall into disuse. We'll explore these topics in this and the next few videos. First, let's take a deeper

look at the data structure, which is the easiest

component to understand. Because the data is limited

to transactions only, the Bitcoin blockchain is really a true ledger that records just who has paid

how much to whom, and if you recall the final

video from the last module, from the actual data, most of these transactions seem to have two or more recipients. Now, let's see why. Consider

this chain of transactions. Andrew, the miner,

mined 100 coins. He then paid 80 coins to Bob, who in turn paid

15 coins to Carol. Carol, then paid 10

coins back to Andrew, and finally, Andrew

paid David 25 coins. How do you do it on an

actual paper ledger? Well, you'll probably just write these five statements down. In the Bitcoin

blockchain, however, these transactions are stored as input-output list to take advantage of the hash pointers

to facilitate searching. The gist of the model is that most transactions have to have both the input field and the output field and

they have to be equal. The exception is the

first transaction in the block which is called

the coinbase transaction. In this transaction,

there's no input and the 100 coins are minted out of thin air and awarded

to the miner Andrew. Now things get more interesting. When Andrew pays Bob 80 coins, he will generate and broadcast the transaction where

in the input field, he will include a

hash pointer pointing to his receipt of the

100 coins before. This is like including a piece of evidence of him

receiving the coins. Now critically as the output, in addition to giving

Bob the 80 coins, he has to include himself as the recipient and

send the remainder, the 20 coins, back to himself. In other words, the

previous transaction that Andrew referred

as the evidence, must be fully consumed. Why? Well, if you think about it, this really makes

searching easier because instead of traversing

all the way up the chain, you only need to

search back one step. Let's keep going down the ledger to see more of this in action. When Bob pays Carol 15 coins, he will include as

evidence the transaction where his address received

the 80 coins from Andrew. In the output field, he'll send 15 to Carol

and 65 back to himself. Similarly, when Carol

pays Andrew 10 coins, she will include

the transaction of her receiving 15 coins as evidence and send 10 to Andrew

and five back to herself. Finally, when Andrew wants

to pay David 25 coins, he has to include two inputs because only the sum of the two can cover the transaction. He'll reference the transaction

where he received 20 from himself and the transaction where he received 10 from Carol. This sums up to 30 coins. So he pays David 25 as the output and five

coins back to himself. As you can see, for a miner validating

these transactions, the task is quite easy. Remember the scripts: check, seek, and equal verify. Instead of searching

through the entire chain, which could take some time, they simply check the signatures, then check the input and the output of the

transaction to make sure they sum up

equally and if they do, is guaranteed by design to

be a valid transaction. This is called the

UTXO principle, and the goal is to enhance the efficiency in

transaction verification.