Introduction to Bitcoin and Decentralized Technology

1. Big Ideas & Basic Use Demos Bitcoin Introduction and Demonstration Hi! My name is Scott Driscoll. Welcome to An Introduction to Bitcoin and Decentralized Technology. The goal of this course is to provide a high-level understanding of bitcoin and the decentralized technology surrounding it. You should walk away with a clear idea of just what Bitcoin is, how it works, and also where it and similar technology can be used including monetary applications like sending money to non-monetary ones like storage, decentralized computing, prediction markets, identity, and even organizations or governments. This first module will discuss the big ideas behind Bitcoin while also giving some basic hands-on demonstrations on how to use it including where to get Bitcoin and how to set up a wallet to hold, send, and receive it. Before we get too philosophical or technical, I want to simply demonstrate using Bitcoin as I find seeing it in action helps demystify it. I'm going to buy a digital video on a website called watchmybit.com. Here's one for 20 cents. After I click on it, it shows me a payment address in the form of a QR code. This 2D code contains both a receiver's address and amount to pay. I'm going to use what's called a wallet app to scan this code. After I scan, you can see the amount and address here. I hit Send, go back to the website, and after a brief time, the video has unlocked and plays. I like this example because it highlights some features of Bitcoin that distinguish it from other payment methods like credit cards or PayPal. First, I never logged into this website. All this site knows about me is my IP address. Bitcoin is very much like an electronic version of cash. I give the site money, it gives me a video. There's no need for me to reveal my home address, zip code, or even an email address. Privacy is one of the big ideas central to Bitcoin. In a world where financial and personal information is continually getting stolen, minimizing the sharing of that information is one of the best protections. I didn't have to give my credit card information to this site in the hope that it wouldn't misuse it in the future. I pushed the payment to the vendor rather than giving them info for them to pull it from me. Despite my not sharing any information here, I should warn that it is still extremely difficult to remain completely anonymous on Bitcoin, but the core design does offer the promise of increased privacy both for end users and the people helping run the Bitcoin network. So how did this site unlock the video for me if it doesn't know who I am? It created a unique Bitcoin address just for my connection and then played the video when money arrived. The owner of this site was able to create this system without creating an account with a bank or a credit card. Bitcoin is open both in terms of its source code and access to the network. To create an application, you just need to write software that uses the correct protocol. Speaking of open, anyone can actually look up this transaction I just made on blockchain.info and several other sites. If I type in the transaction Id, you can see the From address, To address, and amount. How is it that every transaction is publicly visible, yet Bitcoin still provides privacy? Note that there are no names or even IP addresses here, only Bitcoin addresses. So every transaction is public, but the identities are private as long as you can't connect a Bitcoin address to a real identity. Another detail on this page, there's a fee of about 3 cents that I paid to send 25 cents. Unlike credit card transactions or even PayPal for which fees are typically over 30 cents, the fees in Bitcoin are potentially much lower. Low fees open the possibility for micro-transactions like this video, but interestingly, they also apply to high-value transactions as well making Bitcoin a very competitive alternative to international wire transfers. One other difference about Bitcoin transactions is that they're irreversible. This can be seen as both a benefit and a liability. The merchant doesn't have to worry about charge backs, but as a customer, I can't call a credit card company to intervene. I would need to use an escrow service if I was concerned about a receiving party following through on a commitment. Now that I've shown you a quick example of using Bitcoin, I'll describe it more generally. Bitcoin is a decentralized digital currency that enables people to electronically transfer money across the globe as easily as sending an email. Let's look at an example of Bob buying a lawn mower from Carol to begin understanding just what Bitcoin is under the hood. Unlike a service such as PayPal or a national currency like the US dollar, Bitcoin is not controlled by any one company or government. It's maintained by a network of people running Bitcoin server node software who I'll call bookkeepers, and anyone can participate. At its most basic level, each bookkeeper is simply keeping a ledger. When Bob wants to send Carol 5.2 Bitcoins for a lawnmower, he broadcasts a transaction message that contains his account number, Carol's account number, and the amount in Bitcoins to send. Bookkeepers receive this message and adjust Bob's balance down and Carol's up. They then pass the transaction message along to other bookkeepers who update their ledgers. Despite all the jargon and complexity you might have heard about Bitcoin, at its simplest level, bitcoin is just a group of people maintaining a ledger. Now why would anyone trade a lawnmower or anything else real for a higher number in this ledger? In other words, what gives these numbers any value? The same thing that gives the US dollar or Euro value--faith. Faith that when I trade something real like a stereo for a piece of payer, later on other people will also trade real goods and services for those pieces of paper. Now, of course, Bitcoin does have some fundamental features that have enabled the world to build faith in it. The supply of Bitcoin is strictly limited arguably making it more scarce than the US dollar, which the central bank can print more of at any time. Bitcoin is also easily transferrable as we saw in the demo worldwide for low or large amounts. And Bitcoin is secure. The numbers in the ledger can't be changed unfairly either by a hacker stealing from your account or by the bookkeepers manipulating the ledger.


2. Individual Account Security and Decentralization Motivation Let's start diving into the security behind Bitcoin, how it prevents any unauthorized changes to balances in that ledger. Another word used to describe Bitcoin is cryptocurrency, which I'm including as one of the big ideas behind Bitcoin. It gets this name because Bitcoin relies on several cryptographic algorithms to secure many aspects of its operation. To begin, when Bob sends a transaction giving money to Alice, he signs it with a cryptographic digital signature so that bookkeepers have proof that Bob and only Bob authorized that transaction. Cryptographic digital signatures perform the same function as their handwritten counterparts on pen and paper to prove authorization but are much better for the digital world. While a handwritten signature could be forged or copied and reused, digital signatures are based on each specific transaction. This prevents hackers from reusing a previous digital signature on another transaction or modifying even a single character of a transaction as it's passed around the network. The digital signatures that secure individual transactions are a fundamental piece of every Bitcoin account or address. Digital signatures are based on public key encryption, which I'll explain more in the next module. For now, know that each Bitcoin account or address is basically a public key. A mathematically related private key is the password that lets you generate digital signatures to spend money. In addition to projecting individual accounts, cryptography also underlies the system that keeps the bookkeepers honest. But before we get into those details, we should ask, Why multiple bookkeepers? Why decentralization? As I mentioned previously, unlike a government currency or a single company like PayPal, Bitcoin is operated by a group of peers, which is why it's referred to as peer-to-peer technology. While a centralized system would be much simpler, the decentralized nature of Bitcoin offers several benefits and is arguably the main innovation of Bitcoin. When control is centralized, the system is subject to a single point of failure. That failure could be the result of internal abuse, outside attack, or censorship. For example, many currencies have experienced hyperinflation as governments pay bills by printing money. Zimbabwe printed money around the year 2000 to finance a war in government operations eventually leading to hyperinflation, the rate of which reached over 230 billion percent in 2008. Even if a single company were trustworthy, it could still be subject to attack from hackers or governments. E-Gold was a company that faced both of these problems. It operated from 1996 to 2008 and allowed users to send gold electronically peaking at $2 billion of annual transfers. It was an attractive target of money launderers and phishing attacks. And eventually the US government prosecuted and shut down the company for operating without sufficient licenses. PayPal has avoided the fate of E-Gold by implementing many policies aimed at preventing fraud and by better complying with government regulations, but it is often criticized for censorship and unfair freezing of accounts. Now I in no way want to disparage PayPal, which I believe offers a fantastic service in the face of incredibly complex and shifting regulations and fraud attacks. However, I will quickly point out several restricted areas outlined on its website including adult, gambling, and weapons industries. I won't comment on whether these restrictions are right or wrong, only that it's fully within this single company's choice on what business strategy and policies it maintains. Now given these examples, I don't want to claim that a decentralized system would be immune to similar problems, but it is hoped that avoiding a central point of failure will provide a more resilient system. Even big banks have begun investigating the use of some of the decentralized technology behind Bitcoin to reduce the need for trust when exchanging money or settling accounts between each other. In this case, all participants are fully identified and one would assume reasonably trustworthy or accountable. Yet they are still interest in taking a jointly controlled approach. This provides increased visibility and accountability, removes the cost of a centralized clearing and settlement house, and also makes it easier to automate processes across company borders.


3. Keeping the Bookkeepers Synchronized and Honest Now that I've given some rationale for decentralization, let's get back to the security behind Bitcoin, the foundation for why people place value in Bitcoins. We already mentioned that cryptographic digital signatures let the bookkeepers know if a transaction was from a real account owner, but what keeps the bookkeepers themselves honest? What would stop, for instance, a bookkeeper from adding money to his own account? Interestingly, this is in fact how new Bitcoins are generated. Periodically, in return for helping maintain the network, bookkeepers are allowed to add money to their own account, thereby creating money out of thin air. But this is only allowed according to very constrained rules. Those rules include a gradual slowing down of the rate of new money creation until eventually no more money will be created. So how can we be sure all the bookkeepers are following these rules and not adding extra money into the system like the Zimbabwe government? And how can we be sure any one given bookkeeper is using the same rules as all the others? What if two bookkeepers send different ledgers. Who should be trusted? Before answering these questions, note that even without dishonest bookkeepers, it's no trivial task to keep a worldwide network of ledgers in sync. Permit me to take a short digression to talk about the simple-sounding task of deciding whether one transaction came before another. With a centralized server, such as PayPal, transaction order is based on the order transactions are recorded in the centralized server. But in Bitcoin, transactions often reach different bookkeepers in different orders depending on routes and whether a bookkeeper is online. And this opens the door for fraud and confusion. Consider if Bob only had 5 Bitcoins but tried to spend them twice by sending them to Alice and Carol at the same time. Some bookkeepers would receive Alice's transaction first, reduce Bob's balance to 0 and then consider Carol's transaction invalid since Bob already spent all his money. Other bookkeepers receiving the transactions in the opposite order would reach the opposite conclusion that Carol should be the rightful owner. The bookkeepers would have no way to determine which account should hold the money. So the bookkeepers need a way to decide on order and agree with each other about it. And they also need to agree on what version of software and rules to run including mundane things like transaction format to fundamental ones like how fast new money should be created. Bitcoin's solution to this problem is a kind of math-based voting system that allows the bookkeepers to decide what the majority thinks. In a typical vote, participants register with a central authority that enforces one vote per person. But in a pseudonymous system on the internet like Bitcoin, it would be trivial for one person to pretend to be many others to sway the vote. This is known as a Sybil attack named after a woman with dissociative identity disorder. Instead, Bitcoin requires bookkeepers to solve a very special math problem to vote. In this way, voting has a cost in terms of electricity and computing power making it prohibitively expensive for any single person or group to control the vote. This concept is known as proof-of-work and is explained in the original Bitcoin white paper as one vote per CPU instead of one vote per person. Since transactions are continuously being generated, a new vote happens about once every 10 minutes to allow all the bookkeepers to stay synchronized. Each new group of transactions that gets approved is called a block, and these blocks are linked together in a chain called the blockchain. We'll get into more details about how this voting process really works in the next section, but I'll make two brief comments about the math now. The links here are made by using the answer of a previous block as an input to the next block's problem. In this way, blocks get buried under more and more votes or work therefore securing transactions more and more the farther back they get. Second, the math being solved also from the world of cryptography is exceptionally special. There's a clear relationship between the solutions and work required, which allows anyone to look at the solutions and have proof-of-work done or effectively which ledger the majority supports. So amazingly, we have an anonymous voting system that provides mathematical proof of its results with no central registration and vote counting authority to trust. Overall, this is another big idea behind Bitcoin--minimizing trust. On an individual account level, only the account owner can send money by creating a digital signature. There's no bank or third-party service that sits in between two people sending money to each other. Even a bookkeeper couldn't change a balance as other bookkeepers would reject any change that didn't include a valid digital signature. While you do have to trust the bookkeeper network to some extent, the fact that it's decentralized makes it resilient against failure, censorship, or abuse. You can also download and verify the entire ledger and, in fact, its entire history at any time. The trustless and decentralized nature of Bitcoin does come at a cost however. If you lose the password to your account known as its private key, there's no one that can help, including the bookkeepers. In fact, when a private key is lost, that money is effectively destroyed. Also the decentralized network of bookkeepers is not nearly as efficient as a centralized server for sending transactions. It's recommended that you wait at least an hour after sending a high value transaction to make sure the network has fully agreed on and accepted it. The proof-of-work voting mechanism by design requires a substantial amount of energy. And, finally, it can be difficult to implement new features or fixes to the software as a majority of the bookkeepers must agree to the changes.


4. Programmable Money Example and Big Ideas Summary Before we get to some hands-on basic use demonstrations, I want to point out one more example that illustrates a final big idea--programmable money. In addition to sending money between people, digital currency opens up the possibility for programming rules into transactions to make smart contracts. Recently, companies like Kickstarter and Indiegogo have enabled entrepreneurs and creators to crowd source funding by raising small amounts from many people. These companies only release the funds to the creators if enough money is raised for their project to be successful. This same idea could be programmed into a digital currency so that funds are locked until a threshold is met or after a certain time returned to the original senders, all without the cost of a third party or the risk that the third party might take the money for themselves. In review so far, Bitcoin is a decentralized digital currency that enables email-like sending of money. The money is not based on anything physical but, rather, a system of math-based rules that effectively turn numbers in a ledger into a scarce resource. Cryptography protects those numbers ensuring individual accounts cannot be robbed and also keeping a network of bookkeepers synchronized and verifiably honest. The overall system provides some exciting opportunities to improve existing financial systems by limiting third-party risk, increasing privacy, reducing cost, and adding entirely new ways to program money in contracts.


5. Where to Get Bitcoin Let's now go over some basics about how to use Bitcoin starting with how to get it. The easiest way to get Bitcoin is to buy some at an exchange. I'll demonstrate this on Coinbase.com, an exchange where US and European customers can fund accounts via wire transfer or even credit cards. When you first sign up, you'll need to provide some identification and bank information that can vary depending on how much you want to buy and where you're located. After that, you simply go to the Buy/Sell page, enter the amount, and click the Buy button. If you've linked a credit card, small amounts will become available instantly. If not, the time largely depends on how long it takes the bank to send funds, which with the US ACH system is three to five business days. Coinbase charges a 1% fee for the exchange. A small note about privacy and exchanges. In the US, companies that transmit money are required to comply with a number of laws to prevent terrorism financing, fraud, and money laundering. These laws require exchanges to know their customers and monitor transactions for any risky behavior. So while sending and receiving Bitcoin can be done relatively anonymously, exchanging it with fiat currency usually requires revealing identity. While exchanges are typically The most convenient and cheapest way to buy Bitcoins, you can also get Bitcoin at some Bitcoin ATMs and in person-to-person exchanges. There are several ATM directories online including one at the Bitcoin news site Coindesk and coinatmradar.com. These maps give you details about the costs, limits, and which direction the ATM operates. Unlike regular ATMs, most Bitcoin ATMs only work in one direction--cash in, Bitcoin out and not the other way. One good way to find others willing to buy and sell is through Bitcoin meetups. There is also an eBay-like site called LocalBitcoins.com that helps buyers and sellers find each other complete with a reputation system. It also facilitates online trades by operating an escrow service that holds funds until a transfer is verified. Note that many ATM and in-person trades will cost much more than exchanges. A 10% fee or higher is not uncommon. Also, many traders on LocalBitcoins have minimums in the hundreds of dollars.


6. Wallets: How to Store, Send, and Receive Bitcoin If you decide to purchase Bitcoins locally or at an ATM, how do you receive them and hold them? Bitcoins are held is what is called a wallet. For example, I used a wallet app called Airbitz at the beginning of this course to send Bitcoins to purchase the video. Wallets generally facilitate sending and receiving money, as well as listing your balance and transactions. I'll demonstrate receiving money on the mycelium wallet. You simply tap the Receive button and are presented with a QR code. You can show this to another person that has a phone-based wallet to scan or at an ATM to scan. You can also copy and paste the Bitcoin address shown here and send that in an email. The QR codes from this wallet also allow you to include a request amount. When the code is scanned, the other wallet will auto-fill in the amount. Wallets don't just come in the form of smartphone apps. There are also online web page-based wallets, such as Blockchain.info. Online wallets contain many of the same features including a transaction log and forms to send and receive money. When choosing a wallet, a great resource is Bitcoin.org, which lists many, along with pros and cons. Many have differences in terms of features and security. A new feature on some is multi-signatures, which, for example, would allow officers in an organization to spend money only if two of three authorize it. Some wallets provide increased privacy through TOR connections and by creating new addresses for every transaction. On the security side, the most secure are full nodes, which are actually what the bookkeepers run and check every transaction in the entire world independently, while the wallets don't have the resources to do this and often connect to a sampling of bookkeepers or trusted third parties. One of the most important considerations is where the private keys are held. In Bitcoin, the private keys are what ultimately control funds. The term 'private key' comes from public key cryptography, the encryption scheme behind the digital signatures that protect individual accounts. Unlike the password to your bank account, if the private keys to your Bitcoin wallet are lost, there is no way to access your funds. People often use the phrase Be Your Own Bank with Bitcoin, and this is because you and you alone hold access to your funds. Many wallets like Mycelium, Airbitz, and blockchain.info advertise as never having access to the private key. This is good in that there's no way they can steal your funds. However, it also means if you lose your password to the apps and don't have a backup, your funds will be irrevocably lost. That money will effectively be erased from the world. Coinbase, the exchange where I showed purchasing Bitcoin, also has an online wallet. Unlike the other wallets I just mentioned, Coinbase does control the private keys of any Bitcoin balance it shows. While this would allow Coinbase to abscond with your funds and face legal consequences, it also makes it less likely that you would lose your money due to user error. At its most basic level, a wallet is simply a private key or collection of private keys. You can generate a paper wallet that is simply a private key and its associated Bitcoin address at Bitcoin.paperwallet.com or bitaddress.org. I moved my mouse around to generate a random number, and then client-side code generates a Bitcoin address and corresponding private key. I like showing a paper wallet because it will hopefully clarify just what it means to hold Bitcoin. If I send funds to this Bitcoin address, the bookkeepers in the network will update their ledger to show that amount for that Bitcoin address or account. Then only a person that knows the corresponding private key will be able to create an authorized request to move that balance to someone else. So we see that holding Bitcoin really means holding a private key or password to enable transferring those coins. For storing large amounts of Bitcoin, it's recommended that you use cold storage, which means sending Bitcoin to an address that never touched the internet. The paper wallet site I just showed recommends you download the sites HTML code, transfer it to a computer not on the internet, and then generate the address there to avoid any risk of the private key being stolen. There are also hardware-based wallets like Ledger and TREZOR that help to shield private keys from the internet. These wallets sign transactions internally without ever exposing a private key to the internet. I'll demonstrate TREZOR briefly. I'm using it with a desktop software wallet called Electrum. I first create a transaction in Electrum by entering a receiving address and amount. I then plug in the TREZOR and enter a pin using a combination of a blank keypad on my monitor and the TREZOR's display. This is so a virus recording my screen can't learn my pin. Both TREZOR and Ledger are designed to be secure even if using an infected computer. Finally, I confirm the receiving address on the TREZOR. It signs the transaction and sends it back to the computer, which then broadcasts it to the Bitcoin network. Whatever wallet you use, it's important to make backups especially if using a wallet whose developer or company does not have access to the private keys. A backup can take the form of a file that's encrypted with a password or in the case of Mycelium, a list of 12 to 24 random words. The wallet app can reconstruct the private keys and addresses just from these words. If you memorize these words, you now have what's called a brain wallet. It's a somewhat astonishing idea. Millions of dollars can be held in a memory and nowhere else.


7. Bitcoin Mining The one other method of requiring Bitcoin that I should mention is called mining. This was possible back in 2013 and earlier but is no longer a cost effective option. I'll take a brief moment to explain mining, a term I feel is very misleading, and also why it's no longer cost effective. The computation done to mine Bitcoin is actually the proof-of-work computation that the bookkeepers use in the voting process described earlier. Each time the bookkeepers vote, some new Bitcoin is awarded to the bookkeepers in proportion to how much computational work they have done. Because the bookkeepers are effectively finding new money through this computational voting process, they are commonly called miners although their main role is to maintain a ledger, not to create new money. The voting system simply provides a somewhat random way to slowly distribute money into the world. In fact, the rules state that the rate of new money creation will cut in half every four years until around 2140, at which point no more money will be issued. At this point, the bookkeepers will still be checking transactions and voting to synchronize with each other but will not be finding new money and will only be compensated by transaction fees. The reason mining is no longer cost effective for individuals is that substantial specialized hardware and cheap power is needed to be competitive. Using a computer's CPU or graphics card will likely cost more than any Bitcoin returned.


8. Accepting Bitcoin on a Website A final hands-on use case I want to demonstrate is accepting Bitcoin on a website. I'm going to showcase two products, one from BitPay and another from Mycelium. To accept Bitcoin using BitPay, you make an account and then go to the Payment Tools tab. From there, you can select from several tools such as a point of sale app that runs on an iPad, a hosted catalog, or just a simple button, which is what I'm going to show here. Once the code is generated, simply paste it into an HTML file, and the button shows up. When someone clicks Buy, they're taken to a page with a unique Bitcoin address on it. After payment is sent, they're returned to a URL you specify, and an email is sent out. The best part of BitPay is that they will automatically convert sales income into fiat currency and deposit that straight into your bank account. This enables you to accept Bitcoin without having to hold it and worry about the exchange rate changing. Note that the more money you accept, the more information you'll need to provide BitPay in order for it to comply with regulations. The Mycelium Gear is a very new tool that also makes it easy to accept Bitcoin on a website. Mycelium has built-in support for popular platforms like WordPress and Drupal, but you can also generate HTML like we did with BitPay. First, you need to install the Mycelium wallet on an Android or iOS device. Then export the public key, which should begin with xpub. Once the key is entered, you can enter some product information in optional fields like an email address. Then I just copy this HTML into my web page again. The main advantage of Mycelium is that there is no third party involved. The private keys for these addresses are wholly contained in the Mycelium wallet. The Mycelium Gear does not provide automated conversion to dollars however. You can also just put a QR code on a website. Bitcoinqrcode.org is one site that makes this easy. Just copy in an address, download the image, and add an image tag to your HTML. The downside of this method is that every transaction will be linked to this same address. This might be useful when raising money for a charity where you want donations to be visible. But it's a privacy risk for other transactions. Both BitPay and Mycelium generate a unique address for every transaction. So far we've gone through several basic steps for using Bitcoin from where to buy it to how to use a wallet, how to store Bitcoin to how to access Bitcoin on a website. I encourage you to try it out. While acquiring and selling Bitcoin is still a little cumbersome, once you have it, sending money, especially without even revealing an email address, is a somewhat magical experience.


9. How Bitcoin Works Under the Hood The Bitcoin Software Universe In this module, we're going to look under the hood to see how Bitcoin really works. You'll get a tangible understanding of exactly what's going on and what it takes to create applications that interact with Bitcoin or utilize some of the ideas behind Bitcoin. While this module will be more technical than the previous and have a small number of coding examples, my goal is to stay mostly at the concept level so non-developers can follow along also. That being said, the rest of this first clip and the second one will focus on the Bitcoin software landscape and the installation of a specific tool--Bitcore. This gets fairly detailed as there are a couple of tricky aspects, and I want to make sure developers can quickly get up and going writing some basic Bitcoin code. Feel free to skip clip 2 if you don't have any plans to write code. The rest of this clip will give a broad overview of the Bitcoin software landscape. When Bitcoin first came out, there was only one piece of software that did everything. It contained the wallet functionality we talked about in the previous module creating private keys and addresses and creating and signing transactions. It also carried out bookkeeper tasks, checking transactions, recording transactions into the ledger, relaying those transactions, and voting to synchronize with other bookkeepers. Now you can use software that only provides the functionality you need. Most wallet software or thin clients only handle address and transaction creation but do not check or relay transactions or maintain a full ledger. This makes sense as many wallets run on mobile phones or on computers where the owner does not want to dedicate the resources to maintain a full ledger. Programs that check every transaction and maintain a ledger are called full nodes. I want to emphasize that this really does mean the program receives and records every transaction produced in the entire world. The current ledger including all historical transactions as of January 2016 is about 50 GB and can use over 100 GB depending on how your software stores and uses it. Bandwidth requirements can exceed several hundred GB per month to share that ledger with other nodes. The benefit is improved security by verifying every transaction yourself and also better privacy since your node relays many other transactions beyond just your own. Full nodes also have wallet functionality. Bitcoin Core is the official full node and is available at Bitcoin.org. The voting or mining functionality has also been partitioned off from full nodes since, as mentioned previously, to be competitive, this requires specialized hardware. The software in these groupings can all be considered clients that interact with the Bitcoin network. There are also many libraries that don't necessarily connect to the network and just provide tools to create and interpret Bitcoin data. Both tools and clients are available in just about every popular language including Python, Java, Ruby, Go, and more. I'll be installing Bitcore, a JavaScript-based open source package of tools made by BitPay. I'm using it because JavaScript is a fairly well-known language and also because it utilizes the Core C++ Bitcoin code underneath, so there's less risk of differences between Bitcore results and the main Bitcoin code.


10. Installing Bitcore and Creating a Bitcoin Address This clip will provide a detailed walkthrough of getting the Bitcore library installed and using it to create a Bitcoin address. You'll want to go to Bitcore.io to get the latest instructions as they may have changed since this course was released. There are a few requirements we need to install prior to Bitcore that I'll walk through step by step. Bitcore runs on Node.js, a JavaScript runtime environment, so we need to install that first. Furthermore, we need a specific version of Node, 4.2, which I prefer to install using NVM or Node version manager, a program that makes it easier to maintain multiple versions of Node on one machine. NVM only runs on Mac and Linux, but the GitHub page mentions some alternatives for Windows. It also requires a C++ compiler, which you can get on a Mac by installing XCode. Keep in mind you can also just install the correct version of Node.js directly without using NVM. NVM installation instructions can be found at GitHub.com/creationix/nvm. I'll be installing version 0.30.2 on a Mac running El Capitan 10.11.2 and XCode version 7.2. I simply copy in the install script, which downloads and compiles NVM. Once NVM is installed, I close and reopen my terminal so my bash profile reloads and activates nvm. Then we install version 4.2 of Node by typing nvm install v4.2. Confirm the right version is available by typing node --version. If you see something other than 4.2, you may already have installed Node.js and may need to uninstall it. Also if the Node command is not found, you may need to type nvm use 4.2 to load the correct version of Node. This is sometimes needed when you restart the terminal. Now we will install Bitcore. We use NPM, the package manager that ships with Node.js. NPM makes it easy to publish your own code for others to use, download software packages, and get updates on those packages--npm install -g bitcore. That -g installs Bitcore globally, which means the Bitcore library can be used by any Node project you set up. We see it here in my NVM directory. Without the -g, it would install in your current directory. Let's make a new project. First, make a directory. Then go into that directory. Now run npm init to initialize a new project. Just hit Enter to use the defaults. You can change any of these in the package.json file the init command generates later if you'd like to publish your project. The package.json file is a file that describes the project and lists its dependencies. If you open a text editor, I'm going to use Atom, you can see the default state, which has things like the name and version. Now we're going to include the Bitcore library as a dependency--npm install bitcore-lib --save. That command creates a node_modules directory with Bitcore lib inside it. That --save command updates the package.json file to include bitcore-lib under dependencies. Note may package.json has a new line under dependencies. The advantage of keeping your package.json file updated with dependencies is that you can copy that single file, package.json, to a new project, type npm install, and it will automatically install any libraries you listed in that file. With all those prerequisites, we're finally ready to write some code. We're going to create a Bitcoin address. Type node to enter the interactive shell. We load in the Bitcore library first with the require function. Now let's create a random 32-byte number. That returns a string of bytes, and we can convert it to a number format with bitcore.crypto.BN. If I type rand_number by itself, we see the hex version of this number. And if I type ToString, we see the decimal version. Let's make a Bitcoin address from this. First, use the private key command, and then ToAddress. And then type address to print it out. You could copy and paste that address into any wallet program and send money to that right now, but don't do that. If you close the terminal window and lost the private key, any funds sent to that address would be gone forever. From now on, I'll use what's called the testnet, a fully operational Bitcoin network to test code on where you won't risk losing any real money. I do this by specifying testnet in the ToAddress function. You can see the address looks different now. And real wallets won't let you send funds to it. Compare the process of generating a Bitcoin address to signing up for an email address at Gmail, for instance. On Gmail, I have to check with Google to see if an address I want, like Scott@gmail.com, is available. On Bitcoin, I just picked a random number and ran some commands that transform it into an address. I didn't check any central service or even the Bitcoin network to see if that address was already in use. How is this possible? What if I picked an address someone else was already using? Before I elaborate on this, let me explain just what Bitcoin addresses are and how they work.


11. Digital Signatures and Bitcoin Addresses As mentioned in the first module, when Bob sends money to Alice, he authorizes that transaction with a digital signature, the digital equivalent of a hand-written signature that is much more secure on the internet. Digital signatures are an integral piece of Bitcoin addresses. Let me take a few minutes to explain digital signatures. Digital signatures are based on public key cryptography. When I hear cryptography, I think about encrypting secret messages. For instance, I might want to send a secret message, The enemy is attacking, and apply a trivial encryption scheme to avoid anyone reading the message. I could create a table that replaces each letter with a different letter. My recipient could decode my message with this same table or key. Instead of one key that both encrypts and decrypts a message, public key cryptography uses a pair of keys where each one only works in one direction, a public key to encrypt a message and a private key to decrypt it. My recipient can publicly post her public key, which then I use to encrypt my message. Then she decrypts with her private key. The advantage is that I can send her a secret message without ever having to meet to share a key. The math behind this technique is based on one-way or trapdoor functions. Things that are easy to calculate one way but not the reverse. For example, it's easy to multiple 199 and 337 together, but it's much harder to find the factors of this number. I have to try a bunch of numbers. Does it divide by 3? No. By 5? No. By 7?, etc. The algorithm in Bitcoin is based on finding a discrete logarithm on an elliptic curve rather than factoring numbers. Without going into the details of this, the primary benefit is a smaller key size for a given amount of security. So what does this have to do with digital signatures? If I relabel this drawing, this same algorithm can be used to prove ownership. Instead of starting up here, I began with the message in the middle and used the private key to generate a signature instead of decryption. Others can then use the public key to get back to the original message. If the message generated by the public key and signature matches the original message, we have proof the signature was created by Bob's private key. We also have proof that the message hasn't been altered because the signature is in part based on the message. So the same operations used to encrypt a message provide a mechanism for proving the authorization and integrity of a transaction. Getting back to Bitcoin addresses, each address is basically the public key from this digital signature algorithm. When Bob sends money to Alice, he's assigning funds to that public key. Alice then spends those funds by generating a signature that proves she's the owner of that public key. You can think of a Bitcoin address as a public Dropbox where funds can be deposited by anyone but only retrieved by the owner of the private key for that box. If we look back at the code to create an address, we see that the first step is to generate a private key, which is basically just a large random number. The elliptic curve math then provides a way to calculate the public key from this private. There's no way to go back from a public key to a private key. If that were possible, you could steal any coins you wanted. Interestingly, Bitcoin addresses started out just as public keys, but now they have a few more operations to help prevent errors and enhance security and privacy. More on this later. Let's return to the question I asked earlier. If creating a Bitcoin address is just picking a random number, how do you avoid picking a random number someone else has already used, and what would happen if you did pick it? Since that original random number is the private key, you would be able to spend any funds sent to that address. But this is incredibly unlikely because there are so many possible addresses. If this seems hard to believe, it should be. There's nothing in our daily lives that is remotely comparable. There are about 10 to the 24th atoms in a cup of water, which is by itself an unfathomably large number. You can generate trillions of addresses a second for a thousand years and still be short of the number of atoms in that cup of water. But the number of possible Bitcoin is much, much larger than the number of atoms in a cup of water. It's closer to the number of atoms in the entire Earth. This large number underlies the security and privacy behind Bitcoin addresses. Funds are protected by the extraordinarily low possibility of guessing someone else's private key. Also, this way of generating addresses does not require any contact with a central registry or even the Bitcoin network itself. I can generate an address by flipping a coin 256 times without ever telling anyone.


12. Bitcoin Transactions Now that we have an understanding of addresses and how transactions are authorized, let's dive a little deeper into those transactions and how they're stored in the decentralized ledger. One surprising aspect of Bitcoin that I've oversimplified so far is that no balances are stored. The main ledger only stores transactions. But without balances, how do you find out how much money you have? And if Bob creates a transaction sending 5 Bitcoins, how do you know he actually has 5 Bitcoins to spend? To spend 5 Bitcoins, Bob's transaction must source one or more previous transactions that have sent him 5 Bitcoins. And those transactions must in turn source other transactions all the way back to special coin-based transactions that have no inputs where money is effectively created. More on these later. In this way, transactions form an ownership chain. To calculate how much money you have, you need to iterate through every transaction with one of your addresses and add where you've received money and subtract where you've sent money. While this this may seem cumbersome, applications maintain an index that makes this fast. There is also a simplifying role that every input must be spent completely in a transaction. This way applications only need to keep track of unspent transactions and not partially spent ones. Let's look at a real transaction at blockexplorer.com to see how this works in detail. This transaction is sending 0.2495 Bitcoins, which we can see in the output list. The transaction references three input transactions. Now because those input transactions don't add up to 0.2495 exactly and because of the rule that each input must be spent completely, a second output or change output returns the extra to another address, most likely also owned by the sender. We don't strictly know which is the real amount the sender wanted to send versus the change, but it's likely that the bigger amount is what the sender typed into her wallet since the smaller amount wouldn't have required as many inputs. These outputs can then later be used as inputs for other transactions. The software that bookkeepers run keeps track of these so-called unspent transaction outputs, or UTXOs, in a separate database because this database needs to be checked often. Any time a new transaction comes in, its inputs must be checked against this database to ensure it's valid and not trying to re-spend an output. Overall, this structure has some privacy implications. It's best practice in Bitcoin to generate a new address for every transaction including the change address. This makes it harder to connect transactions together to learn about someone's total balance or buying behavior. But as we see with this transaction, addresses are often linked together when you want to spend more than any one transaction output can supply. In order for Bob to spend 5 Bitcoins, he must source a 2 and 4 input transaction to cover that since each one by itself is insufficient. If I go back to the real transaction and expand the details of the inputs, you can see something called a scriptSig under each input. Part of this is the digital signature created by the owner of the address for each input. The signatures prove authorization. But here they also prove a connection between these addresses as the sender must have had the private keys for all these addresses. If a real identity can be linked to one transaction, it's possible to trace through this ownership chain and statistically connect other transactions to it. This is why Bitcoin is not anonymous but pseudonymous. If, for example, I buy Windows from Microsoft, which, by the way, now accepts Bitcoin, now Microsoft knows an address I own and could potentially connect other transactions I make to that one. If we look at the output details of the transaction, we see something called a scriptPubKey. You may have wondered why the signature was labelled scriptSig before. The inputs and outputs are actually more flexible than a simple From and To address. Bitcoin uses a scripting language to open up the possibility for more complex transactions such as requiring two out of three signatures or even storing data. You can think of each output like a puzzle that needs to be solved to be spent. To summarize Bitcoin's ledger so far, we see it's a giant collection of transactions. Current balances are the sum of all the unspent outputs of those transactions. And to spend those, you reference them as inputs to a new transaction and provide the script that unlocks each one. One question many have had is why Bitcoin uses transaction inputs and outputs to track ownership rather than a more familiar ledger of accounts and balances? I believe one of the primary reasons was to enhance privacy by avoiding multiple transactions linked to a single account. But as we just saw, Bitcoin transactions are still often linkable. There are several other pros and cons as well, for example, dealing with the storage space needed to keep track of accounts versus outputs. But considering that there are many systems that do in fact manage accounts and balances directly like Ethereum and Ripple, I think the best answer I can offer is that there are many tradeoffs and no agreement that one way is universally better than the other.


13. Creating and Sending a Transaction Using Bitcore To solidify this transaction system, let's create one by hand using Bitcore and send it out. This is another clip you may want to skip if you're not interested in coding. The first step to playing with Bitcoin is to get your hands on some. We're going to obtain coins on the testnet to avoid losing any real money. If you Google bitcointestnetfaucet, you can find several websites that will send you a small amount of test coins. I'm going to go to bitcointestnetfaucet.com. Now I need an address to send these coins to, so we're going to make a new address. However, it's important that we don't lose the private key to this address, so we're going to store that key in a file this time. Run Node again and require the Bitcore library as before. Then generate a new random private key and add the following function at the end--toWIF. WIF stands for wallet import format and is a format with some error checking and extra information to tell wallets what kind of key it is. Now create an index.js file where we'll both create and send the transaction. I'm first going to copy in that private key string from the console, then convert it to a private key, and then to an address. Save the file and go back to the console. If you're still in the Node shell, exit by typing Ctrl+C twice. Then type node index.js to run the file. In the output, we see the address. Copy that and paste it into the faucet form. You need to get enough to at least cover the fee on sending a transaction. The minimum fees change according to market conditions, but BlockCypher has a page that estimates these for you. At this time, the fee is about 0.0005 Bitcoins. So we'll type in ten times that or 0.005 Bitcoins. Notice that some forms are in satoshis, which are the smallest unit of Bitcoin one one-hundred-millionth. So you might need to convert these numbers on another faucet. Congratulations! You just got your first testnet Bitcoins. Let's see how to send those now. Go back to the index.js file and add the following lines to generate a second address to receive the coins. Here we're making a new address, but this time from a string instead of a random number. The string gets converted to a 256-bit number through a SHA256 hash, which I'll talk about more soon. This is a very risky way to generate an address as humans are bad at generating truly random input. But I wanted to demonstrate it. So now we have a from address and one output address. We need one more piece of information to be able to create a transaction--the input transaction. A given address may have several unspent outputs available if multiple transactions had been created sending money to it. We need to specify which one of those unspent transaction outputs are going to be our inputs. This requires a connection to the Bitcoin network. Go back to your console and now install bitcore-explorers. Now go back to our index.js file and add the following text. This function queries a server run by BitPay's insight server, in this case, test-insight.bitpay.com. The real power behind the Bitcore software is running your own full node and querying that instead of a server you don't control. You can do that by typing bitcored, but this currently requires over 100 GB and several days of processing to set up. Running a full node means downloading and checking every transaction ever created and continuing to receive and relay all new transactions. It's an intensive task. But, remember, this is the price of decentralization and minimizing trust. Every peer on the network maintains its own ledger. So for the sake of a quick demo, we'll just rely on BitPay server, which the explorer's library defaults to. I'm going to comment out the previous console logs before running the file again with node index.js. And the results we see are address, amount, and a transaction Id within index. Remember, transactions can have multiple inputs and outputs, so you need to specify an index along with the transaction. Let's use that unspent output in a transaction now. First, create a transaction and then set the unspent transaction output as the from source. Then set our second address as the to address. And let's send the exact amount that's available in the unspent output--500,000 satoshis. Now to send this transaction, we need to serialize it and then broadcast it using the explorer's module again. I'm going to leave the broadcast function commented out for now. Now we got an error, something about the fee being too small. This is one part of transactions that I haven't discussed in depth yet. The Bitcore library provides some safety checks on transactions, and checking for an appropriate fee is one of those. Transaction fees are collected by the bookkeepers or miners, and if you don't have a sufficient fee, it's likely your transaction will get ignored. Interestingly, there's no fee field in a transaction. Rather, the fee is just the difference between all the inputs and outputs. To add a fee, we need to reduce the output to include one of the minimum fees we saw on the BlockCypher site--50,000. I'm going to change my output down to 10,000 or 0.0001 Bitcoins. Remember, all inputs must be spent completely, so we need to include a change address in order to send a small output with this larger input. Let's return the extra back to our original address. Note the best privacy practice is to generate a new address for the change. Now if I print out the transaction using tx.ToObject, we can see that 10,000 goes to my destination address, and 480,000 is going back to my change address, leaving a fee of 10,000. Bitcore automatically applies a default fee, but I'm going to increase it with the fee command just to be on the safe side. Now when we try to run the code, we get a different error. This time about inputs not being signed. This is where we unlock the funds. We need to use the private key associated with the address in the input transaction. If I print the transaction out again after signing it, we see a script applied to the inputs. I mentioned before that these were more than just digital signatures but rather a small scripting language. If I print out both the input and outputs with the script ToString command, you can see some of the commands in this scripting language. It turns out that the default output is more than a public key, but a function that says something along the lines of provide a signature and public key such that the hash of the public key matches the Bitcoin address and the signature transaction and public key all verify together. I'll explain hashes shortly. But for now just think of them as a compression function. When I first introduced Bitcoin addresses, I noted that the address is not just a public key. It's actually a hash of a public key with some extra conversion to avoid easily mistaken numbers and letters like 0s and Os. This is why the script has some hash commands in there. Another type of much more flexible output puzzle is a pay-to-script hash. To unlock this output, you must supply a script that hashes to the value supplies. This is commonly used to enable outputs that can be unlocked with two of three private keys. A final output worth mentioning is the data store implemented with an OP_RETURN command. This output can never be spent but can be used to permanently store a small amount of data in the ledger. Let's say you invented a new product, you could store a hash of a description of that product in the ledger to have timestamp proof of when you invented it. Bitcore provides a function for this--tx.addData. Note that this still costs a fee and is also a dead-end output. Any money sent to this address will be un-spendable. With those details explained, we're finally ready to send the transaction using insight.broadcast. If it works, you should see the transaction Id returned. We can now go to a block explorer for the testnet and type in either the address we sent the money to or the transaction Id just returned. Congratulations! You just wrote code that successfully sent a Bitcoin transaction. Now, remember, we used a BitPay server to broadcast this transaction. We could have also run a full node ourselves to talk to other Bitcoin peers of our choosing and directly broadcast the transaction. Several sites also provide web forms that accept raw transactions and broadcast them for you. This is useful if you don't have a full node running and are using another library that can't directly broadcast a transaction. To do this, I print out the raw transaction and paste it into the raw transaction form, which here is at test-insight.bitpay.com.


14. Reaching Consensus on the Ledger and Proving That Consensus The Bitcoin addresses, digital signatures, and transactions we've seen so far provide much of the security behind Bitcoin. Without a private key corresponding to a given Bitcoin address, it's impossible to forge a transaction to steal money from someone else. So while we have a secure system for transferring tokens of value, we haven't talked about how those tokens are created in the first place. And that is the crucial other half to the security behind Bitcoin. We saw a brief mention of coin creation already, so-called coin-based transactions that source no inputs. But these transactions are permitted only under very constrained circumstances. If anyone was able to create Bitcoins at will, Bitcoins would no longer be scarce, and the whole system would collapse. Preventing the invalid creation of coins is more subtle of a challenge than just the regulation of coin-based transactions. Consider that Bitcoins are nothing more than digital information and how easy it is to make copies of digital information on the internet. An MP3 music file can be duplicated with a simple download. What is it about Bitcoin that enables it to remain uncopyable and scarce? Allow me to describe a problematic scenario. Suppose I make a copy of the Bitcoin ledger, spend all my money, and then show a merchant the original copy of the ledger I made, and say, Look, the ledger shows I still have money. I'll create a transaction giving you the money in my balance, and you give me that TV. It's crucial that the merchant can tell the difference between the fraudulent ledger I show him and the real one in which I have already spent my money. If he can be tricked into believing my ledger, I can effectively double spend my money or, put differently, create new money. Expanding on this, what if a rogue group of bookkeepers decided to try and trick a merchant? Given a choice between several ledgers, the best we can hope for is to follow the ledger the majority of bookkeepers support. And this brings us back to the voting system discussed in the first module. The voting system enables anyone to see which ledger the majority supports. It also enables the bookkeepers to decide on a ledger version. Now why would bookkeepers ever disagree about anything? Why are decisions even necessary? The bookkeepers need to reach consensus on fundamental aspects like when and how money is created, but also more mundane issues like regular software feature upgrades and fixes. The decentralized nature of the network also necessitates decisions about transaction order. We call the double-spend scenario from the first module where Bob sends both Alice and Carol all his Bitcoins. On a more detailed level, he could create two transactions that both source the same unspent output from a previous transaction. These transactions might reach different bookkeepers in different orders due to network delays or Bob even intentionally sharing them in different orders. Bookkeepers that receive the transaction to Alice first would ignore Carol's because it would be trying to spend an already spent output. Bookkeepers receiving Carol's first would ignore Alice's. And so we see that in addition to deciding on system rules, deciding on transaction order is crucial because that order changes who has money.


15. Cryptographic Hashes Let's now dive into this voting system. I mentioned in the first module that bookkeepers must solve computational puzzles to vote. This gives voting a cost making it financially infeasible for a single anonymous voter to masquerade as many others and sway the vote. It also provides a form of proof to the rest of the world of the majority's will because the solutions could not be generated without the majority's computing resources. Let's see how this works in detail. The math puzzle being solved involves a cryptographic hash. I'm going to spend a few minutes explaining this because it's such an important component of Bitcoin. A hash function is a function that compresses an input into a kind of fingerprint. For example, I'm going to hash the word cat with a simple hash function. I'm going to assign each letter a number for its place in the alphabet, add them together, divide by five, and then use the remainder as the result. So cat becomes 3, 1, 20, summed together is 24, divided by 5 is 4 with a remainder of 4. So 4 is my output. Dog can be hashed similarly--4 + 15 + 7 = 26. 26 divided by 5 is 5 with a remainder of 1. In this way, any word or sentence can be compressed into the numbers 0, 1, 2, 3, or 4, the possible remainders when I divide a number by 5. Note that the process is deterministic, that is, a given input always results in the same output. There's no uncertainty or randomness. Hashes are commonly used as a way to look up things faster. Imagine a phonebook where instead of arranging names in alphabetical order, we use a hash function to decide what page to write each name in. Then to look up a name, we run the hash and go to that page to find the name. This method could be faster than an alphabetical sorting for names like Smith that cover many pages. A good hash function won't give the same answer for many inputs. Our phonebook example wouldn't be good if half the names in the city map to the same page. A cryptographic hash function also has the goal of irreversibility, that is, given an output, it's extremely difficult to guess what input generated it. My simple hash function is terrible for this. It's easy to find a word such as oranges that also maps to 4, the same as cat. The cryptographic hash used in Bitcoin is called SHA256, maps inputs to a 256-bit number, and is much more sophisticated. Here are the results of cat, dog, oranges, and orange (singular). Note how orange and oranges are completely different. It's impossible to deduce anything from the input based on the output. Now SHA256 is much more complicated than my hash function, but a simple way to think about it as a mixer. Part of what happens includes rearranging, combining, and remixing over and over again. There's a great walkthrough of this at metamorphosite.com if you'd like to see exactly how this works in detail. The irreversibility makes it useful for checking the integrity of files. By checking the cryptographic hash of a file, you can be sure that the file is authentic down to every bit. It's impossible for someone to create another file with that same hash.


16. Locking Transactions in Order with the Blockchain Going back to Bitcoin, the puzzle being solved by the bookkeepers is the very thing I just said the cryptographic hash was designed to make difficult--finding an input for a given output. Specifically, the goal is to find an input that results in a hash output smaller than a certain target. The smaller the target, the fewer the number of outputs that fulfil that equation and the harder it is to find a successful input. Let's connect this back to deciding on transaction order. As new transactions are created, they are forwarded around the network but not considered accepted into the official record yet, and are instead placed into a pool of unconfirmed transactions. Bookkeepers draw from this pool to create a candidate next set of transactions to be officially accepted called a block. The full text of all those transactions is then input into the hash function along with the previous block's hash and a random number called a nonce. Bookkeepers try different nonces until the resulting hash is below a target number. because this is a cryptographic hash, there's no way to find an input that works other than by trying different guesses. It's statistically just like rolling dice until you get, say, two 6s in a row only much, much harder. As of January 2016, the bookkeepers are trying over 1 quintillion or 1 billion billion hashes per second. At this point, all bookkeepers are in a competition to solve the hash first, each working on a potentially different set of transactions. When one bookkeeper succeeds, she announces her solution to the rest of the network. While transactions may have reached bookkeepers in different orders, one single bookkeeper chooses the next set of transactions. The hash function makes the decision maker a random one. Everyone then checks that block and the transactions in it and begins working on the next block. Note that while solving the hash puzzle requires many billions of guesses, verifying the solution is trivial and just requires one. Because each block contains the hash solution of the previous block, the blocks form a chain placing transactions in order. Occasionally, two bookkeepers will solve a block at about the same time creating a fork in the blockchain. A fork may also occur if some bookkeepers decide to switch to a different set of rules that others don't accept. At this point, bookkeepers need to decide which branch to build on, that is, which block hash should they include in the input to the hash function along with the next batch of transactions. Which branch to build on is the voting choice the bookkeepers make. Now in normal circumstances, forks quickly resolve. I mentioned that finding a block solution is like trying to roll two 6s in a row. Sometimes you'll get lucky and get two 6s on the very first two rolls. And sometimes you'll get unlucky needing to roll the die hundreds of times. This statistical spread in how long it takes to solve a block means that it's very unlikely for two blocks to be solved at the same time, and even more unlikely for additional blocks to be solved at the same time. In other words, one of the branches will grow before the other very soon. The general rule is to always accept the longest branch available as the authoritative branch. The difficulty target is adjusted periodically so that the average block solution takes about 10 minutes to find. As more and faster computers have joined the network, the difficulty has increased substantially. Strictly speaking, since blocks have changing difficulty, the authoritative branch is not the chain with the highest number of blocks but the chain with the most cumulative difficulty and work. So why 10 minutes? There's no reason for the exact number 10, but there's a balance between accepting transactions quickly and creating instability and waste in the network. During the time a recently found block is being distributed, other bookkeepers will still be working on a now-stale branch wasting energy. The shorter the block time, the higher percentage of the total block time will be wasted, and the greater the chance for forks. The fact that the end of the chain can fork and be rearranged means that transactions toward the end of the chain shouldn't be trusted as much as ones further back. Each block that gets added onto a transaction's block is said to add to that transaction's number of confirmations. Six confirmations means six blocks back and is the recommended number of confirmations to wait for high value transactions. Note that transactions in the discarded blocks are not gone forever. They simply get placed back into the unconfirmed transactions pool and are included in subsequent blocks.


17. Bitcoin Creation and the Double-spend Attack I began this section stating that digital signatures alone only safeguard the transfer of Bitcoins, not the creation of them, which must be carefully controlled to keep Bitcoins scarce and valuable. I can now explain when and how Bitcoins are created. The bookkeeper who solves the block gets a block reward and is allowed to include a coin-based transaction, that is, one with no inputs, in the block he solves. This effectively creates money out of thin air. Currently, the transaction value is set at 25 Bitcoins, but this cuts in half every four years until no more Bitcoins are produced. As I mentioned in the first module, this discovery of money is why bookkeepers are called miners. But, again, their real job is to maintain the ledger. The random nature of the block hashing puzzle simply provides a way to randomly distribute money into the world over time. In addition to the block reward, the bookkeeper who solves a block also gets the fees attached to all the transactions in that block. Here we see why it's valuable to include a decent fee in a transaction. If a transaction has no fee or a lower fee, bookkeepers may choose to ignore it or at least deprioritize it over other transactions. Finding a solution to a block and getting the block reward is extraordinarily hard. It's very much like winning the lottery. In Bitcoin, your chances of winning are based on what percentage of hashing power you have relative to the rest of the network. To increase their payout frequency, most people join mining pools, which work collectively to solve blocks, and then pay out divisions of the block reward depending on how much work each participant contributed. The payout is lower but much steadier. This brings me to another form of double-spend attack. While mining pools enable bookkeepers to receive a steadier payout, they also centralize power to the pool operators. Currently, several pools have over 10% of the total network hashing power, which you can see at blockchain.info/pools. With so much hashing power, it's possible to change the blockchain. Suppose Bob spends a large amount of money for a rare painting and that the seller delivers that painting after three confirmations. Now if Bob can present a new longer chain in which that original transaction's output goes back to Bob instead of the seller, the bookkeeper network will switch to that chain and consider the original transaction invalid. To pull off the attack, Bob needs to build blocks faster than the entire rest of the network while he waits on the painting. While unlikely, someone that controls only 10% of hashing power could get lucky. Note that it's unlikely a mining pool would sabotage their own source of revenue, that is, the Bitcoin network. This example should help explain why transactions further back in the chain are more secure. Because each block builds on the hash of the previous block, any changes to transactions in a past block invalidate all the more recent blocks. For someone to change a transaction in the past and have that accepted, he would need to resolve all the subsequent blocks to catch up to the main chain. Some people have criticized Bitcoin for wasting electricity to solve these hash functions instead of something more useful. However, this function is exceptionally special. Just like trying to get several 6s in a row with a die, there is a well-defined relationship between work and solutions. It's this relationship that allows anyone to compare two different blockchains and have assurance that the one with the most solutions is the one with the most work done and, therefore, the one the majority of the world supports. The hash function also provides an unlimited supply of new problems that can't be solved ahead of time since as just explained each block solution is utilized in the very next one.


18. Simplified Payment Verification (SPV) Wallets and Conclusion A final topic to mention is SPV wallets, or simplified payment verification wallets. While a full node has a complete list of every transaction ever made that it can check against to make sure a new transaction is not already spent, mobile phone wallets don't have the resources for this. Mobile wallets must check with the full node to see if a transaction is valid, and ideally several full nodes. To do this, SPV wallets send a transaction hash to a full node, and the full node returns the block the transaction is in, along with the block headers for every block after that one. In this way, the SPV wallet can verify how many confirmations a transaction has. To avoid sending every transaction in a block, nodes send a much smaller amount using a Merkle tree. A Merkle tree divides up every transaction in a block into pairs and then creates a hash of those transactions. Those hashes are then paired and hashed all the way up to a single root. To verify that a transaction is in a block, the full node only needs to send enough hashes so that you can obtain the Merkle root from that transaction. To verify 938, I would need 434, 321, and 906, and then calculate 121, 543, and 432, the root. To aid privacy, SPV wallets don't ask about specific transactions, but rather a pattern that matches several transactions called a bloom filter. In this way, full nodes don't know exactly what transaction a given wallet is interested in and sends back several. This pattern can be made more or less precise. A broad filter provides more privacy but comes at the cost of bandwidth for more transactions. In summary, the core of Bitcoin is an ordered list of transactions called the blockchain. Each transaction authorizes transfer of value from a previous transaction's output to a new output. Usually these outputs transfer funds to a new Bitcoin address, but the scripting language allows for many more options such as outputs that require two of three signatures or even storing data. Bitcoin addresses are essentially the public keys from public key cryptography, the cryptographic technology that ensures only the owner of a corresponding private key can authorize a transaction. Those private keys are formed independent of any central registry by picking a random number from an unfathomably large pool. While digital signatures prevent unauthorized transactions, they don't prevent someone from presenting a fraudulent ledger. The proof-of-work voting system not only allows bookkeepers to reach consensus about transaction order and system rules, but also proves to the work which ledger the majority of them support. Users can look at the solutions to the cryptographic hashes for a block and have assurance that the majority of the bookkeepers' competing power was needed to create them. If you'd like to go a level deeper to understand the specific formatting of addresses, byte level protocol formatting, and exact rules, I highly recommend Andreas Antonopoulos' book "Mastering Bitcoin." Much of this information is now also available at Bitcoin.org under the developer section. Note, however, that the final say on the exact specifications can only be determined by looking at the source code running on the majority of miner or bookkeeper nodes.


19. Advanced & Upcoming Bitcoin Improved Backups Through Deterministic Wallets Now that we've covered the main concepts behind Bitcoin, how to use it, and some implementation details, I want to discuss some of the more interesting advanced features. Many of these are already available; others are coming soon. I also want to cover some of the challenges Bitcoin faces so that viewers walk away with a balanced view of where Bitcoin is and where it's going. The mantra, Be Your Own Bank, the idea that you and you alone control the keys to your money is one of the main selling points of Bitcoin. However, when you control your own keys, you also bear the full responsibility for not losing those keys. Remember, if you lose the private keys to your Bitcoin wallet either to a hacker or to a bad hard drive, your funds will be irrevocably lost. There's no bank or police department that can be called for help. This risk means that backups are essential for Bitcoin wallets, but many early wallets made this cumbersome. The first Bitcoin wallet software was called JBOK wallet, or Just a Bunch of Keys. For each Bitcoin address in the wallet, a corresponding private key was stored. As the recommended privacy practice is to create a new address for each incoming transaction, a new private key would also be created. This meant you need to create a backup of your wallet every time a new address was created. Now most wallets only require one backup when you first set them up. They're called deterministic wallets as every key is determined from a single seed. Here's how this works. Each key is derived from a seed and an integer through a hash function. In this way, a nearly infinite number of new keys can all be made from a single seed. The corresponding public key and Bitcoin address can then be derived from each private key as shown before. Many wallets us this idea internally and are also guiding users to make backups before beginning to receive any coins. Mycelium, for instance, strongly encourages you to write down 12 words that represent that seed. These words are known as a pneumonic code, a human friendly way to represent a number. Each word is pulled from a list of 2,048 words, each of which represents an 11-bit number. Strung together and put into a hash, they become a number that can be the seed for a deterministic wallet. So who makes this list of words? You can find the list used by many wallets at the Bitcoin GitHub page under the BIPs section and bip-0039. BIPs stands for Bitcoin Improvement Proposals, and this is the main method new features are proposed and evaluated. On the main BIP page, you can see a list of ideas, their authors, and status. Each BIP contains a concise description of the feature, motivation, and a brief technical specification. Another relatively new resource for keeping up with the latest feature is bitcoincore.org.


20. Hierarchical Deterministic Wallets With that brief aside about where to learn about the latest Bitcoin features, let's get back to wallets and the challenge of being your own bank. The ability to generate all your keys from a single seed greatly reduces the original difficulty in maintaining an up-to-date backup, but there are still cases where having a single account is problematic, especially in organizations. Consider an organization with many branches and divisions where each subgroup needs to manage its own account without having access to the other groups' accounts. The CEO should have visibility and control over all these groups ideally without having to manage a large set of separate private keys, which would be a burden to backup and maintain. This is where the additional tweak to our deterministic wallet can be given hierarchical structure. Suppose we had a new CHAIN_CODE field to our key generator shown before where that CHAIN_CODE is also a random number. Now if I'm the CEO, I can give each group a different CHAIN_CODE, thereby letting them all derive as many keys as needed, but also allowing me to generate those keys. The full specification known as BIP32 provides for a systematic way to create hierarchies that are deterministic, meaning you can start from the seed and be sure you're going to get the same keys out every time. One additional surprising and useful feature of hierarchical deterministic wallets or HD wallets is that it's not only possible to derive chains of private keys but also public keys without any knowledge of a private key. This means an exposed eCommerce web server could derive a new public key for every order without having access to the corresponding private keys. Without this ability, you would have to pre-generate a list of public keys to give to the web server if you didn't want to place any of the private keys on that server. The ability to derive public keys without a private key takes advantage of some subtle math inside the elliptic curve public key cryptography we've been using. Permit me to shine a little more light into this black box. It turns out that deriving a public key from a private key is like multiplication, although multiplication over an elliptic curve, not simple arithmetic multiplication. The formula for a public key is to multiply a point on an elliptic curve by a private key, which is a large random number. While not simple arithmetic, it does share some of the same roles we expect, namely the distributed property. This means I can sum before or after multiplying by G, and the answer is the same. If I define a private key Kpri3 = Kpri1 + Kpri2, this means I can get to a public key, Kpub3 in two ways. The normal way of just multiplying the private key by G or by distributing G, I can see that I get there by simply adding two other public keys. The take-home here is that Kpri3, the private key for this public key, is not in that formula. Here's how we can take advantage of this to generate public keys without their corresponding private keys. Consider this formula--Kpub_n = Kpub_master + H(S|n)*G. An exposed server could use that formula to generate a nearly unlimited number of new public keys by inputting new values for n all while never having access to any of the private key n's. To generate the private keys on another secure server, I use knowledge of the master private key. If I substitute Kpri_master*G for Kpub_master and pull out the G, we see that the nth private key is just the sum of the master key and our hash. The important part of this is that Kpri_master is never on the exposed server. Even if a hacker discovered all the other information on the exposed server including the Kpub_master and the seed, he could not spend any funds sent to those addresses. Many wallets have already implemented the backup feature of just having to write down 12 words to recover a wallet no matter how many addresses you generate. But I haven't seen many implementations that support the hierarchy part of HD wallets. I can provide a quick demo using BitCore though. In my corporation, I have two departments, A and B. I first start off creating a top-level HD private key. This function just generates a random key if you don't supply any arguments, so remember to back this up before sending any money to it. Then I'll make a private key for department A and one for B. Now department A can derive further children from that without giving any visibility or access to B. In department B, there's an exposed web server that I want to generate receiving addresses, but I don't want to have any private keys on that server. I make a new private key for that server and also a public key. I put the public key on that server, and from that derive new addresses for each order. On a secure server, I can generate the corresponding private keys. Note that there was some important security subtleties that I've skipped here, namely about hardened keys, so be sure to read more before implementing such a system. Overall, we see that HD wallets help manage some of the challenges posed by being your own bank and having to carefully manage the keys to that bank. The deterministic nature makes backups much more manageable enabling you to create an initial backup just once rather than having to back up a new private key for every address. The hierarchical part helps organizations structure access. And, finally, these techniques can even separate key generation from private keys for exposed servers.


21. Multisignature Addresses for Shared Wallets, Backup, & Security Even with the benefits of HD wallets, you still have one set of keys for any given account, and this presents some security risks for any organization that doesn't want to trust just one person to run off with money. This is where the multi-signature scheme I mentioned in previous modules comes to the rescue. Recall that Bitcoin addresses are more than just receiving accounts but are scripts or puzzles that must be unlocked to access funds. It's this feature that enables you to set up an address that requires, say, three of five signatures to unlock. BitPay's copay wallet has a nice interface for this, which I'll briefly demonstrate. I add a new wallet and choose the Shared Wallet tab. I'll call it Acme Inc, type in my name, and then choose a two out of three requirement to spend funds. I'll also set this to the testnet so I'm not playing with real money. Now two other officers in my company can join this by choosing Join Shared Wallet on another device. To spend money, one person initiates the transaction and creates one of the signatures. Others then receive a notification and can simply accept to finish sending the funds. You could also use a one of two account to provide a joint checking account style access. The two of three scheme is also used by a new wallet product called Case. This is a hardware wallet that has a worldwide cellular connection, camera to scan a QR code, Bitcoin address, and fingerprint scanner. To send money, you scan a QR code and swipe the fingerprint scanner. It then connects to a Case server to provide the second signature and broadcast the transaction. If you lose your device, your funds can be recovered by using Case's key and a third key stored at a separate company. With this product, the two of three scheme provides two-factor authorization and backup. A service called Green Address also utilizes two of two signatures. Each transaction requires a signature from their service, as well as from your device. This bolsters security because two factors are needed, and it also enables you to set withdrawal limits. They provide time-lock backup transactions to recover your funds in case their service disappears, a feature we'll discuss soon. These two services offer interesting alternatives to the responsibility of holding and safeguarding private keys solely on your own. There's a growing ecosystem of choices that allow you to choose how much control and responsibility you have. With Coinbase, they hold the private keys but also all the responsibility. If you ever lose your password, they can always help you recover access. On the other end, wallets like Electrum and Mycelium give you complete control but also complete responsibility. Green Address and Case offer a bit of middle ground, sharing some control and responsibility with you for backing up and safeguarding those private keys.


22. Multisignature Addresses for Escrow Services Being your own bank in addition to meaning that you alone control your funds also means that there's no intermediary between two people when sending money. This is good because it reduces cost and prevents censorship, but in some cases we rely on intermediaries like credit cards to prevent fraud. If you buy something online and their merchant never ships it, a credit card company can usually recover your money. To provide this ability in Bitcoin, you need to use an escrow service. Using the two of three multi-signature scheme, this can be done with surprisingly little trust. Suppose Bob wants to buy a painting from Charlie but doesn't trust Charlie will deliver the painting after receiving funds. Bob and Charlie agree to use a third party, Alice, as an arbitrator in case there are any disagreements. Charlie creates a two of three transaction by first collecting the public keys of Alice and Bob and then crafts a pay-to-script hash multi-signature-type transaction. Recall that this means that a payment is sent to a hash of a script. To spend funds, you need to provide a script that hashes to this value along with any necessary signatures. Charlie sends this script to Bob who checks to make sure the public keys are right, hashes it, and then makes payment to that hash address. Once Charlie sees payment, he ships the painting. If there are no problems, Charlie can construct a transaction that pays him the full amount of the order. The input to that transaction will be the two of three script and two signatures. Charlie adds his signature and sends it to Bob to add his signature and unlock the funds. Notice that Alice, the arbitrator wasn't involved at all in this case. Since this didn't require any work on her part, she might not charge anything if arbitration isn't needed. Suppose, however, the painting wasn't exactly what Bob hoped it would be, so Bob asked for a refund. Charlie disagrees and enlists the help of Alice to arbitrate. Alice requests evidence from both sides and decides that neither party is completely right. So she creates a new transaction splitting the money, 49% to both Bob and Charlie and 2% to her as a fee. She provides her signature and passes the transaction onto Bob and Charlie either of whom can sign it to send it. Interestingly, if Bob and Charlie aren't happy with the resolution, they can create a new two of three transaction sending the funds to a new arbitrator. At no point does any one party have full control over the funds. A real-life version of this service can be found at bitrated.com, which facilitates escrow transactions and has an eBay-like rating system.


23. Centralization Pressures The main innovation of Bitcoin is often said to be decentralization. However, there are several areas where Bitcoin is unfortunately more centralized than many would hope. As mentioned previously, in order to be competitive in the mining or voting process, specialized equipment and cheap power is needed. This has led to a migration from individuals running Bitcoin servers on personal computers to dedicated companies running massive farms of specialized computers that do nothing else but calculate the proof-of-work function. Also, the pooling of miners has further centralized voting or mining power. Recall that winning a block is like winning the lottery. So most miners work in pools to increase the frequency of payouts. In a typical mining pool, the pool operator chooses the transactions to be included in a block, the block to build on, and the version of software to run. The pool participants only receive the block header and work to find block solutions based on that alone, thereby giving the pool operator a substantial amount of power. Since only a handful of pools control the majority of all hashing power on the Bitcoin network, the current mining power is surprisingly concentrated. Now this does not mean that miners have total control. If the miners should change rules against the ultimate desire of end users, who are the ones that trade real goods and services for Bitcoin, those users would switch to a different chain, making the new miner coins worthless. In this author's opinion, however, it's unclear where the balance of power lies, especially in the short-term. Recently, there have also been some technical pressures towards centralization. Since very early in Bitcoin's development, there has been a 1-MB cap on the size of blocks. As of March 1, 2016, the average block size was 0.85 MB, and some transactions are starting to be delayed since there's not enough room in each block. There's only capacity for about four transactions per second. Some are not concerned because even with full blocks, you should be able to get a transaction through by paying a higher fee. However, others think this is bad because it would make Bitcoin cost prohibitive for small amounts. While increasing the block size may seem like an obvious solution, many are opposed to this because they fear it will increase centralization. As the block size grows, the network, storage, and computing resources needed to operate a full node increase making it harder for individuals to run full nodes. This results in further concentration of control in larger institutional operators. Interestingly, the block-size debate appears to be highlighting another source of centralization--code development. There are currently only a handful of core developers that maintain the main GitHub repository and web sites like Bitcoin.org. While the code is completely open, the vast majority of miners run code released by this Bitcoin core team. This is because running any other code has a high risk of being separated from the main network. If you were a voter or miner and run software that disagrees about what a valid block is with the rest of the network, even if the disagreement is caused by a bug in the core code, your blocks may be ignored by the rest of the network. Surprisingly, the only real specification for Bitcoin is the live C++ code that the majority of miners are running. Despite this risk, miners are beginning to run different software as the block-size debate has spurred developers to publish different solutions. One release simply increases the block size to 8 MB. Another has an averaging system. Another lets miners vote. And yet another lets miners accept large blocks but only produce smaller ones. There's currently no consensus or indication of which will win out. The debate has also spurred discussion beyond just what the block size should be to fundamental questions about governance. How should future decisions be made and who should make them? Although Bitcoin is idealized as a math-based trustless currency, many are realizing that it is ultimately a social agreement between people. Some technical decisions will help one group at the expense of another with no clear superior technical metric. In other words, the decisions are political.


24. Upgrading Bitcoin Via Soft and Hard Forks If and when changes are introduced, they will be implemented in what are called hard or soft forks. A soft fork is a rule change that old software will still accept, whereas a hard fork creates new blocks that the old software rejects. There is potential disruption on either path, but most developers feel a soft fork is much less risky. Let's see how both of these work. With either change, developers usually build in a voting mechanism that enables miners to make sure a majority are upgraded before activating a change. This is usually done with a version setting in each block. For instance, the change won't activate until 750 of the last 1000 blocks indicated an upgrade in the version setting. One thousand blocks is about a week. We'll walk through the hard fork case first. Suppose the block size is increased to 2 MB. Older nodes would see blocks over 1 MB as invalid and ignore them. So even through a majority of nodes are running new software, the minority would continue on its own branch splitting the network. Furthermore, all the non-mining nodes that don't upgrade will also be on the older branch potentially including wallets and web services. Now let's walk through a soft fork. Just for illustration purposes, suppose the new software decreased the block size to 0.5 MB. This imposes an additional constraint on the rules that old software does not know about but considers valid. As new blocks are generated, the old software is unaware but happily builds on either. The new software only builds on smaller blocks. However, since we assume a majority of miners are running the new software, no more old blocks will ever make it into the chain. Even if the old software wins a few blocks in a row, the new branch will eventually win out because it has the majority of hashing power. The advantage of a soft fork is that older software will at least accept the new blocks. But there's still some potential disruption. Miners running older software will be wasting energy creating blocks that will never be accepted. And non-mining nodes will also not be aware of the new rules. Consider the case of the pay-to-script hash feature which was added as a soft fork. This added a new constraint to the output scripts that look like this. In English, this reads, In order to spend this coin, supply text that hashes to this given value. The new software added an additional constraint that the text also needs to be a valid script and not just random text. Someone running old software could receive a transaction spending an invalid script and ship a good only to find out later that the rest of the network rejected that transaction. Bear in mind, this is only possible if the receiver accepts zero confirmation transactions though. Since the majority of miners switched to the new software, no older blocks that would accept such an invalid transaction will ever make it in again. So whether hard or soft fork, eventually all software needs to update.


25. Segregated Witness Update Getting back to the block-size debate, increasing the block size to 2 MB would be a simple code change. But since that would be a hard fork, most developers are nervous about introducing it. It turns out, however, that another unrelated feature will increase the block size as a side effect and can be implemented as a soft fork. This interesting new feature is called segregated witness. The term witness here is just a different word for the word signatures that we've been using to describe the scripts that unlock funds. In mathematics, a witness is an example that proves a statement. For instance, if I say there exists a number bigger than 1000, the number 1001 is a witness that proves that statement. Recall in Bitcoin transactions the signature in most cases is more than a simple signature from public key cryptography but rather a script that fulfills a spend condition specified in a transaction output. So segregated witness is referring to the thing we've been calling a signature, but the word witness is used to cover the broader concept and avoid confusion with public key signatures. The segregating part of this new change refers to pulling the signatures out of transactions. This was originally introduced to solve a problem where transactions could be superficially changed called transaction malleability. One of the ways this occurs is due to a subtlety in the elliptic curve cryptography. Imagine if a number 5 is a valid signature, then something like 5 and -5 are both valid. Suppose you create a transaction and sign it with 5, but someone else changes the signature to -5 before passing it along. This is only an issue before a transaction gets confirmed into the blockchain. Well, it's not necessarily a security vulnerability as a hacker can't change the contents of a transaction including the recipients or amounts. It does end up changing the hash and, therefore, the Id of the transaction. If you made a transaction that some malleates, you wouldn't be able to find the transaction in the blockchain based on your original hash Id. You could still look it up based on your addresses. The changed Id could also break some protocols I'll talk about a little later that rely on links between unconfirmed transactions. To address this, the segregated witness feature separates the signatures or witnesses from the transaction. In this way, the hash of the transaction will not change even if the signature does. It also introduces some other benefits. For one, after a transaction has been verified, you can forget about the signatures since you don't need them to calculate who owns what coins. This means storage for the blockchain could be drastically reduced since signatures take up about two-thirds of every block. It also means syncing the blockchain could be much faster if you don't care about validating signatures. There are some other potential benefits as well making it easier for SPV clients to verify blocks and potentially making it easier to extend the scripting language itself. Getting back to the block size, by pulling signatures out of the transactions, the segregated witness feature basically changes the rules for how a block size is calculated subtly allowing more transactions to fit in with a soft fork change. With the current segregated witness proposal, the block size gets effectively doubled. Now older nodes will have to upgrade to properly interpret these blocks, but the network won't split. Also note that nodes that want to fully validate the blockchain will still have to store and transfer the same amount of data per transaction, so this feature does not address concerns about centralization due to small operators not being able to handle more data.


26. Payment Channels If the block size does not get increased, it's highly likely that fees will increase making smaller transactions cost prohibitive. Already as of March 2016, the average cost of sending a transaction is approaching 10 cents. Because of this, many are looking at ways to send small, low-risk transactions off the main Bitcoin chain. One of the most popular services for sending small amounts of Bitcoin is ChangeTip. Once you create an account and fund it with Bitcoin, you can tip extremely small amounts on social services like YouTube and Reddit. On Reddit, you can tip a poster by writing, /u/ChangeTip send $.50. The ChangeTip service will automatically respond with a link that lets the poster collect that tip. ChangeTip can provide almost free service since it's simply changing two numbers, the balance for the sender and the receiver, on its own server. It will charge a small fee to withdraw Bitcoin. The downside is that ChangeTip is a centralized service like PayPal. There are also some exciting innovations coming that allow small payments to be sent both without high fees and without trusting a third party. One of these is called payment channels. Suppose Alice runs a Wi-Fi hotspot where people can access the internet for $.01/MB. Bob wants to use Alice's Wi-Fi but purchasing each MB with a standard Bitcoin payment would cost more in fees than the service itself and would also require ten-minute wait times for each purchase if Alice didn't accept zero-confirmation transactions. One way Alice could provide this service with lower fees is to ask Bob to deposit, say, $50 when he first connects. Then when he's done using the service, Alice calculates his total usage and sends him a refund for any amount not used. Alternatively, Alice could allow Bob to just use the service and charge him later, like a typical tab at a bar. The problem with these methods is that they require trust. Either Bob hopes Alice doesn't steal his deposit, or Alice hopes Bob doesn't run off without paying. The payment channels protocol enables a similar arrangement but without the trust requirement. I'm going to switch to using millibits (mBit) or 1/1000 of a Bitcoin. Bob first creates a two of two multi-signature transaction for 50 mBit. This transaction does not pay Bob or Alice individually, but rather locks the funds in an output condition that requires both Bob and Alice's signatures to spend. This is the payment channel funding transaction. To purchase his first MB, Bob creates a new transaction sourcing that funding output and giving 49.99 mBit back to himself and 0.01 to Alice. He signs the transaction and sends it to Alice. At this point, Alice could sign and broadcast the transaction to receive 0.01 mBit, but she doesn't because Bob plans to keep using the service. When he wants to buy a second MB, he creates another transaction sourcing the same funding transaction. This time sending 0.02 mBit to Alice and 49.98 back to himself. This transaction replaces the first because it is spending the same output. This pattern continues until Bob tells Alice he's done, and then she broadcasts the final transaction, say, for 40 mBit back to Bob and 10 to her. At no point was Alice at risk of Bob not paying as she could have broadcast the last transaction received. And Bob was able to pay for Wi-Fi service 1 MB at a time without risking that Alice would run off with any deposit. The payment channel protocol effectively allowed them to exchange 1000 transactions while only broadcasting and paying the fees for two transactions. The middle transactions are real Bitcoin transactions, they're just not posted allowing payment channels to leverage Bitcoin security without touching the network. There are a few caveats I should point out. Consider that the overall funding transaction was sent to an output that required both Alice and Bob's signatures. If Alice never responded, Bob's funds would be locked away forever. To handle this case, Bob could require Alice to give him a full refund transaction locked for 24 hours before Bob posted his initial payment. This way, after 24 hours, Bob would get his money back if Alice disappeared. The 24-hour lock is provided by a parameter on transactions called nLockTime. If the nLockTime parameter is set, the transaction isn't considered valid until that time. This solution has some vulnerability due to the transaction malleability issue we discussed previously. A malicious server could modify the original funding transaction before it posted the blockchain making the reference to that transaction and the refund transaction invalid.


27. Check Lock Time Verify & Replace by Fee Luckily, a new feature just activated provides a more secure solution to this protocol and several others. It's called check lock time verify and provides a secure way to lock up funds until a given time in the future. Here's how this would work in our example with Bob and Alice. Bob adds an additional line of logic to his original funding transaction output script that says the funds are spendable by just his signature after 24 hours. The full logic looks like this. This is the script language inside Bitcoin's transactions. Translated into English, this says the output is spendable with Alice's and Bob's signatures or if Alice's signature is not valid, the output is spendable if the current time is greater than the time specified. The difference between this technique and the previous nLockTime technique is that here the time delay is embedded in a script confirmed in a blockchain, whereas nLockTime transactions cannot be confirmed until their time threshold is passed. One constraint is on the blockchain; the other is not. Here's how the version that is not on the blockchain could break our payment channel refund. Bob insists that Alice sign the refund transaction before he posts the funding transaction. Remember, the whole point of the refund transaction is to have a backup in case Alice disappears. And here's the problem. Alice could sign the refund, but if Bob's funding transaction gets changed through transaction malleability before it gets confirmed, the refund now doesn't point to the right output and is worthless. By supporting time locks inside scripts, many other interesting smart contracts are possible. For instance, suppose Charles and David operate an account requiring both of their signatures to spend. With the new locking script, they can include a safety mechanism that allows spending by just one of the two after some delay in case one of them disappears. The payment channel idea of guaranteeing payments without actually posting transactions and paying fees can be extended to a much larger net of people in a new protocol called lightning network. This includes sending transactions through networks of payment channels. The idea if successfully implemented will provide a substantial increase in capacity to the Bitcoin network. Only transactions to set up and close payment channels would need to touch the Bitcoin network while the majority could be completed off-chain. People would use the Bitcoin network and protocol as a guarantee of payment without actually needing to transact on it in those cases. Not only would people save on fees, but transactions could be finalized in msec instead of minutes. One drawback to the lightning network idea is the need to lock away funds while a payment channel is open. This means there will still likely be fees for using the network to compensate people for having funds locked up. Also, there are several other changes needed to the core Bitcoin code, namely the use of script locks based on relative time and not absolute time. I mentioned already that full blocks will likely cause fees to increase as there will be more competition to get transactions into limited space, and miners will choose the transactions with the highest fees first. Beyond the obvious downside of having to pay more to send Bitcoins, another issue is that transactions with too low a fee may be stuck. For instance, if you send a transaction with a 0.001 mBit fee when there's an endless supply of transactions offering a higher fee, miners may never include your transaction. Why not simply broadcast another transaction with a higher fee? Most nodes are programmed currently to ignore such double-spend attempts. However, a new patch just released changes this so that nodes will accept the higher fee version. This allows you to broadcast a low priority transaction with a low fee, wait and see if it gets confirmed, and only if necessary broadcast a higher fee version later. The downside of this patch is that zero confirmation transactions become riskier. The change makes it easier to undo transactions by changing the destination of a transaction along with its fee. This means use cases like buying a cup of coffee where the seller typically doesn't wait for a confirmation are more exposed to fraud.


28. Payment Protocol, Privacy and CoinJoin There are two more topics I'd like to briefly mention before concluding this module. Another recent addition to Bitcoin, BIP70, known as payment protocol, provides much better security and convenience when exchanging payment details. As explained so far, to get paid, you provide a Bitcoin address and an amount to a payer. The payer then broadcasts a Bitcoin transaction for that amount to the Bitcoin network. This is a little scary. Are you sure you typed in the right address? Are you sure someone else didn't intercept the address and swap it for one of their own? Furthermore, if you did accidentally pay the wrong but honest person, it's not always possible to determine where to return the money. Transactions can have inputs signed by several different people. The payment protocol addresses many of these concerns starting with a way to prove the Bitcoin addresses supplied were created by the company you think they were. This is made possible by creating a payment request that includes the Bitcoin address and then signing it using the same technology that protects encrypted websites. Allow me to take a brief aside to explain how information you send to websites is secured. When you go to Amazon.com, Amazon sends you its public key so you can encrypt your communication to Amazon, like your credit card number. To make sure you're using Amazon's public key and not a hacker's, Amazon also provides a certificate containing a signature from Google allowing you to check that Google believes Amazon's public key is correct. You can then check Google's signature because your operating system shipped with its public key. This is a fairly large simplification, but the same chain of public keys that allows you to check websites can allow you to check that a payment request and all its contents was generated by the company you think it was. The protocol also includes a few more useful fields including a descriptive memo, a refund address, and the option to include not just one receiving address but several. Without a refund address, a merchant would have to reach back out to a customer to ask where to send funds. The option to include several pay addresses in a payment request brings up a final topic--privacy. Suppose you work at a company that pays salary in Bitcoin. Now at dinner if you've sent $10 to a friend to cover your share of the tab, that transaction might source a salary payment output, and your friend could see how much money you make. With the payment protocol, you could request your employer pay to 100 addresses in much smaller amounts thereby obscuring your salary. At this point, I'd like to offer a few reasons why privacy is important especially for Bitcoin and financial matters. Many people argue that they don't have anything to hide, and so privacy doesn't matter. Even if you're not engaged in illegal activity, privacy can be important. In business negotiations, if one party knows the financial situation of the other, they could use that information to their advantage. For example, if a large company knows a small company does not have very much cash, they large company could initiate a costly court cast to exhaust the limited funds of the smaller company. Or perhaps a landlord could raise your rent if he knows you recently got a raise. While no one may abuse your financial information today, information on the blockchain is long-lived. Ten years from now, a company might analyze and sell information about your long past spending habits possibly to a bank where you've applied for a loan. Also, there's no guarantee that a benevolent government today won't change in the future. Finally, if funds can be precisely tracked, certain Bitcoin addresses may at some point be blacklisted. By analogy, imagine if a thief stole your wallet that had a $100 bill in it. What if you had written down the serial number on that bill and reported it stolen. Theoretically every person in the world could check any bill received against a blacklist of serial numbers and refuse any bills on that list. But this would impose enormous transaction cost. If such a blacklist were created for Bitcoin, it would impact the currency's fungibility or the equivalency of 1 Bitcoin to another. To prevent a loss of fungibility and increase privacy, there are several proposals that reduce the traceability of Bitcoin. One of these is called CoinJoin. In this protocol, several people submit similar amounts as inputs to a transaction and then get the money returned in outputs. In this way, it's not clear which input went to which output. The transaction effectively mixes the inputs. Interestingly, the transaction can be completed largely in a trustless way. First, the transaction is created with the requisite inputs and outputs. Then each participant signs their input and passes it along to the next for their signature. Since each signature covers all the outputs, there's no risk that the transaction can change throughout this process. If the CoinJoin process is repeated multiple times with different people, the probability that one address is associated with another becomes lower and lower. The downsides of this process include fees needed for each mixing transaction, as well as the practical difficulty in finding equal amounts to mix. If one person comes to the table with 100 Bitcoins and two others with 0.1 Bitcoins, it's very easy to see where the money went. While there are many in the Bitcoin community that see privacy and fungibility as crucial to a currency, that view is not universal, and it's not clear where Bitcoin will end up. Bitcoin is much different than past paper money. It's completely digital so checking every transaction against a blacklist is feasible. Consider that every transaction is already checked for double-spends. There's also less ambiguity than with paper money. The ownership chain is sometimes provable. You may receive a coin one day that is provably linked to a ransom payment. It will be interesting to see where the technology and debate take us.


29. Conclusion and Future Outlook In this module, we've gone a bit deeper into Bitcoin to learn about some of its challenges and recent innovations to address those challenges. The mantra, Be Your Own Bank, means Bitcoin users have complete control of their funds but also the ability to lose access to their funds without any helpline to call. HD or hierarchical deterministic wallets make backups much simpler and also provide needed structure for organizations. The scripting language in Bitcoin also aids in supplying additional structure through multi-signatures addresses such as addresses that can only be spent with three of five signatures. Multi-signatures scripts, along with the addition of time locks, enable contracts for many other interesting use cases. One of these is payment channels, which enable a stream of instant and micro-sized transactions between two people at low cost. If expanded to larger groups through the lightning network idea, it presents a promising way to extend the capacity of the Bitcoin network without compromising on trust. Segregated witnesses in addition to solving transaction malleability will also increase capacity by reducing the amount of data needed by some users. Segregated witnesses will also provide a near term block size increase. Bitcoin is only about six years old at this point but already very successful. It's market cap or price times the total Bitcoin in the world is already over $6 billion. And there are now over 200,000 transactions per day. However, despite what many had hoped, it has not yet replaced credit cards. It's still very rare to find any brick and mortar stores that accept it. Bitcoin has also not replaced Western Union for remittances. The last mile or exchanging Bitcoin for fiat currency is still very difficult. There's a bit of a catch 22 with any currency. The more people use it, the more valuable it is. But people won't use something that isn't already valuable. Along with adoption, Bitcoin faces many other challenges including its usability, capacity, privacy, and centralization. Centralization is perhaps the most concerning as decentralization is arguably Bitcoin's main innovation. Right now very few people control the majority of mining power. There are, however, several thousand non-mining nodes also running, and these counter-balance the power of the miners to some degree since most end users connect through these. But the cost of running a full node will increase as Bitcoin becomes more popular, and there are few incentives to run such a node. Another problem with increased usage is that Bitcoin becomes harder to update. There's more money at stake and more people that need to agree on any given change. There are, however, some changes being developed that will hopefully make improvements easier in the future. The core code is being modularized so that developers can work on specific areas without fearing that the critical consensus code is affected. Several nodes on the network are now running different versions. And hopefully there will eventually be a diverse ecosystem of software all communicating via the Bitcoin protocol much like internet services over TCP/IP today. Since the dawn of Bitcoin, many developers have created whole new systems rather than try to get their ideas incorporated into Bitcoin itself. This is the world we'll explore in the last module, Beyond Bitcoin.


30. Decentralized Applications Beyond Bitcoin Building on Bitcoin with Metacoins, Colored Coins, & Sidechains Created in 2009, Bitcoin has spurred a tidal wave of development in other cryptocurrencies and decentralized systems. This module will give you a brief tour of some of the leading ideas, both in new currencies and other areas ranging from decentralized storage to blockchain power door locks, and even new organizations that exist only in code. Developers will find tangible insights into how many of these systems work and can be used. And while this will be a little technical at times, I also hope non-technical listeners will gain a broad understanding of the possibilities and limitations of decentralized technology. We'll start close to Bitcoin with ideas to make better cryptocurrencies including adding to Bitcoin with metacoins, colored coins, and sidechains, alternatives to proof-of-work namely proof-of-stake, performance and capacity improvements, enhanced privacy and stability-focused coins. We'll also take a brief look at private blockchains and the question of whether something like Bitcoin even makes sense behind locked doors. Then I'll move beyond currency starting with Ethereum, a fully decentralized computing platform that can execute so-called smart contracts. We'll then move to applications enabled by Ethereum like prediction markets, Internet of Things, and entirely code-based organizations called DAOs, or Decentralized Autonomous Organizations. I'll conclude with a brief introduction to storage, identity, and reputation solutions. To get a sense for all the different cryptocurrencies and systems out there, a good place to start is Coinmarketcap.com. It lists projects by market capitalization or unit price times the number of units. Now bear in mind the market capitalization can easily be misleading. For example, if I make a new cryptocurrency called ScottsScamCoin, issue myself 1 million units and then talk a friend into buying just one of those units for $10, the market cap is now technically $10 million. But clearly I would struggle to sell the remaining $9.999 million worth. This is what's called an illiquid market. In other words, one where you would struggle to buy or sell anything. Such illiquid markets are common for smaller currencies and, in general, have overinflated values as measured by market cap. With that warning, one first question to ask is, Why are there so many coins and systems? Why haven't these developers simply contributed to Bitcoin? Many of the systems we'll discuss are not currencies at all, so developing a new system makes sense. But many are different variations on cryptocurrencies. As mentioned in the previous module, there's currently a major debate over how big the block size should be. It could be argued that this detail is somewhat minor compared to things like the consensus algorithm or inflation rate, yet debate over it has caused nearly a year of stalemate. Many people want to experiment with much larger changes to Bitcoin, but there's little will to make such risky changes on something that impacts so much money and so many people. Rather than add functionality directly to Bitcoin, some systems have added on top of Bitcoin. For example, Counterparty and Mastercoin both add an additional layer of protocol on top of Bitcoin similar to the way HTTP is built on top of TCP. Those systems seek to expand Bitcoin's scripting language by, for example, allowing people to post trade offers, which would enable a decentralized exchange to run on Bitcoin. To do this, extra data is inserted into regular Bitcoin transactions. For example, funds are sent to a one of three multi-signature address, but several of the redeeming addresses are special codes rather than real addresses. In order to interpret this added layer of protocol, participants must run software that watches the blockchain and identifies transactions marked with a special flag. Another similar concept is colored coins. The idea here is to track ownership of assets beyond just Bitcoin. Again, participants must run special software that tracks the blockchain and interprets specially marked addresses as having extra meaning. Suppose a given output is interpreted to mean ownership in a company. Then when that output is used as an input to another transaction, the shares of that company can be transferred. If the coin is split in two, the ownership splits in two according to the value of the Bitcoin sent. These so-called metacoins are able to leverage the security, network, and data storage of Bitcoin, but they do have their problems. Many dislike the extra load these protocols place on the Bitcoin network. Recall that every transaction is relayed to every node and stored in perpetuity. There are also security concerns. If $1 of Bitcoin represents $1 billion of real-world assets, the economic incentives that keep an attack on Bitcoin unprofitable may become unbalanced. And, finally, there's a fundamental problem that monitoring the blockchain as required by these add-on protocols is not possible for lightweight clients like mobile phones. With regular Bitcoin transactions, it's possible to obtain a short cryptographic proof that a transaction is truly present in the blockchain, or in other words, that you've really been paid. This is called SPV, or simplified payment verification, and involves nodes sending your mobile phone a chain of block headers and just a few transactions inside a block. With this small amount of data, you get proof that the transaction is in a block and that the block is buried under millions of dollars of hash calculations. With metacoins, however, this lightweight verification balloons quickly. Verifying the last transaction works just like any other transaction. But to ensure you really have the asset, you would need to check the input and then its input and all the way back to the initial assignment between a Bitcoin output and asset. This fundamental difficulty in supporting lightweight clients was a major impetus for Ethereum and other entirely new systems. Because of these challenges, many people seek to make entirely unattached new currencies which are typically called altcoins. The vast majority of currencies on coin market cap are, indeed, altcoins. Whether an altcoin or metacoin, the startup stage can be perilous. Most currencies aren't useful until a substantial number of people adopt them. Also, if the security is based on proof of work like Bitcoin, the system could easily be attacked if there aren't many miners participating. Then there's the question of how to distribute a new coin. Bitcoin slowly creates and distributes coins to random participants through mining. But some currencies choose to start out with a thick supply or large initial amount. Many projects offer an initial crowdsale for these coins, which acts as a way to give the new coin a trading value and also raise funds for development. You can think of this like a traditional IPO or initial public offering stock sale. As you might expect, there have been several scams that only resulted in rich founders and no new system within any lasting value. The Counterparty project we just mentioned took an interesting approach, however. They had an initial sale where people could buy the Counterparty currency with Bitcoin. But instead of collecting the Bitcoins themselves, the Bitcoin was burned. Here's how this worked. During the initial sale, an exchange rate was set between Bitcoin and Counterparty. To buy Counterparty, you would send Bitcoin to a special address not redeemable by anyone, that is, one not based on a private key, which effectively destroyed or burned the Bitcoin. The Counterparty software would recognize these transactions and assign the new currency based on how much Bitcoin was burned. It was hoped that this would engender trust in the community since the founders wouldn't be collecting Bitcoin themselves. It also bootstrapped the value of the new currency since something of existing value had to be traded for it. This idea of bootstrapping a currency by training with Bitcoin can be extended to a powerful idea called sidechains. Instead of burning Bitcoin, what if the Bitcoin could simply be locked up and then traded back later on. Suppose somebody wanted to create a new system called Fancycoin. Just like Counterparty, new Fancycoins can be created by sending a Bitcoin to a special locking script. Now rather than monitoring the Bitcoin network, the Fancycoin software could be _____ proof that the Bitcoin is properly locked. This proof would be similar to the SPV proof used by lightweight clients now to verify transaction existence. If a user decides Fancycoin is no longer interesting, he could send the Fancycoin to another locking script on the Fancycoin chain and then take a proof of that back to the Bitcoin chain to unlock funds there. In this way, the new chain is said to have a two-way peg to Bitcoin. Sidechains provide a promising way to experiment on new systems without the perils of bootstrapping entirely unconnected altcoins. The only downside is that the core Bitcoin software needs some additional changes to fully enable transfers. With that overview of how people have attempted to build on top of Bitcoin and bootstrap new systems from Bitcoin, let's dive into some of the altcoins. We'll start with Lightcoin, one of the first offshoots from Bitcoin and its attempts to improve on proof-of-work.


31. Proof-of-work Consensus Alternatives, Challenges Recall that proof-of-work is the mechanism that allows anonymous strangers all over the world to vote on transactions and effectively decide as a group what the true ledger of Bitcoin balances is. It is said to be the first successful solution to the byzantine general's problem, which I'll briefly describe since many other systems reference this name. The byzantine army is surrounding an enemy city and is deciding whether to attack or retreat. Several generals are distributed around the city and must coordinate their actions. They will be successful if they act in unison either all attacking or all retreating. But if they split, both parts will only have partial strength and will likely fail. The generals must decide what a majority of them want and then all act accordingly. The problem is that the messaging system between the generals is untrustworthy. Messengers might be intercepted and coerced. And, worse, some of the generals are traitorous and might send messages that try to intentionally misinform the other generals. How is one general to know if he is following the majority of being tricked? In Bitcoin rather than deciding whether to attack or retreat, the goal is to agree on the order of transactions. Remember that Bob could double spend his money sending 5 Bitcoins to both Alice and Charlie even though he only has 5. It doesn't matter so much whether Alice or Charlie wins, just that everyone agrees one has the money. The proof-of-work algorithm provides unforgeable proof of what the majority thinks. There's no way for a malicious user to masquerade as other nodes to vote more than his fair share. Every vote requires the provable burning of electricity. It's a very elegant solution that ties a definite external cost to every vote. Yet there are many criticisms, a primary one that its algorithm leads to centralization. Because specialized chips called ASICs can solve the algorithm faster than home computers, mining power has concentrated in a handful of large companies that invested in bulk purchases of ASICs and that have access to cheap power. Most people also join pools to smooth out payments, another centralization factor. Litecoin thought to address this problem by making a proof-of-work algorithm called Scrypt that required substantial memory, as well as processing power. It was hoped that it wouldn't be possible to design specialized chips to solve this algorithm, but it appears that new ASICs now deliver a majority of hashing power for Litecoin. Another attempt to make an ASIC-proof algorithm is used by a currency called Dash previously named Darkcoin. The Dash algorithm is called X11, and as its name implies, it uses 11 different hashing algorithms all strung together. The idea is that developing an ASIC that optimizes all 11 of these algorithms will be substantially harder than it was for SHA256, the Bitcoin hashing algorithm. Interestingly, there is one company that is using ASICs to potentially make Bitcoin more decentralized again. 21.co sells miniature computers that include an ASIC chip on board. By mass producing these small computers, it may be affordable for individuals all over the world to again join in the mining effort. They argue that mining hardware has caught up with the most advanced chip manufacturing techniques, so an individual can buy a chip without worrying that it will become outdated in six months. Now at its current price, the $400 computer will likely never provide a return on investment. But 21.co hopes developers will buy it as a fast way to get going in development and to also provide a small source of new Bitcoin during that development. In addition to centralization concerns in Bitcoin's proof-of-work scheme, many see the energy used in Bitcoin system as wasteful. If we assume about 300 W per terahash and a current hashing rate of 1 quintillion hashes per second, we arrive at about 300 megawatts of power for the total Bitcoin network. For comparison, this is about 7% of the power generated by Niagara Falls (4400 megawatts) or about a third of the average power used by the state of Rhode Island in 2014. Proponents say this is a small price relative to the security that the proof-of-work system provides. But detractors worry about the long-term sustainability as Bitcoin becomes more valuable. A given transaction in the blockchain is theoretically only as secure as the cost to re-mine all the blocks after that transaction. To remain secure, the money spent mining and the corresponding energy burn must rise with the value transferred in every block. Some have sought to direct the proof-of-work mining towards useful ends beyond just securing the network. For example, the altcoin, Primecoin, utilizes the search for special prime numbers as its proof-of-work. It's hoped that the discovery of additional primes will assist scientific computing. Several other coins also try to utilize the computation for a greater good including FoldingCoin, which directs resources towards medical problems, and Gridcoin, which attacks scientific problems. Unfortunately, it's quite difficult to replicate the properties of SHA256 with a generic problem. The cryptographic hash provides an unlimited amount of new problems that can't be pre-solved, have a provable amount of work, and are easily verified. Because of this, the problems being solved by FoldingCoin and Gridcoin are not actually used to reach consensus. The coins provide more of a mechanism to pay for computational effort and a way to reach consensus and secure a currency. FoldingCoin is built on top of Bitcoin, and Gridcoin uses an entirely different consensus mechanism called proof-of-stake, which is an important alternative to proof-of-work that we'll talk about next.


32. Proof-of-stake Consensus Proof-of-stake is perhaps the leading alternative consensus mechanism for decentralized and open systems similar to Bitcoin. Instead of voting on the order of transactions with processing power, votes are based on how many coins you own. Let's look at how Peercoin works, the first proof-of-stake system deployed, to begin. The formula for deciding the next block maker in Bitcoin involves hashing the previous block Id, the current block's transactions, and a nonce or random number until the result is less than the current network difficulty. In proof-of-stake, the chance of winning it not based on how many hashes someone runs but how much currency they have. The formula hashes the previous block like before, but also the current time and an unspent output. On the right side because the difficulty is multiplied by the balance of that unspent output, it gets easier the more money you have. In this way, the more currency you own, the more influence you have on the network, which makes sense presumably because you have more to risk if something goes wrong. Importantly, also note that the only thing varying in this formula is time. There's no reason to run this hash more than once per second. Every second everyone in the network calculates this hash. And anyone whose hash falls below this threshold can public a set of transactions in a block signing it with the private key that proves they own the specific UTXO used in the formula. Like with Bitcoin, multiple blocks occasionally get produced at the same time, but this is rare, and it quickly resolves when one branch grows faster than the other. In addition to the reduced energy used to reach consensus, proof-of-stake also avoids the centralization towards a handful of companies that occurs with Bitcoin's proof-of-work. There's no advantage to investing in specialized hardware since you only need to compute one hash per second. There also doesn't appear to be a way to form mining pools. Proponents also argue that proof-of-stake has a higher security margin. To overpower the network, an attacker must borrow a sign percentage of the total value of the currency, which could be billions of dollars. An attack on Bitcoin would only require rental of mining rigs for the duration of the attack, a theoretically much lower value. So with all these advantages of proof-of-stake--environmentally friendly, less centralization, better security--what's not to like? Proof-of-stake seems to have worked fairly well for both Peercoin, the original implementation of a proof-of-stake system, and other newer stake-based coins like NXT, pronounced Next. Let's return to the fork case above where multiple people publish valid blocks at the same time. Presented with two options, most people will just build on top of the first one they received. But, remember, in proof-of-stake, it doesn't cost anything to build. It's just one extra hash. So why not solve the hash for the other branch too just in case. And when those fork, why not build on all of those branches? Even if one of these branches is currently winning, why not build on past branches just in case one of those overtakes the others? Maybe someone pays you a small bribe to do this, which would be nice since it doesn't really cost anything to calculate a few extra hashes. In proof-of-work, building on branches that aren't likely candidates to be the winning branch wastes real money since blocks take trillions of hashes to solve. But in proof-of-stake, there's no cost, so why not? The free nature in proof-of-stake leads to some fundamental questions about whether the consensus algorithm will always converge to a single history and whether the system could withstand an attacker paying only a small bribe. In Peercoin and other currencies, it seems altruistic goodwill has prevailed. The miners have thus far behaved nicely and only mined on one branch at a time. But as a currency grows in value, it's unlikely goodwill will prevail. To counter this threat, a range of additions has been proposed, but there doesn't seem to be consensus that any of the solutions are entirely foolproof. One solution is to punish miners who work on multiple branches, consider a potential double-spend attack where an attacker buys something in branch B and hopes to undo that purchase by switching to another branch A after receiving goods. The attacker pays a bribe to a substantial portion of currency holders to mine branch A in secret. After receiving the good, the attacker signals to his conspirators to publish the new longer secret branch. And while those miners wouldn't want to hurt the value of the currency they hold as individuals, how much of a bad effect could one of them really have? To prevent this, we would like to punish those miners that were working on both branches, but how do we discover who was doing that? It's very possible that the attackers wouldn't have found any blocks on branch B so there would be no double-voting evidence. One solution is to select a miner of blocks well before a fork. This way, the selected miner must choose between branches A and B, and if he builds on both, he can be punished. But this solution leads to the problem of selecting miners. Suppose the selection of block K depends on the hash of the block 1000 before it (K-1000) like this. However, a clever attacker might try to pick transactions in block A-1000 so that he ensures he will be the next miner. This is known as grinding and potentially brings proof-of-stake back into the realm of proof-of-work where miners are once again trying trillions of hashes. To address this, various more sophisticated ideas have been proposed to change how future miners are selected. But it's not clear at this point whether any scheme will survive the test of time and a lot of money. So far, we've been looking at the problems proof-of-stake faces in short timeframes, preventing double-spend attacks, and ensuring everyone actually converges on one branch. But the costless nature of creating blocks also introduces some longer timeframe existential questions about proof-of-stake. Since it's easy to compute different chains, what is to stop the original keyholders of the first coins from creating an alternate chain that is longer than the real one? Anyone currently using the system would reject such a large change in history. But how would a new user tell the difference? With proof-of-work, you have proof that a certain number of calculations were performed. But with proof-of-stake, you only have two pieces of valid-looking digital data. To address this long-time scale attack, most proof-of-stake systems provide a checkpointing system where trusted sources provide copies of the chain at periodic intervals. But there's that word that Bitcoin was designed to avoid--trust. One other nice feature of proof-of-work is that it provides a built-in way to randomly distribute currency to people that don't already have the currency. With proof-of-stake, you have to have stake to get more stake. How will new users get coins, and will existing stakeholders only get richer? I already mentioned doing an IPO or large initial sale to kick off an initial distribution. Many dislike initial sales because of their tendency to be used in scamcoins to enrich the founders. But NXT points out that its initial stakeholders currently hold less than Satoshi Nakamoto, the creator of Bitcoin. Other systems like Ethereum, which we'll discuss shortly, currently use proof-of-work and plan to switch to proof-of-stake sometime in the future. Peercoin uses a combination of proof-of-work and proof-of-stake to get the distribution benefits of proof-of-work and the low cost consensus benefits of proof-of-stake.


33. Permissioned and Private Blockchains Bitcoin provides a completely anonymous open and decentralized system for reaching consensus about a ledger. But what if we didn't care about anonymity, openness, and decentralization so much? What would be left? Is a closed blockchain without anonymity anything more than a distributed database? Most distributed systems in the world utilize trusted servers. Bitcoin, on the other hand, fully expects attacks from both within and without. This is where I believe blockchains thrive. They enable interactions without trust. And this is valuable even without anonymity, openness, or decentralization. In this clip, I'm going to discuss several use cases where we relax some of the goals of Bitcoin. Let's start with BitShares, a system I believe to be slightly less decentralized but much faster than Bitcoin. BitShares uses a consensus algorithm called delegated proof-of-stake, which is to proof-of-stake as a representative democracy is to a pure democracy. Currency holders elect delegates who then take turns forming blocks. The turns are decided in rounds ahead of time so everyone knows who the next block producer will be. This means transactions can be sent directly to that delegate for maximum speed. If a delegate misbehaves, they will be quickly voted out. While the system seems to have worked well so far, it brings questions of centralization and anonymity. The delegates must campaign to become elected, so it seems possible an attacker could identify and target the delegates. Many banks and other enterprises have begun looking at utilizing blockchain technology for internal use in a closed network. Consider that while the banks know who each other are and have some level of trust with each other, this doesn't mean they're married to each other. One bank, for example, would probably not allow the other bank to directly modify its database. The banks would also likely not trust a single member to maintain the books for everyone else. So there is still a certain lack of trust between the banks, and this is where blockchain technology can come in. Blockchains allow members to verify that everyone obeyed the rules using cryptographic proof. Traditional databases simply have permission-based roles and might have an activity log. But blockchains utilize digital signatures and hashes on data that make it impossible to deny responsibility or change history. Because of this cryptographic proof, there is no need to trust a third party for managing exchanges. Many international wire transfers go through a sequence of banks that have trust relationships with each other. It seems possible that the cost and delays of this could be replaced by a single atomic transaction. Also, in securities trading, oftentimes there are third parties that maintain ownership records or hold onto cash while a security is being transferred to avoid so-called counterparty risk, including bankruptcy during the transaction. In today's electronic world, it's remarkable that security trades still take three days. That delay slows down trade and also introduces risk until the transaction is completely settled. Having a provable ledger not only aids the members but could also decrease the cost of regulation. Instead of expensive audits, regulators could rely on cryptographic proofs about where money is. Going beyond the financial industry, there are also potential benefits in the global supply chain where inventory levels must be tracked transparently. And going further than simply tracking assets, anytime the computer systems from one organization need to interact with a computer system from another, having a cryptographically provable interaction in record can help reduce the need for trust, which ultimately means lower risk and cost due to third parties. This becomes especially exciting with smart contracts or agreements that execute automatically, a topic we'll dive into later. So for all these situations where there isn't complete trust between parties and having an immutable and provable record is important, closed blockchains may provide a new way to interact much faster and cheaper. There are several companies offering so-called permissioned or private blockchains. One of those is MultiChain, which provides customizable consensus. Consider our example of five banks all maintaining a blockchain ledger. It would be silly to use Bitcoin's proof-of-work since there's no desire to offer censorship persistence or allow anonymous participants. Instead, the role could be that new transactions must simply be signed by all five banks. MultiChain allows all sorts of options like only requiring a certain percentage of participants to sign these transactions, say three out of five. An organization that many of the large banks have joined called R3 has recently released an interesting blockchain product called Corda. Unlike Bitcoin in which every transaction is visible to all participants, Corda allows configurable visibility, for example, restricting visibility only to the parties that interacted in a given transaction.


34. Improving Performance with Tendermint, Ripple & BigChainDB Tendermint, Ripple, and BigChainDB have consensus algorithms that offer some promising improvements on performance. The systems build on top of decades of research and distributed databases and consensus and attempt to add blockchain qualities such as cryptography, immutability, and byzantine attack resilience. For example, Tendermint claims the ability to function with up to one third of participants attacking the system. And by function, I mean that transactions keep processing and everyone reading the resulting ledger can trust that it reflects the majority will. I believe there may be some compromises in terms of decentralization, anonymity, and openness with these systems. But this is certainly debatable. The Tendermint system starts with a group of validators that must post a deposit to participate. This deposit will be forfeit if they're caught doing some malevolent. Since it requires a stake to participate, the system can be considered a variant of proof-of-stake. Then rather than the proof-of-work lottery system where one member decides the next block, all the validators try to decide in unison to approve a new block. The goal is to have a block that all the validators agree is valid and, importantly, vouch that they saw everyone else agree on. But this is a little bit of a chicken and egg problem. You need to vouch that other people that vouched, but they can't vouch until you vouch. To get around this beginning stalemate, the algorithm works with several rounds during which all the validators signal to each other increasing certainty about a block's acceptance. To begin, one validator proposes a block and shares that block with all the other validators. This proposer role is decided in the turn-taking manner and randomized every round. When the other validators receive the proposed block, they first broadcast a preliminary vote for that block that effectively means, This block is valid. And if everyone else voted for this, I would approve it. Then additional rounds occur where validators advance a block only if they hear that another two thirds of other validators agree on that block. If a quorum less than two thirds of other votes don't come in, the process restarts. If two thirds of validators all approve a block, a final commit vote is broadcast that effectively says, I approve this block, and I also witness that two thirds of other validators approve this block. Ripple works similarly in rounds but collectively decides on the transactions within a block. Each validator can propose a set of transactions for a new block. As validators receive transactions from others, they vote on transactions that the other validators have also voted on. In the first rounds, the threshold for keeping a transaction is low, only, say, 25% of other validators must have approved a given transaction for it to pass to the next round. In the last round, each validator only approves a transaction if 80% of other validators have approved it. Ethereum's future Casper algorithm also works in rounds with each validator betting on the block they think will be most likely to win. There are numerous details I've left out of these, but I wanted to provide a sense for how these round-based algorithms work as they offer much improved performance. And speaking of performance, when evaluating the pros and cons of all these different blockchain systems, it's useful to have a set of metrics with which to compare those systems. First, are the basic requirements even the same? Obviously, a private network among several banks is not trying to achieve the anonymity and censorship resistance of Bitcoin or resistance to byzantine attacks. But it does want a provable audit trail and one that can't be manipulated by a single member. Once the high level requirements are understood, we can move to raw performance, which could include things like the number of transactions per second, transaction synchronization time or how long it takes all the nodes to become aware of a transaction, a transaction finality or how long it takes for a transaction to be irrevocably stored, (note that in Bitcoin a transaction can always be undone, but it becomes more and more unlikely over time), overall storage size, how big can the database become, and perhaps some metrics from the traditional database world like how long queries take. Litecoin was one of the first coins that tried to improve the transaction finality time by reducing its target block time to 2-1/2 minutes. While this provides a faster initial block, the total security depends on the total amount of electricity burned, not necessarily the number of blocks. Also, in Bitcoin, which has a 10-minute block time, many companies now accept zero confirmation transactions, ones that aren't yet in a block for low-risk amounts. These approvals can happen in seconds, so it's not clear that Litecoin has speed advantages in the short or long-term. Tendermint, Ripple, and Ethereum's future Casper proof-of-stake algorithms promise much faster transaction finality hopefully on the order of seconds. A new product called BigChainDB has recently introduced a very interesting take on blockchains that promises magnitudes better performance. Instead of trying to improve the speed of Bitcoin-like blockchains, they started with an existing distributed database and layered on top some of the features of blockchains like public and private key permissions and the cryptographic labels and links that provide immutability. As existing distributed databases have decades of research and development behind them, BigChainDB's strategy seems like a very promising way to improve performance. They're already claiming over one million transactions per second. They also benefit from the querying capabilities of existing databases. Most Bitcoin systems utilize another database beyond just the list of transactions stored in the official blockchain to enable faster searches. Finally, on the capacity side, BigChainDB doesn't necessarily store every piece of data on every computer. By splitting or sharding data across participants, it hopes to support terabytes of data rather than the 50 GB on Bitcoin that must be replicated by every node. It's unclear at least to this author where the limits of BigChainDB are in terms of openness and censorship resistance. Can anonymous participants join and leave the network at will? And will it still function if 15% of its nodes are byzantine attackers. While we're talking about BigChainDB, I want to very briefly mention the fascinating application that spurred its development, a product and company called Ascribe. Ascribe helps artist claim and track their work by fingerprinting their art and then tracking it all over the web. Ascribe stores an initial ownership record of the art and its fingerprint on the Bitcoin blockchain providing an immutable record of ownership. They then crawl the web looking for that fingerprint. To track millions of pieces of art, they need much more data and speed than Bitcoin's blockchain provides, hence the development of BigChainDB. This idea of storing a fingerprint or hash of a document in a blockchain is also being used in many other industries to provide notary or timestamping services. It's one of the more promising non-currency use cases for which blockchains are beginning to be used.


35. Better Privacy with Monero, Ring Signatures & Stealth Addresses On a first look, Bitcoin is seemingly completely anonymous, but this assumption weakens as soon as you begin spending money. If you received a transaction for 2 Bitcoins and then another one for 3 Bitcoins, and then try to spend 5, in most cases, those will be linked in a single transaction as inputs. When you spend that money, you also attach yourself to the new recipient, and he in turn to whoever is his recipient. Each output becomes an input, so a clear ownership chain develops. While there is some ambiguity, for instance, it's sometimes hard to tell whether an output is going to someone new or back to the original owner, every transaction creates statistical information that is forever available for analysis. And once a few real identities can be connected to one address, it's possible to trace to and from those addresses to other real identities. Identities are typically connected to addresses at the exchange points. When goods and services are bought or when Bitcoin is exchanged for fiat currency, a merchant would need to know who to ship a product to and governments usually require exchanges to know your customer to help thwart money laundering and terrorism. There are certainly some cases where it can be argued that privacy has a downside. Governments trying to investigate crimes or prevent terrorism would lose a valuable tool if transactions couldn't be traced. But there are also valid reasons for privacy as discussed earlier. Having financial information available to competitors can severely hurt negotiators. A competitor might try to carry out predatory pricing if they know a business is close to running out of cash. And on a personal level, information about your financial transactions may be used against you perhaps by insurers or future employers. And while no business or government may misuse information today, there is no guarantee that won't change in ten years. Many also worry that fully traceable transactions pose a threat to the fungibility of a currency or the idea that every Bitcoin is equal to another. If a particular address becomes marked has having been involved in a crime, others may not accept coins linked to that address. With that preface, let's look at a new cryptocurrency that promises major improvements to privacy--Monero. Monero still uses the same input/output transaction scheme as Bitcoin but seeks to break the links between transactions and between transactions and owners, all while providing a public record that ensures no one double spends money. This clip gets a bit technical, so feel free to skip to the next clip that describes what may provide the ultimate in privacy--zero-knowledge proofs. Let's start by looking at the links between transactions. Monero uses a mixing idea similar to the CoinJoin technique discussed in the last module where multiple people participate in a single transaction. Imagine five people coming together and each putting a $10 bill on a table, mixing them all together, and then everyone takes a different $10 bill back out. The CoinJoin protocol in Bitcoin requires the active cooperation of different people to jointly create a transaction and usually a third party to manage it. Monero uses an algorithm called ring signatures to allow people to create this ambiguity without directly working with others. Also, the Monero algorithm works on outputs and not transactions. This means outputs from different times can be used making timing analysis of the blockchain much harder. Monero also obfuscates analysis of amounts by automatically breaking down amounts into similar values. For example, 564 Monero would be split into 500, 60, and 4, and then mixed with other outputs of the same value. I'll describe the essence of ring signatures briefly to provide some intuition for how this mixing process works. In Bitcoin when you send someone money, you're effectively assigning those funds to a public key. The recipient can then spend those by proving she has the corresponding private key through a digital signature. With a ring signature, you include some decoy public keys along with the real recipient's public key. Using ring signature magic, she is able to create a signature that proves she owns one of those keys without revealing which one. This is made possible because the operations inside the ring signature mix all the public keys together. To make a signature, generate random numbers for all the public keys you don't own in the set. Then multiply those random numbers by the public keys and add that sum to another variable times your own public key and set all that equal to a final random number, v. Now solve the equation for XMine, which as the math works out only you can do because you know the private key to your public key. Others can verify it by multiplying all those Xs and public keys together and checking the sum. Now the math I just described is missing numerous details including some hash functions and elliptic curve operations, but the overall idea is similar. By checking a mixing of public keys, it's not possible to determine which public key the generator of that signature actually owns. Now if this was used on its own, people could double spend because it's intentionally impossible to see which output someone is spending. To counter that, spenders must also publish a marker calculated from their public and private key that effectively prevents the public key from being reused. For every transaction, observers check both the digital signature and this list of markers to make sure a public key hasn't been reused. This means that a public key could only be used once, which brings us to the second part of how Monero enhances privacy, disconnecting the links between users and transaction outputs. This technique is known as stealth addresses and can already be used with Bitcoin now by adding some extra information in transactions. Stealth addresses largely provide an automated way to gain the same benefits as simply generating a new receiving address for every transaction. This prevents transactions from being linked to each other but is a hassle. Rather than having to generate a new address for every transaction, stealth addresses allow Bob to post just one special public key. Every time someone sends him money, they use his posted public key and mix it with some random data to calculate a one-time public key for a single transaction. To spend the money, Bob uses extra data also posted in the transaction by the sender to recover the corresponding private key and spend the money. It uses the shared secret approach from a Diffie-Hellman key exchange. A color analogy is a great way to explain it. The goal is for Bob and Alice to calculate a secret color that no one else can determine. They each start off with a personal secret color, somewhat like a private key. Then they agree on a shared public color, yellow. They each mix their secret color with the shared color and pass the result to each other. Then they mix the shared color with their secret color again and arrive at a new color that no one else can calculate. Both Bob and Alice mix three colors, but the public only saw the public shared color and the partial mixes. Although I won't go into the precise details, you can think of the public shared color as the extra data that the sender includes in a transaction. From there, the sender and receiver can calculate a shared secret. The sender uses the secret to generate a one-time public key. The recipient uses it to generate a corresponding private key. The end result is that anyone can send funds to a publicly posted address without anyone else being able to connect the public address to any transaction or transactions to each other. Interestingly, the algorithm doesn't require any coordination between the sender and receiver. The sender just mixes a random number with a public posted key and packs some extra information in the transaction that enables the receiver to detect it. The algorithm does require the receiver to run a calculation on every single transaction to see if funds were sent to them. But this can be outsourced to another company and doesn't actually require the full private key. In summary, ring signatures make the links between transactions ambiguous, and stealth addresses break the links between transactions and receivers. When we consider that the ring signatures operate on outputs from any time and with amounts that match, Monero provides a system that is very resistant to analysis and provides very strong privacy.


36. Zerocash and Zero Knowledge Proofs The ultimate private digital currency may come from the ideas behind Zerocash. The protocol uses zero-knowledge proofs to mask participants and amounts but still prove that no one is spending coins twice. Think of an entirely encrypted ledger where all the fields are gibberish, but you have a tool that lets you make sure that all the gibberish adds up correctly. If this sounds suspect, it should. If there was a problem in the algorithms, someone might be able to create money from nothing unbeknownst to anyone else. I want to take a minute to explain how magical zero-knowledge proofs are. The goal is to prove something without revealing any information about it. Imagine you solve a very difficult Sudoku problem and want to sell the solution to someone else. The goal of Sudoku is to take a partially filled matrix and fill in the rest of the numbers without any repeats in the squares, columns, or rows. Now the buyer is skeptical and doesn't want to pay you before knowing without doubt that the solution is, in fact, correct. But how do you convince him of that without showing the answer? Maybe you could show the buyer parts of the solution. The buyer could say, Show me the bottom right square, and you could reveal it proving that there are no repeated numbers in that square. Then the buyer could ask about a different row, column, or square, and you could reveal that. In this way, after enough trials, the buyer could become reasonably assured that you do have the full solution. But the buyer might be worried that you're just making each square in the revealed sections work by, say, filling them in right before showing them and don't actually have a full solution. To address this concern, you could commit to the values before the proving begins. You might run each row, column, and square through a cryptographic hash function and give all the hash results to the buyer beforehand. This way he knows you're not changing anything. But the other problem is that with each test, you're revealing parts of the solution, so this is not a zero-knowledge protocol. So you need a way to hide the solution, possibly be replacing each number with another number for each test. This way, the buyer isn't able to piece together trials to glean more information. Unfortunately, this is where our time in this module and frankly my understanding stops. I hope this helps convey the incredibly daunting task that zero-knowledge proofs are designed to carry out to prove without revealing anything. Zerocash uses this concept to anonymously transfer coins. It's built on top of a Bitcoin-like system with regular transactions, but you can also wash coins by sending them to zerocoins. A zerocoin is like a regular coin created with a transaction, but that transaction is hashed, thereby obscuring the recipients, senders, and amounts. Zerocoins can be sent and received in new transactions, the validity of which is proved using zero-knowledge proofs. Every time a zerocoin is spent, its unique serial number is revealed and added to a public list to prevent double-spending. While zero-knowledge proofs may appear to be a panacea to privacy concerns, it is based on very new cryptography. The zero-knowledge proofs and Zerocash also require substantial computations to create, up to 20 seconds on a modern laptop and gigabytes of data to support them so mobile phone transfers are probably not possible at this point. Transactions are, however, quickly verifiable, so there is a lot of promise. Interestingly, zero-knowledge proofs have already been demonstrated in February 2016 directly on Bitcoin to provide the kind of trustless sale of information I described with the Sudoku example.


37. Seeking Price Stability with Digix, Tether, BitUSD & MakerDao One of the biggest critiques of Bitcoin is its volatility. Because the price of Bitcoin is constantly changing, merchants can't post a price for a product in Bitcoin without fear that they might get substantially less than they wanted or that customers won't buy because the price is too high. Because of this, merchants typically display prices in USD or Euros and only calculate the Bitcoin price at the time of sale. Volatility also causes most merchants to immediately convert any Bitcoin back into fiat currency. In the case of smart contracts, volatility becomes a severe problem. Smart contracts, among other things, are software programs that can send money according to preprogrammed rules. Consider a smart contract to rent an apartment that requires a deposit in Bitcoin. If the value of that deposit cuts in half, the owner is now facing much greater risk. But if the value of the deposit doubles, the renter is locking up too much money. The participants are forced to make an implicit bet on the currency value in addition to entering a rental agreement. Volatility makes pricing more difficult, disincentivizes people from holding the currency, and complicates smart contracts that occur over time. In the long-term, if Bitcoin or any other currency becomes more widely used and more valuable, the volatility should decrease. But in the near-term, several new currencies have been developed to offer of benefits of digital currencies, that is, easy worldwide transfer, low transaction costs, no third parties, use in smart contracts, without the volatility. Digix provides a token directly linked to gold stored in a vault in Singapore. Each token is worth 1 gm of gold and is linked to a real bar of gold that Digix will even send you a picture of. You can actually go to the vault in Singapore and exchange the token for real gold. The connection between the token and the gold bars is secured with a certificate that has signatures from several parties including both Digix and several auditors. Digix is reminiscent of eGold, the first widely used digital currency that eventually was shut down by the US Government. Digix claims improved decentralization and less risk of shutdown since the gold certificates are maintained on Ethereum's decentralized network rather than a database in the Digix offices. Of course, there's still the centralization risk that a government will simply confiscate the gold in the vault. Over time, Digix may open new vaults to reduce this risk. Tether offers a similar concept as Digix but links or is tethered to the US dollar instead of gold. It uses Bitcoin and the Omnilayer protocol as an underlying way to exchange tethers. The Omnilayer protocol was originally developed for a system called Mastercoin, a metacoin. Like Digix, Tether has an auditable vault, but in the case of Tether, it's a bank account located in Hong Kong. To buy one Tether, you give the Tether company $1, and they give you a Tether token worth $1 in exchange. These tokens can then be exchanged freely without the control of the Tether company over the Bitcoin network and eventually exchanged back for US dollars. With both Digix and Tether, the exchange rate is maintained by the willingness of Digix or Tether to always buy or sell the token at the pegged rate. Faith in the value is bolstered by the audits that show sufficient collateral--gold or dollars--is always available for redemption. NuBits provides a stable coin without any backing collateral and a method similar to how national banks pay currencies to other currencies. The organization simply prints more NuBits if demand exceeds supply. In this way, the price is pushed back down by the extra supply of NuBits. On the other hand, if the price drops due to a lack of demand for NuBits, the organization takes NuBits out of circulation by paying people to either temporarily park their NuBits for interest or to burn them. While NuBits doesn't rely on a bank or gold vault not getting taken over by a government, the lack of real-world collateral is a little unnerving. BitUSD and MakerDAO provide a fascinating alternative that provides collateral-backed stability without needing to rely on a central repository. In BitUSD and MakerDAO, the stable coins are created by locking away collateral in a special smart contract. To avoid too many new names, I'll just call the stable currencies StableCoin and assume it can be bought with Bitcoin. We'll also assume that the goal is to peg StableCoin to the US dollar. To get one StableCoin, I deposit $1 USD worth of Bitcoin into a contract, which at $400 per Bitcoin is 0.0025 BTC. This smart contract is an automated program running on the BitShares platform in the case of BitUSD or Ethereum for MakerDAO. Once I deposit the $1 USD worth of Bitcoin, 0.0025 BTC, the contract sends me one StableCoin. I can get that Bitcoin back at any time by returning the stable coin to the contract. But this is problematic when the backing collateral is Bitcoin and not something like gold or dollars, as with Digix and Tether. What if the value of bitcoin falls in half? People might lose faith in StableCoins since there are only half as many equivalent dollars backing them as collateral in the contracts. To address this, the contracts require you to put up more collateral than the StableCoins you get out are worth. You might have to deposit, say, $1.50 of Bitcoin, or 0.00375, to get one StableCoin. This way if the value of Bitcoin drops a little, there's still more than enough collateral backing it. But what if it drops a lot? The contracts are forced closed automatically through a variety of mechanisms possibly involving the original depositor of Bitcoin losing some money. In this way, the system always ensures there's more collateral than StableCoins available so that anyone holding a StableCoin can always get back to a real US dollar. MakerDAO offers an additional layer of insurance for severe market drops, in which the Maker organization puts up additional collateral itself in an emergency. It also provides a mechanism through so-called custodians where a variety of real-world assets can be used as collateral. Now why would someone want to put $1.50 worth of Bitcoin in a contract to only get $1 worth of StableCoin? Not only is Bitcoin locked up, but it's at risk of getting sold at a bad price if the market drops, and there are also fees to use the system. The benefit is the ability to do margin trading. That StableCoin can be traded for another $1 of Bitcoin for a total of $2.50 of Bitcoin. If Bitcoin doubles, the trader makes $2.50 of profit or 166%, whereas Bitcoin only appreciated 100%. The contracts enable traders to make leveraged trades in return for providing the StableCoin. Of course, if Bitcoin went down, the losses would have also been magnified. In addition to guaranteeing collateral, both Maker and BitUSD adjust the cost for traders to create new StableCoins to regulate supply and, therefore, keep the StableCoin close to its target price. Traders of the StableCoins also help to maintain the peg by buying when it's low and selling when it's high because they expect it to return to the peg in the long-term. BitUSD and MakerDAO are two examples of what can be done with smart contracts, automated programs that can send and receive money and respond to real-world inputs. If run on a decentralized system, they provide a way to enter into agreements like these without needing to trust a third party. We'll now veer away from currency and into this larger world with an introduction to Ethereum.


38. Ethereum: A Decentralized Computer for Smart Contracts Many people have looked at Bitcoin's blockchain technology as a tool to provide solutions beyond digital currency. Blockchains allow interactions among groups of people, even anonymous strangers, without needing to rely on, trust, or pay a third party to manage anything. The potential applications are almost endless. DNS or domain name registries, land title registries, asset tracking, insurance, social networks, fully automated Airbnb or eBay-like marketplaces, betting, and prediction markets, identity, voting, and even entire organizations or governments could benefit from trustless interaction and transparency between people. But most of these applications require more sophisticated rules than Bitcoin currently offers. Bitcoin scripting language is intentionally limited to prevent unforeseen problems. For example, there are no for loops. There are also no convenient memory storage, easy way to split outputs, quick access to random numbers, or ways to update transactions over time. Transaction outputs are either unspent or spent. In short, Bitcoin provides a digital system for exchanging currency, not a general computer. Attempts have been made to build on top of Bitcoin with colored coins and metacoins, but these add-ons are difficult for lightweight clients like mobile phones to use. As mentioned earlier, there's no good way to trustlessly verify transactions without downloading massive amounts of data. Many entirely new systems have also been built with specific features like the ability to issue virtual assets or decentralize marketplaces. But new systems are hard to Bootstrap. It can take massive effort to get adoption on a new platform, and in a catch 22, many platforms aren't very useful until they're widely used. Rather than create another altcoin with one or two more features, Ethereum seeks to provide a platform that makes it easy to build any decentralized system imaginable. At its simplest level, Ethereum can be thought of as a decentralized general computer. Its so-called Turing-complete, which basically means that just about any program can be run on it. These programs that run on Ethereum are called contracts. Contracts can have loops, store an unlimited amount of data, send and receive money, and even talk to other contracts. To prevent abuse or a single infinite loop from taking down the entire system, every operation requires a fee payable in Ether, Ethereum's own built-in currency. Like in Bitcoin, every full node in the network runs every single program and stores every piece of information. The nodes use proof-of-work to reach consensus on the order and outcome of operations. Ethereum plans to switch to proof-of-stake down the line. Keep in mind that the goal isn't to run programs fast by breaking up the code and running it on multiple machines, but quite the opposite, to create unstoppable code that is verified by every single participant. In addition to contracts, there are also external accounts that act similar to Bitcoin accounts and hold a balance. External accounts can send either to each other and also trigger contracts to run by sending them messages and Ether. Contracts can also hold a balance of Ether. Unlike Bitcoin's system in which an account balance can only be calculated by adding up all the unspent outputs, Ethereum accounts directly maintain a balance. Whereas in Bitcoin transactions reference unspent outputs, Ethereum transactions simply reference a To and From account and an amount to transfer. To prevent a transaction message from being replayed to execute a transfer multiple times, a per-account transaction counter is included in each transaction. I'm going to briefly demo sending Ether, creating and deploying a contract, and using someone else's contract. I'm using the newly released Ethereum-Wallet, which I believe is a first version of Mist, a program that will eventually be a user-friendly way to explore and use decentralized apps, so-called Dapps. Once you run the wallet app, it will sync with the network. While experimenting, you probably want to switch to the test network. I'm also going to turn on mining so I can have some Ether to play with. It took me about 10 hours to get ten test Ether. When you create an account, you pick a strong password. And in the background, it also generates a keystore file. The password and keystore file are all you need to back up an account. We'll start by simply sending some Ether. I type in another account I made in the To address and enter an amount in Ether. At the bottom, you'll see a slider that goes from cheaper to faster. This is what sets the fee you'll pay to miners. When I click send, you see a summary page with some more details on those fees. Whether you're just sending Ether or sending a message to a contract to execute some code, every operation has a cost in gas that varies based on how many resources are needed. Multiplication might require 1 gas whereas verifying a digital signature might require 10. The wallet automatically estimates the gas required and provides a default gas price in Ether. When you adjust that slider, it's changing this gas Ether exchange rate. Miners will generally execute the transactions that have the highest gas fee first. Since contracts can have unpredictable code-like loops, it's not always possible to estimate how much gas you'll need. The max fee lets you specify the maximum amount of gas to use. If you run out of gas, the contract will revert its state back to where it started, but your gas will be gone. Like preparing a car trip, you probably want to provide a buffer of gas rather than try to predict the exact amount. Any excess doesn't get used. You can see the transaction getting confirmed in the main wallet page, which takes about a minute. You can click on it to see the actual gas used. Now let's create an example application or contract. We'll be making a token which can be a currency like Bitcoin or perhaps shares in a company or even objects in a game. I'm mostly following along with one of the main tutorials on Ethereum's site where you can also find the full source code. We first go to the Contract tab and create a new contract. I paste my code into the source code area. We can see some of the constructor variables if I pick my contract on the right. They're declared in a constructor function with the same name as my contract, and this runs on the initial deploy of my contract. That function gives my account all the money when it starts up. I'll fill out some initial values like 10,000 tokens, a name, and an abbreviation, SC. This line mapping provides the basic ledger functionality. BalanceOf is basically an array that lets you look up and set account balances. Under the transfer function, we see the logic that makes sure a sender's account has enough tokens before sending the requested amount. Let's deploy this contract. Again, we set a fee for the miners. I go back to the Contracts page to interact with my contract. The only function is Transfer. I'll select it and type in another account I own. I choose my main account as the From account. Note that the account management comes free of charge in Ethereum contracts. I didn't have to write any special code for this. Also note that I can send Ether to this contract. Just like other accounts, contracts can hold an Ether balance. My token doesn't do anything with Ether, so I leave this at 0. I can also read from my contract under the Read From Contract section. To see the balance of any accounts, I simply paste in an account into the Balance of field. To share this contract with someone else to use, I need to send the contract address and a JSON ABI, or application binary interface, that tells the wallet how to interact with the contract. Interestingly, the Ethereum wallet has special support for tokens. When I go to send money, I can select my token instead of Ether if I like. Finally, I'll demonstrate using someone else's Dapp called matching Ethers. I go to the Watch Contract section and copy in the contract address. I also copy in the ABI, which I got from its web page. This contract basically lets me bet on a coin flip. I bet flipped or not and send some Ether. When enough other participants bet, I'll either win and get more Ether back or lose and get nothing. In the duration, my Ether is stored in the contract. You can view transactions and source code for other Dapps at an explorer like etherscan.io. And to check out many other great apps, there's a good listing at dapps.ethercasts.com. There are decentralized message boards, betting sites, prediction markets, flight insurance, name registries, voting systems, decentralized organizations, and much more in development. Ethereum is still very much being born and will be much more accessible when the Mist browser is released and provides web page-like interaction with Dapps. Despite all the great potential, one question is how much it will cost to run useful applications. Ethereum's trustlessness may be too expensive for some applications.


39. Augur & Decentralized Prediction Markets In this last section, we're going to take a very brief survey of several other non-currency applications, many of which leverage the Ethereum decentralized computer to run. One of the first applications building on Ethereum is Augur, a decentralized prediction market. Prediction markets capture the wisdom of the crowd to make predictions. At first glance, the mechanics of a prediction market may seem just like a betting site. People make bets on a future outcome, say the president of the United States, and are then awarded if their prediction was right. The market price is thought to be a good indicator of the actual likelihood of an outcome. It is thought that unlike a poll, betting with real money gives participants skin in the game or something to lose, thereby tamping down opinions of uninformed people. Prediction markets are certainly not new in academia or the commercial world and have been correctly predicting elections and other outcomes for decades. One amazing example involves a sunken submarine, the Scorpion, in 1968. Despite knowing the location to be in a 20-mile radius, the Navy had spent months searching without success. A scientist then suggested that a diverse group of experts bet on the location, and the average of those bets turned out to be within 200 meters of the actual location. Augur hopes to provide a decentralized prediction market hopefully avoiding the fate of other companies that came before it. InTrade offered an online system for people to bet on outcomes but was eventually barred from the US due to regulatory pressure reminiscent of Eagle. Augur is making a system that runs entirely on Ethereum smart contracts avoiding any central system that can be shut down. One key ingredient to Augur working is that the smart contracts correctly learn the real outcome of events in order to pay the winners. These inputs are provided by so-called oracles and are critical components to many systems beyond just prediction markets. The stable coins we discussed previously also must be fed the real exchange rate from a reliable source. But how do you know a given oracle is reliable and wouldn't try to report falsely to win a bet? Augur collects results from many different sources and ignores and punishes those who vary too far from the median. Consider if you asked a group of people what the weather was yesterday, and a subset wanted to lie about it. It's unlikely the liars would all come up with a similar false report. Augur uses this tendency for lies to vary to help determine the truth. Prediction markets offer a promising way to extract information from the most informed within a population. They don't always work however. For small questions, there may not be enough participants that know enough, which is why InTrade mostly focused on sports and politics. Interestingly, prediction markets are already being used to make corporate decisions, but their use isn't always long-lived especially if the disagree with the answers management wants.


40. IoT & DAOs (Decentralized Autonomous Organizations) Another company building on top of Ethereum that's received a lot of recent media is called Slock.it. The company comes from the world of Internet of Things and plans to offer smart locks that are controlled by smart contracts. They hope to offer a decentralized version of AirBnB where anyone can rent cars or apartment trustlessly without any middleman. Now one question you may be asking is, What is somebody uses a crowbar to break into a door? It doesn't really matter what a smart contract thinks about permissions if someone uses physical force to bypass it. First, this is not much different than a regular crime. The SmartLocks are no better than a regular lock. The main advantage of a SmartLock is automation. There's no meeting to exchange keys and, importantly, any insurance or deposit arrangements are automatic. When someone wants to rent an apartment, they must post a deposit to a smart contract before the lock can be opened. The Slock.it company is fascinating because they are developing much more than SmartLocks. A $100 Ethereum computer is in development that will allow easy browsing and use of Dapps and control over any IoT device with Wi-Fi, ZigBee, or Bluetooth. Slock.it has also recently launched a massive DAO or decentralized autonomous organization. A DAO is a company or organization that exists only in the code of a smart contract, with shareholders voting to decide where to allocate funds in order to earn a return on investment. It is hoped that such an organization will be more incorruptible and transparent than a traditional legal company. It is also hoped that the wisdom of the crowds will help guide the organization through effective choices, although it is an open question whether such a democracy will be more successful than the super star CEOs behind many other successful companies. More information about the DAO created by Slock.it can be found at daohub.org. Note that the DAO is not at all owned by Slock.it, although I believe Slock.it hopes it will become a vendor or contractor in some of the DAO's first investments.


41. Decentralized Storage with Storj & IPFS At this point, we've discussed decentralized systems that exchange digital currency, the Ethereum decentralized computer for trustless computation, but have yet to discuss another vital pillar of the digital world--storage. I'll start with a company appropriately called Storj that offers what is frequently described as decentralized peer-to-peer Dropbox. Like Slock.it, Storj is in the new sharing economy world where users can offer hard drive space up for rent, and others can pay to have their files stored. Storj breaks files into shards or pieces, encrypts the pieces, and then stores those pieces on different computers across the network. Clients or the people that are backing up data issue cryptographic challenges to farmers, the users that provide the storage, to ensure the data is valid and available. Clients provide micropayments via a native currency for space and can even choose things like the amount of redundancy. For example, you may want to have only three farmers backing up most of your files, but for very important ones, you could pay to have 100 different computers redundantly backing up everything. Storj hopes its platform will be cheaper, more secure, and more available than commercial cloud storage options now available. To bolster the cheaper claim, Storj compared an estimate of free hard drive space in the world around 2013, 250,000 PB, to the storage at Amazon's S3 service, 900,000 PB. And in terms of availability, because farmers are paid to host files, Storj hopefully won't suffer the unavailability on the BitTorrent protocol where only popular files survive. And as an side note, there are other projects attempting similar products including Ethereum's Swarm, Maidsafe, and FileCoin, a part of IPFS, which is where we'll go now. Moving beyond the raw storage of bytes, IPFS, or InterPlanetary File System, attempts to improve the way we access files. It is a distributed peer-to-peer file system that hopes to replace the existing way we link to files on the web through URLs. The key difference and innovation of IPFS over our existing internet addressing is that addresses are based on the content rather than the location. This subtle difference referencing content over location brings with it a wide range of potential benefits. For one, you're linking to a specific version of the content and don't have to worry about the content changing and saying something you disagree with later. The versioning capability of IPFS is very much based on the Git versioning system. Versioning also means you don't necessarily have to store complete copies of a file every time it changes. You might just be able to store the changes. And more importantly than storage, you might not have to download an entire file but just the changes. The IPFS web page sites data showing that the cost of hard drive space is going down much faster than bandwidth. So to take advantage of all the data in the world, that data actually needs to be closer to us. Consider when everyone watches a popular video, which requires many trips from end users to a central server. If the same content is already on a local network, that data would not have to travel nearly as far for other people nearby to access it. This also means offline working is possible. CDNs or content delivery networks and caching help with this a bit but not completely. Encryption makes this harder because you can't see what content to cache. The web has become very centralized due to most applications' server-client nature. But IPFS hopes to redistribute the web's operation. It also hopes to enhance privacy and reduce censorship by allowing files to live anywhere and not just on controlled servers. Having files stored anywhere also may prevent data from disappearing as so often happens when web servers and companies disappear.


42. Identify & Reputation with Identify & Onename I'd like to end on a topic that was the motivation for the very first altcoin or fork of Bitcoin--identity and reputation. Namecoin was the first altcoin after Bitcoin and provided a key value registry based on Bitcoin's blockchain technology. With Namecoin, you can register an IP address to a human-friendly name like scottsite.bit. You could also, for example, link a public key to your name so that anything you sign with that key is cryptographically linked to your name. Registrations cost a small fee and need to be renewed regularly to prevent costless spam registrations. Right now identity is a very centralized service whether in the real world or on the web. You have governments controlling identity in the real world. And online, Google and Facebook manage many of our logins. Centralized DNS registries control the connections between website names and servers. Beyond ownership, there are also issues with privacy. For instance, to use a banking service, you might have to prove your age or identity by sending a scan of your government Id, or perhaps supply your social security number. But then the people at that bank now have a copy of your license, which makes you more susceptible to identity theft. I'll mention two companies that are building on the basic start of Namecoin. Onename provides a registry service built on top of Bitcoin through a metacoin protocol. Names and hashes are stored in an OP_RETURN code in Bitcoin transactions using special prefixes inside the OP_RETURN data. The hash is a collection of whatever data the user would like to attach to a particular name and could include things like a website, Twitter, or GitHub account. Anyone running the Onename software can hash the data and check to see if that hash matches the identity on the Bitcoin blockchain. Their vision goes much further, however, and will eventually include the ability to store private data selectively sharing it as needed. For instance, you might want to only share the fact that you're over 18 with someone rather than a picture of your whole license. They also discuss the ability for different organizations to digitally sign these slices of information. For example, you could provide a government signature that you're 21 or an employer's signature attesting that you really work at a particular company. The flexibility in identity becomes very useful when you want to manage different reputations for different groups of people. For instance, you may not want to mix your gaming profile with your LinkedIn profile. Another company, Identifi, hopes to aid this sharing of reputation through a web of trust. It's not built on the Bitcoin blockchain at all. Rather, people create messages about others that attest they know the other person or ratings for people or companies. For instance, you could rate a doctor 9 out of 10. In this way, you could collect ratings about companies from people you specifically include in your own web of trust and then also look to their web of trust for a second-degree opinion. Decentralized identity and reputation promise much improved privacy, control, and enable many other applications. For instance, a new decentralized marketplace called OpenBazaar utilizes a reputation system so that people can trust each other in trading physical goods. Reputation is also key to Augur's prediction market that we discussed before since trusted reports from the real world are needed to know the results of bets. Finally, voting becomes possible with reliable identity systems. Note that voting on a blockchain may remove fraud, but if votes can probably be linked to real people, they might be coerced or punished for voting a particular way. We've talked about a wide range of projects that extend beyond Bitcoin. We discussed many ideas to create a better currency including alternatives to proof-of-work like proof-of-stake, performance increases, enhancing privacy, and creating less volatile coins. We also looked at using blockchain technology in private groups where it aids in trustless interaction if not in censorship resistance. And outside of currencies, we talked about Ethereum, a decentralized computer that enables smart contracts and many other decentralized interactions like prediction markets and automated renting via smart devices. Finally, we discussed some examples of decentralized storage, identity, and reputation systems. Decentralization promises many improvements in all these areas including better privacy, censorship prevention, no third-party intervention or cost, and more robust systems that don't have a single point of failure. But these advantages come with cost. Centralized services are usually more efficient, and it's harder to organize large groups of people. Bitcoin requires a large amount of software development to keep improving, but there's no software funding built into the protocol and no agreed upon way to make changes. Decentralized organizations offer one potential way to better organize people and funds. Ultimately, the success of decentralized systems will depend on whether they deliver improved utility over alternatives and whether people even care about things like privacy. PGP, or pretty good privacy, encryption has been around for decades, yet few use it because it isn't user friendly. It will be fascinating to see what technologies and projects thrive in the world of decentralization. In closing, I want to thank the Epicenter Bitcoin Podcast for being an invaluable source of information and a special thanks to Jaime Ramos for review and input.