1 00:00:00,850 --> 00:00:03,220 The following content is provided under a Creative 2 00:00:03,220 --> 00:00:04,610 Commons license. 3 00:00:04,610 --> 00:00:06,820 Your support will help MIT OpenCourseWare 4 00:00:06,820 --> 00:00:10,910 continue to offer high-quality educational resources for free. 5 00:00:10,910 --> 00:00:13,480 To make a donation, or to view additional materials 6 00:00:13,480 --> 00:00:17,440 from hundreds of MIT courses, visit MIT OpenCourseWare 7 00:00:17,440 --> 00:00:18,313 at ocw.mit.edu. 8 00:00:21,997 --> 00:00:22,580 PROFESSOR: OK. 9 00:00:22,580 --> 00:00:24,905 So yeah, problem set 2. 10 00:00:24,905 --> 00:00:26,030 There's a lot of work done. 11 00:00:26,030 --> 00:00:27,520 Congratulations, all the workers. 12 00:00:27,520 --> 00:00:29,810 16 trillion hashes performed. 13 00:00:29,810 --> 00:00:32,600 How can we prove that? 14 00:00:32,600 --> 00:00:37,730 So this is a personal gripe that I hear a lot. 15 00:00:37,730 --> 00:00:40,390 That people say that proof of work doesn't scale. 16 00:00:40,390 --> 00:00:44,570 And that really bugs me because sometimes I 17 00:00:44,570 --> 00:00:46,570 think I sort of know what they're talking about, 18 00:00:46,570 --> 00:00:48,695 and they mean like, bitcoin doesn't scale, or like, 19 00:00:48,695 --> 00:00:51,620 these block chains have poor scalability properties, 20 00:00:51,620 --> 00:00:52,430 which sure, sure. 21 00:00:52,430 --> 00:00:53,600 They definitely do. 22 00:00:53,600 --> 00:00:57,110 But proof of work, it scales perfectly, 23 00:00:57,110 --> 00:00:58,460 in a theoretical sense. 24 00:00:58,460 --> 00:01:00,740 There's nothing that can scale better. 25 00:01:00,740 --> 00:01:04,410 You can prove an arbitrary amount of work in 0 of 1. 26 00:01:04,410 --> 00:01:04,910 Right? 27 00:01:04,910 --> 00:01:08,330 So in this case, well, how big were these headers? 28 00:01:08,330 --> 00:01:09,890 They were less than 100 bytes, right? 29 00:01:09,890 --> 00:01:11,330 100 characters. 30 00:01:11,330 --> 00:01:13,880 And with that space, you can prove actually 31 00:01:13,880 --> 00:01:18,240 the entire work that happened over the entire problem set. 32 00:01:18,240 --> 00:01:18,740 So yeah. 33 00:01:18,740 --> 00:01:20,970 block chains, whole bunch of scalability problems. 34 00:01:20,970 --> 00:01:23,900 There's complex systems, all sorts of scaling issues. 35 00:01:23,900 --> 00:01:27,390 But proven work itself, in this pure form, scales really great. 36 00:01:27,390 --> 00:01:27,890 OK. 37 00:01:27,890 --> 00:01:29,900 So question. 38 00:01:29,900 --> 00:01:31,473 Not super intuitive, but how do you 39 00:01:31,473 --> 00:01:33,890 prove all the work ever done throughout the entire problem 40 00:01:33,890 --> 00:01:35,410 set in one line? 41 00:01:37,990 --> 00:01:43,970 Does anyone have any intuition about this 42 00:01:43,970 --> 00:01:48,470 how do you prove all the work from all 1,800 blocks with just 43 00:01:48,470 --> 00:01:51,510 one piece of data? 44 00:01:51,510 --> 00:01:55,550 AUDIENCE: Well you know that for each block, 2 to 33, 45 00:01:55,550 --> 00:01:56,930 work had to go into it. 46 00:01:56,930 --> 00:01:59,600 So you just need to know the number 47 00:01:59,600 --> 00:02:03,080 of blocks produced times the-- 48 00:02:03,080 --> 00:02:03,710 PROFESSOR: OK. 49 00:02:03,710 --> 00:02:08,270 Yeah, so the thing is how do I prove the number of blocks 50 00:02:08,270 --> 00:02:11,140 without showing all of them, right? 51 00:02:11,140 --> 00:02:14,800 So OK, it's a weird trick question. 52 00:02:14,800 --> 00:02:16,320 Andrew-- I think-- 53 00:02:16,320 --> 00:02:19,770 I remember Andrew Miller, who's now a professor at somewhere, 54 00:02:19,770 --> 00:02:21,180 Cornell? 55 00:02:21,180 --> 00:02:24,600 Who was not, during the time, wrote about this initially 56 00:02:24,600 --> 00:02:26,250 in the bitcoin forums. 57 00:02:26,250 --> 00:02:28,520 What you do is you just show the luckiest block, 58 00:02:28,520 --> 00:02:30,270 and I have not yet defined luckiest block. 59 00:02:30,270 --> 00:02:37,140 But in this case, it was mined by turtle. 60 00:02:37,140 --> 00:02:40,650 This is the block, the previous block reference was of 0065a2 61 00:02:40,650 --> 00:02:48,900 turtle 1654244 and the hash of that block is 000c49a414 blah, 62 00:02:48,900 --> 00:02:49,770 blah, blah. 63 00:02:49,770 --> 00:02:53,700 So anything interesting or novel about this particular block 64 00:02:53,700 --> 00:02:55,210 that you can see? 65 00:02:55,210 --> 00:02:55,710 It's not-- 66 00:02:55,710 --> 00:02:56,670 AUDIENCE: [INAUDIBLE] 67 00:02:56,670 --> 00:02:56,880 PROFESSOR: What? 68 00:02:56,880 --> 00:02:58,088 AUDIENCE: It's better than... 69 00:02:58,088 --> 00:03:00,060 PROFESSOR: It's better. 70 00:03:00,060 --> 00:03:00,930 There's more work. 71 00:03:00,930 --> 00:03:03,900 So we didn't count the things as having more or less work just 72 00:03:03,900 --> 00:03:05,190 by a sum number of zeros. 73 00:03:05,190 --> 00:03:08,010 We just looked at the threshold, did it have enough 0 bits 74 00:03:08,010 --> 00:03:10,140 and accepted or rejected. 75 00:03:10,140 --> 00:03:13,490 But in this case, these 4 bytes, right? 76 00:03:13,490 --> 00:03:15,730 You needed 4 bytes and then 1 extra bit. 77 00:03:15,730 --> 00:03:16,800 You needed 33 bits. 78 00:03:16,800 --> 00:03:18,840 So these 4 are always worth 0. 79 00:03:18,840 --> 00:03:21,090 But then in c and red, there's another extra byte 80 00:03:21,090 --> 00:03:21,930 that's all 0s. 81 00:03:21,930 --> 00:03:24,150 And another extra half a byte that's all 0s. 82 00:03:24,150 --> 00:03:27,520 And then a c means for that nibble, 83 00:03:27,520 --> 00:03:30,900 that the highest bit was 1, right? 84 00:03:30,900 --> 00:03:33,300 So you've got this red stuff. 85 00:03:33,300 --> 00:03:35,720 There's a byte and a half extra-- or almost a byte 86 00:03:35,720 --> 00:03:37,240 and a half extra. 87 00:03:37,240 --> 00:03:37,740 So, yeah. 88 00:03:37,740 --> 00:03:40,610 So what you can do for a compact proof work. 89 00:03:40,610 --> 00:03:46,430 So if you look at this again, there's 4 green bytes, byte 90 00:03:46,430 --> 00:03:48,150 and a half is red, right? 91 00:03:48,150 --> 00:03:51,690 So that's 5 and 1/2 bytes, so 44 bits. 92 00:03:51,690 --> 00:03:55,300 And 2 to the 44 is 17 trillion, right, 93 00:03:55,300 --> 00:03:59,160 if you do out 17 something, which is what we expect, 94 00:03:59,160 --> 00:04:00,300 that's our proof, right? 95 00:04:00,300 --> 00:04:05,360 We did 16 trillion hashes for our calculation, 96 00:04:05,360 --> 00:04:07,200 and it shows up here. 97 00:04:07,200 --> 00:04:09,750 And another way to look at it is we needed 33 bits 98 00:04:09,750 --> 00:04:11,280 for a valid block. 99 00:04:11,280 --> 00:04:14,190 We have 44 bits here. 100 00:04:14,190 --> 00:04:15,690 That's 11 bits extra. 101 00:04:15,690 --> 00:04:19,440 That's 11 bits of being lucky. 102 00:04:19,440 --> 00:04:22,660 And so that's 11 bits to the 11, that's 103 00:04:22,660 --> 00:04:26,813 2,048, which is pretty close to the 1,862 104 00:04:26,813 --> 00:04:28,230 that we actually performed, right? 105 00:04:28,230 --> 00:04:30,083 So in this case, we're a little lucky. 106 00:04:30,083 --> 00:04:31,500 We might have only had 2 of the 10 107 00:04:31,500 --> 00:04:33,083 and then we could only prove that we'd 108 00:04:33,083 --> 00:04:36,590 done like 8 trillion work instead of 16 trillion work. 109 00:04:36,590 --> 00:04:41,735 So there's probabilities here, but this 110 00:04:41,735 --> 00:04:43,860 is an interesting property that actually does work. 111 00:04:43,860 --> 00:04:47,420 You can prove all the work, to some approximation usually 112 00:04:47,420 --> 00:04:50,330 within a factor of 2, that the system has ever 113 00:04:50,330 --> 00:04:53,000 done just with 1 block header. 114 00:04:53,000 --> 00:04:53,560 So, yeah. 115 00:04:53,560 --> 00:04:56,240 This is fun because another way to look 116 00:04:56,240 --> 00:04:59,780 at it is that you've got this metagame, 117 00:04:59,780 --> 00:05:05,930 where for every block found, take the, I'm doing a hash 118 00:05:05,930 --> 00:05:08,690 and I need to find a hash with a lot of 0s 119 00:05:08,690 --> 00:05:10,010 to prove that I've done work. 120 00:05:10,010 --> 00:05:13,700 And you go a level deeper and say, OK, I'm finding a block. 121 00:05:13,700 --> 00:05:15,980 And I want to prove that I found an even better block 122 00:05:15,980 --> 00:05:17,080 than everyone else, right? 123 00:05:17,080 --> 00:05:21,057 The entry for admission here is find a valid block. 124 00:05:21,057 --> 00:05:22,640 And then from those blocks, since it's 125 00:05:22,640 --> 00:05:25,940 a uniform distribution with 1s and 0s, 126 00:05:25,940 --> 00:05:28,460 you're going to have this tail-end of like, happened 127 00:05:28,460 --> 00:05:32,030 to have lots of 0s that you didn't need in the beginning. 128 00:05:32,030 --> 00:05:34,280 And that can prove all the work ever done. 129 00:05:34,280 --> 00:05:37,400 There's a really interesting paper called, HyperLogLog, 130 00:05:37,400 --> 00:05:40,190 that uses this for non-bitcoin applications 131 00:05:40,190 --> 00:05:42,487 that uses it for set counting. 132 00:05:42,487 --> 00:05:44,570 Where, like on a website, you want to see how many 133 00:05:44,570 --> 00:05:46,700 unique visitors you've gotten or something. 134 00:05:46,700 --> 00:05:50,060 And you can store that in 0 of 1 space 135 00:05:50,060 --> 00:05:51,710 because you could keep track of OK, 136 00:05:51,710 --> 00:05:54,085 let me keep track of every IP address that's ever visited 137 00:05:54,085 --> 00:05:55,550 or something like that, or cookie. 138 00:05:55,550 --> 00:05:57,500 But instead, you hash them. 139 00:05:57,500 --> 00:05:59,780 See if the hash starts with a bunch of 0s 140 00:05:59,780 --> 00:06:03,890 or any arbitrary character, and then just store the lowest. 141 00:06:03,890 --> 00:06:06,620 And then, every time someone visits, hash it, compare. 142 00:06:06,620 --> 00:06:07,940 If it's lower, replace. 143 00:06:07,940 --> 00:06:09,560 If not, ignore. 144 00:06:09,560 --> 00:06:13,190 And then you have a very compact indication 145 00:06:13,190 --> 00:06:15,630 of how many visitors have visited. 146 00:06:15,630 --> 00:06:18,695 Anyway, that's like a super high-level view of it. 147 00:06:18,695 --> 00:06:21,320 But if you're interested in this stuff, HyperLogLog is a paper. 148 00:06:21,320 --> 00:06:23,713 It builds off of some other things. 149 00:06:23,713 --> 00:06:25,130 It has nothing to do with bitcoin, 150 00:06:25,130 --> 00:06:28,220 other than this property, where you've got this random function 151 00:06:28,220 --> 00:06:30,220 and you see how many 0s are in it. 152 00:06:30,220 --> 00:06:35,010 But I think these are cool, and so to me, this is a fun-- 153 00:06:35,010 --> 00:06:36,560 this is not used in bitcoin, right? 154 00:06:36,560 --> 00:06:38,990 In bitcoin, you actually download all the headers, 155 00:06:38,990 --> 00:06:42,110 but people have written papers about how you could use it. 156 00:06:42,110 --> 00:06:47,390 If long term the headers are big, you could prove. 157 00:06:47,390 --> 00:06:48,770 Have some checkpoint, where look, 158 00:06:48,770 --> 00:06:52,650 I proved all the previous work and now I build from there. 159 00:06:52,650 --> 00:06:54,720 Any questions about this idea? 160 00:06:54,720 --> 00:06:55,523 Yes? 161 00:06:55,523 --> 00:06:56,940 AUDIENCE: It's not really a proof. 162 00:06:56,940 --> 00:06:58,315 It's just a probability weighted. 163 00:07:00,980 --> 00:07:04,080 PROFESSOR: Yes, but the proof of work itself is the same. 164 00:07:04,080 --> 00:07:07,380 Not of real proof because you might have gotten lucky. 165 00:07:07,380 --> 00:07:11,820 So finding a block, it's like, well that's not a proof. 166 00:07:11,820 --> 00:07:14,230 There could be luck involved, there could be probability, 167 00:07:14,230 --> 00:07:16,920 but it's the exact same luck and probability 168 00:07:16,920 --> 00:07:18,930 that the underlying proof of work uses. 169 00:07:18,930 --> 00:07:24,173 So there's no further reduction in security or certainty 170 00:07:24,173 --> 00:07:24,840 because of this. 171 00:07:24,840 --> 00:07:25,890 Not really. 172 00:07:25,890 --> 00:07:29,490 And so I remember talking about this with someone 173 00:07:29,490 --> 00:07:32,040 a few years ago and saying, yeah proof of work is a misnomer. 174 00:07:32,040 --> 00:07:33,720 It's not really a proof, right? 175 00:07:33,720 --> 00:07:36,960 Maybe it's an argument of work or some probabilistic argument 176 00:07:36,960 --> 00:07:37,860 of work. 177 00:07:37,860 --> 00:07:43,470 How could you make it more certain as a proof? 178 00:07:43,470 --> 00:07:44,470 There's a bunch of ways. 179 00:07:44,470 --> 00:07:47,820 One way would be to have multiple nonces, where 180 00:07:47,820 --> 00:07:50,970 instead of just finding one nonce that satisfies it, 181 00:07:50,970 --> 00:07:53,910 you have to find several replaceable nonces 182 00:07:53,910 --> 00:07:55,743 and then iterate through them. 183 00:07:55,743 --> 00:07:57,410 That would be a much more certain proof. 184 00:07:57,410 --> 00:08:00,910 It would remove the idea of probability, to some extent. 185 00:08:00,910 --> 00:08:03,330 It would also completely break the system 186 00:08:03,330 --> 00:08:05,293 in a way that's like fairly unintuitive, 187 00:08:05,293 --> 00:08:06,960 and so I always was sort of joking like, 188 00:08:06,960 --> 00:08:10,628 I should make an altcoin, where you've got multiple nonces, 189 00:08:10,628 --> 00:08:13,170 and you could be like, yes, for more security and then people 190 00:08:13,170 --> 00:08:16,230 would buy it, but it completely breaks. 191 00:08:16,230 --> 00:08:22,672 The completely broken incentives and system, maybe I'll get to-- 192 00:08:22,672 --> 00:08:24,630 I'll let you guys think about it til Wednesday, 193 00:08:24,630 --> 00:08:28,110 and then draw it out and be like, why wouldn't this work? 194 00:08:28,110 --> 00:08:29,580 It's fun. 195 00:08:29,580 --> 00:08:32,190 It breaks in subtle but bad ways. 196 00:08:32,190 --> 00:08:35,010 This is talking about proof of work optimization. 197 00:08:35,010 --> 00:08:38,490 So if you look at this slide anyway, 198 00:08:38,490 --> 00:08:41,198 you've got these headers or blocks 199 00:08:41,198 --> 00:08:42,240 or whatever we're mining. 200 00:08:42,240 --> 00:08:45,990 So you've got kezike17, tomriddle, Thalita, 201 00:08:45,990 --> 00:08:48,133 all these people mining. 202 00:08:48,133 --> 00:08:49,800 It's interesting to see what people use. 203 00:08:49,800 --> 00:08:52,380 Some people use looks like base64, 204 00:08:52,380 --> 00:08:55,290 some people just use a decimal number, 205 00:08:55,290 --> 00:08:57,720 all sorts of different things. 206 00:08:57,720 --> 00:08:58,860 Who knows. 207 00:08:58,860 --> 00:09:01,387 There was also a lot of invalid blocks 208 00:09:01,387 --> 00:09:02,970 with valid work submitted, where there 209 00:09:02,970 --> 00:09:05,762 was four or five different things in my spaces. 210 00:09:05,762 --> 00:09:07,470 So there's been count, but actually a lot 211 00:09:07,470 --> 00:09:09,780 more work was done, and that's not even 212 00:09:09,780 --> 00:09:12,610 counting the human work of doing all these assignments. 213 00:09:12,610 --> 00:09:16,500 So sending this over the wire, or storing it on disk, 214 00:09:16,500 --> 00:09:19,020 some inefficiencies may jump out at you. 215 00:09:19,020 --> 00:09:21,510 What do you think you could do to make this more efficient 216 00:09:21,510 --> 00:09:23,893 or compress it or? 217 00:09:23,893 --> 00:09:24,855 Yeah? 218 00:09:24,855 --> 00:09:26,587 AUDIENCE: [INAUDIBLE] 219 00:09:26,587 --> 00:09:27,170 PROFESSOR: OK. 220 00:09:27,170 --> 00:09:28,010 That's an easy one. 221 00:09:28,010 --> 00:09:29,870 Oh, this doesn't work when I gave you 222 00:09:29,870 --> 00:09:32,360 the slides because you can just look at the next slide. 223 00:09:32,360 --> 00:09:33,180 Whoops, OK. 224 00:09:33,180 --> 00:09:33,680 Never mind. 225 00:09:35,980 --> 00:09:37,730 Yeah, so the first 8 characters are always 226 00:09:37,730 --> 00:09:40,633 going to be 0s by definition. 227 00:09:40,633 --> 00:09:42,050 If it's not, it's an invalid block 228 00:09:42,050 --> 00:09:43,490 so don't even bother sending it. 229 00:09:43,490 --> 00:09:46,340 So the first characters are 0, don't send them over the wire. 230 00:09:46,340 --> 00:09:51,590 Just have that implied and just start at the ninth character. 231 00:09:51,590 --> 00:09:54,590 That saves, well, really you'd have the serializing binary, 232 00:09:54,590 --> 00:09:56,020 so it only saves 4 bytes. 233 00:09:56,020 --> 00:09:58,400 In our case, it would say 8 bytes. 234 00:09:58,400 --> 00:09:59,420 That's cool. 235 00:09:59,420 --> 00:10:02,030 And then, also the entire previous hash. 236 00:10:02,030 --> 00:10:05,480 When you're sending a list of 5 here, like here, in order 237 00:10:05,480 --> 00:10:08,330 for it to be valid, this has to be 238 00:10:08,330 --> 00:10:09,920 the hash of the line above it. 239 00:10:09,920 --> 00:10:12,260 So just don't send the whole thing, right? 240 00:10:12,260 --> 00:10:15,110 Just send name nonce. 241 00:10:15,110 --> 00:10:18,710 The hash is also computable from anyone receiving it. 242 00:10:18,710 --> 00:10:20,810 That takes almost all of this space 243 00:10:20,810 --> 00:10:23,540 and we could compress this entire blockchain 244 00:10:23,540 --> 00:10:26,810 to just the first line, and that's 245 00:10:26,810 --> 00:10:28,460 the only full line we need. 246 00:10:28,460 --> 00:10:30,470 After that, it's just named nonce named nonce, 247 00:10:30,470 --> 00:10:33,860 and we get rid of 70-something percent of this base. 248 00:10:33,860 --> 00:10:37,430 That's pretty cool, right? 249 00:10:37,430 --> 00:10:39,110 Yeah this kind of header optimization 250 00:10:39,110 --> 00:10:41,570 is also very much possible in bitcoin, 251 00:10:41,570 --> 00:10:42,830 and it's not implemented. 252 00:10:42,830 --> 00:10:44,340 It's not done. 253 00:10:44,340 --> 00:10:49,940 If you want to, you could program it, change bitcoin, 254 00:10:49,940 --> 00:10:51,560 make a pull request. 255 00:10:51,560 --> 00:10:53,360 I think-- I mean, we've discussed it, 256 00:10:53,360 --> 00:10:56,903 and people are like, yeah that'd be cool but, no one's done it. 257 00:10:56,903 --> 00:10:58,820 So if you want to leave your mark and be like, 258 00:10:58,820 --> 00:11:02,000 I'm a bitcoin core contributor, and I optimized 259 00:11:02,000 --> 00:11:04,220 the proof of work propagation system or something 260 00:11:04,220 --> 00:11:06,320 sounds cool, you can do this. 261 00:11:06,320 --> 00:11:08,563 It's not too hard. 262 00:11:08,563 --> 00:11:09,980 You got to learn how bitcoin works 263 00:11:09,980 --> 00:11:12,047 and all the different messages and stuff, 264 00:11:12,047 --> 00:11:13,130 so it's a little annoying. 265 00:11:13,130 --> 00:11:15,213 But I think the main reason people haven't done is 266 00:11:15,213 --> 00:11:16,885 because it's-- 267 00:11:16,885 --> 00:11:18,260 this is not the slow part, right. 268 00:11:18,260 --> 00:11:20,218 This is not the critical path, not a bottleneck 269 00:11:20,218 --> 00:11:21,120 in the actual system. 270 00:11:21,120 --> 00:11:24,020 Generally, the proof of work verification is pretty quick. 271 00:11:24,020 --> 00:11:26,450 The headers are a total of 40 something megabytes 272 00:11:26,450 --> 00:11:28,940 now, 50 megabytes maybe. 273 00:11:28,940 --> 00:11:30,950 So you could you could definitely reduce that 274 00:11:30,950 --> 00:11:33,020 by a significant extent, but no one's 275 00:11:33,020 --> 00:11:35,210 bothered because there's so many other scaling 276 00:11:35,210 --> 00:11:37,250 issues that are more pressing. 277 00:11:37,250 --> 00:11:40,150 But it's kind of cool, I think. 278 00:11:40,150 --> 00:11:41,270 So, yeah. 279 00:11:41,270 --> 00:11:43,580 That'd be a fun thing to do. 280 00:11:43,580 --> 00:11:48,090 If you did that would that be a soft or hard fork? 281 00:11:48,090 --> 00:11:51,590 If you said, OK, I'm going to now send header messages that 282 00:11:51,590 --> 00:11:52,940 are truncated. 283 00:11:52,940 --> 00:11:56,900 I'm going to leave off the 4 bytes that are always 0s. 284 00:11:56,900 --> 00:11:58,260 Bitcoin is also the first-- 285 00:11:58,260 --> 00:12:00,468 the difficulty requirement here is basically the same 286 00:12:00,468 --> 00:12:02,690 as it is in bitcoin. 287 00:12:02,690 --> 00:12:06,170 I'm going to have the implied previous block 288 00:12:06,170 --> 00:12:07,880 hash, things like that. 289 00:12:07,880 --> 00:12:10,660 Would that be a fork? 290 00:12:10,660 --> 00:12:12,280 Actually, it wouldn't, right? 291 00:12:12,280 --> 00:12:13,420 It's a non-fork. 292 00:12:13,420 --> 00:12:15,310 There are lots of changes you can make. 293 00:12:15,310 --> 00:12:17,740 So I know Neha talked about soft forks 294 00:12:17,740 --> 00:12:20,495 and hard forks changes you can make in the system that affect 295 00:12:20,495 --> 00:12:22,120 consensus, but there's a lot of changes 296 00:12:22,120 --> 00:12:25,540 you can make that optimize it that don't really 297 00:12:25,540 --> 00:12:28,430 affect other people. 298 00:12:28,430 --> 00:12:30,850 So in this case, it would just be a wire protocol change 299 00:12:30,850 --> 00:12:34,270 and you could easily maintain backwards compatibility right? 300 00:12:34,270 --> 00:12:36,850 So in this case, you say, the header optimization is not 301 00:12:36,850 --> 00:12:38,140 a fork, right. 302 00:12:38,140 --> 00:12:40,000 What you do is you'd have a new message 303 00:12:40,000 --> 00:12:43,087 type like, truncated header or something, 304 00:12:43,087 --> 00:12:44,920 and then, when you connect to nodes you say, 305 00:12:44,920 --> 00:12:47,500 hey, you know about this new message type I'm using? 306 00:12:47,500 --> 00:12:48,820 And if they don't know what you're talking about 307 00:12:48,820 --> 00:12:50,362 or they usually they say what version 308 00:12:50,362 --> 00:12:51,490 they are when they connect. 309 00:12:51,490 --> 00:12:52,480 You're like, oh you're an old version, 310 00:12:52,480 --> 00:12:53,563 you don't know about this. 311 00:12:53,563 --> 00:12:55,720 I'll just keep saying the old header type. 312 00:12:55,720 --> 00:12:58,360 And even if I store the new truncated headers on disk, 313 00:12:58,360 --> 00:13:00,800 I can recreate the old one pretty quickly 314 00:13:00,800 --> 00:13:04,450 by performing the hashtag and then on sending it to you. 315 00:13:04,450 --> 00:13:08,380 So I can be backwards compatible and forwards compatible. 316 00:13:08,380 --> 00:13:10,000 No soft forks needed. 317 00:13:10,000 --> 00:13:12,490 The old nodes, they don't even see that this happens. 318 00:13:12,490 --> 00:13:14,115 They might see that there's oh, there's 319 00:13:14,115 --> 00:13:16,125 a new version or a new message I'm not aware of. 320 00:13:16,125 --> 00:13:16,750 They ignore it. 321 00:13:16,750 --> 00:13:18,610 Everything seems fine. 322 00:13:18,610 --> 00:13:20,140 So these are the easiest-- 323 00:13:20,140 --> 00:13:22,390 they're not forced-- the easiest changes in the system 324 00:13:22,390 --> 00:13:25,990 get through because there's no real coordination needed 325 00:13:25,990 --> 00:13:29,230 and it's backwards and forwards compatible, so that's cool. 326 00:13:29,230 --> 00:13:32,230 So some example non-forks. 327 00:13:32,230 --> 00:13:34,810 A lot of them are internal only. 328 00:13:34,810 --> 00:13:36,700 You can't even see from outside. 329 00:13:36,700 --> 00:13:38,590 So for example, compressing blocks 330 00:13:38,590 --> 00:13:41,620 or compressing your database. 331 00:13:41,620 --> 00:13:44,140 That's fairly straightforward, right? 332 00:13:44,140 --> 00:13:46,060 Intuitively it seems like, well, these are all 333 00:13:46,060 --> 00:13:48,000 random numbers and hashes. 334 00:13:48,000 --> 00:13:51,460 You can't really compress those because they're random. 335 00:13:51,460 --> 00:13:53,050 In practice, you actually can. 336 00:13:53,050 --> 00:13:56,920 People reuse public keys a lot, and so you just 337 00:13:56,920 --> 00:13:58,420 see the same pub key over and over. 338 00:13:58,420 --> 00:14:00,190 So you do some pretty simple encoding 339 00:14:00,190 --> 00:14:02,890 and you can make those smaller. 340 00:14:02,890 --> 00:14:05,040 Also, the amounts is 8 bytes. 341 00:14:05,040 --> 00:14:09,690 So if you're sending someone one bitcoin, that's 100 million. 342 00:14:09,690 --> 00:14:11,800 And people like to use round numbers, 343 00:14:11,800 --> 00:14:13,690 and so those get compressed pretty well. 344 00:14:13,690 --> 00:14:15,430 And generally, they're much smaller. 345 00:14:15,430 --> 00:14:17,290 So the top bytes are usually 0s. 346 00:14:17,290 --> 00:14:19,090 So you can compress it a decent amount. 347 00:14:19,090 --> 00:14:20,950 But no one has to know that you're compressing, right? 348 00:14:20,950 --> 00:14:22,060 That's all transparent. 349 00:14:22,060 --> 00:14:23,477 When someone connects to you, they 350 00:14:23,477 --> 00:14:26,560 have no idea if you're compressing or not on disk. 351 00:14:26,560 --> 00:14:28,690 Something like faster signature verification, 352 00:14:28,690 --> 00:14:30,280 where there's been enormous amounts 353 00:14:30,280 --> 00:14:32,440 of work in optimizing the code for that. 354 00:14:32,440 --> 00:14:35,320 Making assembly, stuff like that. 355 00:14:35,320 --> 00:14:37,360 Nobody knows you're doing it, they're just like, 356 00:14:37,360 --> 00:14:40,590 oh, he's asking for blocks quicker than this other person. 357 00:14:40,590 --> 00:14:42,790 Maybe his network's faster, maybe his CPU faster. 358 00:14:42,790 --> 00:14:45,430 So these are changes that are purely internal. 359 00:14:45,430 --> 00:14:46,600 Nobody needs to know. 360 00:14:46,600 --> 00:14:48,250 That's cool. 361 00:14:48,250 --> 00:14:51,220 Other non-forks are peer-to-peer non-forks. 362 00:14:51,220 --> 00:14:54,340 So the truncated headers, maybe, where you can say, 363 00:14:54,340 --> 00:14:56,740 hey, I'm going to send you less data over the network. 364 00:14:56,740 --> 00:14:58,903 You identify at connect time and you 365 00:14:58,903 --> 00:15:00,070 default to the old behavior. 366 00:15:00,070 --> 00:15:01,903 People don't know what you're talking about. 367 00:15:01,903 --> 00:15:06,390 So there's one called compact blocks. 368 00:15:06,390 --> 00:15:08,140 I didn't describe it, but you can probably 369 00:15:08,140 --> 00:15:10,420 guess what the idea of compact blocks is. 370 00:15:10,420 --> 00:15:12,560 Anyone want to venture a guess what those do? 371 00:15:17,180 --> 00:15:18,890 Block. 372 00:15:18,890 --> 00:15:21,470 So it's not a header that's come back, but the whole block. 373 00:15:21,470 --> 00:15:25,280 How would you compact a block? 374 00:15:25,280 --> 00:15:29,380 AUDIENCE: Get rid of all the fields that aren't necessary. 375 00:15:29,380 --> 00:15:31,620 Like version... 376 00:15:31,620 --> 00:15:34,050 PROFESSOR: Yeah, actually, that would work. 377 00:15:34,050 --> 00:15:36,620 But that's not what they do. 378 00:15:36,620 --> 00:15:40,440 There's a really big 2x redundancy. 379 00:15:40,440 --> 00:15:43,730 And so the basic idea is transactions are propagated, 380 00:15:43,730 --> 00:15:45,290 and then a block's propagated. 381 00:15:45,290 --> 00:15:46,498 Where's the redundancy there? 382 00:15:49,778 --> 00:15:50,838 AUDIENCE: [INAUDIBLE] 383 00:15:50,838 --> 00:15:52,630 PROFESSOR: Yes, the transactions the block. 384 00:15:52,630 --> 00:15:54,490 You've Probably already seen them, right? 385 00:15:54,490 --> 00:15:57,160 You see the transactions, and the block comes out. 386 00:15:57,160 --> 00:15:59,620 Most of it, in general, 90-something percent, 387 00:15:59,620 --> 00:16:01,660 it's like, yeah we're going to see all this. 388 00:16:01,660 --> 00:16:06,880 So compact blocks is a way to say, hey, here is the block. 389 00:16:06,880 --> 00:16:08,380 Here are all the transactions in it, 390 00:16:08,380 --> 00:16:10,005 but I don't show the whole transaction. 391 00:16:10,005 --> 00:16:11,890 I just show the TXID the hashes. 392 00:16:11,890 --> 00:16:13,150 And then you can say, OK. 393 00:16:13,150 --> 00:16:16,510 90% of those I've already seen so we're good. 394 00:16:16,510 --> 00:16:18,580 Here's these 50 transactions I have not 395 00:16:18,580 --> 00:16:20,530 seen, please give them to me. 396 00:16:20,530 --> 00:16:22,570 So it's interactive here's the blocks 397 00:16:22,570 --> 00:16:24,700 with just the transaction identifiers. 398 00:16:24,700 --> 00:16:25,780 OK, what do you need? 399 00:16:25,780 --> 00:16:26,950 OK, I need these 10. 400 00:16:26,950 --> 00:16:30,440 OK, here's the 10, and now I can reconstruct the whole block. 401 00:16:30,440 --> 00:16:33,160 So the block goes from being a megabyte over the wire 402 00:16:33,160 --> 00:16:37,160 to something like 10 kilobytes? 403 00:16:37,160 --> 00:16:40,148 But it is a little slower in that it's like a multi round 404 00:16:40,148 --> 00:16:40,690 thing, right. 405 00:16:40,690 --> 00:16:42,740 It's like, here's the compact block, 406 00:16:42,740 --> 00:16:46,040 OK, I need these extra things, OK, here's the extra things. 407 00:16:46,040 --> 00:16:47,710 So a little bit more complexity. 408 00:16:47,710 --> 00:16:49,377 If you're really optimizing for latency, 409 00:16:49,377 --> 00:16:50,710 then you don't want to use this. 410 00:16:50,710 --> 00:16:52,630 But in general, it's a pretty big gain 411 00:16:52,630 --> 00:16:58,060 in terms of bandwidth, which can be taxing on full nodes. 412 00:16:58,060 --> 00:17:01,800 I run a-- there's a full node on the first floor in one 413 00:17:01,800 --> 00:17:07,450 little rack and it uploads three terabytes a month or so. 414 00:17:07,450 --> 00:17:09,383 Depends on how much people are using bitcoin. 415 00:17:09,383 --> 00:17:11,800 In December, everyone starts downloading it and installing 416 00:17:11,800 --> 00:17:14,200 it, and there's a lot of bandwidth 417 00:17:14,200 --> 00:17:16,150 needed to sync people up. 418 00:17:16,150 --> 00:17:18,579 Another non-fork was the Bloom filters, 419 00:17:18,579 --> 00:17:20,920 which note full nodes can then say, hey, 420 00:17:20,920 --> 00:17:23,800 I will perform Bloom filter calculations for you. 421 00:17:23,800 --> 00:17:25,930 And light nodes can connect in, like I 422 00:17:25,930 --> 00:17:28,810 said two weeks ago with SPV. 423 00:17:28,810 --> 00:17:31,000 Light nodes can submit a Bloom filter say, hey, 424 00:17:31,000 --> 00:17:34,570 when I download a block from you, first, filter the block. 425 00:17:34,570 --> 00:17:37,240 Match all the transactions against this Bloom filter 426 00:17:37,240 --> 00:17:39,790 and only send me things that match. 427 00:17:39,790 --> 00:17:44,170 That's not a fork, but it's a fairly involved change 428 00:17:44,170 --> 00:17:46,220 in the peer-to-peer code. 429 00:17:46,220 --> 00:17:51,130 OK, any questions about these peer-to-peer non-forks? 430 00:17:51,130 --> 00:17:52,060 Cool. 431 00:17:52,060 --> 00:17:58,937 There's another aspect called standardness, where you haven't 432 00:17:58,937 --> 00:18:00,520 soft forked something out, you haven't 433 00:18:00,520 --> 00:18:02,080 declared something invalid, but you 434 00:18:02,080 --> 00:18:04,180 can declare it non-standard. 435 00:18:04,180 --> 00:18:05,980 And what that means, is when you're 436 00:18:05,980 --> 00:18:09,700 node sees a transaction coming over unconfirmed, 437 00:18:09,700 --> 00:18:12,330 the transaction being propagated through the network. 438 00:18:12,330 --> 00:18:13,870 And it's got this property, and you 439 00:18:13,870 --> 00:18:15,250 say, oh, that's non-standard. 440 00:18:15,250 --> 00:18:17,150 I'm going to drop it, I'm going to ignore it. 441 00:18:17,150 --> 00:18:19,220 I won't propagate it onto my peers. 442 00:18:19,220 --> 00:18:20,800 I won't ban, I don't-- 443 00:18:20,800 --> 00:18:21,698 it depends. 444 00:18:21,698 --> 00:18:22,240 I don't know. 445 00:18:22,240 --> 00:18:24,490 Do I ban the person submitting it to me? 446 00:18:24,490 --> 00:18:27,510 I think you don't, but I ignore it. 447 00:18:27,510 --> 00:18:29,260 I don't propagate it, so it doesn't really 448 00:18:29,260 --> 00:18:30,218 get around the network. 449 00:18:30,218 --> 00:18:31,930 When most of the peers on the network 450 00:18:31,930 --> 00:18:33,822 have these rules of non-standardness 451 00:18:33,822 --> 00:18:36,280 it's going to be very difficult to get your transaction out 452 00:18:36,280 --> 00:18:37,330 there. 453 00:18:37,330 --> 00:18:41,260 However, if you see this non-standard transaction 454 00:18:41,260 --> 00:18:43,735 in a block, you accept the block. 455 00:18:43,735 --> 00:18:46,360 You say, OK, well that was this weird thing that I didn't like, 456 00:18:46,360 --> 00:18:48,652 but since it's in a block and someone did a lot of work 457 00:18:48,652 --> 00:18:51,265 on it, I will accept it. 458 00:18:51,265 --> 00:18:52,390 It's a little weird, right? 459 00:18:52,390 --> 00:18:53,530 Why have this? 460 00:18:53,530 --> 00:18:56,400 It's something that's not quite a soft fork, right? 461 00:18:56,400 --> 00:18:58,150 It's showing that we're discouraging this, 462 00:18:58,150 --> 00:18:59,770 we think it's non-standard. 463 00:18:59,770 --> 00:19:02,290 The miners software, by default, will also 464 00:19:02,290 --> 00:19:04,390 consider this non-standard and not mine it. 465 00:19:04,390 --> 00:19:07,730 But if someone else is mining it, we're OK with it. 466 00:19:07,730 --> 00:19:10,150 And so what you can do, is you can 467 00:19:10,150 --> 00:19:13,300 stage future soft forks this way, right. 468 00:19:13,300 --> 00:19:18,280 So for example, in SegWit, oh, I didn't talk about SegWit 469 00:19:18,280 --> 00:19:19,970 at all. 470 00:19:19,970 --> 00:19:23,000 I'm going to have to do that next class, next week. 471 00:19:23,000 --> 00:19:27,160 OK, so SegWit was the biggest soft fork ever in bitcoin, 472 00:19:27,160 --> 00:19:29,530 and it occurred last year. 473 00:19:29,530 --> 00:19:31,930 It changed the output scripts to say-- 474 00:19:41,760 --> 00:19:45,360 so before, you said, OP_DUP, OP_HASH160, the hash, 475 00:19:45,360 --> 00:19:48,660 OP_CHECKS, OP_EQUAL, whatever. 476 00:19:48,660 --> 00:19:50,430 Here, it just says 0. 477 00:19:50,430 --> 00:19:56,160 Just pushes a 0 byte, and then pubkey hash, and that's it. 478 00:19:56,160 --> 00:19:58,410 And if you actually interpret that in the stack, 479 00:19:58,410 --> 00:19:59,910 no signature is needed, right? 480 00:19:59,910 --> 00:20:02,820 You push a 0 to the bottom the stack, you push a pubkey hash 481 00:20:02,820 --> 00:20:05,370 on top of that, and then your execution halts, 482 00:20:05,370 --> 00:20:08,250 and you're like, well, there's a non-zero piece 483 00:20:08,250 --> 00:20:09,750 of data on the top. 484 00:20:09,750 --> 00:20:13,980 I interpret non-zero data as true, same way he does, 485 00:20:13,980 --> 00:20:14,880 so it's true. 486 00:20:14,880 --> 00:20:16,830 You don't need a signature at all. 487 00:20:16,830 --> 00:20:18,930 So that's the weird SegWit soft fork 488 00:20:18,930 --> 00:20:22,470 where they said, no, what used to be considered true 489 00:20:22,470 --> 00:20:25,980 without a signature, we now template and we say, 490 00:20:25,980 --> 00:20:30,510 this means check pubkey hash, right? 491 00:20:30,510 --> 00:20:34,040 This means the same as OP_DUP, OP_HASH160, hash, OP_EQUALS, 492 00:20:34,040 --> 00:20:36,360 OP_CHECKS, OP_CHECKSIG, right. 493 00:20:36,360 --> 00:20:38,370 So what you actually do, is you need 494 00:20:38,370 --> 00:20:40,320 to provide the pubkey that this hashes into, 495 00:20:40,320 --> 00:20:42,330 and then check a signature. 496 00:20:42,330 --> 00:20:47,140 It also defined 1, 2, 3, up to 16, 497 00:20:47,140 --> 00:20:50,940 and left this undefined, and said, look, 498 00:20:50,940 --> 00:20:53,170 these are now non-standard. 499 00:20:53,170 --> 00:20:55,760 Before, if you-- I think they were already non-standard, 500 00:20:55,760 --> 00:20:58,680 but the idea is that if you just push a 1 on the stack, 501 00:20:58,680 --> 00:21:02,295 and then push some data, well, I guess no signatures needed. 502 00:21:02,295 --> 00:21:04,170 But now they're non-standard because it means 503 00:21:04,170 --> 00:21:05,520 we're going to use these next. 504 00:21:05,520 --> 00:21:10,380 The next soft work will define what one, some piece of data 505 00:21:10,380 --> 00:21:11,040 means. 506 00:21:11,040 --> 00:21:12,600 Maybe it's a new signature scheme, 507 00:21:12,600 --> 00:21:16,223 maybe it's a new program where you put some data here, 508 00:21:16,223 --> 00:21:17,140 but it's non-standard. 509 00:21:17,140 --> 00:21:19,020 So if you try to make a transaction that's 510 00:21:19,020 --> 00:21:22,620 using 2 and then a data push, all the nodes 511 00:21:22,620 --> 00:21:25,340 will be like, yeah, I'm not ready for that. 512 00:21:25,340 --> 00:21:26,590 I haven't I haven't seen that. 513 00:21:26,590 --> 00:21:29,280 And if you see, I think in your air logs, 514 00:21:29,280 --> 00:21:31,778 if you see a block with a bunch of these kinds of things, 515 00:21:31,778 --> 00:21:32,820 it'll give you a warning. 516 00:21:32,820 --> 00:21:33,612 It's like, warning. 517 00:21:33,612 --> 00:21:36,600 People are using stuff that your software doesn't know about. 518 00:21:36,600 --> 00:21:38,880 You might need to upgrade. 519 00:21:38,880 --> 00:21:40,950 There's a bunch of warnings like that where like, 520 00:21:40,950 --> 00:21:44,070 warning some percentage of the last few blocks 521 00:21:44,070 --> 00:21:47,370 had these things, so people are doing stuff that you're not 522 00:21:47,370 --> 00:21:48,570 considering invalid, right? 523 00:21:48,570 --> 00:21:52,230 You're not going to refuse the block, but you're also like, 524 00:21:52,230 --> 00:21:54,060 this is something I don't understand 525 00:21:54,060 --> 00:21:57,250 and I've specifically coded it as nonstandard. 526 00:21:57,250 --> 00:22:00,000 OK so any questions about non-standardness? 527 00:22:00,000 --> 00:22:04,770 Neha talked about soft forks and hard forks, 528 00:22:04,770 --> 00:22:08,220 and I will go through a bit more detail 529 00:22:08,220 --> 00:22:11,710 about how these end up working and how these 530 00:22:11,710 --> 00:22:15,420 interact with miners and notes. 531 00:22:15,420 --> 00:22:18,200 Did people have questions about soft forks and hard forks 532 00:22:18,200 --> 00:22:21,010 before we start? 533 00:22:21,010 --> 00:22:23,110 Sort of got the general idea, right? 534 00:22:23,110 --> 00:22:27,040 Soft forks add new rules, hard forks remove rules, in general. 535 00:22:30,030 --> 00:22:31,540 And this is minors. 536 00:22:34,120 --> 00:22:36,520 So the miners have a unique role here. 537 00:22:36,520 --> 00:22:40,450 It's not just the same as a full node. 538 00:22:40,450 --> 00:22:45,760 A miner decides what to put into a block that they're mining. 539 00:22:45,760 --> 00:22:47,460 And so they do have a bit more influence 540 00:22:47,460 --> 00:22:49,410 in this fork decisions. 541 00:22:49,410 --> 00:22:52,430 OK, so a soft forks would be, for example, saying, 542 00:22:52,430 --> 00:22:56,300 OK, all output amounts must be odd, right. 543 00:22:56,300 --> 00:22:59,720 You can't send an even number of coins to anyone anymore. 544 00:22:59,720 --> 00:23:01,907 That would be a weird, silly fork. 545 00:23:01,907 --> 00:23:03,740 Wouldn't really impact the usability system, 546 00:23:03,740 --> 00:23:05,540 but it'd be dumb, but you could do it. 547 00:23:05,540 --> 00:23:06,915 And you could say, OK, well, if I 548 00:23:06,915 --> 00:23:09,590 see a block, if I see a transaction, which outputs, 549 00:23:09,590 --> 00:23:12,740 if any of the outputs have an even number of Satoshis, 550 00:23:12,740 --> 00:23:14,080 invalid. 551 00:23:14,080 --> 00:23:16,930 You've got to do odd. 552 00:23:16,930 --> 00:23:20,700 Potentially leading to the loss of 1 Satoshi per transaction-- 553 00:23:20,700 --> 00:23:22,390 with the fees, 1 Satoshi per block 554 00:23:22,390 --> 00:23:26,530 may end up being lost due to this. 555 00:23:26,530 --> 00:23:31,630 So here I'm saying, an A for adopter and I for ignorer. 556 00:23:31,630 --> 00:23:34,460 Now people may ignore the fork because they disagree with it. 557 00:23:34,460 --> 00:23:36,880 They don't want to do this fork, or they 558 00:23:36,880 --> 00:23:39,550 may do it because they may just not even know 559 00:23:39,550 --> 00:23:41,080 that this software exists. 560 00:23:41,080 --> 00:23:43,360 It's a giant decentralized system, 561 00:23:43,360 --> 00:23:46,870 and it's hard to know how to communicate 562 00:23:46,870 --> 00:23:48,580 with everyone, right? 563 00:23:48,580 --> 00:23:52,540 There is bitcoin.org. 564 00:23:52,540 --> 00:23:54,640 There's also bitcoin.com, where the guy 565 00:23:54,640 --> 00:23:57,160 doesn't like the bitcoin developers, 566 00:23:57,160 --> 00:23:59,440 and says they're bad. 567 00:23:59,440 --> 00:24:01,065 Anyone can just register these things. 568 00:24:01,065 --> 00:24:02,440 There's a bitcoin Twitter account 569 00:24:02,440 --> 00:24:05,080 that was purchased recently by someone who wanted 570 00:24:05,080 --> 00:24:06,460 to argue about these things. 571 00:24:06,460 --> 00:24:08,890 So there's no one really in charge of this. 572 00:24:08,890 --> 00:24:11,100 And then there's also different implementations. 573 00:24:11,100 --> 00:24:12,910 There is the real bitcoin, which is 574 00:24:12,910 --> 00:24:14,912 run by this bunch of crazy people 575 00:24:14,912 --> 00:24:16,870 who say they control bitcoin, and that everyone 576 00:24:16,870 --> 00:24:20,580 has to pay them taxes in bitcoins, yeah. 577 00:24:20,580 --> 00:24:22,360 But they're all running bitcoin-- 578 00:24:22,360 --> 00:24:25,150 they all are in consensus and doing these transactions. 579 00:24:25,150 --> 00:24:27,980 So ignoring could be any number of things. 580 00:24:27,980 --> 00:24:30,800 If you have a soft fork, where you say, 581 00:24:30,800 --> 00:24:35,200 OK, we're now adding this rule, but none of the miners 582 00:24:35,200 --> 00:24:36,100 are enforcing it. 583 00:24:36,100 --> 00:24:39,570 None of the miners even know about it, potentially. 584 00:24:39,570 --> 00:24:42,220 Here, it just stops, right? 585 00:24:42,220 --> 00:24:46,330 You say, no, I require that all output amounts are odd. 586 00:24:46,330 --> 00:24:48,292 And then every block has these even amounts. 587 00:24:48,292 --> 00:24:49,750 And you're just like, OK, no that's 588 00:24:49,750 --> 00:24:51,583 not a valid block, that's not a valid block, 589 00:24:51,583 --> 00:24:53,890 you will never see a valid block again, right? 590 00:24:53,890 --> 00:24:56,860 None of the miners are enforcing this rule, but you are. 591 00:24:56,860 --> 00:25:00,850 Everyone's ignoring it, and they say, everyone's ignoring it. 592 00:25:00,850 --> 00:25:01,960 Everything seems fine. 593 00:25:01,960 --> 00:25:04,870 You just self-imposed this new rule, 594 00:25:04,870 --> 00:25:07,270 making you incompatible with the rest of the network, 595 00:25:07,270 --> 00:25:12,310 and from your perspective, everything stops and no more 596 00:25:12,310 --> 00:25:14,380 blocks occur and the system is over. 597 00:25:14,380 --> 00:25:19,840 Or potentially, if you're soft fork is some weird rule 598 00:25:19,840 --> 00:25:22,780 that nobody knows about and nobody breaks anyway, 599 00:25:22,780 --> 00:25:26,795 we say, OK, the sum of the outputs of all-- 600 00:25:26,795 --> 00:25:28,420 the sum of the outputs in a transaction 601 00:25:28,420 --> 00:25:31,100 must not be a Carmichael number. 602 00:25:31,100 --> 00:25:33,340 OK, you could have that rule. 603 00:25:33,340 --> 00:25:34,790 Probably no one's break-- 604 00:25:34,790 --> 00:25:35,290 wait. 605 00:25:35,290 --> 00:25:36,415 There's a lot of small-- 606 00:25:36,415 --> 00:25:37,540 something like that, right? 607 00:25:37,540 --> 00:25:41,170 Where no one's breaking it anyway. 608 00:25:41,170 --> 00:25:43,180 Then, from your perspective, everything's 609 00:25:43,180 --> 00:25:44,805 cool because everyone's already obeying 610 00:25:44,805 --> 00:25:48,040 your rule even though they don't know about it, it's silly. 611 00:25:48,040 --> 00:25:52,870 Another possibility is let's say a minority, somewhere 1 to 50% 612 00:25:52,870 --> 00:25:54,967 of the miners adopt this rule and say, yeah, 613 00:25:54,967 --> 00:25:56,800 we're going to enforce this new rule, right? 614 00:25:56,800 --> 00:26:00,940 All output amounts need to be odd, so the idea is you say, 615 00:26:00,940 --> 00:26:02,950 yes, only odd numbers. 616 00:26:02,950 --> 00:26:05,890 And a bunch of the majority, actually, of people 617 00:26:05,890 --> 00:26:07,420 don't care about odd or even. 618 00:26:07,420 --> 00:26:10,300 So the majority, they still go off on their own chain, 619 00:26:10,300 --> 00:26:12,010 but you split off into your own faction, 620 00:26:12,010 --> 00:26:15,010 you say, no we're the odd bunch. 621 00:26:15,010 --> 00:26:19,110 And both of those chains are viable. 622 00:26:19,110 --> 00:26:21,240 Blocks come out here maybe quite slowly, 623 00:26:21,240 --> 00:26:22,610 if it's only a few percent. 624 00:26:22,610 --> 00:26:24,840 Blocks still come out here. 625 00:26:24,840 --> 00:26:29,100 The fact, so you've got these odd thing, 626 00:26:29,100 --> 00:26:30,980 and then you've got regular. 627 00:26:30,980 --> 00:26:33,727 And the regular is going to be longer, right? 628 00:26:33,727 --> 00:26:35,310 The regular is going to be potentially 629 00:26:35,310 --> 00:26:37,140 a lot longer, but from the people here, 630 00:26:37,140 --> 00:26:38,932 they're like, we don't care if it's longer. 631 00:26:38,932 --> 00:26:39,660 It's wrong. 632 00:26:39,660 --> 00:26:43,950 They use even numbers, that's just plain, old wrong. 633 00:26:43,950 --> 00:26:46,470 And these people are like, yeah we can sometimes see it, 634 00:26:46,470 --> 00:26:48,450 but actually we lose track of it very quickly. 635 00:26:48,450 --> 00:26:52,200 After here, we start seeing block advertisements like this, 636 00:26:52,200 --> 00:26:54,540 and we're like, we're over here now. 637 00:26:54,540 --> 00:26:55,590 We're way past that. 638 00:26:55,590 --> 00:26:58,590 Why are you talking about this stuff from like weeks ago? 639 00:26:58,590 --> 00:27:00,070 So they just disconnect. 640 00:27:00,070 --> 00:27:02,730 It's pretty ugly, but that can happen. 641 00:27:02,730 --> 00:27:06,840 Now, if you have the majority of the hash power, 642 00:27:06,840 --> 00:27:13,830 this ends up being longer, the odd blocks end up being longer, 643 00:27:13,830 --> 00:27:17,100 and everyone gets dragged along, right? 644 00:27:17,100 --> 00:27:23,530 No split, and now we have a new rule 645 00:27:23,530 --> 00:27:26,260 even though they didn't know about the rule potentially. 646 00:27:26,260 --> 00:27:28,750 So they're like, what the heck, half my transactions 647 00:27:28,750 --> 00:27:30,037 don't work. 648 00:27:30,037 --> 00:27:31,620 Some of them do, Some of them don't, I 649 00:27:31,620 --> 00:27:32,745 don't know what's going on. 650 00:27:32,745 --> 00:27:35,770 I just randomly adjust my fees until it seems to work, 651 00:27:35,770 --> 00:27:37,690 and then my transactions go through. 652 00:27:37,690 --> 00:27:39,310 They should probably find out from someone, oh, yeah, 653 00:27:39,310 --> 00:27:40,102 there's a new rule. 654 00:27:40,102 --> 00:27:41,980 Only odd numbers, and then they-- 655 00:27:41,980 --> 00:27:44,980 that rule is imposed on them from the miners, 656 00:27:44,980 --> 00:27:47,950 essentially, in the rest of the network. 657 00:27:47,950 --> 00:27:49,790 And essentially, the same thing here. 658 00:27:49,790 --> 00:27:53,020 When you get to 100%, there's none of these orphans, 659 00:27:53,020 --> 00:27:55,390 but it worked-- oh, sorry-- these orphans would actually 660 00:27:55,390 --> 00:28:00,790 be like this because everyone agrees that this is valid, 661 00:28:00,790 --> 00:28:03,070 and then some of the people aren't aware of the rule 662 00:28:03,070 --> 00:28:05,050 and keep mining off of these what 663 00:28:05,050 --> 00:28:06,680 they consider valid blocks. 664 00:28:06,680 --> 00:28:08,580 So it's a little different topology. 665 00:28:08,580 --> 00:28:09,940 OK, so that makes sense, right? 666 00:28:09,940 --> 00:28:14,640 Any questions about soft fork, mining power rules? 667 00:28:14,640 --> 00:28:19,050 One other aspect, is if you split here, and then later 668 00:28:19,050 --> 00:28:24,420 on you get a majority and you pull ahead, you will reorg out 669 00:28:24,420 --> 00:28:30,690 the ignoring side, so we split off with 10% of the hash power. 670 00:28:30,690 --> 00:28:32,760 We've got our much shorter chain, 671 00:28:32,760 --> 00:28:34,260 where we only have odd numbers. 672 00:28:34,260 --> 00:28:36,900 At some point, we convinced the rest of the miners, 673 00:28:36,900 --> 00:28:38,350 that, no, this is the way to go. 674 00:28:38,350 --> 00:28:40,980 The even numbers are really screwing up the system. 675 00:28:40,980 --> 00:28:43,650 And we get the majority of the hash power, 676 00:28:43,650 --> 00:28:48,210 and then we overtake the even and odd mix chain. 677 00:28:48,210 --> 00:28:51,030 The people who have not yet updated their software, 678 00:28:51,030 --> 00:28:52,650 and are ignoring the fork, they will 679 00:28:52,650 --> 00:28:54,510 reorg out because from their perspective, 680 00:28:54,510 --> 00:28:57,580 OK, I was on a longer chain now there's this other longer 681 00:28:57,580 --> 00:28:58,080 chain. 682 00:28:58,080 --> 00:29:01,140 They both look valid, and when I see two valid chains, 683 00:29:01,140 --> 00:29:03,300 my way to decide is who has the most work? 684 00:29:03,300 --> 00:29:06,780 And so this one pulled ahead, in terms of work, so I switched. 685 00:29:06,780 --> 00:29:10,243 So it's a weird-- this has never really happened, 686 00:29:10,243 --> 00:29:11,910 that I'm aware of, they were threatening 687 00:29:11,910 --> 00:29:19,850 to do it last summer [INAUDIBLE] I don't know. 688 00:29:19,850 --> 00:29:22,125 So yeah there is all sorts of stuff 689 00:29:22,125 --> 00:29:24,500 on the internet, and Reddit, and Twitter about doing this 690 00:29:24,500 --> 00:29:26,780 with a minority of hash power. 691 00:29:26,780 --> 00:29:29,040 They didn't though, or they did. 692 00:29:29,040 --> 00:29:31,880 They say they did, but everyone else says they didn't though. 693 00:29:31,880 --> 00:29:34,170 A lot of arguing. 694 00:29:34,170 --> 00:29:34,670 OK. 695 00:29:34,670 --> 00:29:36,380 So that's another weird aspect of it. 696 00:29:36,380 --> 00:29:39,510 OK, hard forks. 697 00:29:39,510 --> 00:29:41,610 No minor support. 698 00:29:41,610 --> 00:29:43,650 What happens to those adopting it? 699 00:29:43,650 --> 00:29:47,200 Nothing, right? 700 00:29:47,200 --> 00:29:48,450 Everything just keeps working. 701 00:29:48,450 --> 00:29:51,960 If you say, OK, we're now going to allow every transaction 702 00:29:51,960 --> 00:29:52,800 output. 703 00:29:52,800 --> 00:29:56,400 Every transaction can have 1 extra Satoshi gets created. 704 00:29:56,400 --> 00:29:58,890 It's just 1, it's no big deal. 705 00:29:58,890 --> 00:30:01,500 It's quite limited, but we want to compensate people 706 00:30:01,500 --> 00:30:04,360 for using bitcoin, so when you have your inputs, 707 00:30:04,360 --> 00:30:06,660 you have your outputs, you can add 1 Satoshi. 708 00:30:06,660 --> 00:30:09,570 You get a free Satoshi per transaction. 709 00:30:09,570 --> 00:30:11,415 The previous software, absolutely 710 00:30:11,415 --> 00:30:12,540 does not allow that, right? 711 00:30:12,540 --> 00:30:13,998 If you're just generating money out 712 00:30:13,998 --> 00:30:17,850 of nowhere in these transactions, not OK. 713 00:30:17,850 --> 00:30:21,060 But these guys, they'll see that the transactions they do that 714 00:30:21,060 --> 00:30:23,550 with are not confirming, but otherwise, they're 715 00:30:23,550 --> 00:30:26,610 OK if you don't add a Satoshi. 716 00:30:26,610 --> 00:30:28,300 And so the system works. 717 00:30:28,300 --> 00:30:29,740 Nothing happens, nothing happens. 718 00:30:29,740 --> 00:30:31,630 They just see everything. 719 00:30:31,630 --> 00:30:37,130 With a minority of the hash power, something like 10%, 20%, 720 00:30:37,130 --> 00:30:41,610 you get all these orphans, get all these dead ends, 721 00:30:41,610 --> 00:30:44,310 where you see a block, OK, and it's 722 00:30:44,310 --> 00:30:47,160 got this 1 Satoshi per transaction bonus. 723 00:30:47,160 --> 00:30:49,110 Great, but it keeps getting orphaned out 724 00:30:49,110 --> 00:30:53,210 because you still consider-- 725 00:30:53,210 --> 00:30:56,220 all right, so you see OK, here's this longest chain 726 00:30:56,220 --> 00:30:58,200 without the bonus. 727 00:30:58,200 --> 00:31:00,660 And then you say, oh, here's a block with the bonus, cool. 728 00:31:00,660 --> 00:31:02,430 Maybe someone builds 2, great. 729 00:31:02,430 --> 00:31:06,210 But this keeps getting longer and you keep trying, 730 00:31:06,210 --> 00:31:09,210 but you keep getting overpowered because you see both of them 731 00:31:09,210 --> 00:31:09,780 as valid. 732 00:31:09,780 --> 00:31:11,760 You're not requiring that there's 733 00:31:11,760 --> 00:31:13,440 this 1 Satoshi bonus per transaction, 734 00:31:13,440 --> 00:31:14,615 you're just allowing it. 735 00:31:14,615 --> 00:31:15,990 And so you say, oh, this is cool. 736 00:31:15,990 --> 00:31:17,005 Cool, oh, no. 737 00:31:17,005 --> 00:31:18,380 Got reorged out, got reorged out. 738 00:31:18,380 --> 00:31:21,120 So you see all these little starts, they get reorged out. 739 00:31:21,120 --> 00:31:22,920 And you basically stay with the same chain. 740 00:31:22,920 --> 00:31:24,450 You don't split. 741 00:31:24,450 --> 00:31:29,433 These people also see a bunch of invalid blocks, right? 742 00:31:29,433 --> 00:31:30,850 You'll see it on the network, hey, 743 00:31:30,850 --> 00:31:33,150 someone keeps sending these invalid blocks much more 744 00:31:33,150 --> 00:31:34,530 frequently than usually. 745 00:31:34,530 --> 00:31:36,480 I don't know why they're doing that, 746 00:31:36,480 --> 00:31:39,160 but they've got invalid transactions, I ignore them. 747 00:31:39,160 --> 00:31:47,290 Here, majority of hash power is split, 748 00:31:47,290 --> 00:31:53,530 so once the majority and these are the bonus, the plus ones, 749 00:31:53,530 --> 00:31:55,600 they pull out ahead. 750 00:31:55,600 --> 00:31:58,330 These guys don't actually care that they have a majority. 751 00:31:58,330 --> 00:32:00,540 After the first block, they don't see the rest 752 00:32:00,540 --> 00:32:01,390 because they ban. 753 00:32:01,390 --> 00:32:04,770 So if someone submits to you an invalid block, you ban them. 754 00:32:04,770 --> 00:32:07,000 You ban their IP address for 24 hours or something. 755 00:32:07,000 --> 00:32:09,417 You're like, I don't know what you're doing, you're crazy. 756 00:32:09,417 --> 00:32:10,910 Disconnect. 757 00:32:10,910 --> 00:32:13,450 So you won't really see this pretty quickly. 758 00:32:13,450 --> 00:32:14,920 These guys don't have the bonus. 759 00:32:14,920 --> 00:32:17,350 They're still on their same old blockchain. 760 00:32:17,350 --> 00:32:20,140 It may be much slower because a lot of the harsh power 761 00:32:20,140 --> 00:32:23,230 now moved to this other chain, and these guys 762 00:32:23,230 --> 00:32:24,640 say, oh, it worked, cool. 763 00:32:24,640 --> 00:32:28,150 We've got our new bonus coin chain. 764 00:32:28,150 --> 00:32:31,690 Now we're stimulating the economy, everything like that. 765 00:32:31,690 --> 00:32:32,560 Job creation. 766 00:32:32,560 --> 00:32:35,020 OK, so and then these guys slowers. 767 00:32:35,020 --> 00:32:36,900 Slows down. 768 00:32:36,900 --> 00:32:39,840 And then if you have 100%, well stops. 769 00:32:39,840 --> 00:32:42,720 For the non-adopters, no more blocks come out. 770 00:32:42,720 --> 00:32:43,640 This is the end. 771 00:32:43,640 --> 00:32:47,230 Everyone's gone to the job creation train. 772 00:32:47,230 --> 00:32:50,820 And there's not really a split anymore, 773 00:32:50,820 --> 00:32:51,930 it's just the new rule. 774 00:32:54,580 --> 00:32:55,080 OK. 775 00:32:55,080 --> 00:32:57,360 So any questions there? 776 00:32:57,360 --> 00:33:00,152 This grid so far? 777 00:33:00,152 --> 00:33:01,860 Then another way you can do it is combine 778 00:33:01,860 --> 00:33:05,100 this to say OK we're going to do a soft fork and a hard fork 779 00:33:05,100 --> 00:33:07,500 at the same time, and actually, many times 780 00:33:07,500 --> 00:33:10,320 that people say hard fork, they actually mean this. 781 00:33:10,320 --> 00:33:14,460 So the nomenclature is pretty ambiguous. 782 00:33:14,460 --> 00:33:18,970 I like keeping these terms very distinct and pure, 783 00:33:18,970 --> 00:33:22,140 so like a soft fork is purely increasing the number of rules, 784 00:33:22,140 --> 00:33:26,200 where it must be odd, and a hard fork is just reducing rules. 785 00:33:26,200 --> 00:33:29,430 And yes, we will allow but not require a transaction 786 00:33:29,430 --> 00:33:31,290 to have this property. 787 00:33:31,290 --> 00:33:35,100 And then to combine them would be something like saying, 788 00:33:35,100 --> 00:33:37,650 we allow this new thing that was not allowed before 789 00:33:37,650 --> 00:33:39,600 and we require it to be true. 790 00:33:39,600 --> 00:33:41,100 So for example, every transaction 791 00:33:41,100 --> 00:33:46,200 must introduce 1 new Satoshi bonus. 792 00:33:46,200 --> 00:33:48,810 That would be both hard and soft work 793 00:33:48,810 --> 00:33:51,630 because now if you're doing this, 794 00:33:51,630 --> 00:33:54,240 you no longer consider the old rules appropriate. 795 00:33:54,240 --> 00:33:59,070 And there's a complete mutual disagreement on the rules. 796 00:33:59,070 --> 00:34:03,180 Some people have called this full fork, who called it that? 797 00:34:03,180 --> 00:34:04,660 I forget. 798 00:34:04,660 --> 00:34:08,389 Greg called it a bilateral hard fork. 799 00:34:08,389 --> 00:34:10,540 We don't have good terms for these things. 800 00:34:10,540 --> 00:34:15,760 A lot of people refer to forks that have both as hard forks, 801 00:34:15,760 --> 00:34:16,960 so it's somewhat ambiguous. 802 00:34:16,960 --> 00:34:21,370 I think it helps to keep these different terms, 803 00:34:21,370 --> 00:34:23,110 but it's a different setup. 804 00:34:23,110 --> 00:34:28,540 It's the union of these two things in some way in that, 805 00:34:28,540 --> 00:34:31,790 we allow this new thing that was prohibited before, 806 00:34:31,790 --> 00:34:33,969 and not only that, but we require it. 807 00:34:33,969 --> 00:34:37,719 So if 0% enforce the new hard fork, well the adopters, 808 00:34:37,719 --> 00:34:39,560 it just stops, right? 809 00:34:39,560 --> 00:34:43,150 There requiring this new thing, it's not showing up, it ends. 810 00:34:43,150 --> 00:34:46,270 These guys nothing happens, right? 811 00:34:46,270 --> 00:34:51,090 When there's a minority, it will split off. 812 00:34:51,090 --> 00:34:54,420 It'll split off with the new rule set and the new bonus 813 00:34:54,420 --> 00:34:55,590 coins or whatever. 814 00:34:55,590 --> 00:34:59,640 And the ignorers, they see that it's slower 815 00:34:59,640 --> 00:35:02,670 because some people have left some mining powers left. 816 00:35:02,670 --> 00:35:06,450 When you have a majority, you also split off. 817 00:35:06,450 --> 00:35:09,600 And ignorers, again, it's slow. 818 00:35:09,600 --> 00:35:12,930 They're not going to adopt because they 819 00:35:12,930 --> 00:35:15,820 see the new fork is invalid. 820 00:35:15,820 --> 00:35:18,690 In this case, as well, these guys 821 00:35:18,690 --> 00:35:21,660 won't adopt here because they see it as invalid. 822 00:35:21,660 --> 00:35:23,130 And then for the full thing-- 823 00:35:23,130 --> 00:35:27,690 for the 100%, the adopters, new rule, 824 00:35:27,690 --> 00:35:31,620 and these guys system halts. 825 00:35:31,620 --> 00:35:35,360 OK so any questions about full fork or bilateral fork, 826 00:35:35,360 --> 00:35:37,880 or whatever you want to call it. 827 00:35:37,880 --> 00:35:39,810 Hey, it works. 828 00:35:39,810 --> 00:35:42,380 OK, cool. 829 00:35:48,290 --> 00:35:49,100 Yes. 830 00:35:49,100 --> 00:35:54,470 Bilateral, hard, full, we don't know the good names for these. 831 00:35:54,470 --> 00:35:56,710 But yeah. 832 00:35:56,710 --> 00:35:59,650 It's essentially a soft fork and a hard fork coupled together. 833 00:35:59,650 --> 00:36:04,570 And this is much simpler or easier to produce, 834 00:36:04,570 --> 00:36:06,490 and if you just start changing the code, 835 00:36:06,490 --> 00:36:08,713 you're probably going to create one of these, right? 836 00:36:08,713 --> 00:36:09,880 You have to be very careful. 837 00:36:09,880 --> 00:36:12,880 If I want just a hard fork, I'm very 838 00:36:12,880 --> 00:36:16,240 careful that everything that used to be valid is still valid 839 00:36:16,240 --> 00:36:21,100 and I'm just rescinding one rule or one set of rules. 840 00:36:21,100 --> 00:36:23,245 It's very easy to inadvertently create this 841 00:36:23,245 --> 00:36:25,120 when you're trying to make consensus changes. 842 00:36:27,760 --> 00:36:29,690 Yeah, there have been-- 843 00:36:29,690 --> 00:36:34,390 did Neha talk about the 2013 fork? 844 00:36:34,390 --> 00:36:35,170 I don't think so. 845 00:36:35,170 --> 00:36:38,470 OK, so a little anecdote. 846 00:36:38,470 --> 00:36:40,160 I remember I was in the airport. 847 00:36:40,160 --> 00:36:42,130 I got to Nagoya airport and opened 848 00:36:42,130 --> 00:36:45,970 my laptop and bitcoin went down to like $20 from $30, 849 00:36:45,970 --> 00:36:48,220 and it was all over the internet like, oh, no. 850 00:36:48,220 --> 00:36:54,730 And there was a inadvertent hard fork due to the Berkeley DB 851 00:36:54,730 --> 00:36:57,203 to level DB transition in the software. 852 00:36:57,203 --> 00:36:59,320 AUDIENCE: [INAUDIBLE] 853 00:36:59,320 --> 00:37:00,340 PROFESSOR: No, no, no. 854 00:37:00,340 --> 00:37:04,000 It was 0.7 was using Berkeley-- it 855 00:37:04,000 --> 00:37:06,670 used to be everything was using Berkeley DB for the UTXO set 856 00:37:06,670 --> 00:37:07,990 in the blocks. 857 00:37:07,990 --> 00:37:11,500 And then they switched to level DB, 858 00:37:11,500 --> 00:37:13,990 and then, it was OK for a month or two, 859 00:37:13,990 --> 00:37:16,268 and then someone wanted like a block that had 860 00:37:16,268 --> 00:37:17,560 a bunch of inputs or something. 861 00:37:17,560 --> 00:37:20,450 I don't remember exactly the reason. 862 00:37:20,450 --> 00:37:23,020 And the new software was like, yeah, that's cool, 863 00:37:23,020 --> 00:37:25,060 and the old software said it wasn't OK. 864 00:37:25,060 --> 00:37:27,910 The thing is it wasn't clear why, right? 865 00:37:27,910 --> 00:37:30,220 There was no defined like, this should be invalid, 866 00:37:30,220 --> 00:37:31,480 like, this looks valid. 867 00:37:31,480 --> 00:37:34,900 But the Berkeley DB layer gave an error. 868 00:37:34,900 --> 00:37:36,400 And so it's like, well, the database 869 00:37:36,400 --> 00:37:39,520 says it's bad, so it's not a good block. 870 00:37:39,520 --> 00:37:44,230 So that was a weird unintentional consensus change. 871 00:37:44,230 --> 00:37:47,140 What happened was-- so it seemed like it was a hard fork. 872 00:37:47,140 --> 00:37:49,480 The thing is it was like a compiler time option 873 00:37:49,480 --> 00:37:51,880 dependent hard fork, if you compiled it 874 00:37:51,880 --> 00:37:54,850 with a different Berkeley DB cache setting, 875 00:37:54,850 --> 00:37:57,070 then it would work. 876 00:37:57,070 --> 00:38:01,747 It was sort of ambiguous and people rolled back though. 877 00:38:01,747 --> 00:38:04,330 They were on IRC and they were talking to the different miners 878 00:38:04,330 --> 00:38:05,580 and are like, what's going on? 879 00:38:05,580 --> 00:38:07,510 There's two different forks being built. 880 00:38:07,510 --> 00:38:10,210 And they told the people who were, to some extent, 881 00:38:10,210 --> 00:38:15,340 in the right, the new version, which seemed more correct, 882 00:38:15,340 --> 00:38:16,540 to stop mining. 883 00:38:16,540 --> 00:38:20,050 And they did, and then the old version with the Berkeley DB 884 00:38:20,050 --> 00:38:22,770 caught up, and then they restricted their block size. 885 00:38:22,770 --> 00:38:25,660 It was something to do with like having too many file locks open 886 00:38:25,660 --> 00:38:27,470 or something like that. 887 00:38:27,470 --> 00:38:31,270 So that was essentially a hard fork. 888 00:38:31,270 --> 00:38:33,160 They stopped it, and then went back so there 889 00:38:33,160 --> 00:38:35,650 wasn't a hard fork, but then months later they're like, 890 00:38:35,650 --> 00:38:37,672 OK, we're going to all transition 891 00:38:37,672 --> 00:38:40,130 to level DB because we're not even sure what the rules are. 892 00:38:40,130 --> 00:38:40,660 Yeah? 893 00:38:40,660 --> 00:38:45,690 AUDIENCE: [INAUDIBLE] the number of blocks 894 00:38:45,690 --> 00:38:50,530 update they produce block was way too many, so level DB was 895 00:38:50,530 --> 00:38:53,720 like, OK, [INAUDIBLE] 896 00:38:53,720 --> 00:38:54,490 PROFESSOR: Yeah. 897 00:38:54,490 --> 00:38:56,860 And the thing is, they definitely did-- 898 00:38:56,860 --> 00:39:00,820 at the time, people were running around screaming like, why-- 899 00:39:00,820 --> 00:39:02,830 after the fact, they're like, that's why. 900 00:39:02,830 --> 00:39:05,527 But at the time, people were talking really quick 901 00:39:05,527 --> 00:39:06,610 and like, what's going on? 902 00:39:06,610 --> 00:39:08,980 Bitcoin has failed, sell all your bitcoins, 903 00:39:08,980 --> 00:39:11,020 the system doesn't work because no one really 904 00:39:11,020 --> 00:39:17,020 knew what was going on or why some versions weren't working. 905 00:39:17,020 --> 00:39:20,380 So yeah, that was an unintended fork. 906 00:39:20,380 --> 00:39:22,480 It was a little scary, and then the price 907 00:39:22,480 --> 00:39:25,330 went back up after that, It was like, hey, 908 00:39:25,330 --> 00:39:27,970 we can work through this guys. 909 00:39:27,970 --> 00:39:31,210 So that was a hardcore, right? 910 00:39:31,210 --> 00:39:34,240 The old software would not allow these blocks 911 00:39:34,240 --> 00:39:36,280 that opened a bunch of file locks, 912 00:39:36,280 --> 00:39:39,020 and the new software did. 913 00:39:39,020 --> 00:39:41,530 And so that was probably the one real hard fork 914 00:39:41,530 --> 00:39:43,300 that bitcoin has been through. 915 00:39:43,300 --> 00:39:46,000 There were a few maybe in 2009 that like are 916 00:39:46,000 --> 00:39:48,280 fairly ambiguous because there were no there 917 00:39:48,280 --> 00:39:49,870 was no actual split. 918 00:39:49,870 --> 00:39:54,530 I think there's also a hard fork that's happened, 919 00:39:54,530 --> 00:39:56,950 but it didn't, it's a little weird. 920 00:39:56,950 --> 00:39:59,780 It has to do with the timestamp in the block header 921 00:39:59,780 --> 00:40:03,620 and how it like expires in 2106, once you run out 922 00:40:03,620 --> 00:40:06,800 of bits from Unix time. 923 00:40:06,800 --> 00:40:11,690 1970 plus 2 to the 32 seconds is like 2,106 in January, 924 00:40:11,690 --> 00:40:13,350 or something. 925 00:40:13,350 --> 00:40:14,900 And so they actually did a hard fork, 926 00:40:14,900 --> 00:40:17,000 but the thing is the hard fork wouldn't diverge 927 00:40:17,000 --> 00:40:18,960 until 100 years from now. 928 00:40:18,960 --> 00:40:22,130 So it's like whatever, everyone will have updated by then. 929 00:40:22,130 --> 00:40:27,890 If someone's still running software from 2015 in 2106, 930 00:40:27,890 --> 00:40:32,480 they will diverge, but that seems unlikely. 931 00:40:32,480 --> 00:40:34,550 So there's a lot of weird stuff like that. 932 00:40:37,190 --> 00:40:38,010 OK. 933 00:40:38,010 --> 00:40:39,590 Firm variance. 934 00:40:39,590 --> 00:40:43,940 Some people call it firm fork, people call it evil fork, 935 00:40:43,940 --> 00:40:48,020 I'm [INAUDIBLE] call it evil and firm, I don't know. 936 00:40:48,020 --> 00:40:52,507 This is a fun one that has not been attempted, 937 00:40:52,507 --> 00:40:54,590 and I remember talking to people and they're like, 938 00:40:54,590 --> 00:40:56,420 don't talk about this. 939 00:40:56,420 --> 00:40:59,790 The miners don't know they can do this, so just shh. 940 00:40:59,790 --> 00:41:02,270 I'm like, come on, they don't know they could do this? 941 00:41:02,270 --> 00:41:03,660 That's kind of like-- 942 00:41:03,660 --> 00:41:04,160 OK. 943 00:41:04,160 --> 00:41:05,480 So how would you do this? 944 00:41:05,480 --> 00:41:07,130 Make a soft fork. 945 00:41:07,130 --> 00:41:08,180 It's a hard fork, right? 946 00:41:08,180 --> 00:41:11,120 It completely changes the rules, however, 947 00:41:11,120 --> 00:41:13,970 it looks like a soft fork to non-adopting notes. 948 00:41:17,520 --> 00:41:18,690 It's kind of crazy. 949 00:41:18,690 --> 00:41:21,900 Well, the proof of work for the new chain 950 00:41:21,900 --> 00:41:26,035 is a empty but valid block on the old chain. 951 00:41:26,035 --> 00:41:27,660 So instead of your proof of work being, 952 00:41:27,660 --> 00:41:29,790 hey, have a header that hashes to this, 953 00:41:29,790 --> 00:41:31,860 say, have a header that hashes this. 954 00:41:31,860 --> 00:41:35,550 Also a block that is valid but completely empty. 955 00:41:35,550 --> 00:41:37,965 We'll take that as our header, right? 956 00:41:37,965 --> 00:41:39,090 Our header now gets bigger. 957 00:41:39,090 --> 00:41:41,940 Instead of 80 bytes, it's going to be 200 something bytes, 958 00:41:41,940 --> 00:41:42,990 but that's doable. 959 00:41:42,990 --> 00:41:47,630 Now our header chain is a chain of empty blocks. 960 00:41:47,630 --> 00:41:50,460 And our actual blocks point to that, right. 961 00:41:50,460 --> 00:41:52,550 We can put our Merkle root in the output 962 00:41:52,550 --> 00:41:53,930 address or something. 963 00:41:53,930 --> 00:41:57,080 We can put our Merkle root somewhere in this empty block 964 00:41:57,080 --> 00:42:00,050 transaction-- the one transaction in the block. 965 00:42:00,050 --> 00:42:04,070 The old nodes will see it and say, yep, that's a block. 966 00:42:04,070 --> 00:42:07,123 Someone's mining, here's where the money went. 967 00:42:07,123 --> 00:42:08,540 But there's no transactions in it. 968 00:42:08,540 --> 00:42:10,322 My transactions never confirm. 969 00:42:10,322 --> 00:42:12,530 You don't actually have to connect to the old network 970 00:42:12,530 --> 00:42:15,110 to do this, it's totally deterministic. 971 00:42:15,110 --> 00:42:17,090 You just say, OK, my new proof of work 972 00:42:17,090 --> 00:42:19,550 is a valid but empty block on the old one, 973 00:42:19,550 --> 00:42:23,830 and I commit somewhere in this to my new block. 974 00:42:23,830 --> 00:42:30,480 That's evil because what happens is, here's the chart for this. 975 00:42:30,480 --> 00:42:33,440 It's basically a firm fork plus this little evil thing. 976 00:42:33,440 --> 00:42:36,520 The adopting, if you have no hash firewall system holds, 977 00:42:36,520 --> 00:42:37,810 then nothing changes here. 978 00:42:37,810 --> 00:42:40,200 If you have 1 to 50%, the adopting 979 00:42:40,200 --> 00:42:42,780 split off with the new rule, so in this case, 980 00:42:42,780 --> 00:42:44,490 it's like a hard fork. 981 00:42:44,490 --> 00:42:47,280 However, the main difference from a hard fork, 982 00:42:47,280 --> 00:42:50,610 if you have majority hash power, the ignoring 983 00:42:50,610 --> 00:42:51,930 the system essentially halts. 984 00:42:51,930 --> 00:42:54,690 It doesn't halt in that the blocks keep coming out, right. 985 00:42:54,690 --> 00:42:57,588 You'll still see your software won't give you any warnings. 986 00:42:57,588 --> 00:42:59,130 It'll just be like, yep, block height 987 00:42:59,130 --> 00:43:02,130 keeps progressing as normal, as expected. 988 00:43:02,130 --> 00:43:03,990 We keep selling all these blocks, however, 989 00:43:03,990 --> 00:43:05,920 no transactions occur. 990 00:43:05,920 --> 00:43:07,890 And you can never receive or send money, 991 00:43:07,890 --> 00:43:11,620 but according to your software, everything's working fine. 992 00:43:11,620 --> 00:43:16,170 So this is the firm, evil, sneaky, whatever part, 993 00:43:16,170 --> 00:43:19,470 where if you're able to get 51% of the mining 994 00:43:19,470 --> 00:43:24,000 and you implement this new fork, you're basically 995 00:43:24,000 --> 00:43:27,870 forcing everyone to update because if you don't update 996 00:43:27,870 --> 00:43:30,023 your software, if you're ignoring this fork, 997 00:43:30,023 --> 00:43:30,940 you can't do anything. 998 00:43:30,940 --> 00:43:34,292 You've got to adopt a new rule. 999 00:43:34,292 --> 00:43:35,785 So this is scary. 1000 00:43:35,785 --> 00:43:37,160 And I can see why some people are 1001 00:43:37,160 --> 00:43:38,868 like, don't tell miners they can do this. 1002 00:43:38,868 --> 00:43:43,012 Also I remember last year with SegWit2x stuff, I think, 1003 00:43:43,012 --> 00:43:44,220 they were arguing about this. 1004 00:43:44,220 --> 00:43:45,845 And it really seemed that they were not 1005 00:43:45,845 --> 00:43:50,595 aware of this possibility, which was like, huh, 1006 00:43:50,595 --> 00:43:51,720 they don't know about this. 1007 00:43:51,720 --> 00:43:55,560 Cool, I guess that helps keep things safer because they were 1008 00:43:55,560 --> 00:43:58,950 arguing about how they were going to rent like hundreds 1009 00:43:58,950 --> 00:44:02,910 of millions of dollars of hash power to mine empty blocks 1010 00:44:02,910 --> 00:44:03,937 on the old chain. 1011 00:44:03,937 --> 00:44:06,270 It's like, you know you can do that for free if you just 1012 00:44:06,270 --> 00:44:08,670 change your software to make your new proof of work 1013 00:44:08,670 --> 00:44:10,490 and empty block on the old proof work, 1014 00:44:10,490 --> 00:44:12,240 but I don't think they were aware of that, 1015 00:44:12,240 --> 00:44:15,690 so we're like, OK let them go. 1016 00:44:15,690 --> 00:44:18,810 Anyway, and so the thing is it you can see how it would really 1017 00:44:18,810 --> 00:44:21,180 quickly turn into that, right? 1018 00:44:21,180 --> 00:44:24,210 If You've got 75%, well why would anyone 1019 00:44:24,210 --> 00:44:27,530 try to mine on this? 1020 00:44:27,530 --> 00:44:30,870 You could keep making blocks that did contain transactions, 1021 00:44:30,870 --> 00:44:32,490 but they would get orphaned out. 1022 00:44:32,490 --> 00:44:36,210 And everyone would, you might occasionally see, hey, 1023 00:44:36,210 --> 00:44:38,780 a block came out with transactions in it, 1024 00:44:38,780 --> 00:44:42,523 I just got reorged out, and nothing would ever come of it. 1025 00:44:42,523 --> 00:44:44,440 So you can see how the miners can never really 1026 00:44:44,440 --> 00:44:47,855 get paid on the minority fork and minority chain, 1027 00:44:47,855 --> 00:44:50,230 so they're all going to start switching to the new thing, 1028 00:44:50,230 --> 00:44:51,880 if they want to get paid. 1029 00:44:51,880 --> 00:44:53,500 So that's a little ugly. 1030 00:44:53,500 --> 00:44:55,330 This has not happened yet. 1031 00:44:55,330 --> 00:44:57,910 Hopefully, this doesn't happen, but on the other hand, 1032 00:44:57,910 --> 00:45:01,620 despite it being called evil, I know Luke Jr, 1033 00:45:01,620 --> 00:45:03,610 he's kind of crazy, but he's cool. 1034 00:45:03,610 --> 00:45:07,180 He was saying this is how we should do a hard fork, right? 1035 00:45:07,180 --> 00:45:08,800 We should also give people the option 1036 00:45:08,800 --> 00:45:11,800 to say, look, there's going to be a fork. 1037 00:45:11,800 --> 00:45:15,580 We give you the option to adopt a different system or doing 1038 00:45:15,580 --> 00:45:18,650 this so that no one's inadvertently left behind. 1039 00:45:18,650 --> 00:45:21,800 So we say, hey, a year from now, this is going to happen. 1040 00:45:21,800 --> 00:45:25,090 You can either say we actively refuse this new rule 1041 00:45:25,090 --> 00:45:27,940 and we've got our own chain now. 1042 00:45:27,940 --> 00:45:29,830 We make a soft fork before that point, 1043 00:45:29,830 --> 00:45:32,380 or we adopt this new rule, update our software, 1044 00:45:32,380 --> 00:45:35,390 and now I've got this new proof of work. 1045 00:45:35,390 --> 00:45:36,920 The thing is, the new proof of work, 1046 00:45:36,920 --> 00:45:38,600 you don't need new chips, right? 1047 00:45:38,600 --> 00:45:42,210 You just need to do a little bit different software. 1048 00:45:42,210 --> 00:45:46,450 OK any questions about evil forks? 1049 00:45:46,450 --> 00:45:46,950 Kind of fun. 1050 00:45:46,950 --> 00:45:47,450 Yeah? 1051 00:45:47,450 --> 00:45:49,510 AUDIENCE: [INAUDIBLE] an empty block? 1052 00:45:49,510 --> 00:45:52,010 PROFESSOR: Well, OK every block has to have one transaction, 1053 00:45:52,010 --> 00:45:54,840 so you'd have the coinbase transaction, 1054 00:45:54,840 --> 00:46:00,250 but any user created transactions would not be. 1055 00:46:00,250 --> 00:46:02,700 And, yeah, in the case where there's only one transaction 1056 00:46:02,700 --> 00:46:04,800 the Merkle root just becomes the TXID 1057 00:46:04,800 --> 00:46:08,790 of that single transaction, and you can put arbitrary data 1058 00:46:08,790 --> 00:46:11,640 in that single transaction. 1059 00:46:11,640 --> 00:46:14,010 The input field-- yeah we said-- the input field 1060 00:46:14,010 --> 00:46:17,340 for that coinbase transaction that generates new coins can 1061 00:46:17,340 --> 00:46:18,930 be any arbitrary data you want. 1062 00:46:18,930 --> 00:46:22,962 So you could put a Merkle root from your real block in there, 1063 00:46:22,962 --> 00:46:25,420 and then write your new software and say, OK, the new proof 1064 00:46:25,420 --> 00:46:29,100 of work is the header with the nonce, 1065 00:46:29,100 --> 00:46:32,720 also it's got to have a coinbase transaction, and then 1066 00:46:32,720 --> 00:46:35,160 a real Merkle root in the coinbase transaction, 1067 00:46:35,160 --> 00:46:38,073 and then build out your treat from there. 1068 00:46:38,073 --> 00:46:38,990 So it's a little ugly. 1069 00:46:38,990 --> 00:46:42,222 It's a little more complex, it would totally work though. 1070 00:46:42,222 --> 00:46:43,680 And all the old software would just 1071 00:46:43,680 --> 00:46:45,000 be like, huh, no transactions. 1072 00:46:45,000 --> 00:46:47,583 And all the new software knows that that's not a real coinbase 1073 00:46:47,583 --> 00:46:48,600 transaction. 1074 00:46:48,600 --> 00:46:53,280 It's just a part of the extended header. 1075 00:46:53,280 --> 00:46:53,880 OK. 1076 00:46:53,880 --> 00:46:56,300 Cool. 1077 00:46:56,300 --> 00:46:58,970 Don't try-- well, I mean, try this at home, if you want. 1078 00:46:58,970 --> 00:47:02,030 I don't know. 1079 00:47:02,030 --> 00:47:05,780 Yeah, seems coercive, thus evil, people call it. 1080 00:47:05,780 --> 00:47:09,450 OK, yeah, fork coordination. 1081 00:47:09,450 --> 00:47:13,020 How do you go a level up from this. 1082 00:47:13,020 --> 00:47:15,570 How do we know to do all these things? 1083 00:47:15,570 --> 00:47:19,140 Reddit, IRC, Twitter, there's-- 1084 00:47:19,140 --> 00:47:23,430 these systems exist on the real world and people talk. 1085 00:47:23,430 --> 00:47:25,270 Like the meeting I was at last week. 1086 00:47:25,270 --> 00:47:27,510 We actually didn't talk about forks much, 1087 00:47:27,510 --> 00:47:31,320 we sort of did, but the developers get together, 1088 00:47:31,320 --> 00:47:35,172 companies using bitcoin, all sorts of stuff. 1089 00:47:35,172 --> 00:47:36,630 Yeah, no, on Wednesday, people were 1090 00:47:36,630 --> 00:47:38,273 arguing about MAST versus Schnorr which 1091 00:47:38,273 --> 00:47:39,690 is more important, which we should 1092 00:47:39,690 --> 00:47:41,970 try to soft fork in first. 1093 00:47:41,970 --> 00:47:44,100 Not much gets done. 1094 00:47:44,100 --> 00:47:46,350 So it used to be called BIP9. 1095 00:47:46,350 --> 00:47:47,570 That's still there. 1096 00:47:47,570 --> 00:47:49,770 Bitcoin Improvement Protocol 9. 1097 00:47:49,770 --> 00:47:54,330 It was the idea in the header field in the version field, 1098 00:47:54,330 --> 00:47:57,300 you can set these flag bits for which soft forks 1099 00:47:57,300 --> 00:48:00,060 you are adopting, right so you indicate 1100 00:48:00,060 --> 00:48:04,067 before adopting a fork which one you're ready to adopt. 1101 00:48:04,067 --> 00:48:06,150 And then you don't actually implement the adoption 1102 00:48:06,150 --> 00:48:10,560 until you see some threshold to say, OK, once 95% of people 1103 00:48:10,560 --> 00:48:14,040 are signaling that we have this new operation, 1104 00:48:14,040 --> 00:48:15,780 we'll all enforce it. 1105 00:48:15,780 --> 00:48:18,990 Because quite likely the software people 1106 00:48:18,990 --> 00:48:20,160 don't want this. 1107 00:48:20,160 --> 00:48:22,320 A lot of times you say, look, I want this new rule. 1108 00:48:22,320 --> 00:48:24,150 I want this new signature system or I 1109 00:48:24,150 --> 00:48:26,490 want this new even, odd thing. 1110 00:48:26,490 --> 00:48:29,500 It would be really better if everyone only used on numbers. 1111 00:48:29,500 --> 00:48:31,470 However, I'm not willing to split off 1112 00:48:31,470 --> 00:48:32,940 because of this, right. 1113 00:48:32,940 --> 00:48:35,852 I want everyone on board, or at least the majority on board. 1114 00:48:35,852 --> 00:48:36,810 So we have a new split. 1115 00:48:36,810 --> 00:48:39,720 We get the new one, this is what I want. 1116 00:48:39,720 --> 00:48:42,543 I like the rule but I'm not willing to put 1117 00:48:42,543 --> 00:48:44,960 a stake in the ground say, look, I'm making my own network 1118 00:48:44,960 --> 00:48:46,025 if you don't like it. 1119 00:48:46,025 --> 00:48:47,400 So in order to do that, we say we 1120 00:48:47,400 --> 00:48:49,980 want to get a majority of mining power 1121 00:48:49,980 --> 00:48:52,890 to adopt it before we start doing it. 1122 00:48:52,890 --> 00:48:55,830 And so that way we can signal in the header 1123 00:48:55,830 --> 00:48:58,110 that, hey, I'm aware of this new rule, 1124 00:48:58,110 --> 00:49:01,440 and I will enforce it if everyone else says 1125 00:49:01,440 --> 00:49:05,190 they're going to enforce it so a staging process. 1126 00:49:05,190 --> 00:49:06,900 So that was called BIT9, and the idea 1127 00:49:06,900 --> 00:49:11,820 is once 95% are signaling it, then you activate it. 1128 00:49:11,820 --> 00:49:14,160 This didn't actually work in practice. 1129 00:49:14,160 --> 00:49:17,370 I think it worked once with the OP_CHECKS sequence verify, 1130 00:49:17,370 --> 00:49:19,573 and then last year, people were just 1131 00:49:19,573 --> 00:49:21,240 arguing in the miners are like, no we're 1132 00:49:21,240 --> 00:49:23,570 not going to activate any new soft forks, 1133 00:49:23,570 --> 00:49:27,180 or then, they started making all these deals-- it was a mess. 1134 00:49:27,180 --> 00:49:28,080 Governance, yeah. 1135 00:49:31,090 --> 00:49:34,750 OK, so, yeah, the future of soft forks is definitely unclear. 1136 00:49:34,750 --> 00:49:37,133 This is very much in flux. 1137 00:49:37,133 --> 00:49:38,800 How is this going to work in the future? 1138 00:49:38,800 --> 00:49:41,890 How are people going to agree on these things, right? 1139 00:49:41,890 --> 00:49:44,982 It seems, a lot of the times, from the developer perspective, 1140 00:49:44,982 --> 00:49:45,940 it seems like, why not? 1141 00:49:45,940 --> 00:49:48,280 Like, hey, we made this cool new signature system. 1142 00:49:48,280 --> 00:49:52,570 It's faster, it's more secure, it saves space, let's use it. 1143 00:49:52,570 --> 00:49:56,590 And then people say, no and you're like, well, why? 1144 00:49:56,590 --> 00:49:57,380 Things like that. 1145 00:49:57,380 --> 00:49:58,720 But on the other hand, if it's like, no. 1146 00:49:58,720 --> 00:49:59,762 We only have odd outputs. 1147 00:49:59,762 --> 00:50:00,500 It's like, why? 1148 00:50:00,500 --> 00:50:01,000 Who cares. 1149 00:50:01,000 --> 00:50:03,790 Let's use, even and odd numbers. 1150 00:50:03,790 --> 00:50:06,760 OK so another aspect with the forks. 1151 00:50:06,760 --> 00:50:08,290 Transaction replay. 1152 00:50:08,290 --> 00:50:10,460 So this is tricky. 1153 00:50:10,460 --> 00:50:11,380 So a split happens. 1154 00:50:11,380 --> 00:50:14,920 Let's say in the case of a minority soft fork, 1155 00:50:14,920 --> 00:50:18,970 or a majority, but not unanimous hard fork, 1156 00:50:18,970 --> 00:50:23,380 or a full fork, something like that. 1157 00:50:23,380 --> 00:50:24,610 There's a split, right? 1158 00:50:24,610 --> 00:50:27,070 There's two chains that are now being extended. 1159 00:50:27,070 --> 00:50:28,900 You make a transaction on the old chain 1160 00:50:28,900 --> 00:50:30,673 what happens on the new chain? 1161 00:50:33,530 --> 00:50:35,294 Yes? 1162 00:50:35,294 --> 00:50:36,290 AUDIENCE: [INAUDIBLE] 1163 00:50:36,290 --> 00:50:36,957 PROFESSOR: Yeah. 1164 00:50:36,957 --> 00:50:40,870 [INAUDIBLE] it and it happens on both, right? 1165 00:50:40,870 --> 00:50:43,120 In many cases, these transactions 1166 00:50:43,120 --> 00:50:44,440 are valid on either. 1167 00:50:44,440 --> 00:50:46,420 And so they can be rebroadcast or relayed 1168 00:50:46,420 --> 00:50:48,060 between the two networks. 1169 00:50:48,060 --> 00:50:50,530 And if it can be relayed between the two networks, it will. 1170 00:50:50,530 --> 00:50:53,590 Someone's going to set up a little script that 1171 00:50:53,590 --> 00:50:56,530 grabs all the transactions on one chain, broadcast them 1172 00:50:56,530 --> 00:50:59,302 on the other, even if you don't want them to someone 1173 00:50:59,302 --> 00:51:01,210 will do that, right? 1174 00:51:01,210 --> 00:51:04,630 And if it's valid on both, it gets confirmed on both. 1175 00:51:04,630 --> 00:51:06,640 And so you say, OK, it now splits. 1176 00:51:06,640 --> 00:51:08,170 There's now two different histories. 1177 00:51:10,870 --> 00:51:14,727 At the time of the split, now I've got coins on both, right? 1178 00:51:14,727 --> 00:51:16,810 I don't usually think of it when it's a short term 1179 00:51:16,810 --> 00:51:19,480 split as I now have two types of coins, but I do. 1180 00:51:19,480 --> 00:51:21,580 If these extend indefinitely and they're never 1181 00:51:21,580 --> 00:51:25,750 going to reconverge, well, I've still got the UTXOs on both. 1182 00:51:25,750 --> 00:51:29,590 I can make a transaction here, and maybe it gets relayed here 1183 00:51:29,590 --> 00:51:31,460 and now they move on both sides. 1184 00:51:31,460 --> 00:51:32,800 Or maybe it doesn't. 1185 00:51:32,800 --> 00:51:35,860 So you can you can potentially-- and eventually the UTXO sets 1186 00:51:35,860 --> 00:51:37,330 will diverge, right. 1187 00:51:37,330 --> 00:51:38,680 How do you diverge these things? 1188 00:51:38,680 --> 00:51:41,950 Well, if you mix it with coins that have been mined, 1189 00:51:41,950 --> 00:51:45,640 so you know that the mine, the new coinbase, 1190 00:51:45,640 --> 00:51:48,340 the new coins here, are definitely different, right? 1191 00:51:48,340 --> 00:51:50,110 Those are going to have different TXIDs. 1192 00:51:50,110 --> 00:51:52,840 Coins that got mined here will not exist on this one, and vise 1193 00:51:52,840 --> 00:51:53,630 versa. 1194 00:51:53,630 --> 00:51:55,360 So eventually, more and more coins 1195 00:51:55,360 --> 00:51:59,350 start getting mixed in with each other and they will diverge. 1196 00:51:59,350 --> 00:52:00,533 That takes a while though. 1197 00:52:00,533 --> 00:52:01,950 Another thing you can try to doing 1198 00:52:01,950 --> 00:52:03,490 is a spamming double spends. 1199 00:52:03,490 --> 00:52:04,490 I'm going to send this-- 1200 00:52:04,490 --> 00:52:07,090 I'll make a transaction, Alice pays Bob, I also 1201 00:52:07,090 --> 00:52:09,130 make a transaction, Alice pays Carol. 1202 00:52:09,130 --> 00:52:12,430 I just send one to one place, one to the other, 1203 00:52:12,430 --> 00:52:14,680 hope they get in. 1204 00:52:14,680 --> 00:52:18,370 Eventually, they'll start diverging just by chance. 1205 00:52:18,370 --> 00:52:20,540 You can also try exploiting locktime deltas. 1206 00:52:20,540 --> 00:52:24,710 So in many cases, the heights will be different, 1207 00:52:24,710 --> 00:52:26,090 and you can say, OK, I'm here. 1208 00:52:26,090 --> 00:52:27,673 I'm going to make a transaction that's 1209 00:52:27,673 --> 00:52:30,390 only valid after block 5. 1210 00:52:30,390 --> 00:52:32,440 And if someone replays it here, they're 1211 00:52:32,440 --> 00:52:35,433 going to have to wait 2 blocks before it's valid. 1212 00:52:35,433 --> 00:52:36,850 And then this gets confirmed here, 1213 00:52:36,850 --> 00:52:39,267 and then I make a different transaction spending the coins 1214 00:52:39,267 --> 00:52:40,570 here without a time lock. 1215 00:52:40,570 --> 00:52:43,570 And so I can try to exploit the fact that there's 1216 00:52:43,570 --> 00:52:46,060 timing differences between the two chains 1217 00:52:46,060 --> 00:52:48,640 to make a transaction A occur on the top one, 1218 00:52:48,640 --> 00:52:50,650 and transaction B occur on the bottom one, 1219 00:52:50,650 --> 00:52:53,980 and split my coins off that way. 1220 00:52:53,980 --> 00:52:57,130 So those are potential ways to split your coins, 1221 00:52:57,130 --> 00:52:59,440 despite these transaction replays. 1222 00:52:59,440 --> 00:53:01,210 And then you can now say, OK, I have two 1223 00:53:01,210 --> 00:53:05,260 separate wallets, two separate keys on the different chains. 1224 00:53:05,260 --> 00:53:06,700 However, yes, this is expensive. 1225 00:53:06,700 --> 00:53:07,720 This is ugly. 1226 00:53:07,720 --> 00:53:10,090 It's possible, but it's ugly because you're basically 1227 00:53:10,090 --> 00:53:13,760 going to spam the network and in many cases, 1228 00:53:13,760 --> 00:53:15,700 you're not actually trying to send money, 1229 00:53:15,700 --> 00:53:19,505 you're just moving your own money around internally. 1230 00:53:19,505 --> 00:53:21,130 So if everyone does that in the system, 1231 00:53:21,130 --> 00:53:23,890 it can overload the system, have tons of transactions, 1232 00:53:23,890 --> 00:53:26,188 also if you're doing this, it might not work. 1233 00:53:26,188 --> 00:53:27,730 And you're like, OK, I just confirmed 1234 00:53:27,730 --> 00:53:31,180 a transaction for no point whatsoever, got to keep trying. 1235 00:53:31,180 --> 00:53:32,830 It's pretty ugly. 1236 00:53:32,830 --> 00:53:39,160 Also, people don't know, so why is this a problem? 1237 00:53:39,160 --> 00:53:42,210 Well, in many cases, you want to sell one and not the other. 1238 00:53:42,210 --> 00:53:45,840 In addition to these software rules, 1239 00:53:45,840 --> 00:53:48,690 such as bonus coins for each transaction 1240 00:53:48,690 --> 00:53:51,180 or only odd numbers allowed, there are often 1241 00:53:51,180 --> 00:53:55,440 philosophical and cultural rules that get associated with it, 1242 00:53:55,440 --> 00:53:57,690 and people hate each other and yell at each other 1243 00:53:57,690 --> 00:54:00,690 and insult each other on the internet all the time. 1244 00:54:00,690 --> 00:54:04,170 This is-- I don't think this is unique to bitcoin 1245 00:54:04,170 --> 00:54:05,910 or cryptocurrencies, I think it's just, 1246 00:54:05,910 --> 00:54:09,340 you got money involved, you got trolls on the internet, 1247 00:54:09,340 --> 00:54:14,400 it's a rich mixture of the best parts of humanity. 1248 00:54:14,400 --> 00:54:18,390 So a lot of times people want to sell one or the other. 1249 00:54:18,390 --> 00:54:20,760 So they say, I think the odd coin is stupid. 1250 00:54:20,760 --> 00:54:24,330 I'm going to sell it, and someone wants to buy it 1251 00:54:24,330 --> 00:54:26,400 and I'll get these new coins. 1252 00:54:26,400 --> 00:54:30,310 That's difficult if transaction replays are occurring. 1253 00:54:30,310 --> 00:54:31,740 Another problem is that many users 1254 00:54:31,740 --> 00:54:33,390 could be unaware of the forks. 1255 00:54:33,390 --> 00:54:34,760 I know a lot of people-- 1256 00:54:34,760 --> 00:54:38,580 there have been a bunch of full forks in bitcoin recently, 1257 00:54:38,580 --> 00:54:41,263 where different rules have to been adopted. 1258 00:54:41,263 --> 00:54:42,930 In many cases, entirely different proofs 1259 00:54:42,930 --> 00:54:45,570 of works, things like that. 1260 00:54:45,570 --> 00:54:47,250 I'm not aware of all of them. 1261 00:54:47,250 --> 00:54:49,330 I know of some of them. 1262 00:54:49,330 --> 00:54:51,360 Most people I know don't know of all of them 1263 00:54:51,360 --> 00:54:53,340 or even any of them. 1264 00:54:53,340 --> 00:54:56,048 So users might unknowingly send both or not 1265 00:54:56,048 --> 00:54:57,090 be aware of these things. 1266 00:54:57,090 --> 00:54:58,890 That's an issue. 1267 00:54:58,890 --> 00:55:01,170 There's also all sorts of crazy legal issues. 1268 00:55:01,170 --> 00:55:04,320 Talking to exchanges, where like, OK, this fork happens. 1269 00:55:04,320 --> 00:55:08,110 Do we owe our customers both? 1270 00:55:08,110 --> 00:55:11,680 Do we only owe them the one that-- 1271 00:55:11,680 --> 00:55:15,370 and which does the exchange have to let 1272 00:55:15,370 --> 00:55:18,280 people decide to adopt or ignore new rules set? 1273 00:55:18,280 --> 00:55:21,730 There's all sorts of weird legal issues 1274 00:55:21,730 --> 00:55:26,790 that are still being settled. 1275 00:55:26,790 --> 00:55:31,780 And for one example, you can do a replay attack on exchange 1276 00:55:31,780 --> 00:55:36,010 and this is not a theoretical example, this has happened. 1277 00:55:36,010 --> 00:55:37,810 So let's say the network splits, right? 1278 00:55:37,810 --> 00:55:42,490 You get bonus coin and regular old coin. 1279 00:55:42,490 --> 00:55:45,640 And the bonus coin has a majority hash rate, 1280 00:55:45,640 --> 00:55:48,640 and there's no kind of replay protection. 1281 00:55:48,640 --> 00:55:50,860 All the transactions that are valid in one 1282 00:55:50,860 --> 00:55:52,250 are valid in the other. 1283 00:55:52,250 --> 00:55:54,790 OK, so the network splits into coinA and coinB. 1284 00:55:54,790 --> 00:55:57,487 And the exchange is only running coinB. 1285 00:55:57,487 --> 00:55:59,320 They say, look, this has the most hash power 1286 00:55:59,320 --> 00:56:03,010 and that's what defines the system. 1287 00:56:03,010 --> 00:56:04,545 They adopt a new rule, fine. 1288 00:56:04,545 --> 00:56:06,795 There's this new rule that you can generate a coin out 1289 00:56:06,795 --> 00:56:08,300 of nothing. 1290 00:56:08,300 --> 00:56:10,530 So the user says to the exchange, 1291 00:56:10,530 --> 00:56:13,030 OK, I'm going to deposit coinB. 1292 00:56:13,030 --> 00:56:14,860 The exchange says, yes, I acknowledge 1293 00:56:14,860 --> 00:56:16,510 your deposit of coinB. 1294 00:56:16,510 --> 00:56:18,940 That's the network I'm running on, I see your transaction, 1295 00:56:18,940 --> 00:56:19,607 it's in a block. 1296 00:56:19,607 --> 00:56:21,790 Cool, you've got a balance. 1297 00:56:21,790 --> 00:56:23,890 And the user says, changed my mind. 1298 00:56:23,890 --> 00:56:27,080 I'm withdrawing coinB and the exchange-- 1299 00:56:27,080 --> 00:56:29,390 so what happens next? 1300 00:56:29,390 --> 00:56:31,020 The exchange says, sure. 1301 00:56:31,020 --> 00:56:31,660 Here's coinB. 1302 00:56:31,660 --> 00:56:33,790 Oh, and coinA, right? 1303 00:56:33,790 --> 00:56:36,370 The exchange doesn't implement any replay protection. 1304 00:56:36,370 --> 00:56:37,150 They don't know. 1305 00:56:37,150 --> 00:56:40,090 They don't acknowledge the existence of this other chain. 1306 00:56:40,090 --> 00:56:42,310 They don't know they have coinA, and they 1307 00:56:42,310 --> 00:56:46,580 should because they actively split but whatever. 1308 00:56:46,580 --> 00:56:49,510 And then the users like, cool I got both, right. 1309 00:56:49,510 --> 00:56:52,600 I relayed this transaction between the two networks. 1310 00:56:52,600 --> 00:56:55,180 I was now able to deposit only coinB 1311 00:56:55,180 --> 00:56:57,940 and withdraw both coinA and coinB. 1312 00:56:57,940 --> 00:57:00,280 And now I redeposit-- 1313 00:57:00,280 --> 00:57:05,760 I split again, I redeposit coinB, and I keep doing that. 1314 00:57:05,760 --> 00:57:09,570 And so I can drain the exchange of all of their coinA 1315 00:57:09,570 --> 00:57:11,730 with the same amount of coinB just 1316 00:57:11,730 --> 00:57:16,380 looping through depositing and withdrawing. 1317 00:57:16,380 --> 00:57:17,752 So, yeah, this happens. 1318 00:57:17,752 --> 00:57:19,210 Does anyone-- I mean, I'm not going 1319 00:57:19,210 --> 00:57:23,570 to say which exchange was susceptible to this attack. 1320 00:57:23,570 --> 00:57:25,990 Does anyone know? 1321 00:57:25,990 --> 00:57:28,910 It shares a name with the first transaction in the block. 1322 00:57:28,910 --> 00:57:34,300 Anyway, so yeah, that was almost two years ago, a year 1323 00:57:34,300 --> 00:57:36,940 and a half ago with the ethereum, 1324 00:57:36,940 --> 00:57:39,550 ethereum classic hard fork. 1325 00:57:39,550 --> 00:57:41,680 That happened. 1326 00:57:41,680 --> 00:57:44,200 So that was-- it happened. 1327 00:57:44,200 --> 00:57:46,390 I'm not saying, yeah, it's not obvious, right? 1328 00:57:46,390 --> 00:57:49,600 These are some attacks that are like huh. 1329 00:57:49,600 --> 00:57:52,330 In retrospect, it wasn't that hard to find out. 1330 00:57:52,330 --> 00:57:54,925 I'm sure the people at the exchange were like huh, shoot. 1331 00:57:54,925 --> 00:57:56,800 Yeah, we probably should've seen that coming, 1332 00:57:56,800 --> 00:57:58,450 and we lost a couple of million bucks. 1333 00:57:58,450 --> 00:58:00,340 Shoot. 1334 00:58:00,340 --> 00:58:04,060 It's also weird because all of their users like generally 1335 00:58:04,060 --> 00:58:07,165 are identified, and they have their password 1336 00:58:07,165 --> 00:58:09,040 or where they live, and so you could probably 1337 00:58:09,040 --> 00:58:14,000 tell like, hey, come on dude, give it back. 1338 00:58:14,000 --> 00:58:16,058 But maybe they didn't because they like, well, 1339 00:58:16,058 --> 00:58:18,100 tech-- because they might have a program in a way 1340 00:58:18,100 --> 00:58:19,150 where they could deny it. 1341 00:58:19,150 --> 00:58:22,300 And say, look, I just deposited and withdrew a couple times. 1342 00:58:22,300 --> 00:58:23,890 That's what I always do, I don't know. 1343 00:58:26,082 --> 00:58:27,790 But yeah, there were definitely warnings. 1344 00:58:27,790 --> 00:58:30,850 There were there were a lot of people saying, hey, 1345 00:58:30,850 --> 00:58:31,600 this is dangerous. 1346 00:58:31,600 --> 00:58:35,030 You need to really implement replay protection. 1347 00:58:35,030 --> 00:58:38,980 If there is a fork without replay protection implemented, 1348 00:58:38,980 --> 00:58:41,090 the exchanges really need to honor 1349 00:58:41,090 --> 00:58:44,110 and try to split both before offering both for a deposit 1350 00:58:44,110 --> 00:58:47,090 and withdrawal, things like that. 1351 00:58:47,090 --> 00:58:49,630 And so there's been a lot, last year as well, 1352 00:58:49,630 --> 00:58:52,810 there's a lot of argument because in bitcoin, 1353 00:58:52,810 --> 00:58:57,010 one group of people wanted to SegWit2x, 1354 00:58:57,010 --> 00:58:58,000 was what it was called. 1355 00:58:58,000 --> 00:59:01,490 And they wanted to implement a hard fork 1356 00:59:01,490 --> 00:59:04,537 and not implement replay protection. 1357 00:59:04,537 --> 00:59:06,870 And so that was a big argument where people were saying, 1358 00:59:06,870 --> 00:59:10,550 look, if you're going to make a hard fork, make it a full fork. 1359 00:59:10,550 --> 00:59:14,000 Make it implement so that you're going to go off, but also 1360 00:59:14,000 --> 00:59:15,470 implement replay protection. 1361 00:59:15,470 --> 00:59:18,410 Make it so that transactions that you guys signed 1362 00:59:18,410 --> 00:59:20,483 are slightly different than the old way. 1363 00:59:20,483 --> 00:59:21,650 And it's not too hard to do. 1364 00:59:21,650 --> 00:59:25,640 What you can do is when you're making a signature, 1365 00:59:25,640 --> 00:59:26,710 flip some bits. 1366 00:59:26,710 --> 00:59:27,210 Well, OK. 1367 00:59:27,210 --> 00:59:28,820 You can't flip bits in the signature 1368 00:59:28,820 --> 00:59:31,013 itself because those can be flipped back, 1369 00:59:31,013 --> 00:59:32,930 but what you can do is you can like flip a bit 1370 00:59:32,930 --> 00:59:36,140 or two in the hash that you're signing, 1371 00:59:36,140 --> 00:59:38,930 and then the old software won't be aware of that flip and say, 1372 00:59:38,930 --> 00:59:41,117 look, this doesn't look like a valid signature 1373 00:59:41,117 --> 00:59:43,700 because it's trying to compare it against a different message. 1374 00:59:43,700 --> 00:59:45,492 Or you can like a pen, something at the end 1375 00:59:45,492 --> 00:59:47,660 of the message you're signing, things like that. 1376 00:59:47,660 --> 00:59:52,820 So that on the new network, the signatures look different. 1377 00:59:52,820 --> 00:59:54,860 And that helps in terms of safety 1378 00:59:54,860 --> 00:59:57,920 because then the old software that's ignoring 1379 00:59:57,920 --> 01:00:00,260 will not inadvertently send transactions. 1380 01:00:00,260 --> 01:00:03,050 And also for the new network, they 1381 01:00:03,050 --> 01:00:05,690 will not inadvertently send transactions 1382 01:00:05,690 --> 01:00:07,400 on the old network. 1383 01:00:07,400 --> 01:00:12,740 So that's-- and there's a lot of ideas of opt in versus opt out 1384 01:00:12,740 --> 01:00:15,650 replay protection, where you can like allow the option to sign 1385 01:00:15,650 --> 01:00:17,900 differently, but not require it. 1386 01:00:17,900 --> 01:00:20,930 All sorts of weird ways you can do it. 1387 01:00:20,930 --> 01:00:24,800 But yeah, this is a fairly recent mostly last summer, 1388 01:00:24,800 --> 01:00:27,417 last fall, people were trying to do different things. 1389 01:00:27,417 --> 01:00:28,250 And so in practice-- 1390 01:00:28,250 --> 01:00:29,590 I think this is the end of it. 1391 01:00:29,590 --> 01:00:32,680 Let me go two more minutes. 1392 01:00:32,680 --> 01:00:34,210 But yeah, consensus change is hard. 1393 01:00:34,210 --> 01:00:38,650 In practice, there's been some full forks recently. 1394 01:00:38,650 --> 01:00:41,500 The last soft fork was Segregated Witness SegWit 1395 01:00:41,500 --> 01:00:46,840 happened sometime in September last year. 1396 01:00:46,840 --> 01:00:50,550 It was it was a mess, and there was also some full forks. 1397 01:00:50,550 --> 01:00:52,548 Bitcoin Cash, and then later Bitcoin Gold, 1398 01:00:52,548 --> 01:00:54,340 which is a lot smaller, and they completely 1399 01:00:54,340 --> 01:00:55,480 changed the proof of work. 1400 01:00:55,480 --> 01:00:57,780 And now they're a bunch that are like pushing 1401 01:00:57,780 --> 01:00:59,530 the definition of full fork, where they're 1402 01:00:59,530 --> 01:01:02,680 basically like also called airdrops, where it's 1403 01:01:02,680 --> 01:01:05,770 sort of a completely different coin that just happens to have 1404 01:01:05,770 --> 01:01:07,735 the UTXO side of the old coin. 1405 01:01:07,735 --> 01:01:09,860 And so it's like, why even bother with the history. 1406 01:01:09,860 --> 01:01:11,680 We're just like look, it's a new coin 1407 01:01:11,680 --> 01:01:16,420 that you inherit all these other coins. 1408 01:01:16,420 --> 01:01:19,750 Yeah, so there's a bunch of those. 1409 01:01:19,750 --> 01:01:21,640 It's a mess, it's fun being-- 1410 01:01:21,640 --> 01:01:25,565 I could not have given this lecture a year ago. 1411 01:01:25,565 --> 01:01:27,190 A lot of these things had not happened. 1412 01:01:27,190 --> 01:01:29,440 A lot of these terms were not well defined. 1413 01:01:29,440 --> 01:01:32,760 A few years ago, the idea of soft, hard forks 1414 01:01:32,760 --> 01:01:34,060 were not even defined. 1415 01:01:34,060 --> 01:01:38,560 It's pretty clear that Satoshi later, after releasing bitcoin 1416 01:01:38,560 --> 01:01:40,840 started to understand this system. 1417 01:01:40,840 --> 01:01:44,140 But in the beginning, there was not a clear understanding. 1418 01:01:44,140 --> 01:01:48,790 Probably the biggest, contentious software in 2009 1419 01:01:48,790 --> 01:01:53,020 was that Satoshi added a 1 megabyte block size limit. 1420 01:01:53,020 --> 01:01:58,180 And to reverse a soft fork, is a hard fork, and so this 1421 01:01:58,180 --> 01:01:59,470 blocks out his hard fork. 1422 01:01:59,470 --> 01:02:01,810 And then there is a very clever way with SegWit 1423 01:02:01,810 --> 01:02:05,950 to make it a software, but also increase the block 1424 01:02:05,950 --> 01:02:10,490 size in a weird way that the old software wouldn't recognize. 1425 01:02:10,490 --> 01:02:14,380 I might have to explain a little SegWit to you next week. 1426 01:02:14,380 --> 01:02:16,210 OK, so yeah. 1427 01:02:16,210 --> 01:02:17,830 It's a feature and a bug, right? 1428 01:02:17,830 --> 01:02:22,090 Consensus changes in these systems can be very difficult. 1429 01:02:22,090 --> 01:02:24,190 On the one hand, you want your coins to stay put. 1430 01:02:24,190 --> 01:02:25,910 You don't want your money to change. 1431 01:02:25,910 --> 01:02:28,390 You want to be able to just have a bunch of money, 1432 01:02:28,390 --> 01:02:30,850 and a year later, you still have a bunch of money, 1433 01:02:30,850 --> 01:02:33,470 and that's what you want to do. 1434 01:02:33,470 --> 01:02:35,620 On the other hand, new features are cool. 1435 01:02:35,620 --> 01:02:38,230 And these are not-- 1436 01:02:38,230 --> 01:02:41,020 you don't want these to be ossified legacy systems, 1437 01:02:41,020 --> 01:02:42,910 you want this to be like new, cool technology 1438 01:02:42,910 --> 01:02:46,210 and you go make all these new cool things. 1439 01:02:46,210 --> 01:02:48,490 And make it faster, and better, stronger. 1440 01:02:48,490 --> 01:02:51,610 And the role of miners is also a big point of contention, right? 1441 01:02:51,610 --> 01:02:56,500 They seem to have outsize influence in some ways, right? 1442 01:02:56,500 --> 01:03:00,310 Up here is the mining power and how that affects things. 1443 01:03:00,310 --> 01:03:02,800 And why should these miners have outsize influence? 1444 01:03:02,800 --> 01:03:05,333 Shouldn't the users themselves be able to vote? 1445 01:03:05,333 --> 01:03:06,250 But they can't, right? 1446 01:03:06,250 --> 01:03:07,667 If the users could vote, maybe you 1447 01:03:07,667 --> 01:03:11,560 wouldn't need mining at all to verify block chain. 1448 01:03:11,560 --> 01:03:14,230 So there will continue to be a lot of debate 1449 01:03:14,230 --> 01:03:16,690 on this stuff going into the future. 1450 01:03:16,690 --> 01:03:20,410 I hope this helped explain the general thinking as 1451 01:03:20,410 --> 01:03:24,170 of early 2018, but it'll probably change. 1452 01:03:24,170 --> 01:03:24,880 Cool. 1453 01:03:24,880 --> 01:03:28,833 Any other questions about this whole thing? 1454 01:03:28,833 --> 01:03:30,500 If you have a light-- like I don't know, 1455 01:03:30,500 --> 01:03:33,810 James helps develop Vertcoin, right? 1456 01:03:33,810 --> 01:03:36,690 Are hard forks and soft forks difficult in Vertcoin? 1457 01:03:36,690 --> 01:03:39,230 No, you're like, hey, we're doing a hard fork. 1458 01:03:39,230 --> 01:03:43,500 AUDIENCE: [INAUDIBLE] the [? exchanges ?] 1459 01:03:43,500 --> 01:03:44,180 PROFESSOR: Yeah. 1460 01:03:44,180 --> 01:03:46,430 So in smaller communities, smaller coins, 1461 01:03:46,430 --> 01:03:49,010 where there's not as many people involved and people are all 1462 01:03:49,010 --> 01:03:53,240 on the same page, these changes can be made fairly regularly, 1463 01:03:53,240 --> 01:03:54,620 not a huge deal. 1464 01:03:54,620 --> 01:03:55,723 Bitcoin is very messy. 1465 01:03:55,723 --> 01:03:57,140 Bitcoin everyone hates each other, 1466 01:03:57,140 --> 01:03:58,310 they're always trolling each other 1467 01:03:58,310 --> 01:04:00,080 on the internet and hacking each other, 1468 01:04:00,080 --> 01:04:02,510 death threats, all sorts of stuff. 1469 01:04:02,510 --> 01:04:04,310 So yeah, future forking methods-- there's 1470 01:04:04,310 --> 01:04:07,150 probably new, cool ways you can add to the bottom of that chart 1471 01:04:07,150 --> 01:04:11,150 some new idea that maybe works better. 1472 01:04:11,150 --> 01:04:12,989 So stay tuned.