WEBVTT 00:00:01.240 --> 00:00:03.580 The following content is provided under a Creative 00:00:03.580 --> 00:00:04.970 Commons license. 00:00:04.970 --> 00:00:07.180 Your support will help MIT OpenCourseWare 00:00:07.180 --> 00:00:11.270 continue to offer high-quality educational resources for free. 00:00:11.270 --> 00:00:13.840 To make a donation or to view additional materials 00:00:13.840 --> 00:00:17.800 from hundreds of MIT courses, visit MIT OpenCourseWare 00:00:17.800 --> 00:00:18.680 at ocw.mit.edu. 00:00:23.360 --> 00:00:25.040 NEHA NARULA: OK, let's get started. 00:00:25.040 --> 00:00:28.740 I hope everybody had a great long weekend. 00:00:28.740 --> 00:00:31.760 So I'm teaching today, and today we're 00:00:31.760 --> 00:00:33.990 going to be talking about transactions. 00:00:33.990 --> 00:00:38.680 So just to recap where we've been so far, 00:00:38.680 --> 00:00:42.260 Tadge just sort of explained signatures in Bitcoin, 00:00:42.260 --> 00:00:46.598 in particular RSA and ECDSA, and told us a little bit 00:00:46.598 --> 00:00:47.390 about Merkle trees. 00:00:47.390 --> 00:00:50.600 And so these are some of the underlying primitives 00:00:50.600 --> 00:00:52.580 that we need to know about in order 00:00:52.580 --> 00:00:55.430 to understand how most of the blockchains today 00:00:55.430 --> 00:00:56.865 are constructed. 00:00:56.865 --> 00:00:59.240 So we've spent a bit of time talking about the underlying 00:00:59.240 --> 00:01:03.440 primitives, now let's start to put them together a little bit 00:01:03.440 --> 00:01:06.740 to understand what goes into a blockchain. 00:01:06.740 --> 00:01:09.623 So if you recall, this is a slide 00:01:09.623 --> 00:01:10.790 that Tadge has shown before. 00:01:10.790 --> 00:01:13.600 And I'm really sorry about this quadrant, but I don't know, 00:01:13.600 --> 00:01:15.560 I don't think I can control this individually. 00:01:15.560 --> 00:01:18.558 So we'll definitely post the slides of course, 00:01:18.558 --> 00:01:20.600 but let me know if something is really confusing. 00:01:20.600 --> 00:01:22.370 Just raise your hand. 00:01:22.370 --> 00:01:25.320 So this is something that you guys have seen before, 00:01:25.320 --> 00:01:27.980 and it's like a very sort of rough approximation 00:01:27.980 --> 00:01:29.840 of a hash chain. 00:01:29.840 --> 00:01:31.970 So what we have here is we have-- 00:01:31.970 --> 00:01:33.980 this doesn't actually show the previous, 00:01:33.980 --> 00:01:36.230 but what we have here is we have some message, 00:01:36.230 --> 00:01:38.930 we have a nonce, such that when you hash these three 00:01:38.930 --> 00:01:41.660 things together, you get this hash value, 00:01:41.660 --> 00:01:44.330 which has a certain number of leading zeros at the beginning. 00:01:44.330 --> 00:01:46.490 In this case, it's two leading zeros. 00:01:46.490 --> 00:01:48.800 And when we construct the next block, 00:01:48.800 --> 00:01:52.310 we implicitly point to this previous block 00:01:52.310 --> 00:01:57.860 by including that hash inside of this when we produce this hash. 00:01:57.860 --> 00:02:00.980 So note that there isn't actually 00:02:00.980 --> 00:02:03.590 a physical pointer or a memory address 00:02:03.590 --> 00:02:06.320 pointer type thing connecting these two things together. 00:02:06.320 --> 00:02:08.180 And note that this block does not actually 00:02:08.180 --> 00:02:11.600 contain the hash of itself. 00:02:11.600 --> 00:02:14.270 But we are sort of implicitly pointing to this 00:02:14.270 --> 00:02:18.650 by including the hash of this block in the following block. 00:02:18.650 --> 00:02:22.040 And so on over here-- again, this is a different message, 00:02:22.040 --> 00:02:24.140 a different nonce, and it includes 00:02:24.140 --> 00:02:27.170 the hash of this block instead of the one before. 00:02:27.170 --> 00:02:29.480 And by including the hash of this block, 00:02:29.480 --> 00:02:32.390 it's also implicitly including the hash of this block, 00:02:32.390 --> 00:02:34.020 because that's right here. 00:02:34.020 --> 00:02:38.210 And so what we're going to see is that if you change anything 00:02:38.210 --> 00:02:41.550 about the previous blocks in the blockchain-- for example, 00:02:41.550 --> 00:02:43.170 if you change this message-- 00:02:43.170 --> 00:02:47.065 then you're going to need to change the nonce in order 00:02:47.065 --> 00:02:48.440 to get the hash to compute right. 00:02:48.440 --> 00:02:49.940 That's going to be a different hash. 00:02:49.940 --> 00:02:52.740 And that change is going to trickle down 00:02:52.740 --> 00:02:53.990 through the entire blockchain. 00:02:53.990 --> 00:02:55.740 And so that's what makes these things what 00:02:55.740 --> 00:02:59.510 we call tamper-proof, the fact that there are these hashes, 00:02:59.510 --> 00:03:02.120 these hashes are collision-resistant. 00:03:02.120 --> 00:03:08.600 And so it's very difficult. You can't change what's in the past 00:03:08.600 --> 00:03:12.690 without having it reflected in the future. 00:03:12.690 --> 00:03:14.870 So now let's go into a little bit more 00:03:14.870 --> 00:03:19.730 detail about exactly what this message thing is. 00:03:19.730 --> 00:03:21.872 We've talked about the previous hash pointers, 00:03:21.872 --> 00:03:23.330 we've talked about the nonce, we've 00:03:23.330 --> 00:03:24.560 talked about proof of work. 00:03:24.560 --> 00:03:26.840 But what actually goes inside of a block? 00:03:26.840 --> 00:03:28.658 Well, we have this general-- we've 00:03:28.658 --> 00:03:30.200 kind of been alluding to it, but what 00:03:30.200 --> 00:03:32.510 goes inside a block are transactions. 00:03:32.510 --> 00:03:34.580 We're trying to build a payment system here. 00:03:34.580 --> 00:03:38.270 So what do we need to have in a transaction? 00:03:38.270 --> 00:03:39.770 What should a transaction look like? 00:03:42.500 --> 00:03:43.377 Yes. 00:03:43.377 --> 00:03:44.840 AUDIENCE: Inputs and outputs. 00:03:44.840 --> 00:03:46.640 NEHA NARULA: OK, inputs and outputs. 00:03:46.640 --> 00:03:49.160 Maybe even like a higher level here, semantically, 00:03:49.160 --> 00:03:52.524 what do we want in a transaction? 00:03:52.524 --> 00:03:53.460 Yep. 00:03:53.460 --> 00:03:56.190 AUDIENCE: A sender, a receiver, an amount, like a message. 00:03:56.190 --> 00:03:59.180 NEHA NARULA: OK, a sender, a receiver, an amount. 00:03:59.180 --> 00:04:00.368 Anybody else? 00:04:00.368 --> 00:04:02.240 AUDIENCE: Transaction ID. 00:04:02.240 --> 00:04:05.270 NEHA NARULA: OK, an ID, some way of referencing it. 00:04:05.270 --> 00:04:07.150 Anybody else. 00:04:07.150 --> 00:04:07.785 Yep. 00:04:07.785 --> 00:04:11.260 AUDIENCE: A proof that it's a legit transaction. 00:04:11.260 --> 00:04:14.520 NEHA NARULA: A proof that it's a legit transaction, right, 00:04:14.520 --> 00:04:15.310 exactly. 00:04:15.310 --> 00:04:18.130 So what we need is those things that you guys just said. 00:04:18.130 --> 00:04:20.529 We need to know the amount, how much of this coin 00:04:20.529 --> 00:04:23.620 we're transferring, we need to know where it's coming from, 00:04:23.620 --> 00:04:26.740 and in particular we need an authorization of some sort 00:04:26.740 --> 00:04:29.792 that that user actually authorized the spend, 00:04:29.792 --> 00:04:31.000 and we need who we're paying. 00:04:31.000 --> 00:04:33.190 And so unfortunately this is in the dark part, 00:04:33.190 --> 00:04:37.240 but this is sort of a little rough sketch of a transaction. 00:04:37.240 --> 00:04:40.900 And we have Alice who's spending $5.00 to Bob, 00:04:40.900 --> 00:04:43.915 and we have this authorization here. 00:04:43.915 --> 00:04:46.540 And this authorization, given we just learned about signatures, 00:04:46.540 --> 00:04:48.670 signatures are a great way to do authorization 00:04:48.670 --> 00:04:52.030 because it's something that only Alice can produce. 00:04:52.030 --> 00:04:53.650 So I don't know if you can see this, 00:04:53.650 --> 00:04:55.067 but there are question marks here. 00:04:55.067 --> 00:04:58.570 So what should Alice sign to show that she 00:04:58.570 --> 00:05:00.162 authorized this transaction? 00:05:00.162 --> 00:05:01.870 What do you think would be a good thing-- 00:05:01.870 --> 00:05:04.750 what is a good message for her to sign 00:05:04.750 --> 00:05:08.890 for her to indicate her authority, her desire 00:05:08.890 --> 00:05:11.840 to produce this transaction and spend her funds? 00:05:11.840 --> 00:05:13.822 AUDIENCE: Private key. 00:05:13.822 --> 00:05:15.030 NEHA NARULA: Her private key? 00:05:15.030 --> 00:05:15.910 AUDIENCE: Yeah. 00:05:15.910 --> 00:05:17.785 NEHA NARULA: She should sign her private key? 00:05:17.785 --> 00:05:18.397 OK. 00:05:18.397 --> 00:05:20.230 AUDIENCE: [INAUDIBLE] the whole transaction. 00:05:20.230 --> 00:05:24.220 NEHA NARULA: The whole transaction, OK. 00:05:24.220 --> 00:05:26.270 So let's talk about signing the private key. 00:05:26.270 --> 00:05:29.710 Let's say that she did sign her private key. 00:05:29.710 --> 00:05:32.043 The problem with a signature is that, in order 00:05:32.043 --> 00:05:33.460 to tell if the signature is valid, 00:05:33.460 --> 00:05:35.290 you need the thing that you signed. 00:05:35.290 --> 00:05:38.038 So she would have to include her private key, which would then 00:05:38.038 --> 00:05:40.330 share her private key with everyone, which isn't really 00:05:40.330 --> 00:05:42.790 a good way for her to use her public and private key. 00:05:42.790 --> 00:05:45.840 She could certainly sign the transaction. 00:05:45.840 --> 00:05:48.040 And the nice thing about signing the transaction-- 00:05:48.040 --> 00:05:50.680 this is all blue, indicating that she's signing it-- 00:05:50.680 --> 00:05:54.340 is that she's signing all three of these things as well. 00:05:54.340 --> 00:05:57.730 She's saying, I want to pay Bob, I want to pay Bob $5. 00:05:57.730 --> 00:06:02.390 Now what's the problem with signing the transaction? 00:06:02.390 --> 00:06:02.890 Yes. 00:06:02.890 --> 00:06:05.130 AUDIENCE: Couldn't you just keep using it if you were Bob? 00:06:05.130 --> 00:06:07.380 NEHA NARULA: So that is an excellent point-- you could 00:06:07.380 --> 00:06:08.730 keep using it if you were Bob. 00:06:08.730 --> 00:06:10.590 And we'll get into that a little bit later. 00:06:10.590 --> 00:06:13.410 But another problem here is, the way 00:06:13.410 --> 00:06:15.898 that I've shown it right now, she's signing the signature. 00:06:15.898 --> 00:06:17.940 The signature is kind of part of the transaction. 00:06:17.940 --> 00:06:20.502 And so you want to make sure that you're not-- 00:06:20.502 --> 00:06:21.960 when you sign a transaction, you're 00:06:21.960 --> 00:06:24.120 signing everything but the signature, right, 00:06:24.120 --> 00:06:26.277 because you can't produce the signature. 00:06:26.277 --> 00:06:28.110 You can't sign the signature without knowing 00:06:28.110 --> 00:06:29.117 what the signature is. 00:06:29.117 --> 00:06:31.200 It would be like a whole new type of proof of work 00:06:31.200 --> 00:06:32.040 on the transaction. 00:06:32.040 --> 00:06:33.540 So I don't know if you can see this, 00:06:33.540 --> 00:06:36.030 but this says transaction minus signature. 00:06:36.030 --> 00:06:39.630 And in fact, we can even make that a little bit easier 00:06:39.630 --> 00:06:43.170 by turning that into a hash of the transaction, 00:06:43.170 --> 00:06:44.670 not including the signature. 00:06:44.670 --> 00:06:46.440 Because that sort of brings the message 00:06:46.440 --> 00:06:49.090 down to a smaller thing. 00:06:49.090 --> 00:06:52.440 And from what we know about hash functions you can't really, 00:06:52.440 --> 00:06:57.033 given a message and a hash of that message, 00:06:57.033 --> 00:06:58.950 it's difficult to produce another message that 00:06:58.950 --> 00:07:00.210 would hash to the same thing. 00:07:00.210 --> 00:07:03.120 So this hash serves as kind of an identifier 00:07:03.120 --> 00:07:04.870 for the transaction as a whole. 00:07:04.870 --> 00:07:08.250 In fact, Bitcoin uses the hash of this as the transaction ID. 00:07:08.250 --> 00:07:10.410 So this is how we refer to transactions. 00:07:10.410 --> 00:07:12.060 And it's a nice small thing to sign, 00:07:12.060 --> 00:07:18.120 which indicates Alice's intent to spend her funds. 00:07:18.120 --> 00:07:21.690 So one thing that I kind of want to go into a little bit 00:07:21.690 --> 00:07:24.060 is that there's a couple different ways for thinking 00:07:24.060 --> 00:07:26.370 about transactions, and what transactions actually 00:07:26.370 --> 00:07:28.200 look like, and how they're stored, 00:07:28.200 --> 00:07:30.420 and how we sort of specify coins. 00:07:30.420 --> 00:07:35.070 And the most natural model, to me, anyway, not to everybody, 00:07:35.070 --> 00:07:37.920 perhaps, is what I call the account-based model. 00:07:37.920 --> 00:07:40.350 So it's kind of like what we were doing before, 00:07:40.350 --> 00:07:41.910 when we saw the banks, and we were 00:07:41.910 --> 00:07:43.800 talking about banks keeping track 00:07:43.800 --> 00:07:45.368 of how much funds people have. 00:07:45.368 --> 00:07:47.910 And this is sort of how you and I might think of our own bank 00:07:47.910 --> 00:07:48.630 accounts. 00:07:48.630 --> 00:07:50.838 I think in my bank account as having a certain amount 00:07:50.838 --> 00:07:51.930 of funds in it. 00:07:51.930 --> 00:07:54.000 And so in the account-based model, 00:07:54.000 --> 00:07:57.840 users have certain amounts or balances associated 00:07:57.840 --> 00:08:00.120 with their usernames. 00:08:00.120 --> 00:08:04.380 And when a transaction comes in, like Alice wants to give $5.00 00:08:04.380 --> 00:08:07.890 to Bob, then what might happen is that the nodes 00:08:07.890 --> 00:08:11.040 in the network which are all maintaining, in a unified way, 00:08:11.040 --> 00:08:13.320 this balance sheet, will end up saying, OK, 00:08:13.320 --> 00:08:15.660 Alice had 10 and Bob had zero. 00:08:15.660 --> 00:08:17.340 Alice wants to give $5.00 to Bob. 00:08:17.340 --> 00:08:20.370 Let's subtract $5.00 from Alice's account and give it 00:08:20.370 --> 00:08:21.090 to Bob. 00:08:21.090 --> 00:08:23.160 And so what the nodes would do here 00:08:23.160 --> 00:08:25.740 to see if this transaction was valid would be 00:08:25.740 --> 00:08:27.600 they would check the signature to make sure 00:08:27.600 --> 00:08:30.780 that Alice actually authorized this transaction, 00:08:30.780 --> 00:08:32.880 and they would also make sure that Alice 00:08:32.880 --> 00:08:34.590 had the funds to spend. 00:08:34.590 --> 00:08:38.460 And in the account-based model, the way 00:08:38.460 --> 00:08:40.740 that you check to see if Alice has the funds 00:08:40.740 --> 00:08:42.990 to spend as you literally look at her balance, 00:08:42.990 --> 00:08:45.090 and you look at the amount she wants to spend, 00:08:45.090 --> 00:08:48.150 and you make sure that if she spends that amount, 00:08:48.150 --> 00:08:50.160 the balance won't go below zero. 00:08:50.160 --> 00:08:54.180 So this is actually the model that Ethereum uses. 00:08:54.180 --> 00:08:57.450 It's not the model that Bitcoin uses. 00:08:57.450 --> 00:08:59.520 So just sort of to summarize, you 00:08:59.520 --> 00:09:01.690 store a list of accounts and balances, 00:09:01.690 --> 00:09:05.580 a transaction is valid if there is a balance in the account, 00:09:05.580 --> 00:09:07.890 and then when a transaction is processed, 00:09:07.890 --> 00:09:11.400 you debit the sender and credit the receiver-- so 00:09:11.400 --> 00:09:15.140 very straightforward. 00:09:15.140 --> 00:09:17.970 So like I said, this is a way Ethereum works, 00:09:17.970 --> 00:09:19.950 and it's a little bit more natural, 00:09:19.950 --> 00:09:21.240 I think, to think about. 00:09:21.240 --> 00:09:23.560 But this is not the way Bitcoin works, actually. 00:09:23.560 --> 00:09:25.680 Bitcoin has a very different model 00:09:25.680 --> 00:09:28.770 of coins and of transactions. 00:09:28.770 --> 00:09:33.210 And I think-- when I was learning about how Bitcoin 00:09:33.210 --> 00:09:35.490 worked and how Ethereum worked, I 00:09:35.490 --> 00:09:37.410 found Bitcoin's model a little bit unnatural 00:09:37.410 --> 00:09:40.350 until I went through this exercise of thinking 00:09:40.350 --> 00:09:42.700 about something called replay attacks. 00:09:42.700 --> 00:09:45.810 And this is what [? Issan ?] mentioned earlier, which 00:09:45.810 --> 00:09:47.940 is when you have this transaction, 00:09:47.940 --> 00:09:51.750 and you send it to the network, and the network 00:09:51.750 --> 00:09:54.380 processes the transaction and debits Alice and credits 00:09:54.380 --> 00:09:59.280 Bob, what is to prevent a malicious agent from noticing 00:09:59.280 --> 00:10:02.550 that transaction and rebroadcasting it again 00:10:02.550 --> 00:10:05.610 to the network, so basically repeatedly debiting 00:10:05.610 --> 00:10:09.090 Alice until she doesn't have any funds left. 00:10:09.090 --> 00:10:13.050 So can you guys think of a way to maybe get around this? 00:10:13.050 --> 00:10:13.920 What would you do? 00:10:13.920 --> 00:10:17.480 How would you prevent this replay attack? 00:10:17.480 --> 00:10:18.060 Yeah. 00:10:18.060 --> 00:10:21.770 AUDIENCE: She can add a specific ID to the time, for instance, 00:10:21.770 --> 00:10:25.490 [INAUDIBLE] 00:10:25.490 --> 00:10:28.150 NEHA NARULA: So one thing is adding a time, sure. 00:10:28.150 --> 00:10:31.780 Time is a little bit tricky because of the nature 00:10:31.780 --> 00:10:34.190 of the system. 00:10:34.190 --> 00:10:36.370 But a time is a pretty good idea. 00:10:36.370 --> 00:10:38.800 A unique number of some kind certainly 00:10:38.800 --> 00:10:41.920 would help, because that way if you saw a transaction 00:10:41.920 --> 00:10:44.890 with the same number, then you'd know, 00:10:44.890 --> 00:10:46.702 OK, this transaction has been seen before. 00:10:46.702 --> 00:10:47.410 This is a repeat. 00:10:47.410 --> 00:10:48.910 This is a rebroadcast. 00:10:48.910 --> 00:10:52.160 This is not something I should process. 00:10:52.160 --> 00:10:55.930 So Ethereum actually does something like this. 00:10:55.930 --> 00:11:00.580 There is this number included in every transaction. 00:11:00.580 --> 00:11:03.100 But the tricky part about the way that Ethereum does this-- 00:11:03.100 --> 00:11:04.690 and we're going to learn more about Ethereum later 00:11:04.690 --> 00:11:06.610 on in the course, we're going to have a guest lecturer come 00:11:06.610 --> 00:11:07.990 in and teach us about that-- 00:11:07.990 --> 00:11:11.500 is that it requires you to keep track of all of the numbers 00:11:11.500 --> 00:11:12.220 you've seen. 00:11:12.220 --> 00:11:15.760 And you have to do this per user. 00:11:15.760 --> 00:11:17.500 And so all the nodes in the network 00:11:17.500 --> 00:11:20.350 have to keep track of all of the nonces 00:11:20.350 --> 00:11:23.080 that they've seen per user. 00:11:23.080 --> 00:11:26.710 And so if a user uses Ethereum once and then goes away, 00:11:26.710 --> 00:11:29.530 all of the nodes have to keep that state forever, 00:11:29.530 --> 00:11:32.590 essentially, just in case someone 00:11:32.590 --> 00:11:35.230 comes back and rebroadcasts another transaction. 00:11:35.230 --> 00:11:38.940 So Bitcoin, like I said, and I keep saying, does something. 00:11:38.940 --> 00:11:41.680 And there's nothing wrong with this model. 00:11:41.680 --> 00:11:43.180 We'll sort of compare and contrast. 00:11:43.180 --> 00:11:44.890 Like I said, it's what Ethereum uses. 00:11:44.890 --> 00:11:47.182 But I think that this is part of the motivation for why 00:11:47.182 --> 00:11:49.240 Bitcoin was designed the way that it was. 00:11:49.240 --> 00:11:53.200 And so Bitcoin uses this idea called unspent transaction 00:11:53.200 --> 00:11:54.220 outputs. 00:11:54.220 --> 00:11:57.220 So you'll notice, over here, we don't have 00:11:57.220 --> 00:12:00.430 any notion of a coin, per se. 00:12:00.430 --> 00:12:01.900 There are just amounts, and amounts 00:12:01.900 --> 00:12:03.340 are debited and credited. 00:12:03.340 --> 00:12:06.520 And if Alice spends to Bob, and Alice spends to Carol, 00:12:06.520 --> 00:12:08.380 and they come in different orders, 00:12:08.380 --> 00:12:10.180 either one could happen first. 00:12:10.180 --> 00:12:13.180 There's no notion of, like, Carol gets these coins 00:12:13.180 --> 00:12:14.860 and Bob gets these coins. 00:12:14.860 --> 00:12:16.570 But Bitcoin is a little bit different. 00:12:16.570 --> 00:12:18.860 All coins are not the same. 00:12:18.860 --> 00:12:21.490 And when you're spending, you don't just 00:12:21.490 --> 00:12:27.083 include an amount you refer back to the specific coin 00:12:27.083 --> 00:12:28.000 that you are spending. 00:12:30.970 --> 00:12:35.410 So you actually have to refer to a coin in order to spend it. 00:12:35.410 --> 00:12:38.050 And this is the really weird part-- 00:12:38.050 --> 00:12:42.580 coins are created, destroyed, consumed, 00:12:42.580 --> 00:12:47.780 and then new coins are created every transaction. 00:12:47.780 --> 00:12:51.170 So whenever you spend your bitcoin, 00:12:51.170 --> 00:12:53.630 you have to spend it in its entirety. 00:12:53.630 --> 00:12:57.695 That bitcoin is then destroyed, and new coins are created. 00:13:01.225 --> 00:13:03.600 And there's a rule, in the entire system, that a coin can 00:13:03.600 --> 00:13:04.485 only be spent once. 00:13:08.580 --> 00:13:11.993 So we'll go into exactly what that 00:13:11.993 --> 00:13:13.410 looks like in a transaction, but I 00:13:13.410 --> 00:13:15.300 want to know if there are any questions about that 00:13:15.300 --> 00:13:16.370 first, about that idea. 00:13:16.370 --> 00:13:16.670 Yes. 00:13:16.670 --> 00:13:18.003 AUDIENCE: Aren't coins fungible? 00:13:18.003 --> 00:13:21.363 So what if you spend maybe a little bit of a coin 00:13:21.363 --> 00:13:23.248 on some candy or something? 00:13:23.248 --> 00:13:24.790 NEHA NARULA: That's a great question. 00:13:24.790 --> 00:13:27.480 So the question is, aren't coins fungible? 00:13:27.480 --> 00:13:29.580 So first of all, coins aren't fungible, actually. 00:13:29.580 --> 00:13:31.630 They are very specific. 00:13:31.630 --> 00:13:33.300 You can see a coin. 00:13:33.300 --> 00:13:37.140 But the question about what happens 00:13:37.140 --> 00:13:40.410 if you only want to spend part of a coin is a great question. 00:13:40.410 --> 00:13:42.750 And we'll see how you do that in the way 00:13:42.750 --> 00:13:44.530 that the transaction is constructed. 00:13:44.530 --> 00:13:47.310 But the short answer is, if you want to spend part of a coin, 00:13:47.310 --> 00:13:48.840 you have to spend the whole coin, 00:13:48.840 --> 00:13:51.240 spend the part that you want to someone else, 00:13:51.240 --> 00:13:53.220 and then spend the rest of it back to yourself, 00:13:53.220 --> 00:13:56.810 creating a new coin in the process. 00:13:56.810 --> 00:13:57.570 Yes. 00:13:57.570 --> 00:13:59.810 AUDIENCE: Coins are consumed, and for the new ones, 00:13:59.810 --> 00:14:02.000 who will own the new ones? 00:14:02.000 --> 00:14:05.450 NEHA NARULA: Whoever you say should own the new ones when-- 00:14:05.450 --> 00:14:09.710 a transaction consumes coins and creates new ones as payment. 00:14:09.710 --> 00:14:13.280 And as the creator of that transaction, as the spender, 00:14:13.280 --> 00:14:15.170 I will decide who should get the new coins. 00:14:15.170 --> 00:14:17.326 And I'll show you the details of this in a moment. 00:14:17.326 --> 00:14:18.868 AUDIENCE: You're saying coins, but do 00:14:18.868 --> 00:14:22.505 you actually mean the full balance in the account, right? 00:14:22.505 --> 00:14:24.880 NEHA NARULA: No, not exactly full balance in the account. 00:14:24.880 --> 00:14:27.528 So let's go a little bit further to look 00:14:27.528 --> 00:14:28.570 at what's happening here. 00:14:28.570 --> 00:14:31.280 Because Bitcoin doesn't actually keep track of balances. 00:14:31.280 --> 00:14:34.630 So let's take a look at what a transaction actually 00:14:34.630 --> 00:14:35.950 looks like. 00:14:35.950 --> 00:14:39.190 So a transaction has many different parts, 00:14:39.190 --> 00:14:41.200 but we're going to focus on two parts, which 00:14:41.200 --> 00:14:43.180 is the inputs and outputs. 00:14:43.180 --> 00:14:44.770 And here I'm showing a transaction 00:14:44.770 --> 00:14:48.070 with one input and one output. 00:14:48.070 --> 00:14:52.240 Now, an input actually refers back 00:14:52.240 --> 00:14:55.060 to another transaction's output. 00:14:55.060 --> 00:14:58.060 So let's assume-- and we'll get into how this is done later-- 00:14:58.060 --> 00:15:01.690 but let's assume that there are coins in the system. 00:15:01.690 --> 00:15:04.360 Let's just assume that some coins have been created out 00:15:04.360 --> 00:15:06.130 of nowhere. 00:15:06.130 --> 00:15:09.820 Let's say, in particular, that maybe 12.5 coins have 00:15:09.820 --> 00:15:11.230 been created out of nowhere. 00:15:11.230 --> 00:15:13.540 And so there's a transaction that 00:15:13.540 --> 00:15:16.360 outputs 12.5 coins to Alice. 00:15:16.360 --> 00:15:18.460 And Alice wants to spend those coins. 00:15:18.460 --> 00:15:21.610 And so Alice would create a new transaction 00:15:21.610 --> 00:15:24.730 that points back to the transaction where 00:15:24.730 --> 00:15:26.470 she received those coins. 00:15:26.470 --> 00:15:28.570 And the way that she points back to that 00:15:28.570 --> 00:15:32.800 is using the transaction ID of the previous transaction, which 00:15:32.800 --> 00:15:35.420 you remember is just the hash, the index, 00:15:35.420 --> 00:15:39.100 meaning which output of the previous transaction she's 00:15:39.100 --> 00:15:41.320 intending to spend, and something 00:15:41.320 --> 00:15:45.640 called a scriptSig, which is her authorization 00:15:45.640 --> 00:15:48.560 to spend that output. 00:15:48.560 --> 00:15:52.600 So this is how Alice refers back to the output 00:15:52.600 --> 00:15:53.500 she wants to spend. 00:15:53.500 --> 00:15:58.600 And when I say coin, I'm referring to outputs. 00:15:58.600 --> 00:16:02.740 So outputs can be for different amounts. 00:16:02.740 --> 00:16:03.940 You could create an output-- 00:16:03.940 --> 00:16:08.200 you could spend 12.5 coins and create many different outputs 00:16:08.200 --> 00:16:11.510 of many different amounts, and send them to different people. 00:16:11.510 --> 00:16:13.420 if you wanted to. 00:16:13.420 --> 00:16:15.990 So this is a format of a transaction. 00:16:15.990 --> 00:16:18.130 There is an input which points back 00:16:18.130 --> 00:16:20.200 to a previous transaction's output 00:16:20.200 --> 00:16:21.880 that you're intending to spend. 00:16:21.880 --> 00:16:23.980 And then the way that you spend it-- 00:16:23.980 --> 00:16:25.960 you're consuming that output, essentially, 00:16:25.960 --> 00:16:27.820 by pointing back to it with this input-- 00:16:27.820 --> 00:16:31.337 the way that you spend it by producing a new output. 00:16:31.337 --> 00:16:32.920 And again, this transaction isn't just 00:16:32.920 --> 00:16:35.410 one input and one output, it could have many. 00:16:35.410 --> 00:16:38.530 And the output that you produce has something 00:16:38.530 --> 00:16:40.540 called a scriptPubKey. 00:16:40.540 --> 00:16:42.880 What the scriptPubKey is, the scriptPubKey 00:16:42.880 --> 00:16:46.990 is a way of specifying the conditions under which 00:16:46.990 --> 00:16:49.860 this output can be redeemed. 00:16:49.860 --> 00:16:54.940 So in its simplest sense, you might have the scriptSig merely 00:16:54.940 --> 00:16:58.290 be a signature, just Alice's signature, saying, 00:16:58.290 --> 00:17:00.000 I have the right to spend this. 00:17:00.000 --> 00:17:03.660 And if Alice is spending to Bob, then maybe the scriptPubKey 00:17:03.660 --> 00:17:06.329 would actually just be Bob's public key. 00:17:06.329 --> 00:17:08.550 And the implied meaning there would 00:17:08.550 --> 00:17:10.619 be, anyone who could produce the signature 00:17:10.619 --> 00:17:14.130 of the corresponding private key with that public key 00:17:14.130 --> 00:17:15.690 could then spend this output. 00:17:18.619 --> 00:17:22.099 One thing is that these two things together-- 00:17:22.099 --> 00:17:24.260 the previous transaction ID and the index-- 00:17:24.260 --> 00:17:27.780 serves to uniquely identify an output. 00:17:27.780 --> 00:17:32.060 So these two things uniquely identify some money to spend. 00:17:34.640 --> 00:17:37.880 And the value that's specified in the output 00:17:37.880 --> 00:17:40.850 is actually specified in something called Satoshis, 00:17:40.850 --> 00:17:43.430 and there are 10 to the eighth Satoshis in one bitcoin. 00:17:43.430 --> 00:17:45.790 So the value doesn't have any decimal places in it. 00:17:45.790 --> 00:17:47.380 It is always an integer. 00:17:47.380 --> 00:17:53.090 And output is what I'm referring to when I say the word, coin. 00:17:53.090 --> 00:17:56.450 So, questions on this sort of general setup. 00:17:59.680 --> 00:18:00.350 Yes. 00:18:00.350 --> 00:18:02.580 AUDIENCE: Can you talk about index [INAUDIBLE] 00:18:02.580 --> 00:18:03.820 NEHA NARULA: Sure. 00:18:03.820 --> 00:18:05.680 OK, the index is-- 00:18:05.680 --> 00:18:08.290 remember how I said there could be multiple outputs? 00:18:08.290 --> 00:18:10.628 The index simply refers to which output 00:18:10.628 --> 00:18:12.670 in the previous transaction you're talking about. 00:18:15.987 --> 00:18:17.320 Was there a question back there? 00:18:17.320 --> 00:18:17.820 Yeah. 00:18:17.820 --> 00:18:20.110 AUDIENCE: Yeah, I'm a little bit confused about the-- 00:18:20.110 --> 00:18:23.872 So you have one input that can generate several outputs? 00:18:23.872 --> 00:18:24.580 NEHA NARULA: Yes. 00:18:24.580 --> 00:18:25.690 AUDIENCE: Can you provide an example? 00:18:25.690 --> 00:18:27.010 NEHA NARULA: Sure, yes. 00:18:27.010 --> 00:18:28.985 We'll get to that in a moment, actually. 00:18:28.985 --> 00:18:30.860 But maybe I could just draw one on the board. 00:18:40.270 --> 00:18:42.340 So you could certainly have a transaction 00:18:42.340 --> 00:18:45.730 that has multiple outputs. 00:18:45.730 --> 00:18:49.410 And so this input here would refer back 00:18:49.410 --> 00:18:52.080 to some previous transaction's outputs. 00:18:55.710 --> 00:19:01.360 And let's say that this was, for example, 20 bitcoin. 00:19:01.360 --> 00:19:05.920 Then this needs to consume 20 bitcoin. 00:19:05.920 --> 00:19:08.577 And it can spread that 20 bitcoin out in any way 00:19:08.577 --> 00:19:09.160 that it wants. 00:19:09.160 --> 00:19:10.910 And there are some details here that we're 00:19:10.910 --> 00:19:12.320 going to get to in a moment. 00:19:12.320 --> 00:19:14.140 But basically, you have that 20 here. 00:19:14.140 --> 00:19:18.010 You could send five here, 10 here, five here. 00:19:18.010 --> 00:19:21.640 And each of these outputs would have its own scriptPubKey, 00:19:21.640 --> 00:19:24.490 its own rules for how to redeem it. 00:19:24.490 --> 00:19:26.640 And each output has its own amount. 00:19:31.790 --> 00:19:32.290 Yep. 00:19:32.290 --> 00:19:33.720 TADGE DRYJA: It's also possible with multiple inputs 00:19:33.720 --> 00:19:34.220 [INAUDIBLE] 00:19:34.220 --> 00:19:35.940 NEHA NARULA: Yes. 00:19:35.940 --> 00:19:36.540 Yes. 00:19:36.540 --> 00:19:39.310 AUDIENCE: So where does the name, chain, come from? 00:19:39.310 --> 00:19:41.410 Is it more like a tree, or is it-- 00:19:41.410 --> 00:19:43.480 NEHA NARULA: That's a good question. 00:19:43.480 --> 00:19:47.770 So if you go back to the slide where I sort of was showing-- 00:19:47.770 --> 00:19:51.793 this is where the name, chain, comes from, here. 00:19:51.793 --> 00:19:52.520 [CHUCKLING] 00:19:52.520 --> 00:19:54.280 So what we're talking about right now 00:19:54.280 --> 00:19:57.250 is what goes inside each block. 00:19:57.250 --> 00:19:59.860 And what goes inside each block are transactions. 00:19:59.860 --> 00:20:02.320 So for the moment, you can pretend like each block only 00:20:02.320 --> 00:20:05.410 has one transaction in it, but a block 00:20:05.410 --> 00:20:07.000 can contain a set of transactions. 00:20:07.000 --> 00:20:09.760 But the chain part comes from how we actually 00:20:09.760 --> 00:20:11.860 chain these blocks of transactions together. 00:20:17.590 --> 00:20:21.370 So let's talk about scriptSigs and scriptPubKeys a little bit 00:20:21.370 --> 00:20:22.200 more. 00:20:22.200 --> 00:20:27.020 So scriptPubKeys, like I said, are in the outputs. 00:20:27.020 --> 00:20:29.480 And you can think of them as predicates. 00:20:29.480 --> 00:20:32.380 So scriptPubKeys specify a predicate 00:20:32.380 --> 00:20:36.998 on how someone can redeem this output. 00:20:36.998 --> 00:20:39.290 OK, so remember a transaction can have multiple inputs, 00:20:39.290 --> 00:20:40.640 multiple outputs. 00:20:40.640 --> 00:20:44.370 Each output has its own scriptPubKey. 00:20:44.370 --> 00:20:47.890 scriptSigs, which are in the inputs, 00:20:47.890 --> 00:20:50.630 helps satisfy the predicate that's 00:20:50.630 --> 00:20:53.360 specified in the scriptPubKey. 00:20:53.360 --> 00:21:02.330 So we would have a scriptPubKey here, And. 00:21:02.330 --> 00:21:03.770 We would have a scriptSig here. 00:21:06.380 --> 00:21:10.730 And this scriptSig, if this is a valid transaction, 00:21:10.730 --> 00:21:14.630 would explain how to satisfy the scriptPubKey. 00:21:14.630 --> 00:21:17.870 So the scriptPubKey would set up a predicate on the output. 00:21:17.870 --> 00:21:20.510 The most common predicate is, produce 00:21:20.510 --> 00:21:26.580 a signature and a public key that satisfies this hash. 00:21:26.580 --> 00:21:29.340 And the scriptSig would provide the information 00:21:29.340 --> 00:21:31.333 necessary to satisfy that predicate. 00:21:34.580 --> 00:21:38.420 So what does it mean to have money in this system? 00:21:38.420 --> 00:21:40.795 What does it mean to be able to spend money? 00:21:40.795 --> 00:21:42.170 What does it mean for Alice to be 00:21:42.170 --> 00:21:44.000 able to transfer money to Bob? 00:21:44.000 --> 00:21:46.970 It means Alice knows some information that 00:21:46.970 --> 00:21:50.660 allows her to produce a satisfying scriptSig 00:21:50.660 --> 00:21:52.820 for some outputs out there. 00:21:52.820 --> 00:21:55.610 That's what having money means. 00:21:55.610 --> 00:21:56.810 It's not an account balance. 00:22:00.970 --> 00:22:02.510 So questions on that? 00:22:05.350 --> 00:22:07.620 Because it's a little non-intuitive. 00:22:07.620 --> 00:22:09.270 But the important thing to note here 00:22:09.270 --> 00:22:12.360 is the nodes in the Bitcoin network 00:22:12.360 --> 00:22:15.630 are not keeping track of how much money you have. 00:22:15.630 --> 00:22:18.540 It's your job to keep track of how much money you have, 00:22:18.540 --> 00:22:19.560 or a wallet's job. 00:22:19.560 --> 00:22:21.560 And we'll talk more about wallets later. 00:22:21.560 --> 00:22:24.240 And the way that you do that is by knowing 00:22:24.240 --> 00:22:27.090 how many outputs there are out there that you can actually 00:22:27.090 --> 00:22:28.910 redeem-- 00:22:28.910 --> 00:22:31.200 that you have the knowledge to redeem. 00:22:31.200 --> 00:22:33.840 Like I said, a transaction can have multiple inputs 00:22:33.840 --> 00:22:35.190 and multiple outputs. 00:22:35.190 --> 00:22:38.910 And each input comes with its own scriptSig, 00:22:38.910 --> 00:22:41.550 and each output comes with its own scriptPubKey. 00:22:41.550 --> 00:22:44.370 So it's not that there's one scriptSig and one scriptPubKey 00:22:44.370 --> 00:22:45.900 for the entire transaction. 00:22:45.900 --> 00:22:47.700 The transaction can actually spend 00:22:47.700 --> 00:22:49.770 multiple different outputs and produce 00:22:49.770 --> 00:22:51.840 multiple different new outputs. 00:22:51.840 --> 00:22:54.660 And these outputs could have nothing to do with each other. 00:22:54.660 --> 00:22:58.860 Here, this input might point to a previous output 00:22:58.860 --> 00:23:01.432 that Alice knows how to spend. 00:23:01.432 --> 00:23:03.390 And this input might point to a previous output 00:23:03.390 --> 00:23:05.400 the Carol knows how to spend. 00:23:05.400 --> 00:23:07.290 And you can actually combine both of those 00:23:07.290 --> 00:23:09.660 into the same transaction, assuming 00:23:09.660 --> 00:23:13.200 you can produce a transaction with the right scriptSigs. 00:23:13.200 --> 00:23:16.140 Now, Alice and Carol might have to talk to each other 00:23:16.140 --> 00:23:17.820 in order to produce this transaction, 00:23:17.820 --> 00:23:20.400 because it's going to need both signatures, 00:23:20.400 --> 00:23:21.780 but they could do it. 00:23:25.340 --> 00:23:27.960 AUDIENCE: What prevents people from sort 00:23:27.960 --> 00:23:29.793 of shuffling around and changing the outputs 00:23:29.793 --> 00:23:30.752 and inputs [INAUDIBLE]? 00:23:30.752 --> 00:23:32.200 NEHA NARULA: Ah, great question. 00:23:32.200 --> 00:23:34.690 So what prevents people from shuffling 00:23:34.690 --> 00:23:35.940 around inputs and the outputs? 00:23:35.940 --> 00:23:37.398 Well, part of it is because this is 00:23:37.398 --> 00:23:40.170 serialized into a transaction. 00:23:40.170 --> 00:23:44.040 And that transaction is hashed, and then these signatures 00:23:44.040 --> 00:23:46.410 are on that transaction hash. 00:23:46.410 --> 00:23:48.750 Remember, we saw that from a few slides before. 00:23:48.750 --> 00:23:50.640 So if you were to flip around the order 00:23:50.640 --> 00:23:52.830 or if you were to trying to change any bits in here 00:23:52.830 --> 00:23:54.930 and change the pubkey, you would end up 00:23:54.930 --> 00:23:56.910 changing the hash of the transaction 00:23:56.910 --> 00:23:59.430 and this signature would no longer be valid. 00:23:59.430 --> 00:24:02.400 And something also that's important to note-- 00:24:02.400 --> 00:24:05.820 only valid transactions get accepted to the blockchain. 00:24:05.820 --> 00:24:09.450 So all of the nodes are checking to make sure 00:24:09.450 --> 00:24:12.103 that these scriptPubKeys and these scriptSigs work out. 00:24:12.103 --> 00:24:13.770 And I'll show you the rules that they're 00:24:13.770 --> 00:24:15.810 checking in just a moment. 00:24:15.810 --> 00:24:19.830 And so if anything doesn't match, 00:24:19.830 --> 00:24:23.610 if this signature is not a valid scriptSig for whatever output 00:24:23.610 --> 00:24:26.460 it's pointing to, this is an invalid transaction, 00:24:26.460 --> 00:24:27.690 no one will accept it. 00:24:27.690 --> 00:24:29.940 In fact, most nodes won't even pass it around, 00:24:29.940 --> 00:24:31.860 and it will not get into the blockchain. 00:24:31.860 --> 00:24:34.107 Or if it does get into the blockchain, 00:24:34.107 --> 00:24:35.940 all of the nodes who are following the rules 00:24:35.940 --> 00:24:37.500 of the network will ignore it. 00:24:37.500 --> 00:24:39.330 Because if a transaction is invalid, 00:24:39.330 --> 00:24:41.130 it means the entire block is invalid, 00:24:41.130 --> 00:24:44.912 and it means any chain building off that block is also invalid. 00:24:44.912 --> 00:24:47.370 So nodes that are following the rules of the network, which 00:24:47.370 --> 00:24:51.420 are, these should be valid, will not listen to that, 00:24:51.420 --> 00:24:55.830 and will completely ignore that entire chain. 00:24:55.830 --> 00:24:59.990 So here's another visual of what it looks like to have-- 00:24:59.990 --> 00:25:02.010 and this is not with the blockchain looks like. 00:25:02.010 --> 00:25:03.420 I want to be clear. 00:25:03.420 --> 00:25:05.400 The blockchain just a set of blocks 00:25:05.400 --> 00:25:07.490 pointing to previous blocks. 00:25:07.490 --> 00:25:08.910 What we have here is more sort of 00:25:08.910 --> 00:25:11.160 like the logical representation of what 00:25:11.160 --> 00:25:12.580 a transaction looks like. 00:25:12.580 --> 00:25:14.820 So you have a transaction right here, 00:25:14.820 --> 00:25:17.010 and you have two inputs in this transaction. 00:25:17.010 --> 00:25:20.280 And the first one is pointing to the second output 00:25:20.280 --> 00:25:22.860 of this previous transaction that happened over here. 00:25:22.860 --> 00:25:25.140 So this transaction has a hash. 00:25:25.140 --> 00:25:28.080 And maybe this is the hash of the entire transaction. 00:25:28.080 --> 00:25:31.410 And so in order to spend that output over there, 00:25:31.410 --> 00:25:34.500 you specify the hash, you specify the index-- 00:25:34.500 --> 00:25:39.090 so 012, you specify this index right here-- 00:25:39.090 --> 00:25:42.390 and you provide a scriptSig that will 00:25:42.390 --> 00:25:45.300 validate according to whatever the scriptPubKey is 00:25:45.300 --> 00:25:47.200 for that output. 00:25:47.200 --> 00:25:50.100 So note here, this transaction doesn't care 00:25:50.100 --> 00:25:51.960 what those outputs are at all. 00:25:51.960 --> 00:25:52.947 It's not using those. 00:25:52.947 --> 00:25:54.030 It's not looking at those. 00:25:54.030 --> 00:25:55.863 Someone else might spend those, someone else 00:25:55.863 --> 00:25:56.790 might not spend those. 00:25:56.790 --> 00:25:59.250 It's just spending this one right here. 00:25:59.250 --> 00:26:01.950 And in the act of spending this one right here, 00:26:01.950 --> 00:26:06.390 it doesn't make those other ones invalid in the simplest form. 00:26:06.390 --> 00:26:09.190 Those could still be spent by someone else. 00:26:09.190 --> 00:26:12.330 So outputs are consumed separately. 00:26:12.330 --> 00:26:16.650 So here, it's pointing to a different transaction, 00:26:16.650 --> 00:26:18.510 a transaction with this hash. 00:26:18.510 --> 00:26:21.210 And so it specifies the transaction ID, 00:26:21.210 --> 00:26:23.807 and then it specifies which output in that transaction 00:26:23.807 --> 00:26:24.390 it's spending. 00:26:24.390 --> 00:26:28.230 In this case, it's the third one, so it has index 2. 00:26:28.230 --> 00:26:29.910 And it provides a satisfying scriptSig 00:26:29.910 --> 00:26:32.430 for this output, which probably is 00:26:32.430 --> 00:26:34.430 totally different than the satisfying 00:26:34.430 --> 00:26:37.240 scriptSig for that output. 00:26:37.240 --> 00:26:40.680 So this is what this transaction has to specify in order 00:26:40.680 --> 00:26:42.690 to spend those outputs. 00:26:42.690 --> 00:26:45.240 And it can produce whatever new outputs it wants 00:26:45.240 --> 00:26:46.890 to produce under certain rules. 00:26:50.159 --> 00:26:53.930 AUDIENCE: So in that example, that whole box actually 00:26:53.930 --> 00:26:55.780 points to something else? 00:26:55.780 --> 00:26:59.510 That's not these two boxes on the left, right? 00:26:59.510 --> 00:27:00.540 NEHA NARULA: This box? 00:27:00.540 --> 00:27:02.000 What do you mean when you say, points to? 00:27:02.000 --> 00:27:03.450 AUDIENCE: [? Their ?] blockchain sequence. 00:27:03.450 --> 00:27:04.200 NEHA NARULA: Yeah. 00:27:04.200 --> 00:27:05.930 This is something that will be inside 00:27:05.930 --> 00:27:08.720 of the blockchain-- inside of a block in the blockchain. 00:27:08.720 --> 00:27:11.280 So this doesn't actually point to anything. 00:27:11.280 --> 00:27:13.340 It contains hashes. 00:27:13.340 --> 00:27:15.560 Literally, it just contains these bytes, 00:27:15.560 --> 00:27:18.630 these hashes of the transactions that it's spending. 00:27:18.630 --> 00:27:22.010 And those are kind of like a pointer in a sense. 00:27:22.010 --> 00:27:24.470 But when it comes to the entire blockchain, 00:27:24.470 --> 00:27:26.874 this is one part of one block. 00:27:26.874 --> 00:27:28.537 AUDIENCE: [INAUDIBLE] 00:27:28.537 --> 00:27:29.620 NEHA NARULA: Yeah, I know. 00:27:29.620 --> 00:27:33.520 Can you guys see this at all? 00:27:33.520 --> 00:27:35.140 Can you still see that or no? 00:27:35.140 --> 00:27:35.670 OK, good. 00:27:35.670 --> 00:27:37.055 OK, great. 00:27:37.055 --> 00:27:37.930 You had your hand up. 00:27:37.930 --> 00:27:39.930 AUDIENCE: Yeah, so in one of the earlier slides, 00:27:39.930 --> 00:27:48.560 you showed [INAUDIBLE] Is that signature the same 00:27:48.560 --> 00:27:49.367 as scriptSig, or-- 00:27:49.367 --> 00:27:50.950 NEHA NARULA: No, that was sort of more 00:27:50.950 --> 00:27:52.750 like an idealized transaction. 00:27:52.750 --> 00:27:55.215 So this is what a transaction actually looks like, 00:27:55.215 --> 00:27:56.185 [CHUCKLING] 00:27:56.185 --> 00:27:57.685 AUDIENCE: But the scriptSig is still 00:27:57.685 --> 00:27:58.982 inside the transaction itself. 00:27:58.982 --> 00:28:01.190 NEHA NARULA: The scriptSig is inside the transaction. 00:28:01.190 --> 00:28:02.830 But when you sign the transaction, 00:28:02.830 --> 00:28:06.610 you don't sign the scriptSigs because the scriptSigs include 00:28:06.610 --> 00:28:08.352 the signature of the transaction. 00:28:08.352 --> 00:28:10.060 And it's important to note, the scriptSig 00:28:10.060 --> 00:28:13.910 includes the signature of the transaction as a whole, 00:28:13.910 --> 00:28:16.336 not just this part of it. 00:28:16.336 --> 00:28:20.440 TADGE DRYJA: This actually [INAUDIBLE] We're not talking 00:28:20.440 --> 00:28:23.680 about it now, but that was sort of-- 00:28:23.680 --> 00:28:25.980 there's bugs involved at that point. 00:28:25.980 --> 00:28:26.505 NEHA NARULA: Yeah, we're not going 00:28:26.505 --> 00:28:27.588 to talk about [INAUDIBLE]. 00:28:27.588 --> 00:28:28.750 OK, yes. 00:28:28.750 --> 00:28:32.380 AUDIENCE: Yeah, what prevents two different transactions 00:28:32.380 --> 00:28:34.210 pointing back at the same [INAUDIBLE]?? 00:28:34.210 --> 00:28:35.377 NEHA NARULA: Great question. 00:28:35.377 --> 00:28:39.280 So OK, I said that there's this rule that outputs are supposed 00:28:39.280 --> 00:28:41.110 to only be consumed once. 00:28:41.110 --> 00:28:43.495 But I can definitely produce another transaction which 00:28:43.495 --> 00:28:44.620 points back to that output. 00:28:44.620 --> 00:28:46.240 I could send it to the network. 00:28:46.240 --> 00:28:48.798 And what would happen is the nodes in the network, 00:28:48.798 --> 00:28:50.590 assuming they're following consensus rules, 00:28:50.590 --> 00:28:53.560 would note that this had already been spent. 00:28:53.560 --> 00:28:55.420 So if this is already-- if they've already 00:28:55.420 --> 00:28:59.710 seen a valid transaction that consumes an output, 00:28:59.710 --> 00:29:02.648 they will not accept another transaction that 00:29:02.648 --> 00:29:03.940 tries to spend the same output. 00:29:03.940 --> 00:29:05.840 That's what's known as a double-spend. 00:29:05.840 --> 00:29:07.450 And so all the nodes in the network 00:29:07.450 --> 00:29:10.408 together are maintaining this rule. 00:29:10.408 --> 00:29:12.700 AUDIENCE: Isn't it going to be kind of hard to traverse 00:29:12.700 --> 00:29:14.200 backwards and figure out [INAUDIBLE] 00:29:14.200 --> 00:29:15.110 pointing [INAUDIBLE]? 00:29:15.110 --> 00:29:16.277 NEHA NARULA: Great question. 00:29:16.277 --> 00:29:18.630 Yes, this seems kind of annoying, right? 00:29:18.630 --> 00:29:21.380 You see this transaction, and OK, there's 00:29:21.380 --> 00:29:24.650 some random bytes in here, and a signature, 00:29:24.650 --> 00:29:28.280 and how am I supposed to figure out what this goes to? 00:29:28.280 --> 00:29:31.370 How am I supposed to figure out whether this 00:29:31.370 --> 00:29:34.800 is a valid transaction, whether it's been spent or not? 00:29:34.800 --> 00:29:37.250 And the answer is that every single node 00:29:37.250 --> 00:29:39.410 is maintaining a lot of data structures 00:29:39.410 --> 00:29:41.600 in order to make this faster. 00:29:41.600 --> 00:29:43.700 And in fact they're maintaining a data structure 00:29:43.700 --> 00:29:47.030 called the UTXO set. 00:29:47.030 --> 00:29:51.570 And I'll tell you a little bit about the UTXO set in a minute. 00:29:51.570 --> 00:29:54.740 And I'll tell you how it's created in a moment. 00:29:54.740 --> 00:29:55.541 Yes. 00:29:55.541 --> 00:29:58.190 AUDIENCE: [INAUDIBLE] transaction fees 00:29:58.190 --> 00:30:02.110 and how these transactions pass in to the blockchain itself? 00:30:02.110 --> 00:30:03.260 NEHA NARULA: Sure. 00:30:03.260 --> 00:30:05.855 So I'm not going to go into how a block-- 00:30:08.870 --> 00:30:10.280 what a block is composed of. 00:30:10.280 --> 00:30:12.920 I'm not going to go into what a block is composed of, 00:30:12.920 --> 00:30:14.100 but we will tomorrow. 00:30:18.002 --> 00:30:18.502 Yes. 00:30:18.502 --> 00:30:21.170 AUDIENCE: Just to confirm, with the [INAUDIBLE] scriptSig, 00:30:21.170 --> 00:30:23.298 it's not usually [? taking ?] this, 00:30:23.298 --> 00:30:27.055 it's [INAUDIBLE] the transaction. 00:30:27.055 --> 00:30:28.680 NEHA NARULA: I'm sorry, could you say-- 00:30:28.680 --> 00:30:34.060 AUDIENCE: ScriptSig, [INAUDIBLE] or is it unique for each index? 00:30:34.060 --> 00:30:36.060 NEHA NARULA: Yes, there is a different scriptSig 00:30:36.060 --> 00:30:39.415 for each input. 00:30:39.415 --> 00:30:41.290 There's a different scriptSig for each input, 00:30:41.290 --> 00:30:46.980 but that scriptSig signs most of the transaction. 00:30:46.980 --> 00:30:49.915 So the scriptSig, there's a different one, 00:30:49.915 --> 00:30:52.290 because different outputs could have different satisfying 00:30:52.290 --> 00:30:53.580 conditions. 00:30:53.580 --> 00:30:56.880 But the scriptSig has to sign a message, 00:30:56.880 --> 00:30:59.030 or it has to produce something. 00:30:59.030 --> 00:31:02.640 Actually, we're going to go into a few specific scriptSigs, 00:31:02.640 --> 00:31:05.010 and I think it'll be a lot clearer exactly what this is. 00:31:05.010 --> 00:31:06.930 Because it's not clear right now what goes in the scriptSig 00:31:06.930 --> 00:31:08.220 or in the scriptPubKey. 00:31:08.220 --> 00:31:11.670 So this is sort of like a logical representation of what 00:31:11.670 --> 00:31:12.810 a transaction looks like. 00:31:12.810 --> 00:31:15.780 It refers to the previous transaction 00:31:15.780 --> 00:31:17.520 that it's spending from. 00:31:17.520 --> 00:31:19.650 And the important things to note here 00:31:19.650 --> 00:31:23.490 are you don't have to spend all of the outputs 00:31:23.490 --> 00:31:25.440 in a transaction, you can just spend one. 00:31:25.440 --> 00:31:30.600 But you must consume that output entirely 00:31:30.600 --> 00:31:34.370 when you produce your new outputs. 00:31:34.370 --> 00:31:36.480 And so this is what's actually-- 00:31:36.480 --> 00:31:41.040 this is the JSON representation of a transaction in Bitcoin. 00:31:41.040 --> 00:31:44.160 And so this is probably pretty hard to read, 00:31:44.160 --> 00:31:46.890 and I don't think it's worth it to try to look 00:31:46.890 --> 00:31:49.290 at everything in great detail. 00:31:49.290 --> 00:31:53.520 But when we have the slides up, you can take a look at this. 00:31:53.520 --> 00:31:57.750 And this is literally what goes inside a transaction. 00:31:57.750 --> 00:32:01.270 And there are few fields that I'm not talking about here. 00:32:01.270 --> 00:32:05.070 One is the version, and another is the lock time. 00:32:05.070 --> 00:32:07.290 And I think when we talk-- 00:32:07.290 --> 00:32:09.570 these scripts, these scriptPubKey and scriptSig 00:32:09.570 --> 00:32:11.850 can actually get quite interesting and quite complex. 00:32:11.850 --> 00:32:14.640 That's what makes Bitcoin so cool. 00:32:14.640 --> 00:32:17.070 And I think when we get into that discussion about all 00:32:17.070 --> 00:32:18.862 the different things that can go into that, 00:32:18.862 --> 00:32:21.720 then we'll talk a little bit more about what lock time is. 00:32:21.720 --> 00:32:25.170 But the short answer is, a lock time tells you 00:32:25.170 --> 00:32:27.930 at what point in time this transaction is valid. 00:32:27.930 --> 00:32:31.560 So until that lock time happens, the transaction 00:32:31.560 --> 00:32:34.080 is not valid and can't be included in the blockchain. 00:32:34.080 --> 00:32:36.330 So this transaction has a lock time of zero, 00:32:36.330 --> 00:32:38.640 meaning it's valid immediately and can 00:32:38.640 --> 00:32:40.500 be included in the blockchain. 00:32:40.500 --> 00:32:43.140 So here, this has one input. 00:32:43.140 --> 00:32:47.160 The input has the transaction ID and the index. 00:32:47.160 --> 00:32:49.800 So that's zero, so it's spending the first output of whatever 00:32:49.800 --> 00:32:51.150 that transaction is. 00:32:51.150 --> 00:32:55.230 And it has some scriptSig, which is empty. 00:32:55.230 --> 00:32:59.790 And then this is the output that it's producing. 00:32:59.790 --> 00:33:07.170 It's spending 49.99 bitcoins from that previous output. 00:33:07.170 --> 00:33:10.320 And it's spending it to a new output. 00:33:10.320 --> 00:33:13.580 And these are the rules for redeeming this new output. 00:33:17.530 --> 00:33:19.690 Let's talk about consensus rules. 00:33:19.690 --> 00:33:21.790 So I keep using the word, valid-- 00:33:21.790 --> 00:33:25.408 this transaction is valid, this transaction is invalid. 00:33:25.408 --> 00:33:26.950 And so there are these implicit rules 00:33:26.950 --> 00:33:29.410 to Bitcoin, which are defined by the software, which 00:33:29.410 --> 00:33:32.980 state what makes a valid transaction or a valid block. 00:33:32.980 --> 00:33:35.770 For transactions specifically, the sum of the inputs 00:33:35.770 --> 00:33:39.250 has to be less than or equal to the sum of the outputs. 00:33:39.250 --> 00:33:42.520 So you can't create money out of nowhere. 00:33:42.520 --> 00:33:45.700 You can't spend more than you're putting into a transaction. 00:33:45.700 --> 00:33:47.920 And why less than or equal to? 00:33:50.970 --> 00:33:51.990 Fees, exactly. 00:33:51.990 --> 00:33:59.010 So the difference in the outputs and the inputs is implicit. 00:33:59.010 --> 00:34:01.500 And it's a fee that essentially just goes 00:34:01.500 --> 00:34:03.780 to the miner, the person who purchases the block. 00:34:03.780 --> 00:34:06.420 There is one exception to this rule. 00:34:06.420 --> 00:34:09.030 It's a transaction called the coinbase transaction-- 00:34:09.030 --> 00:34:10.264 no relation to the company. 00:34:10.264 --> 00:34:11.639 It's not named after the company. 00:34:11.639 --> 00:34:13.222 I think the company is named after it. 00:34:13.222 --> 00:34:15.750 But it's the first transaction in a block. 00:34:15.750 --> 00:34:19.500 And it's the transaction that gives out the block reward. 00:34:19.500 --> 00:34:24.060 So the first transaction in a block is special. 00:34:24.060 --> 00:34:25.840 It doesn't have any inputs. 00:34:25.840 --> 00:34:28.800 Or it does have inputs, but they're meaningless. 00:34:28.800 --> 00:34:30.840 And it produces the block reward. 00:34:30.840 --> 00:34:34.620 So right now, the block reward is 12.5 bitcoins. 00:34:34.620 --> 00:34:36.605 So every time a block is produced, 00:34:36.605 --> 00:34:38.730 every time someone solves that proof-of-work puzzle 00:34:38.730 --> 00:34:41.580 and produces a block, they include a transaction 00:34:41.580 --> 00:34:44.610 at the very beginning that usually gives themselves 00:34:44.610 --> 00:34:48.150 12.5 bitcoin plus whatever fees are 00:34:48.150 --> 00:34:55.030 implicit as the sum of all of the transactions in the block. 00:34:55.030 --> 00:34:58.000 So this invariant must be maintained, 00:34:58.000 --> 00:35:00.230 except for the coinbase transaction, of which there 00:35:00.230 --> 00:35:02.620 is one in every block. 00:35:02.620 --> 00:35:04.480 And then this invariant must also 00:35:04.480 --> 00:35:06.445 be maintained, which-- oh, yes, sorry. 00:35:06.445 --> 00:35:08.120 AUDIENCE: Who determines the fees? 00:35:08.120 --> 00:35:10.120 NEHA NARULA: The people creating the transaction 00:35:10.120 --> 00:35:11.330 determine the fees. 00:35:11.330 --> 00:35:13.738 So when I create a transaction, I'm 00:35:13.738 --> 00:35:16.030 specifying which outputs I'm spending, and putting them 00:35:16.030 --> 00:35:18.370 in my inputs, and I'm producing the outputs. 00:35:18.370 --> 00:35:21.850 So I just have to maintain that invariant. 00:35:21.850 --> 00:35:24.490 So let's say that I'm spending an input worth five bitcoin. 00:35:24.490 --> 00:35:26.710 I could produce an output worth five bitcoin, 00:35:26.710 --> 00:35:28.450 meaning that the fee is zero. 00:35:28.450 --> 00:35:31.030 It's very unlikely that my transaction 00:35:31.030 --> 00:35:33.850 would get accepted into the blockchain with a fee of zero. 00:35:33.850 --> 00:35:35.290 It's possible, sure. 00:35:35.290 --> 00:35:38.290 But if I'm not mining myself, why would 00:35:38.290 --> 00:35:40.060 a miner take my transaction when they 00:35:40.060 --> 00:35:42.770 could take a transaction that has a higher fee associated 00:35:42.770 --> 00:35:43.270 with it? 00:35:43.270 --> 00:35:44.530 And the fee is implicit. 00:35:44.530 --> 00:35:46.572 It's the difference between the sum of the inputs 00:35:46.572 --> 00:35:48.420 and the sum of the outputs. 00:35:48.420 --> 00:35:50.630 AUDIENCE: So higher the fees, it's more likely 00:35:50.630 --> 00:35:51.832 that you will be processed-- 00:35:51.832 --> 00:35:52.540 NEHA NARULA: Yes. 00:35:57.810 --> 00:35:59.738 Any other questions at this point? 00:35:59.738 --> 00:36:01.530 AUDIENCE: Are these taken out of the inputs 00:36:01.530 --> 00:36:03.110 or out of the outputs? 00:36:03.110 --> 00:36:06.300 NEHA NARULA: The fee is implicit. 00:36:06.300 --> 00:36:09.960 So, in the inputs, you're consuming-- 00:36:09.960 --> 00:36:13.380 so let's use this example right here. 00:36:13.380 --> 00:36:19.800 So here, we're consuming this output, 00:36:19.800 --> 00:36:21.770 which has 20 bitcoin in it. 00:36:21.770 --> 00:36:27.170 So implicitly, this thing has 20 bitcoin to spend. 00:36:27.170 --> 00:36:32.360 Now, before, I had it set up as 5-10-5. 00:36:32.360 --> 00:36:36.110 And so 20 needs to be greater than 00:36:36.110 --> 00:36:38.930 or equal to 5 plus 10 plus 5. 00:36:38.930 --> 00:36:42.530 And it is, great, 20 is greater than or equal to 20. 00:36:42.530 --> 00:36:44.990 What I could do is I could change this number to a four. 00:36:48.200 --> 00:36:50.360 And so what this means is-- 00:36:50.360 --> 00:36:52.580 notice that this adds up to 19 now. 00:36:52.580 --> 00:36:54.410 Where did that one bitcoin go? 00:36:54.410 --> 00:36:58.400 That one bitcoin implicitly goes to whoever 00:36:58.400 --> 00:37:04.862 produces the block in which that contains this transaction. 00:37:04.862 --> 00:37:06.320 AUDIENCE: So is that greater than-- 00:37:06.320 --> 00:37:08.552 [INTERPOSING VOICES] 00:37:08.552 --> 00:37:09.760 AUDIENCE: No, but [INAUDIBLE] 00:37:09.760 --> 00:37:10.080 NEHA NARULA: No. 00:37:10.080 --> 00:37:11.038 AUDIENCE: On the slide. 00:37:13.307 --> 00:37:14.640 NEHA NARULA: Yeah, you're right. 00:37:14.640 --> 00:37:16.598 Sorry, that should be greater than or equal to. 00:37:16.598 --> 00:37:17.550 Sorry about that. 00:37:17.550 --> 00:37:19.860 So another invariant that needs to be maintained 00:37:19.860 --> 00:37:21.960 is that this output has not already 00:37:21.960 --> 00:37:24.840 been referenced in another transaction, 00:37:24.840 --> 00:37:28.540 in another valid transaction. 00:37:28.540 --> 00:37:31.120 And then, as I alluded to, a final invariant 00:37:31.120 --> 00:37:34.770 is around the lock time. 00:37:34.770 --> 00:37:41.520 So let's go into an example of how this actually works, 00:37:41.520 --> 00:37:44.730 this scriptSig and scriptPubKey thing. 00:37:44.730 --> 00:37:47.370 So I haven't really gone into detail yet about what this is. 00:37:47.370 --> 00:37:50.510 I sort of implied that this specified a key and this 00:37:50.510 --> 00:37:52.200 specified a signature. 00:37:52.200 --> 00:37:54.490 But what does this actually look like? 00:37:54.490 --> 00:37:57.400 And I mean, I think this is really, really interesting, 00:37:57.400 --> 00:37:57.900 actually. 00:37:57.900 --> 00:38:01.320 Because Bitcoin lets you specify lots 00:38:01.320 --> 00:38:04.500 of different scriptPubKeys and lots of different scriptSigs. 00:38:04.500 --> 00:38:06.870 And so this gives you this kind of flexibility 00:38:06.870 --> 00:38:10.020 so that you can program in different kinds of conditions 00:38:10.020 --> 00:38:12.660 on what it takes to redeem a transaction. 00:38:12.660 --> 00:38:14.910 So we're just going to talk about a couple very simple 00:38:14.910 --> 00:38:15.600 ones. 00:38:15.600 --> 00:38:17.460 Because to get into more complex stuff, 00:38:17.460 --> 00:38:22.230 we need to go really deep into this word, script. 00:38:22.230 --> 00:38:27.450 So basically the scriptPubKey and the scriptSig 00:38:27.450 --> 00:38:30.750 are composed of opcodes. 00:38:30.750 --> 00:38:33.840 So Bitcoin has a little less than 200 opcodes, 00:38:33.840 --> 00:38:36.450 and you write Bitcoin scripts using these opcodes. 00:38:40.520 --> 00:38:44.330 So let's talk about the most common Bitcoin script, 00:38:44.330 --> 00:38:46.760 which is Pay to Pubkey Hash. 00:38:46.760 --> 00:38:51.650 So the idea here is you want to send money to a public key. 00:38:51.650 --> 00:38:54.980 So Alice has Bob's public key, and Alice wants to pay Bob. 00:38:54.980 --> 00:38:59.150 And so Alice wants to send money to Bob's public key. 00:38:59.150 --> 00:39:00.890 Well, the reason that this is called 00:39:00.890 --> 00:39:04.430 pubkey hash, public keys are kind of big, 00:39:04.430 --> 00:39:08.060 and there's this nice-- you can kind of make 00:39:08.060 --> 00:39:10.400 this nice observation that you don't necessarily 00:39:10.400 --> 00:39:12.800 have to put the whole public key in the output. 00:39:12.800 --> 00:39:14.758 You can put a hash of the public in the output. 00:39:14.758 --> 00:39:17.383 And I think Tadge already talked about this when he was talking 00:39:17.383 --> 00:39:18.521 about Bitcoin addresses. 00:39:21.170 --> 00:39:26.680 So the scriptPubKey is instructions 00:39:26.680 --> 00:39:30.010 on how to verify a signature of a public key that 00:39:30.010 --> 00:39:35.900 has been hashed and the scriptSig 00:39:35.900 --> 00:39:39.350 is that signature and the actual public key, 00:39:39.350 --> 00:39:42.120 the pre-image of the hash public key. 00:39:42.120 --> 00:39:44.260 And this is what that looks like. 00:39:44.260 --> 00:39:47.370 So this is literally the scriptPubKey 00:39:47.370 --> 00:39:52.980 for a Pay to Pubkey Hash input or output, 00:39:52.980 --> 00:39:56.700 and this is literally the scriptSig that would you would 00:39:56.700 --> 00:40:01.440 use to redeem that output. 00:40:01.440 --> 00:40:06.660 So this right here would go inside one of these. 00:40:06.660 --> 00:40:09.810 And it would set the conditions under which 00:40:09.810 --> 00:40:12.240 you could redeem this output. 00:40:12.240 --> 00:40:15.480 And this right here would go inside the input 00:40:15.480 --> 00:40:18.360 of the transaction that's redeeming it. 00:40:18.360 --> 00:40:22.410 And let's take a look at how this actually works. 00:40:22.410 --> 00:40:26.970 So what the Bitcoin Script Interpreter does is, 00:40:26.970 --> 00:40:31.640 when it's evaluating whether or not a transaction is valid, 00:40:31.640 --> 00:40:33.710 it takes a look at the input, and it 00:40:33.710 --> 00:40:37.010 looks at which previous transaction it's looking at 00:40:37.010 --> 00:40:41.440 and which index the output is, and it grabs the scriptPubKey. 00:40:41.440 --> 00:40:43.940 Well, first of all, it makes sure that output hasn't already 00:40:43.940 --> 00:40:45.730 been spent. 00:40:45.730 --> 00:40:50.080 Then it grabs the scriptPubKey, and it takes the scriptSig 00:40:50.080 --> 00:40:53.450 and it puts them on top of each other, just like this. 00:40:53.450 --> 00:40:55.090 So that's the scriptSig up there, 00:40:55.090 --> 00:40:57.690 this is the scriptPubKey down here. 00:40:57.690 --> 00:41:01.630 And then it runs this combined script 00:41:01.630 --> 00:41:03.790 through the Bitcoin Script Interpreter, which 00:41:03.790 --> 00:41:05.710 is based on a stack model. 00:41:05.710 --> 00:41:09.160 So it starts pushing things onto the stack. 00:41:09.160 --> 00:41:11.200 It starts at the very top, and it 00:41:11.200 --> 00:41:15.850 starts pushing these items onto the stack and evaluating them. 00:41:15.850 --> 00:41:17.500 And so the rules are that constants 00:41:17.500 --> 00:41:18.970 get pushed onto the stack-- 00:41:18.970 --> 00:41:21.730 and then operations-- and these things right here are 00:41:21.730 --> 00:41:22.420 operations-- 00:41:22.420 --> 00:41:25.390 OP_DUP, OP_HASH160, OP_EQUALVERIFY, 00:41:25.390 --> 00:41:29.410 and OP_CHECKSIG, these are all Bitcoin opcodes. 00:41:29.410 --> 00:41:32.140 Operations have different rules as to how they're evaluated 00:41:32.140 --> 00:41:35.220 and what they consume off of the stack. 00:41:35.220 --> 00:41:37.480 So the first thing is a signature. 00:41:37.480 --> 00:41:40.440 We're going to pop the signature and push it onto the stack 00:41:40.440 --> 00:41:44.400 because it is a constant so this would 00:41:44.400 --> 00:41:47.880 be the signature that Alice might produce in order 00:41:47.880 --> 00:41:49.110 to spend her output. 00:41:52.020 --> 00:41:55.560 Then same thing with the pubkey, because the pubkey is also 00:41:55.560 --> 00:41:57.810 a constant. 00:41:57.810 --> 00:41:59.420 Then we're going to take this first-- 00:41:59.420 --> 00:42:01.503 now, OK, we're done with constants for the moment, 00:42:01.503 --> 00:42:04.056 and the next thing on the stack is OP_DUP. 00:42:04.056 --> 00:42:07.292 OP_DUP does basically exactly what it sounds like. 00:42:07.292 --> 00:42:08.750 It takes the thing that's currently 00:42:08.750 --> 00:42:11.220 on the top of the stack and it duplicates it. 00:42:11.220 --> 00:42:14.750 So the way that we consume OP_DUP is we take this pubkey 00:42:14.750 --> 00:42:18.090 and we create another copy of the pubkey. 00:42:18.090 --> 00:42:20.430 The next op is OP_HASH160. 00:42:20.430 --> 00:42:23.190 It also does exactly what it sounds like. 00:42:23.190 --> 00:42:26.790 It takes what's on the top of the stack, it hashes it, 00:42:26.790 --> 00:42:30.760 and it pushes that hash onto the top of the stack. 00:42:30.760 --> 00:42:34.050 So after we run OP_HASH160, this is 00:42:34.050 --> 00:42:36.330 what our stack will look like. 00:42:39.180 --> 00:42:41.750 Next thing is a constant. 00:42:41.750 --> 00:42:47.900 So we take that constant, which should be-- 00:42:47.900 --> 00:42:49.370 which is the hash of the pubkey. 00:42:49.370 --> 00:42:52.700 So this is the address that this money 00:42:52.700 --> 00:42:55.100 is being sent to, essentially. 00:42:55.100 --> 00:42:58.040 And we put that on the top of the stack. 00:42:58.040 --> 00:43:02.810 And then we run this operation called OP_EQUALVERIFY. 00:43:02.810 --> 00:43:05.780 Whenever an opcode ends with VERIFY, 00:43:05.780 --> 00:43:07.880 it means that it's a little bit special. 00:43:07.880 --> 00:43:11.660 It means that it has the ability to, if it fails, 00:43:11.660 --> 00:43:14.300 break out of the entire script execution 00:43:14.300 --> 00:43:17.570 and immediately cause transaction validation to fail. 00:43:17.570 --> 00:43:20.420 So OP_EQUALVERIFY does what it sounds 00:43:20.420 --> 00:43:23.300 like, it checks to make sure that the two 00:43:23.300 --> 00:43:26.600 things on the top of the stack are equal. 00:43:26.600 --> 00:43:28.790 And if they're not equal, then it immediately 00:43:28.790 --> 00:43:32.320 fails validation. 00:43:32.320 --> 00:43:34.725 So you'll note that what the two things 00:43:34.725 --> 00:43:36.100 at the top of the-- let's go back 00:43:36.100 --> 00:43:39.370 to what the two things on the top of the stack are right now. 00:43:39.370 --> 00:43:42.160 So we pushed the sig, we push a pubkey, 00:43:42.160 --> 00:43:45.550 we duplicated that pubkey, and these are from the scriptSig, 00:43:45.550 --> 00:43:49.510 so this is from whoever is redeeming the transaction. 00:43:49.510 --> 00:43:51.100 So whoever's redeeming the transaction 00:43:51.100 --> 00:43:53.410 has put a copy of this pub key on there, 00:43:53.410 --> 00:43:55.540 and now that pubkey is on the stack twice. 00:43:55.540 --> 00:43:58.690 We hashed the pubkey, and then we 00:43:58.690 --> 00:44:02.330 pushed the hash that was specified 00:44:02.330 --> 00:44:06.260 in the previous transaction that set up the rules for how 00:44:06.260 --> 00:44:08.090 to spend this. 00:44:08.090 --> 00:44:10.700 And then OP_EQUALVERIFY makes sure 00:44:10.700 --> 00:44:12.890 that these things are actually the same. 00:44:12.890 --> 00:44:15.040 And if they're not the same, then it'll 00:44:15.040 --> 00:44:18.380 fail that verify check and the entire transaction validation 00:44:18.380 --> 00:44:21.027 will abort, and it's an invalid transaction. 00:44:21.027 --> 00:44:22.610 So let's assume that they're the same. 00:44:22.610 --> 00:44:23.240 OK, great. 00:44:23.240 --> 00:44:25.730 Then OP_EQUALVERIFY-- then we continue 00:44:25.730 --> 00:44:27.050 transaction validation. 00:44:27.050 --> 00:44:34.130 And now we're left with this, OP_CHECKSIG, pubkey, sig. 00:44:34.130 --> 00:44:37.160 And this does exactly what you think it might do, 00:44:37.160 --> 00:44:39.680 it pops two things off the stack, 00:44:39.680 --> 00:44:44.570 checks to make sure that the signature is a valid signature 00:44:44.570 --> 00:44:46.070 for this pub key. 00:44:46.070 --> 00:44:49.010 And if it is, it pushes true onto the stack. 00:44:52.900 --> 00:44:56.170 And if there is a true on top of the stack-- in fact, 00:44:56.170 --> 00:44:58.510 I think if there's any constant on top of the stack 00:44:58.510 --> 00:45:02.900 when we've consumed all of the parts of our scriptSig 00:45:02.900 --> 00:45:07.583 and scriptPubKey, then this returns true 00:45:07.583 --> 00:45:09.250 and the transaction is considered valid. 00:45:12.250 --> 00:45:18.500 So this is a lot, and I know this is kind of complicated. 00:45:18.500 --> 00:45:23.352 So let's sort of step through this one more time. 00:45:23.352 --> 00:45:24.810 And there's just a couple of things 00:45:24.810 --> 00:45:26.640 that I want to make clear. 00:45:26.640 --> 00:45:31.860 This part right here is set up in the output of whatever 00:45:31.860 --> 00:45:33.510 transaction we're spending. 00:45:33.510 --> 00:45:36.450 So if Alice creates this transaction 00:45:36.450 --> 00:45:39.060 and she's spending to Bob, then Alice 00:45:39.060 --> 00:45:43.110 would put whose pubkey here? 00:45:43.110 --> 00:45:43.823 AUDIENCE: Bob's. 00:45:43.823 --> 00:45:45.490 NEHA NARULA: Hash of a pubkey, actually. 00:45:45.490 --> 00:45:49.600 Right, so Alice would put the hash of Bob's pubkey here. 00:45:49.600 --> 00:45:55.170 And when Bob's redeeming, what would go in the input that 00:45:55.170 --> 00:45:57.716 needs to redeem that output? 00:45:57.716 --> 00:46:01.345 AUDIENCE: [INAUDIBLE] 00:46:01.345 --> 00:46:02.720 NEHA NARULA: Sorry, I can't hear. 00:46:02.720 --> 00:46:03.803 AUDIENCE: Bob's signature. 00:46:03.803 --> 00:46:06.310 NEHA NARULA: Bob's signature and the pubkey 00:46:06.310 --> 00:46:07.990 that corresponds to that signature, 00:46:07.990 --> 00:46:10.840 because all we have is a hash. 00:46:10.840 --> 00:46:13.630 So those are the things that would 00:46:13.630 --> 00:46:14.840 get put on top of the stack. 00:46:14.840 --> 00:46:16.630 So up there, we have Bob's signature 00:46:16.630 --> 00:46:18.780 and we have Bob's pubkey. 00:46:18.780 --> 00:46:21.520 Again, those get pushed onto the stack 00:46:21.520 --> 00:46:25.960 because they're constants, duplicated, hash the top, 00:46:25.960 --> 00:46:28.900 copy over the hash, make sure that they're equal, 00:46:28.900 --> 00:46:31.180 and then check the signature. 00:46:31.180 --> 00:46:34.270 And this is a Pay to Pubkey Hash script. 00:46:34.270 --> 00:46:36.840 It is the most common script in Bitcoin. 00:46:36.840 --> 00:46:40.140 And this is this basically the standard way of spending money. 00:46:43.540 --> 00:46:44.980 Are there questions about this? 00:46:44.980 --> 00:46:45.310 Yes. 00:46:45.310 --> 00:46:46.685 AUDIENCE: Is there a significance 00:46:46.685 --> 00:46:48.970 in having that they're equal-verified 00:46:48.970 --> 00:46:50.947 before the CHECKSIG? 00:46:50.947 --> 00:46:52.780 Because it seems like they're both verifying 00:46:52.780 --> 00:46:54.208 tings, and I'm wondering-- 00:46:54.208 --> 00:46:56.000 NEHA NARULA: Yeah, that's a great question. 00:46:56.000 --> 00:46:59.650 So let's say that we didn't have this EQUALVERIFY here then 00:46:59.650 --> 00:47:03.202 what could a malicious spender possibly do? 00:47:03.202 --> 00:47:05.610 AUDIENCE: Well, I just meant flipping the order. 00:47:05.610 --> 00:47:08.440 We're still verifying both, but if you did the CHECKSIG first 00:47:08.440 --> 00:47:10.870 versus the EQUALVERIFY first, does that matter? 00:47:10.870 --> 00:47:11.900 NEHA NARULA: Oh, that's a good question. 00:47:11.900 --> 00:47:13.233 I don't think that would matter. 00:47:13.233 --> 00:47:13.810 I'm not sure. 00:47:13.810 --> 00:47:15.190 Would it matter? 00:47:15.190 --> 00:47:16.180 TADGE DRYJA: You could. 00:47:16.180 --> 00:47:18.740 It's faster to verify the two hashes are equal. 00:47:18.740 --> 00:47:21.370 The CHECKSIG operation takes a lot of CPU time 00:47:21.370 --> 00:47:23.500 so I guess the idea is, if you're going to fail, 00:47:23.500 --> 00:47:25.070 fail-- go the easy route. 00:47:25.070 --> 00:47:26.350 NEHA NARULA: Yes. 00:47:26.350 --> 00:47:27.250 Yes. 00:47:27.250 --> 00:47:29.790 AUDIENCE: So are all nodes on the network running this? 00:47:29.790 --> 00:47:30.880 NEHA NARULA: Yes. 00:47:30.880 --> 00:47:34.600 Every single node on the network is running the Bitcoin Script 00:47:34.600 --> 00:47:35.840 Interpreter inside of it. 00:47:35.840 --> 00:47:38.500 And the Bitcoin Script Interpreter is known as-- 00:47:38.500 --> 00:47:40.240 what's called consensus critical. 00:47:40.240 --> 00:47:44.290 So if two nodes have slightly different script interpreters 00:47:44.290 --> 00:47:46.750 that would interpret this in different ways, 00:47:46.750 --> 00:47:50.300 the network would have a consensus failure. 00:47:50.300 --> 00:47:50.810 Yes. 00:47:50.810 --> 00:47:53.060 AUDIENCE: Why not just Pay to Pubkey? 00:47:53.060 --> 00:47:55.580 NEHA NARULA: Pay to Pubkey is a thing, actually. 00:47:55.580 --> 00:47:58.860 And Pay to Pubkey Hash is considered better. 00:47:58.860 --> 00:48:02.240 And the reason for that is kind of subtle, actually. 00:48:02.240 --> 00:48:06.160 It's because-- so the hash of the pubkey 00:48:06.160 --> 00:48:09.680 is smaller than the pubkey. 00:48:09.680 --> 00:48:14.252 And this is definitely going on the blockchain. 00:48:14.252 --> 00:48:16.835 We don't know if this is going to go on the blockchain or not. 00:48:16.835 --> 00:48:18.680 Not all outputs are consumed. 00:48:18.680 --> 00:48:21.080 So let's put the small stuff here 00:48:21.080 --> 00:48:23.160 and the big stuff over here. 00:48:23.160 --> 00:48:24.570 It's about saving space. 00:48:24.570 --> 00:48:29.070 Also, the set of unspent transaction outputs 00:48:29.070 --> 00:48:32.370 is something that every node has to maintain. 00:48:32.370 --> 00:48:33.480 It's very important. 00:48:33.480 --> 00:48:37.030 You are referring to it quite a bit. 00:48:37.030 --> 00:48:39.570 This is not something that every node has to maintain. 00:48:39.570 --> 00:48:42.888 And so you want to make this smaller, even 00:48:42.888 --> 00:48:44.430 at the expense of making this bigger. 00:48:47.690 --> 00:48:48.190 Yes. 00:48:48.190 --> 00:48:49.857 AUDIENCE: So then you could accidentally 00:48:49.857 --> 00:48:53.109 sign a transaction that has a public key but a script that 00:48:53.109 --> 00:48:55.222 doesn't actually verify it? 00:48:55.222 --> 00:48:56.680 NEHA NARULA: Could you accidentally 00:48:56.680 --> 00:48:59.097 sign a transaction that has a public key but a script that 00:48:59.097 --> 00:49:00.400 doesn't verify? 00:49:00.400 --> 00:49:03.950 Let me see if this answers your question. 00:49:03.950 --> 00:49:09.470 So here is an example of an unspendable output. 00:49:09.470 --> 00:49:13.330 The unspendable output has an OP_RETURN 00:49:13.330 --> 00:49:16.980 as the first instruction of its scriptPubKey. 00:49:16.980 --> 00:49:18.640 OP_RETURN does what you might think 00:49:18.640 --> 00:49:21.390 it does, which means when you evaluate it, 00:49:21.390 --> 00:49:25.060 it returns immediately and says invalid. 00:49:25.060 --> 00:49:31.280 And so if you have one of these in your transaction 00:49:31.280 --> 00:49:34.730 in your scriptPubKey, there is no scriptSig 00:49:34.730 --> 00:49:39.450 that could possibly redeem the scriptPubKey. 00:49:39.450 --> 00:49:41.040 You could create anything you wanted, 00:49:41.040 --> 00:49:42.540 and no matter what you put on there, 00:49:42.540 --> 00:49:44.110 it would never evaluate to true. 00:49:44.110 --> 00:49:46.193 There's no way to actually redeem the scriptPubKey 00:49:46.193 --> 00:49:46.830 in this output. 00:49:46.830 --> 00:49:47.820 Does that answer your question? 00:49:47.820 --> 00:49:48.660 AUDIENCE: I think it's the opposite. 00:49:48.660 --> 00:49:51.035 I was asking if you could accidentally get something that 00:49:51.035 --> 00:49:52.631 would always evaluate to true. 00:49:52.631 --> 00:49:54.980 NEHA NARULA: Ah, OK, well, that's the next slide. 00:49:54.980 --> 00:49:56.940 [CHUCKLING] 00:49:56.940 --> 00:50:00.990 So yes, this is what's called an anyone-can-spend output. 00:50:00.990 --> 00:50:02.580 The simplest anyone-can-spend output 00:50:02.580 --> 00:50:04.500 is just an empty scriptPubKey. 00:50:04.500 --> 00:50:09.030 Because a scriptSig sig OP_TRUE in it would evaluate to true. 00:50:09.030 --> 00:50:13.350 Notice here there's no public keys, there's no signatures, 00:50:13.350 --> 00:50:15.395 there's no hashes of public keys. 00:50:15.395 --> 00:50:16.770 The scriptPubKey doesn't actually 00:50:16.770 --> 00:50:20.560 specify any public keys. 00:50:20.560 --> 00:50:23.800 And so-- but when you evaluate this right here, 00:50:23.800 --> 00:50:26.080 you'd push OP_TRUE onto the stack, 00:50:26.080 --> 00:50:28.330 and then you would finish, and there would be a true-- 00:50:28.330 --> 00:50:30.010 OP_TRUE would push-- sorry, OP_TRUE 00:50:30.010 --> 00:50:31.540 would push a true onto the stack. 00:50:31.540 --> 00:50:32.915 And then when you finished, there 00:50:32.915 --> 00:50:35.442 would be true on the stack, meaning this is valid. 00:50:35.442 --> 00:50:37.650 AUDIENCE: Also another way, you could put the OP_TRUE 00:50:37.650 --> 00:50:38.653 in the output script as well. 00:50:38.653 --> 00:50:40.625 Then you wouldn't have to push it because-- 00:50:40.625 --> 00:50:42.570 NEHA NARULA: Yeah. 00:50:42.570 --> 00:50:45.090 So this is an anyone-can-spend output, 00:50:45.090 --> 00:50:49.550 and this is a no-one-can-spend output. 00:50:49.550 --> 00:50:52.070 And there's no public keys in here. 00:50:52.070 --> 00:50:53.990 There's no signatures in there. 00:50:53.990 --> 00:50:57.680 So you can totally create outputs that have nothing 00:50:57.680 --> 00:51:02.030 to do with signatures, or maybe you verify multiple signatures, 00:51:02.030 --> 00:51:04.050 which we're not going to go into right now, 00:51:04.050 --> 00:51:05.450 but it's also possible. 00:51:05.450 --> 00:51:06.554 Yes. 00:51:06.554 --> 00:51:09.280 AUDIENCE: Can SIG have a [INAUDIBLE] in it? 00:51:09.280 --> 00:51:10.435 NEHA NARULA: Yes. 00:51:10.435 --> 00:51:11.310 AUDIENCE: [INAUDIBLE] 00:51:11.310 --> 00:51:14.370 NEHA NARULA: Yes, it can. 00:51:14.370 --> 00:51:17.990 AUDIENCE: But the list of [INAUDIBLE] are [INAUDIBLE] 00:51:17.990 --> 00:51:20.690 NEHA NARULA: There are fewer than 200 opcodes. 00:51:20.690 --> 00:51:22.758 The number of standard opcodes is even smaller, 00:51:22.758 --> 00:51:24.800 meaning that there's a very small number that you 00:51:24.800 --> 00:51:27.420 can use in your scriptSigs and scriptPubKeys. 00:51:27.420 --> 00:51:31.070 And it's definitely possible, if you 00:51:31.070 --> 00:51:34.850 write some weird scriptPubKey or some weird scriptSig 00:51:34.850 --> 00:51:38.787 to accidentally create outputs that are never spendable, 00:51:38.787 --> 00:51:40.370 or to accidentally create outputs that 00:51:40.370 --> 00:51:41.970 could be spent by someone else. 00:51:41.970 --> 00:51:46.250 So there's a standard set of scriptPubKeys to use. 00:51:46.250 --> 00:51:48.920 And I would not recommend going outside that set, 00:51:48.920 --> 00:51:51.200 except for in the lab that you're going to do, 00:51:51.200 --> 00:51:53.750 because we have some more fun ones in there. 00:51:53.750 --> 00:51:54.387 Yes. 00:51:54.387 --> 00:51:56.720 AUDIENCE: Could you explain a little bit more on the Pay 00:51:56.720 --> 00:51:59.190 to Script Hash. 00:51:59.190 --> 00:52:01.715 Kind of like what [INAUDIBLE] 00:52:01.715 --> 00:52:03.340 NEHA NARULA: Sure, Pay to Script Hash-- 00:52:03.340 --> 00:52:05.465 I don't actually have slides on Pay to Script Hash, 00:52:05.465 --> 00:52:09.700 so I'm not sure that we can do a good job of explaining it 00:52:09.700 --> 00:52:10.630 right now. 00:52:10.630 --> 00:52:15.960 But the idea behind Pay to Script Hash is that-- 00:52:15.960 --> 00:52:18.220 yeah, I don't have the slides for it. 00:52:18.220 --> 00:52:22.900 But the idea is that you're going to put, instead 00:52:22.900 --> 00:52:25.570 of this particular scriptPubKey here, 00:52:25.570 --> 00:52:27.430 you're going to have a scriptPubKey that 00:52:27.430 --> 00:52:30.770 includes a hash of a script. 00:52:30.770 --> 00:52:35.820 And then the scriptSig has to produce that script, 00:52:35.820 --> 00:52:38.690 and it has to match that hash, and the whole thing 00:52:38.690 --> 00:52:44.000 has to verify is the rough idea behind Pay to Script Hash. 00:52:44.000 --> 00:52:48.400 And we can produce an example of that for you tomorrow. 00:52:48.400 --> 00:52:50.410 But the cool thing about that is you 00:52:50.410 --> 00:52:53.740 don't even know what you have to do to redeem this output. 00:52:53.740 --> 00:52:58.310 So someone has to produce a script that has the same hash, 00:52:58.310 --> 00:53:00.160 and when combined with the scriptPubKey, 00:53:00.160 --> 00:53:01.090 will evaluate to true. 00:53:01.090 --> 00:53:03.382 AUDIENCE: And that script would be pushed on the stack? 00:53:03.382 --> 00:53:07.060 NEHA NARULA: Yeah, so the scriptSig and the scriptPubKey 00:53:07.060 --> 00:53:09.190 literally just get concatenated together 00:53:09.190 --> 00:53:11.650 and then evaluated as one thing. 00:53:11.650 --> 00:53:14.080 So yeah, it would just go through the same thing. 00:53:16.610 --> 00:53:17.820 Any more questions? 00:53:23.807 --> 00:53:24.890 So what do you guys think? 00:53:24.890 --> 00:53:25.600 Is this good? 00:53:25.600 --> 00:53:26.254 Is this bad? 00:53:33.840 --> 00:53:44.548 AUDIENCE: Could you try to [INAUDIBLE] 00:53:44.548 --> 00:53:46.340 NEHA NARULA: Yeah, that's a great question. 00:53:46.340 --> 00:53:50.260 So the question is, could you DDoS a network 00:53:50.260 --> 00:53:55.080 by creating transactions that are not spendable? 00:53:55.080 --> 00:53:56.860 AUDIENCE: So you still [INAUDIBLE] 00:53:56.860 --> 00:53:59.680 NEHA NARULA: You can't really DDoS the network, per se. 00:53:59.680 --> 00:54:02.350 So this is an example of a transaction 00:54:02.350 --> 00:54:03.670 that's not spendable. 00:54:03.670 --> 00:54:06.430 And see how it has this OP_RETURN, and it says, 00:54:06.430 --> 00:54:07.210 whatever. 00:54:07.210 --> 00:54:09.040 There is this pattern of people who 00:54:09.040 --> 00:54:11.860 like to store things in the Bitcoin blockchain, 00:54:11.860 --> 00:54:15.910 because it's there, and it's very highly replicated. 00:54:15.910 --> 00:54:20.140 And so one type of transaction that a lot of people make 00:54:20.140 --> 00:54:23.500 is and OP_RETURN with a hash of some data in it 00:54:23.500 --> 00:54:24.970 or some data in it. 00:54:24.970 --> 00:54:28.330 These are unspendable outputs that 00:54:28.330 --> 00:54:30.970 will live on the Bitcoin blockchain forever, 00:54:30.970 --> 00:54:33.940 and will be part of the UTXO set, possibly forever. 00:54:37.450 --> 00:54:39.700 Generally, Bitcoin developers discourage 00:54:39.700 --> 00:54:41.680 using Bitcoin in this way because it 00:54:41.680 --> 00:54:43.518 does bloat the UTXO set. 00:54:46.048 --> 00:54:48.340 That said, there's nothing to prevent you from doing it 00:54:48.340 --> 00:54:49.610 if you want to pay the fees. 00:54:49.610 --> 00:54:50.390 What? 00:54:50.390 --> 00:54:52.040 TADGE DRYJA: It's actually not part of the UTXO set 00:54:52.040 --> 00:54:53.350 because it has the OP_RETURN. 00:54:53.350 --> 00:54:53.920 NEHA NARULA: Oh, really? 00:54:53.920 --> 00:54:54.460 I didn't know that. 00:54:54.460 --> 00:54:56.810 OK, I didn't know that they weren't kept in the UTXO set. 00:54:56.810 --> 00:54:58.477 TADGE DRYJA: [INAUDIBLE] they would just 00:54:58.477 --> 00:55:00.800 made [INAUDIBLE] key hash into whatever [INAUDIBLE] 00:55:00.800 --> 00:55:02.750 and that would bloat the UTXO set. 00:55:02.750 --> 00:55:03.480 So it's like, well, this is not [INAUDIBLE] 00:55:03.480 --> 00:55:04.900 NEHA NARULA: OK, I didn't know that those 00:55:04.900 --> 00:55:06.040 weren't included in the UTXO. 00:55:06.040 --> 00:55:06.730 So that's good. 00:55:06.730 --> 00:55:08.750 So then it doesn't boat the UTXO set, 00:55:08.750 --> 00:55:10.180 it just goes in the blockchain. 00:55:10.180 --> 00:55:12.805 And you paid the fee to put your transaction in the blockchain. 00:55:12.805 --> 00:55:14.020 So good for you. 00:55:14.020 --> 00:55:16.720 Yes. 00:55:16.720 --> 00:55:18.390 AUDIENCE: What's the architectural logic 00:55:18.390 --> 00:55:21.485 for having a specific set of opcodes that Bitcoin can run? 00:55:21.485 --> 00:55:24.235 Why not use a more general programming language? 00:55:24.235 --> 00:55:26.218 Is it just to have control? 00:55:26.218 --> 00:55:27.760 NEHA NARULA: That's a great question. 00:55:27.760 --> 00:55:31.770 So why have this weird Op code thing, right? 00:55:31.770 --> 00:55:34.710 I mean, what kind of sense does this make? 00:55:34.710 --> 00:55:40.550 So the problem with the general programming language 00:55:40.550 --> 00:55:44.940 is it's really easy to shoot yourself in the foot. 00:55:44.940 --> 00:55:48.000 It's really easy to write a program that you think-- 00:55:48.000 --> 00:55:51.383 how many of you have had a bug in your program ever? 00:55:51.383 --> 00:55:52.800 Please, all of you should probably 00:55:52.800 --> 00:55:53.950 raise their hands, right? 00:55:53.950 --> 00:55:55.260 [CHUCKLING] 00:55:55.260 --> 00:55:57.390 And how many of you have had bugs in your program 00:55:57.390 --> 00:55:59.790 that showed up a lot later than you thought they would, 00:55:59.790 --> 00:56:02.760 when you thought your program didn't have any bugs? 00:56:02.760 --> 00:56:06.010 So these things, once you put them out there, 00:56:06.010 --> 00:56:07.470 these scriptPubKeys and script tag, 00:56:07.470 --> 00:56:10.770 once you put these transactions out there, they're out there. 00:56:10.770 --> 00:56:13.350 You cannot take them back-- 00:56:13.350 --> 00:56:15.270 well, not easily. 00:56:15.270 --> 00:56:18.420 And they might execute in ways that you didn't 00:56:18.420 --> 00:56:20.400 anticipate them executing. 00:56:20.400 --> 00:56:23.490 The more complicated the script you write, the more likely 00:56:23.490 --> 00:56:26.670 it is that there's some hole in your script, some way 00:56:26.670 --> 00:56:29.940 of satisfying it that you didn't anticipate, 00:56:29.940 --> 00:56:33.000 that could end up stealing your money. 00:56:33.000 --> 00:56:35.040 So with a general programming language, 00:56:35.040 --> 00:56:39.067 well, you might think, oh, well, these OP codes 00:56:39.067 --> 00:56:41.400 are super tricky and weird, and I don't understand them, 00:56:41.400 --> 00:56:43.358 at least with the general programming language, 00:56:43.358 --> 00:56:45.664 I'm more likely to write correct things, right? 00:56:45.664 --> 00:56:46.164 Eh. 00:56:46.164 --> 00:56:47.580 [CHUCKLING] 00:56:47.580 --> 00:56:49.470 Actually, having this strange opcode language 00:56:49.470 --> 00:56:50.620 has a lot of benefits. 00:56:50.620 --> 00:56:53.190 So number one, it's not Turing-complete. 00:56:53.190 --> 00:56:56.760 You know exactly how much CPU it is 00:56:56.760 --> 00:56:59.850 going to take to run these scripts because 00:56:59.850 --> 00:57:03.870 of the nature of the opcodes and the language. 00:57:03.870 --> 00:57:05.880 There's no FOR loops in here. 00:57:05.880 --> 00:57:10.170 You know you can't just run a WHILE that takes forever. 00:57:10.170 --> 00:57:12.390 This is a stack-based language. 00:57:12.390 --> 00:57:16.373 And so it's very easy to tell how long a transaction is 00:57:16.373 --> 00:57:17.790 actually going to take to execute. 00:57:17.790 --> 00:57:19.790 And this is really important, because every node 00:57:19.790 --> 00:57:22.860 in the network has to execute these things. 00:57:22.860 --> 00:57:26.550 So you don't want a script sneaking in there that's 00:57:26.550 --> 00:57:30.750 going to take hours to execute. 00:57:30.750 --> 00:57:34.210 It's also-- you can look at the number of opcodes 00:57:34.210 --> 00:57:36.565 in the script, and like I said, get a rough sense of how 00:57:36.565 --> 00:57:37.690 expensive it's going to be. 00:57:37.690 --> 00:57:40.210 And that's why there are limits on the number of opcodes 00:57:40.210 --> 00:57:41.410 you can have in a script. 00:57:41.410 --> 00:57:43.030 It's very difficult to do that if you have a more 00:57:43.030 --> 00:57:44.260 general programming language. 00:57:46.930 --> 00:57:48.440 So those are a couple of reasons. 00:57:48.440 --> 00:57:50.560 And I mean, I think it's important to point out 00:57:50.560 --> 00:57:53.200 that Ethereum, which does have a more general programming 00:57:53.200 --> 00:57:56.020 language, there are constantly problems popping up 00:57:56.020 --> 00:57:58.440 where people are taking advantage of transact 00:57:58.440 --> 00:58:02.020 of contracts, even fairly well-understood ones-- 00:58:02.020 --> 00:58:04.840 or we thought they were well understood-- 00:58:04.840 --> 00:58:08.260 and figuring out how to freeze people's funds 00:58:08.260 --> 00:58:09.940 or steal people's funds. 00:58:09.940 --> 00:58:12.850 So that's the motivation behind this sort 00:58:12.850 --> 00:58:16.540 of strange, stack-based opcode language. 00:58:16.540 --> 00:58:20.080 Are there any other questions? 00:58:20.080 --> 00:58:21.850 Yeah, back there. 00:58:21.850 --> 00:58:24.780 AUDIENCE: You talked about unspendable transactions 00:58:24.780 --> 00:58:25.280 outputs. 00:58:25.280 --> 00:58:26.990 NEHA NARULA: Outputs, Yes. 00:58:26.990 --> 00:58:29.690 AUDIENCE: Could you comment on colored coins? 00:58:29.690 --> 00:58:31.210 NEHA NARULA: Oh, colored coins-- 00:58:31.210 --> 00:58:32.410 no comment on colored coins. 00:58:32.410 --> 00:58:33.400 I don't understand them well enough 00:58:33.400 --> 00:58:34.630 to talk about them right now. 00:58:34.630 --> 00:58:35.907 Yeah. 00:58:35.907 --> 00:58:36.490 What did you-- 00:58:36.490 --> 00:58:38.198 TADGE DRYJA: I would say one other thing. 00:58:38.198 --> 00:58:41.100 Most of the-- a lot of the cool opcodes are disabled. 00:58:41.100 --> 00:58:43.000 So it's very limited. 00:58:43.000 --> 00:58:43.792 It seems like you-- 00:58:43.792 --> 00:58:45.625 there's a list of, here's all these opcodes. 00:58:45.625 --> 00:58:47.210 Oh, I can multiply numbers together. 00:58:47.210 --> 00:58:47.877 That's disabled. 00:58:47.877 --> 00:58:48.880 [INAUDIBLE] 00:58:48.880 --> 00:58:49.900 NEHA NARULA: Yeah. 00:58:49.900 --> 00:58:52.180 And I do want to stress, when you're dealing with real 00:58:52.180 --> 00:58:55.050 money-- so not in the lab for this class-- 00:58:55.050 --> 00:58:57.280 you want to stick with very standard scripts. 00:58:57.280 --> 00:58:59.627 You don't want to write super-crazy, weird, tricky 00:58:59.627 --> 00:59:01.210 scripts, or if you do, you want to get 00:59:01.210 --> 00:59:02.850 them vetted very carefully. 00:59:02.850 --> 00:59:03.350 Yes. 00:59:03.350 --> 00:59:06.340 AUDIENCE: Who is disabling and enabling these things? 00:59:06.340 --> 00:59:08.220 NEHA NARULA: Great question. 00:59:08.220 --> 00:59:11.440 So there are two levels at which things can be 00:59:11.440 --> 00:59:13.330 enabled or disabled in Bitcoin. 00:59:13.330 --> 00:59:15.380 So first, there's the validation rules, 00:59:15.380 --> 00:59:18.700 so what makes a transaction valid or not valid. 00:59:18.700 --> 00:59:23.440 Meaning that if a transaction is invalid and it's in a block, 00:59:23.440 --> 00:59:24.850 that whole block is invalid. 00:59:24.850 --> 00:59:27.610 If a transaction is invalid and in a block, and that block 00:59:27.610 --> 00:59:30.850 is in a blockchain, that entire blockchain is invalid. 00:59:30.850 --> 00:59:32.860 So there's that level. 00:59:32.860 --> 00:59:36.070 And we're going to talk about how those rules change 00:59:36.070 --> 00:59:37.360 and who sets those rules. 00:59:37.360 --> 00:59:39.280 But you can consider them sort of, for now, 00:59:39.280 --> 00:59:42.280 being set by the code, the Bitcoin Core-- 00:59:42.280 --> 00:59:45.520 or the Bitcoin software, which specifies what is valid 00:59:45.520 --> 00:59:46.450 and what is invalid. 00:59:46.450 --> 00:59:48.310 But there is another level at which 00:59:48.310 --> 00:59:55.060 you can adjust what ends up getting accepted 00:59:55.060 --> 00:59:56.060 or not accepted. 00:59:56.060 --> 00:59:59.960 And that is what is transmitted over the peer-to-peer network. 00:59:59.960 --> 01:00:03.160 So there are transactions that are valid, but are 01:00:03.160 --> 01:00:05.470 what's known as non-standard. 01:00:05.470 --> 01:00:09.310 And that transaction, if it gets into a block, 01:00:09.310 --> 01:00:10.630 that block is still valid. 01:00:10.630 --> 01:00:13.540 But the nodes in the network, if it sees that transaction, 01:00:13.540 --> 01:00:16.990 won't relay them around. 01:00:16.990 --> 01:00:19.900 So you'd have to be a miner and actually decide, 01:00:19.900 --> 01:00:22.280 I want this transaction in a block, and mine that block. 01:00:22.280 --> 01:00:24.030 And if you do that, everyone will consider 01:00:24.030 --> 01:00:25.870 it a valid block, OK, fine. 01:00:25.870 --> 01:00:28.440 But no one will actually send your transaction around. 01:00:28.440 --> 01:00:30.267 And so if you're not a miner yourself, 01:00:30.267 --> 01:00:32.600 the odds of it getting into the blockchain are very low. 01:00:32.600 --> 01:00:35.710 And so those are the two sets of rules. 01:00:35.710 --> 01:00:39.280 The peer-to-peer rules are more restrictive than the validation 01:00:39.280 --> 01:00:39.780 rules. 01:00:44.010 --> 01:00:46.440 OK, so we already kind of started 01:00:46.440 --> 01:00:48.042 talking about this a little bit-- 01:00:48.042 --> 01:00:49.500 what are the benefits of your UTXOs 01:00:49.500 --> 01:00:51.270 and what are the downsides of UTXOs? 01:00:51.270 --> 01:00:55.382 So one of the benefits of UTXOs is that-- 01:00:55.382 --> 01:01:00.360 do you guys see how they help with replay attacks? 01:01:00.360 --> 01:01:02.075 Sure, I can copy this transaction 01:01:02.075 --> 01:01:04.200 and put multiple out there, but you're only allowed 01:01:04.200 --> 01:01:05.370 to spend an output once. 01:01:05.370 --> 01:01:07.560 And once you consume that output, that's it. 01:01:07.560 --> 01:01:11.260 So you can't really do replay attacks in this model. 01:01:11.260 --> 01:01:13.242 So it's a very sort of elegant way 01:01:13.242 --> 01:01:14.700 of getting rid of the replay attack 01:01:14.700 --> 01:01:19.710 problem without having to store a nonce per account 01:01:19.710 --> 01:01:21.370 in your system. 01:01:21.370 --> 01:01:25.020 Another benefit is that you can actually 01:01:25.020 --> 01:01:28.960 get a little bit better privacy with this UTXO system. 01:01:28.960 --> 01:01:32.940 Because you don't have to use the same public key 01:01:32.940 --> 01:01:34.180 for all of your transactions. 01:01:34.180 --> 01:01:36.910 You can generate new ones every single time, 01:01:36.910 --> 01:01:39.813 and then combine UTXOs from different things into-- 01:01:39.813 --> 01:01:41.980 I mean, you're going to have to combine them anyway, 01:01:41.980 --> 01:01:44.070 even if they did spend at the same public key. 01:01:44.070 --> 01:01:46.133 So why not generate fresh ones all the time? 01:01:46.133 --> 01:01:47.550 And it becomes a little bit harder 01:01:47.550 --> 01:01:50.490 to track who you're spending and who you're paying to. 01:01:50.490 --> 01:01:53.845 In the account-based model, you need to have-- 01:01:53.845 --> 01:01:55.470 it's more likely that all of your funds 01:01:55.470 --> 01:01:59.350 are going to be in one account in order to make a spend. 01:01:59.350 --> 01:02:04.000 Now a downside of UTXOs is that they're complicated. 01:02:04.000 --> 01:02:06.310 So when I first heard about UTXOs 01:02:06.310 --> 01:02:08.890 and I first understood how Bitcoin worked, I was like, 01:02:08.890 --> 01:02:10.270 why does Bitcoin work this way? 01:02:10.270 --> 01:02:11.200 This makes zero sense. 01:02:11.200 --> 01:02:14.500 An account-based model would be so much easier. 01:02:14.500 --> 01:02:17.470 And I mean, I think, for wallet providers 01:02:17.470 --> 01:02:20.020 and for people who are writing user software, 01:02:20.020 --> 01:02:23.510 it is easier to deal with an account-based model than a UTXO 01:02:23.510 --> 01:02:24.340 model. 01:02:24.340 --> 01:02:27.580 Because people who are writing Bitcoin wallet software 01:02:27.580 --> 01:02:30.280 have to keep track of all of your UTXOs 01:02:30.280 --> 01:02:32.320 and then figure out how to combine them 01:02:32.320 --> 01:02:34.390 to get the amount that you want to spend, 01:02:34.390 --> 01:02:38.560 and make sure that they produce what are called change outputs 01:02:38.560 --> 01:02:40.750 the right way, so you don't accidentally 01:02:40.750 --> 01:02:42.910 lose some of your money because you're 01:02:42.910 --> 01:02:44.740 spending an output that has 100 bitcoin 01:02:44.740 --> 01:02:46.660 but you're only paying someone one bitcoin. 01:02:46.660 --> 01:02:49.700 You better make sure you have that 99 bitcoin output in there 01:02:49.700 --> 01:02:50.800 going back to you. 01:02:50.800 --> 01:02:54.717 So it just makes everything a little bit more complicated. 01:02:54.717 --> 01:02:56.800 You can't just spend the amount you want to spend. 01:02:56.800 --> 01:02:58.800 You have to find these outputs, and combine them 01:02:58.800 --> 01:03:03.140 in the right way, and figure all of this stuff out. 01:03:03.140 --> 01:03:05.210 Another problem is around fungibility. 01:03:05.210 --> 01:03:07.670 So this is why I say that bitcoin is not fungible, 01:03:07.670 --> 01:03:10.370 because of these outputs, and the fact that you have 01:03:10.370 --> 01:03:14.330 to point back to the output that you're going to spend, 01:03:14.330 --> 01:03:18.170 which ends up creating what's called a transaction graph. 01:03:18.170 --> 01:03:21.860 So you can sort of see how things are chained together, 01:03:21.860 --> 01:03:25.310 and you can actually discern quite a bit of information 01:03:25.310 --> 01:03:26.990 about what's going on in the network. 01:03:26.990 --> 01:03:31.010 And in fact, the FBI has used the transaction graph 01:03:31.010 --> 01:03:33.140 in some of its cases around Silk Road, 01:03:33.140 --> 01:03:35.250 to see where Bitcoin was moving. 01:03:35.250 --> 01:03:37.460 And there are many companies out there-- 01:03:37.460 --> 01:03:41.330 Chain Analysis, Elliptic, that provide services 01:03:41.330 --> 01:03:45.650 based around the fact that Bitcoin's transaction graph is 01:03:45.650 --> 01:03:49.580 totally open, and so you can see how coins are moving around. 01:03:49.580 --> 01:03:53.450 So in addition to the transaction graph problem, 01:03:53.450 --> 01:03:56.900 you kind of lose this aspect of fungibility in the sense 01:03:56.900 --> 01:04:00.920 that, let's say, that I know that, for whatever reason, 01:04:00.920 --> 01:04:05.180 these coins came from, let's say, I don't know, 01:04:05.180 --> 01:04:08.150 a terrorist or something like that. 01:04:08.150 --> 01:04:11.780 You then know exactly where those coins are going, 01:04:11.780 --> 01:04:14.360 and you can kind of see the chain of transactions 01:04:14.360 --> 01:04:16.310 that come off of those coins. 01:04:16.310 --> 01:04:19.580 And it sort of creates a potential opportunity 01:04:19.580 --> 01:04:21.500 for someone to blacklist coins. 01:04:21.500 --> 01:04:27.040 Or you might decide that you like coins that were produced-- 01:04:27.040 --> 01:04:29.750 that are fresher than other coins. 01:04:29.750 --> 01:04:33.330 So there's this ability to distinguish between coins, 01:04:33.330 --> 01:04:35.150 which is a little bit troublesome, 01:04:35.150 --> 01:04:37.580 because fungibility is generally considered 01:04:37.580 --> 01:04:39.590 a very good property for money to have, 01:04:39.590 --> 01:04:41.238 and this is not entirely fungible. 01:04:41.238 --> 01:04:42.530 But people are working on that. 01:04:46.160 --> 01:04:49.070 Any other questions? 01:04:49.070 --> 01:04:52.120 I alluded to this earlier, but every single node 01:04:52.120 --> 01:04:53.770 that's running the Bitcoin software 01:04:53.770 --> 01:04:56.500 keeps this data structure called the UTXO set. 01:04:56.500 --> 01:05:00.160 So these are all of the outstanding, unspent 01:05:00.160 --> 01:05:01.300 transaction outputs. 01:05:01.300 --> 01:05:03.550 It's all of the coins in the system, all 01:05:03.550 --> 01:05:07.780 of the money in the system that's available to be spent. 01:05:07.780 --> 01:05:09.880 The way that this is computed is, 01:05:09.880 --> 01:05:12.790 when a Bitcoin node comes online and starts 01:05:12.790 --> 01:05:16.420 to download the blockchain, they run through the blockchain 01:05:16.420 --> 01:05:18.190 and continuously add and remove things 01:05:18.190 --> 01:05:21.760 from the UTXO set to produce a UTXO 01:05:21.760 --> 01:05:24.010 set that is valid for whatever the last block is 01:05:24.010 --> 01:05:25.330 that it's seen. 01:05:25.330 --> 01:05:29.230 When a new block comes in, a node runs through the block, 01:05:29.230 --> 01:05:31.810 and again removes and adds things 01:05:31.810 --> 01:05:35.770 to the UTXO set as necessary. 01:05:35.770 --> 01:05:42.190 Right now, there's about 60 million UTXOs in the UTXO set. 01:05:42.190 --> 01:05:46.690 A lot of them, unfortunately-- well, a lot, 01:05:46.690 --> 01:05:50.260 in terms of bytes of the UTXO set, a lot of them 01:05:50.260 --> 01:05:53.480 are very small and are unlikely to get spent very soon. 01:05:53.480 --> 01:05:54.910 So that's kind of a bummer. 01:05:54.910 --> 01:05:58.530 The UTXO set is about three gigabytes right now, I think. 01:05:58.530 --> 01:06:01.180 And so every node in Bitcoin, in addition 01:06:01.180 --> 01:06:05.230 to storing the blockchain, stores this UTXO set, 01:06:05.230 --> 01:06:08.740 and uses this data structure to very quickly tell 01:06:08.740 --> 01:06:13.780 if a transaction is a double-spend or not. 01:06:13.780 --> 01:06:15.340 Any questions about the UTXO set? 01:06:15.340 --> 01:06:16.183 Yes, SJ. 01:06:16.183 --> 01:06:18.350 AUDIENCE: How do you avoid having small transactions 01:06:18.350 --> 01:06:20.198 accumulate over time? 01:06:20.198 --> 01:06:21.740 NEHA NARULA: That's a good question-- 01:06:21.740 --> 01:06:24.100 how do you avoid having small transactions accumulate 01:06:24.100 --> 01:06:25.180 over time? 01:06:25.180 --> 01:06:27.323 I don't know the answer to that question. 01:06:27.323 --> 01:06:28.240 It's kind of a bummer. 01:06:30.910 --> 01:06:32.860 It's not really in people's interest 01:06:32.860 --> 01:06:36.370 to generate those transactions because you're creating-- 01:06:36.370 --> 01:06:39.280 I haven't talked about how fees are computed yet. 01:06:39.280 --> 01:06:43.840 But fees are measured according to the resources 01:06:43.840 --> 01:06:45.790 that a transaction takes up in the system. 01:06:45.790 --> 01:06:48.260 Fees are measured according to the size of the transaction. 01:06:48.260 --> 01:06:53.260 So if you have to combine a whole bunch of tiny outputs 01:06:53.260 --> 01:06:54.760 in order to get a big enough sum, 01:06:54.760 --> 01:06:57.280 you're going to have to pay more in fees. 01:06:57.280 --> 01:06:59.530 So it's not really in your interest 01:06:59.530 --> 01:07:01.420 to produce a lot of these tiny things. 01:07:01.420 --> 01:07:04.388 But there's not really a good way of stopping it. 01:07:04.388 --> 01:07:06.430 And in fact there have been services in the past, 01:07:06.430 --> 01:07:08.290 like Satoshi dice and whatnot, that 01:07:08.290 --> 01:07:12.130 have created a ton of very tiny outputs 01:07:12.130 --> 01:07:14.212 and it bloated the UTXO set. 01:07:14.212 --> 01:07:16.420 I don't know, Tadge, if you have any insight into how 01:07:16.420 --> 01:07:18.293 to stop that from happening. 01:07:18.293 --> 01:07:19.710 TADGE DRYJA: Make the fees higher. 01:07:19.710 --> 01:07:21.127 NEHA NARULA: Other than the fees-- 01:07:21.127 --> 01:07:22.630 other than the fees, yeah. 01:07:22.630 --> 01:07:24.140 TADGE DRYJA: Better wallet software. 01:07:24.140 --> 01:07:28.732 A lot of it's [? unintentional. ?] 01:07:28.732 --> 01:07:29.440 NEHA NARULA: Yes. 01:07:29.440 --> 01:07:32.023 AUDIENCE: You mentioned that one other [INAUDIBLE] is privacy, 01:07:32.023 --> 01:07:35.450 and you need to generate new pubkeys. 01:07:35.450 --> 01:07:39.120 But would this prevent you, in the account-based model, 01:07:39.120 --> 01:07:42.740 prevent from getting an account? 01:07:42.740 --> 01:07:44.137 NEHA NARULA: Yeah. 01:07:44.137 --> 01:07:45.970 So I'm not sure in the account-based model-- 01:07:45.970 --> 01:07:49.210 we'll find out more about this when we get to the Ethereum 01:07:49.210 --> 01:07:50.650 section of the class-- 01:07:50.650 --> 01:07:53.930 how you combine spending from different accounts. 01:07:53.930 --> 01:07:57.010 But Bitcoin makes it very easy to combine spending 01:07:57.010 --> 01:07:58.340 from different pubkeys. 01:07:58.340 --> 01:07:59.380 In the account-based model, I could 01:07:59.380 --> 01:08:01.600 imagine it being a slightly more complicated process. 01:08:01.600 --> 01:08:02.660 But that's a good point. 01:08:02.660 --> 01:08:04.660 Yes, you could definitely create a lot of accounts 01:08:04.660 --> 01:08:05.827 with a lot of small balance. 01:08:05.827 --> 01:08:07.450 But if you want to spend a lot, you're 01:08:07.450 --> 01:08:09.400 going to have to somehow accumulate 01:08:09.400 --> 01:08:11.243 all of that spending. 01:08:11.243 --> 01:08:12.660 Remember, I talked about how there 01:08:12.660 --> 01:08:17.370 is one special transaction in every block, called 01:08:17.370 --> 01:08:18.450 the coinbase transaction. 01:08:18.450 --> 01:08:19.867 And this transaction does not have 01:08:19.867 --> 01:08:22.649 to follow all of the rules specified before. 01:08:22.649 --> 01:08:25.170 So this is kind of like a hard-coded exception 01:08:25.170 --> 01:08:26.670 into how Bitcoin works, that there 01:08:26.670 --> 01:08:29.069 can be this one transaction in every block, 01:08:29.069 --> 01:08:30.540 called the coinbase transaction. 01:08:30.540 --> 01:08:32.260 It is the first transaction. 01:08:32.260 --> 01:08:36.090 The coinbase transaction has exactly one input. 01:08:36.090 --> 01:08:40.170 And that input needs to have certain feel. 01:08:40.170 --> 01:08:44.220 This input does not point to a previous output. 01:08:44.220 --> 01:08:47.890 This input is essentially empty. 01:08:47.890 --> 01:08:51.670 This is the transaction that doles out the block reward. 01:08:51.670 --> 01:08:54.430 So this is the transaction that-- 01:08:54.430 --> 01:08:57.319 the block reward used to be 50 bitcoins-- 01:08:57.319 --> 01:09:01.359 25 bitcoins, 50 bitcoins, now it's 12.5 bitcoins per block. 01:09:01.359 --> 01:09:05.229 This is the transaction that doles out that 12.5 bitcoins 01:09:05.229 --> 01:09:09.189 plus the fees of the block. 01:09:09.189 --> 01:09:11.500 So it has exactly one input. 01:09:11.500 --> 01:09:16.720 And that input has all zeros for the previous transaction ID. 01:09:16.720 --> 01:09:20.574 And then FFFFF for the index into that previous transaction 01:09:20.574 --> 01:09:22.090 ID. 01:09:22.090 --> 01:09:25.270 I think the scriptSig can basically be whatever you want. 01:09:25.270 --> 01:09:27.850 It's not evaluated. 01:09:27.850 --> 01:09:28.960 It might have to be valid. 01:09:28.960 --> 01:09:30.260 I'm not sure. 01:09:30.260 --> 01:09:34.420 And then its output is in Satoshis. 01:09:34.420 --> 01:09:37.330 So this is 12.5 Bitcoin. 01:09:37.330 --> 01:09:41.170 Because remember, a Bitcoin is 10 to the eighth Satoshis. 01:09:41.170 --> 01:09:43.720 So this is 12.5 bitcoin, plus here 01:09:43.720 --> 01:09:45.910 are the fees from that block. 01:09:45.910 --> 01:09:49.080 And you probably, if you're the one-- 01:09:49.080 --> 01:09:51.760 so the miner is the one who creates this transaction. 01:09:51.760 --> 01:09:56.530 And the miner who creates this transaction probably 01:09:56.530 --> 01:10:00.770 wants to give themselves the Bitcoin and the block reward, 01:10:00.770 --> 01:10:03.630 and so would specify, in here, a scriptPubKey 01:10:03.630 --> 01:10:04.750 that they could redeem. 01:10:07.660 --> 01:10:10.067 Note that this also has the nice property of making-- 01:10:10.067 --> 01:10:11.650 well, I don't if it's a nice property, 01:10:11.650 --> 01:10:14.350 but all the blocks that people work on are actually different. 01:10:14.350 --> 01:10:16.682 Because in each block, the coinbase transaction 01:10:16.682 --> 01:10:18.640 is going to be different because each person is 01:10:18.640 --> 01:10:21.280 trying to pay themselves for-- the different miners. 01:10:21.280 --> 01:10:21.845 Yes. 01:10:21.845 --> 01:10:24.777 AUDIENCE: What's [INAUDIBLE] them to 12.5 bitcoins? 01:10:24.777 --> 01:10:26.110 NEHA NARULA: Ah, great question. 01:10:26.110 --> 01:10:28.780 So what would happen if a miner put, 01:10:28.780 --> 01:10:30.480 like, 100 bitcoins in there? 01:10:30.480 --> 01:10:31.115 Any idea? 01:10:37.560 --> 01:10:41.010 So what's keeping that at 12.5 bitcoins 01:10:41.010 --> 01:10:44.220 is the same thing that's keeping invalid transactions out 01:10:44.220 --> 01:10:48.720 of the blockchain, which is the consensus rules of Bitcoin. 01:10:48.720 --> 01:10:52.980 It says in the code that, at this point in time, given 01:10:52.980 --> 01:10:56.280 the block height where we are, that number 01:10:56.280 --> 01:11:00.000 should be no larger than 12.5 plus the fees 01:11:00.000 --> 01:11:02.510 in the transaction. 01:11:02.510 --> 01:11:06.400 And if a miner put a different number in there-- 01:11:06.400 --> 01:11:09.220 they can put a lower number, that's fine. 01:11:09.220 --> 01:11:11.810 They'll end up burning some Bitcoin, which is unfortunate. 01:11:11.810 --> 01:11:15.730 But if they try to put something higher in there, 01:11:15.730 --> 01:11:18.340 the network will regard it as invalid, 01:11:18.340 --> 01:11:20.920 because the network is running a set of rules. 01:11:20.920 --> 01:11:23.440 And we are, in this class, going to get 01:11:23.440 --> 01:11:26.740 to what happens when you want to change that set of rules, which 01:11:26.740 --> 01:11:28.090 gets really tricky. 01:11:28.090 --> 01:11:31.720 But right now, assume that the network 01:11:31.720 --> 01:11:34.120 is running the set of rules, they're all checking, 01:11:34.120 --> 01:11:35.085 they're all validating. 01:11:35.085 --> 01:11:36.460 And so the answer is, the network 01:11:36.460 --> 01:11:41.930 would reject this block if there was a higher number in there. 01:11:41.930 --> 01:11:44.470 So this is kind of fun, because you can sort of 01:11:44.470 --> 01:11:45.790 put whatever you want in here. 01:11:45.790 --> 01:11:49.750 And so miners like to put advertisements in there. 01:11:49.750 --> 01:11:51.965 And there actually was a period, there was a time-- 01:11:51.965 --> 01:11:53.590 I don't know if you can still do this-- 01:11:53.590 --> 01:11:56.758 where you could literally buy this space from miners, 01:11:56.758 --> 01:11:58.300 and put whatever you wanted in there. 01:11:58.300 --> 01:12:02.230 So you could put your name, or ask someone to marry you, 01:12:02.230 --> 01:12:04.360 or whatever you might want to do, 01:12:04.360 --> 01:12:07.210 to put in the Bitcoin blockchain for all eternity. 01:12:07.210 --> 01:12:13.510 But yeah, so miners like to put fun things in the scriptSig. 01:12:13.510 --> 01:12:16.570 And maybe we could show them some of those things later. 01:12:16.570 --> 01:12:18.930 Or you could go look yourself.