1 00:00:01,240 --> 00:00:03,580 The following content is provided under a Creative 2 00:00:03,580 --> 00:00:04,970 Commons license. 3 00:00:04,970 --> 00:00:07,180 Your support will help MIT OpenCourseWare 4 00:00:07,180 --> 00:00:11,270 continue to offer high-quality educational resources for free. 5 00:00:11,270 --> 00:00:13,840 To make a donation or to view additional materials 6 00:00:13,840 --> 00:00:17,800 from hundreds of MIT courses, visit MIT OpenCourseWare 7 00:00:17,800 --> 00:00:18,680 at ocw.mit.edu. 8 00:00:23,360 --> 00:00:25,040 NEHA NARULA: OK, let's get started. 9 00:00:25,040 --> 00:00:28,740 I hope everybody had a great long weekend. 10 00:00:28,740 --> 00:00:31,760 So I'm teaching today, and today we're 11 00:00:31,760 --> 00:00:33,990 going to be talking about transactions. 12 00:00:33,990 --> 00:00:38,680 So just to recap where we've been so far, 13 00:00:38,680 --> 00:00:42,260 Tadge just sort of explained signatures in Bitcoin, 14 00:00:42,260 --> 00:00:46,598 in particular RSA and ECDSA, and told us a little bit 15 00:00:46,598 --> 00:00:47,390 about Merkle trees. 16 00:00:47,390 --> 00:00:50,600 And so these are some of the underlying primitives 17 00:00:50,600 --> 00:00:52,580 that we need to know about in order 18 00:00:52,580 --> 00:00:55,430 to understand how most of the blockchains today 19 00:00:55,430 --> 00:00:56,865 are constructed. 20 00:00:56,865 --> 00:00:59,240 So we've spent a bit of time talking about the underlying 21 00:00:59,240 --> 00:01:03,440 primitives, now let's start to put them together a little bit 22 00:01:03,440 --> 00:01:06,740 to understand what goes into a blockchain. 23 00:01:06,740 --> 00:01:09,623 So if you recall, this is a slide 24 00:01:09,623 --> 00:01:10,790 that Tadge has shown before. 25 00:01:10,790 --> 00:01:13,600 And I'm really sorry about this quadrant, but I don't know, 26 00:01:13,600 --> 00:01:15,560 I don't think I can control this individually. 27 00:01:15,560 --> 00:01:18,558 So we'll definitely post the slides of course, 28 00:01:18,558 --> 00:01:20,600 but let me know if something is really confusing. 29 00:01:20,600 --> 00:01:22,370 Just raise your hand. 30 00:01:22,370 --> 00:01:25,320 So this is something that you guys have seen before, 31 00:01:25,320 --> 00:01:27,980 and it's like a very sort of rough approximation 32 00:01:27,980 --> 00:01:29,840 of a hash chain. 33 00:01:29,840 --> 00:01:31,970 So what we have here is we have-- 34 00:01:31,970 --> 00:01:33,980 this doesn't actually show the previous, 35 00:01:33,980 --> 00:01:36,230 but what we have here is we have some message, 36 00:01:36,230 --> 00:01:38,930 we have a nonce, such that when you hash these three 37 00:01:38,930 --> 00:01:41,660 things together, you get this hash value, 38 00:01:41,660 --> 00:01:44,330 which has a certain number of leading zeros at the beginning. 39 00:01:44,330 --> 00:01:46,490 In this case, it's two leading zeros. 40 00:01:46,490 --> 00:01:48,800 And when we construct the next block, 41 00:01:48,800 --> 00:01:52,310 we implicitly point to this previous block 42 00:01:52,310 --> 00:01:57,860 by including that hash inside of this when we produce this hash. 43 00:01:57,860 --> 00:02:00,980 So note that there isn't actually 44 00:02:00,980 --> 00:02:03,590 a physical pointer or a memory address 45 00:02:03,590 --> 00:02:06,320 pointer type thing connecting these two things together. 46 00:02:06,320 --> 00:02:08,180 And note that this block does not actually 47 00:02:08,180 --> 00:02:11,600 contain the hash of itself. 48 00:02:11,600 --> 00:02:14,270 But we are sort of implicitly pointing to this 49 00:02:14,270 --> 00:02:18,650 by including the hash of this block in the following block. 50 00:02:18,650 --> 00:02:22,040 And so on over here-- again, this is a different message, 51 00:02:22,040 --> 00:02:24,140 a different nonce, and it includes 52 00:02:24,140 --> 00:02:27,170 the hash of this block instead of the one before. 53 00:02:27,170 --> 00:02:29,480 And by including the hash of this block, 54 00:02:29,480 --> 00:02:32,390 it's also implicitly including the hash of this block, 55 00:02:32,390 --> 00:02:34,020 because that's right here. 56 00:02:34,020 --> 00:02:38,210 And so what we're going to see is that if you change anything 57 00:02:38,210 --> 00:02:41,550 about the previous blocks in the blockchain-- for example, 58 00:02:41,550 --> 00:02:43,170 if you change this message-- 59 00:02:43,170 --> 00:02:47,065 then you're going to need to change the nonce in order 60 00:02:47,065 --> 00:02:48,440 to get the hash to compute right. 61 00:02:48,440 --> 00:02:49,940 That's going to be a different hash. 62 00:02:49,940 --> 00:02:52,740 And that change is going to trickle down 63 00:02:52,740 --> 00:02:53,990 through the entire blockchain. 64 00:02:53,990 --> 00:02:55,740 And so that's what makes these things what 65 00:02:55,740 --> 00:02:59,510 we call tamper-proof, the fact that there are these hashes, 66 00:02:59,510 --> 00:03:02,120 these hashes are collision-resistant. 67 00:03:02,120 --> 00:03:08,600 And so it's very difficult. You can't change what's in the past 68 00:03:08,600 --> 00:03:12,690 without having it reflected in the future. 69 00:03:12,690 --> 00:03:14,870 So now let's go into a little bit more 70 00:03:14,870 --> 00:03:19,730 detail about exactly what this message thing is. 71 00:03:19,730 --> 00:03:21,872 We've talked about the previous hash pointers, 72 00:03:21,872 --> 00:03:23,330 we've talked about the nonce, we've 73 00:03:23,330 --> 00:03:24,560 talked about proof of work. 74 00:03:24,560 --> 00:03:26,840 But what actually goes inside of a block? 75 00:03:26,840 --> 00:03:28,658 Well, we have this general-- we've 76 00:03:28,658 --> 00:03:30,200 kind of been alluding to it, but what 77 00:03:30,200 --> 00:03:32,510 goes inside a block are transactions. 78 00:03:32,510 --> 00:03:34,580 We're trying to build a payment system here. 79 00:03:34,580 --> 00:03:38,270 So what do we need to have in a transaction? 80 00:03:38,270 --> 00:03:39,770 What should a transaction look like? 81 00:03:42,500 --> 00:03:43,377 Yes. 82 00:03:43,377 --> 00:03:44,840 AUDIENCE: Inputs and outputs. 83 00:03:44,840 --> 00:03:46,640 NEHA NARULA: OK, inputs and outputs. 84 00:03:46,640 --> 00:03:49,160 Maybe even like a higher level here, semantically, 85 00:03:49,160 --> 00:03:52,524 what do we want in a transaction? 86 00:03:52,524 --> 00:03:53,460 Yep. 87 00:03:53,460 --> 00:03:56,190 AUDIENCE: A sender, a receiver, an amount, like a message. 88 00:03:56,190 --> 00:03:59,180 NEHA NARULA: OK, a sender, a receiver, an amount. 89 00:03:59,180 --> 00:04:00,368 Anybody else? 90 00:04:00,368 --> 00:04:02,240 AUDIENCE: Transaction ID. 91 00:04:02,240 --> 00:04:05,270 NEHA NARULA: OK, an ID, some way of referencing it. 92 00:04:05,270 --> 00:04:07,150 Anybody else. 93 00:04:07,150 --> 00:04:07,785 Yep. 94 00:04:07,785 --> 00:04:11,260 AUDIENCE: A proof that it's a legit transaction. 95 00:04:11,260 --> 00:04:14,520 NEHA NARULA: A proof that it's a legit transaction, right, 96 00:04:14,520 --> 00:04:15,310 exactly. 97 00:04:15,310 --> 00:04:18,130 So what we need is those things that you guys just said. 98 00:04:18,130 --> 00:04:20,529 We need to know the amount, how much of this coin 99 00:04:20,529 --> 00:04:23,620 we're transferring, we need to know where it's coming from, 100 00:04:23,620 --> 00:04:26,740 and in particular we need an authorization of some sort 101 00:04:26,740 --> 00:04:29,792 that that user actually authorized the spend, 102 00:04:29,792 --> 00:04:31,000 and we need who we're paying. 103 00:04:31,000 --> 00:04:33,190 And so unfortunately this is in the dark part, 104 00:04:33,190 --> 00:04:37,240 but this is sort of a little rough sketch of a transaction. 105 00:04:37,240 --> 00:04:40,900 And we have Alice who's spending $5.00 to Bob, 106 00:04:40,900 --> 00:04:43,915 and we have this authorization here. 107 00:04:43,915 --> 00:04:46,540 And this authorization, given we just learned about signatures, 108 00:04:46,540 --> 00:04:48,670 signatures are a great way to do authorization 109 00:04:48,670 --> 00:04:52,030 because it's something that only Alice can produce. 110 00:04:52,030 --> 00:04:53,650 So I don't know if you can see this, 111 00:04:53,650 --> 00:04:55,067 but there are question marks here. 112 00:04:55,067 --> 00:04:58,570 So what should Alice sign to show that she 113 00:04:58,570 --> 00:05:00,162 authorized this transaction? 114 00:05:00,162 --> 00:05:01,870 What do you think would be a good thing-- 115 00:05:01,870 --> 00:05:04,750 what is a good message for her to sign 116 00:05:04,750 --> 00:05:08,890 for her to indicate her authority, her desire 117 00:05:08,890 --> 00:05:11,840 to produce this transaction and spend her funds? 118 00:05:11,840 --> 00:05:13,822 AUDIENCE: Private key. 119 00:05:13,822 --> 00:05:15,030 NEHA NARULA: Her private key? 120 00:05:15,030 --> 00:05:15,910 AUDIENCE: Yeah. 121 00:05:15,910 --> 00:05:17,785 NEHA NARULA: She should sign her private key? 122 00:05:17,785 --> 00:05:18,397 OK. 123 00:05:18,397 --> 00:05:20,230 AUDIENCE: [INAUDIBLE] the whole transaction. 124 00:05:20,230 --> 00:05:24,220 NEHA NARULA: The whole transaction, OK. 125 00:05:24,220 --> 00:05:26,270 So let's talk about signing the private key. 126 00:05:26,270 --> 00:05:29,710 Let's say that she did sign her private key. 127 00:05:29,710 --> 00:05:32,043 The problem with a signature is that, in order 128 00:05:32,043 --> 00:05:33,460 to tell if the signature is valid, 129 00:05:33,460 --> 00:05:35,290 you need the thing that you signed. 130 00:05:35,290 --> 00:05:38,038 So she would have to include her private key, which would then 131 00:05:38,038 --> 00:05:40,330 share her private key with everyone, which isn't really 132 00:05:40,330 --> 00:05:42,790 a good way for her to use her public and private key. 133 00:05:42,790 --> 00:05:45,840 She could certainly sign the transaction. 134 00:05:45,840 --> 00:05:48,040 And the nice thing about signing the transaction-- 135 00:05:48,040 --> 00:05:50,680 this is all blue, indicating that she's signing it-- 136 00:05:50,680 --> 00:05:54,340 is that she's signing all three of these things as well. 137 00:05:54,340 --> 00:05:57,730 She's saying, I want to pay Bob, I want to pay Bob $5. 138 00:05:57,730 --> 00:06:02,390 Now what's the problem with signing the transaction? 139 00:06:02,390 --> 00:06:02,890 Yes. 140 00:06:02,890 --> 00:06:05,130 AUDIENCE: Couldn't you just keep using it if you were Bob? 141 00:06:05,130 --> 00:06:07,380 NEHA NARULA: So that is an excellent point-- you could 142 00:06:07,380 --> 00:06:08,730 keep using it if you were Bob. 143 00:06:08,730 --> 00:06:10,590 And we'll get into that a little bit later. 144 00:06:10,590 --> 00:06:13,410 But another problem here is, the way 145 00:06:13,410 --> 00:06:15,898 that I've shown it right now, she's signing the signature. 146 00:06:15,898 --> 00:06:17,940 The signature is kind of part of the transaction. 147 00:06:17,940 --> 00:06:20,502 And so you want to make sure that you're not-- 148 00:06:20,502 --> 00:06:21,960 when you sign a transaction, you're 149 00:06:21,960 --> 00:06:24,120 signing everything but the signature, right, 150 00:06:24,120 --> 00:06:26,277 because you can't produce the signature. 151 00:06:26,277 --> 00:06:28,110 You can't sign the signature without knowing 152 00:06:28,110 --> 00:06:29,117 what the signature is. 153 00:06:29,117 --> 00:06:31,200 It would be like a whole new type of proof of work 154 00:06:31,200 --> 00:06:32,040 on the transaction. 155 00:06:32,040 --> 00:06:33,540 So I don't know if you can see this, 156 00:06:33,540 --> 00:06:36,030 but this says transaction minus signature. 157 00:06:36,030 --> 00:06:39,630 And in fact, we can even make that a little bit easier 158 00:06:39,630 --> 00:06:43,170 by turning that into a hash of the transaction, 159 00:06:43,170 --> 00:06:44,670 not including the signature. 160 00:06:44,670 --> 00:06:46,440 Because that sort of brings the message 161 00:06:46,440 --> 00:06:49,090 down to a smaller thing. 162 00:06:49,090 --> 00:06:52,440 And from what we know about hash functions you can't really, 163 00:06:52,440 --> 00:06:57,033 given a message and a hash of that message, 164 00:06:57,033 --> 00:06:58,950 it's difficult to produce another message that 165 00:06:58,950 --> 00:07:00,210 would hash to the same thing. 166 00:07:00,210 --> 00:07:03,120 So this hash serves as kind of an identifier 167 00:07:03,120 --> 00:07:04,870 for the transaction as a whole. 168 00:07:04,870 --> 00:07:08,250 In fact, Bitcoin uses the hash of this as the transaction ID. 169 00:07:08,250 --> 00:07:10,410 So this is how we refer to transactions. 170 00:07:10,410 --> 00:07:12,060 And it's a nice small thing to sign, 171 00:07:12,060 --> 00:07:18,120 which indicates Alice's intent to spend her funds. 172 00:07:18,120 --> 00:07:21,690 So one thing that I kind of want to go into a little bit 173 00:07:21,690 --> 00:07:24,060 is that there's a couple different ways for thinking 174 00:07:24,060 --> 00:07:26,370 about transactions, and what transactions actually 175 00:07:26,370 --> 00:07:28,200 look like, and how they're stored, 176 00:07:28,200 --> 00:07:30,420 and how we sort of specify coins. 177 00:07:30,420 --> 00:07:35,070 And the most natural model, to me, anyway, not to everybody, 178 00:07:35,070 --> 00:07:37,920 perhaps, is what I call the account-based model. 179 00:07:37,920 --> 00:07:40,350 So it's kind of like what we were doing before, 180 00:07:40,350 --> 00:07:41,910 when we saw the banks, and we were 181 00:07:41,910 --> 00:07:43,800 talking about banks keeping track 182 00:07:43,800 --> 00:07:45,368 of how much funds people have. 183 00:07:45,368 --> 00:07:47,910 And this is sort of how you and I might think of our own bank 184 00:07:47,910 --> 00:07:48,630 accounts. 185 00:07:48,630 --> 00:07:50,838 I think in my bank account as having a certain amount 186 00:07:50,838 --> 00:07:51,930 of funds in it. 187 00:07:51,930 --> 00:07:54,000 And so in the account-based model, 188 00:07:54,000 --> 00:07:57,840 users have certain amounts or balances associated 189 00:07:57,840 --> 00:08:00,120 with their usernames. 190 00:08:00,120 --> 00:08:04,380 And when a transaction comes in, like Alice wants to give $5.00 191 00:08:04,380 --> 00:08:07,890 to Bob, then what might happen is that the nodes 192 00:08:07,890 --> 00:08:11,040 in the network which are all maintaining, in a unified way, 193 00:08:11,040 --> 00:08:13,320 this balance sheet, will end up saying, OK, 194 00:08:13,320 --> 00:08:15,660 Alice had 10 and Bob had zero. 195 00:08:15,660 --> 00:08:17,340 Alice wants to give $5.00 to Bob. 196 00:08:17,340 --> 00:08:20,370 Let's subtract $5.00 from Alice's account and give it 197 00:08:20,370 --> 00:08:21,090 to Bob. 198 00:08:21,090 --> 00:08:23,160 And so what the nodes would do here 199 00:08:23,160 --> 00:08:25,740 to see if this transaction was valid would be 200 00:08:25,740 --> 00:08:27,600 they would check the signature to make sure 201 00:08:27,600 --> 00:08:30,780 that Alice actually authorized this transaction, 202 00:08:30,780 --> 00:08:32,880 and they would also make sure that Alice 203 00:08:32,880 --> 00:08:34,590 had the funds to spend. 204 00:08:34,590 --> 00:08:38,460 And in the account-based model, the way 205 00:08:38,460 --> 00:08:40,740 that you check to see if Alice has the funds 206 00:08:40,740 --> 00:08:42,990 to spend as you literally look at her balance, 207 00:08:42,990 --> 00:08:45,090 and you look at the amount she wants to spend, 208 00:08:45,090 --> 00:08:48,150 and you make sure that if she spends that amount, 209 00:08:48,150 --> 00:08:50,160 the balance won't go below zero. 210 00:08:50,160 --> 00:08:54,180 So this is actually the model that Ethereum uses. 211 00:08:54,180 --> 00:08:57,450 It's not the model that Bitcoin uses. 212 00:08:57,450 --> 00:08:59,520 So just sort of to summarize, you 213 00:08:59,520 --> 00:09:01,690 store a list of accounts and balances, 214 00:09:01,690 --> 00:09:05,580 a transaction is valid if there is a balance in the account, 215 00:09:05,580 --> 00:09:07,890 and then when a transaction is processed, 216 00:09:07,890 --> 00:09:11,400 you debit the sender and credit the receiver-- so 217 00:09:11,400 --> 00:09:15,140 very straightforward. 218 00:09:15,140 --> 00:09:17,970 So like I said, this is a way Ethereum works, 219 00:09:17,970 --> 00:09:19,950 and it's a little bit more natural, 220 00:09:19,950 --> 00:09:21,240 I think, to think about. 221 00:09:21,240 --> 00:09:23,560 But this is not the way Bitcoin works, actually. 222 00:09:23,560 --> 00:09:25,680 Bitcoin has a very different model 223 00:09:25,680 --> 00:09:28,770 of coins and of transactions. 224 00:09:28,770 --> 00:09:33,210 And I think-- when I was learning about how Bitcoin 225 00:09:33,210 --> 00:09:35,490 worked and how Ethereum worked, I 226 00:09:35,490 --> 00:09:37,410 found Bitcoin's model a little bit unnatural 227 00:09:37,410 --> 00:09:40,350 until I went through this exercise of thinking 228 00:09:40,350 --> 00:09:42,700 about something called replay attacks. 229 00:09:42,700 --> 00:09:45,810 And this is what [? Issan ?] mentioned earlier, which 230 00:09:45,810 --> 00:09:47,940 is when you have this transaction, 231 00:09:47,940 --> 00:09:51,750 and you send it to the network, and the network 232 00:09:51,750 --> 00:09:54,380 processes the transaction and debits Alice and credits 233 00:09:54,380 --> 00:09:59,280 Bob, what is to prevent a malicious agent from noticing 234 00:09:59,280 --> 00:10:02,550 that transaction and rebroadcasting it again 235 00:10:02,550 --> 00:10:05,610 to the network, so basically repeatedly debiting 236 00:10:05,610 --> 00:10:09,090 Alice until she doesn't have any funds left. 237 00:10:09,090 --> 00:10:13,050 So can you guys think of a way to maybe get around this? 238 00:10:13,050 --> 00:10:13,920 What would you do? 239 00:10:13,920 --> 00:10:17,480 How would you prevent this replay attack? 240 00:10:17,480 --> 00:10:18,060 Yeah. 241 00:10:18,060 --> 00:10:21,770 AUDIENCE: She can add a specific ID to the time, for instance, 242 00:10:21,770 --> 00:10:25,490 [INAUDIBLE] 243 00:10:25,490 --> 00:10:28,150 NEHA NARULA: So one thing is adding a time, sure. 244 00:10:28,150 --> 00:10:31,780 Time is a little bit tricky because of the nature 245 00:10:31,780 --> 00:10:34,190 of the system. 246 00:10:34,190 --> 00:10:36,370 But a time is a pretty good idea. 247 00:10:36,370 --> 00:10:38,800 A unique number of some kind certainly 248 00:10:38,800 --> 00:10:41,920 would help, because that way if you saw a transaction 249 00:10:41,920 --> 00:10:44,890 with the same number, then you'd know, 250 00:10:44,890 --> 00:10:46,702 OK, this transaction has been seen before. 251 00:10:46,702 --> 00:10:47,410 This is a repeat. 252 00:10:47,410 --> 00:10:48,910 This is a rebroadcast. 253 00:10:48,910 --> 00:10:52,160 This is not something I should process. 254 00:10:52,160 --> 00:10:55,930 So Ethereum actually does something like this. 255 00:10:55,930 --> 00:11:00,580 There is this number included in every transaction. 256 00:11:00,580 --> 00:11:03,100 But the tricky part about the way that Ethereum does this-- 257 00:11:03,100 --> 00:11:04,690 and we're going to learn more about Ethereum later 258 00:11:04,690 --> 00:11:06,610 on in the course, we're going to have a guest lecturer come 259 00:11:06,610 --> 00:11:07,990 in and teach us about that-- 260 00:11:07,990 --> 00:11:11,500 is that it requires you to keep track of all of the numbers 261 00:11:11,500 --> 00:11:12,220 you've seen. 262 00:11:12,220 --> 00:11:15,760 And you have to do this per user. 263 00:11:15,760 --> 00:11:17,500 And so all the nodes in the network 264 00:11:17,500 --> 00:11:20,350 have to keep track of all of the nonces 265 00:11:20,350 --> 00:11:23,080 that they've seen per user. 266 00:11:23,080 --> 00:11:26,710 And so if a user uses Ethereum once and then goes away, 267 00:11:26,710 --> 00:11:29,530 all of the nodes have to keep that state forever, 268 00:11:29,530 --> 00:11:32,590 essentially, just in case someone 269 00:11:32,590 --> 00:11:35,230 comes back and rebroadcasts another transaction. 270 00:11:35,230 --> 00:11:38,940 So Bitcoin, like I said, and I keep saying, does something. 271 00:11:38,940 --> 00:11:41,680 And there's nothing wrong with this model. 272 00:11:41,680 --> 00:11:43,180 We'll sort of compare and contrast. 273 00:11:43,180 --> 00:11:44,890 Like I said, it's what Ethereum uses. 274 00:11:44,890 --> 00:11:47,182 But I think that this is part of the motivation for why 275 00:11:47,182 --> 00:11:49,240 Bitcoin was designed the way that it was. 276 00:11:49,240 --> 00:11:53,200 And so Bitcoin uses this idea called unspent transaction 277 00:11:53,200 --> 00:11:54,220 outputs. 278 00:11:54,220 --> 00:11:57,220 So you'll notice, over here, we don't have 279 00:11:57,220 --> 00:12:00,430 any notion of a coin, per se. 280 00:12:00,430 --> 00:12:01,900 There are just amounts, and amounts 281 00:12:01,900 --> 00:12:03,340 are debited and credited. 282 00:12:03,340 --> 00:12:06,520 And if Alice spends to Bob, and Alice spends to Carol, 283 00:12:06,520 --> 00:12:08,380 and they come in different orders, 284 00:12:08,380 --> 00:12:10,180 either one could happen first. 285 00:12:10,180 --> 00:12:13,180 There's no notion of, like, Carol gets these coins 286 00:12:13,180 --> 00:12:14,860 and Bob gets these coins. 287 00:12:14,860 --> 00:12:16,570 But Bitcoin is a little bit different. 288 00:12:16,570 --> 00:12:18,860 All coins are not the same. 289 00:12:18,860 --> 00:12:21,490 And when you're spending, you don't just 290 00:12:21,490 --> 00:12:27,083 include an amount you refer back to the specific coin 291 00:12:27,083 --> 00:12:28,000 that you are spending. 292 00:12:30,970 --> 00:12:35,410 So you actually have to refer to a coin in order to spend it. 293 00:12:35,410 --> 00:12:38,050 And this is the really weird part-- 294 00:12:38,050 --> 00:12:42,580 coins are created, destroyed, consumed, 295 00:12:42,580 --> 00:12:47,780 and then new coins are created every transaction. 296 00:12:47,780 --> 00:12:51,170 So whenever you spend your bitcoin, 297 00:12:51,170 --> 00:12:53,630 you have to spend it in its entirety. 298 00:12:53,630 --> 00:12:57,695 That bitcoin is then destroyed, and new coins are created. 299 00:13:01,225 --> 00:13:03,600 And there's a rule, in the entire system, that a coin can 300 00:13:03,600 --> 00:13:04,485 only be spent once. 301 00:13:08,580 --> 00:13:11,993 So we'll go into exactly what that 302 00:13:11,993 --> 00:13:13,410 looks like in a transaction, but I 303 00:13:13,410 --> 00:13:15,300 want to know if there are any questions about that 304 00:13:15,300 --> 00:13:16,370 first, about that idea. 305 00:13:16,370 --> 00:13:16,670 Yes. 306 00:13:16,670 --> 00:13:18,003 AUDIENCE: Aren't coins fungible? 307 00:13:18,003 --> 00:13:21,363 So what if you spend maybe a little bit of a coin 308 00:13:21,363 --> 00:13:23,248 on some candy or something? 309 00:13:23,248 --> 00:13:24,790 NEHA NARULA: That's a great question. 310 00:13:24,790 --> 00:13:27,480 So the question is, aren't coins fungible? 311 00:13:27,480 --> 00:13:29,580 So first of all, coins aren't fungible, actually. 312 00:13:29,580 --> 00:13:31,630 They are very specific. 313 00:13:31,630 --> 00:13:33,300 You can see a coin. 314 00:13:33,300 --> 00:13:37,140 But the question about what happens 315 00:13:37,140 --> 00:13:40,410 if you only want to spend part of a coin is a great question. 316 00:13:40,410 --> 00:13:42,750 And we'll see how you do that in the way 317 00:13:42,750 --> 00:13:44,530 that the transaction is constructed. 318 00:13:44,530 --> 00:13:47,310 But the short answer is, if you want to spend part of a coin, 319 00:13:47,310 --> 00:13:48,840 you have to spend the whole coin, 320 00:13:48,840 --> 00:13:51,240 spend the part that you want to someone else, 321 00:13:51,240 --> 00:13:53,220 and then spend the rest of it back to yourself, 322 00:13:53,220 --> 00:13:56,810 creating a new coin in the process. 323 00:13:56,810 --> 00:13:57,570 Yes. 324 00:13:57,570 --> 00:13:59,810 AUDIENCE: Coins are consumed, and for the new ones, 325 00:13:59,810 --> 00:14:02,000 who will own the new ones? 326 00:14:02,000 --> 00:14:05,450 NEHA NARULA: Whoever you say should own the new ones when-- 327 00:14:05,450 --> 00:14:09,710 a transaction consumes coins and creates new ones as payment. 328 00:14:09,710 --> 00:14:13,280 And as the creator of that transaction, as the spender, 329 00:14:13,280 --> 00:14:15,170 I will decide who should get the new coins. 330 00:14:15,170 --> 00:14:17,326 And I'll show you the details of this in a moment. 331 00:14:17,326 --> 00:14:18,868 AUDIENCE: You're saying coins, but do 332 00:14:18,868 --> 00:14:22,505 you actually mean the full balance in the account, right? 333 00:14:22,505 --> 00:14:24,880 NEHA NARULA: No, not exactly full balance in the account. 334 00:14:24,880 --> 00:14:27,528 So let's go a little bit further to look 335 00:14:27,528 --> 00:14:28,570 at what's happening here. 336 00:14:28,570 --> 00:14:31,280 Because Bitcoin doesn't actually keep track of balances. 337 00:14:31,280 --> 00:14:34,630 So let's take a look at what a transaction actually 338 00:14:34,630 --> 00:14:35,950 looks like. 339 00:14:35,950 --> 00:14:39,190 So a transaction has many different parts, 340 00:14:39,190 --> 00:14:41,200 but we're going to focus on two parts, which 341 00:14:41,200 --> 00:14:43,180 is the inputs and outputs. 342 00:14:43,180 --> 00:14:44,770 And here I'm showing a transaction 343 00:14:44,770 --> 00:14:48,070 with one input and one output. 344 00:14:48,070 --> 00:14:52,240 Now, an input actually refers back 345 00:14:52,240 --> 00:14:55,060 to another transaction's output. 346 00:14:55,060 --> 00:14:58,060 So let's assume-- and we'll get into how this is done later-- 347 00:14:58,060 --> 00:15:01,690 but let's assume that there are coins in the system. 348 00:15:01,690 --> 00:15:04,360 Let's just assume that some coins have been created out 349 00:15:04,360 --> 00:15:06,130 of nowhere. 350 00:15:06,130 --> 00:15:09,820 Let's say, in particular, that maybe 12.5 coins have 351 00:15:09,820 --> 00:15:11,230 been created out of nowhere. 352 00:15:11,230 --> 00:15:13,540 And so there's a transaction that 353 00:15:13,540 --> 00:15:16,360 outputs 12.5 coins to Alice. 354 00:15:16,360 --> 00:15:18,460 And Alice wants to spend those coins. 355 00:15:18,460 --> 00:15:21,610 And so Alice would create a new transaction 356 00:15:21,610 --> 00:15:24,730 that points back to the transaction where 357 00:15:24,730 --> 00:15:26,470 she received those coins. 358 00:15:26,470 --> 00:15:28,570 And the way that she points back to that 359 00:15:28,570 --> 00:15:32,800 is using the transaction ID of the previous transaction, which 360 00:15:32,800 --> 00:15:35,420 you remember is just the hash, the index, 361 00:15:35,420 --> 00:15:39,100 meaning which output of the previous transaction she's 362 00:15:39,100 --> 00:15:41,320 intending to spend, and something 363 00:15:41,320 --> 00:15:45,640 called a scriptSig, which is her authorization 364 00:15:45,640 --> 00:15:48,560 to spend that output. 365 00:15:48,560 --> 00:15:52,600 So this is how Alice refers back to the output 366 00:15:52,600 --> 00:15:53,500 she wants to spend. 367 00:15:53,500 --> 00:15:58,600 And when I say coin, I'm referring to outputs. 368 00:15:58,600 --> 00:16:02,740 So outputs can be for different amounts. 369 00:16:02,740 --> 00:16:03,940 You could create an output-- 370 00:16:03,940 --> 00:16:08,200 you could spend 12.5 coins and create many different outputs 371 00:16:08,200 --> 00:16:11,510 of many different amounts, and send them to different people. 372 00:16:11,510 --> 00:16:13,420 if you wanted to. 373 00:16:13,420 --> 00:16:15,990 So this is a format of a transaction. 374 00:16:15,990 --> 00:16:18,130 There is an input which points back 375 00:16:18,130 --> 00:16:20,200 to a previous transaction's output 376 00:16:20,200 --> 00:16:21,880 that you're intending to spend. 377 00:16:21,880 --> 00:16:23,980 And then the way that you spend it-- 378 00:16:23,980 --> 00:16:25,960 you're consuming that output, essentially, 379 00:16:25,960 --> 00:16:27,820 by pointing back to it with this input-- 380 00:16:27,820 --> 00:16:31,337 the way that you spend it by producing a new output. 381 00:16:31,337 --> 00:16:32,920 And again, this transaction isn't just 382 00:16:32,920 --> 00:16:35,410 one input and one output, it could have many. 383 00:16:35,410 --> 00:16:38,530 And the output that you produce has something 384 00:16:38,530 --> 00:16:40,540 called a scriptPubKey. 385 00:16:40,540 --> 00:16:42,880 What the scriptPubKey is, the scriptPubKey 386 00:16:42,880 --> 00:16:46,990 is a way of specifying the conditions under which 387 00:16:46,990 --> 00:16:49,860 this output can be redeemed. 388 00:16:49,860 --> 00:16:54,940 So in its simplest sense, you might have the scriptSig merely 389 00:16:54,940 --> 00:16:58,290 be a signature, just Alice's signature, saying, 390 00:16:58,290 --> 00:17:00,000 I have the right to spend this. 391 00:17:00,000 --> 00:17:03,660 And if Alice is spending to Bob, then maybe the scriptPubKey 392 00:17:03,660 --> 00:17:06,329 would actually just be Bob's public key. 393 00:17:06,329 --> 00:17:08,550 And the implied meaning there would 394 00:17:08,550 --> 00:17:10,619 be, anyone who could produce the signature 395 00:17:10,619 --> 00:17:14,130 of the corresponding private key with that public key 396 00:17:14,130 --> 00:17:15,690 could then spend this output. 397 00:17:18,619 --> 00:17:22,099 One thing is that these two things together-- 398 00:17:22,099 --> 00:17:24,260 the previous transaction ID and the index-- 399 00:17:24,260 --> 00:17:27,780 serves to uniquely identify an output. 400 00:17:27,780 --> 00:17:32,060 So these two things uniquely identify some money to spend. 401 00:17:34,640 --> 00:17:37,880 And the value that's specified in the output 402 00:17:37,880 --> 00:17:40,850 is actually specified in something called Satoshis, 403 00:17:40,850 --> 00:17:43,430 and there are 10 to the eighth Satoshis in one bitcoin. 404 00:17:43,430 --> 00:17:45,790 So the value doesn't have any decimal places in it. 405 00:17:45,790 --> 00:17:47,380 It is always an integer. 406 00:17:47,380 --> 00:17:53,090 And output is what I'm referring to when I say the word, coin. 407 00:17:53,090 --> 00:17:56,450 So, questions on this sort of general setup. 408 00:17:59,680 --> 00:18:00,350 Yes. 409 00:18:00,350 --> 00:18:02,580 AUDIENCE: Can you talk about index [INAUDIBLE] 410 00:18:02,580 --> 00:18:03,820 NEHA NARULA: Sure. 411 00:18:03,820 --> 00:18:05,680 OK, the index is-- 412 00:18:05,680 --> 00:18:08,290 remember how I said there could be multiple outputs? 413 00:18:08,290 --> 00:18:10,628 The index simply refers to which output 414 00:18:10,628 --> 00:18:12,670 in the previous transaction you're talking about. 415 00:18:15,987 --> 00:18:17,320 Was there a question back there? 416 00:18:17,320 --> 00:18:17,820 Yeah. 417 00:18:17,820 --> 00:18:20,110 AUDIENCE: Yeah, I'm a little bit confused about the-- 418 00:18:20,110 --> 00:18:23,872 So you have one input that can generate several outputs? 419 00:18:23,872 --> 00:18:24,580 NEHA NARULA: Yes. 420 00:18:24,580 --> 00:18:25,690 AUDIENCE: Can you provide an example? 421 00:18:25,690 --> 00:18:27,010 NEHA NARULA: Sure, yes. 422 00:18:27,010 --> 00:18:28,985 We'll get to that in a moment, actually. 423 00:18:28,985 --> 00:18:30,860 But maybe I could just draw one on the board. 424 00:18:40,270 --> 00:18:42,340 So you could certainly have a transaction 425 00:18:42,340 --> 00:18:45,730 that has multiple outputs. 426 00:18:45,730 --> 00:18:49,410 And so this input here would refer back 427 00:18:49,410 --> 00:18:52,080 to some previous transaction's outputs. 428 00:18:55,710 --> 00:19:01,360 And let's say that this was, for example, 20 bitcoin. 429 00:19:01,360 --> 00:19:05,920 Then this needs to consume 20 bitcoin. 430 00:19:05,920 --> 00:19:08,577 And it can spread that 20 bitcoin out in any way 431 00:19:08,577 --> 00:19:09,160 that it wants. 432 00:19:09,160 --> 00:19:10,910 And there are some details here that we're 433 00:19:10,910 --> 00:19:12,320 going to get to in a moment. 434 00:19:12,320 --> 00:19:14,140 But basically, you have that 20 here. 435 00:19:14,140 --> 00:19:18,010 You could send five here, 10 here, five here. 436 00:19:18,010 --> 00:19:21,640 And each of these outputs would have its own scriptPubKey, 437 00:19:21,640 --> 00:19:24,490 its own rules for how to redeem it. 438 00:19:24,490 --> 00:19:26,640 And each output has its own amount. 439 00:19:31,790 --> 00:19:32,290 Yep. 440 00:19:32,290 --> 00:19:33,720 TADGE DRYJA: It's also possible with multiple inputs 441 00:19:33,720 --> 00:19:34,220 [INAUDIBLE] 442 00:19:34,220 --> 00:19:35,940 NEHA NARULA: Yes. 443 00:19:35,940 --> 00:19:36,540 Yes. 444 00:19:36,540 --> 00:19:39,310 AUDIENCE: So where does the name, chain, come from? 445 00:19:39,310 --> 00:19:41,410 Is it more like a tree, or is it-- 446 00:19:41,410 --> 00:19:43,480 NEHA NARULA: That's a good question. 447 00:19:43,480 --> 00:19:47,770 So if you go back to the slide where I sort of was showing-- 448 00:19:47,770 --> 00:19:51,793 this is where the name, chain, comes from, here. 449 00:19:51,793 --> 00:19:52,520 [CHUCKLING] 450 00:19:52,520 --> 00:19:54,280 So what we're talking about right now 451 00:19:54,280 --> 00:19:57,250 is what goes inside each block. 452 00:19:57,250 --> 00:19:59,860 And what goes inside each block are transactions. 453 00:19:59,860 --> 00:20:02,320 So for the moment, you can pretend like each block only 454 00:20:02,320 --> 00:20:05,410 has one transaction in it, but a block 455 00:20:05,410 --> 00:20:07,000 can contain a set of transactions. 456 00:20:07,000 --> 00:20:09,760 But the chain part comes from how we actually 457 00:20:09,760 --> 00:20:11,860 chain these blocks of transactions together. 458 00:20:17,590 --> 00:20:21,370 So let's talk about scriptSigs and scriptPubKeys a little bit 459 00:20:21,370 --> 00:20:22,200 more. 460 00:20:22,200 --> 00:20:27,020 So scriptPubKeys, like I said, are in the outputs. 461 00:20:27,020 --> 00:20:29,480 And you can think of them as predicates. 462 00:20:29,480 --> 00:20:32,380 So scriptPubKeys specify a predicate 463 00:20:32,380 --> 00:20:36,998 on how someone can redeem this output. 464 00:20:36,998 --> 00:20:39,290 OK, so remember a transaction can have multiple inputs, 465 00:20:39,290 --> 00:20:40,640 multiple outputs. 466 00:20:40,640 --> 00:20:44,370 Each output has its own scriptPubKey. 467 00:20:44,370 --> 00:20:47,890 scriptSigs, which are in the inputs, 468 00:20:47,890 --> 00:20:50,630 helps satisfy the predicate that's 469 00:20:50,630 --> 00:20:53,360 specified in the scriptPubKey. 470 00:20:53,360 --> 00:21:02,330 So we would have a scriptPubKey here, And. 471 00:21:02,330 --> 00:21:03,770 We would have a scriptSig here. 472 00:21:06,380 --> 00:21:10,730 And this scriptSig, if this is a valid transaction, 473 00:21:10,730 --> 00:21:14,630 would explain how to satisfy the scriptPubKey. 474 00:21:14,630 --> 00:21:17,870 So the scriptPubKey would set up a predicate on the output. 475 00:21:17,870 --> 00:21:20,510 The most common predicate is, produce 476 00:21:20,510 --> 00:21:26,580 a signature and a public key that satisfies this hash. 477 00:21:26,580 --> 00:21:29,340 And the scriptSig would provide the information 478 00:21:29,340 --> 00:21:31,333 necessary to satisfy that predicate. 479 00:21:34,580 --> 00:21:38,420 So what does it mean to have money in this system? 480 00:21:38,420 --> 00:21:40,795 What does it mean to be able to spend money? 481 00:21:40,795 --> 00:21:42,170 What does it mean for Alice to be 482 00:21:42,170 --> 00:21:44,000 able to transfer money to Bob? 483 00:21:44,000 --> 00:21:46,970 It means Alice knows some information that 484 00:21:46,970 --> 00:21:50,660 allows her to produce a satisfying scriptSig 485 00:21:50,660 --> 00:21:52,820 for some outputs out there. 486 00:21:52,820 --> 00:21:55,610 That's what having money means. 487 00:21:55,610 --> 00:21:56,810 It's not an account balance. 488 00:22:00,970 --> 00:22:02,510 So questions on that? 489 00:22:05,350 --> 00:22:07,620 Because it's a little non-intuitive. 490 00:22:07,620 --> 00:22:09,270 But the important thing to note here 491 00:22:09,270 --> 00:22:12,360 is the nodes in the Bitcoin network 492 00:22:12,360 --> 00:22:15,630 are not keeping track of how much money you have. 493 00:22:15,630 --> 00:22:18,540 It's your job to keep track of how much money you have, 494 00:22:18,540 --> 00:22:19,560 or a wallet's job. 495 00:22:19,560 --> 00:22:21,560 And we'll talk more about wallets later. 496 00:22:21,560 --> 00:22:24,240 And the way that you do that is by knowing 497 00:22:24,240 --> 00:22:27,090 how many outputs there are out there that you can actually 498 00:22:27,090 --> 00:22:28,910 redeem-- 499 00:22:28,910 --> 00:22:31,200 that you have the knowledge to redeem. 500 00:22:31,200 --> 00:22:33,840 Like I said, a transaction can have multiple inputs 501 00:22:33,840 --> 00:22:35,190 and multiple outputs. 502 00:22:35,190 --> 00:22:38,910 And each input comes with its own scriptSig, 503 00:22:38,910 --> 00:22:41,550 and each output comes with its own scriptPubKey. 504 00:22:41,550 --> 00:22:44,370 So it's not that there's one scriptSig and one scriptPubKey 505 00:22:44,370 --> 00:22:45,900 for the entire transaction. 506 00:22:45,900 --> 00:22:47,700 The transaction can actually spend 507 00:22:47,700 --> 00:22:49,770 multiple different outputs and produce 508 00:22:49,770 --> 00:22:51,840 multiple different new outputs. 509 00:22:51,840 --> 00:22:54,660 And these outputs could have nothing to do with each other. 510 00:22:54,660 --> 00:22:58,860 Here, this input might point to a previous output 511 00:22:58,860 --> 00:23:01,432 that Alice knows how to spend. 512 00:23:01,432 --> 00:23:03,390 And this input might point to a previous output 513 00:23:03,390 --> 00:23:05,400 the Carol knows how to spend. 514 00:23:05,400 --> 00:23:07,290 And you can actually combine both of those 515 00:23:07,290 --> 00:23:09,660 into the same transaction, assuming 516 00:23:09,660 --> 00:23:13,200 you can produce a transaction with the right scriptSigs. 517 00:23:13,200 --> 00:23:16,140 Now, Alice and Carol might have to talk to each other 518 00:23:16,140 --> 00:23:17,820 in order to produce this transaction, 519 00:23:17,820 --> 00:23:20,400 because it's going to need both signatures, 520 00:23:20,400 --> 00:23:21,780 but they could do it. 521 00:23:25,340 --> 00:23:27,960 AUDIENCE: What prevents people from sort 522 00:23:27,960 --> 00:23:29,793 of shuffling around and changing the outputs 523 00:23:29,793 --> 00:23:30,752 and inputs [INAUDIBLE]? 524 00:23:30,752 --> 00:23:32,200 NEHA NARULA: Ah, great question. 525 00:23:32,200 --> 00:23:34,690 So what prevents people from shuffling 526 00:23:34,690 --> 00:23:35,940 around inputs and the outputs? 527 00:23:35,940 --> 00:23:37,398 Well, part of it is because this is 528 00:23:37,398 --> 00:23:40,170 serialized into a transaction. 529 00:23:40,170 --> 00:23:44,040 And that transaction is hashed, and then these signatures 530 00:23:44,040 --> 00:23:46,410 are on that transaction hash. 531 00:23:46,410 --> 00:23:48,750 Remember, we saw that from a few slides before. 532 00:23:48,750 --> 00:23:50,640 So if you were to flip around the order 533 00:23:50,640 --> 00:23:52,830 or if you were to trying to change any bits in here 534 00:23:52,830 --> 00:23:54,930 and change the pubkey, you would end up 535 00:23:54,930 --> 00:23:56,910 changing the hash of the transaction 536 00:23:56,910 --> 00:23:59,430 and this signature would no longer be valid. 537 00:23:59,430 --> 00:24:02,400 And something also that's important to note-- 538 00:24:02,400 --> 00:24:05,820 only valid transactions get accepted to the blockchain. 539 00:24:05,820 --> 00:24:09,450 So all of the nodes are checking to make sure 540 00:24:09,450 --> 00:24:12,103 that these scriptPubKeys and these scriptSigs work out. 541 00:24:12,103 --> 00:24:13,770 And I'll show you the rules that they're 542 00:24:13,770 --> 00:24:15,810 checking in just a moment. 543 00:24:15,810 --> 00:24:19,830 And so if anything doesn't match, 544 00:24:19,830 --> 00:24:23,610 if this signature is not a valid scriptSig for whatever output 545 00:24:23,610 --> 00:24:26,460 it's pointing to, this is an invalid transaction, 546 00:24:26,460 --> 00:24:27,690 no one will accept it. 547 00:24:27,690 --> 00:24:29,940 In fact, most nodes won't even pass it around, 548 00:24:29,940 --> 00:24:31,860 and it will not get into the blockchain. 549 00:24:31,860 --> 00:24:34,107 Or if it does get into the blockchain, 550 00:24:34,107 --> 00:24:35,940 all of the nodes who are following the rules 551 00:24:35,940 --> 00:24:37,500 of the network will ignore it. 552 00:24:37,500 --> 00:24:39,330 Because if a transaction is invalid, 553 00:24:39,330 --> 00:24:41,130 it means the entire block is invalid, 554 00:24:41,130 --> 00:24:44,912 and it means any chain building off that block is also invalid. 555 00:24:44,912 --> 00:24:47,370 So nodes that are following the rules of the network, which 556 00:24:47,370 --> 00:24:51,420 are, these should be valid, will not listen to that, 557 00:24:51,420 --> 00:24:55,830 and will completely ignore that entire chain. 558 00:24:55,830 --> 00:24:59,990 So here's another visual of what it looks like to have-- 559 00:24:59,990 --> 00:25:02,010 and this is not with the blockchain looks like. 560 00:25:02,010 --> 00:25:03,420 I want to be clear. 561 00:25:03,420 --> 00:25:05,400 The blockchain just a set of blocks 562 00:25:05,400 --> 00:25:07,490 pointing to previous blocks. 563 00:25:07,490 --> 00:25:08,910 What we have here is more sort of 564 00:25:08,910 --> 00:25:11,160 like the logical representation of what 565 00:25:11,160 --> 00:25:12,580 a transaction looks like. 566 00:25:12,580 --> 00:25:14,820 So you have a transaction right here, 567 00:25:14,820 --> 00:25:17,010 and you have two inputs in this transaction. 568 00:25:17,010 --> 00:25:20,280 And the first one is pointing to the second output 569 00:25:20,280 --> 00:25:22,860 of this previous transaction that happened over here. 570 00:25:22,860 --> 00:25:25,140 So this transaction has a hash. 571 00:25:25,140 --> 00:25:28,080 And maybe this is the hash of the entire transaction. 572 00:25:28,080 --> 00:25:31,410 And so in order to spend that output over there, 573 00:25:31,410 --> 00:25:34,500 you specify the hash, you specify the index-- 574 00:25:34,500 --> 00:25:39,090 so 012, you specify this index right here-- 575 00:25:39,090 --> 00:25:42,390 and you provide a scriptSig that will 576 00:25:42,390 --> 00:25:45,300 validate according to whatever the scriptPubKey is 577 00:25:45,300 --> 00:25:47,200 for that output. 578 00:25:47,200 --> 00:25:50,100 So note here, this transaction doesn't care 579 00:25:50,100 --> 00:25:51,960 what those outputs are at all. 580 00:25:51,960 --> 00:25:52,947 It's not using those. 581 00:25:52,947 --> 00:25:54,030 It's not looking at those. 582 00:25:54,030 --> 00:25:55,863 Someone else might spend those, someone else 583 00:25:55,863 --> 00:25:56,790 might not spend those. 584 00:25:56,790 --> 00:25:59,250 It's just spending this one right here. 585 00:25:59,250 --> 00:26:01,950 And in the act of spending this one right here, 586 00:26:01,950 --> 00:26:06,390 it doesn't make those other ones invalid in the simplest form. 587 00:26:06,390 --> 00:26:09,190 Those could still be spent by someone else. 588 00:26:09,190 --> 00:26:12,330 So outputs are consumed separately. 589 00:26:12,330 --> 00:26:16,650 So here, it's pointing to a different transaction, 590 00:26:16,650 --> 00:26:18,510 a transaction with this hash. 591 00:26:18,510 --> 00:26:21,210 And so it specifies the transaction ID, 592 00:26:21,210 --> 00:26:23,807 and then it specifies which output in that transaction 593 00:26:23,807 --> 00:26:24,390 it's spending. 594 00:26:24,390 --> 00:26:28,230 In this case, it's the third one, so it has index 2. 595 00:26:28,230 --> 00:26:29,910 And it provides a satisfying scriptSig 596 00:26:29,910 --> 00:26:32,430 for this output, which probably is 597 00:26:32,430 --> 00:26:34,430 totally different than the satisfying 598 00:26:34,430 --> 00:26:37,240 scriptSig for that output. 599 00:26:37,240 --> 00:26:40,680 So this is what this transaction has to specify in order 600 00:26:40,680 --> 00:26:42,690 to spend those outputs. 601 00:26:42,690 --> 00:26:45,240 And it can produce whatever new outputs it wants 602 00:26:45,240 --> 00:26:46,890 to produce under certain rules. 603 00:26:50,159 --> 00:26:53,930 AUDIENCE: So in that example, that whole box actually 604 00:26:53,930 --> 00:26:55,780 points to something else? 605 00:26:55,780 --> 00:26:59,510 That's not these two boxes on the left, right? 606 00:26:59,510 --> 00:27:00,540 NEHA NARULA: This box? 607 00:27:00,540 --> 00:27:02,000 What do you mean when you say, points to? 608 00:27:02,000 --> 00:27:03,450 AUDIENCE: [? Their ?] blockchain sequence. 609 00:27:03,450 --> 00:27:04,200 NEHA NARULA: Yeah. 610 00:27:04,200 --> 00:27:05,930 This is something that will be inside 611 00:27:05,930 --> 00:27:08,720 of the blockchain-- inside of a block in the blockchain. 612 00:27:08,720 --> 00:27:11,280 So this doesn't actually point to anything. 613 00:27:11,280 --> 00:27:13,340 It contains hashes. 614 00:27:13,340 --> 00:27:15,560 Literally, it just contains these bytes, 615 00:27:15,560 --> 00:27:18,630 these hashes of the transactions that it's spending. 616 00:27:18,630 --> 00:27:22,010 And those are kind of like a pointer in a sense. 617 00:27:22,010 --> 00:27:24,470 But when it comes to the entire blockchain, 618 00:27:24,470 --> 00:27:26,874 this is one part of one block. 619 00:27:26,874 --> 00:27:28,537 AUDIENCE: [INAUDIBLE] 620 00:27:28,537 --> 00:27:29,620 NEHA NARULA: Yeah, I know. 621 00:27:29,620 --> 00:27:33,520 Can you guys see this at all? 622 00:27:33,520 --> 00:27:35,140 Can you still see that or no? 623 00:27:35,140 --> 00:27:35,670 OK, good. 624 00:27:35,670 --> 00:27:37,055 OK, great. 625 00:27:37,055 --> 00:27:37,930 You had your hand up. 626 00:27:37,930 --> 00:27:39,930 AUDIENCE: Yeah, so in one of the earlier slides, 627 00:27:39,930 --> 00:27:48,560 you showed [INAUDIBLE] Is that signature the same 628 00:27:48,560 --> 00:27:49,367 as scriptSig, or-- 629 00:27:49,367 --> 00:27:50,950 NEHA NARULA: No, that was sort of more 630 00:27:50,950 --> 00:27:52,750 like an idealized transaction. 631 00:27:52,750 --> 00:27:55,215 So this is what a transaction actually looks like, 632 00:27:55,215 --> 00:27:56,185 [CHUCKLING] 633 00:27:56,185 --> 00:27:57,685 AUDIENCE: But the scriptSig is still 634 00:27:57,685 --> 00:27:58,982 inside the transaction itself. 635 00:27:58,982 --> 00:28:01,190 NEHA NARULA: The scriptSig is inside the transaction. 636 00:28:01,190 --> 00:28:02,830 But when you sign the transaction, 637 00:28:02,830 --> 00:28:06,610 you don't sign the scriptSigs because the scriptSigs include 638 00:28:06,610 --> 00:28:08,352 the signature of the transaction. 639 00:28:08,352 --> 00:28:10,060 And it's important to note, the scriptSig 640 00:28:10,060 --> 00:28:13,910 includes the signature of the transaction as a whole, 641 00:28:13,910 --> 00:28:16,336 not just this part of it. 642 00:28:16,336 --> 00:28:20,440 TADGE DRYJA: This actually [INAUDIBLE] We're not talking 643 00:28:20,440 --> 00:28:23,680 about it now, but that was sort of-- 644 00:28:23,680 --> 00:28:25,980 there's bugs involved at that point. 645 00:28:25,980 --> 00:28:26,505 NEHA NARULA: Yeah, we're not going 646 00:28:26,505 --> 00:28:27,588 to talk about [INAUDIBLE]. 647 00:28:27,588 --> 00:28:28,750 OK, yes. 648 00:28:28,750 --> 00:28:32,380 AUDIENCE: Yeah, what prevents two different transactions 649 00:28:32,380 --> 00:28:34,210 pointing back at the same [INAUDIBLE]?? 650 00:28:34,210 --> 00:28:35,377 NEHA NARULA: Great question. 651 00:28:35,377 --> 00:28:39,280 So OK, I said that there's this rule that outputs are supposed 652 00:28:39,280 --> 00:28:41,110 to only be consumed once. 653 00:28:41,110 --> 00:28:43,495 But I can definitely produce another transaction which 654 00:28:43,495 --> 00:28:44,620 points back to that output. 655 00:28:44,620 --> 00:28:46,240 I could send it to the network. 656 00:28:46,240 --> 00:28:48,798 And what would happen is the nodes in the network, 657 00:28:48,798 --> 00:28:50,590 assuming they're following consensus rules, 658 00:28:50,590 --> 00:28:53,560 would note that this had already been spent. 659 00:28:53,560 --> 00:28:55,420 So if this is already-- if they've already 660 00:28:55,420 --> 00:28:59,710 seen a valid transaction that consumes an output, 661 00:28:59,710 --> 00:29:02,648 they will not accept another transaction that 662 00:29:02,648 --> 00:29:03,940 tries to spend the same output. 663 00:29:03,940 --> 00:29:05,840 That's what's known as a double-spend. 664 00:29:05,840 --> 00:29:07,450 And so all the nodes in the network 665 00:29:07,450 --> 00:29:10,408 together are maintaining this rule. 666 00:29:10,408 --> 00:29:12,700 AUDIENCE: Isn't it going to be kind of hard to traverse 667 00:29:12,700 --> 00:29:14,200 backwards and figure out [INAUDIBLE] 668 00:29:14,200 --> 00:29:15,110 pointing [INAUDIBLE]? 669 00:29:15,110 --> 00:29:16,277 NEHA NARULA: Great question. 670 00:29:16,277 --> 00:29:18,630 Yes, this seems kind of annoying, right? 671 00:29:18,630 --> 00:29:21,380 You see this transaction, and OK, there's 672 00:29:21,380 --> 00:29:24,650 some random bytes in here, and a signature, 673 00:29:24,650 --> 00:29:28,280 and how am I supposed to figure out what this goes to? 674 00:29:28,280 --> 00:29:31,370 How am I supposed to figure out whether this 675 00:29:31,370 --> 00:29:34,800 is a valid transaction, whether it's been spent or not? 676 00:29:34,800 --> 00:29:37,250 And the answer is that every single node 677 00:29:37,250 --> 00:29:39,410 is maintaining a lot of data structures 678 00:29:39,410 --> 00:29:41,600 in order to make this faster. 679 00:29:41,600 --> 00:29:43,700 And in fact they're maintaining a data structure 680 00:29:43,700 --> 00:29:47,030 called the UTXO set. 681 00:29:47,030 --> 00:29:51,570 And I'll tell you a little bit about the UTXO set in a minute. 682 00:29:51,570 --> 00:29:54,740 And I'll tell you how it's created in a moment. 683 00:29:54,740 --> 00:29:55,541 Yes. 684 00:29:55,541 --> 00:29:58,190 AUDIENCE: [INAUDIBLE] transaction fees 685 00:29:58,190 --> 00:30:02,110 and how these transactions pass in to the blockchain itself? 686 00:30:02,110 --> 00:30:03,260 NEHA NARULA: Sure. 687 00:30:03,260 --> 00:30:05,855 So I'm not going to go into how a block-- 688 00:30:08,870 --> 00:30:10,280 what a block is composed of. 689 00:30:10,280 --> 00:30:12,920 I'm not going to go into what a block is composed of, 690 00:30:12,920 --> 00:30:14,100 but we will tomorrow. 691 00:30:18,002 --> 00:30:18,502 Yes. 692 00:30:18,502 --> 00:30:21,170 AUDIENCE: Just to confirm, with the [INAUDIBLE] scriptSig, 693 00:30:21,170 --> 00:30:23,298 it's not usually [? taking ?] this, 694 00:30:23,298 --> 00:30:27,055 it's [INAUDIBLE] the transaction. 695 00:30:27,055 --> 00:30:28,680 NEHA NARULA: I'm sorry, could you say-- 696 00:30:28,680 --> 00:30:34,060 AUDIENCE: ScriptSig, [INAUDIBLE] or is it unique for each index? 697 00:30:34,060 --> 00:30:36,060 NEHA NARULA: Yes, there is a different scriptSig 698 00:30:36,060 --> 00:30:39,415 for each input. 699 00:30:39,415 --> 00:30:41,290 There's a different scriptSig for each input, 700 00:30:41,290 --> 00:30:46,980 but that scriptSig signs most of the transaction. 701 00:30:46,980 --> 00:30:49,915 So the scriptSig, there's a different one, 702 00:30:49,915 --> 00:30:52,290 because different outputs could have different satisfying 703 00:30:52,290 --> 00:30:53,580 conditions. 704 00:30:53,580 --> 00:30:56,880 But the scriptSig has to sign a message, 705 00:30:56,880 --> 00:30:59,030 or it has to produce something. 706 00:30:59,030 --> 00:31:02,640 Actually, we're going to go into a few specific scriptSigs, 707 00:31:02,640 --> 00:31:05,010 and I think it'll be a lot clearer exactly what this is. 708 00:31:05,010 --> 00:31:06,930 Because it's not clear right now what goes in the scriptSig 709 00:31:06,930 --> 00:31:08,220 or in the scriptPubKey. 710 00:31:08,220 --> 00:31:11,670 So this is sort of like a logical representation of what 711 00:31:11,670 --> 00:31:12,810 a transaction looks like. 712 00:31:12,810 --> 00:31:15,780 It refers to the previous transaction 713 00:31:15,780 --> 00:31:17,520 that it's spending from. 714 00:31:17,520 --> 00:31:19,650 And the important things to note here 715 00:31:19,650 --> 00:31:23,490 are you don't have to spend all of the outputs 716 00:31:23,490 --> 00:31:25,440 in a transaction, you can just spend one. 717 00:31:25,440 --> 00:31:30,600 But you must consume that output entirely 718 00:31:30,600 --> 00:31:34,370 when you produce your new outputs. 719 00:31:34,370 --> 00:31:36,480 And so this is what's actually-- 720 00:31:36,480 --> 00:31:41,040 this is the JSON representation of a transaction in Bitcoin. 721 00:31:41,040 --> 00:31:44,160 And so this is probably pretty hard to read, 722 00:31:44,160 --> 00:31:46,890 and I don't think it's worth it to try to look 723 00:31:46,890 --> 00:31:49,290 at everything in great detail. 724 00:31:49,290 --> 00:31:53,520 But when we have the slides up, you can take a look at this. 725 00:31:53,520 --> 00:31:57,750 And this is literally what goes inside a transaction. 726 00:31:57,750 --> 00:32:01,270 And there are few fields that I'm not talking about here. 727 00:32:01,270 --> 00:32:05,070 One is the version, and another is the lock time. 728 00:32:05,070 --> 00:32:07,290 And I think when we talk-- 729 00:32:07,290 --> 00:32:09,570 these scripts, these scriptPubKey and scriptSig 730 00:32:09,570 --> 00:32:11,850 can actually get quite interesting and quite complex. 731 00:32:11,850 --> 00:32:14,640 That's what makes Bitcoin so cool. 732 00:32:14,640 --> 00:32:17,070 And I think when we get into that discussion about all 733 00:32:17,070 --> 00:32:18,862 the different things that can go into that, 734 00:32:18,862 --> 00:32:21,720 then we'll talk a little bit more about what lock time is. 735 00:32:21,720 --> 00:32:25,170 But the short answer is, a lock time tells you 736 00:32:25,170 --> 00:32:27,930 at what point in time this transaction is valid. 737 00:32:27,930 --> 00:32:31,560 So until that lock time happens, the transaction 738 00:32:31,560 --> 00:32:34,080 is not valid and can't be included in the blockchain. 739 00:32:34,080 --> 00:32:36,330 So this transaction has a lock time of zero, 740 00:32:36,330 --> 00:32:38,640 meaning it's valid immediately and can 741 00:32:38,640 --> 00:32:40,500 be included in the blockchain. 742 00:32:40,500 --> 00:32:43,140 So here, this has one input. 743 00:32:43,140 --> 00:32:47,160 The input has the transaction ID and the index. 744 00:32:47,160 --> 00:32:49,800 So that's zero, so it's spending the first output of whatever 745 00:32:49,800 --> 00:32:51,150 that transaction is. 746 00:32:51,150 --> 00:32:55,230 And it has some scriptSig, which is empty. 747 00:32:55,230 --> 00:32:59,790 And then this is the output that it's producing. 748 00:32:59,790 --> 00:33:07,170 It's spending 49.99 bitcoins from that previous output. 749 00:33:07,170 --> 00:33:10,320 And it's spending it to a new output. 750 00:33:10,320 --> 00:33:13,580 And these are the rules for redeeming this new output. 751 00:33:17,530 --> 00:33:19,690 Let's talk about consensus rules. 752 00:33:19,690 --> 00:33:21,790 So I keep using the word, valid-- 753 00:33:21,790 --> 00:33:25,408 this transaction is valid, this transaction is invalid. 754 00:33:25,408 --> 00:33:26,950 And so there are these implicit rules 755 00:33:26,950 --> 00:33:29,410 to Bitcoin, which are defined by the software, which 756 00:33:29,410 --> 00:33:32,980 state what makes a valid transaction or a valid block. 757 00:33:32,980 --> 00:33:35,770 For transactions specifically, the sum of the inputs 758 00:33:35,770 --> 00:33:39,250 has to be less than or equal to the sum of the outputs. 759 00:33:39,250 --> 00:33:42,520 So you can't create money out of nowhere. 760 00:33:42,520 --> 00:33:45,700 You can't spend more than you're putting into a transaction. 761 00:33:45,700 --> 00:33:47,920 And why less than or equal to? 762 00:33:50,970 --> 00:33:51,990 Fees, exactly. 763 00:33:51,990 --> 00:33:59,010 So the difference in the outputs and the inputs is implicit. 764 00:33:59,010 --> 00:34:01,500 And it's a fee that essentially just goes 765 00:34:01,500 --> 00:34:03,780 to the miner, the person who purchases the block. 766 00:34:03,780 --> 00:34:06,420 There is one exception to this rule. 767 00:34:06,420 --> 00:34:09,030 It's a transaction called the coinbase transaction-- 768 00:34:09,030 --> 00:34:10,264 no relation to the company. 769 00:34:10,264 --> 00:34:11,639 It's not named after the company. 770 00:34:11,639 --> 00:34:13,222 I think the company is named after it. 771 00:34:13,222 --> 00:34:15,750 But it's the first transaction in a block. 772 00:34:15,750 --> 00:34:19,500 And it's the transaction that gives out the block reward. 773 00:34:19,500 --> 00:34:24,060 So the first transaction in a block is special. 774 00:34:24,060 --> 00:34:25,840 It doesn't have any inputs. 775 00:34:25,840 --> 00:34:28,800 Or it does have inputs, but they're meaningless. 776 00:34:28,800 --> 00:34:30,840 And it produces the block reward. 777 00:34:30,840 --> 00:34:34,620 So right now, the block reward is 12.5 bitcoins. 778 00:34:34,620 --> 00:34:36,605 So every time a block is produced, 779 00:34:36,605 --> 00:34:38,730 every time someone solves that proof-of-work puzzle 780 00:34:38,730 --> 00:34:41,580 and produces a block, they include a transaction 781 00:34:41,580 --> 00:34:44,610 at the very beginning that usually gives themselves 782 00:34:44,610 --> 00:34:48,150 12.5 bitcoin plus whatever fees are 783 00:34:48,150 --> 00:34:55,030 implicit as the sum of all of the transactions in the block. 784 00:34:55,030 --> 00:34:58,000 So this invariant must be maintained, 785 00:34:58,000 --> 00:35:00,230 except for the coinbase transaction, of which there 786 00:35:00,230 --> 00:35:02,620 is one in every block. 787 00:35:02,620 --> 00:35:04,480 And then this invariant must also 788 00:35:04,480 --> 00:35:06,445 be maintained, which-- oh, yes, sorry. 789 00:35:06,445 --> 00:35:08,120 AUDIENCE: Who determines the fees? 790 00:35:08,120 --> 00:35:10,120 NEHA NARULA: The people creating the transaction 791 00:35:10,120 --> 00:35:11,330 determine the fees. 792 00:35:11,330 --> 00:35:13,738 So when I create a transaction, I'm 793 00:35:13,738 --> 00:35:16,030 specifying which outputs I'm spending, and putting them 794 00:35:16,030 --> 00:35:18,370 in my inputs, and I'm producing the outputs. 795 00:35:18,370 --> 00:35:21,850 So I just have to maintain that invariant. 796 00:35:21,850 --> 00:35:24,490 So let's say that I'm spending an input worth five bitcoin. 797 00:35:24,490 --> 00:35:26,710 I could produce an output worth five bitcoin, 798 00:35:26,710 --> 00:35:28,450 meaning that the fee is zero. 799 00:35:28,450 --> 00:35:31,030 It's very unlikely that my transaction 800 00:35:31,030 --> 00:35:33,850 would get accepted into the blockchain with a fee of zero. 801 00:35:33,850 --> 00:35:35,290 It's possible, sure. 802 00:35:35,290 --> 00:35:38,290 But if I'm not mining myself, why would 803 00:35:38,290 --> 00:35:40,060 a miner take my transaction when they 804 00:35:40,060 --> 00:35:42,770 could take a transaction that has a higher fee associated 805 00:35:42,770 --> 00:35:43,270 with it? 806 00:35:43,270 --> 00:35:44,530 And the fee is implicit. 807 00:35:44,530 --> 00:35:46,572 It's the difference between the sum of the inputs 808 00:35:46,572 --> 00:35:48,420 and the sum of the outputs. 809 00:35:48,420 --> 00:35:50,630 AUDIENCE: So higher the fees, it's more likely 810 00:35:50,630 --> 00:35:51,832 that you will be processed-- 811 00:35:51,832 --> 00:35:52,540 NEHA NARULA: Yes. 812 00:35:57,810 --> 00:35:59,738 Any other questions at this point? 813 00:35:59,738 --> 00:36:01,530 AUDIENCE: Are these taken out of the inputs 814 00:36:01,530 --> 00:36:03,110 or out of the outputs? 815 00:36:03,110 --> 00:36:06,300 NEHA NARULA: The fee is implicit. 816 00:36:06,300 --> 00:36:09,960 So, in the inputs, you're consuming-- 817 00:36:09,960 --> 00:36:13,380 so let's use this example right here. 818 00:36:13,380 --> 00:36:19,800 So here, we're consuming this output, 819 00:36:19,800 --> 00:36:21,770 which has 20 bitcoin in it. 820 00:36:21,770 --> 00:36:27,170 So implicitly, this thing has 20 bitcoin to spend. 821 00:36:27,170 --> 00:36:32,360 Now, before, I had it set up as 5-10-5. 822 00:36:32,360 --> 00:36:36,110 And so 20 needs to be greater than 823 00:36:36,110 --> 00:36:38,930 or equal to 5 plus 10 plus 5. 824 00:36:38,930 --> 00:36:42,530 And it is, great, 20 is greater than or equal to 20. 825 00:36:42,530 --> 00:36:44,990 What I could do is I could change this number to a four. 826 00:36:48,200 --> 00:36:50,360 And so what this means is-- 827 00:36:50,360 --> 00:36:52,580 notice that this adds up to 19 now. 828 00:36:52,580 --> 00:36:54,410 Where did that one bitcoin go? 829 00:36:54,410 --> 00:36:58,400 That one bitcoin implicitly goes to whoever 830 00:36:58,400 --> 00:37:04,862 produces the block in which that contains this transaction. 831 00:37:04,862 --> 00:37:06,320 AUDIENCE: So is that greater than-- 832 00:37:06,320 --> 00:37:08,552 [INTERPOSING VOICES] 833 00:37:08,552 --> 00:37:09,760 AUDIENCE: No, but [INAUDIBLE] 834 00:37:09,760 --> 00:37:10,080 NEHA NARULA: No. 835 00:37:10,080 --> 00:37:11,038 AUDIENCE: On the slide. 836 00:37:13,307 --> 00:37:14,640 NEHA NARULA: Yeah, you're right. 837 00:37:14,640 --> 00:37:16,598 Sorry, that should be greater than or equal to. 838 00:37:16,598 --> 00:37:17,550 Sorry about that. 839 00:37:17,550 --> 00:37:19,860 So another invariant that needs to be maintained 840 00:37:19,860 --> 00:37:21,960 is that this output has not already 841 00:37:21,960 --> 00:37:24,840 been referenced in another transaction, 842 00:37:24,840 --> 00:37:28,540 in another valid transaction. 843 00:37:28,540 --> 00:37:31,120 And then, as I alluded to, a final invariant 844 00:37:31,120 --> 00:37:34,770 is around the lock time. 845 00:37:34,770 --> 00:37:41,520 So let's go into an example of how this actually works, 846 00:37:41,520 --> 00:37:44,730 this scriptSig and scriptPubKey thing. 847 00:37:44,730 --> 00:37:47,370 So I haven't really gone into detail yet about what this is. 848 00:37:47,370 --> 00:37:50,510 I sort of implied that this specified a key and this 849 00:37:50,510 --> 00:37:52,200 specified a signature. 850 00:37:52,200 --> 00:37:54,490 But what does this actually look like? 851 00:37:54,490 --> 00:37:57,400 And I mean, I think this is really, really interesting, 852 00:37:57,400 --> 00:37:57,900 actually. 853 00:37:57,900 --> 00:38:01,320 Because Bitcoin lets you specify lots 854 00:38:01,320 --> 00:38:04,500 of different scriptPubKeys and lots of different scriptSigs. 855 00:38:04,500 --> 00:38:06,870 And so this gives you this kind of flexibility 856 00:38:06,870 --> 00:38:10,020 so that you can program in different kinds of conditions 857 00:38:10,020 --> 00:38:12,660 on what it takes to redeem a transaction. 858 00:38:12,660 --> 00:38:14,910 So we're just going to talk about a couple very simple 859 00:38:14,910 --> 00:38:15,600 ones. 860 00:38:15,600 --> 00:38:17,460 Because to get into more complex stuff, 861 00:38:17,460 --> 00:38:22,230 we need to go really deep into this word, script. 862 00:38:22,230 --> 00:38:27,450 So basically the scriptPubKey and the scriptSig 863 00:38:27,450 --> 00:38:30,750 are composed of opcodes. 864 00:38:30,750 --> 00:38:33,840 So Bitcoin has a little less than 200 opcodes, 865 00:38:33,840 --> 00:38:36,450 and you write Bitcoin scripts using these opcodes. 866 00:38:40,520 --> 00:38:44,330 So let's talk about the most common Bitcoin script, 867 00:38:44,330 --> 00:38:46,760 which is Pay to Pubkey Hash. 868 00:38:46,760 --> 00:38:51,650 So the idea here is you want to send money to a public key. 869 00:38:51,650 --> 00:38:54,980 So Alice has Bob's public key, and Alice wants to pay Bob. 870 00:38:54,980 --> 00:38:59,150 And so Alice wants to send money to Bob's public key. 871 00:38:59,150 --> 00:39:00,890 Well, the reason that this is called 872 00:39:00,890 --> 00:39:04,430 pubkey hash, public keys are kind of big, 873 00:39:04,430 --> 00:39:08,060 and there's this nice-- you can kind of make 874 00:39:08,060 --> 00:39:10,400 this nice observation that you don't necessarily 875 00:39:10,400 --> 00:39:12,800 have to put the whole public key in the output. 876 00:39:12,800 --> 00:39:14,758 You can put a hash of the public in the output. 877 00:39:14,758 --> 00:39:17,383 And I think Tadge already talked about this when he was talking 878 00:39:17,383 --> 00:39:18,521 about Bitcoin addresses. 879 00:39:21,170 --> 00:39:26,680 So the scriptPubKey is instructions 880 00:39:26,680 --> 00:39:30,010 on how to verify a signature of a public key that 881 00:39:30,010 --> 00:39:35,900 has been hashed and the scriptSig 882 00:39:35,900 --> 00:39:39,350 is that signature and the actual public key, 883 00:39:39,350 --> 00:39:42,120 the pre-image of the hash public key. 884 00:39:42,120 --> 00:39:44,260 And this is what that looks like. 885 00:39:44,260 --> 00:39:47,370 So this is literally the scriptPubKey 886 00:39:47,370 --> 00:39:52,980 for a Pay to Pubkey Hash input or output, 887 00:39:52,980 --> 00:39:56,700 and this is literally the scriptSig that would you would 888 00:39:56,700 --> 00:40:01,440 use to redeem that output. 889 00:40:01,440 --> 00:40:06,660 So this right here would go inside one of these. 890 00:40:06,660 --> 00:40:09,810 And it would set the conditions under which 891 00:40:09,810 --> 00:40:12,240 you could redeem this output. 892 00:40:12,240 --> 00:40:15,480 And this right here would go inside the input 893 00:40:15,480 --> 00:40:18,360 of the transaction that's redeeming it. 894 00:40:18,360 --> 00:40:22,410 And let's take a look at how this actually works. 895 00:40:22,410 --> 00:40:26,970 So what the Bitcoin Script Interpreter does is, 896 00:40:26,970 --> 00:40:31,640 when it's evaluating whether or not a transaction is valid, 897 00:40:31,640 --> 00:40:33,710 it takes a look at the input, and it 898 00:40:33,710 --> 00:40:37,010 looks at which previous transaction it's looking at 899 00:40:37,010 --> 00:40:41,440 and which index the output is, and it grabs the scriptPubKey. 900 00:40:41,440 --> 00:40:43,940 Well, first of all, it makes sure that output hasn't already 901 00:40:43,940 --> 00:40:45,730 been spent. 902 00:40:45,730 --> 00:40:50,080 Then it grabs the scriptPubKey, and it takes the scriptSig 903 00:40:50,080 --> 00:40:53,450 and it puts them on top of each other, just like this. 904 00:40:53,450 --> 00:40:55,090 So that's the scriptSig up there, 905 00:40:55,090 --> 00:40:57,690 this is the scriptPubKey down here. 906 00:40:57,690 --> 00:41:01,630 And then it runs this combined script 907 00:41:01,630 --> 00:41:03,790 through the Bitcoin Script Interpreter, which 908 00:41:03,790 --> 00:41:05,710 is based on a stack model. 909 00:41:05,710 --> 00:41:09,160 So it starts pushing things onto the stack. 910 00:41:09,160 --> 00:41:11,200 It starts at the very top, and it 911 00:41:11,200 --> 00:41:15,850 starts pushing these items onto the stack and evaluating them. 912 00:41:15,850 --> 00:41:17,500 And so the rules are that constants 913 00:41:17,500 --> 00:41:18,970 get pushed onto the stack-- 914 00:41:18,970 --> 00:41:21,730 and then operations-- and these things right here are 915 00:41:21,730 --> 00:41:22,420 operations-- 916 00:41:22,420 --> 00:41:25,390 OP_DUP, OP_HASH160, OP_EQUALVERIFY, 917 00:41:25,390 --> 00:41:29,410 and OP_CHECKSIG, these are all Bitcoin opcodes. 918 00:41:29,410 --> 00:41:32,140 Operations have different rules as to how they're evaluated 919 00:41:32,140 --> 00:41:35,220 and what they consume off of the stack. 920 00:41:35,220 --> 00:41:37,480 So the first thing is a signature. 921 00:41:37,480 --> 00:41:40,440 We're going to pop the signature and push it onto the stack 922 00:41:40,440 --> 00:41:44,400 because it is a constant so this would 923 00:41:44,400 --> 00:41:47,880 be the signature that Alice might produce in order 924 00:41:47,880 --> 00:41:49,110 to spend her output. 925 00:41:52,020 --> 00:41:55,560 Then same thing with the pubkey, because the pubkey is also 926 00:41:55,560 --> 00:41:57,810 a constant. 927 00:41:57,810 --> 00:41:59,420 Then we're going to take this first-- 928 00:41:59,420 --> 00:42:01,503 now, OK, we're done with constants for the moment, 929 00:42:01,503 --> 00:42:04,056 and the next thing on the stack is OP_DUP. 930 00:42:04,056 --> 00:42:07,292 OP_DUP does basically exactly what it sounds like. 931 00:42:07,292 --> 00:42:08,750 It takes the thing that's currently 932 00:42:08,750 --> 00:42:11,220 on the top of the stack and it duplicates it. 933 00:42:11,220 --> 00:42:14,750 So the way that we consume OP_DUP is we take this pubkey 934 00:42:14,750 --> 00:42:18,090 and we create another copy of the pubkey. 935 00:42:18,090 --> 00:42:20,430 The next op is OP_HASH160. 936 00:42:20,430 --> 00:42:23,190 It also does exactly what it sounds like. 937 00:42:23,190 --> 00:42:26,790 It takes what's on the top of the stack, it hashes it, 938 00:42:26,790 --> 00:42:30,760 and it pushes that hash onto the top of the stack. 939 00:42:30,760 --> 00:42:34,050 So after we run OP_HASH160, this is 940 00:42:34,050 --> 00:42:36,330 what our stack will look like. 941 00:42:39,180 --> 00:42:41,750 Next thing is a constant. 942 00:42:41,750 --> 00:42:47,900 So we take that constant, which should be-- 943 00:42:47,900 --> 00:42:49,370 which is the hash of the pubkey. 944 00:42:49,370 --> 00:42:52,700 So this is the address that this money 945 00:42:52,700 --> 00:42:55,100 is being sent to, essentially. 946 00:42:55,100 --> 00:42:58,040 And we put that on the top of the stack. 947 00:42:58,040 --> 00:43:02,810 And then we run this operation called OP_EQUALVERIFY. 948 00:43:02,810 --> 00:43:05,780 Whenever an opcode ends with VERIFY, 949 00:43:05,780 --> 00:43:07,880 it means that it's a little bit special. 950 00:43:07,880 --> 00:43:11,660 It means that it has the ability to, if it fails, 951 00:43:11,660 --> 00:43:14,300 break out of the entire script execution 952 00:43:14,300 --> 00:43:17,570 and immediately cause transaction validation to fail. 953 00:43:17,570 --> 00:43:20,420 So OP_EQUALVERIFY does what it sounds 954 00:43:20,420 --> 00:43:23,300 like, it checks to make sure that the two 955 00:43:23,300 --> 00:43:26,600 things on the top of the stack are equal. 956 00:43:26,600 --> 00:43:28,790 And if they're not equal, then it immediately 957 00:43:28,790 --> 00:43:32,320 fails validation. 958 00:43:32,320 --> 00:43:34,725 So you'll note that what the two things 959 00:43:34,725 --> 00:43:36,100 at the top of the-- let's go back 960 00:43:36,100 --> 00:43:39,370 to what the two things on the top of the stack are right now. 961 00:43:39,370 --> 00:43:42,160 So we pushed the sig, we push a pubkey, 962 00:43:42,160 --> 00:43:45,550 we duplicated that pubkey, and these are from the scriptSig, 963 00:43:45,550 --> 00:43:49,510 so this is from whoever is redeeming the transaction. 964 00:43:49,510 --> 00:43:51,100 So whoever's redeeming the transaction 965 00:43:51,100 --> 00:43:53,410 has put a copy of this pub key on there, 966 00:43:53,410 --> 00:43:55,540 and now that pubkey is on the stack twice. 967 00:43:55,540 --> 00:43:58,690 We hashed the pubkey, and then we 968 00:43:58,690 --> 00:44:02,330 pushed the hash that was specified 969 00:44:02,330 --> 00:44:06,260 in the previous transaction that set up the rules for how 970 00:44:06,260 --> 00:44:08,090 to spend this. 971 00:44:08,090 --> 00:44:10,700 And then OP_EQUALVERIFY makes sure 972 00:44:10,700 --> 00:44:12,890 that these things are actually the same. 973 00:44:12,890 --> 00:44:15,040 And if they're not the same, then it'll 974 00:44:15,040 --> 00:44:18,380 fail that verify check and the entire transaction validation 975 00:44:18,380 --> 00:44:21,027 will abort, and it's an invalid transaction. 976 00:44:21,027 --> 00:44:22,610 So let's assume that they're the same. 977 00:44:22,610 --> 00:44:23,240 OK, great. 978 00:44:23,240 --> 00:44:25,730 Then OP_EQUALVERIFY-- then we continue 979 00:44:25,730 --> 00:44:27,050 transaction validation. 980 00:44:27,050 --> 00:44:34,130 And now we're left with this, OP_CHECKSIG, pubkey, sig. 981 00:44:34,130 --> 00:44:37,160 And this does exactly what you think it might do, 982 00:44:37,160 --> 00:44:39,680 it pops two things off the stack, 983 00:44:39,680 --> 00:44:44,570 checks to make sure that the signature is a valid signature 984 00:44:44,570 --> 00:44:46,070 for this pub key. 985 00:44:46,070 --> 00:44:49,010 And if it is, it pushes true onto the stack. 986 00:44:52,900 --> 00:44:56,170 And if there is a true on top of the stack-- in fact, 987 00:44:56,170 --> 00:44:58,510 I think if there's any constant on top of the stack 988 00:44:58,510 --> 00:45:02,900 when we've consumed all of the parts of our scriptSig 989 00:45:02,900 --> 00:45:07,583 and scriptPubKey, then this returns true 990 00:45:07,583 --> 00:45:09,250 and the transaction is considered valid. 991 00:45:12,250 --> 00:45:18,500 So this is a lot, and I know this is kind of complicated. 992 00:45:18,500 --> 00:45:23,352 So let's sort of step through this one more time. 993 00:45:23,352 --> 00:45:24,810 And there's just a couple of things 994 00:45:24,810 --> 00:45:26,640 that I want to make clear. 995 00:45:26,640 --> 00:45:31,860 This part right here is set up in the output of whatever 996 00:45:31,860 --> 00:45:33,510 transaction we're spending. 997 00:45:33,510 --> 00:45:36,450 So if Alice creates this transaction 998 00:45:36,450 --> 00:45:39,060 and she's spending to Bob, then Alice 999 00:45:39,060 --> 00:45:43,110 would put whose pubkey here? 1000 00:45:43,110 --> 00:45:43,823 AUDIENCE: Bob's. 1001 00:45:43,823 --> 00:45:45,490 NEHA NARULA: Hash of a pubkey, actually. 1002 00:45:45,490 --> 00:45:49,600 Right, so Alice would put the hash of Bob's pubkey here. 1003 00:45:49,600 --> 00:45:55,170 And when Bob's redeeming, what would go in the input that 1004 00:45:55,170 --> 00:45:57,716 needs to redeem that output? 1005 00:45:57,716 --> 00:46:01,345 AUDIENCE: [INAUDIBLE] 1006 00:46:01,345 --> 00:46:02,720 NEHA NARULA: Sorry, I can't hear. 1007 00:46:02,720 --> 00:46:03,803 AUDIENCE: Bob's signature. 1008 00:46:03,803 --> 00:46:06,310 NEHA NARULA: Bob's signature and the pubkey 1009 00:46:06,310 --> 00:46:07,990 that corresponds to that signature, 1010 00:46:07,990 --> 00:46:10,840 because all we have is a hash. 1011 00:46:10,840 --> 00:46:13,630 So those are the things that would 1012 00:46:13,630 --> 00:46:14,840 get put on top of the stack. 1013 00:46:14,840 --> 00:46:16,630 So up there, we have Bob's signature 1014 00:46:16,630 --> 00:46:18,780 and we have Bob's pubkey. 1015 00:46:18,780 --> 00:46:21,520 Again, those get pushed onto the stack 1016 00:46:21,520 --> 00:46:25,960 because they're constants, duplicated, hash the top, 1017 00:46:25,960 --> 00:46:28,900 copy over the hash, make sure that they're equal, 1018 00:46:28,900 --> 00:46:31,180 and then check the signature. 1019 00:46:31,180 --> 00:46:34,270 And this is a Pay to Pubkey Hash script. 1020 00:46:34,270 --> 00:46:36,840 It is the most common script in Bitcoin. 1021 00:46:36,840 --> 00:46:40,140 And this is this basically the standard way of spending money. 1022 00:46:43,540 --> 00:46:44,980 Are there questions about this? 1023 00:46:44,980 --> 00:46:45,310 Yes. 1024 00:46:45,310 --> 00:46:46,685 AUDIENCE: Is there a significance 1025 00:46:46,685 --> 00:46:48,970 in having that they're equal-verified 1026 00:46:48,970 --> 00:46:50,947 before the CHECKSIG? 1027 00:46:50,947 --> 00:46:52,780 Because it seems like they're both verifying 1028 00:46:52,780 --> 00:46:54,208 tings, and I'm wondering-- 1029 00:46:54,208 --> 00:46:56,000 NEHA NARULA: Yeah, that's a great question. 1030 00:46:56,000 --> 00:46:59,650 So let's say that we didn't have this EQUALVERIFY here then 1031 00:46:59,650 --> 00:47:03,202 what could a malicious spender possibly do? 1032 00:47:03,202 --> 00:47:05,610 AUDIENCE: Well, I just meant flipping the order. 1033 00:47:05,610 --> 00:47:08,440 We're still verifying both, but if you did the CHECKSIG first 1034 00:47:08,440 --> 00:47:10,870 versus the EQUALVERIFY first, does that matter? 1035 00:47:10,870 --> 00:47:11,900 NEHA NARULA: Oh, that's a good question. 1036 00:47:11,900 --> 00:47:13,233 I don't think that would matter. 1037 00:47:13,233 --> 00:47:13,810 I'm not sure. 1038 00:47:13,810 --> 00:47:15,190 Would it matter? 1039 00:47:15,190 --> 00:47:16,180 TADGE DRYJA: You could. 1040 00:47:16,180 --> 00:47:18,740 It's faster to verify the two hashes are equal. 1041 00:47:18,740 --> 00:47:21,370 The CHECKSIG operation takes a lot of CPU time 1042 00:47:21,370 --> 00:47:23,500 so I guess the idea is, if you're going to fail, 1043 00:47:23,500 --> 00:47:25,070 fail-- go the easy route. 1044 00:47:25,070 --> 00:47:26,350 NEHA NARULA: Yes. 1045 00:47:26,350 --> 00:47:27,250 Yes. 1046 00:47:27,250 --> 00:47:29,790 AUDIENCE: So are all nodes on the network running this? 1047 00:47:29,790 --> 00:47:30,880 NEHA NARULA: Yes. 1048 00:47:30,880 --> 00:47:34,600 Every single node on the network is running the Bitcoin Script 1049 00:47:34,600 --> 00:47:35,840 Interpreter inside of it. 1050 00:47:35,840 --> 00:47:38,500 And the Bitcoin Script Interpreter is known as-- 1051 00:47:38,500 --> 00:47:40,240 what's called consensus critical. 1052 00:47:40,240 --> 00:47:44,290 So if two nodes have slightly different script interpreters 1053 00:47:44,290 --> 00:47:46,750 that would interpret this in different ways, 1054 00:47:46,750 --> 00:47:50,300 the network would have a consensus failure. 1055 00:47:50,300 --> 00:47:50,810 Yes. 1056 00:47:50,810 --> 00:47:53,060 AUDIENCE: Why not just Pay to Pubkey? 1057 00:47:53,060 --> 00:47:55,580 NEHA NARULA: Pay to Pubkey is a thing, actually. 1058 00:47:55,580 --> 00:47:58,860 And Pay to Pubkey Hash is considered better. 1059 00:47:58,860 --> 00:48:02,240 And the reason for that is kind of subtle, actually. 1060 00:48:02,240 --> 00:48:06,160 It's because-- so the hash of the pubkey 1061 00:48:06,160 --> 00:48:09,680 is smaller than the pubkey. 1062 00:48:09,680 --> 00:48:14,252 And this is definitely going on the blockchain. 1063 00:48:14,252 --> 00:48:16,835 We don't know if this is going to go on the blockchain or not. 1064 00:48:16,835 --> 00:48:18,680 Not all outputs are consumed. 1065 00:48:18,680 --> 00:48:21,080 So let's put the small stuff here 1066 00:48:21,080 --> 00:48:23,160 and the big stuff over here. 1067 00:48:23,160 --> 00:48:24,570 It's about saving space. 1068 00:48:24,570 --> 00:48:29,070 Also, the set of unspent transaction outputs 1069 00:48:29,070 --> 00:48:32,370 is something that every node has to maintain. 1070 00:48:32,370 --> 00:48:33,480 It's very important. 1071 00:48:33,480 --> 00:48:37,030 You are referring to it quite a bit. 1072 00:48:37,030 --> 00:48:39,570 This is not something that every node has to maintain. 1073 00:48:39,570 --> 00:48:42,888 And so you want to make this smaller, even 1074 00:48:42,888 --> 00:48:44,430 at the expense of making this bigger. 1075 00:48:47,690 --> 00:48:48,190 Yes. 1076 00:48:48,190 --> 00:48:49,857 AUDIENCE: So then you could accidentally 1077 00:48:49,857 --> 00:48:53,109 sign a transaction that has a public key but a script that 1078 00:48:53,109 --> 00:48:55,222 doesn't actually verify it? 1079 00:48:55,222 --> 00:48:56,680 NEHA NARULA: Could you accidentally 1080 00:48:56,680 --> 00:48:59,097 sign a transaction that has a public key but a script that 1081 00:48:59,097 --> 00:49:00,400 doesn't verify? 1082 00:49:00,400 --> 00:49:03,950 Let me see if this answers your question. 1083 00:49:03,950 --> 00:49:09,470 So here is an example of an unspendable output. 1084 00:49:09,470 --> 00:49:13,330 The unspendable output has an OP_RETURN 1085 00:49:13,330 --> 00:49:16,980 as the first instruction of its scriptPubKey. 1086 00:49:16,980 --> 00:49:18,640 OP_RETURN does what you might think 1087 00:49:18,640 --> 00:49:21,390 it does, which means when you evaluate it, 1088 00:49:21,390 --> 00:49:25,060 it returns immediately and says invalid. 1089 00:49:25,060 --> 00:49:31,280 And so if you have one of these in your transaction 1090 00:49:31,280 --> 00:49:34,730 in your scriptPubKey, there is no scriptSig 1091 00:49:34,730 --> 00:49:39,450 that could possibly redeem the scriptPubKey. 1092 00:49:39,450 --> 00:49:41,040 You could create anything you wanted, 1093 00:49:41,040 --> 00:49:42,540 and no matter what you put on there, 1094 00:49:42,540 --> 00:49:44,110 it would never evaluate to true. 1095 00:49:44,110 --> 00:49:46,193 There's no way to actually redeem the scriptPubKey 1096 00:49:46,193 --> 00:49:46,830 in this output. 1097 00:49:46,830 --> 00:49:47,820 Does that answer your question? 1098 00:49:47,820 --> 00:49:48,660 AUDIENCE: I think it's the opposite. 1099 00:49:48,660 --> 00:49:51,035 I was asking if you could accidentally get something that 1100 00:49:51,035 --> 00:49:52,631 would always evaluate to true. 1101 00:49:52,631 --> 00:49:54,980 NEHA NARULA: Ah, OK, well, that's the next slide. 1102 00:49:54,980 --> 00:49:56,940 [CHUCKLING] 1103 00:49:56,940 --> 00:50:00,990 So yes, this is what's called an anyone-can-spend output. 1104 00:50:00,990 --> 00:50:02,580 The simplest anyone-can-spend output 1105 00:50:02,580 --> 00:50:04,500 is just an empty scriptPubKey. 1106 00:50:04,500 --> 00:50:09,030 Because a scriptSig sig OP_TRUE in it would evaluate to true. 1107 00:50:09,030 --> 00:50:13,350 Notice here there's no public keys, there's no signatures, 1108 00:50:13,350 --> 00:50:15,395 there's no hashes of public keys. 1109 00:50:15,395 --> 00:50:16,770 The scriptPubKey doesn't actually 1110 00:50:16,770 --> 00:50:20,560 specify any public keys. 1111 00:50:20,560 --> 00:50:23,800 And so-- but when you evaluate this right here, 1112 00:50:23,800 --> 00:50:26,080 you'd push OP_TRUE onto the stack, 1113 00:50:26,080 --> 00:50:28,330 and then you would finish, and there would be a true-- 1114 00:50:28,330 --> 00:50:30,010 OP_TRUE would push-- sorry, OP_TRUE 1115 00:50:30,010 --> 00:50:31,540 would push a true onto the stack. 1116 00:50:31,540 --> 00:50:32,915 And then when you finished, there 1117 00:50:32,915 --> 00:50:35,442 would be true on the stack, meaning this is valid. 1118 00:50:35,442 --> 00:50:37,650 AUDIENCE: Also another way, you could put the OP_TRUE 1119 00:50:37,650 --> 00:50:38,653 in the output script as well. 1120 00:50:38,653 --> 00:50:40,625 Then you wouldn't have to push it because-- 1121 00:50:40,625 --> 00:50:42,570 NEHA NARULA: Yeah. 1122 00:50:42,570 --> 00:50:45,090 So this is an anyone-can-spend output, 1123 00:50:45,090 --> 00:50:49,550 and this is a no-one-can-spend output. 1124 00:50:49,550 --> 00:50:52,070 And there's no public keys in here. 1125 00:50:52,070 --> 00:50:53,990 There's no signatures in there. 1126 00:50:53,990 --> 00:50:57,680 So you can totally create outputs that have nothing 1127 00:50:57,680 --> 00:51:02,030 to do with signatures, or maybe you verify multiple signatures, 1128 00:51:02,030 --> 00:51:04,050 which we're not going to go into right now, 1129 00:51:04,050 --> 00:51:05,450 but it's also possible. 1130 00:51:05,450 --> 00:51:06,554 Yes. 1131 00:51:06,554 --> 00:51:09,280 AUDIENCE: Can SIG have a [INAUDIBLE] in it? 1132 00:51:09,280 --> 00:51:10,435 NEHA NARULA: Yes. 1133 00:51:10,435 --> 00:51:11,310 AUDIENCE: [INAUDIBLE] 1134 00:51:11,310 --> 00:51:14,370 NEHA NARULA: Yes, it can. 1135 00:51:14,370 --> 00:51:17,990 AUDIENCE: But the list of [INAUDIBLE] are [INAUDIBLE] 1136 00:51:17,990 --> 00:51:20,690 NEHA NARULA: There are fewer than 200 opcodes. 1137 00:51:20,690 --> 00:51:22,758 The number of standard opcodes is even smaller, 1138 00:51:22,758 --> 00:51:24,800 meaning that there's a very small number that you 1139 00:51:24,800 --> 00:51:27,420 can use in your scriptSigs and scriptPubKeys. 1140 00:51:27,420 --> 00:51:31,070 And it's definitely possible, if you 1141 00:51:31,070 --> 00:51:34,850 write some weird scriptPubKey or some weird scriptSig 1142 00:51:34,850 --> 00:51:38,787 to accidentally create outputs that are never spendable, 1143 00:51:38,787 --> 00:51:40,370 or to accidentally create outputs that 1144 00:51:40,370 --> 00:51:41,970 could be spent by someone else. 1145 00:51:41,970 --> 00:51:46,250 So there's a standard set of scriptPubKeys to use. 1146 00:51:46,250 --> 00:51:48,920 And I would not recommend going outside that set, 1147 00:51:48,920 --> 00:51:51,200 except for in the lab that you're going to do, 1148 00:51:51,200 --> 00:51:53,750 because we have some more fun ones in there. 1149 00:51:53,750 --> 00:51:54,387 Yes. 1150 00:51:54,387 --> 00:51:56,720 AUDIENCE: Could you explain a little bit more on the Pay 1151 00:51:56,720 --> 00:51:59,190 to Script Hash. 1152 00:51:59,190 --> 00:52:01,715 Kind of like what [INAUDIBLE] 1153 00:52:01,715 --> 00:52:03,340 NEHA NARULA: Sure, Pay to Script Hash-- 1154 00:52:03,340 --> 00:52:05,465 I don't actually have slides on Pay to Script Hash, 1155 00:52:05,465 --> 00:52:09,700 so I'm not sure that we can do a good job of explaining it 1156 00:52:09,700 --> 00:52:10,630 right now. 1157 00:52:10,630 --> 00:52:15,960 But the idea behind Pay to Script Hash is that-- 1158 00:52:15,960 --> 00:52:18,220 yeah, I don't have the slides for it. 1159 00:52:18,220 --> 00:52:22,900 But the idea is that you're going to put, instead 1160 00:52:22,900 --> 00:52:25,570 of this particular scriptPubKey here, 1161 00:52:25,570 --> 00:52:27,430 you're going to have a scriptPubKey that 1162 00:52:27,430 --> 00:52:30,770 includes a hash of a script. 1163 00:52:30,770 --> 00:52:35,820 And then the scriptSig has to produce that script, 1164 00:52:35,820 --> 00:52:38,690 and it has to match that hash, and the whole thing 1165 00:52:38,690 --> 00:52:44,000 has to verify is the rough idea behind Pay to Script Hash. 1166 00:52:44,000 --> 00:52:48,400 And we can produce an example of that for you tomorrow. 1167 00:52:48,400 --> 00:52:50,410 But the cool thing about that is you 1168 00:52:50,410 --> 00:52:53,740 don't even know what you have to do to redeem this output. 1169 00:52:53,740 --> 00:52:58,310 So someone has to produce a script that has the same hash, 1170 00:52:58,310 --> 00:53:00,160 and when combined with the scriptPubKey, 1171 00:53:00,160 --> 00:53:01,090 will evaluate to true. 1172 00:53:01,090 --> 00:53:03,382 AUDIENCE: And that script would be pushed on the stack? 1173 00:53:03,382 --> 00:53:07,060 NEHA NARULA: Yeah, so the scriptSig and the scriptPubKey 1174 00:53:07,060 --> 00:53:09,190 literally just get concatenated together 1175 00:53:09,190 --> 00:53:11,650 and then evaluated as one thing. 1176 00:53:11,650 --> 00:53:14,080 So yeah, it would just go through the same thing. 1177 00:53:16,610 --> 00:53:17,820 Any more questions? 1178 00:53:23,807 --> 00:53:24,890 So what do you guys think? 1179 00:53:24,890 --> 00:53:25,600 Is this good? 1180 00:53:25,600 --> 00:53:26,254 Is this bad? 1181 00:53:33,840 --> 00:53:44,548 AUDIENCE: Could you try to [INAUDIBLE] 1182 00:53:44,548 --> 00:53:46,340 NEHA NARULA: Yeah, that's a great question. 1183 00:53:46,340 --> 00:53:50,260 So the question is, could you DDoS a network 1184 00:53:50,260 --> 00:53:55,080 by creating transactions that are not spendable? 1185 00:53:55,080 --> 00:53:56,860 AUDIENCE: So you still [INAUDIBLE] 1186 00:53:56,860 --> 00:53:59,680 NEHA NARULA: You can't really DDoS the network, per se. 1187 00:53:59,680 --> 00:54:02,350 So this is an example of a transaction 1188 00:54:02,350 --> 00:54:03,670 that's not spendable. 1189 00:54:03,670 --> 00:54:06,430 And see how it has this OP_RETURN, and it says, 1190 00:54:06,430 --> 00:54:07,210 whatever. 1191 00:54:07,210 --> 00:54:09,040 There is this pattern of people who 1192 00:54:09,040 --> 00:54:11,860 like to store things in the Bitcoin blockchain, 1193 00:54:11,860 --> 00:54:15,910 because it's there, and it's very highly replicated. 1194 00:54:15,910 --> 00:54:20,140 And so one type of transaction that a lot of people make 1195 00:54:20,140 --> 00:54:23,500 is and OP_RETURN with a hash of some data in it 1196 00:54:23,500 --> 00:54:24,970 or some data in it. 1197 00:54:24,970 --> 00:54:28,330 These are unspendable outputs that 1198 00:54:28,330 --> 00:54:30,970 will live on the Bitcoin blockchain forever, 1199 00:54:30,970 --> 00:54:33,940 and will be part of the UTXO set, possibly forever. 1200 00:54:37,450 --> 00:54:39,700 Generally, Bitcoin developers discourage 1201 00:54:39,700 --> 00:54:41,680 using Bitcoin in this way because it 1202 00:54:41,680 --> 00:54:43,518 does bloat the UTXO set. 1203 00:54:46,048 --> 00:54:48,340 That said, there's nothing to prevent you from doing it 1204 00:54:48,340 --> 00:54:49,610 if you want to pay the fees. 1205 00:54:49,610 --> 00:54:50,390 What? 1206 00:54:50,390 --> 00:54:52,040 TADGE DRYJA: It's actually not part of the UTXO set 1207 00:54:52,040 --> 00:54:53,350 because it has the OP_RETURN. 1208 00:54:53,350 --> 00:54:53,920 NEHA NARULA: Oh, really? 1209 00:54:53,920 --> 00:54:54,460 I didn't know that. 1210 00:54:54,460 --> 00:54:56,810 OK, I didn't know that they weren't kept in the UTXO set. 1211 00:54:56,810 --> 00:54:58,477 TADGE DRYJA: [INAUDIBLE] they would just 1212 00:54:58,477 --> 00:55:00,800 made [INAUDIBLE] key hash into whatever [INAUDIBLE] 1213 00:55:00,800 --> 00:55:02,750 and that would bloat the UTXO set. 1214 00:55:02,750 --> 00:55:03,480 So it's like, well, this is not [INAUDIBLE] 1215 00:55:03,480 --> 00:55:04,900 NEHA NARULA: OK, I didn't know that those 1216 00:55:04,900 --> 00:55:06,040 weren't included in the UTXO. 1217 00:55:06,040 --> 00:55:06,730 So that's good. 1218 00:55:06,730 --> 00:55:08,750 So then it doesn't boat the UTXO set, 1219 00:55:08,750 --> 00:55:10,180 it just goes in the blockchain. 1220 00:55:10,180 --> 00:55:12,805 And you paid the fee to put your transaction in the blockchain. 1221 00:55:12,805 --> 00:55:14,020 So good for you. 1222 00:55:14,020 --> 00:55:16,720 Yes. 1223 00:55:16,720 --> 00:55:18,390 AUDIENCE: What's the architectural logic 1224 00:55:18,390 --> 00:55:21,485 for having a specific set of opcodes that Bitcoin can run? 1225 00:55:21,485 --> 00:55:24,235 Why not use a more general programming language? 1226 00:55:24,235 --> 00:55:26,218 Is it just to have control? 1227 00:55:26,218 --> 00:55:27,760 NEHA NARULA: That's a great question. 1228 00:55:27,760 --> 00:55:31,770 So why have this weird Op code thing, right? 1229 00:55:31,770 --> 00:55:34,710 I mean, what kind of sense does this make? 1230 00:55:34,710 --> 00:55:40,550 So the problem with the general programming language 1231 00:55:40,550 --> 00:55:44,940 is it's really easy to shoot yourself in the foot. 1232 00:55:44,940 --> 00:55:48,000 It's really easy to write a program that you think-- 1233 00:55:48,000 --> 00:55:51,383 how many of you have had a bug in your program ever? 1234 00:55:51,383 --> 00:55:52,800 Please, all of you should probably 1235 00:55:52,800 --> 00:55:53,950 raise their hands, right? 1236 00:55:53,950 --> 00:55:55,260 [CHUCKLING] 1237 00:55:55,260 --> 00:55:57,390 And how many of you have had bugs in your program 1238 00:55:57,390 --> 00:55:59,790 that showed up a lot later than you thought they would, 1239 00:55:59,790 --> 00:56:02,760 when you thought your program didn't have any bugs? 1240 00:56:02,760 --> 00:56:06,010 So these things, once you put them out there, 1241 00:56:06,010 --> 00:56:07,470 these scriptPubKeys and script tag, 1242 00:56:07,470 --> 00:56:10,770 once you put these transactions out there, they're out there. 1243 00:56:10,770 --> 00:56:13,350 You cannot take them back-- 1244 00:56:13,350 --> 00:56:15,270 well, not easily. 1245 00:56:15,270 --> 00:56:18,420 And they might execute in ways that you didn't 1246 00:56:18,420 --> 00:56:20,400 anticipate them executing. 1247 00:56:20,400 --> 00:56:23,490 The more complicated the script you write, the more likely 1248 00:56:23,490 --> 00:56:26,670 it is that there's some hole in your script, some way 1249 00:56:26,670 --> 00:56:29,940 of satisfying it that you didn't anticipate, 1250 00:56:29,940 --> 00:56:33,000 that could end up stealing your money. 1251 00:56:33,000 --> 00:56:35,040 So with a general programming language, 1252 00:56:35,040 --> 00:56:39,067 well, you might think, oh, well, these OP codes 1253 00:56:39,067 --> 00:56:41,400 are super tricky and weird, and I don't understand them, 1254 00:56:41,400 --> 00:56:43,358 at least with the general programming language, 1255 00:56:43,358 --> 00:56:45,664 I'm more likely to write correct things, right? 1256 00:56:45,664 --> 00:56:46,164 Eh. 1257 00:56:46,164 --> 00:56:47,580 [CHUCKLING] 1258 00:56:47,580 --> 00:56:49,470 Actually, having this strange opcode language 1259 00:56:49,470 --> 00:56:50,620 has a lot of benefits. 1260 00:56:50,620 --> 00:56:53,190 So number one, it's not Turing-complete. 1261 00:56:53,190 --> 00:56:56,760 You know exactly how much CPU it is 1262 00:56:56,760 --> 00:56:59,850 going to take to run these scripts because 1263 00:56:59,850 --> 00:57:03,870 of the nature of the opcodes and the language. 1264 00:57:03,870 --> 00:57:05,880 There's no FOR loops in here. 1265 00:57:05,880 --> 00:57:10,170 You know you can't just run a WHILE that takes forever. 1266 00:57:10,170 --> 00:57:12,390 This is a stack-based language. 1267 00:57:12,390 --> 00:57:16,373 And so it's very easy to tell how long a transaction is 1268 00:57:16,373 --> 00:57:17,790 actually going to take to execute. 1269 00:57:17,790 --> 00:57:19,790 And this is really important, because every node 1270 00:57:19,790 --> 00:57:22,860 in the network has to execute these things. 1271 00:57:22,860 --> 00:57:26,550 So you don't want a script sneaking in there that's 1272 00:57:26,550 --> 00:57:30,750 going to take hours to execute. 1273 00:57:30,750 --> 00:57:34,210 It's also-- you can look at the number of opcodes 1274 00:57:34,210 --> 00:57:36,565 in the script, and like I said, get a rough sense of how 1275 00:57:36,565 --> 00:57:37,690 expensive it's going to be. 1276 00:57:37,690 --> 00:57:40,210 And that's why there are limits on the number of opcodes 1277 00:57:40,210 --> 00:57:41,410 you can have in a script. 1278 00:57:41,410 --> 00:57:43,030 It's very difficult to do that if you have a more 1279 00:57:43,030 --> 00:57:44,260 general programming language. 1280 00:57:46,930 --> 00:57:48,440 So those are a couple of reasons. 1281 00:57:48,440 --> 00:57:50,560 And I mean, I think it's important to point out 1282 00:57:50,560 --> 00:57:53,200 that Ethereum, which does have a more general programming 1283 00:57:53,200 --> 00:57:56,020 language, there are constantly problems popping up 1284 00:57:56,020 --> 00:57:58,440 where people are taking advantage of transact 1285 00:57:58,440 --> 00:58:02,020 of contracts, even fairly well-understood ones-- 1286 00:58:02,020 --> 00:58:04,840 or we thought they were well understood-- 1287 00:58:04,840 --> 00:58:08,260 and figuring out how to freeze people's funds 1288 00:58:08,260 --> 00:58:09,940 or steal people's funds. 1289 00:58:09,940 --> 00:58:12,850 So that's the motivation behind this sort 1290 00:58:12,850 --> 00:58:16,540 of strange, stack-based opcode language. 1291 00:58:16,540 --> 00:58:20,080 Are there any other questions? 1292 00:58:20,080 --> 00:58:21,850 Yeah, back there. 1293 00:58:21,850 --> 00:58:24,780 AUDIENCE: You talked about unspendable transactions 1294 00:58:24,780 --> 00:58:25,280 outputs. 1295 00:58:25,280 --> 00:58:26,990 NEHA NARULA: Outputs, Yes. 1296 00:58:26,990 --> 00:58:29,690 AUDIENCE: Could you comment on colored coins? 1297 00:58:29,690 --> 00:58:31,210 NEHA NARULA: Oh, colored coins-- 1298 00:58:31,210 --> 00:58:32,410 no comment on colored coins. 1299 00:58:32,410 --> 00:58:33,400 I don't understand them well enough 1300 00:58:33,400 --> 00:58:34,630 to talk about them right now. 1301 00:58:34,630 --> 00:58:35,907 Yeah. 1302 00:58:35,907 --> 00:58:36,490 What did you-- 1303 00:58:36,490 --> 00:58:38,198 TADGE DRYJA: I would say one other thing. 1304 00:58:38,198 --> 00:58:41,100 Most of the-- a lot of the cool opcodes are disabled. 1305 00:58:41,100 --> 00:58:43,000 So it's very limited. 1306 00:58:43,000 --> 00:58:43,792 It seems like you-- 1307 00:58:43,792 --> 00:58:45,625 there's a list of, here's all these opcodes. 1308 00:58:45,625 --> 00:58:47,210 Oh, I can multiply numbers together. 1309 00:58:47,210 --> 00:58:47,877 That's disabled. 1310 00:58:47,877 --> 00:58:48,880 [INAUDIBLE] 1311 00:58:48,880 --> 00:58:49,900 NEHA NARULA: Yeah. 1312 00:58:49,900 --> 00:58:52,180 And I do want to stress, when you're dealing with real 1313 00:58:52,180 --> 00:58:55,050 money-- so not in the lab for this class-- 1314 00:58:55,050 --> 00:58:57,280 you want to stick with very standard scripts. 1315 00:58:57,280 --> 00:58:59,627 You don't want to write super-crazy, weird, tricky 1316 00:58:59,627 --> 00:59:01,210 scripts, or if you do, you want to get 1317 00:59:01,210 --> 00:59:02,850 them vetted very carefully. 1318 00:59:02,850 --> 00:59:03,350 Yes. 1319 00:59:03,350 --> 00:59:06,340 AUDIENCE: Who is disabling and enabling these things? 1320 00:59:06,340 --> 00:59:08,220 NEHA NARULA: Great question. 1321 00:59:08,220 --> 00:59:11,440 So there are two levels at which things can be 1322 00:59:11,440 --> 00:59:13,330 enabled or disabled in Bitcoin. 1323 00:59:13,330 --> 00:59:15,380 So first, there's the validation rules, 1324 00:59:15,380 --> 00:59:18,700 so what makes a transaction valid or not valid. 1325 00:59:18,700 --> 00:59:23,440 Meaning that if a transaction is invalid and it's in a block, 1326 00:59:23,440 --> 00:59:24,850 that whole block is invalid. 1327 00:59:24,850 --> 00:59:27,610 If a transaction is invalid and in a block, and that block 1328 00:59:27,610 --> 00:59:30,850 is in a blockchain, that entire blockchain is invalid. 1329 00:59:30,850 --> 00:59:32,860 So there's that level. 1330 00:59:32,860 --> 00:59:36,070 And we're going to talk about how those rules change 1331 00:59:36,070 --> 00:59:37,360 and who sets those rules. 1332 00:59:37,360 --> 00:59:39,280 But you can consider them sort of, for now, 1333 00:59:39,280 --> 00:59:42,280 being set by the code, the Bitcoin Core-- 1334 00:59:42,280 --> 00:59:45,520 or the Bitcoin software, which specifies what is valid 1335 00:59:45,520 --> 00:59:46,450 and what is invalid. 1336 00:59:46,450 --> 00:59:48,310 But there is another level at which 1337 00:59:48,310 --> 00:59:55,060 you can adjust what ends up getting accepted 1338 00:59:55,060 --> 00:59:56,060 or not accepted. 1339 00:59:56,060 --> 00:59:59,960 And that is what is transmitted over the peer-to-peer network. 1340 00:59:59,960 --> 01:00:03,160 So there are transactions that are valid, but are 1341 01:00:03,160 --> 01:00:05,470 what's known as non-standard. 1342 01:00:05,470 --> 01:00:09,310 And that transaction, if it gets into a block, 1343 01:00:09,310 --> 01:00:10,630 that block is still valid. 1344 01:00:10,630 --> 01:00:13,540 But the nodes in the network, if it sees that transaction, 1345 01:00:13,540 --> 01:00:16,990 won't relay them around. 1346 01:00:16,990 --> 01:00:19,900 So you'd have to be a miner and actually decide, 1347 01:00:19,900 --> 01:00:22,280 I want this transaction in a block, and mine that block. 1348 01:00:22,280 --> 01:00:24,030 And if you do that, everyone will consider 1349 01:00:24,030 --> 01:00:25,870 it a valid block, OK, fine. 1350 01:00:25,870 --> 01:00:28,440 But no one will actually send your transaction around. 1351 01:00:28,440 --> 01:00:30,267 And so if you're not a miner yourself, 1352 01:00:30,267 --> 01:00:32,600 the odds of it getting into the blockchain are very low. 1353 01:00:32,600 --> 01:00:35,710 And so those are the two sets of rules. 1354 01:00:35,710 --> 01:00:39,280 The peer-to-peer rules are more restrictive than the validation 1355 01:00:39,280 --> 01:00:39,780 rules. 1356 01:00:44,010 --> 01:00:46,440 OK, so we already kind of started 1357 01:00:46,440 --> 01:00:48,042 talking about this a little bit-- 1358 01:00:48,042 --> 01:00:49,500 what are the benefits of your UTXOs 1359 01:00:49,500 --> 01:00:51,270 and what are the downsides of UTXOs? 1360 01:00:51,270 --> 01:00:55,382 So one of the benefits of UTXOs is that-- 1361 01:00:55,382 --> 01:01:00,360 do you guys see how they help with replay attacks? 1362 01:01:00,360 --> 01:01:02,075 Sure, I can copy this transaction 1363 01:01:02,075 --> 01:01:04,200 and put multiple out there, but you're only allowed 1364 01:01:04,200 --> 01:01:05,370 to spend an output once. 1365 01:01:05,370 --> 01:01:07,560 And once you consume that output, that's it. 1366 01:01:07,560 --> 01:01:11,260 So you can't really do replay attacks in this model. 1367 01:01:11,260 --> 01:01:13,242 So it's a very sort of elegant way 1368 01:01:13,242 --> 01:01:14,700 of getting rid of the replay attack 1369 01:01:14,700 --> 01:01:19,710 problem without having to store a nonce per account 1370 01:01:19,710 --> 01:01:21,370 in your system. 1371 01:01:21,370 --> 01:01:25,020 Another benefit is that you can actually 1372 01:01:25,020 --> 01:01:28,960 get a little bit better privacy with this UTXO system. 1373 01:01:28,960 --> 01:01:32,940 Because you don't have to use the same public key 1374 01:01:32,940 --> 01:01:34,180 for all of your transactions. 1375 01:01:34,180 --> 01:01:36,910 You can generate new ones every single time, 1376 01:01:36,910 --> 01:01:39,813 and then combine UTXOs from different things into-- 1377 01:01:39,813 --> 01:01:41,980 I mean, you're going to have to combine them anyway, 1378 01:01:41,980 --> 01:01:44,070 even if they did spend at the same public key. 1379 01:01:44,070 --> 01:01:46,133 So why not generate fresh ones all the time? 1380 01:01:46,133 --> 01:01:47,550 And it becomes a little bit harder 1381 01:01:47,550 --> 01:01:50,490 to track who you're spending and who you're paying to. 1382 01:01:50,490 --> 01:01:53,845 In the account-based model, you need to have-- 1383 01:01:53,845 --> 01:01:55,470 it's more likely that all of your funds 1384 01:01:55,470 --> 01:01:59,350 are going to be in one account in order to make a spend. 1385 01:01:59,350 --> 01:02:04,000 Now a downside of UTXOs is that they're complicated. 1386 01:02:04,000 --> 01:02:06,310 So when I first heard about UTXOs 1387 01:02:06,310 --> 01:02:08,890 and I first understood how Bitcoin worked, I was like, 1388 01:02:08,890 --> 01:02:10,270 why does Bitcoin work this way? 1389 01:02:10,270 --> 01:02:11,200 This makes zero sense. 1390 01:02:11,200 --> 01:02:14,500 An account-based model would be so much easier. 1391 01:02:14,500 --> 01:02:17,470 And I mean, I think, for wallet providers 1392 01:02:17,470 --> 01:02:20,020 and for people who are writing user software, 1393 01:02:20,020 --> 01:02:23,510 it is easier to deal with an account-based model than a UTXO 1394 01:02:23,510 --> 01:02:24,340 model. 1395 01:02:24,340 --> 01:02:27,580 Because people who are writing Bitcoin wallet software 1396 01:02:27,580 --> 01:02:30,280 have to keep track of all of your UTXOs 1397 01:02:30,280 --> 01:02:32,320 and then figure out how to combine them 1398 01:02:32,320 --> 01:02:34,390 to get the amount that you want to spend, 1399 01:02:34,390 --> 01:02:38,560 and make sure that they produce what are called change outputs 1400 01:02:38,560 --> 01:02:40,750 the right way, so you don't accidentally 1401 01:02:40,750 --> 01:02:42,910 lose some of your money because you're 1402 01:02:42,910 --> 01:02:44,740 spending an output that has 100 bitcoin 1403 01:02:44,740 --> 01:02:46,660 but you're only paying someone one bitcoin. 1404 01:02:46,660 --> 01:02:49,700 You better make sure you have that 99 bitcoin output in there 1405 01:02:49,700 --> 01:02:50,800 going back to you. 1406 01:02:50,800 --> 01:02:54,717 So it just makes everything a little bit more complicated. 1407 01:02:54,717 --> 01:02:56,800 You can't just spend the amount you want to spend. 1408 01:02:56,800 --> 01:02:58,800 You have to find these outputs, and combine them 1409 01:02:58,800 --> 01:03:03,140 in the right way, and figure all of this stuff out. 1410 01:03:03,140 --> 01:03:05,210 Another problem is around fungibility. 1411 01:03:05,210 --> 01:03:07,670 So this is why I say that bitcoin is not fungible, 1412 01:03:07,670 --> 01:03:10,370 because of these outputs, and the fact that you have 1413 01:03:10,370 --> 01:03:14,330 to point back to the output that you're going to spend, 1414 01:03:14,330 --> 01:03:18,170 which ends up creating what's called a transaction graph. 1415 01:03:18,170 --> 01:03:21,860 So you can sort of see how things are chained together, 1416 01:03:21,860 --> 01:03:25,310 and you can actually discern quite a bit of information 1417 01:03:25,310 --> 01:03:26,990 about what's going on in the network. 1418 01:03:26,990 --> 01:03:31,010 And in fact, the FBI has used the transaction graph 1419 01:03:31,010 --> 01:03:33,140 in some of its cases around Silk Road, 1420 01:03:33,140 --> 01:03:35,250 to see where Bitcoin was moving. 1421 01:03:35,250 --> 01:03:37,460 And there are many companies out there-- 1422 01:03:37,460 --> 01:03:41,330 Chain Analysis, Elliptic, that provide services 1423 01:03:41,330 --> 01:03:45,650 based around the fact that Bitcoin's transaction graph is 1424 01:03:45,650 --> 01:03:49,580 totally open, and so you can see how coins are moving around. 1425 01:03:49,580 --> 01:03:53,450 So in addition to the transaction graph problem, 1426 01:03:53,450 --> 01:03:56,900 you kind of lose this aspect of fungibility in the sense 1427 01:03:56,900 --> 01:04:00,920 that, let's say, that I know that, for whatever reason, 1428 01:04:00,920 --> 01:04:05,180 these coins came from, let's say, I don't know, 1429 01:04:05,180 --> 01:04:08,150 a terrorist or something like that. 1430 01:04:08,150 --> 01:04:11,780 You then know exactly where those coins are going, 1431 01:04:11,780 --> 01:04:14,360 and you can kind of see the chain of transactions 1432 01:04:14,360 --> 01:04:16,310 that come off of those coins. 1433 01:04:16,310 --> 01:04:19,580 And it sort of creates a potential opportunity 1434 01:04:19,580 --> 01:04:21,500 for someone to blacklist coins. 1435 01:04:21,500 --> 01:04:27,040 Or you might decide that you like coins that were produced-- 1436 01:04:27,040 --> 01:04:29,750 that are fresher than other coins. 1437 01:04:29,750 --> 01:04:33,330 So there's this ability to distinguish between coins, 1438 01:04:33,330 --> 01:04:35,150 which is a little bit troublesome, 1439 01:04:35,150 --> 01:04:37,580 because fungibility is generally considered 1440 01:04:37,580 --> 01:04:39,590 a very good property for money to have, 1441 01:04:39,590 --> 01:04:41,238 and this is not entirely fungible. 1442 01:04:41,238 --> 01:04:42,530 But people are working on that. 1443 01:04:46,160 --> 01:04:49,070 Any other questions? 1444 01:04:49,070 --> 01:04:52,120 I alluded to this earlier, but every single node 1445 01:04:52,120 --> 01:04:53,770 that's running the Bitcoin software 1446 01:04:53,770 --> 01:04:56,500 keeps this data structure called the UTXO set. 1447 01:04:56,500 --> 01:05:00,160 So these are all of the outstanding, unspent 1448 01:05:00,160 --> 01:05:01,300 transaction outputs. 1449 01:05:01,300 --> 01:05:03,550 It's all of the coins in the system, all 1450 01:05:03,550 --> 01:05:07,780 of the money in the system that's available to be spent. 1451 01:05:07,780 --> 01:05:09,880 The way that this is computed is, 1452 01:05:09,880 --> 01:05:12,790 when a Bitcoin node comes online and starts 1453 01:05:12,790 --> 01:05:16,420 to download the blockchain, they run through the blockchain 1454 01:05:16,420 --> 01:05:18,190 and continuously add and remove things 1455 01:05:18,190 --> 01:05:21,760 from the UTXO set to produce a UTXO 1456 01:05:21,760 --> 01:05:24,010 set that is valid for whatever the last block is 1457 01:05:24,010 --> 01:05:25,330 that it's seen. 1458 01:05:25,330 --> 01:05:29,230 When a new block comes in, a node runs through the block, 1459 01:05:29,230 --> 01:05:31,810 and again removes and adds things 1460 01:05:31,810 --> 01:05:35,770 to the UTXO set as necessary. 1461 01:05:35,770 --> 01:05:42,190 Right now, there's about 60 million UTXOs in the UTXO set. 1462 01:05:42,190 --> 01:05:46,690 A lot of them, unfortunately-- well, a lot, 1463 01:05:46,690 --> 01:05:50,260 in terms of bytes of the UTXO set, a lot of them 1464 01:05:50,260 --> 01:05:53,480 are very small and are unlikely to get spent very soon. 1465 01:05:53,480 --> 01:05:54,910 So that's kind of a bummer. 1466 01:05:54,910 --> 01:05:58,530 The UTXO set is about three gigabytes right now, I think. 1467 01:05:58,530 --> 01:06:01,180 And so every node in Bitcoin, in addition 1468 01:06:01,180 --> 01:06:05,230 to storing the blockchain, stores this UTXO set, 1469 01:06:05,230 --> 01:06:08,740 and uses this data structure to very quickly tell 1470 01:06:08,740 --> 01:06:13,780 if a transaction is a double-spend or not. 1471 01:06:13,780 --> 01:06:15,340 Any questions about the UTXO set? 1472 01:06:15,340 --> 01:06:16,183 Yes, SJ. 1473 01:06:16,183 --> 01:06:18,350 AUDIENCE: How do you avoid having small transactions 1474 01:06:18,350 --> 01:06:20,198 accumulate over time? 1475 01:06:20,198 --> 01:06:21,740 NEHA NARULA: That's a good question-- 1476 01:06:21,740 --> 01:06:24,100 how do you avoid having small transactions accumulate 1477 01:06:24,100 --> 01:06:25,180 over time? 1478 01:06:25,180 --> 01:06:27,323 I don't know the answer to that question. 1479 01:06:27,323 --> 01:06:28,240 It's kind of a bummer. 1480 01:06:30,910 --> 01:06:32,860 It's not really in people's interest 1481 01:06:32,860 --> 01:06:36,370 to generate those transactions because you're creating-- 1482 01:06:36,370 --> 01:06:39,280 I haven't talked about how fees are computed yet. 1483 01:06:39,280 --> 01:06:43,840 But fees are measured according to the resources 1484 01:06:43,840 --> 01:06:45,790 that a transaction takes up in the system. 1485 01:06:45,790 --> 01:06:48,260 Fees are measured according to the size of the transaction. 1486 01:06:48,260 --> 01:06:53,260 So if you have to combine a whole bunch of tiny outputs 1487 01:06:53,260 --> 01:06:54,760 in order to get a big enough sum, 1488 01:06:54,760 --> 01:06:57,280 you're going to have to pay more in fees. 1489 01:06:57,280 --> 01:06:59,530 So it's not really in your interest 1490 01:06:59,530 --> 01:07:01,420 to produce a lot of these tiny things. 1491 01:07:01,420 --> 01:07:04,388 But there's not really a good way of stopping it. 1492 01:07:04,388 --> 01:07:06,430 And in fact there have been services in the past, 1493 01:07:06,430 --> 01:07:08,290 like Satoshi dice and whatnot, that 1494 01:07:08,290 --> 01:07:12,130 have created a ton of very tiny outputs 1495 01:07:12,130 --> 01:07:14,212 and it bloated the UTXO set. 1496 01:07:14,212 --> 01:07:16,420 I don't know, Tadge, if you have any insight into how 1497 01:07:16,420 --> 01:07:18,293 to stop that from happening. 1498 01:07:18,293 --> 01:07:19,710 TADGE DRYJA: Make the fees higher. 1499 01:07:19,710 --> 01:07:21,127 NEHA NARULA: Other than the fees-- 1500 01:07:21,127 --> 01:07:22,630 other than the fees, yeah. 1501 01:07:22,630 --> 01:07:24,140 TADGE DRYJA: Better wallet software. 1502 01:07:24,140 --> 01:07:28,732 A lot of it's [? unintentional. ?] 1503 01:07:28,732 --> 01:07:29,440 NEHA NARULA: Yes. 1504 01:07:29,440 --> 01:07:32,023 AUDIENCE: You mentioned that one other [INAUDIBLE] is privacy, 1505 01:07:32,023 --> 01:07:35,450 and you need to generate new pubkeys. 1506 01:07:35,450 --> 01:07:39,120 But would this prevent you, in the account-based model, 1507 01:07:39,120 --> 01:07:42,740 prevent from getting an account? 1508 01:07:42,740 --> 01:07:44,137 NEHA NARULA: Yeah. 1509 01:07:44,137 --> 01:07:45,970 So I'm not sure in the account-based model-- 1510 01:07:45,970 --> 01:07:49,210 we'll find out more about this when we get to the Ethereum 1511 01:07:49,210 --> 01:07:50,650 section of the class-- 1512 01:07:50,650 --> 01:07:53,930 how you combine spending from different accounts. 1513 01:07:53,930 --> 01:07:57,010 But Bitcoin makes it very easy to combine spending 1514 01:07:57,010 --> 01:07:58,340 from different pubkeys. 1515 01:07:58,340 --> 01:07:59,380 In the account-based model, I could 1516 01:07:59,380 --> 01:08:01,600 imagine it being a slightly more complicated process. 1517 01:08:01,600 --> 01:08:02,660 But that's a good point. 1518 01:08:02,660 --> 01:08:04,660 Yes, you could definitely create a lot of accounts 1519 01:08:04,660 --> 01:08:05,827 with a lot of small balance. 1520 01:08:05,827 --> 01:08:07,450 But if you want to spend a lot, you're 1521 01:08:07,450 --> 01:08:09,400 going to have to somehow accumulate 1522 01:08:09,400 --> 01:08:11,243 all of that spending. 1523 01:08:11,243 --> 01:08:12,660 Remember, I talked about how there 1524 01:08:12,660 --> 01:08:17,370 is one special transaction in every block, called 1525 01:08:17,370 --> 01:08:18,450 the coinbase transaction. 1526 01:08:18,450 --> 01:08:19,867 And this transaction does not have 1527 01:08:19,867 --> 01:08:22,649 to follow all of the rules specified before. 1528 01:08:22,649 --> 01:08:25,170 So this is kind of like a hard-coded exception 1529 01:08:25,170 --> 01:08:26,670 into how Bitcoin works, that there 1530 01:08:26,670 --> 01:08:29,069 can be this one transaction in every block, 1531 01:08:29,069 --> 01:08:30,540 called the coinbase transaction. 1532 01:08:30,540 --> 01:08:32,260 It is the first transaction. 1533 01:08:32,260 --> 01:08:36,090 The coinbase transaction has exactly one input. 1534 01:08:36,090 --> 01:08:40,170 And that input needs to have certain feel. 1535 01:08:40,170 --> 01:08:44,220 This input does not point to a previous output. 1536 01:08:44,220 --> 01:08:47,890 This input is essentially empty. 1537 01:08:47,890 --> 01:08:51,670 This is the transaction that doles out the block reward. 1538 01:08:51,670 --> 01:08:54,430 So this is the transaction that-- 1539 01:08:54,430 --> 01:08:57,319 the block reward used to be 50 bitcoins-- 1540 01:08:57,319 --> 01:09:01,359 25 bitcoins, 50 bitcoins, now it's 12.5 bitcoins per block. 1541 01:09:01,359 --> 01:09:05,229 This is the transaction that doles out that 12.5 bitcoins 1542 01:09:05,229 --> 01:09:09,189 plus the fees of the block. 1543 01:09:09,189 --> 01:09:11,500 So it has exactly one input. 1544 01:09:11,500 --> 01:09:16,720 And that input has all zeros for the previous transaction ID. 1545 01:09:16,720 --> 01:09:20,574 And then FFFFF for the index into that previous transaction 1546 01:09:20,574 --> 01:09:22,090 ID. 1547 01:09:22,090 --> 01:09:25,270 I think the scriptSig can basically be whatever you want. 1548 01:09:25,270 --> 01:09:27,850 It's not evaluated. 1549 01:09:27,850 --> 01:09:28,960 It might have to be valid. 1550 01:09:28,960 --> 01:09:30,260 I'm not sure. 1551 01:09:30,260 --> 01:09:34,420 And then its output is in Satoshis. 1552 01:09:34,420 --> 01:09:37,330 So this is 12.5 Bitcoin. 1553 01:09:37,330 --> 01:09:41,170 Because remember, a Bitcoin is 10 to the eighth Satoshis. 1554 01:09:41,170 --> 01:09:43,720 So this is 12.5 bitcoin, plus here 1555 01:09:43,720 --> 01:09:45,910 are the fees from that block. 1556 01:09:45,910 --> 01:09:49,080 And you probably, if you're the one-- 1557 01:09:49,080 --> 01:09:51,760 so the miner is the one who creates this transaction. 1558 01:09:51,760 --> 01:09:56,530 And the miner who creates this transaction probably 1559 01:09:56,530 --> 01:10:00,770 wants to give themselves the Bitcoin and the block reward, 1560 01:10:00,770 --> 01:10:03,630 and so would specify, in here, a scriptPubKey 1561 01:10:03,630 --> 01:10:04,750 that they could redeem. 1562 01:10:07,660 --> 01:10:10,067 Note that this also has the nice property of making-- 1563 01:10:10,067 --> 01:10:11,650 well, I don't if it's a nice property, 1564 01:10:11,650 --> 01:10:14,350 but all the blocks that people work on are actually different. 1565 01:10:14,350 --> 01:10:16,682 Because in each block, the coinbase transaction 1566 01:10:16,682 --> 01:10:18,640 is going to be different because each person is 1567 01:10:18,640 --> 01:10:21,280 trying to pay themselves for-- the different miners. 1568 01:10:21,280 --> 01:10:21,845 Yes. 1569 01:10:21,845 --> 01:10:24,777 AUDIENCE: What's [INAUDIBLE] them to 12.5 bitcoins? 1570 01:10:24,777 --> 01:10:26,110 NEHA NARULA: Ah, great question. 1571 01:10:26,110 --> 01:10:28,780 So what would happen if a miner put, 1572 01:10:28,780 --> 01:10:30,480 like, 100 bitcoins in there? 1573 01:10:30,480 --> 01:10:31,115 Any idea? 1574 01:10:37,560 --> 01:10:41,010 So what's keeping that at 12.5 bitcoins 1575 01:10:41,010 --> 01:10:44,220 is the same thing that's keeping invalid transactions out 1576 01:10:44,220 --> 01:10:48,720 of the blockchain, which is the consensus rules of Bitcoin. 1577 01:10:48,720 --> 01:10:52,980 It says in the code that, at this point in time, given 1578 01:10:52,980 --> 01:10:56,280 the block height where we are, that number 1579 01:10:56,280 --> 01:11:00,000 should be no larger than 12.5 plus the fees 1580 01:11:00,000 --> 01:11:02,510 in the transaction. 1581 01:11:02,510 --> 01:11:06,400 And if a miner put a different number in there-- 1582 01:11:06,400 --> 01:11:09,220 they can put a lower number, that's fine. 1583 01:11:09,220 --> 01:11:11,810 They'll end up burning some Bitcoin, which is unfortunate. 1584 01:11:11,810 --> 01:11:15,730 But if they try to put something higher in there, 1585 01:11:15,730 --> 01:11:18,340 the network will regard it as invalid, 1586 01:11:18,340 --> 01:11:20,920 because the network is running a set of rules. 1587 01:11:20,920 --> 01:11:23,440 And we are, in this class, going to get 1588 01:11:23,440 --> 01:11:26,740 to what happens when you want to change that set of rules, which 1589 01:11:26,740 --> 01:11:28,090 gets really tricky. 1590 01:11:28,090 --> 01:11:31,720 But right now, assume that the network 1591 01:11:31,720 --> 01:11:34,120 is running the set of rules, they're all checking, 1592 01:11:34,120 --> 01:11:35,085 they're all validating. 1593 01:11:35,085 --> 01:11:36,460 And so the answer is, the network 1594 01:11:36,460 --> 01:11:41,930 would reject this block if there was a higher number in there. 1595 01:11:41,930 --> 01:11:44,470 So this is kind of fun, because you can sort of 1596 01:11:44,470 --> 01:11:45,790 put whatever you want in here. 1597 01:11:45,790 --> 01:11:49,750 And so miners like to put advertisements in there. 1598 01:11:49,750 --> 01:11:51,965 And there actually was a period, there was a time-- 1599 01:11:51,965 --> 01:11:53,590 I don't know if you can still do this-- 1600 01:11:53,590 --> 01:11:56,758 where you could literally buy this space from miners, 1601 01:11:56,758 --> 01:11:58,300 and put whatever you wanted in there. 1602 01:11:58,300 --> 01:12:02,230 So you could put your name, or ask someone to marry you, 1603 01:12:02,230 --> 01:12:04,360 or whatever you might want to do, 1604 01:12:04,360 --> 01:12:07,210 to put in the Bitcoin blockchain for all eternity. 1605 01:12:07,210 --> 01:12:13,510 But yeah, so miners like to put fun things in the scriptSig. 1606 01:12:13,510 --> 01:12:16,570 And maybe we could show them some of those things later. 1607 01:12:16,570 --> 01:12:18,930 Or you could go look yourself.