1 00:00:00,530 --> 00:00:03,640 In this portion of the lecture, we'll begin looking at the history 2 00:00:03,640 --> 00:00:07,090 of payment systems that were invented prior to Bitcoin. 3 00:00:07,090 --> 00:00:09,810 We're going to start by looking at credit based systems. 4 00:00:09,810 --> 00:00:12,230 In general, what you can do is you can take all the systems and 5 00:00:12,230 --> 00:00:13,670 sort them into two piles. 6 00:00:13,670 --> 00:00:17,530 There's pile based on credit systems and there's piles based on cash systems. 7 00:00:17,530 --> 00:00:20,460 Bitcoin obviously is in the pile of cash systems. 8 00:00:20,460 --> 00:00:24,328 However, we should also look at credit based systems, even though Bitcoin's not 9 00:00:24,328 --> 00:00:28,098 part of that pile because these are the systems that are competing with Bitcoin. 10 00:00:30,258 --> 00:00:35,125 Credit card transactions are the dominant payment method that is used on 11 00:00:35,125 --> 00:00:36,850 the web today. 12 00:00:36,850 --> 00:00:39,770 If you've ever bought something from a website such as Amazon, 13 00:00:39,770 --> 00:00:41,990 you know how the arrangement goes. 14 00:00:41,990 --> 00:00:45,900 You type in your credit card details, you send it to Amazon and 15 00:00:45,900 --> 00:00:49,130 then Amazon turns around with these credit card details and 16 00:00:49,130 --> 00:00:52,630 they talk to the system, the financial system. 17 00:00:52,630 --> 00:00:55,410 We don't have to go into all the details of who the parties are that 18 00:00:55,410 --> 00:00:57,200 are involved in the financial system. 19 00:00:57,200 --> 00:01:01,317 But in general there's a credit card processor and the credit card processor is 20 00:01:01,317 --> 00:01:05,693 going to talk to the banks, the credit card companies, and other intermediaries. 21 00:01:07,133 --> 00:01:11,271 The other architecture that you may see if you use something like PayPal is 22 00:01:11,271 --> 00:01:13,580 an intermediary architecture. 23 00:01:13,580 --> 00:01:16,840 In this case there's a company that sits between you and the website. 24 00:01:16,840 --> 00:01:22,110 So, you send your credit card details to this company, it approves the transaction, 25 00:01:22,110 --> 00:01:23,400 and settles with the website. 26 00:01:24,710 --> 00:01:27,760 The advantages of this type of architecture are privacy. 27 00:01:27,760 --> 00:01:28,380 In this case, 28 00:01:28,380 --> 00:01:32,490 the user is never fully disclosing all their credit card details to the website. 29 00:01:32,490 --> 00:01:36,430 The drawback is that the user's no longer directly 30 00:01:36,430 --> 00:01:38,470 interacting with the website alone. 31 00:01:38,470 --> 00:01:40,930 The user has to interact with his intermediary. 32 00:01:40,930 --> 00:01:43,190 They have to be aware that the intermediary exists. 33 00:01:43,190 --> 00:01:45,790 They may have to have an account with the intermediary. 34 00:01:48,100 --> 00:01:52,105 Now an early system to use this type of architecture was a company called 35 00:01:52,105 --> 00:01:53,330 FirstVirtual. 36 00:01:53,330 --> 00:01:55,420 It was founded in 1994. 37 00:01:55,420 --> 00:01:59,000 FirstVirtual is an interesting company because beyond just being one of 38 00:01:59,000 --> 00:02:03,080 the earliest players in doing electronic payments they were also one of 39 00:02:03,080 --> 00:02:07,450 the earliest companies to try and set up a virtual office as it was called. 40 00:02:07,450 --> 00:02:10,120 And that's why they called their company FirstVirtual. 41 00:02:10,120 --> 00:02:13,680 So in a virtual office there was no physical office where people met. 42 00:02:13,680 --> 00:02:16,380 People were scattered across the country and 43 00:02:16,380 --> 00:02:18,920 they communicated through email on the internet. 44 00:02:18,920 --> 00:02:23,600 Now remember, in 1994 this was before the days of GitHub and Skype and Slack. 45 00:02:23,600 --> 00:02:27,430 And so it was very hard to run a business this way. 46 00:02:27,430 --> 00:02:30,700 And they have an interesting paper outlining some of the challenges of that 47 00:02:30,700 --> 00:02:32,120 business model. 48 00:02:32,120 --> 00:02:35,080 But anyways, back to what they actually propose. 49 00:02:35,080 --> 00:02:37,960 What they propose is a system where both the user and 50 00:02:37,960 --> 00:02:41,690 the merchant sign up with FirstVirtual, they have an account, and 51 00:02:41,690 --> 00:02:46,610 then they conduct transactions of electronic payments over email. 52 00:02:46,610 --> 00:02:52,360 The idea is that one you put something in your cart and say I'd like to check out, 53 00:02:52,360 --> 00:02:56,250 what the merchant will do is they'll send an email to transfer@card.com, 54 00:02:56,250 --> 00:02:58,960 which is an email address run by FirstVirtual. 55 00:02:58,960 --> 00:03:02,020 And it will have all the details of the transaction. 56 00:03:02,020 --> 00:03:05,980 The user is then sent an email with the transaction details asking them to 57 00:03:05,980 --> 00:03:07,330 approve it. 58 00:03:07,330 --> 00:03:09,320 If the user emails back yes, 59 00:03:09,320 --> 00:03:13,260 then FirstVirtual will bill their credit card of the user. 60 00:03:13,260 --> 00:03:16,940 A credit card that the user had provided when they enrolled in the service. 61 00:03:17,940 --> 00:03:21,550 Then what will happen is FirstVirtual will wait to see if the user will dispute 62 00:03:21,550 --> 00:03:23,060 the credit card change. 63 00:03:23,060 --> 00:03:26,120 The user typically had 90 days to file a dispute. 64 00:03:26,120 --> 00:03:29,110 And so FirstVirtual will ride out these 90 days and 65 00:03:29,110 --> 00:03:33,300 it's only on the 91st day that the merchant actually gets paid the money. 66 00:03:33,300 --> 00:03:35,450 This is a major drawback of this system, 67 00:03:35,450 --> 00:03:39,060 having to wait that long to receive payment if you're a merchant. 68 00:03:39,060 --> 00:03:42,700 However, amazingly, it's not that much different than what happens today. 69 00:03:42,700 --> 00:03:46,840 Today, the merchant does get paid immediately, however, 70 00:03:46,840 --> 00:03:51,720 there still is the threat that the customer will file a charge back, or 71 00:03:51,720 --> 00:03:54,200 dispute the credit card statement. 72 00:03:54,200 --> 00:03:55,062 And in this case, 73 00:03:55,062 --> 00:03:58,513 the merchant will have to pay the money back to the credit card company. 74 00:04:00,353 --> 00:04:05,400 Two other systems who use this architecture are OpenMarket and NetBill. 75 00:04:05,400 --> 00:04:07,420 And when you look at these early protocols, 76 00:04:07,420 --> 00:04:11,490 what is interesting is to drill down and see at a protocol level what protocols 77 00:04:11,490 --> 00:04:14,760 they are using to send transactions back and forth. 78 00:04:14,760 --> 00:04:17,450 FirstVirtual, as mentioned, was based on email. 79 00:04:17,450 --> 00:04:19,280 There were other competing approaches. 80 00:04:19,280 --> 00:04:24,080 In OpenMarket, it was based on encoding information into the URL For NetBill, 81 00:04:24,080 --> 00:04:27,060 they use a custom MIME type over HTTP. 82 00:04:27,060 --> 00:04:29,710 In the mid 90s there was also competing approach 83 00:04:29,710 --> 00:04:33,410 to the FirstVirtual intermediary based architecture. 84 00:04:33,410 --> 00:04:35,660 We'll call it the SET architecture. 85 00:04:35,660 --> 00:04:40,390 Like the intermediary architecture, it also tries to dress the problem 86 00:04:40,390 --> 00:04:45,320 of users not sending all of their credit card information to the merchants. 87 00:04:45,320 --> 00:04:49,450 It's actually remarkable that no one thought that was a good idea in the 90s. 88 00:04:49,450 --> 00:04:53,270 It wasn't until much later that that system became predominant. 89 00:04:53,270 --> 00:04:57,590 In this system, it also tried to address the idea of the user having to 90 00:04:57,590 --> 00:04:59,720 enroll with the intermediary. 91 00:04:59,720 --> 00:05:04,350 So, what they decided to pursue is an architecture, where the user, 92 00:05:04,350 --> 00:05:07,140 once they've settled on the transaction that they want to 93 00:05:07,140 --> 00:05:10,460 conduct with the website, they only interact with the website. 94 00:05:10,460 --> 00:05:15,195 However, what they do is they take their view of what the transaction details 95 00:05:15,195 --> 00:05:20,355 are and they encode their credit card information, and they encrypt it such that 96 00:05:20,355 --> 00:05:25,167 some server, some third party can decrypt it but the merchant cannot decrypt it. 97 00:05:25,167 --> 00:05:27,337 They send it to the merchant, and 98 00:05:27,337 --> 00:05:29,987 the merchant takes this information since it can't decrypt it. 99 00:05:29,987 --> 00:05:33,657 All it can do is blindly forward it on to the third party. 100 00:05:33,657 --> 00:05:38,567 However, they also append their own view of what the transaction looks like. 101 00:05:38,567 --> 00:05:41,307 Then the third party can decrypt both of these. 102 00:05:41,307 --> 00:05:44,762 They can compare the views of the transactions, and if they align, 103 00:05:44,762 --> 00:05:48,412 they both say the same thing, then they'll approve the transaction. 104 00:05:50,312 --> 00:05:53,427 Now SET was a standard that was developed by Visa and 105 00:05:53,427 --> 00:05:58,500 MasterCard in conjunction with a lot of technology companies at the time. 106 00:05:58,500 --> 00:06:01,430 Netscape, Microsoft, Verisign, RSA. 107 00:06:02,615 --> 00:06:06,505 SET was sort of had some intellectual ancestors. 108 00:06:06,505 --> 00:06:10,015 There was another company at the time called CyberCash. 109 00:06:10,015 --> 00:06:13,675 IBM had a proposal called IKP that was later standardized 110 00:06:13,675 --> 00:06:15,272 into a standard Called SEPP. 111 00:06:15,272 --> 00:06:19,112 And Microsoft working with Visa has also developed their own standard. 112 00:06:19,112 --> 00:06:23,483 All of these use that same architecture that we just described, and so 113 00:06:23,483 --> 00:06:28,004 the idea of SET was to unify this architecture, provide a specification 114 00:06:28,004 --> 00:06:31,955 where all of these systems would fit under the umbrella of SET. 115 00:06:34,115 --> 00:06:38,558 Now CyberCash is the one company that went into SET is an interesting company that 116 00:06:38,558 --> 00:06:40,728 we'll spend a few minutes looking at. 117 00:06:40,728 --> 00:06:44,820 CyberCash had very good relationships with the US government. 118 00:06:44,820 --> 00:06:48,280 In addition to their product that was based on credit cards, they also had 119 00:06:48,280 --> 00:06:52,150 a coin-based system, a digital cash-based system called CyberCoin. 120 00:06:52,150 --> 00:06:55,600 CyberCoin was a micropayment system, so what that meant is you probably 121 00:06:55,600 --> 00:06:59,440 never have more than ten dollars in your account at any one given time. 122 00:06:59,440 --> 00:07:04,470 However what CyberCash was able to do is they were able to actually 123 00:07:04,470 --> 00:07:08,974 get FDIC insurance for each account for up to $100,000. 124 00:07:10,540 --> 00:07:13,630 Back in the 90s when CyberCash was operating 125 00:07:13,630 --> 00:07:17,310 there was also a restriction on the export of cryptography. 126 00:07:17,310 --> 00:07:19,850 Cryptography was considered a weapon and so 127 00:07:19,850 --> 00:07:23,360 you couldn't export it to other nations. 128 00:07:23,360 --> 00:07:26,050 In this case CyberCash wanted to export their software. 129 00:07:26,050 --> 00:07:28,610 They wanted other people around the world to be able to use it. 130 00:07:28,610 --> 00:07:31,080 However it used the encryption technology. 131 00:07:31,080 --> 00:07:35,450 So normally this export would not be allowed, however what CyberCash was able 132 00:07:35,450 --> 00:07:39,130 to do, is work with the state of department to get a special exemption for 133 00:07:39,130 --> 00:07:40,142 their software. 134 00:07:40,142 --> 00:07:43,182 And the argument was, that going into their software and 135 00:07:43,182 --> 00:07:47,234 extracting the encryption technology out of it would be way more work than it 136 00:07:47,234 --> 00:07:50,041 would take to just to write the crypto from scratch. 137 00:07:52,013 --> 00:07:56,594 Also leading into the year 2000 there was a lot of concern over a bug called 138 00:07:56,594 --> 00:07:57,870 the Y2K bug. 139 00:07:57,870 --> 00:08:00,500 The Y2K bug didn't turn out to be that big of a deal. 140 00:08:00,500 --> 00:08:04,740 There weren't a lot of systems that were influenced or effected by the bug. 141 00:08:04,740 --> 00:08:08,797 However, CyberCash has the dubious distinction of being one that was 142 00:08:08,797 --> 00:08:09,768 effected by it. 143 00:08:09,768 --> 00:08:14,660 And their payment processor software exhibited double 144 00:08:14,660 --> 00:08:18,260 payments as a result of this bug. 145 00:08:18,260 --> 00:08:20,398 They later went bankrupt in 2001. 146 00:08:20,398 --> 00:08:24,655 Their intellectual property was acquired by Verisign, who then turned around and 147 00:08:24,655 --> 00:08:26,798 sold it to PayPal, where it lives today. 148 00:08:29,118 --> 00:08:32,060 So, let's think about why the SET architecture didn't work. 149 00:08:33,690 --> 00:08:37,140 The big problem, probably the fundamental problem of the SET architecture, 150 00:08:37,140 --> 00:08:40,870 has to do with a subject of distributing public keys to 151 00:08:40,870 --> 00:08:43,660 all the people that need public keys in the protocol. 152 00:08:43,660 --> 00:08:47,050 This is called PKI, or Public Key Infrastructure. 153 00:08:47,050 --> 00:08:50,970 And a nice way of thinking about this was actually developed by iKP, 154 00:08:50,970 --> 00:08:55,030 the IBM project that was one of the predecessors to SET. 155 00:08:55,030 --> 00:08:58,610 What iKP did is they came up with three levels of security. 156 00:08:58,610 --> 00:09:02,580 In the most basic security, only the processor had to have a public key. 157 00:09:02,580 --> 00:09:06,010 Now, they had to have more than a public key, this public key had to be bound 158 00:09:06,010 --> 00:09:08,650 to their identity in something called a certificate, so 159 00:09:08,650 --> 00:09:10,820 we can think of these as certificates. 160 00:09:10,820 --> 00:09:12,740 On the second level of security, 161 00:09:12,740 --> 00:09:16,500 all the merchants also had to acquire certificates. 162 00:09:16,500 --> 00:09:20,080 And in the third level of security- the highest level of security, 163 00:09:20,080 --> 00:09:23,750 not only did the processor and all the merchants have to have certificates, but 164 00:09:23,750 --> 00:09:29,080 they suggested that all users also have to go and acquire a certificate. 165 00:09:29,080 --> 00:09:31,170 Now these certificates are used so 166 00:09:31,170 --> 00:09:33,920 that everybody in the protocol has signing keys. 167 00:09:33,920 --> 00:09:36,780 And essentially what happens is every time you do a transaction, 168 00:09:36,780 --> 00:09:40,260 everybody signs everything they do, and if there's disputes later, 169 00:09:40,260 --> 00:09:44,230 then there's a record of who said what about the transaction. 170 00:09:44,230 --> 00:09:48,300 So it's used to keep everybody accountable in the protocol. 171 00:09:48,300 --> 00:09:50,950 CyberCash always required level three. 172 00:09:50,950 --> 00:09:53,440 And when the standardization SET came along, 173 00:09:53,440 --> 00:09:56,610 they decide that level 3 was the best level. 174 00:09:56,610 --> 00:09:59,480 This is the level where; as I mentioned, all users have to go and 175 00:09:59,480 --> 00:10:01,210 acquire certificates. 176 00:10:01,210 --> 00:10:02,900 Now this was a disaster. 177 00:10:02,900 --> 00:10:05,770 Users don't want go and acquire certificates, it's complicated, 178 00:10:05,770 --> 00:10:08,550 you have to deal with the certificate authority. 179 00:10:08,550 --> 00:10:11,050 In these days, it wasn't an automated process. 180 00:10:11,050 --> 00:10:16,230 You have to send enough information about who you are so that you could be granted 181 00:10:16,230 --> 00:10:20,120 the certificates, and so that's a big reason why the SET architecture failed. 182 00:10:23,140 --> 00:10:26,225 Some other points of interest about SET, it was, 183 00:10:26,225 --> 00:10:28,365 as I mentioned SET is not a system itself. 184 00:10:28,365 --> 00:10:30,555 It is an attempt at standardization. 185 00:10:30,555 --> 00:10:32,275 It was done in 1996. 186 00:10:32,275 --> 00:10:35,655 Around the same time, another group, the World Wide Web Consortium, 187 00:10:35,655 --> 00:10:38,750 were also looking at standardizing financial payments. 188 00:10:38,750 --> 00:10:42,700 They took a different approach, they thought it would be interesting to extend 189 00:10:42,700 --> 00:10:46,220 HTTP the protocol is sort of arbitrary ways. 190 00:10:46,220 --> 00:10:49,270 And they had a very general proposal for how you might extend it, and 191 00:10:49,270 --> 00:10:52,910 one of the use cases that they had was doing payments. 192 00:10:52,910 --> 00:10:57,310 This never happened, essentially this was never actually deployed, 193 00:10:57,310 --> 00:11:00,570 the whole extension framework was never deployed, and so 194 00:11:00,570 --> 00:11:03,640 this was another standardization attempt that failed. 195 00:11:03,640 --> 00:11:07,530 At the time that we're recording this lecture in 2015, 196 00:11:07,530 --> 00:11:12,160 the W3C has recently came out and said that they would like to 197 00:11:12,160 --> 00:11:16,090 do another attempt at standardizing financial systems. 198 00:11:16,090 --> 00:11:19,520 And in this case, Bitcoin will be part of that standardization. 199 00:11:19,520 --> 00:11:23,478 However, given the past failures, they have a tough hill to climb.