1 00:00:00,500 --> 00:00:06,290 So we've just invested the effort to understand Bitcoin scripts a little bit, 2 00:00:06,290 --> 00:00:09,820 but I haven't really shown you what's so cool about Bitcoin scripts yet. 3 00:00:09,820 --> 00:00:13,881 It turns out you can do quite a lot of neat things that will justify 4 00:00:13,881 --> 00:00:17,250 the complexity of having the scripting language instead of just specifying 5 00:00:17,250 --> 00:00:18,070 public keys. 6 00:00:19,610 --> 00:00:21,650 So one of them is to do an escrow transaction. 7 00:00:23,080 --> 00:00:25,270 So this is a classic situation online. 8 00:00:25,270 --> 00:00:27,760 Alice and Bob want to do business with each other. 9 00:00:27,760 --> 00:00:30,500 Maybe Alice has just won some online auction and 10 00:00:30,500 --> 00:00:32,190 is ready to buy some things from Bob. 11 00:00:33,660 --> 00:00:36,060 Now Alice wants to pay Bob in Bitcoin for 12 00:00:36,060 --> 00:00:39,440 Bob to send some physical goods back to Alice. 13 00:00:39,440 --> 00:00:42,310 But we get into this problem where Alice doesn't want to 14 00:00:42,310 --> 00:00:45,010 pay until after she's received the goods, but 15 00:00:45,010 --> 00:00:48,010 Bob doesn't want to send the goods until after Bob has been paid. 16 00:00:49,300 --> 00:00:50,450 So what can we do about that? 17 00:00:51,550 --> 00:00:54,760 There's quite a nice solution in Bitcoin that's actually used quite heavily in 18 00:00:54,760 --> 00:00:58,800 practice, which is to introduce a third party and do escrow transactions. 19 00:01:00,120 --> 00:01:01,010 So how does this work? 20 00:01:02,250 --> 00:01:07,580 Well, Alice is going to send the money not directly to Bob but 21 00:01:07,580 --> 00:01:10,780 create a MULTISIG transaction that requires 22 00:01:10,780 --> 00:01:14,200 two of three people to sign in order to redeem the coins. 23 00:01:15,350 --> 00:01:18,080 And those three people are going to be Alice, Bob, and Judy, 24 00:01:18,080 --> 00:01:22,810 who's a judge, who's going to come into play in case there's any dispute. 25 00:01:22,810 --> 00:01:26,960 So Alice will create this transaction for the desired amount 26 00:01:26,960 --> 00:01:31,190 with that two out of three MULTISIG between Alice, Bob, and Judy. 27 00:01:31,190 --> 00:01:34,690 Alice signs the transaction, redeeming some coins that she owns, and 28 00:01:34,690 --> 00:01:36,275 this will get published in the blockchain. 29 00:01:37,590 --> 00:01:41,870 So at this point these coins are held in escrow between Alice, 30 00:01:41,870 --> 00:01:46,780 Bob, and Judy, and any two of them can specify where the coins should go. 31 00:01:48,550 --> 00:01:51,470 So Bob will be satisfied after that happens that he's 32 00:01:51,470 --> 00:01:53,525 safe sending the goods over to Alice. 33 00:01:53,525 --> 00:01:56,470 And he'll mail them or deliver them physically. 34 00:01:59,180 --> 00:02:02,400 Now, what we hope happens in the normal case is that Alice and 35 00:02:02,400 --> 00:02:06,260 Bob are both honest, in which case the goods arrive on time, 36 00:02:06,260 --> 00:02:08,200 they're what Alice was expecting, and 37 00:02:08,200 --> 00:02:12,000 she wants to actually release the money from escrow so that Bob can spend it. 38 00:02:13,430 --> 00:02:17,760 So if this happens, Alice and Bob can both sign a transaction 39 00:02:17,760 --> 00:02:20,300 redeeming the funds from escrow and sending them to Bob. 40 00:02:20,300 --> 00:02:25,200 And the great thing here is that Judy never had to get involved at all. 41 00:02:25,200 --> 00:02:26,800 There was no dispute. 42 00:02:26,800 --> 00:02:31,150 And so Alice and Bob were able to sign, and that 43 00:02:31,150 --> 00:02:34,840 represents two out of the three people required by the MULTISIG transaction. 44 00:02:36,090 --> 00:02:40,440 So in the normal case this isn't that much less efficient than Alice just sending Bob 45 00:02:40,440 --> 00:02:41,410 the money. 46 00:02:41,410 --> 00:02:44,155 It requires just one extra transaction on the blockchain. 47 00:02:47,120 --> 00:02:51,460 Now what would have happened if Bob didn't actually send the goods or 48 00:02:51,460 --> 00:02:53,890 if he tried to send them and they were lost in the mail? 49 00:02:53,890 --> 00:02:55,380 Maybe he sent the wrong size. 50 00:02:56,780 --> 00:03:00,270 Alice now doesn't want to pay Bob because she thinks that she got cheated, and 51 00:03:00,270 --> 00:03:01,530 she wants to get her money back. 52 00:03:03,630 --> 00:03:07,560 So Alice and Bob are definitely not both going to sign a transaction that releases 53 00:03:07,560 --> 00:03:09,500 the money to Bob. 54 00:03:09,500 --> 00:03:12,720 But Bob's also not going to sign a transaction that releases the money back 55 00:03:12,720 --> 00:03:17,460 to Alice because he may be denying Alice's claim of fraud here. 56 00:03:19,040 --> 00:03:21,180 So now we're going to have to get Judy involved. 57 00:03:21,180 --> 00:03:25,180 Judy is going to have to decide which of these two people was honest, 58 00:03:25,180 --> 00:03:26,680 which one doesn't deserve the money. 59 00:03:26,680 --> 00:03:32,490 And if Judy decides that Bob cheated, Judy will be willing to sign 60 00:03:32,490 --> 00:03:37,460 a transaction along with Alice, sending the money from escrow back to Alice. 61 00:03:37,460 --> 00:03:39,570 So Alice and Judy can get together. 62 00:03:39,570 --> 00:03:41,700 That's two of the three required signatures. 63 00:03:41,700 --> 00:03:42,910 And Alice can get her money back. 64 00:03:44,550 --> 00:03:47,390 And of course, Judy would have the opportunity to rule in the other 65 00:03:47,390 --> 00:03:48,570 direction. 66 00:03:48,570 --> 00:03:50,877 If Judy thinks that Alice is at fault here, and 67 00:03:50,877 --> 00:03:53,302 Alice is simply refusing to pay when she should, 68 00:03:53,302 --> 00:03:56,517 Judy can sign a transaction with Bob, sending the money to Bob. 69 00:03:59,075 --> 00:04:01,757 So Judy essentially has full control here, but 70 00:04:01,757 --> 00:04:06,260 the nice thing is that she won't have to be involved unless there's a dispute. 71 00:04:07,840 --> 00:04:10,979 Another cool application is what are called green addresses. 72 00:04:12,300 --> 00:04:16,700 So the problem here is that Alice wants to pay Bob and Bob's offline. 73 00:04:16,700 --> 00:04:19,910 So Bob can't go and look at the blockchain to see if the transaction that 74 00:04:19,910 --> 00:04:22,740 Alice is sending is actually there. 75 00:04:22,740 --> 00:04:26,440 Maybe Bob simply doesn't have the time to go and look at the blockchain and 76 00:04:26,440 --> 00:04:28,429 wait for the transaction to be confirmed. 77 00:04:29,550 --> 00:04:32,770 Remember that normally we want a transaction to be in the blockchain and 78 00:04:32,770 --> 00:04:34,360 be confirmed by six blocks, 79 00:04:34,360 --> 00:04:38,240 which takes up to an hour before we trust that it's really in the blockchain. 80 00:04:39,790 --> 00:04:43,400 Or maybe Bob's just in a Faraday cage and doesn't have any connection to 81 00:04:43,400 --> 00:04:47,210 the Internet at all, so Bob is never going to be able to check the blockchain. 82 00:04:47,210 --> 00:04:51,060 This would be the case, say, if Bob was a person selling food on the street. 83 00:04:51,060 --> 00:04:55,977 So to solve this problem of being able to send money using Bitcoin without 84 00:04:55,977 --> 00:04:59,525 the recipient being able to access the blockchain, 85 00:04:59,525 --> 00:05:03,736 we have to introduce another third party, which is the bank. 86 00:05:03,736 --> 00:05:07,819 So Alice is going to talk to her bank and say, hey it's me Alice. 87 00:05:07,819 --> 00:05:09,330 I am your loyal customer. 88 00:05:09,330 --> 00:05:11,750 Here is my card or my identification. 89 00:05:11,750 --> 00:05:13,265 And I'd really like to pay Bob here. 90 00:05:13,265 --> 00:05:14,030 Could you help me out? 91 00:05:15,580 --> 00:05:17,200 And the bank will say sure. 92 00:05:17,200 --> 00:05:19,270 I'm going to deduct some money out of your account and 93 00:05:19,270 --> 00:05:24,080 draw up a transaction from one of my green addresses over to Bob. 94 00:05:26,120 --> 00:05:30,110 So notice that this money is coming directly from the bank to Bob. 95 00:05:30,110 --> 00:05:33,600 Some of the money, of course, and a change address is going back to the bank, maybe. 96 00:05:35,040 --> 00:05:39,175 But essentially the bank is paying Bob here from a bank-controlled address. 97 00:05:39,175 --> 00:05:42,460 That bank-controlled address comes with a guarantee 98 00:05:42,460 --> 00:05:45,310 that that money will never be double-spent. 99 00:05:45,310 --> 00:05:48,534 So as soon as Bob sees that this transaction is signed by the bank, 100 00:05:48,534 --> 00:05:49,140 if he trusts the bank, 101 00:05:49,140 --> 00:05:53,770 if he trusts the bank's guarantee not to double-spend the money, he can 102 00:05:53,770 --> 00:05:57,365 accept that that money will eventually be his when it's confirmed in the blockchain. 103 00:05:59,570 --> 00:06:02,600 Now notice that this is not a Bitcoin-enforced guarantee. 104 00:06:02,600 --> 00:06:04,660 This is a real-world guarantee. 105 00:06:04,660 --> 00:06:09,090 So Bob has to trust that the bank in the real world Is doing a business and 106 00:06:09,090 --> 00:06:12,860 cares about their reputation and won't double spend for that reason. 107 00:06:13,940 --> 00:06:16,900 And the bank will be able to say, you can look at my history. 108 00:06:16,900 --> 00:06:21,980 I've been using this green address for a long time, and I've never double-spent. 109 00:06:21,980 --> 00:06:24,450 Therefore, I'm very unlikely to do so in the future. 110 00:06:27,360 --> 00:06:29,870 Of course if the bank ever does double-spend, 111 00:06:29,870 --> 00:06:32,490 trust in this whole system is going to collapse very quickly. 112 00:06:32,490 --> 00:06:39,890 And in fact, the two most prominent online services that implemented green addresses, 113 00:06:39,890 --> 00:06:46,290 which were Instawallet and MtGox, both ended up collapsing. 114 00:06:46,290 --> 00:06:49,660 So for that reason green addresses aren't used as much in Bitcoin 115 00:06:49,660 --> 00:06:51,250 as when they were first proposed. 116 00:06:51,250 --> 00:06:54,440 People were really excited and thought this was a great idea and 117 00:06:54,440 --> 00:06:59,150 a way to do payments more quickly and without accessing the blockchain. 118 00:06:59,150 --> 00:07:01,670 Now people are actually quite nervous about this idea, 119 00:07:01,670 --> 00:07:05,750 and they're worried that this puts too much trust in the bank. 120 00:07:05,750 --> 00:07:09,431 As a result, this isn't used that much in practice even though it's a cool protocol. 121 00:07:13,758 --> 00:07:19,110 A third example I'd like to show you is a way to do efficient micropayments. 122 00:07:19,110 --> 00:07:24,030 So the setup here is that Alice is a customer who wants to pay Bob 123 00:07:24,030 --> 00:07:26,636 a low amount of money for some service that she's going to use. 124 00:07:27,990 --> 00:07:31,880 So maybe in this case Bob is really Alice's wireless service provider, and 125 00:07:31,880 --> 00:07:34,240 Alice wants to pay a small amount of money for 126 00:07:34,240 --> 00:07:35,780 every minute that she talks on her phone. 127 00:07:38,580 --> 00:07:42,510 Now you can see why a solution that won't work here is to simply create a Bitcoin 128 00:07:42,510 --> 00:07:46,090 transaction every minute that Alice speaks on the phone. 129 00:07:46,090 --> 00:07:48,520 That's going to create too many transactions. 130 00:07:48,520 --> 00:07:53,110 There will be too many transaction fees, and nobody is happy about that. 131 00:07:53,110 --> 00:07:57,120 The simple solution here is to create a new low value transaction 132 00:07:57,120 --> 00:07:59,450 every minute that Alice talks on the phone. 133 00:07:59,450 --> 00:08:02,650 So if she talks for two hours, you might need over a hundred transactions. 134 00:08:03,900 --> 00:08:07,040 The problem that you're going to get in to in that system is that those transactions 135 00:08:07,040 --> 00:08:10,779 might be all very low value, and the transaction fees might really kill you. 136 00:08:11,780 --> 00:08:16,170 So if the value of each one of these transactions is on the order of what 137 00:08:16,170 --> 00:08:20,230 the transaction fees are you're going to be paying quite a high cost to do this. 138 00:08:21,500 --> 00:08:24,710 So what we would like is if you can combine all these small payments into 139 00:08:24,710 --> 00:08:25,880 one big payment at the end. 140 00:08:25,880 --> 00:08:31,650 And there's actually a neat way to do this with serial micropayments. 141 00:08:31,650 --> 00:08:32,990 So how is this going to work? 142 00:08:32,990 --> 00:08:37,490 So we start with a MULTISIG transaction that pays the maximum amount Alice would 143 00:08:37,490 --> 00:08:43,090 ever need to spend to a MULTISIG transaction requiring both Alice and 144 00:08:43,090 --> 00:08:45,170 Bob to sign to release the coins. 145 00:08:47,720 --> 00:08:51,430 Now after the first minute that Alice has used the service or 146 00:08:51,430 --> 00:08:56,130 the first time Alice needs to make a miropayment, she signs 147 00:08:56,130 --> 00:09:01,160 a transaction spending those coins that were sent to the MULTISIG address, 148 00:09:01,160 --> 00:09:05,889 sending one coin to Bob and returning the rest to Alice. 149 00:09:08,280 --> 00:09:12,604 After the next minute of using the service, Alive signs another transaction, 150 00:09:12,604 --> 00:09:16,745 and this time she's paying two coins to Bob and sending the rest to herself. 151 00:09:16,745 --> 00:09:18,430 And notice that these are just signed by Alice. 152 00:09:18,430 --> 00:09:22,470 They haven't been signed by Bob yet. 153 00:09:22,470 --> 00:09:25,220 Alice is going to keep sending these transactions to Bob 154 00:09:25,220 --> 00:09:26,589 every minute that she uses the service. 155 00:09:28,950 --> 00:09:31,050 Notice that these aren't getting published in the blockchain. 156 00:09:31,050 --> 00:09:35,075 They're just getting sent from Alice to Bob. 157 00:09:35,075 --> 00:09:38,025 Eventually Alice is going to finish using the service, 158 00:09:38,025 --> 00:09:40,459 in which case she'll tell Bob, I'm done. 159 00:09:40,459 --> 00:09:41,850 You can cut off the service. 160 00:09:41,850 --> 00:09:43,088 I'm not going to pay you anymore. 161 00:09:43,088 --> 00:09:47,400 And Bob's going to say, great, I'll disconnect your service. 162 00:09:47,400 --> 00:09:50,390 And I'm going to take that last transaction that you sent me, and 163 00:09:50,390 --> 00:09:55,280 I'm also going to sign that and publish that to the blockchain. 164 00:09:55,280 --> 00:09:59,574 So, since each transaction was paying Bob a little bit more and Alice a little bit 165 00:09:59,574 --> 00:10:03,805 less, whatever the final one is is what Bob is going to choose to actually redeem, 166 00:10:03,805 --> 00:10:06,457 paying him for the service that he was provided and 167 00:10:06,457 --> 00:10:08,767 giving the rest of the money back to Alice. 168 00:10:11,938 --> 00:10:15,761 And the great thing is that all those transactions that Alice signed along 169 00:10:15,761 --> 00:10:17,830 the way won't make to the blockchain. 170 00:10:17,830 --> 00:10:19,150 Bob doesn't have to sign them. 171 00:10:19,150 --> 00:10:20,890 They'll just get discarded. 172 00:10:21,920 --> 00:10:25,730 So technically all of these transactions are double-spends. 173 00:10:25,730 --> 00:10:29,615 So unlike the case with green addresses, where we were specifically trying to avoid 174 00:10:29,615 --> 00:10:33,890 double-spends with a strong guarantee, with this micropayment protocol, 175 00:10:33,890 --> 00:10:37,086 we're actually generating a huge amount of potential double-spends. 176 00:10:37,086 --> 00:10:41,820 Although in practice, if both parties are operating normally, 177 00:10:41,820 --> 00:10:47,630 Bob will never sign any transaction but the last one, in which case the blockchain 178 00:10:47,630 --> 00:10:52,730 won't actually see any attempt at a double-spend. 179 00:10:52,730 --> 00:10:56,380 Now there's one more detail here, if you stop and think for a second, 180 00:10:56,380 --> 00:10:57,940 which is somewhat tricky to deal with. 181 00:10:59,090 --> 00:11:02,440 What if Bob never signs the last transaction? 182 00:11:02,440 --> 00:11:06,210 He may just say, I'm happy to let the coins sit there in escrow forever, 183 00:11:06,210 --> 00:11:08,740 in which case maybe the coins wont move. 184 00:11:08,740 --> 00:11:12,700 But Alice will be out the full value that she paid at the beginning. 185 00:11:12,700 --> 00:11:17,310 So there's a very clever way to avoid this problem using a feature that I described 186 00:11:17,310 --> 00:11:20,640 earlier but haven't explained yet, which I'll need to introduce now. 187 00:11:20,640 --> 00:11:23,210 And that feature is called lock time. 188 00:11:25,800 --> 00:11:30,340 So to avoid this problem, before the micropayment protocol can even start, 189 00:11:30,340 --> 00:11:35,340 Alice and Bob will both sign a transaction which refunds all of Alice's money back to 190 00:11:35,340 --> 00:11:38,520 her but is locked until some time in the future. 191 00:11:39,670 --> 00:11:42,570 So before Alice signs the first transaction paying for the first 192 00:11:42,570 --> 00:11:46,780 minute of service, she's going to want to get this refund transaction from Bob and 193 00:11:46,780 --> 00:11:50,720 be able to hold that in her hand and know that if she makes it to time t and 194 00:11:50,720 --> 00:11:54,020 Bob hasn't signed any of the small transactions that Alice has sent, 195 00:11:55,100 --> 00:11:59,580 Alice can publish this transaction which refunds all of the money directly to her. 196 00:11:59,580 --> 00:12:04,220 So what does it mean when I said it's locked until time t? 197 00:12:04,220 --> 00:12:04,890 How do we do that? 198 00:12:06,460 --> 00:12:09,110 Well, you'll remember when we looked at the metadata in the bitcoin 199 00:12:09,110 --> 00:12:13,270 transactions that there was a lock_time parameter, which I had left unexplained. 200 00:12:15,400 --> 00:12:16,840 It's quite simple actually. 201 00:12:16,840 --> 00:12:21,140 If you specify any value other than zero for the lock_time, 202 00:12:21,140 --> 00:12:25,490 that tells miners, don't publish this transaction until this point in time. 203 00:12:25,490 --> 00:12:28,730 The transaction is invalid and can't be published 204 00:12:28,730 --> 00:12:33,530 until either a specific block number or a specific point in time, 205 00:12:33,530 --> 00:12:35,930 based on the timestamps that are being put in to blocks. 206 00:12:37,580 --> 00:12:40,540 So this is a way of preparing a transaction that can only 207 00:12:40,540 --> 00:12:43,380 be spent in the future if something else doesn't happen. 208 00:12:43,380 --> 00:12:46,780 And it works quite nicely in that micropayments protocol 209 00:12:46,780 --> 00:12:49,940 as a safety valve for Alice to know that if Bob never signs, 210 00:12:49,940 --> 00:12:51,610 eventually she'll be able to get her money back. 211 00:12:52,640 --> 00:12:55,770 So hopefully those examples have shown you that you can do some pretty neat stuff 212 00:12:55,770 --> 00:12:57,270 with Bitcoin scripts. 213 00:12:57,270 --> 00:13:02,300 Those are just three examples that are the most practical and simple to explain, but 214 00:13:02,300 --> 00:13:05,350 there are a lot of other things that people have looked into doing. 215 00:13:05,350 --> 00:13:09,120 One of them is multiplayer lotteries, which is a very complicated multi-step 216 00:13:09,120 --> 00:13:14,470 protocol with a lot of transactions with different lock times. 217 00:13:14,470 --> 00:13:16,310 There are escrows in case people cheat. 218 00:13:16,310 --> 00:13:20,450 But you can actually run a fair multi-party lottery over Bitcoin 219 00:13:20,450 --> 00:13:23,260 using just the scripting language, which is really neat. 220 00:13:24,920 --> 00:13:25,580 There are other things, 221 00:13:25,580 --> 00:13:28,240 like you can pay someone if they know the pre-image of a hash. 222 00:13:28,240 --> 00:13:31,280 So you can try to pay somebody to do some brute-force work for you. 223 00:13:31,280 --> 00:13:36,200 And there are a couple of neat protocols for different people to get their coins 224 00:13:36,200 --> 00:13:39,960 together and mix them so that it's harder to trace who owns which coin. 225 00:13:39,960 --> 00:13:43,969 And we'll talk about that a lot more in our lecture on anonymity. 226 00:13:44,970 --> 00:13:48,400 So the general term for contracts like this is smart contracts, 227 00:13:48,400 --> 00:13:52,440 which means that the contracts actually have some technical enforcement of 228 00:13:52,440 --> 00:13:57,190 something that use to be enforced through things like laws or courts of arbitration. 229 00:13:58,370 --> 00:14:01,360 So it's a really cool feature of bit coin that we can use scripts, and 230 00:14:01,360 --> 00:14:04,820 we can use miners, and we can use transaction validation 231 00:14:04,820 --> 00:14:08,760 to enforce things like escrow or the micropayment protocol. 232 00:14:08,760 --> 00:14:11,660 And you don't have to rely on any centralized authority to actually 233 00:14:11,660 --> 00:14:13,040 enforce these contracts. 234 00:14:14,450 --> 00:14:17,430 Now the whole field of smart contracts goes quite deep. 235 00:14:17,430 --> 00:14:20,300 There's a lot more smart contracts people would like to apply, 236 00:14:20,300 --> 00:14:24,660 a lot of which you unfortunately can't build with a Bitcoin script today. 237 00:14:24,660 --> 00:14:29,690 So the Bitcoin script is fairly limited in the types of things that you can address. 238 00:14:29,690 --> 00:14:33,420 There's a lot of smart contracts people wish they could build 239 00:14:33,420 --> 00:14:37,535 that either are impossible or nobody has come up with a way to do it yet. 240 00:14:37,535 --> 00:14:40,903 But you can do quite a few interesting smart contracts with the Bitcoin script.