WEBVTT 00:00:01.140 --> 00:00:03.480 The following content is provided under a Creative 00:00:03.480 --> 00:00:04.870 Commons license. 00:00:04.870 --> 00:00:07.080 Your support will help MIT OpenCourseWare 00:00:07.080 --> 00:00:11.170 continue to offer high-quality, educational resources for free. 00:00:11.170 --> 00:00:13.740 To make a donation or to view additional materials 00:00:13.740 --> 00:00:17.700 from hundreds of MIT courses, visit MIT OpenCourseWare 00:00:17.700 --> 00:00:18.580 at ocw.mit.edu. 00:00:22.840 --> 00:00:24.820 NEHA NARULA: Welcome back. 00:00:24.820 --> 00:00:29.860 Today, we are going to talk about forks. 00:00:29.860 --> 00:00:34.330 So I think you guys have had a guest lecture last week 00:00:34.330 --> 00:00:37.780 from Alin Tomescu, who talked about his project, Catena. 00:00:37.780 --> 00:00:41.590 And one of the really interesting things about Catena 00:00:41.590 --> 00:00:44.470 is that he's trying to prevent a server from equivocating. 00:00:44.470 --> 00:00:46.840 So he's trying to keep a server from being 00:00:46.840 --> 00:00:49.420 able to say one answer to some people and another answer 00:00:49.420 --> 00:00:51.040 to another person. 00:00:51.040 --> 00:00:54.760 That's kind of the goal of this whole blockchain thing. 00:00:54.760 --> 00:00:57.970 But there's actually something really complex 00:00:57.970 --> 00:01:01.997 that happens when we start to change what's 00:01:01.997 --> 00:01:03.580 happening in the network, and we start 00:01:03.580 --> 00:01:05.980 to change the software that's happening in the network. 00:01:05.980 --> 00:01:10.240 And so this lecture is going to be about forks. 00:01:10.240 --> 00:01:13.450 And I want you guys to feel free to raise your hands 00:01:13.450 --> 00:01:17.170 and ask questions during class, because this stuff is actually 00:01:17.170 --> 00:01:19.330 kind of non-intuitive sometimes. 00:01:19.330 --> 00:01:24.370 So a blockchain is a chain of blocks which have previous hash 00:01:24.370 --> 00:01:25.930 pointers inside of them. 00:01:25.930 --> 00:01:30.610 So a question-- can a block point to two previous blocks 00:01:30.610 --> 00:01:33.282 at the same time? 00:01:33.282 --> 00:01:34.990 Anybody know the answer to this question? 00:01:34.990 --> 00:01:36.820 No, exactly, that is the whole point. 00:01:36.820 --> 00:01:40.300 There is exactly one spot in the block header 00:01:40.300 --> 00:01:42.580 for a previous hash block. 00:01:42.580 --> 00:01:46.450 And so a block can only point to one previous block. 00:01:46.450 --> 00:01:50.360 A single block cannot point to two previous blocks. 00:01:50.360 --> 00:01:52.030 However, can this happen? 00:01:52.030 --> 00:01:55.360 Can two different blocks point to the same previous block 00:01:55.360 --> 00:01:56.270 header? 00:01:56.270 --> 00:01:59.979 Yes, yes, and this happens all the time. 00:01:59.979 --> 00:02:03.310 Now, part of the reason that this happens all the time 00:02:03.310 --> 00:02:05.830 is because the way that blocks are 00:02:05.830 --> 00:02:09.759 found in the bitcoin network is completely probabilistic. 00:02:09.759 --> 00:02:11.470 There are many people who are trying 00:02:11.470 --> 00:02:13.930 to find the next block at the same time. 00:02:13.930 --> 00:02:16.930 And it's entirely possible that two different miners 00:02:16.930 --> 00:02:20.140 will get lucky in a time period that 00:02:20.140 --> 00:02:22.720 is within the time it takes for a block to get gossipped 00:02:22.720 --> 00:02:23.770 around the network. 00:02:23.770 --> 00:02:26.380 And so, totally, two people can find the same block 00:02:26.380 --> 00:02:27.370 at the same time. 00:02:27.370 --> 00:02:30.820 This is actually what's known as a fork. 00:02:30.820 --> 00:02:31.990 And you can kind of see why. 00:02:31.990 --> 00:02:35.460 We have a fork in the chain right here. 00:02:35.460 --> 00:02:37.990 But what does it really mean when 00:02:37.990 --> 00:02:39.370 there's a fork in the chain? 00:02:39.370 --> 00:02:41.620 I just told you that this is something 00:02:41.620 --> 00:02:43.300 that happens all the time. 00:02:43.300 --> 00:02:46.480 And these cryptocurrency networks seem to keep running. 00:02:46.480 --> 00:02:48.130 They seem to be keep going. 00:02:48.130 --> 00:02:51.820 So perhaps it's not as bad as it seems, 00:02:51.820 --> 00:02:53.320 even though it seems to be violating 00:02:53.320 --> 00:02:57.250 one of the major tenets of what a blockchain is. 00:02:57.250 --> 00:02:59.050 Well, it is kind of bad, actually, 00:02:59.050 --> 00:03:02.650 because when you have these two blocks here, 00:03:02.650 --> 00:03:06.040 is there anything that makes one the right blockchain 00:03:06.040 --> 00:03:07.240 over the other blockchain? 00:03:07.240 --> 00:03:10.030 Just if this is one blockchain right here, 00:03:10.030 --> 00:03:12.910 and this is another blockchain right there, 00:03:12.910 --> 00:03:14.930 how is one supposed to distinguish between this? 00:03:14.930 --> 00:03:15.430 Yeah? 00:03:15.430 --> 00:03:16.690 AUDIENCE: The one with the most work. 00:03:16.690 --> 00:03:18.357 NEHA NARULA: The one with the most work, 00:03:18.357 --> 00:03:22.215 OK, that's a great sort of way of thinking about it. 00:03:22.215 --> 00:03:24.340 What if they have similar amounts of proof of work. 00:03:24.340 --> 00:03:24.690 Then what? 00:03:24.690 --> 00:03:26.200 AUDIENCE: The one that's accepted 00:03:26.200 --> 00:03:26.990 by the majority of the network. 00:03:26.990 --> 00:03:28.300 NEHA NARULA: The one that's accepted 00:03:28.300 --> 00:03:29.050 by the majority of the network. 00:03:29.050 --> 00:03:30.640 How do we know which one is accepted 00:03:30.640 --> 00:03:33.380 by the majority of the network? 00:03:33.380 --> 00:03:35.710 It gets extended, OK, great. 00:03:35.710 --> 00:03:39.910 So that's a really good way of looking at it. 00:03:39.910 --> 00:03:43.090 Before we go into what that means, 00:03:43.090 --> 00:03:46.390 do people understand why if this state were to persist 00:03:46.390 --> 00:03:49.130 it would be a really bad situation? 00:03:49.130 --> 00:03:50.792 One thing that we could have, given 00:03:50.792 --> 00:03:52.750 that there's two blocks, what that really means 00:03:52.750 --> 00:03:54.970 is that we have two versions of history. 00:03:54.970 --> 00:03:56.530 We have two versions of the ledger 00:03:56.530 --> 00:03:58.270 if these two things are not the same. 00:03:58.270 --> 00:04:01.810 Different coins might be spent on one side of the fork, 00:04:01.810 --> 00:04:04.270 versus on the other side of the fork. 00:04:04.270 --> 00:04:08.260 In fact, the same coin might be spent in two different people 00:04:08.260 --> 00:04:10.600 on either sides of these forks. 00:04:10.600 --> 00:04:13.810 And so over here, Alice might be spending her coin to Bob. 00:04:13.810 --> 00:04:16.269 Over here, Alex might be spending that same coin-- 00:04:16.269 --> 00:04:19.143 and, remember, coins can only be spent once. 00:04:19.143 --> 00:04:20.560 Even if Alice has other coins, she 00:04:20.560 --> 00:04:22.610 specifies which coin she's spending. 00:04:22.610 --> 00:04:25.410 Alice might spend that coin over to Carol. 00:04:25.410 --> 00:04:27.790 And so if Bob sees this, he thinks he got paid. 00:04:27.790 --> 00:04:30.520 If Carol sees this, she thinks she got paid. 00:04:30.520 --> 00:04:33.790 And we violated one of the fundamental tenets 00:04:33.790 --> 00:04:36.317 of the blockchain, which is not to double spend coins. 00:04:36.317 --> 00:04:37.900 You can't create money out of nowhere. 00:04:40.770 --> 00:04:43.980 If these two things would persist, 00:04:43.980 --> 00:04:47.130 if we don't resolve this fork somehow, 00:04:47.130 --> 00:04:50.190 then we literally have two different versions 00:04:50.190 --> 00:04:53.890 of the same currency. 00:04:53.890 --> 00:04:56.350 This is kind of as though I took the money 00:04:56.350 --> 00:05:00.820 in my pocket, my dollar bill, and I xeroxed them all, 00:05:00.820 --> 00:05:04.150 and managed to convince some people that the Xerox was also 00:05:04.150 --> 00:05:05.740 real. 00:05:05.740 --> 00:05:07.570 This is the exact same thing as what's 00:05:07.570 --> 00:05:12.740 happening when you have these two things persist. 00:05:12.740 --> 00:05:15.060 OK, so how do we fix it? 00:05:15.060 --> 00:05:19.800 Well, which is the right one? 00:05:19.800 --> 00:05:22.170 And just given what I've shown you right here, 00:05:22.170 --> 00:05:24.300 it is not clear which is the right one. 00:05:24.300 --> 00:05:26.957 And like I also said, this happens all the time 00:05:26.957 --> 00:05:29.040 in the bitcoin network because the bitcoin network 00:05:29.040 --> 00:05:30.740 is probabilistic. 00:05:30.740 --> 00:05:34.680 So the way that people figure out which one is the right one 00:05:34.680 --> 00:05:36.250 is they wait. 00:05:36.250 --> 00:05:39.760 They wait and see which side gets extended. 00:05:39.760 --> 00:05:42.180 And by the nature of probability, 00:05:42.180 --> 00:05:45.360 one side is going to eventually win out, and get extended 00:05:45.360 --> 00:05:46.890 more often than the other side. 00:05:46.890 --> 00:05:51.090 It's very unlikely for two forks to randomly sort 00:05:51.090 --> 00:05:54.120 of probabilistically exist at roughly the same way 00:05:54.120 --> 00:05:57.220 for the same amount of time for very long. 00:05:57.220 --> 00:05:59.970 Now, as someone said, you might look at this. 00:05:59.970 --> 00:06:02.940 How do you distinguish between these two things? 00:06:02.940 --> 00:06:05.820 There is this common idea that in blockchains we 00:06:05.820 --> 00:06:07.710 take the longest chain. 00:06:07.710 --> 00:06:10.530 Longest is a little bit misleading actually. 00:06:10.530 --> 00:06:12.300 It's not the longest chain. 00:06:12.300 --> 00:06:15.030 It's the heaviest work chain. 00:06:15.030 --> 00:06:18.870 So we pick the chain that has the most proof of work 00:06:18.870 --> 00:06:21.450 on it, even if that happens to have 00:06:21.450 --> 00:06:22.830 a smaller number of blocks. 00:06:22.830 --> 00:06:24.010 Usually that's not the case. 00:06:24.010 --> 00:06:25.475 That's not what happens. 00:06:25.475 --> 00:06:26.850 The reason for that-- does anyone 00:06:26.850 --> 00:06:29.250 know why we take the heaviest chain instead of the longest 00:06:29.250 --> 00:06:29.750 chain? 00:06:32.960 --> 00:06:35.370 AUDIENCE: So that nobody can cheat and lower 00:06:35.370 --> 00:06:37.602 the level of difficulty. 00:06:37.602 --> 00:06:39.810 NEHA NARULA: Right, so it's not very easy to do this. 00:06:39.810 --> 00:06:41.550 But over time, someone could slowly 00:06:41.550 --> 00:06:43.800 decrease difficulty level, and then 00:06:43.800 --> 00:06:47.430 create a nice, really long chain with many low difficulty 00:06:47.430 --> 00:06:50.820 blocks, and then say, hey, I've got the longest chain. 00:06:50.820 --> 00:06:52.290 I have the most number of blocks. 00:06:52.290 --> 00:06:54.990 Despite the fact that your chain has more proof of work on it, 00:06:54.990 --> 00:06:56.250 you should all take my chain. 00:06:56.250 --> 00:06:59.400 And they could do that with less than a majority 00:06:59.400 --> 00:07:01.142 of the hash power. 00:07:01.142 --> 00:07:02.600 Now, this is not easy attack to do. 00:07:02.600 --> 00:07:03.767 But it is a possible attack. 00:07:03.767 --> 00:07:06.380 And so that's why we take the heaviest chain, which 00:07:06.380 --> 00:07:11.210 represents the most hash power in the system, the majority 00:07:11.210 --> 00:07:12.500 of the system. 00:07:12.500 --> 00:07:16.580 So forks happen all the time. 00:07:16.580 --> 00:07:19.440 Forks are normal. 00:07:19.440 --> 00:07:23.240 The way that people who see forks decide 00:07:23.240 --> 00:07:25.940 which side of the fork to use, is they 00:07:25.940 --> 00:07:29.060 check and see which one has the most proof of work, 00:07:29.060 --> 00:07:30.740 the heaviest proof of work. 00:07:30.740 --> 00:07:32.780 Now, one thing that's kind of cool, 00:07:32.780 --> 00:07:36.440 is, as you probably learned about two classes ago, 00:07:36.440 --> 00:07:40.130 even SPV nodes, even clients, can 00:07:40.130 --> 00:07:42.770 tell which chain has the most proof of work 00:07:42.770 --> 00:07:46.159 simply by looking at the headers, the block headers. 00:07:46.159 --> 00:07:47.690 They can see what the difficulty is. 00:07:47.690 --> 00:07:48.890 And they can measure for themselves 00:07:48.890 --> 00:07:51.015 which side of the chain has the most proof of work. 00:07:51.015 --> 00:07:52.980 They don't even need all of the chain. 00:07:52.980 --> 00:07:55.159 So this is a nice property of light clients, 00:07:55.159 --> 00:07:57.740 is that they can download all of the block headers 00:07:57.740 --> 00:08:00.230 and immediately tell which side of a fork 00:08:00.230 --> 00:08:03.440 has the most proof of work. 00:08:03.440 --> 00:08:08.068 Great, we call the block that ends up-- so what 00:08:08.068 --> 00:08:09.110 do we do with this block? 00:08:09.110 --> 00:08:13.330 Does anyone know what actually happens with this block? 00:08:13.330 --> 00:08:15.940 Anybody? 00:08:15.940 --> 00:08:19.790 OK, so this book is basically abandoned. 00:08:19.790 --> 00:08:21.980 This block is just left. 00:08:21.980 --> 00:08:23.150 It exists. 00:08:23.150 --> 00:08:24.740 It points into the chain. 00:08:24.740 --> 00:08:25.780 That's great. 00:08:25.780 --> 00:08:27.870 In bitcoin, in particular, it's meaningless. 00:08:27.870 --> 00:08:29.450 It doesn't mean anything. 00:08:29.450 --> 00:08:32.870 Every transaction that was in that block 00:08:32.870 --> 00:08:35.159 is not considered to have happened. 00:08:35.159 --> 00:08:37.789 So those transactions need to be replayed 00:08:37.789 --> 00:08:41.270 on the chain that ends up being the longest chain. 00:08:41.270 --> 00:08:44.940 And this happens, like I said, all the time. 00:08:44.940 --> 00:08:48.500 We call that block an orphan, because it doesn't have anyone. 00:08:48.500 --> 00:08:50.060 It's kind of the wrong way around. 00:08:50.060 --> 00:08:51.620 I mean, I think of this as a child. 00:08:51.620 --> 00:08:53.980 But, whatever, this block doesn't have a parent. 00:08:53.980 --> 00:08:56.030 But we call those blocks orphans. 00:08:56.030 --> 00:08:58.730 And, again, remember, we pick the side 00:08:58.730 --> 00:09:03.070 of the chain that ends up having the most proof of work. 00:09:03.070 --> 00:09:07.403 Now, we draw these figures in two different ways. 00:09:07.403 --> 00:09:09.070 Sometimes we draw the figures like this, 00:09:09.070 --> 00:09:11.800 like there's this blockchain that exists out there, 00:09:11.800 --> 00:09:15.790 that is written down, and that everyone is sort of looking at. 00:09:15.790 --> 00:09:17.200 There's one blockchain. 00:09:17.200 --> 00:09:20.170 But this isn't a logical representation. 00:09:20.170 --> 00:09:23.530 In reality, there are many, many, many, many different 00:09:23.530 --> 00:09:24.160 blockchains. 00:09:24.160 --> 00:09:26.380 In fact, every node in the system 00:09:26.380 --> 00:09:28.750 has its own version of the blockchain. 00:09:28.750 --> 00:09:31.540 And it's what those nodes are doing together 00:09:31.540 --> 00:09:34.610 that ends up deciding what the blockchain actually is. 00:09:34.610 --> 00:09:39.130 So if these are nodes that are running the bitcoin protocol, 00:09:39.130 --> 00:09:42.590 and when I say nodes, what's the difference 00:09:42.590 --> 00:09:43.880 between a miner and a node? 00:09:49.640 --> 00:09:51.410 AUDIENCE: Nodes verify transactions, 00:09:51.410 --> 00:09:55.320 but miners push blocks. 00:09:55.320 --> 00:09:57.540 NEHA NARULA: Exactly, so miners actually 00:09:57.540 --> 00:09:59.640 create blocks in the system. 00:09:59.640 --> 00:10:02.880 Miners have write access to the blockchain. 00:10:02.880 --> 00:10:06.420 They actually produce new blocks. 00:10:06.420 --> 00:10:08.940 People think a lot about what the miners are, 00:10:08.940 --> 00:10:10.150 and what the miners can do. 00:10:10.150 --> 00:10:12.120 And there's a lot of game theory thinking about the miners. 00:10:12.120 --> 00:10:15.000 And, oh, what if they collude, but the hash power does this? 00:10:15.000 --> 00:10:17.527 And sometimes we forget that nodes in the bitcoin network 00:10:17.527 --> 00:10:19.110 are actually incredibly important too, 00:10:19.110 --> 00:10:21.082 because it's the nodes in the bitcoin network 00:10:21.082 --> 00:10:22.290 that are now creating blocks. 00:10:22.290 --> 00:10:24.040 And, to be clear, someone could be a miner 00:10:24.040 --> 00:10:25.890 and a node at the same time. 00:10:25.890 --> 00:10:27.360 They're distinct roles. 00:10:27.360 --> 00:10:31.353 The same entity could certainly run a node and be a miner. 00:10:31.353 --> 00:10:33.270 But nodes are doing something really important 00:10:33.270 --> 00:10:35.850 as well, which is they're reading all of the blocks. 00:10:35.850 --> 00:10:39.570 And they're deciding which side of a fork to take, 00:10:39.570 --> 00:10:43.320 and which blocks to accept and which blocks not to accept. 00:10:43.320 --> 00:10:46.770 So let's say that these are all bitcoin nodes. 00:10:46.770 --> 00:10:49.860 And this is what the blockchain looks like right now. 00:10:49.860 --> 00:10:53.670 And we've used this figure multiple times. 00:10:53.670 --> 00:10:58.230 Every block has a previous hash, which acts as a pointer 00:10:58.230 --> 00:11:01.050 to the previous block. 00:11:01.050 --> 00:11:03.390 Every block has a set of transactions. 00:11:03.390 --> 00:11:06.180 And every block has a nonce, such 00:11:06.180 --> 00:11:09.660 that when you take the hash of the block header, 00:11:09.660 --> 00:11:12.450 you end up with something that has a sufficient number 00:11:12.450 --> 00:11:13.290 of leading zeros. 00:11:13.290 --> 00:11:14.700 It has valid proof of work. 00:11:17.710 --> 00:11:21.270 So let's say that this is the state of the system right now. 00:11:21.270 --> 00:11:25.890 And then, we see this new block come along. 00:11:25.890 --> 00:11:29.700 So what happens here is that a miner has produced this block, 00:11:29.700 --> 00:11:32.890 and has sent it out over the bitcoin network. 00:11:32.890 --> 00:11:35.160 They've started gossiping the block around the bitcoin 00:11:35.160 --> 00:11:35.820 network. 00:11:35.820 --> 00:11:38.910 And so every one of these nodes, hopefully, will eventually, 00:11:38.910 --> 00:11:41.180 if they're well connected, will see this block. 00:11:41.180 --> 00:11:43.890 They're going to see the block at different times. 00:11:43.890 --> 00:11:48.000 And they're each going to make an independent decision 00:11:48.000 --> 00:11:50.130 about the block. 00:11:50.130 --> 00:11:53.190 So every node is going to decide when it sees 00:11:53.190 --> 00:11:56.460 this block what to do with it. 00:11:56.460 --> 00:11:59.110 And there's basically two things it can do with it. 00:11:59.110 --> 00:12:03.360 One, it can add it to its own local version 00:12:03.360 --> 00:12:05.250 of the blockchain. 00:12:05.250 --> 00:12:09.750 And number two, it can reject it. 00:12:09.750 --> 00:12:13.110 Does everyone see why that is? 00:12:13.110 --> 00:12:16.890 So sure, every node is maintaining this local copy 00:12:16.890 --> 00:12:17.610 of a blockchain. 00:12:17.610 --> 00:12:21.000 There is no single, global copy that everyone 00:12:21.000 --> 00:12:22.290 is referring to physically. 00:12:22.290 --> 00:12:24.420 There's no single database running the blockchain. 00:12:24.420 --> 00:12:27.030 Every node has its own local copy of the blockchain. 00:12:27.030 --> 00:12:31.200 Every node is making its own local decisions about 00:12:31.200 --> 00:12:34.020 whether or not a block is valid, and about whether or not 00:12:34.020 --> 00:12:37.380 it's going to add that block to its own local copy 00:12:37.380 --> 00:12:38.590 of its blockchain. 00:12:41.350 --> 00:12:44.170 So the way that the node decides this 00:12:44.170 --> 00:12:48.670 is that it has a set of validation rules. 00:12:48.670 --> 00:12:52.300 So it has its own set of rules, which are specified 00:12:52.300 --> 00:12:55.300 by the bitcoin protocol. 00:12:55.300 --> 00:13:00.670 And it checks that block against its set of validation rules. 00:13:00.670 --> 00:13:02.620 So every node, every bitcoin node, 00:13:02.620 --> 00:13:05.860 is constantly validating, constantly validating blocks. 00:13:05.860 --> 00:13:08.400 Here are just some of the validation rules. 00:13:08.400 --> 00:13:11.170 And we've talked about a lot of these sort of off and on 00:13:11.170 --> 00:13:12.500 during the class. 00:13:12.500 --> 00:13:15.610 So first of all, there's a max block size. 00:13:15.610 --> 00:13:18.610 And the way that this works is if at any point 00:13:18.610 --> 00:13:23.140 you fail one of these validation rules, you reject the block. 00:13:23.140 --> 00:13:26.740 So first, the block has to be smaller than this variable max 00:13:26.740 --> 00:13:27.880 block size. 00:13:27.880 --> 00:13:32.080 At the moment, max block size is set to 1 megabyte. 00:13:32.080 --> 00:13:36.250 Every single transaction in the block also has to be valid. 00:13:36.250 --> 00:13:37.855 And what does that mean? 00:13:37.855 --> 00:13:39.730 Well, it needs to be formatted a certain way. 00:13:39.730 --> 00:13:43.870 And it also means that when we concatenate the script pub 00:13:43.870 --> 00:13:46.630 key and the script sig together, and then run that 00:13:46.630 --> 00:13:50.170 through the interpreter to evaluate 00:13:50.170 --> 00:13:55.780 the script on the stack, it ends up returning true. 00:13:55.780 --> 00:13:58.630 And if at any point, any transaction-- and not just 00:13:58.630 --> 00:14:00.670 any transaction, any input in any transaction, 00:14:00.670 --> 00:14:03.400 does not satisfy this, we reject the entire block. 00:14:06.460 --> 00:14:08.410 Another thing that each transaction 00:14:08.410 --> 00:14:13.390 needs to satisfy if it's valid, is if the transaction specifies 00:14:13.390 --> 00:14:15.300 an end lock time, than that end lock 00:14:15.300 --> 00:14:17.920 time needs to be greater than whatever is specified 00:14:17.920 --> 00:14:19.000 in the transaction. 00:14:19.000 --> 00:14:22.900 That transaction is now is now far enough in the future 00:14:22.900 --> 00:14:25.750 that it can be satisfied. 00:14:25.750 --> 00:14:29.200 The block as a whole needs to have valid proof of work. 00:14:29.200 --> 00:14:30.580 So it needs to have a nonce, such 00:14:30.580 --> 00:14:32.890 that when you hash the block header, 00:14:32.890 --> 00:14:35.830 you end up with a hash that has a certain number of leading 00:14:35.830 --> 00:14:36.940 zeros. 00:14:36.940 --> 00:14:40.930 And what's really interesting is the protocol also 00:14:40.930 --> 00:14:45.190 specifies exactly how many leading zeros there need to be, 00:14:45.190 --> 00:14:48.020 depending upon how many leading zeros there have 00:14:48.020 --> 00:14:49.145 been in blocks in the past. 00:14:51.940 --> 00:14:53.560 There cannot be any double spends. 00:14:53.560 --> 00:14:56.770 So given the version of the blockchain that I, as a node, 00:14:56.770 --> 00:15:02.070 have, this better not be double spending any outputs. 00:15:02.070 --> 00:15:04.060 There are some rules around what the block 00:15:04.060 --> 00:15:06.070 can have as its timestamp. 00:15:06.070 --> 00:15:07.870 It cannot be more than-- 00:15:07.870 --> 00:15:10.210 if I see a block that has a timestamp that's 00:15:10.210 --> 00:15:12.820 more than two hours in the future from my own timestamp, 00:15:12.820 --> 00:15:14.330 I will reject it. 00:15:14.330 --> 00:15:18.730 And if it isn't after some point that's 00:15:18.730 --> 00:15:20.950 the median of the previous block's timestamps, 00:15:20.950 --> 00:15:24.270 then I'll also reject it. 00:15:24.270 --> 00:15:28.980 And, of course, the block needs to actually point to a block 00:15:28.980 --> 00:15:30.510 that I've seen before. 00:15:30.510 --> 00:15:32.280 And as a node, I will keep around 00:15:32.280 --> 00:15:35.610 blocks which have a previous hash pointer that I 00:15:35.610 --> 00:15:37.180 don't know about. 00:15:37.180 --> 00:15:39.690 But I'm not going to keep them around forever, 00:15:39.690 --> 00:15:41.700 because that's a potential Dos attack. 00:15:41.700 --> 00:15:45.690 And in order for me to actually insert this block 00:15:45.690 --> 00:15:47.910 into my version of a blockchain, I 00:15:47.910 --> 00:15:52.140 need to know which block to put it after. 00:15:52.140 --> 00:15:55.260 Note also, note what's not on here 00:15:55.260 --> 00:15:59.070 is that it needs to be the only block pointing 00:15:59.070 --> 00:16:00.180 to a previous block. 00:16:00.180 --> 00:16:03.330 I'll keep around multiple blocks at the same level 00:16:03.330 --> 00:16:06.390 until I have some sense of which one is going to win out, 00:16:06.390 --> 00:16:07.920 because of the probabilistic nature 00:16:07.920 --> 00:16:10.552 of maybe this block I'm seeing is not going to end up 00:16:10.552 --> 00:16:11.760 being part of the blockchain. 00:16:11.760 --> 00:16:13.135 Maybe it's going to be an orphan. 00:16:16.480 --> 00:16:21.810 So these validation rules are what 00:16:21.810 --> 00:16:25.860 are called consensus critical rules in the bitcoin network. 00:16:25.860 --> 00:16:30.000 And what that means is that if you want to tweak these rules, 00:16:30.000 --> 00:16:32.430 if you want to change them, then you 00:16:32.430 --> 00:16:36.450 may end up changing which blocks nodes will accept, 00:16:36.450 --> 00:16:39.640 and which blocks nodes won't accept. 00:16:39.640 --> 00:16:43.120 Now, something that's kind of interesting to note here 00:16:43.120 --> 00:16:46.510 is that the entire script interpreter in bitcoin 00:16:46.510 --> 00:16:48.680 is consensus critical. 00:16:48.680 --> 00:16:49.935 Yes? 00:16:49.935 --> 00:16:52.060 AUDIENCE: If you reduce the amount of transactions, 00:16:52.060 --> 00:16:55.060 does that reduce the size of the blocks as well? 00:16:55.060 --> 00:16:56.230 NEHA NARULA: Yes, it can. 00:16:56.230 --> 00:16:58.840 Yes, so you can definitely have a block-- 00:16:58.840 --> 00:17:00.650 so that's a great question actually. 00:17:00.650 --> 00:17:04.030 So let's say that we had a block that was half a megabyte. 00:17:04.030 --> 00:17:07.400 What would nodes do? 00:17:07.400 --> 00:17:09.500 What do you think? 00:17:09.500 --> 00:17:11.810 AUDIENCE: I think an advantageous miner would 00:17:11.810 --> 00:17:14.307 potentially process it faster. 00:17:14.307 --> 00:17:15.348 NEHA NARULA: That's true. 00:17:17.983 --> 00:17:19.150 What would you as a node do. 00:17:19.150 --> 00:17:21.646 If you're running the bitcoin protocol as it exists today, 00:17:21.646 --> 00:17:23.230 and it has the following set of rules, 00:17:23.230 --> 00:17:25.420 and I hand you a block that's half a megabyte, 00:17:25.420 --> 00:17:27.710 what would you do? 00:17:27.710 --> 00:17:29.950 You would say OK, exactly, because the rule that I 00:17:29.950 --> 00:17:32.410 specified here just says the block has 00:17:32.410 --> 00:17:34.150 to be less than 1 megabyte. 00:17:34.150 --> 00:17:36.730 It didn't say it has to be greater than anything. 00:17:36.730 --> 00:17:39.580 And is half a megabyte less than 1 megabyte? 00:17:39.580 --> 00:17:42.100 Yes, so you're going to pass the checks. 00:17:42.100 --> 00:17:43.750 And you're going to accept the block. 00:17:46.770 --> 00:17:49.890 AUDIENCE: Is that a good thing for miners, so 00:17:49.890 --> 00:17:52.690 maybe remove the transactions from a potential block, 00:17:52.690 --> 00:17:54.830 because they want to process it faster? 00:17:54.830 --> 00:17:57.460 NEHA NARULA: Sure, so the question is, should miners 00:17:57.460 --> 00:17:59.500 remove transactions from a block, 00:17:59.500 --> 00:18:01.840 or perhaps not put transactions in a block, 00:18:01.840 --> 00:18:04.570 because it seems like they could process a small block faster 00:18:04.570 --> 00:18:06.730 than a large block, right? 00:18:06.730 --> 00:18:09.070 So that is very true. 00:18:09.070 --> 00:18:11.650 Miners, if there are fewer transactions, 00:18:11.650 --> 00:18:13.030 they have fewer things to verify. 00:18:13.030 --> 00:18:15.860 So they can check and see if the book is valid faster. 00:18:15.860 --> 00:18:20.140 However, the fewer transactions, the fewer the transaction fees. 00:18:20.140 --> 00:18:22.510 And so the less the miner will earn from the block. 00:18:25.460 --> 00:18:26.370 Yes? 00:18:26.370 --> 00:18:31.250 AUDIENCE: And also, the energy put in, most of it mining, 00:18:31.250 --> 00:18:33.390 is like mining the block, not actually verifying. 00:18:33.390 --> 00:18:34.140 NEHA NARULA: Yeah. 00:18:36.080 --> 00:18:42.410 So verifying transactions is nowhere near as CPU-intensive 00:18:42.410 --> 00:18:45.960 as it is to actually find the nonce 00:18:45.960 --> 00:18:47.210 and produce the proof of work. 00:18:47.210 --> 00:18:51.800 However, miners should verify transactions 00:18:51.800 --> 00:18:54.180 before even starting that process. 00:18:54.180 --> 00:18:57.050 And so if a miner didn't verify transactions, 00:18:57.050 --> 00:19:01.150 they would get a head start on the proof of work process. 00:19:01.150 --> 00:19:02.600 So there's that sort of balance. 00:19:02.600 --> 00:19:06.140 And, in fact, I think we've talked about this in this class 00:19:06.140 --> 00:19:07.940 before, there have been times in history 00:19:07.940 --> 00:19:10.010 where things have happened that have shown that miners actually 00:19:10.010 --> 00:19:11.590 haven't been verifying blocks. 00:19:11.590 --> 00:19:13.350 They'll just mine on whatever. 00:19:13.350 --> 00:19:14.630 It's caused some problems. 00:19:14.630 --> 00:19:16.370 And they ended up losing a lot of money 00:19:16.370 --> 00:19:20.120 because they should have been verifying blocks. 00:19:20.120 --> 00:19:21.230 Great. 00:19:21.230 --> 00:19:23.780 So these rules are what are called consensus critical. 00:19:23.780 --> 00:19:26.240 They are the rules that each node independently 00:19:26.240 --> 00:19:29.000 uses to decide whether or not they're 00:19:29.000 --> 00:19:31.570 going to accept the block. 00:19:31.570 --> 00:19:32.490 Yes? 00:19:32.490 --> 00:19:33.990 AUDIENCE: When you talk about nodes, 00:19:33.990 --> 00:19:36.633 you talk about SPDs, right? 00:19:36.633 --> 00:19:37.300 NEHA NARULA: No. 00:19:37.300 --> 00:19:40.390 I'm not talking about SPDs when I talk about nodes. 00:19:40.390 --> 00:19:42.940 I'm actually talking about full nodes. 00:19:42.940 --> 00:19:47.160 So I'm talking about nodes that are holding 00:19:47.160 --> 00:19:49.440 onto the entire bitcoin blockchain, that 00:19:49.440 --> 00:19:52.958 are looking at every block, every transaction. 00:19:52.958 --> 00:19:54.750 AUDIENCE: So the difference between a miner 00:19:54.750 --> 00:19:58.873 and and a node are [INAUDIBLE]? 00:19:58.873 --> 00:19:59.790 NEHA NARULA: A miner-- 00:19:59.790 --> 00:20:01.230 yeah, they're distinct roles. 00:20:01.230 --> 00:20:05.220 So a miner is running this proof of work algorithm 00:20:05.220 --> 00:20:06.620 to try to find-- 00:20:06.620 --> 00:20:08.670 to produce blocks. 00:20:08.670 --> 00:20:10.680 A full node does not write blocks. 00:20:10.680 --> 00:20:12.060 It doesn't create new blocks. 00:20:12.060 --> 00:20:15.390 It receives blocks, and then validates them, or not, 00:20:15.390 --> 00:20:17.520 and adds them to its local copy of the blockchain. 00:20:17.520 --> 00:20:20.920 A miner might also be running a full node. 00:20:20.920 --> 00:20:21.420 Yes? 00:20:21.420 --> 00:20:23.070 AUDIENCE: Miners should be running full nodes. 00:20:23.070 --> 00:20:24.487 NEHA NARULA: Yeah, they should be. 00:20:24.487 --> 00:20:28.590 But it's not clear that that happens, for the reasons 00:20:28.590 --> 00:20:31.500 we were talking about before. 00:20:31.500 --> 00:20:32.040 I'm sorry? 00:20:32.040 --> 00:20:41.230 AUDIENCE: You can force miners to [INAUDIBLE] 00:20:41.230 --> 00:20:46.480 NEHA NARULA: OK, so let's go back to this image right here. 00:20:46.480 --> 00:20:49.630 These nodes are all running some version of the software. 00:20:49.630 --> 00:20:51.430 They see this transaction. 00:20:51.430 --> 00:20:55.990 And they say, yes, this looks like a valid transaction to me. 00:20:55.990 --> 00:20:57.280 And note that they have to-- 00:20:57.280 --> 00:20:58.060 or, sorry, block. 00:20:58.060 --> 00:20:59.260 They look at this block. 00:20:59.260 --> 00:21:00.968 Yes, this looks like a valid block to me. 00:21:00.968 --> 00:21:02.860 And note that they kind of have to evaluate 00:21:02.860 --> 00:21:06.340 that block with respect to all of the other blocks 00:21:06.340 --> 00:21:07.330 that it's seen. 00:21:07.330 --> 00:21:10.480 No double spends, all of the scripts eggs, the script pub 00:21:10.480 --> 00:21:15.400 keys, work out correctly, it's the right size, et cetera, 00:21:15.400 --> 00:21:16.840 et cetera. 00:21:16.840 --> 00:21:21.760 And then once it's decided that that's all OK, 00:21:21.760 --> 00:21:26.440 each node will independently make the same decision 00:21:26.440 --> 00:21:30.010 to add that block to its blockchain. 00:21:30.010 --> 00:21:32.830 So you can see here that determinism is actually 00:21:32.830 --> 00:21:34.030 really important. 00:21:34.030 --> 00:21:35.410 It can't be the case that there's 00:21:35.410 --> 00:21:37.098 any randomness in this process. 00:21:37.098 --> 00:21:38.890 It can't be the case that sort of randomly, 00:21:38.890 --> 00:21:40.980 depending on the time of day, one node will decide 00:21:40.980 --> 00:21:42.560 this is a valid block, one node will 00:21:42.560 --> 00:21:43.810 decide it's not a valid block. 00:21:43.810 --> 00:21:46.660 That's not the greatest situation to have happen. 00:21:46.660 --> 00:21:49.360 We want this to be as deterministic as possible. 00:21:49.360 --> 00:21:51.430 We want them to all independently arrive 00:21:51.430 --> 00:21:53.800 at the same decision. 00:21:53.800 --> 00:21:55.090 Great. 00:21:55.090 --> 00:21:57.340 So this is how validation works. 00:21:57.340 --> 00:21:58.960 This is what nodes do. 00:21:58.960 --> 00:22:01.840 Major problem, though-- sometimes, 00:22:01.840 --> 00:22:04.780 we need to change the validation rules. 00:22:04.780 --> 00:22:08.170 Sometimes, we need to upgrade the software. 00:22:08.170 --> 00:22:10.450 I mean, software is not a static thing. 00:22:10.450 --> 00:22:12.700 The software that these nodes are running, 00:22:12.700 --> 00:22:14.140 there's going to be bugs. 00:22:14.140 --> 00:22:16.220 There might be security vulnerabilities. 00:22:16.220 --> 00:22:20.120 We might want to add new features. 00:22:20.120 --> 00:22:23.990 And so we're going to want to change the validation rules. 00:22:23.990 --> 00:22:26.000 It's pretty much inevitable. 00:22:26.000 --> 00:22:29.540 And, yet, given the nature of the system, 00:22:29.540 --> 00:22:33.170 we can't upgrade every single node at the same time. 00:22:36.800 --> 00:22:40.850 So I think a useful analogy here, something to think about, 00:22:40.850 --> 00:22:43.240 is actually browsers. 00:22:43.240 --> 00:22:47.350 So web browsers-- right now, a lot of people run Chrome. 00:22:47.350 --> 00:22:48.940 But not everyone runs Chrome. 00:22:48.940 --> 00:22:50.800 And Chrome actually has auto update 00:22:50.800 --> 00:22:53.860 where it will push changes to your browser. 00:22:53.860 --> 00:22:56.080 Google will automatically upgrade you. 00:22:56.080 --> 00:22:57.790 But the way the browsers used to work 00:22:57.790 --> 00:23:00.082 is that you didn't always have auto update. 00:23:00.082 --> 00:23:01.540 Or it would bother you, and ask you 00:23:01.540 --> 00:23:04.560 if you were OK with auto updating before. 00:23:04.560 --> 00:23:06.940 And people would say, I don't deal with this right now. 00:23:06.940 --> 00:23:07.750 I'm in the middle of something. 00:23:07.750 --> 00:23:09.070 I don't want to auto update my browser, 00:23:09.070 --> 00:23:10.570 and have to restart the whole thing. 00:23:10.570 --> 00:23:12.400 And so what would end up happening 00:23:12.400 --> 00:23:15.790 is you'd have significant numbers of people on very 00:23:15.790 --> 00:23:17.800 different versions of browsers. 00:23:17.800 --> 00:23:20.140 And this was kind of a disaster for the internet, 00:23:20.140 --> 00:23:24.340 because people who were developing websites, 00:23:24.340 --> 00:23:25.810 they wouldn't have any confidence 00:23:25.810 --> 00:23:27.185 that the majority of their users, 00:23:27.185 --> 00:23:29.080 or a significant majority of their users, 00:23:29.080 --> 00:23:31.130 had upgraded to the new features. 00:23:31.130 --> 00:23:35.620 So they had to support all these old versions of browsers. 00:23:35.620 --> 00:23:37.910 And it was a nightmare. 00:23:37.910 --> 00:23:43.120 So that's what we're dealing with here in cryptocurrencies, 00:23:43.120 --> 00:23:45.640 except it's even worse. 00:23:45.640 --> 00:23:48.820 So you definitely cannot guarantee that everyone will 00:23:48.820 --> 00:23:50.740 upgrade their software at the same time. 00:23:50.740 --> 00:23:53.290 You can't guarantee that everyone will even 00:23:53.290 --> 00:23:55.510 upgrade ever. 00:23:55.510 --> 00:23:57.460 And so the designers of the software, 00:23:57.460 --> 00:23:59.680 when you want to create a new version of software, 00:23:59.680 --> 00:24:03.732 you have to think really, really carefully about it. 00:24:03.732 --> 00:24:05.690 So let's say that we're in this situation right 00:24:05.690 --> 00:24:09.520 here, where these three nodes are running V1 of the software. 00:24:09.520 --> 00:24:11.660 The developers have worked out V2. 00:24:11.660 --> 00:24:14.180 V2 has some interesting new features, 00:24:14.180 --> 00:24:15.920 which slightly changed the validation 00:24:15.920 --> 00:24:18.230 rules about what a node running V2 will 00:24:18.230 --> 00:24:21.840 consider valid or invalid. 00:24:21.840 --> 00:24:27.070 So now, when we see this new block, and we ask the question, 00:24:27.070 --> 00:24:31.470 is this block valid, these nodes might make different decisions. 00:24:31.470 --> 00:24:35.400 In particular, maybe the old nodes will think it's valid. 00:24:35.400 --> 00:24:37.380 Great, passes all the validation rules. 00:24:37.380 --> 00:24:39.480 I will append this block to my blockchain. 00:24:39.480 --> 00:24:42.430 And the new node will not think it's valid, 00:24:42.430 --> 00:24:44.910 and will say, garbage block, fantastic. 00:24:44.910 --> 00:24:48.420 I will not append this block to my blockchain. 00:24:48.420 --> 00:24:51.240 And what we end up with when this happens 00:24:51.240 --> 00:24:53.730 is we have two different versions of history. 00:24:53.730 --> 00:24:55.975 The nodes running the old version of the software 00:24:55.975 --> 00:24:58.100 think that there are four blocks in the blockchain. 00:24:58.100 --> 00:25:01.280 The nodes that are running the new version of the software 00:25:01.280 --> 00:25:02.970 have decided that that block is invalid. 00:25:02.970 --> 00:25:06.880 And they only have three blocks in the blockchain. 00:25:06.880 --> 00:25:10.110 So what does this mean? 00:25:10.110 --> 00:25:12.530 First of all, is this like the situation we saw before, 00:25:12.530 --> 00:25:15.527 where if we just wait for enough proof of work 00:25:15.527 --> 00:25:16.610 this will sort itself out? 00:25:19.180 --> 00:25:22.020 What do you guys think? 00:25:22.020 --> 00:25:24.100 I'm seeing some people shaking their heads. 00:25:24.100 --> 00:25:27.370 And, yes, this situation is different than the situation 00:25:27.370 --> 00:25:29.320 we saw before, because the situation 00:25:29.320 --> 00:25:32.720 we saw before, all the nodes still had the same validation 00:25:32.720 --> 00:25:33.220 rules. 00:25:36.400 --> 00:25:40.630 They just saw the blocks in different orders, 00:25:40.630 --> 00:25:42.240 or they got later, whatever. 00:25:42.240 --> 00:25:46.540 All of that can be resolved by looking at the proof of work. 00:25:46.540 --> 00:25:50.170 Sometimes when this happens, sometimes 00:25:50.170 --> 00:25:52.390 when nodes are actually running different versions 00:25:52.390 --> 00:25:54.190 of validation software, things can 00:25:54.190 --> 00:25:56.260 be resolved by just looking at proof of work. 00:25:56.260 --> 00:25:58.900 But quite often, actually, they can't. 00:25:58.900 --> 00:26:01.630 And so in this situation, what might happen 00:26:01.630 --> 00:26:03.860 is another block comes along. 00:26:03.860 --> 00:26:07.000 So this is a different block than this one. 00:26:07.000 --> 00:26:08.740 And this set of nodes might decide 00:26:08.740 --> 00:26:11.410 that this is the next block in the blockchain, 00:26:11.410 --> 00:26:16.630 whereas the blue nodes will never, ever, ever validate 00:26:16.630 --> 00:26:18.040 this block. 00:26:18.040 --> 00:26:20.350 They will never decide that this block is valid, 00:26:20.350 --> 00:26:22.600 given the version of the software they are running. 00:26:22.600 --> 00:26:25.240 They will never switch to a blockchain 00:26:25.240 --> 00:26:27.610 that has this block in it, even if it 00:26:27.610 --> 00:26:29.710 has the most proof of work. 00:26:29.710 --> 00:26:31.990 So I think this is a really important point. 00:26:31.990 --> 00:26:33.820 And I think it sort of fundamentally 00:26:33.820 --> 00:26:36.130 gets to why miners don't actually 00:26:36.130 --> 00:26:38.680 have as much power in the system as one 00:26:38.680 --> 00:26:40.060 might think that they do. 00:26:40.060 --> 00:26:43.390 And the reason for that is that the way bitcoin is designed 00:26:43.390 --> 00:26:48.190 is that a node will never accept a chain with a single invalid 00:26:48.190 --> 00:26:49.880 transaction. 00:26:49.880 --> 00:26:52.430 If, according to its set of rules, 00:26:52.430 --> 00:26:55.730 a single transaction is invalid, it will completely 00:26:55.730 --> 00:26:56.720 ignore that chain. 00:26:56.720 --> 00:26:58.720 Doesn't matter if it has the most proof of work. 00:27:00.980 --> 00:27:02.798 Does that make sense to everyone? 00:27:05.870 --> 00:27:06.860 It's kind of intense. 00:27:06.860 --> 00:27:08.540 It's kind of crazy, right? 00:27:08.540 --> 00:27:11.060 Like, even if it has mountains upon mountains 00:27:11.060 --> 00:27:12.740 of proof of work, it will completely 00:27:12.740 --> 00:27:14.480 ignore that chain because there's 00:27:14.480 --> 00:27:16.790 something invalid about it. 00:27:16.790 --> 00:27:20.450 So miners can mine what they want. 00:27:20.450 --> 00:27:24.080 But they better mine within the validation rules 00:27:24.080 --> 00:27:27.260 set of the economic majority of the nodes. 00:27:27.260 --> 00:27:28.760 Otherwise, those nodes are all going 00:27:28.760 --> 00:27:30.207 to ignore whatever they mine. 00:27:30.207 --> 00:27:32.290 And their money is not going to be worth anything. 00:27:36.870 --> 00:27:37.590 Great. 00:27:37.590 --> 00:27:42.270 So in this situation, we end up with two different blockchains. 00:27:42.270 --> 00:27:45.750 And we actually end up with something quite irreconcilable, 00:27:45.750 --> 00:27:48.870 unless we change the software again, somehow. 00:27:48.870 --> 00:27:51.570 And what we've ended up with that's irreconcilable 00:27:51.570 --> 00:27:56.310 is we now have a block over here, and a block over here. 00:27:56.310 --> 00:28:00.400 This node will never accept a chain with this block in it. 00:28:00.400 --> 00:28:02.545 And so we've got two different blockchains. 00:28:06.110 --> 00:28:11.060 So when this happens, we call it a fork. 00:28:11.060 --> 00:28:13.650 Now, the word fork can be used to mean many different things 00:28:13.650 --> 00:28:14.150 in software. 00:28:14.150 --> 00:28:16.903 For example, you fork a project on GitHub. 00:28:16.903 --> 00:28:18.320 When you fork a project on GitHub, 00:28:18.320 --> 00:28:20.840 you might make changes to it. 00:28:20.840 --> 00:28:24.140 This is a little bit different because of the linearity 00:28:24.140 --> 00:28:26.090 of history here. 00:28:26.090 --> 00:28:29.450 When a fork happens in a cryptocurrency, 00:28:29.450 --> 00:28:33.320 in particular a sort of a fork that can't easily be resolved, 00:28:33.320 --> 00:28:34.700 that isn't just going to, oh, one 00:28:34.700 --> 00:28:35.990 side has more proof of work, OK, great 00:28:35.990 --> 00:28:37.820 we're all going to switch to that other side. 00:28:37.820 --> 00:28:39.612 When you have a fork that can't be resolved 00:28:39.612 --> 00:28:43.400 that easily then it's actually a pretty big deal, 00:28:43.400 --> 00:28:45.082 because like we were saying earlier 00:28:45.082 --> 00:28:47.540 we now have two versions of history, two different versions 00:28:47.540 --> 00:28:48.170 of money. 00:28:48.170 --> 00:28:50.750 It's like I took the dollar from my wallet, 00:28:50.750 --> 00:28:51.920 and I photocopied it. 00:28:51.920 --> 00:28:54.950 And now there's $2 where there was only one. 00:28:54.950 --> 00:28:57.750 So maybe you like this kind of dollars. 00:28:57.750 --> 00:28:59.700 Maybe you don't like that kind of dollars. 00:28:59.700 --> 00:29:02.180 We've basically taken this entire network 00:29:02.180 --> 00:29:05.090 that all sort of agreed on what this form of money was, 00:29:05.090 --> 00:29:06.560 and we've divided it into two. 00:29:09.800 --> 00:29:12.740 So there's two different kind of forks 00:29:12.740 --> 00:29:16.130 that people will talk about mostly in this industry. 00:29:16.130 --> 00:29:20.420 But forking is actually much more complicated than that. 00:29:20.420 --> 00:29:22.653 You can't just talk about forks as 00:29:22.653 --> 00:29:24.320 in-- so the two different kinds of forks 00:29:24.320 --> 00:29:26.045 are soft forks and hard forks. 00:29:26.045 --> 00:29:27.920 And I'm going to explain what a soft work is, 00:29:27.920 --> 00:29:29.120 versus a hard fork. 00:29:29.120 --> 00:29:32.120 But, actually, that delineation, it 00:29:32.120 --> 00:29:34.693 gets much more nuanced because different things happen 00:29:34.693 --> 00:29:36.110 in a soft fork versus a hard fork, 00:29:36.110 --> 00:29:40.890 depending upon who's decided to adopt the rules. 00:29:40.890 --> 00:29:43.100 OK, so a soft fork-- 00:29:43.100 --> 00:29:49.250 a soft fork is a fork which is backwards compatible. 00:29:49.250 --> 00:29:52.640 So we have some rule set. 00:29:52.640 --> 00:29:56.900 And under that rule set you apply 00:29:56.900 --> 00:30:03.660 that rule set to every single possible one megabyte 00:30:03.660 --> 00:30:04.972 chunk of data. 00:30:04.972 --> 00:30:06.930 And we're going to end up with some set of what 00:30:06.930 --> 00:30:09.840 are valid blocks. 00:30:09.840 --> 00:30:14.430 A soft fork is when you add rules to the rule set, 00:30:14.430 --> 00:30:17.460 such that the set of valid blocks actually shrinks. 00:30:20.850 --> 00:30:22.950 So what does that mean? 00:30:22.950 --> 00:30:24.960 We had a whole bunch of rules before. 00:30:24.960 --> 00:30:26.880 Blocks have to be less than 1 megabyte. 00:30:26.880 --> 00:30:28.355 Transactions all have to be valid. 00:30:28.355 --> 00:30:30.480 It means that their scripts certify, like validate, 00:30:30.480 --> 00:30:32.160 under the certain script interpreter, 00:30:32.160 --> 00:30:34.103 et cetera, no double spends. 00:30:34.103 --> 00:30:36.520 Let's take one of the rules that's actually pretty simple, 00:30:36.520 --> 00:30:40.050 which is that blocks have to be less than one megabyte. 00:30:40.050 --> 00:30:42.000 Let's say that I change that to blocks 00:30:42.000 --> 00:30:44.340 have to be less than two megabytes. 00:30:44.340 --> 00:30:45.210 Is that a soft fork? 00:30:48.050 --> 00:30:48.633 AUDIENCE: Yes. 00:30:51.330 --> 00:30:53.830 NEHA NARULA: Oh, wow, there's some actual dissent over this, 00:30:53.830 --> 00:30:54.370 right? 00:30:54.370 --> 00:30:59.415 OK, so someone who says no, why is the answer no? 00:30:59.415 --> 00:31:01.790 AUDIENCE: Because you have something that is now accepted 00:31:01.790 --> 00:31:03.470 that wasn't accepted before. 00:31:03.470 --> 00:31:06.590 NEHA NARULA: Right, so remember, valid blocks 00:31:06.590 --> 00:31:09.578 before newly valid blocks fit inside of this. 00:31:09.578 --> 00:31:11.120 Now, someone who said yes it's a soft 00:31:11.120 --> 00:31:14.020 fork, why do you think that? 00:31:14.020 --> 00:31:17.758 AUDIENCE: All blocks still have less than two. 00:31:17.758 --> 00:31:18.550 NEHA NARULA: Right. 00:31:18.550 --> 00:31:21.740 So it's actually not a soft fork. 00:31:21.740 --> 00:31:23.530 And the reason that it's not a soft fork 00:31:23.530 --> 00:31:31.220 is because a block that is 1.75 megabytes, previously, 00:31:31.220 --> 00:31:34.370 the old rule set, was invalid. 00:31:34.370 --> 00:31:37.360 New rule set, it's valid. 00:31:37.360 --> 00:31:40.600 But we just said everything that's newly valid 00:31:40.600 --> 00:31:43.570 has to fit inside what used to be valid. 00:31:43.570 --> 00:31:47.230 So a soft fork is restricting the set of valid things. 00:31:47.230 --> 00:31:50.070 You can think of it as expanding the set of rules 00:31:50.070 --> 00:31:55.755 that a block now has to comply with. 00:31:55.755 --> 00:32:04.110 So a feature of this is that if you don't upgrade-- 00:32:04.110 --> 00:32:07.440 so V1 is the old rule software. 00:32:07.440 --> 00:32:08.970 V2 is the new rule software. 00:32:08.970 --> 00:32:12.060 If you don't upgrade, you will continue 00:32:12.060 --> 00:32:14.970 to see the new blocks as valid. 00:32:14.970 --> 00:32:17.400 And this is actually a very nice property, 00:32:17.400 --> 00:32:19.560 because, remember what happened over here, 00:32:19.560 --> 00:32:21.810 we had this property where the people on the blue side 00:32:21.810 --> 00:32:24.300 were just never, ever going to accept 00:32:24.300 --> 00:32:26.220 one of these blockchains. 00:32:26.220 --> 00:32:33.130 And if it were the case that this were a soft fork, 00:32:33.130 --> 00:32:37.030 the old side would never, ever-- 00:32:37.030 --> 00:32:39.610 well, if this sorry, if it were the case 00:32:39.610 --> 00:32:41.620 that this weren't a soft work, the old nodes 00:32:41.620 --> 00:32:45.280 would never accept this new stuff. 00:32:45.280 --> 00:32:47.440 So soft forks are really nice, because they're 00:32:47.440 --> 00:32:49.000 backwards compatible. 00:32:49.000 --> 00:32:52.150 Old nodes will still see the new blocks as valid. 00:32:52.150 --> 00:32:53.890 They won't reject them. 00:32:53.890 --> 00:32:56.440 If that chain gets a ton of proof of work, 00:32:56.440 --> 00:32:59.440 then the old nodes will happily switch over to that chain. 00:32:59.440 --> 00:33:01.690 So, what does that mean? 00:33:01.690 --> 00:33:05.100 So let's say that the black nodes are the old rules, 00:33:05.100 --> 00:33:09.330 and the blue nodes are new rules, new rule blocks. 00:33:09.330 --> 00:33:11.190 And, again, we have to look at this from two 00:33:11.190 --> 00:33:12.420 different perspectives. 00:33:12.420 --> 00:33:14.210 There are the people creating the blocks. 00:33:14.210 --> 00:33:16.290 And there are the people reading the blocks. 00:33:16.290 --> 00:33:17.957 And sometimes those are the same people. 00:33:17.957 --> 00:33:19.367 Sometimes, they're not. 00:33:19.367 --> 00:33:20.700 So we're looking at blocks here. 00:33:20.700 --> 00:33:22.700 So these are people who are creating the blocks. 00:33:26.520 --> 00:33:28.710 And, again, both of these sets of people 00:33:28.710 --> 00:33:31.170 might upgrade or not upgrade. 00:33:31.170 --> 00:33:34.947 So we might have miners who are following the old rules 00:33:34.947 --> 00:33:36.780 and miners who were following the new rules. 00:33:36.780 --> 00:33:38.340 Then we might have validating nodes 00:33:38.340 --> 00:33:40.075 who are following the old rules, and validating nodes who 00:33:40.075 --> 00:33:41.730 are following the new rules. 00:33:41.730 --> 00:33:43.570 And this is not even talking about SPV yet. 00:33:43.570 --> 00:33:45.070 OK, we're just talking about miners. 00:33:45.070 --> 00:33:47.800 And we're talking about nodes. 00:33:47.800 --> 00:33:51.380 So let's say some of the miners upgrade to the new rules, 00:33:51.380 --> 00:33:54.340 but not all of the miners upgrade to the new rules. 00:33:54.340 --> 00:33:57.400 The miners who didn't upgrade to the new rules 00:33:57.400 --> 00:34:00.860 are going to continue producing old rule blocks. 00:34:00.860 --> 00:34:04.510 They're going to continue producing V1 version blocks. 00:34:04.510 --> 00:34:08.650 But if the majority of miners upgrade to the new rules, 00:34:08.650 --> 00:34:13.300 remember, the new rule people have new rules. 00:34:13.300 --> 00:34:16.750 So they have more restrictions on the set of blocks 00:34:16.750 --> 00:34:18.820 that they will accept. 00:34:18.820 --> 00:34:22.558 So they might not see that block as valid. 00:34:22.558 --> 00:34:24.850 So they're never going to accept that chain, because it 00:34:24.850 --> 00:34:26.380 has invalid things in it. 00:34:26.380 --> 00:34:28.780 Once you've upgraded, you might no longer 00:34:28.780 --> 00:34:30.455 accept the old chain as valid. 00:34:30.455 --> 00:34:32.080 And so what's going to end up happening 00:34:32.080 --> 00:34:34.246 is something that looks very much like the orphaning 00:34:34.246 --> 00:34:35.920 situation that was happening before, 00:34:35.920 --> 00:34:38.800 where if the majority of the hash powers, which 00:34:38.800 --> 00:34:42.639 is over here, this chain is going to keep going bigger. 00:34:42.639 --> 00:34:45.429 These guys might keep trying to produce old style blocks. 00:34:45.429 --> 00:34:47.770 But they just keep getting orphaned off. 00:34:47.770 --> 00:34:50.980 It's actually like very much in their economic interest 00:34:50.980 --> 00:34:54.010 to hurry up and upgrade, so they're not wasting hash power 00:34:54.010 --> 00:34:54.850 on orphan blocks. 00:34:59.170 --> 00:35:01.120 Are there questions about soft forks? 00:35:07.000 --> 00:35:08.470 Yes? 00:35:08.470 --> 00:35:10.750 AUDIENCE: So are soft forks also used 00:35:10.750 --> 00:35:15.640 for changing software other than validation? 00:35:15.640 --> 00:35:18.480 NEHA NARULA: Yes, that's a great question. 00:35:18.480 --> 00:35:21.040 Are soft forks also used for changing software other 00:35:21.040 --> 00:35:22.310 than validation? 00:35:22.310 --> 00:35:27.760 So we can certainly upgrade more than just the validation 00:35:27.760 --> 00:35:30.400 parts of the bitcoin software. 00:35:30.400 --> 00:35:33.850 If it doesn't change the set of blocks that would be accepted 00:35:33.850 --> 00:35:38.050 or not accepted, we don't even bother calling it a fork. 00:35:38.050 --> 00:35:42.250 So let's say that we wanted to change something about the peer 00:35:42.250 --> 00:35:45.790 to peer network, or the way that things are stored on disk, 00:35:45.790 --> 00:35:48.340 or something like that. 00:35:48.340 --> 00:35:51.053 We would see that a change like that, 00:35:51.053 --> 00:35:53.470 if it didn't change the set of blocks that would have been 00:35:53.470 --> 00:35:56.710 accepted or not accepted, if after the change 00:35:56.710 --> 00:35:59.230 a set of blocks accepted or not accepted is the exact same, 00:35:59.230 --> 00:36:02.910 we don't call that a fork, a change that induces a fork. 00:36:02.910 --> 00:36:05.410 It's only when the set of blocks are accepted or wouldn't be 00:36:05.410 --> 00:36:06.760 accepted are actually changed. 00:36:06.760 --> 00:36:07.420 Yes? 00:36:07.420 --> 00:36:09.913 AUDIENCE: How often do updates get pushed on the network? 00:36:09.913 --> 00:36:11.080 NEHA NARULA: Great question. 00:36:11.080 --> 00:36:13.270 How often do updates get pushed on the network? 00:36:13.270 --> 00:36:16.870 So Bitcoin is at version 0.16 right now. 00:36:16.870 --> 00:36:19.998 And 0.16 came out like a week or two ago. 00:36:19.998 --> 00:36:22.540 And I think it's sort of been on the order of a couple months 00:36:22.540 --> 00:36:26.320 between different versions of Bitcoin. 00:36:26.320 --> 00:36:28.510 Other cryptocurrencies release more frequently. 00:36:28.510 --> 00:36:30.940 Some release less frequently. 00:36:30.940 --> 00:36:33.310 Some do forks very, very regularly. 00:36:33.310 --> 00:36:35.322 And we'll speak a little bit about that. 00:36:35.322 --> 00:36:37.780 But the software is pretty much constantly getting updated. 00:36:41.840 --> 00:36:42.600 Yeah? 00:36:42.600 --> 00:36:45.390 AUDIENCE: So in practice, people are just 00:36:45.390 --> 00:36:47.680 updating their versions? 00:36:47.680 --> 00:36:50.360 NEHA NARULA: Yeah, so in Bitcoin in particular, 00:36:50.360 --> 00:36:52.525 Bitcoin does not have an auto update function. 00:36:52.525 --> 00:36:54.650 So in order to run the new version of the software, 00:36:54.650 --> 00:36:56.030 you have to decide that you're going 00:36:56.030 --> 00:36:57.655 to run the new version of the software. 00:36:57.655 --> 00:37:00.620 Or there might be a way to decide to turn auto update on. 00:37:00.620 --> 00:37:01.400 I can't remember. 00:37:01.400 --> 00:37:03.290 But the point is that they try to leave it 00:37:03.290 --> 00:37:05.330 in their user's hands. 00:37:05.330 --> 00:37:05.830 Yes? 00:37:05.830 --> 00:37:07.810 AUDIENCE: How are versions created? 00:37:07.810 --> 00:37:10.870 So if you like on the GitHub, there are a ton of features, 00:37:10.870 --> 00:37:13.060 and sometimes they're pushed forward. 00:37:13.060 --> 00:37:15.310 Is there a subreddit, where they're like, OK, version? 00:37:18.690 --> 00:37:20.440 NEHA NARULA: OK, how are versions created? 00:37:20.440 --> 00:37:22.928 It's actually very similar to any other software project, 00:37:22.928 --> 00:37:24.970 where the people who work on the software project 00:37:24.970 --> 00:37:28.950 get together, and decide which pull requests are going 00:37:28.950 --> 00:37:30.200 to be part of the new version. 00:37:30.200 --> 00:37:31.700 So, yes, at some point, they're just 00:37:31.700 --> 00:37:33.720 like, new version, release. 00:37:33.720 --> 00:37:34.220 Yeah? 00:37:37.130 --> 00:37:40.938 AUDIENCE: Do software get released as updated versions? 00:37:40.938 --> 00:37:42.730 NEHA NARULA: Yes, soft forks are definitely 00:37:42.730 --> 00:37:45.820 released as updated versions. 00:37:45.820 --> 00:37:48.250 So that's a great question. 00:37:48.250 --> 00:37:50.732 I think not every version has a soft fork in it. 00:37:50.732 --> 00:37:52.690 But if there is a soft fork, it will definitely 00:37:52.690 --> 00:37:53.950 be a new version. 00:37:53.950 --> 00:37:54.770 Yes? 00:37:54.770 --> 00:37:56.890 AUDIENCE: Why can't this black miner 00:37:56.890 --> 00:38:00.200 not just look at the version in the blue block 00:38:00.200 --> 00:38:01.450 and decide not to? 00:38:01.450 --> 00:38:04.840 NEHA NARULA: Because it's not a blue block. 00:38:04.840 --> 00:38:09.110 So you're talking about here, right? 00:38:11.920 --> 00:38:15.460 OK, so the nodes are running different software. 00:38:15.460 --> 00:38:18.910 And then a block comes along that-- 00:38:21.630 --> 00:38:26.010 ideally, yes the block would have a version number in it 00:38:26.010 --> 00:38:29.770 that specifies which version of the software. 00:38:29.770 --> 00:38:33.920 And this is a very useful field in the block header. 00:38:33.920 --> 00:38:38.050 But that's not really-- 00:38:38.050 --> 00:38:39.860 so what it has a different version? 00:38:39.860 --> 00:38:42.230 AUDIENCE: If it's lower than mine-- 00:38:42.230 --> 00:38:45.550 sorry, higher than mine, then I don't do it. 00:38:45.550 --> 00:38:46.765 Then I won't update first. 00:38:46.765 --> 00:38:48.640 NEHA NARULA: What do you mean by don't do it? 00:38:48.640 --> 00:38:50.500 You mean, you ignore it? 00:38:50.500 --> 00:38:52.840 AUDIENCE: No, I [INAUDIBLE] myself, 00:38:52.840 --> 00:38:55.408 because I see that a higher version is in circulation. 00:38:55.408 --> 00:38:56.950 NEHA NARULA: So that would be one way 00:38:56.950 --> 00:38:59.450 of running the network, which is if I ever see anything that 00:38:59.450 --> 00:39:01.750 indicates that there's newer software out there, 00:39:01.750 --> 00:39:04.990 I just realize I'm old, and that I need to update. 00:39:07.720 --> 00:39:10.720 I think that Bitcoin simply made a different design 00:39:10.720 --> 00:39:15.710 decision, which was that older nodes should still be able to-- 00:39:15.710 --> 00:39:19.450 because think about nodes that were sort of set it 00:39:19.450 --> 00:39:22.060 and forget it, they're out there running. 00:39:22.060 --> 00:39:23.800 One tenant that is absolutely true 00:39:23.800 --> 00:39:25.900 is that users will not upgrade. 00:39:25.900 --> 00:39:27.580 They will not all upgrade. 00:39:27.580 --> 00:39:28.460 It just won't happen. 00:39:28.460 --> 00:39:30.250 You will have old versions of software running. 00:39:30.250 --> 00:39:32.620 And given that you will have old versions of software running, 00:39:32.620 --> 00:39:34.720 I think it's a question as to whether or not those 00:39:34.720 --> 00:39:36.370 nodes should still be a part of the network, 00:39:36.370 --> 00:39:38.120 or whether you just want to slice them off 00:39:38.120 --> 00:39:40.635 because they're not running the latest version. 00:39:40.635 --> 00:39:42.010 And I think in Bitcoin, they want 00:39:42.010 --> 00:39:43.940 those nodes to still be a part of the network. 00:39:43.940 --> 00:39:46.630 They want people to be able to make the active decision not 00:39:46.630 --> 00:39:48.350 to upgrade. 00:39:48.350 --> 00:39:52.680 Tadge actually, I think is still running 0.13, or some older 00:39:52.680 --> 00:39:53.940 version of Bitcoin. 00:39:53.940 --> 00:39:55.050 Still works great. 00:39:55.050 --> 00:39:59.440 He can still validate transactions totally fine. 00:39:59.440 --> 00:40:03.010 OK, so we just talked about soft forks. 00:40:03.010 --> 00:40:05.510 And I think the important thing to remember about soft works 00:40:05.510 --> 00:40:07.760 is that soft works are backwards compatible. 00:40:07.760 --> 00:40:13.850 We also talked about an example that is not a hard fork, which 00:40:13.850 --> 00:40:16.490 is if we decided that we wanted to allow blocks that 00:40:16.490 --> 00:40:19.040 were less than two megabytes, instead of less 00:40:19.040 --> 00:40:20.300 than one megabyte. 00:40:20.300 --> 00:40:25.500 And so a 1.75 megabyte of block appears. 00:40:25.500 --> 00:40:27.220 That is not a soft work. 00:40:27.220 --> 00:40:29.790 What if we changed the rule to say 00:40:29.790 --> 00:40:32.795 that, instead of only accepting blocks that 00:40:32.795 --> 00:40:34.170 are less than one megabyte, we're 00:40:34.170 --> 00:40:37.230 only going to accept blocks that are less than half a megabyte. 00:40:37.230 --> 00:40:38.720 Is that a soft work or hard fork? 00:40:43.310 --> 00:40:45.127 AUDIENCE: Soft fork. 00:40:45.127 --> 00:40:46.460 NEHA NARULA: That's a soft work. 00:40:46.460 --> 00:40:48.220 The reason that that's a soft fork, 00:40:48.220 --> 00:40:50.890 is because a block that is less than half a megabyte 00:40:50.890 --> 00:40:53.470 was also still less than one megabyte. 00:40:53.470 --> 00:40:58.210 So it's still valid under the old set of rules. 00:40:58.210 --> 00:41:01.275 So if the change made here was now we want smaller blocks. 00:41:01.275 --> 00:41:02.900 So we're only going to take blocks that 00:41:02.900 --> 00:41:05.030 are less than half a megabyte. 00:41:05.030 --> 00:41:07.237 That's fine. 00:41:07.237 --> 00:41:09.070 Everyone will still see this chain as valid. 00:41:09.070 --> 00:41:10.800 This is still backwards compatible. 00:41:10.800 --> 00:41:12.750 Just because your blocks are 300 kilobytes now 00:41:12.750 --> 00:41:15.970 doesn't mean that they violate a rule. 00:41:15.970 --> 00:41:18.945 AUDIENCE: Can I ask one last question in relation to that? 00:41:18.945 --> 00:41:21.120 So what happens if I want to do something 00:41:21.120 --> 00:41:26.160 with the old version, and [INAUDIBLE].. 00:41:26.160 --> 00:41:28.840 And they realize, wow, I love [INAUDIBLE].. 00:41:35.172 --> 00:41:36.630 NEHA NARULA: Right, so what happens 00:41:36.630 --> 00:41:38.910 to all the previous stuff in my chain, right? 00:41:38.910 --> 00:41:41.070 Now, ideally, the way that the rules 00:41:41.070 --> 00:41:44.880 would be setup, the new rules, is that they would take effect 00:41:44.880 --> 00:41:46.265 sometime in the future. 00:41:46.265 --> 00:41:47.640 So you wouldn't apply those rules 00:41:47.640 --> 00:41:51.330 retroactively to the things that you already put into the chain, 00:41:51.330 --> 00:41:53.400 because then you just throw away all history. 00:41:53.400 --> 00:41:54.858 And that would be kind of a bummer. 00:41:54.858 --> 00:41:56.335 Instead, you say, after this block, 00:41:56.335 --> 00:41:57.960 we are only going to accept blocks that 00:41:57.960 --> 00:41:59.310 are less than half a megabyte. 00:41:59.310 --> 00:42:01.227 AUDIENCE: So what happens if after that block, 00:42:01.227 --> 00:42:05.963 so a majority of miners are running old software. 00:42:05.963 --> 00:42:07.130 NEHA NARULA: Great question. 00:42:07.130 --> 00:42:08.315 AUDIENCE: [INAUDIBLE] 00:42:08.315 --> 00:42:09.690 NEHA NARULA: We'll get into that. 00:42:09.690 --> 00:42:13.470 We'll get into what happens when the majority, versus minority, 00:42:13.470 --> 00:42:16.050 of different parts of the ecosystem decide 00:42:16.050 --> 00:42:19.720 to adopt the change, versus not adopt the change. 00:42:19.720 --> 00:42:21.720 But first, we're going to talk about hard forks. 00:42:21.720 --> 00:42:23.520 What is a hard fork? 00:42:23.520 --> 00:42:26.070 A hard fork is not backwards compatible. 00:42:26.070 --> 00:42:28.470 And so a hard fork is a fork where, 00:42:28.470 --> 00:42:31.200 if this was the old set of rules, 00:42:31.200 --> 00:42:33.630 under the new set of rules you actually accept 00:42:33.630 --> 00:42:36.180 more blocks than you would have accepted before. 00:42:39.120 --> 00:42:44.720 So just to be clear, under the new rules, 00:42:44.720 --> 00:42:47.960 you might produce a block, which a node running 00:42:47.960 --> 00:42:51.410 under the old rules will reject. 00:42:51.410 --> 00:42:54.680 This is not backwards compatible, 00:42:54.680 --> 00:43:00.440 because any chain that has this new type of block in it 00:43:00.440 --> 00:43:03.485 will not be accepted by any of the old nodes, full stop. 00:43:03.485 --> 00:43:05.360 It doesn't matter about proof of work at all. 00:43:12.920 --> 00:43:18.940 OK, so the thing with hard forks is 00:43:18.940 --> 00:43:21.920 that because they're not backwards compatible, 00:43:21.920 --> 00:43:24.790 they're a little crazier and a little bit sort of harder 00:43:24.790 --> 00:43:27.040 to manage in your network. 00:43:27.040 --> 00:43:31.030 Because if you do a hard fork and not everyone upgrades, 00:43:31.030 --> 00:43:33.610 you might end up with two chains, possibly forever. 00:43:36.240 --> 00:43:39.715 If we assume that those nodes are not going to upgrade-- 00:43:39.715 --> 00:43:41.840 and let's say they're not upgrading because there's 00:43:41.840 --> 00:43:43.710 no one really maintaining them. 00:43:43.710 --> 00:43:46.338 Then they're not going to upgrade in the future. 00:43:46.338 --> 00:43:48.380 And they're not going to upgrade to a change that 00:43:48.380 --> 00:43:50.360 might fix what's going on here. 00:43:50.360 --> 00:43:53.540 They're just going to keep doing their old time thing. 00:43:53.540 --> 00:43:57.350 Then with a hard fork, these nodes 00:43:57.350 --> 00:44:01.723 are never going to accept the new blocks. 00:44:01.723 --> 00:44:06.210 It doesn't matter what the proof of work is on that chain. 00:44:06.210 --> 00:44:08.490 So hard forks versus soft works-- 00:44:08.490 --> 00:44:11.640 hard forks, as I keep stressing, are not backwards compatible. 00:44:11.640 --> 00:44:12.210 Guess what? 00:44:12.210 --> 00:44:15.570 A fork can be a hard fork and a soft work at the same time. 00:44:15.570 --> 00:44:18.120 Yay. 00:44:18.120 --> 00:44:21.510 Super confusing, actually, because you 00:44:21.510 --> 00:44:23.490 can both restrict the set of rules 00:44:23.490 --> 00:44:26.130 and expand the set of rules at the same time. 00:44:26.130 --> 00:44:29.820 Basically, it means it's a new, overlapping, but not entirely 00:44:29.820 --> 00:44:34.430 inclusive or not inclusive, set of rules, very unfortunate. 00:44:34.430 --> 00:44:36.020 In fact, most things should actually 00:44:36.020 --> 00:44:37.545 be both, to avoid some of the things 00:44:37.545 --> 00:44:39.170 that I'm going to show you in a minute. 00:44:39.170 --> 00:44:39.680 Yes? 00:44:39.680 --> 00:44:42.080 AUDIENCE: But then for all useful purposes, 00:44:42.080 --> 00:44:43.820 isn't it just a hard fork, because that 00:44:43.820 --> 00:44:45.968 means some nodes won't be inside the blocks. 00:44:45.968 --> 00:44:47.510 NEHA NARULA: For all useful purposes, 00:44:47.510 --> 00:44:51.215 it's not just a hard fork. 00:44:51.215 --> 00:44:52.090 Let me see if I can-- 00:45:01.450 --> 00:45:03.550 The reason that it's not just a hard fork-- 00:45:08.373 --> 00:45:10.790 this is something that requires a little bit more thought. 00:45:10.790 --> 00:45:12.110 It's not just a hard fork. 00:45:12.110 --> 00:45:14.070 But I will think about how to explain this, and perhaps 00:45:14.070 --> 00:45:14.987 say something on this. 00:45:14.987 --> 00:45:16.022 Or, yeah? 00:45:16.022 --> 00:45:18.420 AUDIENCE: [INAUDIBLE] 00:45:35.078 --> 00:45:35.870 NEHA NARULA: It is. 00:45:35.870 --> 00:45:38.720 But he's asking, isn't that just a hard fork? 00:45:38.720 --> 00:45:40.670 And it's not just a hard fork, because I 00:45:40.670 --> 00:45:46.900 think old nodes will do something different. 00:45:46.900 --> 00:45:52.100 Ah, OK, so there's two reasons why it's not just a hard fork. 00:45:52.100 --> 00:45:53.970 One is because of reorgs. 00:45:53.970 --> 00:45:59.690 So different things will happen as the majority of hash power 00:45:59.690 --> 00:46:04.280 starts to accept or not accept the change, 00:46:04.280 --> 00:46:07.250 whether or not all nodes will switch over or not. 00:46:07.250 --> 00:46:09.470 But if it's both a hard and a soft work, 00:46:09.470 --> 00:46:11.570 they will never switch over. 00:46:11.570 --> 00:46:18.050 But I think the question is whether old nodes can 00:46:18.050 --> 00:46:20.660 even still function. 00:46:20.660 --> 00:46:24.590 So I think one way to use combination 00:46:24.590 --> 00:46:27.110 hard and soft works is to actually stop 00:46:27.110 --> 00:46:31.730 the old nodes from being able to have blocks at all. 00:46:31.730 --> 00:46:33.590 Like, you design things in such a way, 00:46:33.590 --> 00:46:37.430 that given a majority of hash power moves over, 00:46:37.430 --> 00:46:39.572 they're just going to end up with nothing. 00:46:39.572 --> 00:46:41.030 But this is a really good question. 00:46:41.030 --> 00:46:42.780 And we should go into more detail on this. 00:46:42.780 --> 00:46:46.230 And I will try to figure out a way to get that to you guys. 00:46:46.230 --> 00:46:50.140 OK, so who controls forks? 00:46:54.390 --> 00:46:54.890 Yes? 00:46:58.250 --> 00:46:58.750 Sorry? 00:46:58.750 --> 00:46:59.792 AUDIENCE: The developers. 00:46:59.792 --> 00:47:01.958 NEHA NARULA: OK, the developers, which I didn't even 00:47:01.958 --> 00:47:03.050 write down as a note here. 00:47:03.050 --> 00:47:06.460 OK, do the Bitcoin developers control forks? 00:47:06.460 --> 00:47:09.635 Who thinks yes? 00:47:09.635 --> 00:47:12.360 You're not even raising your hand. 00:47:12.360 --> 00:47:13.090 Who thinks no? 00:47:16.267 --> 00:47:18.600 Determines whether or not a fork is going to go through. 00:47:18.600 --> 00:47:20.600 There's the Bitcoin developers, who are actually 00:47:20.600 --> 00:47:22.930 writing the software, and who also 00:47:22.930 --> 00:47:26.140 have a lot of influence in the system, 00:47:26.140 --> 00:47:28.360 because presumably they understand it really well 00:47:28.360 --> 00:47:30.160 if they're writing software. 00:47:30.160 --> 00:47:33.073 So they can write some software, and decide 00:47:33.073 --> 00:47:34.240 that they want to do a fork. 00:47:34.240 --> 00:47:36.820 Does that mean that the fork is going to go through? 00:47:36.820 --> 00:47:39.900 No, certainly not, everyone can ignore them. 00:47:39.900 --> 00:47:41.650 And there have been situations in the past 00:47:41.650 --> 00:47:43.870 where everyone ignored them for quite a long time, 00:47:43.870 --> 00:47:46.870 and argued about it, and didn't push a fork through. 00:47:46.870 --> 00:47:52.000 Well, miners are the ones who actually create the blocks. 00:47:52.000 --> 00:47:56.280 Are they the ones who control forks? 00:47:56.280 --> 00:47:57.900 I see a very strong head shake no. 00:47:57.900 --> 00:48:00.560 Why do you shake your head? 00:48:00.560 --> 00:48:02.050 AUDIENCE: So if the miners decide 00:48:02.050 --> 00:48:04.500 to change what types of blocks they're putting out, 00:48:04.500 --> 00:48:05.615 they can do that. 00:48:05.615 --> 00:48:08.000 But the nodes that are actually validating it, 00:48:08.000 --> 00:48:10.502 no one can say they're not going to accept it. 00:48:10.502 --> 00:48:11.460 NEHA NARULA: Very true. 00:48:11.460 --> 00:48:15.810 So as we saw before, there are times when nodes will not 00:48:15.810 --> 00:48:18.420 accept a chain no matter how much proof of work 00:48:18.420 --> 00:48:19.473 it has on it. 00:48:19.473 --> 00:48:21.390 I think that's a very common misunderstanding. 00:48:21.390 --> 00:48:24.720 The nodes run their own validation rules. 00:48:24.720 --> 00:48:28.830 And so if I'm running a node, I can run whatever 00:48:28.830 --> 00:48:30.450 validation rules I want. 00:48:30.450 --> 00:48:34.050 And I can decide what chain is the one that 00:48:34.050 --> 00:48:38.250 aligns with my interests. 00:48:38.250 --> 00:48:38.750 Yes? 00:48:41.987 --> 00:48:43.570 AUDIENCE: If you're doing a hard fork, 00:48:43.570 --> 00:48:45.680 and you are accepting new blocks, 00:48:45.680 --> 00:48:48.220 and they just never mined any blocks with those new rules. 00:48:48.220 --> 00:48:49.130 NEHA NARULA: Exactly. 00:48:49.130 --> 00:48:52.220 So there's certainly incentives in many different directions. 00:48:52.220 --> 00:48:55.832 If all the miners decided to go to one side, 00:48:55.832 --> 00:48:58.040 then I'm a full node with my side of validation rules 00:48:58.040 --> 00:48:59.390 who has no new blocks. 00:48:59.390 --> 00:49:01.200 Great, what am I going to do? 00:49:01.200 --> 00:49:03.060 How am I going to make transactions? 00:49:03.060 --> 00:49:04.670 How am I going to spend my money? 00:49:04.670 --> 00:49:08.170 Also, let's say all the miners don't go to one side, 00:49:08.170 --> 00:49:12.350 but most of them do, and most of the nodes go to the other side. 00:49:12.350 --> 00:49:13.853 Then what am I going to do? 00:49:13.853 --> 00:49:15.020 Who's going to listen to me? 00:49:15.020 --> 00:49:17.020 Who's going to trade with me? 00:49:17.020 --> 00:49:21.610 Who's going to take the coins on my side of the fork? 00:49:21.610 --> 00:49:26.382 So I guess that's just to say that it's complicated. 00:49:26.382 --> 00:49:27.340 There's the developers. 00:49:27.340 --> 00:49:28.132 There's the miners. 00:49:28.132 --> 00:49:29.050 There's nodes. 00:49:29.050 --> 00:49:32.070 There's the users who determine the economic value 00:49:32.070 --> 00:49:33.820 of these tokens, and which side they think 00:49:33.820 --> 00:49:36.100 is more valuable or less valuable. 00:49:36.100 --> 00:49:38.432 And we've seen this happen with lots 00:49:38.432 --> 00:49:39.890 of cryptocurrencies multiple times. 00:49:39.890 --> 00:49:40.973 And it's kind of exciting. 00:49:40.973 --> 00:49:43.480 So Bitcoin has forked multiple times. 00:49:43.480 --> 00:49:47.590 And every time it's forked so far, 00:49:47.590 --> 00:49:50.500 it has created a whole new version of the coin. 00:49:50.500 --> 00:49:54.642 So it's been like a pretty serious hard fork. 00:49:54.642 --> 00:49:56.100 And so now, in addition to Bitcoin, 00:49:56.100 --> 00:50:01.050 there's Bitcoin Cash, Bitcoin Gold, Bitcoin Diamond. 00:50:01.050 --> 00:50:05.010 Ethereum also has fought. 00:50:05.010 --> 00:50:09.000 In Ethereum's case, they tried to take along everyone 00:50:09.000 --> 00:50:10.020 with them. 00:50:10.020 --> 00:50:11.490 And so the hard fork was supposed 00:50:11.490 --> 00:50:13.980 to be an upgrade to Ethereum. 00:50:13.980 --> 00:50:15.450 But some people decided they didn't 00:50:15.450 --> 00:50:16.980 want to go along with it. 00:50:16.980 --> 00:50:18.315 So there's Ethereum Classic. 00:50:18.315 --> 00:50:19.190 And there's Ethereum. 00:50:23.300 --> 00:50:26.660 Both of them have value. 00:50:26.660 --> 00:50:30.830 So it's really unclear who controls forks. 00:50:30.830 --> 00:50:34.940 So now, let's talk about hash rate and forks. 00:50:34.940 --> 00:50:36.980 So nodes are pretty-- 00:50:36.980 --> 00:50:41.780 OK, what nodes will do is they have a set of validation rules. 00:50:41.780 --> 00:50:47.040 If a block validates under their set of validation rules, 00:50:47.040 --> 00:50:48.390 they will accept it. 00:50:48.390 --> 00:50:52.260 And if all the blocks validate under their validation rules, 00:50:52.260 --> 00:50:55.500 they will accept the chain that those blocks are on. 00:50:55.500 --> 00:50:57.720 And if there are two different chains where 00:50:57.720 --> 00:51:00.450 all the blocks validate under their validation rules, 00:51:00.450 --> 00:51:03.450 they'll take the one with the heaviest proof of work. 00:51:03.450 --> 00:51:06.780 That's what nodes do. 00:51:06.780 --> 00:51:09.900 So heaviest proof of work is clearly kind of important 00:51:09.900 --> 00:51:13.560 here, if both sides of a fork validate. 00:51:13.560 --> 00:51:16.610 So if both sides of a fork validate-- 00:51:16.610 --> 00:51:20.193 so we have to think about this from the perspective of nodes 00:51:20.193 --> 00:51:22.110 who upgrade to the new software, and nodes who 00:51:22.110 --> 00:51:24.300 don't upgrade to new software. 00:51:24.300 --> 00:51:27.362 So it might be worth it to try to kind of write 00:51:27.362 --> 00:51:28.320 this down a little bit. 00:51:42.300 --> 00:51:49.185 So we have the old rule nodes, and the new rule nodes. 00:51:53.760 --> 00:51:57.310 And let's just talk about one kind of work for now. 00:51:57.310 --> 00:52:02.830 Now, let's say less than 50% of the miners upgrade. 00:52:05.430 --> 00:52:13.780 And let's say greater than 50% of the miners upgrade. 00:52:13.780 --> 00:52:16.500 OK, so let's use this chart, as we're 00:52:16.500 --> 00:52:18.810 kind of trying to reason about what's 00:52:18.810 --> 00:52:24.420 going to happen in the ecosystem for soft works and hard works. 00:52:24.420 --> 00:52:30.462 So what happens if a soft fork does not obtain more than 50% 00:52:30.462 --> 00:52:31.170 of the hash rate? 00:52:33.740 --> 00:52:35.440 So we've got the old rules. 00:52:38.530 --> 00:52:40.488 We've got nodes. 00:52:40.488 --> 00:52:41.530 Some nodes have upgraded. 00:52:41.530 --> 00:52:43.720 Some nodes haven't upgraded. 00:52:43.720 --> 00:52:47.820 Less than 50% of the miners have upgraded. 00:52:47.820 --> 00:52:50.223 So the old rule chain is going to be longer, 00:52:50.223 --> 00:52:51.890 because they're going to continue mining 00:52:51.890 --> 00:52:53.960 on the old rules. 00:52:53.960 --> 00:52:55.877 By the way, sometimes they don't ignore things 00:52:55.877 --> 00:52:56.668 with the new rules. 00:52:56.668 --> 00:52:57.500 Sometimes they do. 00:52:57.500 --> 00:52:58.417 It's very complicated. 00:52:58.417 --> 00:53:01.100 But let's just pretend right now that they are ignoring things 00:53:01.100 --> 00:53:02.810 with the new rules, because they haven't upgraded, 00:53:02.810 --> 00:53:03.810 and they don't see that. 00:53:06.120 --> 00:53:09.270 Or, sorry, they would see the new rules as valid. 00:53:09.270 --> 00:53:12.150 But the majority of the hashing power is over here. 00:53:12.150 --> 00:53:13.337 So what's going to happen? 00:53:18.590 --> 00:53:19.110 Yes? 00:53:19.110 --> 00:53:20.527 AUDIENCE: The benefits of the fork 00:53:20.527 --> 00:53:25.260 aren't going to really be useful much, because be there'll 00:53:25.260 --> 00:53:29.800 be some blocks with the new rules. 00:53:29.800 --> 00:53:33.900 But the majority is just not going to change. 00:53:33.900 --> 00:53:39.300 NEHA NARULA: Right, so it kind of depends on the soft fork. 00:53:39.300 --> 00:53:44.340 So it depends on what the new rule nodes think of old blocks. 00:53:44.340 --> 00:53:49.960 If they think that old blocks are still all valid, 00:53:49.960 --> 00:53:55.270 then they're going to build upon old blocks just fine, 00:53:55.270 --> 00:53:56.710 because they think they're valid. 00:53:56.710 --> 00:54:00.200 If they think that old blocks are no longer valid, 00:54:00.200 --> 00:54:03.460 then they're going to try to do their own chain. 00:54:06.190 --> 00:54:09.250 But the majority of the hashing power is with the old side. 00:54:09.250 --> 00:54:12.300 So they're just going to get reorged out. 00:54:12.300 --> 00:54:12.900 Yes? 00:54:12.900 --> 00:54:15.630 AUDIENCE: If it's a soft fork, but they also 00:54:15.630 --> 00:54:18.363 think all the blocks are valid, how is it a fork at all? 00:54:21.763 --> 00:54:23.180 NEHA NARULA: So an example of this 00:54:23.180 --> 00:54:30.950 is taking what was an unused op code, 00:54:30.950 --> 00:54:32.870 and now making it meaningful. 00:54:32.870 --> 00:54:37.250 So it just so happens that none of the old rule nodes 00:54:37.250 --> 00:54:40.580 ever used this silly unused op code. 00:54:40.580 --> 00:54:42.410 Because they never used it, they never 00:54:42.410 --> 00:54:46.910 had any invalid uses of the op code. 00:54:46.910 --> 00:54:52.395 So the new nodes will still accept old blocks, 00:54:52.395 --> 00:54:54.270 because none of them use this op code anyway. 00:54:54.270 --> 00:54:57.720 But if they were to use the new op code, 00:54:57.720 --> 00:55:00.090 and they used it as a no-op op code, 00:55:00.090 --> 00:55:02.250 instead of what the new rules are then 00:55:02.250 --> 00:55:03.925 it would be an invalid block. 00:55:03.925 --> 00:55:04.800 Does that make sense? 00:55:07.790 --> 00:55:10.690 So you have to think really carefully 00:55:10.690 --> 00:55:13.300 about how you are designing these upgrades 00:55:13.300 --> 00:55:14.500 to your software. 00:55:14.500 --> 00:55:16.112 You have to think very carefully what 00:55:16.112 --> 00:55:17.320 will happen to the old nodes. 00:55:17.320 --> 00:55:19.540 What happens if 50% of the miners take this thing? 00:55:19.540 --> 00:55:22.360 Well, under the old rules, was anyone actually using 00:55:22.360 --> 00:55:24.310 this thing, that we are now maintaining 00:55:24.310 --> 00:55:26.170 must be used in a new way? 00:55:26.170 --> 00:55:28.800 Or pay to script hash is a good example of this as well. 00:55:28.800 --> 00:55:31.510 Pay to script hash, technically, looks like you're just 00:55:31.510 --> 00:55:33.190 paying to a hash. 00:55:33.190 --> 00:55:34.780 So old nodes will see it, and say, OK, 00:55:34.780 --> 00:55:36.610 if you can produce a signature that 00:55:36.610 --> 00:55:39.470 shows that this is valid, blah, blah, whatever, whatever, 00:55:39.470 --> 00:55:40.340 that's fine. 00:55:40.340 --> 00:55:41.950 But nobody ever did that. 00:55:41.950 --> 00:55:45.430 Nobody ever did that in a way that was 00:55:45.430 --> 00:55:46.930 meaningful under the new rules. 00:55:46.930 --> 00:55:48.100 No one ever used it. 00:55:48.100 --> 00:55:51.490 So all the old things will still validate, simply 00:55:51.490 --> 00:55:53.260 because no one ever did anything that 00:55:53.260 --> 00:55:55.510 was under the subset of the new rules. 00:55:55.510 --> 00:55:57.370 Sorry, this is very kind of complicated. 00:55:57.370 --> 00:56:03.670 So what we have here is that if old rule blocks are still 00:56:03.670 --> 00:56:06.130 valid, the software will get reorged out. 00:56:06.130 --> 00:56:14.350 So no fork there, no fork there. 00:56:14.350 --> 00:56:16.070 You're just not really going to end up 00:56:16.070 --> 00:56:18.590 with stuff in the blockchain. 00:56:18.590 --> 00:56:23.460 If old rule blocks are now invalid, 00:56:23.460 --> 00:56:28.050 then we're going to end up with two chains. 00:56:28.050 --> 00:56:30.050 Do people see why this is? 00:56:30.050 --> 00:56:35.390 Because the new rule people are not 00:56:35.390 --> 00:56:41.360 going to accept any chain that has an invalid thing in it. 00:56:41.360 --> 00:56:44.940 So they're not going to reorg out. 00:56:44.940 --> 00:56:46.580 They are going to continue. 00:56:46.580 --> 00:56:49.220 And they are going to have their own chain. 00:56:49.220 --> 00:56:52.040 And they're going to ignore all of the blocks 00:56:52.040 --> 00:56:54.650 on the other chain, which they deem to be the invalid chain. 00:56:54.650 --> 00:56:55.160 Yes? 00:56:55.160 --> 00:56:57.013 AUDIENCE: Is this the case for Bitcoin Cash? 00:56:57.013 --> 00:56:59.180 NEHA NARULA: No, it's not the case for Bitcoin Cash. 00:56:59.180 --> 00:57:01.130 It's actually the case for something 00:57:01.130 --> 00:57:04.580 called a user-activated soft fork, which the bitcoin 00:57:04.580 --> 00:57:07.490 community threatened to do when the miners wouldn't 00:57:07.490 --> 00:57:09.320 do a soft fork they wanted them to do. 00:57:09.320 --> 00:57:11.900 They said, fine, you miners won't do the software 00:57:11.900 --> 00:57:13.400 that we want you to do. 00:57:13.400 --> 00:57:16.190 So, normally, people don't like the situation. 00:57:16.190 --> 00:57:17.750 So you don't want this to happen. 00:57:17.750 --> 00:57:20.600 So, normally, soft forks are written such 00:57:20.600 --> 00:57:24.440 that if you don't get 95% of the miners to sign, 00:57:24.440 --> 00:57:27.002 on the soft fork never activates. 00:57:27.002 --> 00:57:29.210 So that's the way that, traditionally, soft works are 00:57:29.210 --> 00:57:30.680 done in the Bitcoin ecosystem. 00:57:30.680 --> 00:57:31.740 What does that mean? 00:57:31.740 --> 00:57:34.790 It means 5.001% of the hash power 00:57:34.790 --> 00:57:36.590 can stop a soft fork from going through. 00:57:39.347 --> 00:57:41.180 So usually, things are written in such a way 00:57:41.180 --> 00:57:43.590 that you really want to guarantee this two chain 00:57:43.590 --> 00:57:44.780 thing never happens. 00:57:44.780 --> 00:57:47.660 We see hash power is kind of voting. 00:57:47.660 --> 00:57:49.850 And if you can get 95% of the hash power 00:57:49.850 --> 00:57:52.340 to agree with the soft fork, then only will the soft fork 00:57:52.340 --> 00:57:53.240 activate. 00:57:53.240 --> 00:57:56.960 And the way that miners do this is they signal in their block 00:57:56.960 --> 00:58:00.590 headers that they are going to adopt the soft fork. 00:58:00.590 --> 00:58:03.590 And then the software is usually programmed in such a way 00:58:03.590 --> 00:58:06.530 that it looks at some sliding window of block headers 00:58:06.530 --> 00:58:08.515 to determine whether 95% of the hash power 00:58:08.515 --> 00:58:10.640 has decided that they're going to go along with it. 00:58:10.640 --> 00:58:15.360 And it only activates once that's the case. 00:58:15.360 --> 00:58:18.100 So doing protocol upgrades is really hard. 00:58:18.100 --> 00:58:19.290 It's not a trivial matter. 00:58:19.290 --> 00:58:22.200 You don't just push some code. 00:58:22.200 --> 00:58:24.030 So usually, it's the case that you 00:58:24.030 --> 00:58:28.080 want to wait for a significant majority of the mining power 00:58:28.080 --> 00:58:30.740 to indicate support for the soft fork. 00:58:30.740 --> 00:58:32.490 And, by the way, they can indicate support 00:58:32.490 --> 00:58:34.200 without actually running the soft fork. 00:58:34.200 --> 00:58:36.330 This happens all the time. 00:58:36.330 --> 00:58:40.410 But you want to wait for significant support 00:58:40.410 --> 00:58:42.180 from the mining community before actually 00:58:42.180 --> 00:58:43.830 activating the soft fork. 00:58:43.830 --> 00:58:47.397 What happened recently with something 00:58:47.397 --> 00:58:49.480 called Segregated Witness, which we'll talk about, 00:58:49.480 --> 00:58:52.410 which was a soft fork to Bitcoin to introduce new functionality 00:58:52.410 --> 00:58:56.310 that the miners opposed, was the community actually said, 00:58:56.310 --> 00:58:57.120 forget it. 00:58:57.120 --> 00:58:59.100 We are going to start running the new rules. 00:58:59.100 --> 00:59:00.330 We're going to ignore you. 00:59:00.330 --> 00:59:02.810 We don't care what the majority of the hash power does. 00:59:02.810 --> 00:59:05.970 We are going to go ahead and create this two chain 00:59:05.970 --> 00:59:09.540 situation, and follow the chain with the new rules. 00:59:09.540 --> 00:59:14.020 Interestingly, this actually worked. 00:59:14.020 --> 00:59:16.740 I think it was like 80 plus percent of the hash power 00:59:16.740 --> 00:59:19.380 was not in favor of the soft fork. 00:59:19.380 --> 00:59:23.490 And the users managed to create this kind of detente where they 00:59:23.490 --> 00:59:25.770 forced everyone to go along with what they wanted, 00:59:25.770 --> 00:59:26.975 super interesting. 00:59:29.610 --> 00:59:32.670 They had no actual way to vote. 00:59:32.670 --> 00:59:36.510 It was entirely sort of via Twitter. 00:59:36.510 --> 00:59:38.390 AUDIENCE: [INAUDIBLE] 00:59:51.840 --> 00:59:54.090 NEHA NARULA: Yes, so this is one of the major reasons, 00:59:54.090 --> 00:59:55.882 and I think some of the strongest evidence, 00:59:55.882 --> 00:59:57.900 that miners have nowhere near as much power 00:59:57.900 --> 01:00:00.600 as you actually think they do in these ecosystems. 01:00:00.600 --> 01:00:02.850 Certainly have power, and part of the power they 01:00:02.850 --> 01:00:06.300 have is to do what's called an evil soft fork, 01:00:06.300 --> 01:00:08.682 which I'm not going to talk about in this class, 01:00:08.682 --> 01:00:10.140 but I think we probably should talk 01:00:10.140 --> 01:00:12.360 about at some point in time. 01:00:12.360 --> 01:00:15.000 OK, great. 01:00:15.000 --> 01:00:15.520 Let's see. 01:00:15.520 --> 01:00:20.740 OK, if the soft fork is greater than 50%, 01:00:20.740 --> 01:00:26.020 old rule blocks will follow the new rule blocks automatically. 01:00:26.020 --> 01:00:29.830 So we get soft fork successful. 01:00:29.830 --> 01:00:34.390 We do not have two chains, because these will simply 01:00:34.390 --> 01:00:36.730 be orphaned and abandoned. 01:00:36.730 --> 01:00:40.360 And, in fact, there's actually pressure for the miners 01:00:40.360 --> 01:00:43.060 to move over to the new rules so that their blocks aren't 01:00:43.060 --> 01:00:44.094 abandoned. 01:00:46.880 --> 01:00:48.680 Yes? 01:00:48.680 --> 01:00:54.270 AUDIENCE: So [INAUDIBLE] making it easier 01:00:54.270 --> 01:00:58.130 mine, are those considered types of forks? 01:00:58.130 --> 01:00:59.930 NEHA NARULA: It depends. 01:00:59.930 --> 01:01:01.880 So the question is around difficulty, 01:01:01.880 --> 01:01:04.580 and the number of leading zeros required in the proof of work. 01:01:04.580 --> 01:01:05.910 That changes all the time. 01:01:05.910 --> 01:01:07.430 There's a formula which determines 01:01:07.430 --> 01:01:09.500 what that number should be. 01:01:09.500 --> 01:01:11.210 So, no, it doesn't require a fork. 01:01:11.210 --> 01:01:15.920 But if you want to change the formula, that would be a fork. 01:01:15.920 --> 01:01:19.687 Requiring more proof of work would be a soft work. 01:01:19.687 --> 01:01:21.770 Requiring less proof of work would be a hard fork. 01:01:25.160 --> 01:01:27.110 OK, now let's talk about hard forks. 01:01:27.110 --> 01:01:30.650 So what happens if a hard fork doesn't 01:01:30.650 --> 01:01:33.032 obtain 50% of the hash rate? 01:01:38.984 --> 01:01:40.741 AUDIENCE: [INAUDIBLE] 01:01:43.450 --> 01:01:45.660 NEHA NARULA: It depends, again. 01:01:45.660 --> 01:01:50.460 It depends on if the old rule blocks are still valid. 01:01:50.460 --> 01:01:52.530 So we're doing a hard fork. 01:01:52.530 --> 01:01:56.700 We're changing the set of valid blocks. 01:01:56.700 --> 01:02:01.200 If blocks are still valid under the old rules, 01:02:01.200 --> 01:02:05.790 then we're going to end up with a situation like this. 01:02:05.790 --> 01:02:07.920 If old rule blocks are still valid 01:02:07.920 --> 01:02:10.800 according to the new rule nodes, then the new rule nodes 01:02:10.800 --> 01:02:12.020 will just follow along. 01:02:12.020 --> 01:02:17.880 OK, so basically no work happening here, 01:02:17.880 --> 01:02:22.940 because the new rule nodes are going to produce blocks. 01:02:22.940 --> 01:02:26.790 They're not going to have enough of the hash power. 01:02:26.790 --> 01:02:31.950 And so they're not going to be considered valid 01:02:31.950 --> 01:02:33.750 by the other set. 01:02:33.750 --> 01:02:37.770 So they're going to end up following 01:02:37.770 --> 01:02:40.590 along with the old rule nodes. 01:02:40.590 --> 01:02:41.152 Yes? 01:02:41.152 --> 01:02:43.360 AUDIENCE: Again, isn't the whole point of a hard fork 01:02:43.360 --> 01:02:47.090 that you're expanding the set of things that are valid? 01:02:47.090 --> 01:02:51.498 So aren't all old blocks going to be valid in a hard fork? 01:02:51.498 --> 01:02:53.540 NEHA NARULA: Not if it's a combination hard fork, 01:02:53.540 --> 01:02:54.040 soft fork. 01:02:54.040 --> 01:02:56.075 So maybe I should split this up into 01:02:56.075 --> 01:02:57.450 whether or not it's a combination 01:02:57.450 --> 01:02:59.160 hard fork, soft fork, or not. 01:02:59.160 --> 01:03:02.820 OK, so what happens if a hard fork doesn't obtain greater 01:03:02.820 --> 01:03:05.463 than 50% of the hash rate? 01:03:05.463 --> 01:03:06.630 What's going to happen then? 01:03:12.606 --> 01:03:15.600 AUDIENCE: We'll be mining to the old rules. 01:03:15.600 --> 01:03:18.570 NEHA NARULA: Yes, we're going to end up with two chains. 01:03:18.570 --> 01:03:21.978 This is going to have chain-- 01:03:21.978 --> 01:03:23.520 whatever, the point is, there's going 01:03:23.520 --> 01:03:26.040 to be an old chain and a new chain. 01:03:26.040 --> 01:03:32.590 The old nodes are never going to accept the new nodes blocks. 01:03:32.590 --> 01:03:37.940 And we're going to end up with two chains forever. 01:03:37.940 --> 01:03:40.490 And this has happened multiple times. 01:03:43.290 --> 01:03:45.840 Are there questions about hard forks? 01:03:50.790 --> 01:03:51.700 Yes? 01:03:51.700 --> 01:03:53.992 AUDIENCE: Are there ways for the hard fork to make life 01:03:53.992 --> 01:03:57.757 really difficult for the smaller chain? 01:03:57.757 --> 01:04:00.090 NEHA NARULA: Are there ways for a hard work to make life 01:04:00.090 --> 01:04:02.250 really difficult for the smaller chain? 01:04:02.250 --> 01:04:03.450 That is a good question. 01:04:03.450 --> 01:04:04.385 I think it depends. 01:04:08.840 --> 01:04:11.180 So there's multiple ways to make life difficult. 01:04:11.180 --> 01:04:14.220 I think what you're asking is not, 01:04:14.220 --> 01:04:17.085 what if the hard fork becomes more popular and more people 01:04:17.085 --> 01:04:19.460 decide to move over to it, and abandon the smaller chain? 01:04:19.460 --> 01:04:22.279 That's one way in which life could be more difficult. 01:04:22.279 --> 01:04:24.590 But another way that life could be more difficult 01:04:24.590 --> 01:04:29.690 is if the hard fork somehow made the previous chain no longer 01:04:29.690 --> 01:04:33.240 a productive chain to be on. 01:04:33.240 --> 01:04:37.760 And I think that the primary way that that would happen 01:04:37.760 --> 01:04:39.680 would not actually be a hard fork, 01:04:39.680 --> 01:04:42.860 but would be a combination hard fork, soft fork. 01:04:42.860 --> 01:04:46.430 But there are definitely ways for miners 01:04:46.430 --> 01:04:51.410 to play with hard forks and soft forks in such a way that-- see, 01:04:51.410 --> 01:04:54.260 this is actually kind of ideal in some ways. 01:04:54.260 --> 01:04:58.182 This is like, OK, we disagree on what the rules should be. 01:04:58.182 --> 01:04:59.390 I want some new set of rules. 01:04:59.390 --> 01:05:01.220 You don't want some new set of rules. 01:05:01.220 --> 01:05:03.380 Fine, let's just split the ecosystem. 01:05:03.380 --> 01:05:05.330 You guys go your way. 01:05:05.330 --> 01:05:06.500 I'll go my way. 01:05:06.500 --> 01:05:08.570 We'll have two different coins. 01:05:08.570 --> 01:05:10.670 Life will be great. 01:05:10.670 --> 01:05:13.100 What's kind of not so nice is when 01:05:13.100 --> 01:05:17.240 one side tries to coerce the other side to go along, 01:05:17.240 --> 01:05:20.810 which is kind of what a greater than 50% soft fork is. 01:05:20.810 --> 01:05:22.820 You're kind of coercing the other side 01:05:22.820 --> 01:05:28.270 to go along, because they have no way of opting out. 01:05:28.270 --> 01:05:33.610 And there are ways that miners can make the side of the chain 01:05:33.610 --> 01:05:37.420 with less harsh power basically useless. 01:05:40.270 --> 01:05:42.190 This is totally something miners can do. 01:05:42.190 --> 01:05:44.020 People talk about it occasionally. 01:05:44.020 --> 01:05:45.970 It just doesn't seem like they figured out 01:05:45.970 --> 01:05:48.338 that they can do it, or they haven't tried to do it. 01:05:48.338 --> 01:05:48.880 I don't know. 01:05:48.880 --> 01:05:49.750 Maybe they don't want to do it. 01:05:49.750 --> 01:05:50.350 I'm not sure. 01:05:50.350 --> 01:05:52.613 It would be pretty disruptive to the ecosystem. 01:05:56.320 --> 01:06:00.610 OK, so question-- we've talked about what happens here 01:06:00.610 --> 01:06:02.620 from the perspective of full nodes, 01:06:02.620 --> 01:06:05.230 and from the perspective of miners. 01:06:05.230 --> 01:06:07.120 What happens from the perspective of people 01:06:07.120 --> 01:06:09.170 with wallets who might be running SPV? 01:06:14.122 --> 01:06:14.830 What do we think? 01:06:17.770 --> 01:06:21.950 Depends on which node they're connected to. 01:06:21.950 --> 01:06:27.750 So one problem with SPV is that they don't actually 01:06:27.750 --> 01:06:29.880 get the blocks. 01:06:29.880 --> 01:06:32.340 So they don't actually validate blocks. 01:06:32.340 --> 01:06:36.060 All they validate is proof of work. 01:06:36.060 --> 01:06:38.310 Some changes that make a block invalid 01:06:38.310 --> 01:06:41.940 might show up in the header. 01:06:41.940 --> 01:06:44.880 But a lot of changes that might make a block invalid, 01:06:44.880 --> 01:06:49.184 or new blocks valid, don't show up in the header. 01:06:52.140 --> 01:06:55.680 So given what we've learned about how SPV works, 01:06:55.680 --> 01:06:59.750 what happens when there's a fork? 01:06:59.750 --> 01:07:03.710 So let's go back and take a look at what SPV wallets see. 01:07:03.710 --> 01:07:04.880 They see the block headers. 01:07:04.880 --> 01:07:06.770 You have to download all the headers, which 01:07:06.770 --> 01:07:10.340 includes the nines for the proof of work, 01:07:10.340 --> 01:07:12.620 the Merkle root for the transaction, timestamp, 01:07:12.620 --> 01:07:13.910 stuff like that. 01:07:13.910 --> 01:07:16.820 They also get Merkle paths for the transactions 01:07:16.820 --> 01:07:19.880 that they've told the node they're interested in. 01:07:23.010 --> 01:07:25.950 So what would happen if there were a soft work or hard fork? 01:07:25.950 --> 01:07:28.035 What would happen to an SPV? 01:07:33.840 --> 01:07:36.430 They don't really have a say in the situation. 01:07:36.430 --> 01:07:39.570 They aren't really participating in validation. 01:07:39.570 --> 01:07:42.270 They're not participating in mining. 01:07:42.270 --> 01:07:45.240 And they're kind of at the mercy of whatever 01:07:45.240 --> 01:07:48.900 node that they are talking to. 01:07:48.900 --> 01:07:51.120 And, in fact, if they try to talk to multiple nodes, 01:07:51.120 --> 01:07:53.220 they might get multiple different answers. 01:07:53.220 --> 01:07:57.279 And they don't really know which answer is the right answer. 01:07:57.279 --> 01:08:01.180 And this could get really tricky and complicated. 01:08:01.180 --> 01:08:03.570 Now, I think probably it's fair to say 01:08:03.570 --> 01:08:07.140 that the majority of the Bitcoin ecosystem, in terms of users, 01:08:07.140 --> 01:08:10.590 actually does not run their own full nodes. 01:08:10.590 --> 01:08:13.590 They interact with the Bitcoin network, 01:08:13.590 --> 01:08:17.220 at best, through SPV, and at worst through a trusted 01:08:17.220 --> 01:08:19.740 third party like Coinbase. 01:08:19.740 --> 01:08:24.600 So what does the ecosystem have to say or do about 01:08:24.600 --> 01:08:27.300 whether or not forks are accepted or not accepted? 01:08:35.920 --> 01:08:36.420 Yeah? 01:08:36.420 --> 01:08:37.880 AUDIENCE: They don't really have to. 01:08:37.880 --> 01:08:39.630 NEHA NARULA: They don't really have a say. 01:08:39.630 --> 01:08:44.000 They kind of I would say at like a meta level, in that users 01:08:44.000 --> 01:08:48.559 can pressure Coinbase to start following Bitcoin Cash which 01:08:48.559 --> 01:08:50.660 is a hard fork of bitcoin. 01:08:50.660 --> 01:08:54.080 They kind of have a say at an economic level, 01:08:54.080 --> 01:08:58.160 in that if Coinbase starts accepting Bitcoin Cash, 01:08:58.160 --> 01:09:00.140 then the price of Bitcoin Cash will go up. 01:09:00.140 --> 01:09:02.040 And so that's kind of a big deal. 01:09:02.040 --> 01:09:04.130 But in terms of like a protocol level, 01:09:04.130 --> 01:09:09.290 in terms of accepting or rejecting transactions, 01:09:09.290 --> 01:09:11.450 they don't really have a say because they 01:09:11.450 --> 01:09:17.165 can't see enough to determine whether or not 01:09:17.165 --> 01:09:19.790 they're interested in following a fork or not following a fork. 01:09:19.790 --> 01:09:22.010 In fact, it's even worse than that. 01:09:22.010 --> 01:09:23.510 There were multiple situations where 01:09:23.510 --> 01:09:25.880 we ended up with two chains. 01:09:25.880 --> 01:09:29.899 So an SPV wallet might think that they received money 01:09:29.899 --> 01:09:32.270 on one chain, and they didn't receive money 01:09:32.270 --> 01:09:34.840 on the other chain. 01:09:34.840 --> 01:09:41.200 So very bad things can happen to wallets and to SPV clients 01:09:41.200 --> 01:09:42.160 during a fork. 01:09:42.160 --> 01:09:45.309 And it's incredibly disruptive. 01:09:45.309 --> 01:09:50.240 And people who create software on the behalf of users-- 01:09:50.240 --> 01:09:52.359 so not even running SPV, but like the Coinbase's 01:09:52.359 --> 01:09:54.950 of the world, and the exchanges of the world-- 01:09:54.950 --> 01:09:57.130 they have to do a fair amount of work 01:09:57.130 --> 01:10:02.770 to make sure that they aren't going to lose users' money when 01:10:02.770 --> 01:10:03.850 there's a fork. 01:10:03.850 --> 01:10:07.900 And the exchanges, and the Coinbase's of the world, 01:10:07.900 --> 01:10:09.840 have screwed this up in the past. 01:10:09.840 --> 01:10:13.330 There's been money lost. 01:10:13.330 --> 01:10:16.420 There are ways to safely design your fork 01:10:16.420 --> 01:10:18.850 so that it's less likely that wallets 01:10:18.850 --> 01:10:21.970 will do the wrong thing. 01:10:21.970 --> 01:10:24.400 But I think we're kind of just figuring out how 01:10:24.400 --> 01:10:26.260 to really do that effectively. 01:10:26.260 --> 01:10:28.055 AUDIENCE: [INAUDIBLE] 01:10:37.780 --> 01:10:40.270 NEHA NARULA: Yeah, so this is kind of pretty bad, 01:10:40.270 --> 01:10:42.970 because if Bitcoin is really going 01:10:42.970 --> 01:10:44.480 to undergo a hard fork or soft fork, 01:10:44.480 --> 01:10:45.730 everybody is paying attention. 01:10:45.730 --> 01:10:48.188 If Ethereum is going to do it, everyone's paying attention. 01:10:48.188 --> 01:10:50.110 But there's so many altcoins out there. 01:10:50.110 --> 01:10:52.720 And, yeah, there's so much opportunity 01:10:52.720 --> 01:10:55.030 for people to take advantage of the disarray that 01:10:55.030 --> 01:10:57.340 happens when a fork happens. 01:10:57.340 --> 01:11:00.940 So I think we're right in the middle of trying to figure out 01:11:00.940 --> 01:11:06.880 best practices for handling forks safely, and also, 01:11:06.880 --> 01:11:11.260 giving users some way of choosing what side of a fork 01:11:11.260 --> 01:11:16.150 that they want, because there's this sort of thought 01:11:16.150 --> 01:11:21.340 that eventually there will be economic pressure to-- 01:11:21.340 --> 01:11:25.360 for a long time, people thought that if Bitcoin hard forked, 01:11:25.360 --> 01:11:28.750 one side would win, and the other side would go to zero. 01:11:28.750 --> 01:11:32.050 And now, we've seen that that is absolutely not true. 01:11:32.050 --> 01:11:34.570 In fact, when Bitcoin hard forked, 01:11:34.570 --> 01:11:38.410 sometimes the total market cap of one side plus the other side 01:11:38.410 --> 01:11:41.440 is bigger than the total market cap of what Bitcoin used to be. 01:11:41.440 --> 01:11:44.140 So money is literally created out of nowhere. 01:11:44.140 --> 01:11:46.780 So hard forking is very lucrative. 01:11:46.780 --> 01:11:49.880 It literally gives every Bitcoin user more money. 01:11:49.880 --> 01:11:53.440 So if you own Bitcoin within the past-- 01:11:53.440 --> 01:11:55.570 like, if you owned Bitcoin a year ago, 01:11:55.570 --> 01:11:58.628 you probably have like four other coins right now. 01:11:58.628 --> 01:11:59.170 I don't know. 01:11:59.170 --> 01:12:01.293 You should go sell them, or sell the Bitcoin, 01:12:01.293 --> 01:12:03.460 and buy the other coins, or whatever you want to do. 01:12:03.460 --> 01:12:05.080 But the point is, you have more money 01:12:05.080 --> 01:12:07.160 than you might have even known that you had, 01:12:07.160 --> 01:12:09.309 because someone has done these forks. 01:12:09.309 --> 01:12:11.320 Don't even like get started about the tax 01:12:11.320 --> 01:12:12.390 consequences of this. 01:12:12.390 --> 01:12:14.552 It's very confusing, extraordinarily confusing. 01:12:14.552 --> 01:12:16.510 And people are trying to figure out what to do, 01:12:16.510 --> 01:12:18.530 because you didn't ask for this fork. 01:12:18.530 --> 01:12:20.590 Like, I as a holder of Bitcoin, didn't 01:12:20.590 --> 01:12:24.370 decide that I wanted Bitcoin Cash to be a thing. 01:12:24.370 --> 01:12:26.500 I didn't accept Bitcoin Cash. 01:12:26.500 --> 01:12:29.710 But now, the same private keys I used to control my Bitcoin also 01:12:29.710 --> 01:12:32.340 control the same amount of Bitcoin Cash. 01:12:32.340 --> 01:12:33.430 It's kind of crazy. 01:12:33.430 --> 01:12:35.559 Let's talk about forks in practice. 01:12:35.559 --> 01:12:37.052 So soft forks in practice-- there 01:12:37.052 --> 01:12:38.260 have been lots of soft forks. 01:12:38.260 --> 01:12:39.340 Soft forks are very useful. 01:12:39.340 --> 01:12:40.340 Soft forks are helpful. 01:12:40.340 --> 01:12:42.652 This is the major way that people upgrade software. 01:12:42.652 --> 01:12:44.110 And, again, the way that they do it 01:12:44.110 --> 01:12:46.870 is they try to make sure 95%, or some huge majority 01:12:46.870 --> 01:12:48.130 of the miners, are on board. 01:12:48.130 --> 01:12:50.740 And that way, it's sort of like as non-disruptive 01:12:50.740 --> 01:12:52.880 to the ecosystem as possible. 01:12:52.880 --> 01:12:55.830 So pay to script has was a soft fork. 01:12:55.830 --> 01:12:57.830 The introduction of Segwit was a soft fork. 01:12:57.830 --> 01:12:59.740 In operation, check sequence verify 01:12:59.740 --> 01:13:02.150 was added as a soft fork. 01:13:02.150 --> 01:13:04.750 So that's kind of why they're all these like unused ops 01:13:04.750 --> 01:13:05.680 out there. 01:13:05.680 --> 01:13:09.820 In case we want to use one of them for something new, 01:13:09.820 --> 01:13:12.760 we can do that with a soft fork. 01:13:12.760 --> 01:13:15.340 Hard forks in practice-- 01:13:15.340 --> 01:13:19.370 there's lots of new Bitcoins, Bitcoin Cash, Gold, Diamond, 01:13:19.370 --> 01:13:20.500 like I said. 01:13:20.500 --> 01:13:23.582 Ethereum went through a really interesting hard fork. 01:13:23.582 --> 01:13:25.540 And there's some cryptocurrencies that actually 01:13:25.540 --> 01:13:27.445 hard fork quite frequently. 01:13:27.445 --> 01:13:29.320 For instance, I learned the Monero hard forks 01:13:29.320 --> 01:13:30.330 about every six months. 01:13:30.330 --> 01:13:33.120 Vertcoin, how many hard forks have you guys done? 01:13:33.120 --> 01:13:33.840 Three? 01:13:33.840 --> 01:13:35.350 Three hard forks. 01:13:35.350 --> 01:13:39.640 So, despite the way that I said that hard forks are 01:13:39.640 --> 01:13:44.620 very disruptive, if you can get all the nodes to upgrade, 01:13:44.620 --> 01:13:46.150 it's not really a big problem. 01:13:46.150 --> 01:13:48.850 So for cryptocurrencies where the nodes are really well 01:13:48.850 --> 01:13:52.180 connected, or they auto update, or things like that, 01:13:52.180 --> 01:13:55.540 hard forks are much less disruptive. 01:13:55.540 --> 01:13:59.540 So let's talk about the Ethereum hard fork for a moment. 01:13:59.540 --> 01:14:03.640 So this happened two years ago-- 01:14:03.640 --> 01:14:04.335 a year ago? 01:14:04.335 --> 01:14:06.460 I can't remember when this happened, two years ago, 01:14:06.460 --> 01:14:08.800 I think, almost. 01:14:08.800 --> 01:14:11.148 And so what happened was we haven't 01:14:11.148 --> 01:14:12.690 talked a lot about Ethereum, so we'll 01:14:12.690 --> 01:14:15.110 be coming to explain Ethereum in much greater detail. 01:14:15.110 --> 01:14:18.220 But the point is Ethereum had a smart contract 01:14:18.220 --> 01:14:19.280 which had a bug in it. 01:14:22.510 --> 01:14:26.920 And someone hacked the contract, and started siphoning off ether 01:14:26.920 --> 01:14:28.900 from the contract. 01:14:28.900 --> 01:14:32.450 So the Ethereum team all got together, and decided, 01:14:32.450 --> 01:14:34.950 we're going to rectify this wrong. 01:14:34.950 --> 01:14:36.103 Now, rectifying the wrong-- 01:14:36.103 --> 01:14:37.770 I mean, I already said it's a hard fork. 01:14:37.770 --> 01:14:44.250 But why is rectifying this wrong a hard fork not a soft fork? 01:14:44.250 --> 01:14:47.110 AUDIENCE: Because you want to change history. 01:14:47.110 --> 01:14:49.620 NEHA NARULA: Because you want to change history. 01:14:49.620 --> 01:14:51.690 That's an interesting way of putting it. 01:14:51.690 --> 01:14:53.160 And the way that we change history 01:14:53.160 --> 01:14:56.490 is not by actually going back in time and editing history, 01:14:56.490 --> 01:14:58.290 unless you are Accenture I guess, 01:14:58.290 --> 01:15:00.090 which creates editable blockchains. 01:15:00.090 --> 01:15:02.160 But the way that we edit history, 01:15:02.160 --> 01:15:05.130 is we add something to the blockchain which 01:15:05.130 --> 01:15:08.760 indicates that we're going to undo, or change, or rollback 01:15:08.760 --> 01:15:12.360 or somehow create an operation, that 01:15:12.360 --> 01:15:14.100 does something that effectively undoes 01:15:14.100 --> 01:15:15.390 what happened in the past. 01:15:20.330 --> 01:15:22.309 So the Ethereum developer got together. 01:15:22.309 --> 01:15:26.210 And they originally tried to do this as a soft fork, actually. 01:15:26.210 --> 01:15:28.640 So it could have been a soft fork. 01:15:28.640 --> 01:15:30.680 And the way that the soft work would have worked 01:15:30.680 --> 01:15:32.900 is that it just would have ignored 01:15:32.900 --> 01:15:39.045 all of the transactions that were sort of-- 01:15:39.045 --> 01:15:40.670 I can't remember exactly how it worked. 01:15:40.670 --> 01:15:42.950 But, basically, the general idea was, ignore 01:15:42.950 --> 01:15:48.440 all of the transactions that might spend the hacker's money. 01:15:48.440 --> 01:15:52.070 Ignore the transaction where people gave money 01:15:52.070 --> 01:15:55.670 to the hacker, what ultimately became the hacker, which 01:15:55.670 --> 01:15:56.960 is a new rule. 01:15:56.960 --> 01:15:59.300 Now, you're shrinking the set of acceptable blocks. 01:15:59.300 --> 01:16:01.160 And the problem was they realized 01:16:01.160 --> 01:16:03.680 that if they did this as a soft fork, then 01:16:03.680 --> 01:16:06.740 they were inadvertently creating an attack 01:16:06.740 --> 01:16:11.030 vector, because people could now spam the network 01:16:11.030 --> 01:16:13.670 and potentially waste the resources of the miners-- 01:16:13.670 --> 01:16:16.160 very challenging to do soft forks and hard forks correctly. 01:16:16.160 --> 01:16:17.750 So they decided, OK, you know what? 01:16:17.750 --> 01:16:20.180 We're just going to do it as a hard fork. 01:16:20.180 --> 01:16:25.230 When this block comes about, block 1,920,000, 01:16:25.230 --> 01:16:29.840 we are going to simply transfer around 12 million 01:16:29.840 --> 01:16:35.152 either from the hacker's account into this other account, 01:16:35.152 --> 01:16:37.610 this other contract, which is going to give the money back, 01:16:37.610 --> 01:16:40.630 where people can reclaim their money. 01:16:40.630 --> 01:16:45.070 So literally just hardcoded in this transfer. 01:16:45.070 --> 01:16:50.620 85% of the hash power in Ethereum went along with it. 01:16:50.620 --> 01:16:53.080 So that means 15% didn't. 01:16:53.080 --> 01:16:55.420 And that means that there are two currencies now. 01:16:55.420 --> 01:16:58.390 There is Ethereum, and Ethereum Classic. 01:16:58.390 --> 01:17:01.900 And they persist to this day, almost two years later. 01:17:01.900 --> 01:17:05.230 And when I looked this morning, it was about a 30 to 1 01:17:05.230 --> 01:17:08.020 ratio between Ethereum and Ethereum Classic. 01:17:08.020 --> 01:17:08.910 Yes? 01:17:08.910 --> 01:17:10.368 AUDIENCE: So Ethereum Classic says, 01:17:10.368 --> 01:17:13.422 we are not OK with you guys undoing this hack. 01:17:13.422 --> 01:17:15.130 NEHA NARULA: Exactly, so Ethereum Classic 01:17:15.130 --> 01:17:17.800 says, we're not messing with people's accounts like that. 01:17:17.800 --> 01:17:19.180 No, no, no. 01:17:19.180 --> 01:17:21.370 What happened happened, fair and square. 01:17:21.370 --> 01:17:24.340 We are not changing history. 01:17:24.340 --> 01:17:27.277 And so in Ethereum Classic, the hacker has money. 01:17:27.277 --> 01:17:29.110 On Ethereum, the hacker does not have money. 01:17:31.940 --> 01:17:32.623 Yes? 01:17:32.623 --> 01:17:37.390 AUDIENCE: [INAUDIBLE] one specific contract. 01:17:37.390 --> 01:17:40.750 So the argument is we shouldn't be fixing people's mistakes. 01:17:40.750 --> 01:17:42.630 They should learn-- 01:17:42.630 --> 01:17:45.480 Was this analogous to the Parity? 01:17:45.480 --> 01:17:47.900 NEHA NARULA: Yes. 01:17:47.900 --> 01:17:50.570 So here they decided, there was a bug 01:17:50.570 --> 01:17:52.220 in someone's smart contract. 01:17:52.220 --> 01:17:53.517 It was exploited. 01:17:53.517 --> 01:17:55.350 We're going to give people their money back. 01:17:55.350 --> 01:17:57.680 This happened again with a different type 01:17:57.680 --> 01:18:01.160 of smart contract in a different way a couple months ago. 01:18:01.160 --> 01:18:05.570 And they decided-- well, they could still decide to do it. 01:18:05.570 --> 01:18:08.390 But so far, they decided not to give everyone's money back. 01:18:08.390 --> 01:18:10.520 So there's about 90 million or something dollars 01:18:10.520 --> 01:18:13.820 worth of ether that's locked up in these contracts, 01:18:13.820 --> 01:18:15.500 due to a bug. 01:18:15.500 --> 01:18:18.410 And in the case of the DAO, they decided, let's do it. 01:18:18.410 --> 01:18:23.610 In the case of this Parity bug, they decided, let's not do it. 01:18:23.610 --> 01:18:26.570 And if you talk to the Ethereum Foundation people, 01:18:26.570 --> 01:18:28.160 they'll talk about governance. 01:18:28.160 --> 01:18:30.980 And they'll say, well, we feel like this made sense 01:18:30.980 --> 01:18:31.790 for these reasons. 01:18:31.790 --> 01:18:33.707 But this doesn't make sense for these reasons. 01:18:33.707 --> 01:18:35.867 But it's still it's a set of people 01:18:35.867 --> 01:18:37.700 getting together and deciding whether or not 01:18:37.700 --> 01:18:38.559 to give money back. 01:18:38.559 --> 01:18:40.850 Yeah? 01:18:40.850 --> 01:18:41.980 AUDIENCE: [INAUDIBLE] 01:18:44.747 --> 01:18:46.830 NEHA NARULA: No, it's not the Ethereum Foundation. 01:18:46.830 --> 01:18:49.220 The Ethereum Foundation was not a fan of Ethereum Classic. 01:18:49.220 --> 01:18:50.270 It's a separate group of people. 01:18:50.270 --> 01:18:51.200 AUDIENCE: [INAUDIBLE] 01:18:52.700 --> 01:18:55.535 NEHA NARULA: No, actually, so it turned out, 01:18:55.535 --> 01:18:57.410 interestingly enough-- and this was something 01:18:57.410 --> 01:18:59.750 that I saw at a conference that looked 01:18:59.750 --> 01:19:01.688 into who were the contributors to all 01:19:01.688 --> 01:19:03.230 of these different forks, when trying 01:19:03.230 --> 01:19:04.190 to understand governance? 01:19:04.190 --> 01:19:06.315 It actually turns out that no one from the Ethereum 01:19:06.315 --> 01:19:08.210 Foundation works on Ethereum Classic. 01:19:08.210 --> 01:19:10.250 And no one who used to work on Bitcoin 01:19:10.250 --> 01:19:12.860 works on Bitcoin Cash, Gold, or Diamond. 01:19:12.860 --> 01:19:15.180 So it's entirely new sets of people. 01:19:15.180 --> 01:19:15.680 Yes? 01:19:15.680 --> 01:19:18.680 AUDIENCE: The former lead developer of Bitcoin core 01:19:18.680 --> 01:19:21.490 is working on Bitcoin Cash. 01:19:21.490 --> 01:19:23.120 NEHA NARULA: He's not actually. 01:19:23.120 --> 01:19:25.250 You're talking about Gavin Andreessen? 01:19:25.250 --> 01:19:28.443 Yeah, I don't think he actually makes commits to Bitcoin Cash. 01:19:28.443 --> 01:19:30.260 AUDIENCE: In a general sense, he's 01:19:30.260 --> 01:19:32.530 contributing on GitHub, not specifically 01:19:32.530 --> 01:19:33.980 to any implementations. 01:19:33.980 --> 01:19:37.648 But to protocol, block-level exchanges. 01:19:37.648 --> 01:19:38.690 NEHA NARULA: Interesting. 01:19:38.690 --> 01:19:39.200 Yes? 01:19:39.200 --> 01:19:40.190 AUDIENCE: [INAUDIBLE] 01:19:44.983 --> 01:19:46.400 NEHA NARULA: It depends on how you 01:19:46.400 --> 01:19:48.050 define contribute, certainly. 01:19:48.050 --> 01:19:51.260 This is a really interesting example of a hard fork. 01:19:51.260 --> 01:19:54.500 In summary, just to wrap up here, 01:19:54.500 --> 01:19:56.510 forks are extremely challenging. 01:19:56.510 --> 01:20:00.620 Upgrading software in decentralized cryptocurrencies 01:20:00.620 --> 01:20:03.030 is extremely challenging. 01:20:03.030 --> 01:20:05.510 And so the lesson that I want you to take from this is, 01:20:05.510 --> 01:20:08.210 unless you need what a decentralized cryptocurrency 01:20:08.210 --> 01:20:12.530 has to offer, you will probably be better off not using 01:20:12.530 --> 01:20:13.890 a decentralized cryptocurrency. 01:20:13.890 --> 01:20:15.140 They are very hard to update. 01:20:15.140 --> 01:20:16.580 They're very hard to upgrade. 01:20:16.580 --> 01:20:18.680 There are frequently bugs. 01:20:18.680 --> 01:20:22.490 And so I think that forks and the challenges around forks 01:20:22.490 --> 01:20:28.880 are an excellent reason not to do this when you don't have to. 01:20:28.880 --> 01:20:31.160 And also, what's really interesting, I think, 01:20:31.160 --> 01:20:35.059 is that your traditional consensus systems 01:20:35.059 --> 01:20:37.130 don't address this problem at all, 01:20:37.130 --> 01:20:40.160 because your traditional distributed consensus 01:20:40.160 --> 01:20:42.740 systems don't have any notion of what nodes 01:20:42.740 --> 01:20:44.390 are going to find valid, or not valid, 01:20:44.390 --> 01:20:46.045 or changing the rules of validity. 01:20:46.045 --> 01:20:47.420 And so these problems really only 01:20:47.420 --> 01:20:50.090 arise when you start to have these validity 01:20:50.090 --> 01:20:52.070 rules that you're dealing with, and you 01:20:52.070 --> 01:20:53.952 have nodes that might take one set of rules, 01:20:53.952 --> 01:20:55.910 and nodes that might take another set of rules. 01:20:55.910 --> 01:20:58.460 The consensus mechanism here ultimately 01:20:58.460 --> 01:21:01.580 becomes irrelevant if you don't agree with the validity 01:21:01.580 --> 01:21:02.210 of the blocks. 01:21:02.210 --> 01:21:05.270 It doesn't matter that a majority of hash power 01:21:05.270 --> 01:21:07.120 said that this is the blockchain. 01:21:07.120 --> 01:21:08.870 It doesn't matter if a majority of signers 01:21:08.870 --> 01:21:10.052 say this is the blockchain. 01:21:10.052 --> 01:21:12.260 If you don't agree that the things in that blockchain 01:21:12.260 --> 01:21:14.030 are valid, you're going to ignore that. 01:21:14.030 --> 01:21:14.990 Majority be damned. 01:21:14.990 --> 01:21:19.270 So it's very different than distributed consensus. 01:21:19.270 --> 01:21:22.059 Okay, and so real quick, last thing... 01:21:22.059 --> 01:21:26.200 on Wednesday we will have another guest lecturer. Her name is Sharon Goldberg. 01:21:26.200 --> 01:21:29.080 She's a professor at Boston University and she's worked on a lot of really 01:21:29.080 --> 01:21:32.590 interesting things. In particular, something really cool that she's worked 01:21:32.590 --> 01:21:37.840 on is using the peer-to-peer network to create attacks in Bitcoin, and then very 01:21:37.840 --> 01:21:41.800 recently she nor co-authors released a paper on peer-to-peer network attacks in 01:21:41.800 --> 01:21:44.920 Ethereum. And so she's gonna be here to talk about the peer-to-peer networks 01:21:44.920 --> 01:21:51.000 behind these things and to share some of the research that she's done.