Hi, I'm Jeremy Clark. I'm an assistant professor at Concordia University in Montreal. Today's lecture is on the history of cryptocurrencies. We'll look at all the technologies that led up to the invention of Bitcoin. Now, understanding the history of cryptocurrencies isn't essential to understanding how Bitcoin works. Thus, it wasn't part of the original lecture series. However, enough people thought that it would be an interesting subject to look at that we decided to release this as a bonus lecture to the original series. In this lecture, we'll look at the history of electronic payment systems. These will include digital cash proposals and broader proposals that tie into the credit card network. We'll also look at the history of certain primitives that Bitcoin uses that aren't directly related to eCash. We'll look at proof-of-work protocols and we'll look at secure time stamping schemes. Finally, at the end of the lecture, we'll reflect a bit on what we can learn about Satoshi and what he understood from the history of cryptocurrencies in the design of Bitcoin. Spoiler alert, we won't tell you who Satoshi Nakamoto is. The path to Bitcoin is littered with many failed attempts at eCash systems and other credit card payment systems. Here's about a hundred schemes that are notable in some regard. Some of them are academic proposals that have been well cited. Others are actual systems that were deployed and tested. Of all the names on this list, there's probably only one that you recognize. That's PayPal. It's the only current system that we have from the history of cryptocurrencies that's still being used today. In this portion of the lecture, we'll look at traditional financial arrangements. We're not going to give you a full history of cash and the assent of money and all the things that went into the invention of cash, but we will look at some of the basics just to remind ourselves. They will help us understand the different types of proposals that we'll see. If we rewind in time and go back to a time before there was a government, before there was currency, one system that worked for acquiring goods was barter. In a barter arrangement, you may have two people. For example, here we have one person who wants to have a tool and we have another person that needs medicine. Now, if each of these has what the other person needs, then they can do a swap and they can both satisfy their needs. For example, this person can give medicine to the second person. The second person can give a tool in return. Now, the problem with barter is what happens when the two people don't have what the other wants? In this case, for example, we might assume that this person has food, which they're willing to trade for a tool which they want. The other person has a tool, but they don't have any need for food. They want medicine instead. This situation can be resolved with the introduction of new parties. For example, let's assume that there's a third person. This person wants food and they have medicine available that they're willing to trade for food. In this case, it's possible to arrange a three-way swap where everyone gets what they need. Now, the drawback of a barter-based system is a coordination. It's hard to coordinate all three people to have them at the same place, but also to situate them in time where everyone's needs and wants align in time so that they are able to complete this swap. In order to deal with this drawback of barter, one of two systems emerged to replace it. One system is credit, one system is cash. It's currently a subject of academic debate, which of the two emerged first. For the purposes of this lecture, we don't really care about that debate. In a credit-based system, we can assume that the first person, for example, who needs a tool, they're able to acquire the tool from another person. However, they don't have the medicine that this person wants. All they can offer is food. Since this person doesn't want food, the arrangement could be that they still make the trade. The first person gets the tool, but the second person gets a favor that's owed to them in the future. In other words, this person has a debt that they need to settle with this person in the future sometime. Now, we can say that this person's needs are satisfied. She acquired the tool that she wants, but really she has a new need as a result of this arrangement. She has a debt, and she would at some point like to cancel that debt in the future. So that's her new want. Now, at some future time, she may come across a third person, and in this case, the third person wants food, which she has. The third person is offering medicine, and if she remembers that medicine is what the person she has a debt with wanted to acquire, then she can trade her food for the medicine, and then when she has the medicine, she can go back to the original person and cancel the debt. As a result, everybody's happy. A second alternative we can look at is the cash-based systems. In this case, we'll assume the same scenario, except for in this case, we'll assume that this person also has some money, something of monetary value. In this case, when this person wants to acquire a tool from someone who's offering the tool, they can offer cash instead, since they don't want the food that they have. So in this case, they do the swap. This person satisfied. She has acquired her tool, and this person has acquired money, which is the value of that tool. Then later, if this person happens to come across this person, she still wants medicine. This person is offering medicine. She can swap it for the money. Finally, to complete the cycle, the original person has food. This person needs food and has money. They can pay for the food, and the money goes back to the original person who held the money in the first place, and everyone's needs are satisfied. Now we can contrast and compare cash systems versus credit systems. In a cash-based system, one requirement to bootstrap the system is you need an initial allocation of cash. The whole trading cycle would not have worked had the one person not originally had some cash on hand. By contrast, in a credit-based system, there's no allocation that's needed. It can work right out of the box. However, the credit-based system does have one drawback, and that is the party that gives the tool to the other party in exchange for a debt is taking on some risk. There's a chance that person never comes back and settles the debt. Cash also allows for a finer-grain precision when you want to say how much something is worth. In barter-based systems, it's hard to say if a tool is worth more than medicine or a medicine is worth more than food. With cash, we can apply a mathematical quantity to how much something is worth. For these reasons, this is why we use a blended system today. We use a combined system of cash and credit where debts are measured in the amount of cash it would take to settle the debt. A fairly direct application of these ideas can be seen in some proposals for peer-to-peer file sharing. Two systems that use these ideas are Mojo Nation and Karma. Mojo Nation was a short-lived project. It lived about two years, but it's sort of the intellectual ancestor of other protocols that are used today like BitTorrent and Taohau Lafs. Karma, on the other hand, was an academic proposal. In both of these cases, we consider a peer-to-peer file sharing system where some people have files, say movies or music that they're offering to send to other people in the network, and they'll do this in exchange for other files that they want to acquire. In this case, both of these systems suggested that users, when they enroll in the system, are allocated initially some amount of cash called Mojo or Karma in the systems, respectively. Then the users were able to spend this money to acquire the files that they want, so if you're downloading from someone else, then you're paying cash to that person. When someone comes to you and they get a file that you have that you're offering, they pay the cash back to you, and the idea is to try and keep your balance floating around the amount that you were initially allocated. This also solves the problem of arranging barter between users. If different users have disjoint sets of files that they want to share and files that they want to acquire, then by using currency, they don't have to find that perfect person who has exactly what they need and is looking for exactly what they're offering. In this portion of the lecture, we'll begin looking at the history of payment systems that were invented prior to Bitcoin. We're going to start by looking at credit-based systems. In general, what you can do is you can take all the systems and sort them into two piles. There's pile based on credit systems and there's piles based on cash systems. Bitcoin obviously is in the pile of cash systems. However, we should also look at credit-based systems, even though Bitcoin's not part of that pile, because these are the systems that are competing with Bitcoin. Credit card transactions are the dominant payment method that is used on the web today. If you've ever bought something from a website such as Amazon, you know how the arrangement goes. You type in your credit card details, you send it to Amazon, and then Amazon turns around with these credit card details and they talk to the system, the financial system. We don't have to go into all the details of who the parties are that are involved in the financial system. But in general, there's a credit card processor and the credit card processor is going to talk to the banks, the credit card companies, and other intermediaries. The other architecture that you may see if you use something like PayPal is an intermediary architecture. In this case, there's a company that sits between you and the website. So you send your credit card details to this company. It approves the transaction and settles with the website. The advantages of this type of architecture are privacy. In this case, the user is never fully disclosing all their credit card details to the website. The drawback is that the user is no longer directly interacting with the website alone. The user has to interact with this intermediary. They have to be aware that the intermediary exists. They may have to have an account with the intermediary. Now, an early system to use this type of architecture was a company called First Virtual. It was founded in 1994. First Virtual is an interesting company because beyond just being one of the earliest players in doing electronic payments, they were also one of the earliest companies to try and set up a virtual office, as it was called. And that's why they called their company First Virtual. So in a virtual office, there was no physical office where people met. People were scattered across the country and they communicated through email on the internet. Now, remember, in 1994, this was before the days of GitHub and Skype and Slack. And so it was very hard to run a business this way. And they have an interesting paper outlining some of the challenges of that business model. But anyways, back to what they actually propose. What they propose is a system where both the user and the merchant sign up with First Virtual. They have an account and then they conduct transactions of electronic payments over email. The idea is that once you put something in your cart and you say, I'd like to check out, what the merchant will do is they'll send an email to transfer at card.com, which is an email address run by First Virtual, and it will have all the details of the transaction. The user is then sent an email with the transaction details asking them to approve it. If the user emails back, yes, then First Virtual will build the credit card of the user, a credit card that the user had provided when they enrolled in the service. Then what will happen is First Virtual will wait to see if the user will dispute the credit card change. The user typically has 90 days to file a dispute. And so First Virtual will ride out these 90 days, and it's only on the 91st day that the merchant actually gets paid the money. This is a major drawback of the system, having to wait that long to receive payment if you're a merchant. However, amazingly, it's not that much different than what happens today. Today the merchant does get paid immediately. However, there still is the threat that the customer will file a chargeback or dispute the credit card statement. And in this case, the merchant will have to pay the money back to the credit card company. Two other systems to use this architecture are OpenMarket and NetBill. And when you look at these early protocols, what's interesting is to drill down and see at a protocol level what protocols they're using to send transactions back and forth. First Virtual, as mentioned, was based on email. There were other competing approaches. In OpenMarket, it was based on encoding information into the URL. For NetBill, they use a custom MIME type over HTTP. In the mid 90s, there was also a competing approach to the first Virtual intermediary based architecture. We'll call it the set architecture. Like the intermediary architecture, it also tries to address the problem of users not sending all of their credit card information to the merchants. It's actually remarkable that no one thought that was a good idea in the 90s. It wasn't until much later that that system became predominant. In this system, it also tried to address the idea of the user having to enroll with the intermediary. So what they decided to pursue is an architecture where the user, once they've settled on the transaction that they want to conduct with the website, they only interact with the website. However, what they do is they take their view of what the transaction details are and they encode their credit card information and they encrypt it such that some server, some third party can decrypt it, but the merchant cannot decrypt it. They send it to the merchant and the merchant takes this information. Since it can't decrypt it, all it can do is blindly forward it onto the third party. However, they also append their own view of what the transaction looks like. Then the third party can decrypt both of these. They can compare the views of the transactions and if they align, they both say the same thing, then they'll approve the transaction. Now SET was a standard that was developed by Visa and MasterCard in conjunction with a lot of technology companies at the time, Netscape, Microsoft, Verisign, RSA. SET was sort of had some intellectual ancestors. There was another company at the time called Cybercash. IBM had a proposal called IKP that was later standardized into a standard called SET and Microsoft working with Visa had also developed their own standard. All of these use that same architecture that we just described and so the idea of SET was to unify this architecture, provide a specification where all of these systems would fit under the umbrella of SET. Now Cybercash, the one company that went into SET is an interesting company that we'll spend a few minutes looking at. Cybercash had very good relationships with the US government. In addition to their product that was based on credit cards, they also had a coin based system, a digital cash based system called Cybercoin. Cybercoin was a micro payment system so what that meant is that you probably never had more than $10 in your account at any one given time. However, what Cybercash was able to do is they were able to actually get FDIC insurance for each account for up to $100,000. Back in the 90s when Cybercash was operating there was also a restriction on the export of cryptography. Cryptography was considered a weapon and so you couldn't export it to other nations. In this case Cybercash wanted to export their software, they wanted other people around the world to be able to use it, however it used encryption technology so normally this export would not be allowed. However, what Cybercash was able to do is work with the state of department to get a special exemption for their software and the argument was that going into their software and extracting the encryption technology out of it would be way more work than it would take to just write the crypto from scratch. Also leading into the year 2000 there was a lot of concern over a bug called the Y2K bug. The Y2K bug didn't turn out to be that big of a deal, there weren't a lot of systems that were influenced or affected by the bug. However, Cybercash has the dubious distinction of being one that was affected by it and their payment processor software exhibited double payments as a result of this bug. They later went bankrupt in 2001, their intellectual property was acquired by Verisign who then turned around and sold it to PayPal where it lives today. So let's think about why the set architecture didn't work. The big problem, probably the fundamental problem of the set architecture has to do with a subject of distributing public keys to all the people that need public keys in the protocol. This is called PKI or public key infrastructure and a nice way of thinking about this was actually developed by IKP, the IBM project that was one of the predecessors to set. What IKP did is they came up with three levels of security. In the most basic security only the processor had to have a public key. Now they had to have more than a public key, this public key had to be bound to their identity in something called a certificate. So we can think of these as certificates. On the second level of security all the merchants also had to acquire certificates and in the third level of security the highest level of security not only did the processor and all the merchants have to have certificates but they suggested that all users also have to go and acquire a certificate. Now these certificates are used so that everybody in the protocol has signing keys and essentially what happens is every time you do a transaction everybody signs everything they do and if there's disputes later then there's a record of who said what about the transaction. So it's used to keep everybody accountable in the protocol. Cyber cash always required level three and when the standardization of set came along they decided that level three was the best level. This is a level where as I mentioned all users had to go and acquire certificates. Now this was a disaster so users don't want to go and acquire certificates it's complicated you have to deal with a certificate authority. In these days it wasn't an automated process you would have to send enough information about who you are so that you could be granted the certificates and so that's a big reason why the set architecture failed. Some other points of interest about set it was as I mentioned set is not a system itself it's an attempt at standardization it was done in 1996. Around the same time another group the World Wide Web Consortium were also looking at standardizing financial payments. They took a different approach they thought it would be interesting to extend HTTP the protocol in sort of arbitrary ways and they had a very general proposal for how you might extend it and one of the use cases that they had was doing payments. This never happened essentially this was never actually deployed the whole extension framework was never deployed and so this was another standardization attempt that failed. At the time that we're recording this lecture in 2015 the W3C has already has recently came out and said that they would like to do another attempt at standardizing financial systems and in this case Bitcoin will be part of that standardization. However given the past failures they have a tough hill to climb. In the past portion of this lecture we looked at credit based systems. We'll now turn our attention to cash based systems. Cash based systems offer two advantages over credit based systems. The first is they provide better anonymity when you use a credit card based system the bank always knows what you're doing because the credit card is issued in your name. When you pay for something in cash nobody necessarily knows who you are when you purchase something. The other thing that cash can enable is offline transactions where you don't have to phone home to a third party in order to get the transaction approved. You can give someone cash and the transaction is done and everyone satisfied. Maybe later they go to a third party like a bank to deposit the cash but that third party doesn't need to be present in the transaction itself. Now these two requirements are sort of a more extreme version of what Bitcoin offers. In Bitcoin it doesn't offer the same anonymity level as cash. In Bitcoin it offers pseudonymity which means that some of your transactions could be tied together if you use the same Bitcoin addresses to originate transactions. Bitcoin also doesn't work in a fully offline way. It's true what you could do is you could create a Bitcoin transaction you could sign it you could hand it to someone maybe email it to them but that person won't be content that that money won't be double spent until they see that it's incorporated in the blockchain. So unless if you are online and able to broadcast that to the peer-to-peer network or alternatively you really trust the person that you're receiving the money from Bitcoin operates in essentially an online fashion. The earliest ideas of applying cryptography to cash came from David Chom in 1983. To think about David Chom's proposal let's start with a sort of predecessor to his actual proposal.  In any case I want you to sign this paper saying that you will honor that arrangement and then I'll take that paper with me and I'll give it to someone else. If I give it to someone else then that paper is effectively worth a hundred dollars. Now you might be thinking what's the big deal all you did is convert one small piece of paper worth a hundred dollars the bill into a big piece of paper worth a hundred dollars which is the contract but of course this is a physical analogy of what you can do in a digital realm. We are able to do digital signatures and so this contract could be a digital object. As long as people trust that the person who issued the contract is willing to honor the contract then the system works and effectively this digital contract is worth a hundred dollars. Now there is one problem however the problem is once it's a digital contract it's very easy to copy and paste those bits so now you have two contracts. If each contract's worth a hundred dollars you just doubled your money to two hundred dollars. If you send those two contracts to two different people this is called the double spending problem and double spending is a problem that exists in all e-cash systems. All e-cash systems have to have some way of dealing with double spending problem including bitcoin. So the first attempt at fixing the double spending problem is to encode a unique serial number in each contract. This is actually isn't sufficient to completely solve the problem but it's a step in the right direction. Now the problem with the serial number is that remember one of the advantages of cash is that it's anonymous but now if you have unique serial numbers the bank knows who it issued this contract to and they can write down their name and they can write down the serial number that the contract encoded and then they can trace this person as they spend the money. So David Chom came up with the digital equivalent of something called a blind signature and I'll explain it more in paper based form. To understand a blind signature you could imagine that we take this contract but in this case instead of it being printed in normal ink we print it in invisible ink. So the bank we take it to the bank and we say will you sign this contract and they can't actually read what is written because it's an invisible ink. So the ink is providing two properties. The first is the obvious property is that it hides the information that's in the contract but the second property which is equally important is that whatever I printed on that contract in invisible ink I can't change it it's locked in it's fixed and so if the bank decided to expose it to see what actually was written there then there's no way to change it okay so this is called the binding property. So this solution obviously solves the problem of the bank seeing your serial number the bank doesn't see your serial number however it creates an even bigger problem which is the bank doesn't see anything about the contract at all it has no idea that it encodes the fact that it owes someone a hundred dollars the contract might encode the fact that it owes someone a million dollars. So the bank wants to be convinced that this contract is formed correctly that the amounts are correct but the paradox is it can't see the serial number. Now one solution to this might be that only the serial number is printed in invisible ink and the rest of the contract is printed in regular ink so everyone so the bank is content they can see what the amount is and the user's contents because they maintain their privacy. The problem with this is at a cryptographic level when we transition into digital signatures we didn't at least in the early 80s we didn't know how to do this. Blind signatures back then were all or nothing either you hid everything that was being signed or you hid none of it and so we needed a different solution. So the question is how can I convince you to sign something if you can't read it and the answer is we can use what's called a cut and choose protocol. In this protocol what I would do is I would create a hundred contracts and hand them to you in a stack. What you would do is you would pick one at random from the stack and you would reveal the invisible ink and when you reveal it you can check that at least for that contract yes it did encode the fact that you owed a hundred dollars as opposed to a million dollars. Then you can pick a second contract out of the pile you can reveal it and make sure it also says a hundred dollars. You can keep doing it until there's one contract left okay when you have this one contract and you're holding it even though you don't reveal the invisible ink because the other 99 all said a hundred dollars and you chose them randomly you're pretty sure that this one also encodes a hundred dollars and so you sign it convinced at least to a 99 probability that it actually says a hundred dollars. So how does this help with the double spending problem? Well the cut and choose protocol allows the bank to sign a contract be convinced that it encodes the right amount and yet not be able to see someone's serial number. So the idea is that you would get granted one of these contracts when you wanted to do a transaction you would give this contract to the person that you're the merchant that you're buying the goods from and then the merchant would turn around and give it back to the bank right away. So in Charm's earliest system this was an online transaction system where you had to phone home to the bank every time you received one of these contracts and we can stop calling them contracts we can call them coins because that's another term for what they actually are and so when you spend a coin the merchant goes to the bank and they give it to the bank and they ask the bank have you seen this coin before has it been has it come in before has this serial number been spent before and if the bank says no it hasn't been spent before then they honor the coin the contract component of the coin and they give the merchant the money that's owed. If the merchant goes to the bank and it has been double spent then they can at least detect it. Now the problem is that if it is double spent there's no you have no idea who the buyer is because it's an anonymous system so that's a drawback that people were worked on later to address. Another drawback of this system is that once you spend a coin you can't use it again so it's not like an actual cash system where you mint coins you hand it to the first person they send it to a second person and then the second person can give it to a third and a fourth and you can have a whole bunch of chain you have a whole chain of transactions. In these type of system every time you receive a transaction you have to go back to the bank and essentially cash it in. Now the bank might issue a fresh coin that's fine but the point is that these coins are only living for one transaction at a time. Now one proposal at fixing the problem that the bank has to be online at all times came in 1988 from Chom along with Fiat and Deore. What they observed is that if you want to prevent somebody from double spending a digital object it's really hard it might be impossible there's no way to stop people from copying and pasting digital digital strings. However they also noted that in traditional finance we have this idea of checks and the same problem arises if I write you a check you have no guarantee that the money is actually in my account. Maybe the money is in my account I write you a check for a hundred dollars I have a hundred dollars in my account but there's nothing stopping me from writing a second check to someone else for a hundred dollars in which case if both of you try and cash it then one of you won't be able to cash it. So in order to stop bad checks from circulating what the bank system uses is a detection system as opposed to a prevention system. They don't try and stop you from writing that second check but what they do is when you write that second check they are able to detect that it exists they know who you are because you have a bank account with the bank and they'll punish you through a penalty for doing that. And so the idea of Chom Fiat and Deore is is there some way to do that type of system in the digital realm. So if we go back to the idea that coins encode a unique serial number we can think about what the serial number looks like. If the serial number if the bank maintains a mapping between customer names and serial numbers then there's no anonymity in the system. Every time a coin comes back to the bank they know who it was that spent it and since the coin is coming from a merchant they know where that user spent the money. In the original Chom 83 scheme the serial numbers were just random numbers okay there was no link between the serial number and the bank in fact the bank couldn't even link them because of the blind signature it hid the serial numbers in the coin so the bank didn't even see the serial numbers. In this case it offers full anonymity. Now the question is is there something in the middle between having no anonymity and full anonymity where we can allow partial traceability of coins particularly in the case where they're double spent. So what Chom Fiat and Deore came up with is the idea that every coin would include two serial numbers. These serial numbers would be arranged so that when you add them together it actually forms the identity of the person who withdraw the cash. Now this is a more general description of what this technique is is secret sharing. So in a secret sharing scheme you have a secret and you split it up into n shares you give it to n people and you do it in such a way that if any m of the n where m is some number less than n as long as m people come together then they can reconstruct what the secret is. So you can think of this as a two out of two secret sharing scheme but any there's any possibility for n and m is also possible in the system. So the idea is you would still go to the bank as normal you give them a contract just like in the previous scheme the only difference is that there would be two serial numbers. Now the bank would do the cut and choose you would hand them a hundred coins and they would open up 99 of them and when they open the 99 they would check that those two numbers also add up to your actual identity. So they're certain that in the contract they sign the coin that they sign that those two numbers will also add up to your identity. So the idea is when I spend a coin I give it to the merchant and these serial numbers are still hidden the merchant has no idea what the two serial numbers are but what the merchant can do is they can ask me to reveal one or the other. You can think of it as the left serial number or the right serial number so they might flip a coin and ask me to reveal it. So what happens if I just spend the coin once which is what we want to encourage they only learn half of the secret so they're either learning a random number or a random number minus my identity which is also a random number that's fully masked and so it doesn't reveal any information about my identity. Now if I double spend if I send that same coin to a second merchant there one of two things can happen the second merchant will also go through the same protocol they'll last me to either reveal the left share or the right share assuming the first merchant asked for the left share and if the second merchant also asked for the left left share then what happens is my identity still isn't revealed. Now when both of those merchants cash in their coins the bank will detect that double spending occurred but they won't have any idea about who actually did it. However 50% of the time the second merchant will ask for a different share than the first so if the first asks for the left share the second might ask for the right share. In this case when they both cash in their coins at the bank the bank sees that it's double spending because they have different shares they can add those shares together now they know the identity of the person who did the double spending and they can leverage some fee or punishment against that person. Now 50% chance of catching double spending isn't that great and so is there any way that we can boost this? So the idea that Charmfiat and Neor had is instead of encoding one pair of numbers what if we encode say 10? So for example let's assume that they have a table and here's my real name and they assign a serial number to my name 31337 and so here's a list of 10 numbers 10 pairs of numbers and if you do the mental arithmetic you'll see that in each case they add up to this number. So what happens is when I spend a coin these numbers are originally hidden and the merchant gets to go through the list and they get to pick from each pair whether they want to see the left number or the right pair but they do this for all 10 instead of just one single pair so for example the merchant might ask for the left the left the right the left and so on. Now when I go to a second merchant we do the same protocol they're initially hidden but the second merchant gets that also for each pair asked for either the left or the right and what will happen with overwhelming probability is that at some point going through these pairs the two merchants will ask for different shares. So for example in the second row and also in a lot of other rows in this example if they ask for the left share and the right share and in that case you can add together those two shares and reveal the identity of the person who spent the money and so this works to boost the probability from one half to actually any number that you want if you have n rows or n pairs then the probability of getting caught is 1 minus 2 to the minus n and so it goes up to for example 99.999% if you use 20 pairs. Now this doesn't solve the problem of being able to spend a coin more than once. Once you spend your coin the merchant still has to go back to the bank and they have to cash that coin in and you can think about why why can't the merchant accept a transaction and then take that coin and turn around and spend it. Well the answer is that that coin encodes the identity of the original spender okay so if the merchant were able to respend that coin then let's say they double spent it then it would be the original person who has issued the coin whose identity is encoded in that coin. Now you might also think is there some attack here where I receive a coin and then I turn around and try and double spend it to falsely blame the person who gave it to me but because I don't know what the other numbers are that are hidden I only know the the one path of opening up the pairs that's all I can do if I turn around and try and spend it myself I can only open up the same pairs. Now there's a couple ways we can improve this protocol one thing is the efficiency is really bad if we think about the idea of using 20 pairs of serial numbers in that case we have 40 serial numbers okay 20 pairs but remember when you go to the bank initially you hand them say a hundred coins and they're going to open 99. Now in that case they have a 1% chance you have a 1% chance of deceiving the bank and that's probably too high you probably want it a lot smaller than that so you're more likely to go to the bank with a thousand coins or 10,000 coins and they're going to open all of them but one and so if you think about serial numbers 40 serial numbers on each coin and then you're handing a thousand coins you're handing over 4,000 serial numbers to the bank so this is a large digital object that you're giving to the bank to audit so what happened over the ensuing years is that a bunch of cryptographers look at this problem and sort of in parallel to this e-cash systems being developed there was some advancements in an area called zero knowledge proofs which we're talking about in the earlier lecture in this series when you talked about zero coin in this case they slowly replace all these cut and choose with more compact zero knowledge proofs so it's very easy you just go to the bank you hand them one contract and then you prove in zero knowledge for example that encodes a hundred and then you're done you don't have to give them a hundred coins you just give them one and the proof is very succinct and it's short. Another area of research was the idea of adding divisibility to the coins so in Chom's original scheme in Chom Fiat and Nayor if you got issued a coin that was worth a hundred dollars and you went and bought you wanted to buy something that was say only seventy five dollars there was no way to split that coin into seventy five and twenty five all you could do is go back to the bank cash in that hundred dollars and ask for a seventy five dollar coin and a twenty five dollar coin so Okamoto and Ota they had some interesting ideas it used merkle trees which show up in bitcoin to create a system that was divisible where you could actually subdivide the coins that you were issued without involving the bank in the process. Now Chom took his ideas and he commercialized them he formed a company in 1989 called Digit Cash and this was probably the earliest company that dealt with online transactions or tried to solve the problem of online transactions they had about a five-year head start on other companies like First Virtual and Cyber Cash that we talked about in the earlier lectures they the actual cash in their system was called eCash and they had another system called Cyber Box and there were a couple banks that actually implemented them there were a few in the US there was at least one in Finland in this case in the eCash systems because it uses Chom's protocols clients are anonymous so the bank can't trace the money when the money comes back the coin comes back it has a serial number and the bank doesn't know which users serial number that was issued to however the merchants aren't the merchants because they have to return coins as soon as they they receive them the bank knows all all the information about the merchants how much money is coming in at what time etc this is what the screenshot looked of like from the software and so you can see here there's a wallet and it shows you your balance and then here's all the coins that you have that have been issued to you from the bank and because you can't split coins because there's no way to split them up what the bank does is they issue you a whole set of coins in different denominations so for example you might get eight pennies eight two cent coins eight four cent coins etc etc so that you can always sort of reconstruct the right amount of change to pay for the exact amount of a transaction when you filled out a transaction what would happen is you would browse to a website so for example this is to make a donation to epic and if you wanted to donate the money you would click the link on the website and what it would do is it would open a server connection back to your computer and so your computer had to have the full ability to be online and accept incoming server connections it had to be running HTTP and have a port open to receive it you had to have a full IP address and if it was successful the connection was successful then your wallet service would launch on your computer and then you were able to approve the transaction and send the money now there were certain variants to digit cash that were were pursued one thing that was sort of controversial about digit cash is that the technology was patented in specifically the blind signature scheme that was used had a patent filed on it and so that stopped other people from developing e-cash systems that used the same protocol there were a bunch of cryptographers that hung out on a mailing list called the cypherpunks mailing list this later transitioned into the cryptography mailing list and you'll know the cryptography mailing list as the place where satoshi originally posted the white paper and introduced bitcoin so but before it made that transition the cypherpunks they implemented a version of e-cash of david's e-cash that was called magic money and magic money was only for experimental use so it did violate the patents but because it was non-commercial you could use it to experiment with and it was sort of a fun piece of software to play with the interface was all text-based you could send transactions by email you would just copy and paste literally into email hopefully you'd use a pgp key to protect the transaction in transit and you could email it to another user the other user would import it into a file on their computer which was called allcoins.dat which sounds a little bit like wallet.dat which is what bitcoin uses to store its coins another proposal by ben lorry with contributions from lots of other people is called lucra and in this scheme what they did is they targeted the blind signature scheme and they tried to come up with an alternative which wouldn't be covered by the patent and then you can keep the rest of the system largely the same another problem that's interesting that arises when you use digicash is as we mentioned you can't make change and so if you need to make change you have to go back to the bank and you have to get the bank to reissue the right set of coins so that you can make exact change for something ian goldberg had the idea that maybe the merchant could send you coins back if they had some coins so that you might overpay for the item but then you would get some coins back however this introduces a problem with anonymity remember in ecash the senders are anonymous however the merchants are and when the merchant sends cash back technically they're the sender so they're anonymous and you as the person who has to turn this cash into the bank are not anonymous and so there's no way to do that system without breaking the anonymity of the original user trying to buy the goods and so he had a different proposal where there were different types of coins that would allow these transactions to occur allow you to get changed back and preserve the anonymity of the user now why did digicash fail the main problem with digicash is it was hard to persuade you know the banks and the merchants to adopt it people didn't want to use it and because no merchants are not allowed merchants were using it to accept money then users didn't want to use it either it also didn't support user user user transactions at least it didn't support them very well it was really centered on the user to merchant transaction and so if merchants weren't on board with the system then there was no way to really bootstrap interest in the system as a note a side note bitcoin because it allows both user to merchant and user to user transaction bitcoin probably part of its success could be attributed to the fact that it supported user to user transactions so there was something to do with your bitcoin at least send it to other users well the community tried to drum up support for bitcoin and get merchants to accept it so at the end of the day digicash lost in the credit card companies won in the later years of the company digicash also experimented with tamper proof hardware or tamper resistant hardware in this case they had devices they might be a small device that was usually called a wallet or it might be some sort of card and what they were trying to solve is this double spending problem and in this case they weren't trying to just merely detect the existence of double spending they were trying to actually prevent it so in this hardware there might be a counter that encodes your balance and every time you spend money the counter decreases if you load the card with more money then the counter goes up but the point is there's no way to physically or digitally go in and tamper with that counter so if that counter goes to zero then that card stops being able to spend money now there were a bunch of companies that looked at this tamper resistant hardware in addition to digicash digicash worked later with a company called cafe which was based in europe there was also another company formed called mondax that was later acquired by mastercard and visa had their own variant called visa cash so this is the mondax system mondax consisted of a card this is a smart card with a chip and there were also these wallet units and you could load either of them with cash so you can get the cards and they would have some amount of cash on them and you can have wallets that would also have cash on them and if you wanted to do a user to user swap of money what would happen is the first user would put their card into the wallet you could move money off of the the card onto the wallet then you'd stick the second card in the wallet and you move the money off the wallet onto the second card and so you could exchange cash in that way and it was anonymous now mondax actually trialed their technology in a bunch of communities one community is actually a city very close to where i grew up in gualf, ontario and needless to say because it doesn't exist today this technology you know what the the end of the story is which is it didn't really catch on and the main problem with it is that cards mondax cards they're like cash if you lose them or they get stolen the money's gone and if there was some sort of malfunction with the card if the card reader wouldn't read it there's no way to determine whether that card had balance on it or not and so mondax typically what they would do in these scenarios is they would incur the cost they would assume that that the card was loaded and then they would uh re enumerate the user for that that lost money but that cost the company a lot of money the wallet itself was also it was sort of a larger foreign factor it was slow in order to process it was much faster to pay with credit card or with cash and retailers hated having a bunch of these terminals they just wanted to have one terminal for your visa card and they didn't want to have two different terminals so for all of these reasons the mondax experiment was not successful however what was successful is if you remember these cards we have these small chips on them and so this is a smart card technology today in a lot of countries including canada where i live every single credit card and every single debit card now has this technology on it they all are based on uh smart cards it's used for a different purpose it's not used to prevent double spending it's used for authentication so you prove that you know the pin that's associated with your account but this technology was adopted and mondax was using it long before uh the wider banking industry made it a standard for bank issued cards in this portion of the lecture we'll look at where e-cash gets its value from we didn't cover this in the previous portion when we talked about different e-cash systems and the reality is that there's a bunch of different proposals for how you do this and different companies do it differently in the very early portion of this lecture we looked at credit card based systems and so in this case it's obvious that the user's credit card is getting billed every time they conduct a transaction in the case of digit cash we have these digital cash objects and they might be worth a hundred dollars but what makes them actually worth a hundred dollars the answer is that in order to be issued digit cash that's worth a hundred dollars you would have to take a hundred dollars out of your bank account and give it to the bank that was issuing you the digit cash some other maybe more far-fetched ideas was what if the government actually authorized services to mint money they were actually authorized by the mint of a particular country in order to create new cash out of the thin air that was the idea behind net cash another proposal thought that what if we took a pile of gold and we put it in a vault and we only issued digital cash that was of the same value of the gold that was in the vault so e-gold used this there was another company called digit gold they weren't fully backed by gold but they at least had partial reserves for the amount of digital cash that they issued that was backed by gold so in a digital realm how do you create something that has value out of thin air especially when digital bits can be copied and pasted the idea is to create something that's scarce scarcity is one of the features of all not just cash but other things that have been used like gold or diamonds as substitutes for cash one way to achieve scarcity in cryptography is to look at the solutions to a moderately hard puzzle or the output of a moderately hard function so a moderately hard function is a function that takes some amount of time computational resources maybe memory in order to compute the output of in this case by moderate we mean like it might take you know for example in in bitcoin you know that the entire peer-to-peer network it takes them about 10 minutes to solve a block that's the idea of a moderately hard function it takes a significant amount of time but it's also not completely infeasible as would be the case if you were trying to recover someone's private key from their public key in the signature scheme that bitcoin uses so the idea of applying moderately hard puzzles to solving cash like systems cash like problems was first proposed by dwork and neor and they looked at email spam and so their idea was what if every time you spend an email you would have to compute the solution to some moderately hard puzzle for the average user it wouldn't be that much of a barrier to sending emails because you're not sending emails very frequently but if you're spamming you're trying to send out thousands or millions of emails all at once then that cost would become prohibitive once you multiply it by the thousand or a hundred or a million emails that you're trying to send this idea was later actually implemented and sort of independently discovered by adam back in a proposal called hash cash now proof of work or moderately hard puzzles they also can be used just to slow things down so if you have some function and you want to delay the amount of time that it takes think about the creation of blocks in the blockchain in bitcoin you can also apply it to this problem as well so hash cash as mentioned was proposed by back in 97 and it was the same idea which is that if you're an emailer or you can think of it as a more general at a general level if you are the consumer of some resource then in order to consume that resource or send an email you would have to generate the solution to one of these moderately hard puzzles or they're also known as proof of work protocols so the specific puzzle that hash cash uses which will look familiar to you having looked at bitcoin is what happens is you're given a hash function and you're given some string and we'll talk about what's in this string but the idea is you have a knots value and you can choose any value you want so the easiest thing would be to set it equal to zero like a counter and then step through and so what you would do is you would hash this string together with your chosen knots say zero and you would look at the output now the output will have will be random looking and just by chance it will have a certain number of leading zeros maybe it has none it you know the output happens to start with a one maybe you get two or three leading zeros and the idea is that you would change this knots value and you would keep competing this hash until you happen to find some knots value that satisfies an output where there's m leading zeros where m could be a number like 20 or 40 now what's inside the string that you're hashing that ties it back into the email system that we're trying to do so the first thing is there's some name that describes the service that you're going to use this hash cash to spend on and what this does is it just means that this cash can only be spent consuming that service okay so if you generate one coin you can't use it to both send email and you know download a file with it another thing is a validity period so hash cash has the problem of double spending like all e-cash systems and it solves it the same way as everyone else does which is the person that's receiving the hash cash they just keep a list of all the hash cash they've seen and they check it to see if someone spends it twice okay now this list would get really long over time and so if you put a validity period into the hash cash say that hash cash lasts three months then your list you can at least shorten it as soon as hash cash that you've seen that expired uh a month ago you can purge it from your list and you can end up with a shorter list another thing another alternative if you don't want to maintain a list is if you have an interactive protocol where the person that you're giving the hash cash to is online when you're ready to deliver or consume the resource then what that person can do is they can send you a challenge and if they send you a challenge you can incorporate it in your proof of work and now that proof of work or that hash cash is specific to that person that person gave you the challenge they know that it's not a double spend because they choose random challenges every time they ask for hash cash the final alternative is if you are not in the interactive setting if you're just generating hash cash yourself it could be the spammer still is able to send a million emails just by spending a really long time computing hash cash for all the emails that they want to spend and so one thing you can do is you can prove that your hash cash is fresh that it was freshly generated it wasn't generated before some period in the past and the way you can do this is with a beacon a beacon is just a fancy way of saying some source of unpredictable randomness so in the hash cash proposal they thought about lottery tickets you could use the lottery numbers of a certain day and if that was involved in the creation of this hash cash you know that the person started computing the hash cash after those lottery numbers were released you could also use stock market prices or you could use the cover of The Times of London because no one could predict what the story would be on a particular day at least not before say a day before that newspaper was published now you might recognize a beacon from bitcoin because in bitcoin what Satoshi did is in the very first block the Genesis block he incorporated a newspaper article that proved that he didn't start minting or sorry he didn't start working on the blockchain until after the date that that newspaper was published okay so this could prevent some sort of farfetched attack but maybe where he pre-computed a huge blockchain and then as other people came into the bitcoin network and started competing with him to solving blocks if someone else solved the block he could just drop two or three blocks because he had this long pre-computed chain okay so he proved that he didn't actually do this attack by incorporating a beacon into the Genesis block let's compare and contrast hash cash with bitcoin now the problem with hash cash is that the granularity of the proof of work or moderately hard puzzle is very coarse essentially all you can do is you can increase the number of zeros that are required at the output of the hash function or you can decrease them what this effectively does is double how hard the problem is or you can scale it back and have the problem as well so we know from bitcoin that the blockchain you want to solve blocks on average the whole network wants to solve them in about a 10-minute interval so let's say that for some reason the network got really fast and they started solving blocks on average in eight minutes instead of 10 minutes and so you want to make the problem a little more hard now if bitcoin used hash caches proof of work then they could only double it so it would go from eight minutes to 16 minutes and then that's way too long and so what we want is a finer grain precision where we can make it harder so that it something that's taking eight minutes can take exactly 10 minutes so satoshi observed that there's a way of thinking about the hash cash proposal for proof of work that's that's equivalent but looks at it slightly different if you think about an output that has a whole bunch of leading zeros well any number with a huge number of leading zeros is actually just a small number that's another way of thinking about it small numbers are numbers that have a lot of leading zeros and so what you can think of it as equivalently is you're hashy this thing until you get a number that's smaller than some upper bound okay and in hash cash because there's selecting bits that upper bound has to be a perfect power of two but there's no reason that it has to be a perfect power of two it could be any number that you want you can just pick a number and say keep hashing until it's less than this number and so with that tweak satoshi proposed that that number just be any integer it's called the target and the proof of work that bitcoin uses is very similar to hash cash but with this twist that you're trying to generate a number an output of your hash that's less than this particular number now another proposal for how to mint coins using proof of work comes from revests and chimera 97 these are the r and the s in the rsa crypto system respectively and they observe that with hash cash style minting what happens is when you solve say you create one coin if you want to solve the proof of work to create a second coin a third coin it takes you the same amount of work every time you want to do it now for revests and chimera unlike a hash cash where users themselves are generating their own hash cash revests and chimera were interested in what if a government decided that they wanted to mint money instead and if you think about how anti counterfeiting works just in say paper currency in order to counterfeit a bill there's a huge initial cost you have to acquire all the equipment to mimic the security features that are on on the bills but once you have all that equipment then you can print it doesn't matter if you print one bill or you print a hundred bills your costs go down so it has a huge fixed overhead cost but it has a low marginal cost and so they were interested in whether you could do a proof of work scheme that would mimic these properties where it would cost a real lot to mint that first coin but once you had the computational abilities to mint that first coin then minting a second third and fourth coin became a lot cheaper and so they had a proposal it was also based on hash functions in this case it was based on finding collisions as opposed to pre-images we won't go through the details of their scheme but it was interesting at a high level the problem that they were trying to solve another extension of hash cash comes from Hal Finney and what Hal didn't like about hash cash is that once you create a unit of hash cash you spend some computational resources creating it you spend it but then you have to retire that coin to prevent double spending you have to check that that coin doesn't get spent again there's no way that once you mint a piece of hash cash it can be passed around from person to person so he thought well what if I set up a server and every time you spend a hash cash you can a piece of hash cash you can send it to the server and the server will sort of refresh that coin it won't refresh it by computing a new proof of work it will just refresh it because you trust the server to only refresh coins that it receives and not create new coins out of thin air and then to provide a layer of security what he did is he based this server using a trusted platform module or a tpm which is a little chip where you can create programs and you can actually remotely over the internet check and see that that computer is running exactly the program that was specified so he set up a server that used this remote attestation so you could check that this refreshing service wasn't creating its own new coins it was just refreshing existing hash cash now let's think about the differences between hash cash and bitcoin so as we mentioned bitcoin effectively uses hash cash as proof of work but it modifies it slightly instead of shooting for a number that's smaller than a perfect power of two it's any number but that's just a slight modification the more substantial difference is a little more subtle in bitcoin the proof of work is being used for a different purpose than minting coins you're not solving the proof of work in order to mint coins now you might be saying wait a minute that's that's not right we have these miners and miners we call them miners because they're minting new coins and all miners do is solve proof of work right so obviously the proof of work is being solved in order to mine new coins or mint new coins however there's a subtle distinction here that needs to be made the best way to think about this is maybe think about what happens to bitcoin after all 21 million bitcoins are created what happens is the miners the so-called miners they continue solving the proof of work even though they're not getting any new money okay so they're not actually solving the proof of work to to generate new money they're doing something else to solve the proof of work specifically what they're doing is they're solving the proof of work to add blocks to the blockchain okay now the the mechanism for minting new coins piggybacks on that system where if you create a new block will also insert new coins into that block at least for a certain time period that bitcoin runs over but it's not the idea of hash cash where any individual can fire up their computer and directly mint coins by solving a proof of work system bitcoin also differs from hash cash in the sense that bitcoin has a lot more to it than hash cash does and hash cash it's simple system where you just mint a coin you send it to someone else in bitcoin you have a distributed peer-to-peer network you have the blockchain with the ledger you have transactions which have very complicated transaction types so I only be labor at this point because you know there is this notion that for example in the words of adam back who invented hash cash he says that bitcoin is hash cash extended with inflation control I think that's overreaching a bit it's sort of like saying a tesla is just a battery that has transportability so why did hash cash never catch on probably the issue is that spam just wasn't a big enough problem to solve for a lot of people they view spam as a nuisance but it's not something that they want to spend their computing cycles on combating we have spam filters today and they work pretty well at keeping spam out of our inboxes it's also possible that it wouldn't actually prevent spammers in particular if spammers had a botnet where they took control of a large number of other people's computers then they could use those computers to harvest hash cash and then they could continue spamming us however that said the idea of using proof of work to to limit resources it's still an idea that's kicking around you can see it in some proposals for replacing network protocols for example minimal LT in this portion of the lecture we'll look at a few systems that also combine proof of work with developing a cryptocurrency but they introduce a third component which is time stamping time stamping there's a bunch of proposals but the earliest goes back to harbour and stornetta in 1991 and they they sort of finesse their ideas in the ensuing years and this what i'll explain now is sort of the the latter version of it but in their time stamping scheme time stamping is actually a bit of a misnomer the idea isn't that you have some object and you're going to say conclusively that it came into existence at a particular time but what it's going to do is it's going to try and give you a sense of a sort of fuzzy sense of when it came into existence and it's also going to be order preserving so if one element is introduced after another element that partial ordering is preserved and it's undisputable so their idea is if you have a bunch of information data of any sort you can think of them visually as these blocks what they'll do is they'll define certain regions of times or intervals so this might be every 10 minutes for example and so in the first 10 minutes they spend some time collecting all the information and then when the intervals up what they do is they take that information and they use a merkle tree to combine all the information into a single node that represents all the information okay then when the second 10 minutes are up and they've collected all their objects they do the same thing they collect all of them and they aggregate them into a single into a single value using a merkle tree and they tie the node in the second interval to the node in the first interval by hashing in this representative node as well as the whole tree then as time continues more blocks come in and they continue to do this and they build up this chain now this data structure should look extremely familiar to you because it's essentially the blockchain okay blockchain also you have blocks and they're aggregated the transactions are aggregated using a merkle tree and every block is tied to the previous block using a hash chain the idea of stornetta and harbour is let's say everybody observes this block at a particular time once they observe that block they may sign it to say that yes i saw it and i saw it at this particular time and once you observe this block then everything that happened before is sort of fixed you can't go back and you can't change the ordering of any of the events that occurred before so you don't have to pay attention to all of these blocks as as they come in but the idea is that occasionally you check in you grab the latest value and when you grab it it sort of fix it fixes all the stuff that existed before it so let's compare and contrast this time stamping service which looks a lot like the blockchain in bitcoin with the blockchain itself so the first difference is that in a time stamping or the only difference is that the time stamping service the intervals are set by some party and you trust them so if they're going to define the intervals every 10 minutes nothing's enforcing that they actually occur every 10 minutes so toshi's idea was what if we take a proof of work a proof of work you can use to delay things and so what if you apply it to delaying the creation of these new entities in the hash chain if you can delay it and you set the proof of work so it takes about 10 minutes then you can actually enforce in a trustless manner the fact that these intervals last roughly 10 minutes the nice idea the really nice idea is that if you take the hash cash proposal for proof of work or satoshi's slight modification of it and you drop it in as the hash function that's hashing all the blocks in the merkle tree as well as the previous block in the hash chain if you drop it in it just works right they're both based on hashes and so you can just drop it in it preserves all the properties you need from a hash chain and a hash tree plus it gives you the proof of work which slows things down so that you can only add on intervals that are set by the difficulty of this problem now in the time stamping service we also mentioned that observers observe these blocks and they sign off on them in bitcoin you don't need that you don't need signatures you don't need people paying attention because the blockchain is difficult to create by looking at the blockchain you can just look for the longest chain the longest chain is the one that reflects the most amount of work and you trust it because the work was put into it not because a bunch of people said i saw this at a particular time now the bonus of using the blockchain is it also gives you a really nice way of minting cash if you want to mint new bitcoins you can update when you update the blockchain you can include a transaction a coin based transaction that creates these new bitcoins out of thin air and because these intervals are set for every 10 minutes then you have a controlled mechanism for creating these currencies at regular intervals now another proposal that looked at combining proof of work time stamping with applications to e-cash is called b-money from waydye in 1998 in this proposal you have a peer-to-peer network sort of like in bitcoin and their observers and the point is that they all maintain a ledger but they each have there's no global ledger like in the blockchain they each have their own ledger of what they think everyone's balance is what happens is if i want to create a new coin i choose a proof of work and it's not really specified what this would be but i just solve some proof of work i generate the solution and then that's my coin when i have the coin i broadcast it to all the observers and all the observers say that my account goes up by some amount based on how much work i put into minting this coin then if i want to transfer the money from someone to someone else then i do something very similar to bitcoin where i say who i am i say what coin i want to transfer and i sign it with a secret key that is tied to my identity uh so everyone knows that this transaction came from me and i broadcast that to the network then people validate the signature the observers validate it and they update their ledger moving the money from my account to another account another proposal an academic proposal came in 1999 and in this case it also used a ledger based system it used a merkle tree instead of the structure where you have merkle trees that tie into a hash chain they just had a huge merkle tree so you make a merkle tree that represented each day and once you had two days you would you create a note above it that represented weeks and once you've run it for more than one week then you would create one for months etc etc so despite the differences in the structure the properties are basically the same what would happen is the ledger would track coins as they're created so this is different from both b-money and from bitcoin in the sense that we're not using this ledger to track transactions themselves okay the transactions still happen in some fashion that's offline from the ledger all this ledger is keeping track of is what coins were issued with what serial numbers to prevent things like double spending uh but they have some additional proofs using zero knowledge so that that you can't trace coins as they're spent another similar proposal comes from nick sasbo he proposed a system called bit gold and according to him he had the idea for bit gold as early as 1998 however he didn't get around to blogging about it into 2005 now the reason these dates are maybe a little interesting is that there's a minor conspiracy theory that's popularized by nathaniel popper who works as a new york times reporter and also wrote a book on the history of bitcoin a very good book aside from this particular issue where he notes that the blog post timestamps changed after bitcoin was released so that the beam the bit gold proposal looks like it was written up about two months after bitcoin was released popper's hypothesis is that sasbo is a leading contender if not satoshi nakamoto himself and he cites this as evidence of sasbo as satoshi trying to cover up the fact that he invented bit gold before he knew about about bitcoin now the problem with this is i'll explain how bit gold works and you can decide for yourself if it's that similar to bitcoin or not the other problem is if you actually read the contents of the blog post nick is very clear about him having this idea in 1998 and he doesn't try and change those dates so more reasonable explanation is that maybe he just bumped the post to the top of his blog after bitcoin just to popularize the idea and make sure that people were aware of his similar proposal that existed prior to it anyways let's take a look at the proposal itself so in this proposal it starts off very similar to be money or hash cash you have a user alice and she takes a challenge string she computes a moderately hard proof of work function on it to create a solution now where does this challenge string come from well there was somebody who created currency before her and so what she does is she uses their solution in order to form her challenge and after she creates her solution someone else will come along and they'll take her solution and they'll use it as a challenge for themselves so all these coins are tied together through a chaining of the proof of works when she has a solution she broadcasts it to a network of time stamping servers so this is a peer-to-peer network of servers that that do time stamping and probably it was originally envisioned when time stamping services were available where companies would actually run these services where you could send them documents and they would sign off saying what time certain things were observed so what you do is you take your solution you combine it with your identity and a public key and you assert what time you created the solution at and you get all these time servers to sign off saying that they did observe it at roughly that amount of time once you have this object created you can take it and combine it with the original challenge that was used to create the solution and you can broadcast that to a different network of servers it could be the same network or it could be a different network and this network maintains what's called a secure title registry and so what they'll do is they'll take this tuple and they'll store it for future work and if anyone comes along and wants to see uh you know this this coin they'll pull it out and they'll show that it was created at a certain time and it was signed by a bunch of time stamping services now let's say that alice wants to transfer this money to bob what she does is she gets bob's identification in his public key and she creates a second type of transaction and she specifies her original transaction she asserts that she wants to move this transaction from her identity to bob's identity she lists bob's public key and she signs it with her private key that corresponds to the public key that was incorporated in the original transaction and so this is what stops anybody from transferring the money other than alice from alice's account then she broadcasts this transaction to the network and the network records it and the whole system continues now smart contracts is something else that was pioneered by sasvo that bitcoin touches on and other altcoins like ethereum take to a larger extent smart contracts you know nick never really wrote directly about how smart contracts would work in bit gold he did write in general about how they might work with a secure title registry which is the primitive that bit gold uses to keep track of all the transactions but in any case he did a lot of writing on that aspect of digital cash as well in both b-money and bit gold proof of work is used to directly mint currency anybody can solve a proof of work and the solution is money itself in the bitcoin the solution to a proof of work isn't money itself it's a block that extends the blockchain so proof of work is used to update a blockchain instead it's not used directly to mint coins and you'll continue to do the proof of work well after you're done minting all the coins that will exist in bitcoin b-money and bitcoin or bit gold rather rely on time stamping services so they rely on basically trusting that certain people see things at certain time and they sign off on it in bitcoin you actually don't really care about what time certain things were created all you care about is the relative order that certain blocks were created after other blocks and the reason that you can trust that a particular blockchain that you see is an accurate one is amount is based on the amount of work that went into creating it because it takes a lot of work to create the blockchain that's what makes you trust it not because it was signed by a bunch of entities that assert that certain things happen at certain times so in bitcoin it's a really simple solution where you can just look at the blockchain and use the longest chain finally when you think about the entities that make up the peer-to-peer networks and b-money and bit gold if these entities start disagreeing about things that you see you're going to basically decide what the ground truth is by counting who says what by basically taking a vote amongst these entities but since anybody can become an entity and entities might hide behind a hundred identities then it's really hard and not very reliable to do these type of mechanisms in bitcoin because they apply the proof of work to the blockchain as opposed to relying on time stampers to to to assert that certain things happen at certain times then what you can do in bitcoin instead is you can you can count the work that went into the creation of something as assertion of its validity rather than relying on what a certain number of people say so in other words you're counting the amount of computational power that's backing some version of events as opposed to as opposed to relying on the number of identities asserting that a certain order of events occurred b-money and bit gold never took off both of them were just proposed in in b-money's case it was on a mailing list in bit gold it was across a series of blog posts neither of them were implemented directly and because they were blog posts and not full specifications not as detailed as for example the bitcoin white paper and there was no code to go along with it the blog post sort of gloss over a couple issues that may be solvable may not be solvable but what happens when people disagree about version of events is something that's not explained very well or in a convincing manner i note that b-money doesn't really explain it at all bit gold does refer to some academic literature on how you solve problems so it's a little more convincing but there's nothing like a full rationale and explanation of how it's going to resolve conflicts the second is that once you solve a proof of work and you broadcast it someone else might try and steal it and then it's a foot race to see who gets to register at first that could probably be solved by incorporating into the challenge the identity of the person who's creating the coins but that's not explicitly mentioned a third problem is determining how hard the proof of work should be when you mint the coins and how much that amount of proof of work is is actually worth so in b-money every bit every piece of currency that's created and in bit gold as well it may have a completely different value depending on how hard a particular moderately hard function was at a given time given the computational advancements what bitcoin does instead is it adjusts the difficulty as the network gets faster or it scales it back and it keeps everything uniform so every every bitcoin is worth or a fraction of bitcoin is worth the same amount whereas that's not guaranteed in b-money or bit gold different coins could be worth different amounts depending on the functions that were used to create them in this final portion of the lecture we'll look about what if anything we can determine about Satoshi Nakamoto himself and also the the ideas that he had in the design of bitcoin by looking at the history of the ideas that that led up to the invention of bitcoin so first off just as a refresher who is Satoshi Nakamoto a lot of people know him as the creator of bitcoin and that's sort of an abstract notion okay we can be a little more specific about what was done in the name of Satoshi Nakamoto so according to Satoshi Nakamoto and i'll note as an aside that when Satoshi asserts that something is true i'm going to take him out of his word okay i don't think just because he's anonymous there's a reason that he's going to lie about certain things so if he says that i started coding bitcoin in may 2007 let's let's believe him and believe that that's true so at least according to him around may 2007 is when he started coding bitcoin he registered the domain bitcoin.org in august 2008 and at that time he started sending private emails to a few people who were he thought might be interested in the proposal okay then a little later in october 2008 he released publicly a white paper that described the protocol and then soon after he released the code for it as well then he stuck around for about two years and over these ensuing two years he posted lots of messages on message forums he emailed with lots of people he responded to people's concerns on the code side he submitted patches to the code he fixed it up in conjunction with other developers and basically maintained the source code in december 2010 he then left the project now i'm referring to Satoshi Nakamoto as a he i have no reason to believe that he's a he as opposed to a she it's just since he assumed a male name it's the easiest pronoun to use another thing i'm doing is i'm referring to him as a single individual there is a theory that maybe Satoshi Nakamoto is a collection of individuals i don't buy this theory i think that he is probably an individual the reason why is if we think about what was done in the name of Satoshi Nakamoto if we start at the end and we think about the two years somebody spent replying to emails and patching code it would be really hard to think that this would be multiple people sharing user accounts and passwords and you know responding in similar style uh a similar voice and making sure they didn't contradict each other it just seems a much simpler explanation that at least this portion of what Satoshi did was done by a single by a single individual now if you look at what he writes and what he says and the the patches that he makes to the code it's clear that he understood whoever the single individual is that individual did understand the full code base of bitcoin and so it's very reasonable that they're also the person that created the original piece of bitcoin software okay it's also clear from their writings that they understood all the design aspects of bitcoin and so uh they're probably uh the person who wrote the white paper as well there's no reason to assume otherwise now all of this isn't to say that Satoshi didn't have help with the original design however we know that Satoshi is very quick to attribute any help he receives after bitcoin is released to the people that contributed to the project and there's no reason to think that he would lie about inventing something by himself when he actually had help from other individuals now we might ask ourselves what did Satoshi know about the history of e-cache and to understand this better we can look at what he cites in his white paper and also the references that existed on early versions of the bitcoin website so if we look at his white paper we see that he cites some papers on basic cryptography and probability theory he also cites the time stamping work that we saw in the previous slides and it's very natural to think that he based the design of the blockchain on these references since the similarities are so apparent he also cites the hash cash proposal which has a proof of work that's very similar to the one that's used in bitcoin and he has a reference to b-money later on the website he added references to bit gold and as well to how Finney's reusable proof of work schemes now if we look at the history of email transactions that were made by were made public by people who corresponded with Satoshi Nakamoto in the early days we see that the b-money proposal was actually added after the fact at the suggestion of adam back Satoshi then emailed Wei Dai who created b-money and apparently we die was the one that that told him about Nick's proposal about bit gold okay so these proposals weren't probably inspirations for the original design he later corresponded a lot with how Finney and that's quite a reasonable explanation for why he cites reusable proof of works at least on the website so based on just the citations in the white paper it seems reasonable that maybe the only things that he knew or thought were relevant about the history of e-cash was hash cash and the time stamping proposals in the early days of bitcoin bitcoin had a wikipedia article and at some point it was flagged for deletion by the moderators of wikipedia because they thought it wasn't relevant or noteworthy and so there was some discussion between Satoshi and others about how to get this article so wikipedia would accept it and what Satoshi did is he actually suggested a stub article a single sentence that describes bitcoin and the way he phrased it was the following bitcoin is an implementation of way dies be money proposed on cypher punks in 1998 and Nick's as well as bit gold proposal so Satoshi at this point did see positioning bitcoin as an extension of these two ideas or an implementation of these two prior systems as a good explanation of of how it worked however from the previous slide it seems that Satoshi actually didn't know about these two systems when he came up with the original design of bitcoin now what about everything else the chami and e-cash uh you know all the credit card proposals that we looked at all the microtransactions what about all of that stuff did he know any of that history well the answer is we don't know what he did know or what he didn't know but he didn't give any indication really of knowing that history and it's just as likely that uh he didn't uh reference this because it just wasn't relevant to bitcoin bitcoin used a completely different model and so there's no reason to talk about these old systems that failed he does mention in passing chami and e-cash in one of his blog posts when he's talking about another proposal called opencoin.org and he notes that they seem to be talking about the old chami and central mint stuff but maybe because that was the only thing available maybe they would be interested in going in a new direction a lot of people automatically dismiss e-currency as a lost cause because of all the companies that failed since the 1990s i hope it's obvious it was only the centrally controlled nature of those systems that doom them i think this is the first time we're trying to decentralize non-trust based system so this gives a really nice idea a nice view of what satoshi thought of the earlier proposals and specifically how he felt bitcoin was different which is that bitcoin moved in a decentralized manner and from our study of all the previous systems we can see that this is true that this is a defining feature of bitcoin that's not present in a lot of the systems that we looked at another interesting quote from satoshi suggests that maybe he's not an academic a lot of academics think about ideas and write them down immediately satoshi says that he took an opposite approach he says i actually did bitcoin kind of backwards i had to write all the code before i could convince myself that i could solve every problem then i wrote the paper i i think i will be able to release the code sooner than i could write a detailed specification a final question we may ask ourselves colored by what we understand from the history of e-cash is why does satoshi maintain his anonymity the first reason might be it's just for fun uh there's lots of people that write novels that are anonymous there's graffiti artists like banksy that remain that maintain their anonymity and at that time in the community that he was involved in the cypherpunk community in the cryptography mailing list there were lots of people that were posting on that mailing list in an anonymous fashion the second that ties a little closer to to what we've seen is maybe there were legal reasons that he was concerned about revealing his identity there were a couple events in particular that led up to the release of bitcoin where two other proposals one was called liberty reserve and the other egold which we talked briefly about ran into legal trouble for money laundering in particular in 2006 the ceo or the founders of liberty reserve actually fled the united states because they were afraid they were going to be indicted on money laundering charges and for egold the founders stayed in the united states and they were actually indicted and eventually pled guilty to the charges and the guilty plea was registered just right before satoshi started the bitcoin and website and started emailing people about his proposal that said there's lots of people that invented ecash systems and nobody else was scared of the legal implications and no one else remained anonymous as well so this may have been a reason it may not have been the reason another thing is that we mentioned that certain aspects of ecash were patented and if you go back to the culture of the cypherpunk movement they were concerned about implementing ecash systems because they may violate the patents of some of this the technology that was was patented and so here's a post proposing that for example they launch a project to implement david charms ecash system which was subject to a patent and they do it under the guise of anonymity so that no one knows who they are and then if they get sued for violating the patent no one can find them to actually issue the the lawsuit a final reason that's often cited is that because bitcoin was so successful and satoshi has a lot of bitcoins that are worth a lot of money that maybe he's doing this for personal security reasons and this could very well be the the reason why he maintains his anonymity choosing to be anonymous isn't a decision you make once it's something that he understood that it could be successful but he wasn't a perfect oracle of the future he made mistakes just like everyone else both in the code he had some features that he added to bitcoin like sending money to ip addresses that never caught on no one thought they were useful when he described what bitcoin was useful for he gave a bunch of use cases that were very centered on the idea of using it across the internet which of course is a huge use case for bitcoin but it's not the only one he didn't really envision it being used by stores going into a car


I've just been reviewing some of the film you just can't see how big the waves are I don't know what it is about the lens on the camera or whatever it is but it makes it look a flat car and yet here's a wave that's at least two meters probably three you can see the straights on there on the water showing you how fast the wind is blowing. I'll have a quick look. It's 19 knots right now. Average today has been about 20 gusts peaking well earlier on the peaks were like 29 30 but now most of the day it's been a steady not steady but it's been 20 with gusts 25. All caused by these clouds which have been all day which I think is also going to be tomorrow. At half past two I think I've already said this. Maybe I said two o'clock. I'll hit my Lisbon waypoint. It's not actually Lisbon it's 60 miles off the coast of it. And then I'm going to change tack and head in towards Cape St Vincent which if you don't know that's the corner of Borgeville the bottom. Southwest corner famous for launching ships to explore the world in a time gone by. These days it's the corner of the Algarve. And then we'll then we'll do some soul searching and work out if we're going to stop in the Algarve or if we're going to carry on to across the Bay of Cadiz to the Straits of Gibraltar. And at the moment it will all entirely depend on what happens with the weather in the next two days. So if I've been in this all the way to the Algarve there's every chance that I'll need to stop get some more diesel for start because I have to every now and when there's no sun I have to run the engine to charge the battery. I've got solar panels but obviously today they've reduced very little at all. Certainly not kept up with the autopilot which I'm having to use because the wind vane doesn't work. So that's put a bit of a stretch on my diesel reserves. And you know it's all if management I'll find I'll do the maths on the way there and make a decision when we get there based on any number of factors. I would like to press on but you know there's the decision you'd like and there's the right decision and they're not always the same so we'll see how it is. That's enough probably. Can you see Tahoe Spirit? We're on the horizon three miles away. It's massive. Being strong is one thing. Being shifty as well has a whole new level of entertainment. Currently waiting until I can lay the mark and then I'm going to jive on to believe it or not on to port tech. But then we'll be heading inshore inshore which may be good or may be bad. We've got to cross the traffic lanes. We'll be outside of the traffic separation screem scheme the TSS rocker is Lisbon. So I'm waiting till we're past that and then we'll knit through all the traffic in the dead of night. They won't even know I'm here. A cup of tea now. Might puke first though.