1 00:00:01,050 --> 00:00:03,420 The following content is provided under a Creative 2 00:00:03,420 --> 00:00:04,810 Commons license. 3 00:00:04,810 --> 00:00:07,020 Your support will help MIT OpenCourseWare 4 00:00:07,020 --> 00:00:11,110 continue to offer high-quality educational resources for free. 5 00:00:11,110 --> 00:00:13,680 To make a donation or to view additional materials 6 00:00:13,680 --> 00:00:17,640 from hundreds of MIT courses, visit MIT OpenCourseWare 7 00:00:17,640 --> 00:00:18,513 at ocw.mit.edu. 8 00:00:22,270 --> 00:00:24,990 NEHA NARULA: So to start, we're going 9 00:00:24,990 --> 00:00:29,020 to recap what happened last class. 10 00:00:29,020 --> 00:00:32,950 And last class we were talking about how traditional payment 11 00:00:32,950 --> 00:00:36,280 systems work and some of the downsides 12 00:00:36,280 --> 00:00:40,600 when you had a bank in the middle 13 00:00:40,600 --> 00:00:44,260 even if you were using techniques like Chaumian e-cash 14 00:00:44,260 --> 00:00:48,010 to try to manage what the bank was doing. 15 00:00:48,010 --> 00:00:52,150 So just as a quick reminder, we had this kind of setup 16 00:00:52,150 --> 00:00:56,500 where there was Alice and there was Bob. 17 00:00:56,500 --> 00:00:58,420 In order to actually make transfers, 18 00:00:58,420 --> 00:01:01,500 Alice had to interact with the bank. 19 00:01:01,500 --> 00:01:05,060 And in the case of the traditional payment system, 20 00:01:05,060 --> 00:01:08,950 we saw that the bank could basically just say no, right? 21 00:01:08,950 --> 00:01:11,350 That it was always possible that a bank could decide 22 00:01:11,350 --> 00:01:13,900 that it didn't like Alice and it didn't 23 00:01:13,900 --> 00:01:16,420 want to process Alice's transactions. 24 00:01:16,420 --> 00:01:18,670 We got a little better than this with Chaumian e-cash, 25 00:01:18,670 --> 00:01:21,370 but even with Chaumian e-cash, the bank 26 00:01:21,370 --> 00:01:23,260 was required to do something. 27 00:01:23,260 --> 00:01:24,910 They were the ones minting the tokens, 28 00:01:24,910 --> 00:01:26,980 and they were the ones redeeming the tokens. 29 00:01:26,980 --> 00:01:31,420 So the banks still played an integral part in this system. 30 00:01:31,420 --> 00:01:35,270 And that actually really does make a difference. 31 00:01:35,270 --> 00:01:37,390 It's not just a theoretical problem. 32 00:01:37,390 --> 00:01:39,880 There are many accounts of people with, for example, 33 00:01:39,880 --> 00:01:43,727 PayPal accounts, who have their funds frozen, 34 00:01:43,727 --> 00:01:46,060 so they can't access the money that they have in PayPal. 35 00:01:46,060 --> 00:01:48,700 So this often happens to merchants, actually, 36 00:01:48,700 --> 00:01:51,597 who end up accepting customers from different countries, 37 00:01:51,597 --> 00:01:52,430 or things like this. 38 00:01:52,430 --> 00:01:55,030 They can get flagged by people's algorithms 39 00:01:55,030 --> 00:01:57,130 as being potentially fraudulent, and that 40 00:01:57,130 --> 00:01:59,800 can put a hold on their funds. 41 00:01:59,800 --> 00:02:01,840 In the case of Chaumian e-cash, you'll 42 00:02:01,840 --> 00:02:04,060 notice that we're not all running around using 43 00:02:04,060 --> 00:02:05,770 digital tokens issued by banks. 44 00:02:05,770 --> 00:02:07,630 Chaumian e-cash didn't really work out. 45 00:02:07,630 --> 00:02:09,729 And that was in part due to the fact 46 00:02:09,729 --> 00:02:12,730 that banks weren't really interested in implementing 47 00:02:12,730 --> 00:02:14,080 this technique. 48 00:02:14,080 --> 00:02:15,970 So-- OK. 49 00:02:15,970 --> 00:02:18,790 So this is where we ended last class, which 50 00:02:18,790 --> 00:02:21,760 was we're in this situation where 51 00:02:21,760 --> 00:02:25,450 the bank has a lot of control over payments 52 00:02:25,450 --> 00:02:27,640 and how payments happen. 53 00:02:27,640 --> 00:02:30,130 And something I want to emphasize here, as well, 54 00:02:30,130 --> 00:02:32,350 is this isn't-- 55 00:02:32,350 --> 00:02:35,050 it's not just that we worry about this 56 00:02:35,050 --> 00:02:38,320 because we want to do illegal activity. 57 00:02:38,320 --> 00:02:42,460 Having an institution in the middle of payments 58 00:02:42,460 --> 00:02:44,140 and being able to facilitate payments 59 00:02:44,140 --> 00:02:47,860 can be a problem in other ways, as well, because it can just 60 00:02:47,860 --> 00:02:49,570 simply make things slower. 61 00:02:49,570 --> 00:02:51,647 It can make things-- it's harder to innovate. 62 00:02:51,647 --> 00:02:53,230 It's harder to introduce new features. 63 00:02:53,230 --> 00:02:54,850 There's a sign up process. 64 00:02:54,850 --> 00:02:57,360 So there are reasons why we don't 65 00:02:57,360 --> 00:02:59,110 want to have an institution in the middle, 66 00:02:59,110 --> 00:03:02,170 even if we're totally honest actors. 67 00:03:02,170 --> 00:03:04,900 So the question-- so where we ended up 68 00:03:04,900 --> 00:03:08,920 was how do we build a decentralized digital token 69 00:03:08,920 --> 00:03:09,730 transfer? 70 00:03:09,730 --> 00:03:11,650 So we ended with Chaumian e-cash. 71 00:03:11,650 --> 00:03:13,942 And now we're in this position where what we want to do 72 00:03:13,942 --> 00:03:15,910 is we want to figure out how to make payments 73 00:03:15,910 --> 00:03:17,560 without a bank in the middle. 74 00:03:20,200 --> 00:03:21,700 So there's a few problems that we're 75 00:03:21,700 --> 00:03:25,240 going to have to address in order to make this happen, OK? 76 00:03:25,240 --> 00:03:29,890 So first of all, we really don't want 77 00:03:29,890 --> 00:03:31,690 it to be possible for other users 78 00:03:31,690 --> 00:03:34,840 to intercept a transfer of payment and steal funds. 79 00:03:34,840 --> 00:03:37,790 If our system can't support this very basic thing, 80 00:03:37,790 --> 00:03:39,040 then no one's going to use it. 81 00:03:39,040 --> 00:03:39,940 No one's going to trust it. 82 00:03:39,940 --> 00:03:41,148 No one's going to rely on it. 83 00:03:41,148 --> 00:03:44,230 So it's very important that we have security, right? 84 00:03:44,230 --> 00:03:46,660 Another aspect of security is that we 85 00:03:46,660 --> 00:03:48,790 don't want to allow people to spend money 86 00:03:48,790 --> 00:03:50,320 without authorization. 87 00:03:50,320 --> 00:03:53,170 There has to be some mechanism by which we're 88 00:03:53,170 --> 00:03:57,400 really sure it's Alice when Alice wants to make a payment. 89 00:04:00,940 --> 00:04:03,220 Another problem that we want to avoid 90 00:04:03,220 --> 00:04:04,750 is the double spend problem. 91 00:04:04,750 --> 00:04:06,430 So what is the double spend problem? 92 00:04:06,430 --> 00:04:09,970 Well-- oh, and an equivocation problem. 93 00:04:09,970 --> 00:04:11,500 So what is a double spend problem? 94 00:04:11,500 --> 00:04:14,710 Well, when you have digital tokens, 95 00:04:14,710 --> 00:04:16,990 the problem with digital information 96 00:04:16,990 --> 00:04:19,480 is that it can really easily be replicated, right? 97 00:04:19,480 --> 00:04:22,690 So you actually need to think pretty carefully. 98 00:04:22,690 --> 00:04:26,050 The naive solution of just having a unique string 99 00:04:26,050 --> 00:04:28,547 that you blast around as your a digital token 100 00:04:28,547 --> 00:04:29,380 doesn't really work. 101 00:04:29,380 --> 00:04:32,890 You have to do something extra to think about how to ensure 102 00:04:32,890 --> 00:04:33,790 that these-- 103 00:04:33,790 --> 00:04:37,810 once a token is spent, it cannot be spent again. 104 00:04:37,810 --> 00:04:40,210 Now, what I mean by the equivocation problem 105 00:04:40,210 --> 00:04:45,770 is you want to make sure that once a spend happens, 106 00:04:45,770 --> 00:04:48,340 it can't be taken back very easily, right? 107 00:04:48,340 --> 00:04:52,180 So if I'm being paid by Alice, I have some confidence 108 00:04:52,180 --> 00:04:55,000 that once I actually receive the money I've received the money. 109 00:04:55,000 --> 00:04:57,465 Alice can't renege on that promise, OK? 110 00:04:57,465 --> 00:04:58,840 So these are some of the problems 111 00:04:58,840 --> 00:05:02,500 that we want to solve with a decentralized digital payment 112 00:05:02,500 --> 00:05:04,750 system. 113 00:05:04,750 --> 00:05:07,388 And here are some of the features that we want to have, 114 00:05:07,388 --> 00:05:09,430 which is kind of related to some of the problems. 115 00:05:09,430 --> 00:05:12,880 So first of all, we want to make sure that anyone can use it. 116 00:05:12,880 --> 00:05:14,980 That's what we mean by the word decentralized. 117 00:05:14,980 --> 00:05:16,660 There's no single point of control. 118 00:05:16,660 --> 00:05:19,988 There's no one metering access to this system. 119 00:05:19,988 --> 00:05:22,530 If you want to make payments, if you want to join the system, 120 00:05:22,530 --> 00:05:23,970 you can join the system. 121 00:05:23,970 --> 00:05:25,920 So anyone can use it. 122 00:05:25,920 --> 00:05:29,370 We need authoritative transfer so that we can be sure 123 00:05:29,370 --> 00:05:32,280 that when Alice produces a transaction it's really her, 124 00:05:32,280 --> 00:05:33,833 and we believe that. 125 00:05:33,833 --> 00:05:36,000 And we want to make it so that you can't equivocate. 126 00:05:36,000 --> 00:05:38,190 You can't undo spends. 127 00:05:38,190 --> 00:05:41,940 So that translates into the following terminology 128 00:05:41,940 --> 00:05:44,190 that we often use with these systems. 129 00:05:44,190 --> 00:05:45,990 We want it to be permission-less. 130 00:05:45,990 --> 00:05:48,450 It doesn't require permission to enter the system. 131 00:05:48,450 --> 00:05:50,190 Anyone can join. 132 00:05:50,190 --> 00:05:51,960 Authoritative transfer, no double 133 00:05:51,960 --> 00:05:53,730 spends, and you can't undo. 134 00:05:53,730 --> 00:05:55,852 We call that being tamper-proof. 135 00:05:55,852 --> 00:05:57,810 So we don't want it to be the case that someone 136 00:05:57,810 --> 00:06:00,078 could go back and undo a spend. 137 00:06:00,078 --> 00:06:01,620 Another way to think about that is we 138 00:06:01,620 --> 00:06:03,570 don't want people tampering with history. 139 00:06:06,860 --> 00:06:09,650 Something that would be really useful here, 140 00:06:09,650 --> 00:06:13,220 and something that the bank was keeping implicitly, 141 00:06:13,220 --> 00:06:16,610 was a database of who is transferring money 142 00:06:16,610 --> 00:06:18,170 to whom, right? 143 00:06:18,170 --> 00:06:20,750 That was sort of the little thing in the corner which 144 00:06:20,750 --> 00:06:22,640 said how much was in Alice's account 145 00:06:22,640 --> 00:06:25,130 and how much was in Bob's account. 146 00:06:25,130 --> 00:06:28,250 There are actually techniques out there 147 00:06:28,250 --> 00:06:32,150 for maintaining a decentralized database 148 00:06:32,150 --> 00:06:34,010 among a set of participants. 149 00:06:34,010 --> 00:06:38,600 This problem of needing to agree on a value 150 00:06:38,600 --> 00:06:40,850 amongst many different participants 151 00:06:40,850 --> 00:06:44,720 is a problem known as distributed consensus. 152 00:06:44,720 --> 00:06:47,090 So here's what distributed consensus means. 153 00:06:47,090 --> 00:06:49,250 And if you've taken A24, then you've 154 00:06:49,250 --> 00:06:50,840 probably seen this before. 155 00:06:50,840 --> 00:06:52,550 But distributed consensus is the problem 156 00:06:52,550 --> 00:06:55,910 of multiple computers agreeing on a value, 157 00:06:55,910 --> 00:06:57,630 particularly in the presence of faults. 158 00:06:57,630 --> 00:07:00,810 So some of these computers might fail or go away. 159 00:07:00,810 --> 00:07:03,230 You can use this technique, distributed consensus, 160 00:07:03,230 --> 00:07:05,960 to build a log of operations with something called state 161 00:07:05,960 --> 00:07:08,540 machine replication, and essentially what you have 162 00:07:08,540 --> 00:07:11,570 when you do this is a distributed database, which 163 00:07:11,570 --> 00:07:13,070 is what we're trying to obtain here. 164 00:07:13,070 --> 00:07:14,540 We need to keep track of accounts 165 00:07:14,540 --> 00:07:16,580 and who's spending what, and what payments 166 00:07:16,580 --> 00:07:18,060 have happened in the system. 167 00:07:18,060 --> 00:07:20,600 And so distributed consensus is a tool that we might 168 00:07:20,600 --> 00:07:22,280 be able to use to do this. 169 00:07:25,010 --> 00:07:28,580 So the reason that we might be able to use distributed 170 00:07:28,580 --> 00:07:30,920 consensus to do this is we could keep 171 00:07:30,920 --> 00:07:33,800 a log of all of the transactions in the system. 172 00:07:33,800 --> 00:07:35,930 So Alice pays Bob. 173 00:07:35,930 --> 00:07:37,610 David pays Charlie. 174 00:07:37,610 --> 00:07:41,480 And what this log provides is it provides ordering. 175 00:07:41,480 --> 00:07:45,530 So if Alice tries to pay Carol the same thing that Alice pays 176 00:07:45,530 --> 00:07:49,250 Bob, because we have this primitive, this log, 177 00:07:49,250 --> 00:07:51,680 this globally ordered log, everyone 178 00:07:51,680 --> 00:07:54,650 can see that this came after that one, right? 179 00:07:54,650 --> 00:07:57,050 Everyone can see that Alice was trying to double spend. 180 00:07:57,050 --> 00:08:00,080 Alice was trying to spend the same coin twice. 181 00:08:00,080 --> 00:08:02,540 So this primitive is going to be really useful. 182 00:08:02,540 --> 00:08:05,030 This idea of this globally-ordered log 183 00:08:05,030 --> 00:08:09,050 of transactions is what fundamentally 184 00:08:09,050 --> 00:08:10,460 underlies all of these things. 185 00:08:13,580 --> 00:08:16,888 So we could say, if we were to see this log 186 00:08:16,888 --> 00:08:18,680 and we were to see this transaction pop up, 187 00:08:18,680 --> 00:08:21,200 we can decide that this doesn't really count. 188 00:08:21,200 --> 00:08:22,240 That this is-- 189 00:08:22,240 --> 00:08:23,512 Alice already spent her coin. 190 00:08:23,512 --> 00:08:25,720 A property that we want to maintain with these things 191 00:08:25,720 --> 00:08:27,558 is that you can only spend a coin once. 192 00:08:27,558 --> 00:08:30,100 So therefore, we're not really going to allow this to happen. 193 00:08:33,460 --> 00:08:37,380 So as I said, the problem of distributed consensus 194 00:08:37,380 --> 00:08:39,480 is that when you have a whole bunch of people 195 00:08:39,480 --> 00:08:42,270 working on this log, you can tolerate faults. 196 00:08:42,270 --> 00:08:43,740 So if some of the people go away, 197 00:08:43,740 --> 00:08:46,410 if it's only up to a certain number, it's OK. 198 00:08:46,410 --> 00:08:50,800 You still have a consistent, globally-ordered log. 199 00:08:50,800 --> 00:08:53,040 So there's a lot of existing systems that 200 00:08:53,040 --> 00:08:55,260 actually provide this property. 201 00:08:55,260 --> 00:08:58,050 Some of them are Paxos, ZooKeeper, and Raft, 202 00:08:58,050 --> 00:09:00,430 if you've ever heard of them. 203 00:09:00,430 --> 00:09:02,700 So the way that these protocols work 204 00:09:02,700 --> 00:09:05,070 is that all of these participants 205 00:09:05,070 --> 00:09:07,440 are executing the protocol to agree on the log. 206 00:09:07,440 --> 00:09:10,080 If a few fail, the protocol can still operate. 207 00:09:10,080 --> 00:09:13,080 Usually they can tolerate up to a minority failing. 208 00:09:15,900 --> 00:09:18,390 So these protocols, the ones that I just listed, 209 00:09:18,390 --> 00:09:21,970 operate in something called the crash fault tolerance model, 210 00:09:21,970 --> 00:09:25,050 meaning they can handle computers going away, 211 00:09:25,050 --> 00:09:26,940 but not really much else. 212 00:09:26,940 --> 00:09:30,420 And when we're operating in decentralized digital payment 213 00:09:30,420 --> 00:09:33,060 land, we want to be able to tolerate more than crashes. 214 00:09:33,060 --> 00:09:36,135 We want to be able to tolerate actively malicious behavior. 215 00:09:36,135 --> 00:09:38,260 Because if you're going to create a digital payment 216 00:09:38,260 --> 00:09:40,350 system, and it's money, then people 217 00:09:40,350 --> 00:09:43,890 are going to try to steal that money. 218 00:09:43,890 --> 00:09:47,400 So like I said, if people go away, if it's up to a minority, 219 00:09:47,400 --> 00:09:49,330 you can still have the log. 220 00:09:49,330 --> 00:09:51,150 So there's stuff from the literature 221 00:09:51,150 --> 00:09:53,580 that actually supports something close to this. 222 00:09:53,580 --> 00:09:57,000 There's something called Byzantine fault tolerance. 223 00:09:57,000 --> 00:10:00,270 And Byzantine fault tolerance tolerates more than crashes. 224 00:10:00,270 --> 00:10:05,140 It actually tolerates actively malicious participants. 225 00:10:05,140 --> 00:10:08,100 It can tolerate a smaller number of actively 226 00:10:08,100 --> 00:10:10,380 malicious participants, up to a third. 227 00:10:10,380 --> 00:10:12,930 So here, nodes might not just fail. 228 00:10:12,930 --> 00:10:16,440 They might actually try to subvert the protocol 229 00:10:16,440 --> 00:10:23,490 to keep from landing on a single globally-ordered log. 230 00:10:23,490 --> 00:10:25,740 And like I said, we have protocols 231 00:10:25,740 --> 00:10:27,090 that can tolerate this. 232 00:10:27,090 --> 00:10:28,260 Great. 233 00:10:28,260 --> 00:10:33,920 However, and these protocols are very, very old, OK? 234 00:10:33,920 --> 00:10:36,390 Like the Byzantine general's problem, 235 00:10:36,390 --> 00:10:39,330 which was a basic formulation of what 236 00:10:39,330 --> 00:10:41,070 led to Byzantium fault tolerance, 237 00:10:41,070 --> 00:10:44,190 was formulated in 1982. 238 00:10:44,190 --> 00:10:46,710 Paxos and view-stamped replication 239 00:10:46,710 --> 00:10:48,000 also came about in the '80s. 240 00:10:48,000 --> 00:10:50,970 Those were two distributed consensus program protocols. 241 00:10:50,970 --> 00:10:52,830 Practical Byzantine fault tolerance, 242 00:10:52,830 --> 00:10:56,760 so an actual, very practical protocol that you can implement 243 00:10:56,760 --> 00:11:00,420 and that you can use to create a globally-ordered log, that 244 00:11:00,420 --> 00:11:02,450 was in the '90s. 245 00:11:02,450 --> 00:11:05,700 And ever since then we've had a lot of different protocols. 246 00:11:05,700 --> 00:11:08,910 So-- And then in 2009, Bitcoin. 247 00:11:08,910 --> 00:11:12,030 So this idea, this idea of a globally-ordered log 248 00:11:12,030 --> 00:11:15,030 that can tolerate malicious participants, the thing I 249 00:11:15,030 --> 00:11:17,310 want to impress upon you is that it's an old idea. 250 00:11:17,310 --> 00:11:20,380 Decades old. 251 00:11:20,380 --> 00:11:21,220 So what's new? 252 00:11:21,220 --> 00:11:23,590 What happened with Bitcoin? 253 00:11:23,590 --> 00:11:28,420 Well, a downside that all of these systems have 254 00:11:28,420 --> 00:11:33,070 is that you need to know exactly who is participating 255 00:11:33,070 --> 00:11:34,550 in the protocol. 256 00:11:34,550 --> 00:11:36,610 So the way that these systems work 257 00:11:36,610 --> 00:11:39,640 is that the protocol works based on identity. 258 00:11:39,640 --> 00:11:42,640 So you have to know who is involved. 259 00:11:42,640 --> 00:11:45,520 You need to know everybody in the system. 260 00:11:45,520 --> 00:11:47,320 You know everybody in the system. 261 00:11:47,320 --> 00:11:50,560 You can tell who's sending you messages 262 00:11:50,560 --> 00:11:52,060 and who's not sending you messages, 263 00:11:52,060 --> 00:11:53,602 and you can make decisions about what 264 00:11:53,602 --> 00:11:55,810 everybody else thinks the globally-ordered log looks 265 00:11:55,810 --> 00:11:56,710 like. 266 00:11:56,710 --> 00:12:00,190 The thing that these protocols did not tolerate 267 00:12:00,190 --> 00:12:04,240 was when you don't know everybody in the system. 268 00:12:04,240 --> 00:12:07,720 And the problem when you don't know everybody in the system, 269 00:12:07,720 --> 00:12:09,640 and you're not doing participation 270 00:12:09,640 --> 00:12:12,850 based on identity, is that an attacker could create 271 00:12:12,850 --> 00:12:14,227 a whole bunch of identities. 272 00:12:14,227 --> 00:12:16,060 Well, there's nothing preventing an attacker 273 00:12:16,060 --> 00:12:17,440 from creating identities. 274 00:12:17,440 --> 00:12:20,410 And remember, we want a permission-less, decentralized 275 00:12:20,410 --> 00:12:21,160 system. 276 00:12:21,160 --> 00:12:25,360 We don't want to have some gatekeeper saying who can enter 277 00:12:25,360 --> 00:12:26,650 into and out of the system. 278 00:12:26,650 --> 00:12:29,650 And given that we don't want to have that gatekeeper, 279 00:12:29,650 --> 00:12:31,930 we can't just let people join willy-nilly 280 00:12:31,930 --> 00:12:34,630 and manufacture their own identities, because if they do, 281 00:12:34,630 --> 00:12:38,560 all of these protocols, all of a sudden, no longer work. 282 00:12:38,560 --> 00:12:41,890 This is what's known as a Sybil attack, OK? 283 00:12:41,890 --> 00:12:44,710 When an attacker can create identities, 284 00:12:44,710 --> 00:12:48,580 essentially for free, and can swarm the good guys 285 00:12:48,580 --> 00:12:51,500 and take over the protocol. 286 00:12:51,500 --> 00:12:55,630 So where I'm going to leave you is with this problem, which 287 00:12:55,630 --> 00:12:59,710 is we want to figure out how to address the Sybil attack 288 00:12:59,710 --> 00:13:03,880 problem when creating a globally-ordered log. 289 00:13:03,880 --> 00:13:06,790 And one way of doing that is to think 290 00:13:06,790 --> 00:13:09,340 about making identities costly. 291 00:13:09,340 --> 00:13:12,370 So good guys can create new identities 292 00:13:12,370 --> 00:13:15,130 and can join the system and can execute the protocol. 293 00:13:15,130 --> 00:13:18,130 Bad guys could potentially create identities 294 00:13:18,130 --> 00:13:20,590 and join the system and execute the protocol, 295 00:13:20,590 --> 00:13:24,160 but because identities actually cost something, 296 00:13:24,160 --> 00:13:25,160 there's a limit. 297 00:13:25,160 --> 00:13:26,268 There's an inherent limit. 298 00:13:26,268 --> 00:13:27,310 They don't come for free. 299 00:13:27,310 --> 00:13:30,130 The bad guys can only create so many. 300 00:13:30,130 --> 00:13:33,520 And that's where I want to end. 301 00:13:33,520 --> 00:13:35,140 Are there any questions about that 302 00:13:35,140 --> 00:13:38,703 as we transfer over to Tadge? 303 00:13:38,703 --> 00:13:39,870 AUDIENCE: I have a question. 304 00:13:39,870 --> 00:13:40,330 NEHA NARULA: Yeah? 305 00:13:40,330 --> 00:13:42,030 AUDIENCE: Does that model you presented 306 00:13:42,030 --> 00:13:44,210 to deal with distributed consensus assume you 307 00:13:44,210 --> 00:13:46,292 have synchronicity in the system? 308 00:13:46,292 --> 00:13:47,500 NEHA NARULA: Not necessarily. 309 00:13:47,500 --> 00:13:52,360 So that problem is unsolvable in the case 310 00:13:52,360 --> 00:13:55,570 where there is a totally asynchronous system. 311 00:13:55,570 --> 00:13:57,160 But there's a lot of different ways 312 00:13:57,160 --> 00:13:59,210 to create a model where, for example, 313 00:13:59,210 --> 00:14:00,670 if you have random coins, then it 314 00:14:00,670 --> 00:14:02,868 is solvable in an asynchronous system. 315 00:14:02,868 --> 00:14:05,410 So this is something that-- you might have heard of something 316 00:14:05,410 --> 00:14:06,368 called the CAP theorem. 317 00:14:06,368 --> 00:14:09,310 This is sort of a predecessor to that, 318 00:14:09,310 --> 00:14:12,670 which indicates that in a totally asynchronous system, 319 00:14:12,670 --> 00:14:16,960 without random coins, consensus is actually impossible. 320 00:14:16,960 --> 00:14:20,470 But that's-- there's different ways to get around that. 321 00:14:20,470 --> 00:14:22,360 And oftentimes, people assume that the system 322 00:14:22,360 --> 00:14:23,410 is semi-synchronous. 323 00:14:23,410 --> 00:14:26,356 AUDIENCE: Awesome. 324 00:14:26,356 --> 00:14:28,342 TADGE DRYJA: Neha. 325 00:14:28,342 --> 00:14:29,800 AUDIENCE: I have one more question. 326 00:14:29,800 --> 00:14:30,080 NEHA NARULA: What? 327 00:14:30,080 --> 00:14:30,580 Oh, sorry. 328 00:14:30,580 --> 00:14:32,390 Yeah. 329 00:14:32,390 --> 00:14:35,590 AUDIENCE: So with Bitcoin, in the paper 330 00:14:35,590 --> 00:14:39,080 they mentioned that they moved away from IP-based identity 331 00:14:39,080 --> 00:14:42,720 to CPU [INAUDIBLE] identity. 332 00:14:42,720 --> 00:14:44,235 Is that where the cost comes from? 333 00:14:44,235 --> 00:14:45,110 NEHA NARULA: Exactly. 334 00:14:45,110 --> 00:14:46,340 And that's what Tadge is going to talk about. 335 00:14:46,340 --> 00:14:46,882 AUDIENCE: OK. 336 00:14:46,882 --> 00:14:47,632 NEHA NARULA: Yeah. 337 00:14:47,632 --> 00:14:48,757 TADGE DRYJA: Anything else? 338 00:14:48,757 --> 00:14:49,320 Cool. 339 00:14:49,320 --> 00:14:49,820 OK. 340 00:14:49,820 --> 00:14:51,437 Hi, everyone. 341 00:14:51,437 --> 00:14:53,270 I'm going to talk about proof of work, which 342 00:14:53,270 --> 00:14:58,760 is, in my estimation, sort of the thing that started all 343 00:14:58,760 --> 00:15:01,670 of this, that, you know, there's all sorts of cool cryptography 344 00:15:01,670 --> 00:15:04,550 involved in Bitcoin and different cryptocurrencies, 345 00:15:04,550 --> 00:15:06,140 but it was the proof of work consensus 346 00:15:06,140 --> 00:15:09,690 that kicked all this off, and that was the big difference. 347 00:15:09,690 --> 00:15:11,730 So we want a cost, Neha was mentioning. 348 00:15:11,730 --> 00:15:14,090 We want some kind of cost to create identities or cost 349 00:15:14,090 --> 00:15:15,620 to participate in the system. 350 00:15:15,620 --> 00:15:18,450 How do we prevent Sybil attacks? 351 00:15:18,450 --> 00:15:20,720 And this is a very hard problem, because it 352 00:15:20,720 --> 00:15:23,570 tends to be an arms race in many ways, 353 00:15:23,570 --> 00:15:25,850 where Twitter or Facebook or things like 354 00:15:25,850 --> 00:15:27,740 that have tons of bots. 355 00:15:27,740 --> 00:15:31,100 Because as soon as Twitter makes a cool new algorithm 356 00:15:31,100 --> 00:15:35,840 to identify what's a bot and kick them off the system, 357 00:15:35,840 --> 00:15:37,790 the various people who were trying 358 00:15:37,790 --> 00:15:40,403 to make millions of Twitter bots start to figure it out. 359 00:15:40,403 --> 00:15:42,320 They're like, hey, they banned all these bots. 360 00:15:42,320 --> 00:15:44,090 Ah, well, I'll switch this around, 361 00:15:44,090 --> 00:15:47,420 and make my bots more human-like and better. 362 00:15:47,420 --> 00:15:49,670 I was actually kicked off of Twitter for being a bot, 363 00:15:49,670 --> 00:15:50,820 and I am not. 364 00:15:50,820 --> 00:15:51,560 I totally am not. 365 00:15:51,560 --> 00:15:54,400 [LAUGHTER] 366 00:15:54,400 --> 00:15:58,690 They said I exhibited automated activity. 367 00:15:58,690 --> 00:16:00,590 So this is a hard problem, and this sort 368 00:16:00,590 --> 00:16:04,040 of gets into like Turing test, CAPTCHA-kind of thing as well. 369 00:16:04,040 --> 00:16:06,820 But Bitcoin's a fairly different solution. 370 00:16:06,820 --> 00:16:09,500 And as Neha said, you don't want really anyone in charge. 371 00:16:09,500 --> 00:16:12,620 You don't want a set identity list of people 372 00:16:12,620 --> 00:16:14,000 who can participate. 373 00:16:14,000 --> 00:16:17,690 So that rules out things that other system use, like let's 374 00:16:17,690 --> 00:16:18,970 use social security numbers. 375 00:16:18,970 --> 00:16:19,970 Let's use phone numbers. 376 00:16:19,970 --> 00:16:21,088 Let's use CAPTCHAs. 377 00:16:21,088 --> 00:16:22,380 Well, those don't really apply. 378 00:16:22,380 --> 00:16:24,720 Like, what's a social security number? 379 00:16:24,720 --> 00:16:27,130 What if I'm in Germany and I want to use it? 380 00:16:27,130 --> 00:16:29,570 What if I'm in somewhere else, you know? 381 00:16:29,570 --> 00:16:30,590 Phone numbers as well. 382 00:16:30,590 --> 00:16:32,540 Phone numbers are just administrated 383 00:16:32,540 --> 00:16:34,580 by a phone company who would then 384 00:16:34,580 --> 00:16:37,160 become the de facto controller of the system. 385 00:16:37,160 --> 00:16:41,930 And CAPTCHAs are kind of an interesting idea, but they-- 386 00:16:41,930 --> 00:16:45,470 you know, the identify the signs in this picture 387 00:16:45,470 --> 00:16:48,440 or the cars in this picture or whatever. 388 00:16:48,440 --> 00:16:51,440 But it doesn't really apply, because it's not 389 00:16:51,440 --> 00:16:54,380 easy for people to verify, and not easy 390 00:16:54,380 --> 00:16:57,230 for computers to verify, that the people were actually 391 00:16:57,230 --> 00:16:57,770 doing it. 392 00:16:57,770 --> 00:17:00,030 So those don't work. 393 00:17:00,030 --> 00:17:02,840 So what does work is work. 394 00:17:02,840 --> 00:17:04,280 So I don't know if-- 395 00:17:04,280 --> 00:17:06,152 I think some people have said they've-- 396 00:17:06,152 --> 00:17:08,569 some people said the first day, oh, I did problem set one. 397 00:17:08,569 --> 00:17:09,430 I was, like, oh, OK. 398 00:17:09,430 --> 00:17:10,050 Cool. 399 00:17:10,050 --> 00:17:13,680 Some people have yet to start, which is fine as well. 400 00:17:13,680 --> 00:17:15,790 But if you have started and looked into problem 401 00:17:15,790 --> 00:17:17,900 set one, great. 402 00:17:17,900 --> 00:17:23,300 I will talk about it a little bit in the next few minutes. 403 00:17:23,300 --> 00:17:27,150 The problem set needs many attempts to forge a signature. 404 00:17:27,150 --> 00:17:28,870 So if you've done it, you've-- 405 00:17:28,870 --> 00:17:31,130 I don't know what the fastest-- 406 00:17:31,130 --> 00:17:33,080 probably someone got it to work really fast. 407 00:17:33,080 --> 00:17:36,230 When I completed it, I got it to run 408 00:17:36,230 --> 00:17:38,780 on eight cores of a fairly fast machine, 409 00:17:38,780 --> 00:17:41,510 and I got it to run in like three minutes. 410 00:17:41,510 --> 00:17:46,520 And it took me something like 2 billion attempts. 411 00:17:46,520 --> 00:17:47,950 Which it should, right? 412 00:17:47,950 --> 00:17:50,060 2 billion is a run. 413 00:17:50,060 --> 00:17:52,800 So this is because the hash functions have random output, 414 00:17:52,800 --> 00:17:53,300 right? 415 00:17:53,300 --> 00:17:56,360 I'm looking for a string where certain bits are set 416 00:17:56,360 --> 00:17:57,920 and certain bits are free. 417 00:17:57,920 --> 00:18:00,720 And since the hash functions have random output, 418 00:18:00,720 --> 00:18:02,220 I have no shortcut to be like, well, 419 00:18:02,220 --> 00:18:04,340 I want an output where these bits are ones 420 00:18:04,340 --> 00:18:07,010 and these bits are zeros, and the rest I don't care. 421 00:18:07,010 --> 00:18:10,700 I can't really specify that as the input to my hash function. 422 00:18:10,700 --> 00:18:13,587 So I just have to keep trying different numbers, all right? 423 00:18:13,587 --> 00:18:15,920 We know what we want, but the only way to get it is just 424 00:18:15,920 --> 00:18:18,770 keep throwing in different numbers to this hash function, 425 00:18:18,770 --> 00:18:23,590 getting the output, and checking if it matches our criteria. 426 00:18:23,590 --> 00:18:25,690 So what do you want out of work in this case? 427 00:18:25,690 --> 00:18:27,200 You want it to be time-consuming, 428 00:18:27,200 --> 00:18:28,557 kind of like the homework. 429 00:18:28,557 --> 00:18:30,640 But the example in the homework has some problems, 430 00:18:30,640 --> 00:18:33,100 because it's this weird trusted setup, right? 431 00:18:33,100 --> 00:18:36,040 In fact, it's-- so in the homework case, 432 00:18:36,040 --> 00:18:38,020 you're trying to forge a signature where I have 433 00:18:38,020 --> 00:18:39,490 the private key. 434 00:18:39,490 --> 00:18:41,500 I've made four signatures, and you 435 00:18:41,500 --> 00:18:45,340 want to forge a fifth signature without my private key. 436 00:18:45,340 --> 00:18:46,900 The problem is it seems like I would 437 00:18:46,900 --> 00:18:49,390 have an advantage in this work. 438 00:18:49,390 --> 00:18:53,200 I actually don't, because you can verify that I 439 00:18:53,200 --> 00:18:55,570 haven't revealed any new bits. 440 00:18:55,570 --> 00:18:57,190 But it's a weird setup, right? 441 00:18:57,190 --> 00:18:58,607 Where it's like, OK, well, there's 442 00:18:58,607 --> 00:19:01,360 one certain actor that like sets up this whole work, 443 00:19:01,360 --> 00:19:03,890 and we shouldn't have that kind of thing. 444 00:19:03,890 --> 00:19:05,710 So you want it to be deterministic. 445 00:19:05,710 --> 00:19:07,143 You also want it to be scalable. 446 00:19:07,143 --> 00:19:08,560 And you want it to be memory-less, 447 00:19:08,560 --> 00:19:11,807 where everyone gets a chance and you're not making progress. 448 00:19:11,807 --> 00:19:12,640 Because if you are-- 449 00:19:12,640 --> 00:19:15,310 I'll get to that later, but if you're making progress, 450 00:19:15,310 --> 00:19:19,330 it tends to be that the fastest person always wins, right? 451 00:19:19,330 --> 00:19:21,190 If there's no randomness involved. 452 00:19:21,190 --> 00:19:22,750 Like, if it's, you know, let's have 453 00:19:22,750 --> 00:19:25,220 a race between a bicycle and someone running. 454 00:19:25,220 --> 00:19:26,940 It's like, well, that's not really race. 455 00:19:26,940 --> 00:19:29,170 The bicycle is always going to win. 456 00:19:29,170 --> 00:19:31,840 Whereas in this case, if it's memory-less, 457 00:19:31,840 --> 00:19:34,900 every attempt is a new shot at getting it, 458 00:19:34,900 --> 00:19:37,280 and so someone who is 10% as fast 459 00:19:37,280 --> 00:19:40,190 will still win 10% of the time. 460 00:19:40,190 --> 00:19:40,690 OK. 461 00:19:40,690 --> 00:19:42,880 So in the case of the homework. 462 00:19:42,880 --> 00:19:48,040 So here's an example where five bits of eight are constrained. 463 00:19:48,040 --> 00:19:50,920 So let's say these first two, you've 464 00:19:50,920 --> 00:19:53,500 got the pre-images for both. 465 00:19:53,500 --> 00:19:55,120 This is the zero row. 466 00:19:55,120 --> 00:19:56,770 This is the one row. 467 00:19:56,770 --> 00:19:59,920 And the signatures I've revealed-- 468 00:19:59,920 --> 00:20:01,247 OK, you get both bits here. 469 00:20:01,247 --> 00:20:02,830 However, here, in this place, you only 470 00:20:02,830 --> 00:20:05,317 have the one bit, the one pre-image. 471 00:20:05,317 --> 00:20:06,400 Here you only have a zero. 472 00:20:06,400 --> 00:20:07,690 Here you only have the one. 473 00:20:07,690 --> 00:20:10,540 Here you've got both, and then you're also here, one, zero. 474 00:20:10,540 --> 00:20:14,260 So the idea is these three bits are like x. 475 00:20:14,260 --> 00:20:15,100 Like, don't care. 476 00:20:15,100 --> 00:20:19,090 Either a one or a zero will work. 477 00:20:19,090 --> 00:20:22,360 These five bits are constrained. 478 00:20:22,360 --> 00:20:26,270 So it must match 101 and then 10. 479 00:20:26,270 --> 00:20:29,050 So you're going to have to keep trying messages. 480 00:20:29,050 --> 00:20:30,610 And since five bits are constrained, 481 00:20:30,610 --> 00:20:32,860 you're going to have to try 2 to the 5 messages, which 482 00:20:32,860 --> 00:20:34,380 is, what, 64? 483 00:20:34,380 --> 00:20:35,010 I think? 484 00:20:35,010 --> 00:20:36,040 Yeah. 485 00:20:36,040 --> 00:20:37,840 Which is totally doable, right? 486 00:20:37,840 --> 00:20:40,600 64 tries, and you'll probably get it. 487 00:20:40,600 --> 00:20:42,380 So for example, you try once, and you 488 00:20:42,380 --> 00:20:45,490 say, OK, I got, 11001100. 489 00:20:45,490 --> 00:20:46,420 Doesn't work. 490 00:20:46,420 --> 00:20:48,520 These are OK, because they're OK no matter what. 491 00:20:48,520 --> 00:20:49,330 This one's wrong. 492 00:20:49,330 --> 00:20:50,110 This one's OK. 493 00:20:50,110 --> 00:20:50,860 This one's OK. 494 00:20:50,860 --> 00:20:52,300 This one's wrong. 495 00:20:52,300 --> 00:20:54,060 Let me try again. 496 00:20:54,060 --> 00:20:56,230 OK, I got it, right? 497 00:20:56,230 --> 00:20:57,370 These can be anything. 498 00:20:57,370 --> 00:20:58,180 I got a 0 and a 1. 499 00:20:58,180 --> 00:20:59,020 Sure. 500 00:20:59,020 --> 00:21:00,430 These all line up. 501 00:21:00,430 --> 00:21:03,040 The red ones all line up, so I've found a valid solution. 502 00:21:05,860 --> 00:21:10,220 And so that works as a proof of work, and in this case, 503 00:21:10,220 --> 00:21:19,870 I found a solution, which was Tadge forge 1 154262107. 504 00:21:19,870 --> 00:21:22,420 And that's a message that can be forged, given those four 505 00:21:22,420 --> 00:21:23,950 signatures in the problem set. 506 00:21:23,950 --> 00:21:26,620 And anyone can, you know, whatever homework solution 507 00:21:26,620 --> 00:21:30,220 you have, you can probably copy and paste that string 508 00:21:30,220 --> 00:21:32,980 and check that if you hash that, you'll 509 00:21:32,980 --> 00:21:36,460 get a hash that matches up and can be signed with those four 510 00:21:36,460 --> 00:21:38,080 signatures. 511 00:21:38,080 --> 00:21:42,430 So then the question is, did I do 154 million tries 512 00:21:42,430 --> 00:21:43,030 to get that? 513 00:21:43,030 --> 00:21:44,890 Like did I start at zero? 514 00:21:44,890 --> 00:21:46,060 Maybe I did more. 515 00:21:46,060 --> 00:21:47,680 Maybe it was random. 516 00:21:47,680 --> 00:21:52,390 Maybe I got lucky and I started counting at 150 million. 517 00:21:52,390 --> 00:21:55,390 So it's not really a proof, is the thing. 518 00:21:55,390 --> 00:22:00,590 Like, you're not exactly sure how many attempts someone did. 519 00:22:00,590 --> 00:22:01,880 Not quite a proof, right? 520 00:22:01,880 --> 00:22:03,680 There's a lot of chance. 521 00:22:03,680 --> 00:22:08,480 However, over many proofs, it averages out 522 00:22:08,480 --> 00:22:11,040 and you can be pretty sure that someone's doing all the work, 523 00:22:11,040 --> 00:22:11,540 right? 524 00:22:11,540 --> 00:22:17,230 So if-- you know, if someone gets lucky once, fine. 525 00:22:17,230 --> 00:22:19,840 Like, maybe they tried a couple times 526 00:22:19,840 --> 00:22:23,080 and got a valid proof of work, but eventually, 527 00:22:23,080 --> 00:22:26,410 if they keep doing proof of work and they're iteratively 528 00:22:26,410 --> 00:22:28,720 showing them, then you can be pretty sure 529 00:22:28,720 --> 00:22:31,930 that they're not going to be lucky the whole time, right? 530 00:22:31,930 --> 00:22:34,690 And so you have to estimate the collision difficulty. 531 00:22:34,690 --> 00:22:36,940 The best way to estimate the difficulty and the amount 532 00:22:36,940 --> 00:22:40,900 of work that people have done isn't to look at their proof, 533 00:22:40,900 --> 00:22:42,820 isn't to look at their nonce, but to look 534 00:22:42,820 --> 00:22:46,060 at the constraints of the system before they start, right? 535 00:22:46,060 --> 00:22:52,810 So in the case of the homework, 31 bits are specified, right? 536 00:22:52,810 --> 00:22:55,480 So with four signatures, you'd guess 537 00:22:55,480 --> 00:22:58,130 that about 32 bits would be-- and in this case, 538 00:22:58,130 --> 00:23:00,485 there's 1 bit difference. 539 00:23:00,485 --> 00:23:02,110 So in the case of the homework, there's 540 00:23:02,110 --> 00:23:04,360 31 bits that are specified, so that 541 00:23:04,360 --> 00:23:07,900 means you're going to have to do about 2 billion hashes, right? 542 00:23:07,900 --> 00:23:11,720 2 to the 31 is like 2.1 billion, or something. 543 00:23:11,720 --> 00:23:14,620 And so that's the best estimate of how long it took, 544 00:23:14,620 --> 00:23:16,750 regardless of what the nonce is, regardless 545 00:23:16,750 --> 00:23:19,570 of what it looks like they did, you could say, well, 546 00:23:19,570 --> 00:23:21,640 it's going to take on average 2 to 31 attempts. 547 00:23:21,640 --> 00:23:24,340 Let's just-- and so if any valid solution they give me, I'm 548 00:23:24,340 --> 00:23:29,790 going to credit that with 2 to the 31 work. 549 00:23:29,790 --> 00:23:32,942 So actually, in the case of mine, 550 00:23:32,942 --> 00:23:35,400 the one is the thread number, and there were eight threads, 551 00:23:35,400 --> 00:23:39,120 so this Tadge forge 1 154 million. 552 00:23:39,120 --> 00:23:41,280 So I had eight threads going in parallel, 553 00:23:41,280 --> 00:23:43,290 and that happened to be thread one. 554 00:23:43,290 --> 00:23:46,390 And so they all went about the same speed. 555 00:23:46,390 --> 00:23:48,330 So it's really like, 154 million times 556 00:23:48,330 --> 00:23:51,780 eight, which is about 1.2 billion. 557 00:23:51,780 --> 00:23:54,040 And so that's actually kind of lucky, right? 558 00:23:54,040 --> 00:23:56,400 Like, it should-- you would estimate 559 00:23:56,400 --> 00:23:58,620 on average you would take 2 billion, 560 00:23:58,620 --> 00:24:01,230 and I got it at 1.2 billion, so pretty good luck, 561 00:24:01,230 --> 00:24:05,950 but within 2x of what you'd expect. 562 00:24:05,950 --> 00:24:08,880 And since you can look at the probability distributions 563 00:24:08,880 --> 00:24:09,593 of like-- 564 00:24:09,593 --> 00:24:11,760 that might be kind of interesting with the homework, 565 00:24:11,760 --> 00:24:15,285 like OK, everyone's attempt, some people it takes 2 billion. 566 00:24:15,285 --> 00:24:17,160 Some people get lucky and it takes 1 billion. 567 00:24:17,160 --> 00:24:19,710 Some people get unlucky and it takes 5 billion. 568 00:24:19,710 --> 00:24:23,220 And you're going to have this curve to see it. 569 00:24:23,220 --> 00:24:26,760 But this is-- that's a kind of weird application 570 00:24:26,760 --> 00:24:29,470 of this signature forging algorithm, all right? 571 00:24:29,470 --> 00:24:31,200 It's not what it's made for. 572 00:24:31,200 --> 00:24:33,510 We can have a simpler proof of work 573 00:24:33,510 --> 00:24:36,390 that has a specific target that's reused forever, 574 00:24:36,390 --> 00:24:39,030 and it's more universal in that it's not, 575 00:24:39,030 --> 00:24:42,030 like, oh, here's this private key. 576 00:24:42,030 --> 00:24:44,502 Here's this key pair and here are these four signatures. 577 00:24:44,502 --> 00:24:45,960 Where are these things coming from? 578 00:24:45,960 --> 00:24:47,020 That's weird. 579 00:24:47,020 --> 00:24:50,610 We have to match these weird strings of bits and stuff. 580 00:24:50,610 --> 00:24:52,510 That's kind of annoying. 581 00:24:52,510 --> 00:24:55,860 So it's better to do something similar, but much simpler. 582 00:24:55,860 --> 00:24:58,020 We'll just try to collide with a fixed string. 583 00:24:58,020 --> 00:25:00,762 So there's some defined string of ones and zeros, 584 00:25:00,762 --> 00:25:02,220 and we just say, OK, well let's try 585 00:25:02,220 --> 00:25:04,350 to have a collision with this. 586 00:25:04,350 --> 00:25:06,960 And the simplest is collide with zero, 587 00:25:06,960 --> 00:25:09,720 or you could also collide with like FFFF. 588 00:25:09,720 --> 00:25:11,460 But in the case of Bitcoin and the case 589 00:25:11,460 --> 00:25:13,320 of many of these systems, we say, well, 590 00:25:13,320 --> 00:25:16,060 let's just try to have a low number. 591 00:25:16,060 --> 00:25:21,390 So let's interpret the hash output as an actual number. 592 00:25:21,390 --> 00:25:24,000 In most cases-- do we have any hashes out here? 593 00:25:24,000 --> 00:25:25,380 No. 594 00:25:25,380 --> 00:25:30,390 You know, it's a 32 byte string, and we think of it as just, 595 00:25:30,390 --> 00:25:32,070 like, here's a blob of bytes. 596 00:25:32,070 --> 00:25:34,793 But you could cast that into an integer, right? 597 00:25:34,793 --> 00:25:36,210 You could say, oh, let's interpret 598 00:25:36,210 --> 00:25:38,960 these 32 bytes as a uint 256. 599 00:25:38,960 --> 00:25:39,460 Right? 600 00:25:39,460 --> 00:25:42,060 A 256-bit unsigned integer. 601 00:25:42,060 --> 00:25:45,220 And let's look for really low ones. 602 00:25:45,220 --> 00:25:46,110 And you can do that. 603 00:25:46,110 --> 00:25:48,090 I think with some CPUs, they'll actually 604 00:25:48,090 --> 00:25:51,492 let you do giant integers that way. 605 00:25:51,492 --> 00:25:52,950 But even if not, you have some kind 606 00:25:52,950 --> 00:25:55,580 of big int library in your computer, which just interprets 607 00:25:55,580 --> 00:25:56,700 it that way and says, OK, let's try 608 00:25:56,700 --> 00:25:57,960 to find collisions with zero. 609 00:25:57,960 --> 00:26:00,370 Basically, let's try to find low numbers. 610 00:26:00,370 --> 00:26:00,870 Yeah, OK. 611 00:26:00,870 --> 00:26:04,020 So this idea-- there's a paper before hashcash, 612 00:26:04,020 --> 00:26:06,630 but I don't think hashcash was the first software. 613 00:26:06,630 --> 00:26:08,850 This idea is actually really old. 614 00:26:08,850 --> 00:26:12,900 In 1997, Adam Back, who still works on this kind of stuff 615 00:26:12,900 --> 00:26:16,770 now with Bitcoin, the idea was to stop email spam, which-- 616 00:26:16,770 --> 00:26:19,590 I don't if-- you know, in the late '90s, 617 00:26:19,590 --> 00:26:21,770 was actually a huge problem. 618 00:26:21,770 --> 00:26:24,120 They didn't have all the cool like different machine 619 00:26:24,120 --> 00:26:26,790 learning stuff, and there's tons of spam. 620 00:26:26,790 --> 00:26:28,680 And the idea was, OK, put a nonce. 621 00:26:28,680 --> 00:26:32,280 And a nonce is this-- 622 00:26:32,280 --> 00:26:35,130 we call this a nonce, right, the random number 623 00:26:35,130 --> 00:26:37,800 you're throwing in to keep changing things. 624 00:26:37,800 --> 00:26:41,640 Put a nonce in your email header, 625 00:26:41,640 --> 00:26:43,860 and you try to get a low hash output 626 00:26:43,860 --> 00:26:46,080 when you hash the whole thing. 627 00:26:46,080 --> 00:26:49,410 So within the UI for email, you don't necessarily 628 00:26:49,410 --> 00:26:51,810 have to see, OK, what's this person's nonce? 629 00:26:51,810 --> 00:26:54,550 The computer just does it all automatically for you. 630 00:26:54,550 --> 00:26:56,920 But the idea is you need a partial collision with zero. 631 00:26:56,920 --> 00:26:59,700 You need a low hash output for your email, 632 00:26:59,700 --> 00:27:03,900 before your email, the receiving person, will display the email. 633 00:27:03,900 --> 00:27:08,293 And since the header includes the destination address, 634 00:27:08,293 --> 00:27:09,960 if you're a spammer and you want to spam 635 00:27:09,960 --> 00:27:11,940 a million different people, you're 636 00:27:11,940 --> 00:27:14,400 going to have to come up with a million different proofs 637 00:27:14,400 --> 00:27:15,253 of work. 638 00:27:15,253 --> 00:27:16,670 And that could take quite a while. 639 00:27:16,670 --> 00:27:19,230 Like, let's say an average CPU can do it 640 00:27:19,230 --> 00:27:21,810 in two or three seconds. 641 00:27:21,810 --> 00:27:24,000 That means you're going to have to be waiting months 642 00:27:24,000 --> 00:27:25,227 to spam all these emails. 643 00:27:25,227 --> 00:27:27,060 However, for a normal person, if you're just 644 00:27:27,060 --> 00:27:30,240 sending an email to your friend, takes a few seconds, right? 645 00:27:30,240 --> 00:27:34,760 Takes two seconds for your CPU time, which is not a huge deal. 646 00:27:34,760 --> 00:27:36,330 So this was a cool idea. 647 00:27:36,330 --> 00:27:38,550 It never really got off the ground 648 00:27:38,550 --> 00:27:41,700 just because, I don't know, Gmail happened, 649 00:27:41,700 --> 00:27:42,480 Hotmail happened. 650 00:27:42,480 --> 00:27:44,250 A lot of web mail things happened. 651 00:27:44,250 --> 00:27:45,710 People don't really use-- 652 00:27:45,710 --> 00:27:48,965 AUDIENCE: I think there was a paper that the economics of it 653 00:27:48,965 --> 00:27:50,420 doesn't work. 654 00:27:50,420 --> 00:27:55,440 TADGE DRYJA: Yeah, I mean, spammers often have bot nets. 655 00:27:55,440 --> 00:27:57,620 So, yeah, there's a lot of other issues, right? 656 00:27:57,620 --> 00:28:01,770 Like there's-- it didn't take off for various reasons. 657 00:28:01,770 --> 00:28:03,720 But yeah, also, spammers have botnets, 658 00:28:03,720 --> 00:28:07,380 which also sort of hurts the whole idea of proof of work, 659 00:28:07,380 --> 00:28:10,630 in some cases, which we'll talk about in a second. 660 00:28:10,630 --> 00:28:11,130 OK. 661 00:28:11,130 --> 00:28:12,720 So the simpler proof of work. 662 00:28:12,720 --> 00:28:16,240 So for example, if you go onto your computers, 663 00:28:16,240 --> 00:28:21,450 and you say, echo Tadge 4233964024, and pipe 664 00:28:21,450 --> 00:28:25,080 that to sha256sum, you will get this output. 665 00:28:25,080 --> 00:28:29,830 And that's eight zeros in the front, so that's 4 bytes. 666 00:28:29,830 --> 00:28:33,850 I did 2 the 32 work, and it's-- you know, that's me, right? 667 00:28:33,850 --> 00:28:35,680 And so that proves that I'm a hard worker, 668 00:28:35,680 --> 00:28:38,440 and I'm going to put this nonce on my resume, 669 00:28:38,440 --> 00:28:41,230 and everyone can see that I do work. 670 00:28:41,230 --> 00:28:46,060 That is kind of silly, but it's a really easy universal way 671 00:28:46,060 --> 00:28:47,180 to have a proof of work. 672 00:28:47,180 --> 00:28:51,580 Anyone can put their name or any message, and any kind of nonce, 673 00:28:51,580 --> 00:28:54,940 and we all just pipe it into the sha256 function 674 00:28:54,940 --> 00:28:57,790 and see how low the output is. 675 00:28:57,790 --> 00:29:01,720 In this case, it's actually 2 to 33, right? 676 00:29:01,720 --> 00:29:06,970 Because the first digit is a 7, so that's 0111. 677 00:29:06,970 --> 00:29:09,070 But this is what we use in Bitcoins. 678 00:29:09,070 --> 00:29:11,890 It's what they use in a lot of these things. 679 00:29:11,890 --> 00:29:13,570 I mean, it's really straightforward. 680 00:29:13,570 --> 00:29:14,070 OK. 681 00:29:14,070 --> 00:29:15,470 So partial collision work. 682 00:29:15,470 --> 00:29:18,330 It has a lot of the properties that we're 683 00:29:18,330 --> 00:29:21,540 looking for when we want this consensus system, right? 684 00:29:21,540 --> 00:29:23,700 It increases the costs of equivocation 685 00:29:23,700 --> 00:29:28,890 and helps with Sybil resistance, in that if I want to fool you, 686 00:29:28,890 --> 00:29:31,050 I'm still going to have to do a lot of work. 687 00:29:31,050 --> 00:29:33,120 And I need time to do that. 688 00:29:33,120 --> 00:29:34,410 I need electricity to do that. 689 00:29:34,410 --> 00:29:37,110 I need a bunch of computers to do that with. 690 00:29:37,110 --> 00:29:41,850 Also scalable, because a ton of work 691 00:29:41,850 --> 00:29:44,250 still takes the same amount of time and space 692 00:29:44,250 --> 00:29:46,650 to verify as a little bit of work, right? 693 00:29:46,650 --> 00:29:49,020 So I can do O of n work, right? 694 00:29:49,020 --> 00:29:51,180 I can put as many zeros as I want, 695 00:29:51,180 --> 00:29:53,748 and the nonce doesn't really get any bigger. 696 00:29:53,748 --> 00:29:56,040 The nonce never has to get bigger than the hash output, 697 00:29:56,040 --> 00:29:56,930 certainly. 698 00:29:56,930 --> 00:29:59,250 And the time to verify is the same 699 00:29:59,250 --> 00:30:02,870 no matter what, so that's really cool. 700 00:30:02,870 --> 00:30:05,630 So why do we do work, in the case of Bitcoin? 701 00:30:05,630 --> 00:30:09,020 The idea is you use a chained proof of work 702 00:30:09,020 --> 00:30:11,810 as a distributed time stamping mechanism. 703 00:30:11,810 --> 00:30:16,530 So it's to determine what happened first. 704 00:30:16,530 --> 00:30:19,265 So in the case of a double spend, where someone is saying, 705 00:30:19,265 --> 00:30:20,990 oh, transaction A happened first. 706 00:30:20,990 --> 00:30:22,490 And someone else says, well, I think 707 00:30:22,490 --> 00:30:24,530 transaction B happened first. 708 00:30:24,530 --> 00:30:27,500 You can't just rely on what other people are telling you, 709 00:30:27,500 --> 00:30:29,300 because who are these other people? 710 00:30:29,300 --> 00:30:31,130 There's no real identities here. 711 00:30:31,130 --> 00:30:35,000 So you look at what got into the chain of hashes first. 712 00:30:35,000 --> 00:30:37,310 And you say, OK, well, that one-- 713 00:30:37,310 --> 00:30:40,830 this one, this data, has a hash of this data, 714 00:30:40,830 --> 00:30:43,022 so it must have happened after it, right? 715 00:30:43,022 --> 00:30:44,480 And the things that happened before 716 00:30:44,480 --> 00:30:47,510 are pointed to by the things that happened after. 717 00:30:47,510 --> 00:30:51,080 Because the idea is I can't include the hash of something 718 00:30:51,080 --> 00:30:53,180 that I haven't seen yet, right? 719 00:30:53,180 --> 00:30:56,220 It should be impossible to do that. 720 00:30:56,220 --> 00:30:58,890 So the idea of the blockchain. 721 00:30:58,890 --> 00:31:01,440 You've got some message m, some nonce. 722 00:31:01,440 --> 00:31:03,613 Let's call it r, and some target, t. 723 00:31:03,613 --> 00:31:05,530 And this actually changes, but we're not going 724 00:31:05,530 --> 00:31:07,110 to talk about the changes yet. 725 00:31:07,110 --> 00:31:09,420 So you tack the hash of your message and the nonce-- 726 00:31:09,420 --> 00:31:11,130 like I was doing with Tadge-- 727 00:31:11,130 --> 00:31:13,320 and the number, and you say, OK, that's h. 728 00:31:13,320 --> 00:31:15,810 And h has to be less than some number t. 729 00:31:15,810 --> 00:31:18,460 So in the case where I just said my nonce, 730 00:31:18,460 --> 00:31:20,070 I had 2 to the 33 work. 731 00:31:20,070 --> 00:31:23,882 So say the same thing here. 732 00:31:23,882 --> 00:31:25,590 In the example, I'm going to only require 733 00:31:25,590 --> 00:31:27,960 2 bytes for the target, so that target 734 00:31:27,960 --> 00:31:29,910 needs to be fairly large. 735 00:31:29,910 --> 00:31:38,250 And then the message for block n includes some data, and also 736 00:31:38,250 --> 00:31:40,530 the hash of block m minus 1. 737 00:31:40,530 --> 00:31:45,000 You refer to your previous block hash in your current block 738 00:31:45,000 --> 00:31:45,900 data. 739 00:31:45,900 --> 00:31:47,490 So for example, message number two 740 00:31:47,490 --> 00:31:52,330 would be data 2 concatenated with the hash of data 1 and r-- 741 00:31:52,330 --> 00:31:53,890 well, there should be r1 there. 742 00:31:53,890 --> 00:31:54,390 OK. 743 00:31:54,390 --> 00:31:56,730 So I'll show you a little diagram this. 744 00:31:56,730 --> 00:31:58,685 So the idea of a blockchain, which-- yeah? 745 00:31:58,685 --> 00:32:00,060 AUDIENCE: You'll need to back up. 746 00:32:00,060 --> 00:32:03,790 Could you explain why it's less than? 747 00:32:03,790 --> 00:32:06,607 TADGE DRYJA: In this case, we want low numbers 748 00:32:06,607 --> 00:32:07,440 as the hash outputs. 749 00:32:07,440 --> 00:32:08,800 AUDIENCE: Does it have to be less than? 750 00:32:08,800 --> 00:32:10,425 TADGE DRYJA: You could do greater than. 751 00:32:10,425 --> 00:32:13,920 You could have, I want something that starts with a lot of Fs. 752 00:32:13,920 --> 00:32:16,460 It would work the same, you know? 753 00:32:16,460 --> 00:32:17,466 You could-- yeah? 754 00:32:17,466 --> 00:32:20,660 AUDIENCE: The idea here is you want to constrain, right? 755 00:32:20,660 --> 00:32:21,410 TADGE DRYJA: Yeah. 756 00:32:21,410 --> 00:32:22,955 AUDIENCE: So you can do that with less than 757 00:32:22,955 --> 00:32:24,050 or you can do that with greater than. 758 00:32:24,050 --> 00:32:25,970 You could do that with a fixed sort of-- 759 00:32:25,970 --> 00:32:26,330 TADGE DRYJA: Yeah, you could-- 760 00:32:26,330 --> 00:32:27,530 AUDIENCE: Little bits have to be-- 761 00:32:27,530 --> 00:32:28,580 TADGE DRYJA: Well, there's something-- 762 00:32:28,580 --> 00:32:30,530 OK, so less than and greater than are actually 763 00:32:30,530 --> 00:32:33,170 nicer than just fixed bit. 764 00:32:33,170 --> 00:32:35,930 So you could say, I want it to start with the repeating 765 00:32:35,930 --> 00:32:38,240 pattern 10101010. 766 00:32:38,240 --> 00:32:40,490 That would work, too, but then you're 767 00:32:40,490 --> 00:32:43,010 constrained in how fine tuned you 768 00:32:43,010 --> 00:32:44,900 can turn the knob, in that you're 769 00:32:44,900 --> 00:32:48,320 going to either have to add another bit of constraint 770 00:32:48,320 --> 00:32:49,692 or remove a bit of constraint. 771 00:32:49,692 --> 00:32:51,150 And so that, you know, you're going 772 00:32:51,150 --> 00:32:53,150 to have to go in 2x jumps. 773 00:32:53,150 --> 00:32:56,690 What's nice with this is you actually have very fine-grained 774 00:32:56,690 --> 00:33:00,110 control over how much work you're requiring, 775 00:33:00,110 --> 00:33:01,520 because you don't-- 776 00:33:01,520 --> 00:33:05,540 so in this example, I said, hey, I have this many zero bits. 777 00:33:05,540 --> 00:33:08,090 But I can also say, well, I needed 778 00:33:08,090 --> 00:33:13,010 to have a number less than 7f-- 779 00:33:13,010 --> 00:33:14,010 dah, dah, dah, dah, dah. 780 00:33:14,010 --> 00:33:17,060 Like, less than 7f 000 here. 781 00:33:17,060 --> 00:33:19,020 And this satisfies it, because hey, that's 7e. 782 00:33:19,020 --> 00:33:20,640 That's less than 7f. 783 00:33:20,640 --> 00:33:21,140 right? 784 00:33:21,140 --> 00:33:25,520 So I can actually have a pretty specific thing, 785 00:33:25,520 --> 00:33:28,430 not just in terms of number of bits specified. 786 00:33:28,430 --> 00:33:32,300 So greater than or less than is kind of nice in that sense, 787 00:33:32,300 --> 00:33:36,194 because you can have very small changes to the target. 788 00:33:36,194 --> 00:33:37,090 Oh. 789 00:33:37,090 --> 00:33:37,660 OK. 790 00:33:37,660 --> 00:33:40,480 Any questions about all this crazy stuff? 791 00:33:44,700 --> 00:33:45,200 Cool. 792 00:33:45,200 --> 00:33:47,210 OK. 793 00:33:47,210 --> 00:33:47,710 Yeah. 794 00:33:47,710 --> 00:33:50,400 So you can you can specify. 795 00:33:50,400 --> 00:33:54,630 So in the case of the homework, it's just number of bits, 796 00:33:54,630 --> 00:33:55,130 right? 797 00:33:55,130 --> 00:33:57,160 Because they're all scattered throughout the field, 798 00:33:57,160 --> 00:33:58,310 whereas in this one, you can say, 799 00:33:58,310 --> 00:34:00,420 well, it's the targets greater than or less than. 800 00:34:00,420 --> 00:34:01,420 In this case, less than. 801 00:34:01,420 --> 00:34:05,320 So I have fine-grained control. 802 00:34:05,320 --> 00:34:06,820 Which, we're not going to-- 803 00:34:06,820 --> 00:34:08,150 we'll get into later. 804 00:34:08,150 --> 00:34:10,750 But, yeah, in the actual case of Bitcoin, 805 00:34:10,750 --> 00:34:13,090 the target can vary, right? 806 00:34:13,090 --> 00:34:18,370 So when Bitcoin started, you needed 4 bytes of zeros, right? 807 00:34:18,370 --> 00:34:20,440 You needed to do 2 to the 32 work. 808 00:34:20,440 --> 00:34:23,560 Now you need to do way way, way more, 809 00:34:23,560 --> 00:34:25,719 and there's an algorithm in Bitcoin that 810 00:34:25,719 --> 00:34:27,413 adjusts what that target is. 811 00:34:27,413 --> 00:34:28,830 And I'll show at the end of this-- 812 00:34:28,830 --> 00:34:30,664 like a current Bitcoin proof of work. 813 00:34:30,664 --> 00:34:32,289 AUDIENCE: We've got to talk about that. 814 00:34:32,289 --> 00:34:35,530 I was going to ask you, [INAUDIBLE] time? 815 00:34:35,530 --> 00:34:37,018 How do you know [INAUDIBLE] solve? 816 00:34:37,018 --> 00:34:37,810 TADGE DRYJA: Right. 817 00:34:37,810 --> 00:34:38,310 Right. 818 00:34:38,310 --> 00:34:42,770 So time is sort of a tricky, semi-ugly subject in Bitcoin. 819 00:34:42,770 --> 00:34:44,770 It'd be really cool if they could get rid of it. 820 00:34:44,770 --> 00:34:49,840 But time is used, and only to vary that target, right? 821 00:34:49,840 --> 00:34:52,030 So when you mine a block, you say, I'm 822 00:34:52,030 --> 00:34:54,280 going to put what time it is. 823 00:34:54,280 --> 00:34:57,360 And you look at the last two-- 824 00:34:57,360 --> 00:35:00,900 when every two weeks, or so, every 2016 blocks, 825 00:35:00,900 --> 00:35:04,110 you look at them, and say, OK, what's 826 00:35:04,110 --> 00:35:06,930 the first timestamp of this 2016 period 827 00:35:06,930 --> 00:35:08,285 and the current timestamp? 828 00:35:08,285 --> 00:35:09,660 And if that took two weeks, cool, 829 00:35:09,660 --> 00:35:11,130 we don't have to vary the target. 830 00:35:11,130 --> 00:35:14,880 If it took less than two weeks, let's crank up the difficulty, 831 00:35:14,880 --> 00:35:16,830 or lower the target. 832 00:35:16,830 --> 00:35:18,780 And if it took too long, let's make it 833 00:35:18,780 --> 00:35:21,900 easier by raising the target. 834 00:35:21,900 --> 00:35:23,400 And so really, you're only comparing 835 00:35:23,400 --> 00:35:24,840 the first and last thing. 836 00:35:24,840 --> 00:35:28,530 During the process, when everyone's downloading stuff, I 837 00:35:28,530 --> 00:35:31,080 think the general rule is if you see something that's off 838 00:35:31,080 --> 00:35:33,660 by more than two hours, you reject it, 839 00:35:33,660 --> 00:35:37,332 but it's very lax in terms of synchronization, right? 840 00:35:37,332 --> 00:35:39,540 If someone's 10 minutes off, you're like, yeah, sure. 841 00:35:39,540 --> 00:35:41,700 I'll take it. 842 00:35:41,700 --> 00:35:45,240 Even if block eight says it happened before block seven, 843 00:35:45,240 --> 00:35:46,770 refers to block seven, and yet has 844 00:35:46,770 --> 00:35:49,320 a timestamp that's before it, you're still like, yeah, OK. 845 00:35:49,320 --> 00:35:50,230 Fine. 846 00:35:50,230 --> 00:35:50,730 Whatever. 847 00:35:50,730 --> 00:35:52,250 People's clocks are off. 848 00:35:52,250 --> 00:35:54,360 So that the time is fairly lax. 849 00:35:54,360 --> 00:35:56,810 AUDIENCE: What happens if, like, the person 850 00:35:56,810 --> 00:35:59,010 who has the last block-- 851 00:35:59,010 --> 00:36:00,585 who decides-- who timestamps it? 852 00:36:00,585 --> 00:36:02,460 TADGE DRYJA: You just time-- the person who's 853 00:36:02,460 --> 00:36:03,885 doing the work timestamps it. 854 00:36:03,885 --> 00:36:06,770 AUDIENCE: Could an actor timestamp it wrong to like-- 855 00:36:06,770 --> 00:36:07,520 TADGE DRYJA: Yeah. 856 00:36:07,520 --> 00:36:08,580 To screw around with the difficulty? 857 00:36:08,580 --> 00:36:09,080 Yeah. 858 00:36:09,080 --> 00:36:10,200 AUDIENCE: OK. 859 00:36:10,200 --> 00:36:12,117 TADGE DRYJA: You're fairly constrained, right? 860 00:36:12,117 --> 00:36:14,710 So it should be two weeks, and you can say, well, 861 00:36:14,710 --> 00:36:19,980 I bet if I'm off by 20 minutes everyone will be OK with it. 862 00:36:19,980 --> 00:36:22,770 But that's not a ton of control, right? 863 00:36:22,770 --> 00:36:25,860 If you're the last one of this difficulty adjustment thing, 864 00:36:25,860 --> 00:36:28,100 you could say, hey, I'm going to say it's-- 865 00:36:28,100 --> 00:36:28,950 I'm going to say-- 866 00:36:28,950 --> 00:36:30,987 what would you probably want to do? 867 00:36:30,987 --> 00:36:33,570 I'm going to say it's 20 minutes in the future, because I want 868 00:36:33,570 --> 00:36:36,150 the difficulty to not go up too much, because I'm 869 00:36:36,150 --> 00:36:38,490 trying to get more blocks. 870 00:36:38,490 --> 00:36:40,830 So you could try to push it to 20 minutes in the future 871 00:36:40,830 --> 00:36:42,600 from what it actually is, and people, 872 00:36:42,600 --> 00:36:44,267 all the rest of the nodes in the network 873 00:36:44,267 --> 00:36:47,520 will probably accept it. 874 00:36:47,520 --> 00:36:49,980 But you get 20 minutes difference 875 00:36:49,980 --> 00:36:53,298 over a two week period, which is way less than a percent, so-- 876 00:36:53,298 --> 00:36:54,840 AUDIENCE: And you said two hours is-- 877 00:36:54,840 --> 00:36:56,520 like, it would not take a block that 878 00:36:56,520 --> 00:36:57,840 says it's a week in the future? 879 00:36:57,840 --> 00:36:58,160 TADGE DRYJA: Yeah. 880 00:36:58,160 --> 00:36:58,660 Yeah. 881 00:36:58,660 --> 00:37:03,660 So-- the thing is, it's hard to-- 882 00:37:03,660 --> 00:37:07,020 you don't really necessarily know everyone's consensus rules 883 00:37:07,020 --> 00:37:08,790 in these systems. 884 00:37:08,790 --> 00:37:13,610 But I think the default is two hours from your clock. 885 00:37:13,610 --> 00:37:16,220 And every client I've seen will reject 886 00:37:16,220 --> 00:37:19,160 something that seems to be more than two hours off. 887 00:37:19,160 --> 00:37:20,960 Which is really lax, right? 888 00:37:20,960 --> 00:37:24,740 For most types of distributed systems, two hours is crazy. 889 00:37:24,740 --> 00:37:28,130 Most of the time they're going to be within a few seconds. 890 00:37:28,130 --> 00:37:32,180 So in general, I don't think it ever 891 00:37:32,180 --> 00:37:34,500 is a problem in terms of that. 892 00:37:34,500 --> 00:37:35,000 So yeah. 893 00:37:35,000 --> 00:37:35,770 But what people do-- 894 00:37:35,770 --> 00:37:36,020 OK. 895 00:37:36,020 --> 00:37:38,270 So one of the things they do, which I can get to here. 896 00:37:38,270 --> 00:37:42,470 Since there is a timestamp in the message being hashed, 897 00:37:42,470 --> 00:37:45,410 some chips that are purpose-built for doing 898 00:37:45,410 --> 00:37:48,800 this work, will actually flip bits in the timestamp, 899 00:37:48,800 --> 00:37:51,140 flip the low order bits, because they're like, well, 900 00:37:51,140 --> 00:37:53,210 no one cares what second it is, so I 901 00:37:53,210 --> 00:37:55,310 have a bit here that I can just turn on and off 902 00:37:55,310 --> 00:37:57,720 and use as a nonce. 903 00:37:57,720 --> 00:38:00,702 So the last, the lowest few bits, they just randomize. 904 00:38:00,702 --> 00:38:02,660 They're like, well, if I'm off by five seconds, 905 00:38:02,660 --> 00:38:05,090 no one cares whether future, past, 906 00:38:05,090 --> 00:38:06,780 so I'll just use this as nonce space. 907 00:38:06,780 --> 00:38:07,280 OK. 908 00:38:07,280 --> 00:38:11,510 So-- but I'll get into that a little more later. 909 00:38:11,510 --> 00:38:13,220 So anyways, so a block. 910 00:38:13,220 --> 00:38:14,200 Let's call this. 911 00:38:14,200 --> 00:38:17,060 A block has a bunch of data, and then we hash it, right? 912 00:38:17,060 --> 00:38:20,570 And in this case, it's got three things. 913 00:38:20,570 --> 00:38:23,660 It's got a previous hash, so a pointer. 914 00:38:23,660 --> 00:38:26,900 It specifies the thing it's building off of. 915 00:38:26,900 --> 00:38:28,640 It's got a message so that you can 916 00:38:28,640 --> 00:38:31,850 add your message that you're adding to the blockchain. 917 00:38:31,850 --> 00:38:33,680 And it's got a nonce, so that you 918 00:38:33,680 --> 00:38:36,960 can prove you're doing work. 919 00:38:36,960 --> 00:38:39,810 And then these are the things, the actual data, but then 920 00:38:39,810 --> 00:38:41,820 the block itself has a hash, right? 921 00:38:41,820 --> 00:38:45,690 And this hash is not included anywhere in the block, 922 00:38:45,690 --> 00:38:47,310 because it couldn't be, right? 923 00:38:47,310 --> 00:38:50,200 This is the hash of this data. 924 00:38:50,200 --> 00:38:53,370 And so we can compute it, but we can't we can't stick this 00db 925 00:38:53,370 --> 00:38:58,510 thing here, because that would then change the data itself. 926 00:38:58,510 --> 00:39:01,470 So the idea is, use these block hashes as identifiers. 927 00:39:01,470 --> 00:39:05,580 And in most of these systems, in general, the hash of something 928 00:39:05,580 --> 00:39:10,270 is its identifiers, its name, the way to point to it. 929 00:39:10,270 --> 00:39:10,770 OK. 930 00:39:10,770 --> 00:39:15,210 So the next block includes a hash of the last block, right? 931 00:39:15,210 --> 00:39:18,560 So here you're saying, OK, the previous block is 00db. 932 00:39:18,560 --> 00:39:19,980 You're pointing to it. 933 00:39:19,980 --> 00:39:22,080 And then you're adding your own message, oh hi. 934 00:39:22,080 --> 00:39:24,300 And you're adding your own nonce to make-- you know? 935 00:39:24,300 --> 00:39:27,690 And so these two things you start out with. 936 00:39:27,690 --> 00:39:30,155 You start out with the pointer to the previous block, 937 00:39:30,155 --> 00:39:31,530 and then you say, OK, the message 938 00:39:31,530 --> 00:39:33,840 I'm going to try to add here is oh hi. 939 00:39:33,840 --> 00:39:36,000 And then you start grinding through these, right? 940 00:39:36,000 --> 00:39:40,890 You start iterating or randomly attempting different nonces, 941 00:39:40,890 --> 00:39:44,760 until you found one where it's low, right? 942 00:39:44,760 --> 00:39:46,350 It's got a bunch of zeros. 943 00:39:46,350 --> 00:39:49,920 And so this is the nonce you need to specify 944 00:39:49,920 --> 00:39:51,450 to get a lot of zeros. 945 00:39:51,450 --> 00:39:54,390 And in this case, there's four characters of nonce. 946 00:39:54,390 --> 00:39:56,430 And you only need two characters of zero, 947 00:39:56,430 --> 00:40:00,130 so it's way more nonce space than you need. 948 00:40:00,130 --> 00:40:00,630 Yes? 949 00:40:00,630 --> 00:40:02,047 AUDIENCE: How many possible nonces 950 00:40:02,047 --> 00:40:04,265 are there that would result in this? 951 00:40:04,265 --> 00:40:05,950 TADGE DRYJA: In this case there would 952 00:40:05,950 --> 00:40:10,430 be, on average, 255 nonces that would work, right? 953 00:40:10,430 --> 00:40:12,450 Because-- I'm, OK. 954 00:40:12,450 --> 00:40:14,200 I haven't actually specified these things, 955 00:40:14,200 --> 00:40:20,200 but assuming the target here is must be less than 00ff, right? 956 00:40:20,200 --> 00:40:23,620 So you need eight zero bits in the front, 957 00:40:23,620 --> 00:40:26,410 and all the rest can be Fs. 958 00:40:26,410 --> 00:40:28,040 And you can have any nonce you want. 959 00:40:28,040 --> 00:40:32,090 And this is an actual hash function, which is 2 byes long. 960 00:40:32,090 --> 00:40:35,050 That means you've got 2 bytes here and only 1 byte specified, 961 00:40:35,050 --> 00:40:37,660 so you've got two to the 16 nonce space, 962 00:40:37,660 --> 00:40:40,210 and your output is constrained in 2 to the 8, 963 00:40:40,210 --> 00:40:44,410 so you're going to have 2 to the 8 different nonces that 964 00:40:44,410 --> 00:40:45,970 will work. 965 00:40:45,970 --> 00:40:48,310 In the case of Bitcoin, there's nowhere near 966 00:40:48,310 --> 00:40:50,020 enough nonce space, right? 967 00:40:50,020 --> 00:40:53,110 Because your actual constraint on your proof of work 968 00:40:53,110 --> 00:40:57,130 is a lot of bits, and you only have 4 bytes, or 32 bits, 969 00:40:57,130 --> 00:40:58,300 of nonce space. 970 00:40:58,300 --> 00:40:59,830 So what you actually end up doing 971 00:40:59,830 --> 00:41:03,850 is using your message as further nonce space, right? 972 00:41:03,850 --> 00:41:08,320 So the thing is, I could put oh hi 2, 973 00:41:08,320 --> 00:41:12,010 and now I've changed my message, which will change my hash. 974 00:41:12,010 --> 00:41:15,760 And so if I go through my entire nonce space 975 00:41:15,760 --> 00:41:19,660 and don't find a valid proof of work, I can edit my message 976 00:41:19,660 --> 00:41:21,730 and then go through it again. 977 00:41:21,730 --> 00:41:23,292 So that-- it's a little ugly, right? 978 00:41:23,292 --> 00:41:25,750 It'd be nicer if your nonce space was big enough that you'd 979 00:41:25,750 --> 00:41:27,010 never had to do that. 980 00:41:27,010 --> 00:41:30,190 In the case of Bitcoin, we don't know who designed it, 981 00:41:30,190 --> 00:41:33,130 and whoever designed it didn't put enough nonce space, 982 00:41:33,130 --> 00:41:35,340 and so it's kind of annoying. 983 00:41:35,340 --> 00:41:38,145 But you can get around it. 984 00:41:38,145 --> 00:41:40,270 In theory, you could just eliminate the nonce space 985 00:41:40,270 --> 00:41:45,277 entirely and say, well, just put it in the message, right? 986 00:41:45,277 --> 00:41:47,860 But it's nice-- it's much easier to think of when you're like, 987 00:41:47,860 --> 00:41:48,760 here are these separate things. 988 00:41:48,760 --> 00:41:49,635 Like, this is random. 989 00:41:49,635 --> 00:41:50,733 It has no real meaning. 990 00:41:50,733 --> 00:41:52,150 This is the thing that has meaning 991 00:41:52,150 --> 00:41:53,150 that we're going to use. 992 00:41:53,150 --> 00:41:54,720 Anyway. 993 00:41:54,720 --> 00:41:55,540 So yeah. 994 00:41:55,540 --> 00:41:57,400 The chain keeps building. 995 00:41:57,400 --> 00:42:01,250 You add work each time, right, by finding 996 00:42:01,250 --> 00:42:03,680 different nonces that match up with your message. 997 00:42:03,680 --> 00:42:04,545 How are you? 998 00:42:04,545 --> 00:42:05,300 Oh, I'm good. 999 00:42:05,300 --> 00:42:06,020 OK. 1000 00:42:06,020 --> 00:42:08,450 And the idea is if you flip a bit 1001 00:42:08,450 --> 00:42:11,600 in any block that's come out. 1002 00:42:11,600 --> 00:42:14,180 So, for example, you change oh hi to oh hey, 1003 00:42:14,180 --> 00:42:17,090 and try to leave everything the same, 1004 00:42:17,090 --> 00:42:18,680 you're going to change the hash. 1005 00:42:18,680 --> 00:42:20,750 So most likely, the proof of work 1006 00:42:20,750 --> 00:42:22,662 will no longer be valid, right? 1007 00:42:22,662 --> 00:42:23,870 Oh, this starts with a 9 now. 1008 00:42:23,870 --> 00:42:26,150 No one's going to use it. 1009 00:42:26,150 --> 00:42:28,640 And more importantly, actually, these pointers 1010 00:42:28,640 --> 00:42:29,810 stop working, right? 1011 00:42:29,810 --> 00:42:33,020 Because this block was pointing to 002c. 1012 00:42:33,020 --> 00:42:34,520 That's not this. 1013 00:42:34,520 --> 00:42:36,300 That's this other one. 1014 00:42:36,300 --> 00:42:39,740 So basically, you flip any bit in the entire history 1015 00:42:39,740 --> 00:42:42,560 of this chain, and it breaks, right? 1016 00:42:42,560 --> 00:42:45,620 So you can't go back and edit things. 1017 00:42:45,620 --> 00:42:47,400 You can't change messages after the fact. 1018 00:42:47,400 --> 00:42:49,460 So it gives you the nice property of immutability 1019 00:42:49,460 --> 00:42:52,260 that once a message is included in the system. 1020 00:42:52,260 --> 00:42:54,260 So in the case of money, once a transaction 1021 00:42:54,260 --> 00:42:57,547 has moved funds from one place to another, 1022 00:42:57,547 --> 00:42:58,880 you can't go back and change it. 1023 00:42:58,880 --> 00:43:01,180 You can't undo something. 1024 00:43:01,180 --> 00:43:03,740 Unless. 1025 00:43:03,740 --> 00:43:05,910 Unless you fork the chain. 1026 00:43:05,910 --> 00:43:12,320 So the idea is everyone is running this system. 1027 00:43:12,320 --> 00:43:15,320 Sometimes inadvertently, or sometimes on purpose, 1028 00:43:15,320 --> 00:43:17,720 you can have two branches, right? 1029 00:43:17,720 --> 00:43:20,300 You can't have something point to two 1030 00:43:20,300 --> 00:43:21,950 different previous blocks, right? 1031 00:43:21,950 --> 00:43:24,920 There's one specified-- so in this case, when 1032 00:43:24,920 --> 00:43:28,940 I say previous block, it's a single, specific hash 1033 00:43:28,940 --> 00:43:30,350 that I'm pointing to. 1034 00:43:30,350 --> 00:43:33,440 And since we're pretty sure we can't find collisions, 1035 00:43:33,440 --> 00:43:37,730 that means if I'm pointing to 00db, it's only this one, 1036 00:43:37,730 --> 00:43:39,290 which has the message hi. 1037 00:43:39,290 --> 00:43:42,200 I should not be able to find two different blocks which hash 1038 00:43:42,200 --> 00:43:45,440 to 00db, because then it's ambiguous, and like, wait, 1039 00:43:45,440 --> 00:43:47,003 which am I pointing to? 1040 00:43:47,003 --> 00:43:48,420 So I shouldn't be able to do that. 1041 00:43:48,420 --> 00:43:52,100 However, it's easy to have two blocks 1042 00:43:52,100 --> 00:43:54,170 here that both point to the same ancestor, 1043 00:43:54,170 --> 00:43:58,106 that both-- we call this a parent, call this a child, 1044 00:43:58,106 --> 00:43:59,870 call this a branch. 1045 00:43:59,870 --> 00:44:01,400 So this is easy to do, right? 1046 00:44:01,400 --> 00:44:04,820 Two different people can just come up with their own messages 1047 00:44:04,820 --> 00:44:08,630 and own nonces and point to the same ancestor. 1048 00:44:08,630 --> 00:44:10,340 They could do this inadvertently, 1049 00:44:10,340 --> 00:44:13,400 because they're not aware of each other's work, right? 1050 00:44:13,400 --> 00:44:15,660 Or maybe these two things happened at the same time, 1051 00:44:15,660 --> 00:44:17,200 and they're like, oh, well we both found the answers 1052 00:44:17,200 --> 00:44:18,350 at about the same time. 1053 00:44:18,350 --> 00:44:19,760 Or they could do it, maliciously, 1054 00:44:19,760 --> 00:44:22,562 where I saw that you made this block, 1055 00:44:22,562 --> 00:44:24,020 and I saw that you made this block, 1056 00:44:24,020 --> 00:44:28,280 and I'm going to make these two, to try to confuse things. 1057 00:44:28,280 --> 00:44:30,450 So this can happen. 1058 00:44:30,450 --> 00:44:34,100 And the rule in Bitcoin, and most all of these systems, 1059 00:44:34,100 --> 00:44:37,160 is OK, well, the highest blockchain wins. 1060 00:44:37,160 --> 00:44:38,840 The most work wins. 1061 00:44:38,840 --> 00:44:42,170 So that's just our metric for what we all determine 1062 00:44:42,170 --> 00:44:44,810 as the state of the system. 1063 00:44:44,810 --> 00:44:47,390 So everyone uses the chain with the most work. 1064 00:44:47,390 --> 00:44:49,880 And that can change, right? 1065 00:44:49,880 --> 00:44:56,060 Let's say we started off with the 008a being the chain tip. 1066 00:44:56,060 --> 00:44:59,210 That's what we call the current state of the system. 1067 00:44:59,210 --> 00:45:01,170 And then someone came along and said, 1068 00:45:01,170 --> 00:45:04,130 well, I'm want to get rid of this thing. 1069 00:45:04,130 --> 00:45:08,900 Something happened in 94 that I want to rewrite. 1070 00:45:08,900 --> 00:45:12,080 I want to get rid of the how ru message, 1071 00:45:12,080 --> 00:45:14,360 and I'm going to replace it with my own message. 1072 00:45:14,360 --> 00:45:18,320 And so the way I do it is I branch off from 002c, 1073 00:45:18,320 --> 00:45:23,360 make this one, make this one, and now, I've made another one. 1074 00:45:23,360 --> 00:45:27,000 So now, this branch here has the most work. 1075 00:45:27,000 --> 00:45:29,000 And everyone's going to use it. 1076 00:45:29,000 --> 00:45:31,560 And they sort of forget about these two things. 1077 00:45:31,560 --> 00:45:34,730 They're like, yeah, that was the tip. 1078 00:45:34,730 --> 00:45:38,570 That was the most work state of the system, but now this is. 1079 00:45:38,570 --> 00:45:39,770 So now we have to go back. 1080 00:45:39,770 --> 00:45:41,690 We have to erase these two messages, 1081 00:45:41,690 --> 00:45:45,140 and add these three messages, and now everyone 1082 00:45:45,140 --> 00:45:47,250 agrees that that's the next state the system. 1083 00:45:47,250 --> 00:45:51,920 And this is called a reorg, a reorganization of the block. 1084 00:45:51,920 --> 00:45:53,230 This is sort of bad, but yeah. 1085 00:45:53,230 --> 00:45:53,730 Yeah? 1086 00:45:53,730 --> 00:45:55,438 AUDIENCE: How does the whole process of-- 1087 00:45:59,160 --> 00:46:01,660 so no one realizes they're in the wrong chain, [INAUDIBLE],, 1088 00:46:01,660 --> 00:46:02,255 right? 1089 00:46:02,255 --> 00:46:02,610 TADGE DRYJA: Mm-hmm. 1090 00:46:02,610 --> 00:46:05,150 AUDIENCE: How do they say, OK, I need all the information 1091 00:46:05,150 --> 00:46:07,130 to build the actual chain? 1092 00:46:07,130 --> 00:46:07,880 TADGE DRYJA: Yeah. 1093 00:46:11,780 --> 00:46:15,150 They request it, or basically, someone says, hey, 1094 00:46:15,150 --> 00:46:17,890 I have these three. 1095 00:46:17,890 --> 00:46:18,890 And you're like, really? 1096 00:46:18,890 --> 00:46:19,520 What are those three? 1097 00:46:19,520 --> 00:46:20,270 And they give them to you. 1098 00:46:20,270 --> 00:46:21,150 And you're like, OK. 1099 00:46:21,150 --> 00:46:21,650 Yep. 1100 00:46:21,650 --> 00:46:22,700 That works. 1101 00:46:22,700 --> 00:46:25,293 So the actual network-- 1102 00:46:25,293 --> 00:46:27,710 I think in a few weeks we're going into the actual network 1103 00:46:27,710 --> 00:46:32,540 messages that are used in Bitcoin, but they're not like-- 1104 00:46:32,540 --> 00:46:33,212 you-- 1105 00:46:33,212 --> 00:46:34,670 actually, if you wrote it yourself, 1106 00:46:34,670 --> 00:46:36,720 you'd probably write something more sensible and better. 1107 00:46:36,720 --> 00:46:37,610 It's a little weird. 1108 00:46:37,610 --> 00:46:39,350 But basically, you sort of-- 1109 00:46:39,350 --> 00:46:41,750 nodes in this network are all connected to each other, 1110 00:46:41,750 --> 00:46:43,250 and they report on what they have. 1111 00:46:43,250 --> 00:46:45,490 And they say, hey, I have 0061. 1112 00:46:45,490 --> 00:46:46,490 And you're like, really? 1113 00:46:46,490 --> 00:46:48,320 I don't have 0061. 1114 00:46:48,320 --> 00:46:50,228 And you think, maybe 0061 builds off here. 1115 00:46:50,228 --> 00:46:51,770 You request 0061 and you're like, oh, 1116 00:46:51,770 --> 00:46:53,750 it builds off of here. 1117 00:46:53,750 --> 00:46:55,270 And then they're like, I have f2. 1118 00:46:55,270 --> 00:46:55,940 I have a3. 1119 00:46:55,940 --> 00:46:57,760 And so they build these-- 1120 00:46:57,760 --> 00:47:00,200 you know, they request them all and build them. 1121 00:47:00,200 --> 00:47:02,870 And then they actually keep these in memory 1122 00:47:02,870 --> 00:47:04,580 for a little while, and then-- 1123 00:47:04,580 --> 00:47:07,530 but I don't think they save them on disc. 1124 00:47:07,530 --> 00:47:10,070 So you can have multiple different branches, 1125 00:47:10,070 --> 00:47:12,770 concurrently, in your software, and you just use this 1126 00:47:12,770 --> 00:47:13,840 and show this to the UI. 1127 00:47:13,840 --> 00:47:14,340 Yeah? 1128 00:47:14,340 --> 00:47:17,250 AUDIENCE: Who specifically do you ask for the chain? 1129 00:47:17,250 --> 00:47:21,668 Because if it needs only one, then you could just sort of-- 1130 00:47:21,668 --> 00:47:22,710 TADGE DRYJA: Needs only-- 1131 00:47:22,710 --> 00:47:24,810 AUDIENCE: If only one person had a longer chain, 1132 00:47:24,810 --> 00:47:27,410 and then everyone starts replicating it, 1133 00:47:27,410 --> 00:47:29,470 then the network starts believing it, right? 1134 00:47:29,470 --> 00:47:29,620 TADGE DRYJA: Yep. 1135 00:47:29,620 --> 00:47:30,120 Yep. 1136 00:47:30,120 --> 00:47:32,550 So it's a gossip network. 1137 00:47:32,550 --> 00:47:34,910 So basically, there's no real identity 1138 00:47:34,910 --> 00:47:38,060 for all the different nodes of computers. 1139 00:47:38,060 --> 00:47:39,940 You also will report all the-- 1140 00:47:39,940 --> 00:47:42,620 you basically do it by IP address, right? 1141 00:47:42,620 --> 00:47:46,010 So when I connect to a node, I don't think I ask. 1142 00:47:46,010 --> 00:47:47,610 I think they just tell me, like, hey, 1143 00:47:47,610 --> 00:47:50,588 here's a thousand IP addresses that I know of, 1144 00:47:50,588 --> 00:47:52,880 that I've connected to, that are running this software. 1145 00:47:52,880 --> 00:47:53,713 And you're like, OK. 1146 00:47:53,713 --> 00:47:55,190 I'll add that into my list. 1147 00:47:55,190 --> 00:47:57,100 And then you just randomly connect to people. 1148 00:47:57,100 --> 00:48:00,690 I think the default is randomly connect to seven peers. 1149 00:48:00,690 --> 00:48:02,030 And then when you-- 1150 00:48:02,030 --> 00:48:04,330 when anything comes in, you're like, hey, I got a new-- 1151 00:48:04,330 --> 00:48:06,260 you know, I got a new block message. 1152 00:48:06,260 --> 00:48:08,180 You will tell all seven of your peers. 1153 00:48:08,180 --> 00:48:09,650 Hey, I got 00a3. 1154 00:48:09,650 --> 00:48:12,410 And if they request what the data is, 1155 00:48:12,410 --> 00:48:13,980 you'll give it to them. 1156 00:48:13,980 --> 00:48:16,950 So in practice, things get propagated pretty well. 1157 00:48:16,950 --> 00:48:18,260 But yeah, partition attacks. 1158 00:48:18,260 --> 00:48:20,180 If you can isolate-- 1159 00:48:20,180 --> 00:48:23,030 so like, if you can isolate this off the network, 1160 00:48:23,030 --> 00:48:25,950 you may be able to prevent this kind of thing from happening. 1161 00:48:25,950 --> 00:48:29,280 So if someone built these three blocks 1162 00:48:29,280 --> 00:48:31,880 but isn't able to broadcast it to the network, 1163 00:48:31,880 --> 00:48:35,720 then people will still think that this is the most work 1164 00:48:35,720 --> 00:48:36,950 and build off of this. 1165 00:48:36,950 --> 00:48:39,550 So yeah, those are attacks that can happen. 1166 00:48:39,550 --> 00:48:40,050 Yeah? 1167 00:48:40,050 --> 00:48:43,335 AUDIENCE: What happens if you reorg transactions, 1168 00:48:43,335 --> 00:48:44,165 for instance? 1169 00:48:44,165 --> 00:48:46,280 Like if the messages were transactions? 1170 00:48:46,280 --> 00:48:47,030 TADGE DRYJA: Yeah. 1171 00:48:47,030 --> 00:48:50,970 They stop being-- they get undone. 1172 00:48:50,970 --> 00:48:52,240 So this is a very real risk. 1173 00:48:52,240 --> 00:48:56,630 If you have a-- 1174 00:48:56,630 --> 00:49:00,490 Alice is sending Bob 5 bitcoins in this block. 1175 00:49:00,490 --> 00:49:02,740 And in this block, you have a conflicting transaction, 1176 00:49:02,740 --> 00:49:07,640 Alice is sending Carol 5 bitcoins, the same 5 bitcoins, 1177 00:49:07,640 --> 00:49:10,370 Bob could think at this point, hey, I got some money. 1178 00:49:10,370 --> 00:49:11,300 I have some money. 1179 00:49:11,300 --> 00:49:12,050 Oh, shoot. 1180 00:49:12,050 --> 00:49:14,420 I, whoops, don't have the money anymore when 1181 00:49:14,420 --> 00:49:16,490 this gets reorged out. 1182 00:49:16,490 --> 00:49:18,950 So that's-- that is an attack, right? 1183 00:49:18,950 --> 00:49:22,550 And you have to be aware of that in using Bitcoin, or any 1184 00:49:22,550 --> 00:49:23,750 of these kinds of systems. 1185 00:49:23,750 --> 00:49:26,360 They're not-- you have consensus, 1186 00:49:26,360 --> 00:49:29,510 but I think it's like eventually consensus. 1187 00:49:29,510 --> 00:49:33,980 So generally, the rule of thumb people use is wait six blocks. 1188 00:49:33,980 --> 00:49:36,440 I think that's in the original Bitcoin white paper. 1189 00:49:36,440 --> 00:49:37,580 Which is fairly arbitrary. 1190 00:49:37,580 --> 00:49:39,080 Like, you know? 1191 00:49:39,080 --> 00:49:40,940 The longer you wait, the more certain it is. 1192 00:49:40,940 --> 00:49:44,540 The more difficult it will be to perform this kind of attack, 1193 00:49:44,540 --> 00:49:47,720 because you're going to have to do more work, right? 1194 00:49:47,720 --> 00:49:49,940 And the idea is everyone's building off of the one 1195 00:49:49,940 --> 00:49:51,630 that they think is the tip. 1196 00:49:51,630 --> 00:49:53,050 So everyone's going to-- 1197 00:49:53,050 --> 00:49:57,320 you have to get pretty lucky or outrun everyone else to perform 1198 00:49:57,320 --> 00:49:58,460 this kind of attack. 1199 00:49:58,460 --> 00:50:00,260 So. 1200 00:50:00,260 --> 00:50:00,760 OK. 1201 00:50:00,760 --> 00:50:01,450 Yeah? 1202 00:50:01,450 --> 00:50:04,160 AUDIENCE: Are those known as uncles? 1203 00:50:04,160 --> 00:50:05,210 TADGE DRYJA: Oh. 1204 00:50:05,210 --> 00:50:07,850 So like, in Ethereum and some other systems 1205 00:50:07,850 --> 00:50:11,090 they have uncles where you can point 1206 00:50:11,090 --> 00:50:13,572 to multiple ancestors, which is weird, 1207 00:50:13,572 --> 00:50:16,030 because your uncle is not really your ancestor, but anyway. 1208 00:50:16,030 --> 00:50:17,780 [LAUGHTER] 1209 00:50:17,780 --> 00:50:21,410 So that would let-- 1210 00:50:21,410 --> 00:50:28,740 for example, that would let 00f2 to point to both 0061 and 0094. 1211 00:50:28,740 --> 00:50:29,990 NEHA NARULA: The answer is no. 1212 00:50:29,990 --> 00:50:30,940 These are not uncles. 1213 00:50:30,940 --> 00:50:31,150 TADGE DRYJA: Yes. 1214 00:50:31,150 --> 00:50:31,490 So yes. 1215 00:50:31,490 --> 00:50:31,920 NEHA NARULA: [LAUGHS] 1216 00:50:31,920 --> 00:50:32,780 TADGE DRYJA: Sorry. 1217 00:50:32,780 --> 00:50:34,460 Uncles is a separate thing. 1218 00:50:34,460 --> 00:50:37,258 This is not uncles, but related, right? 1219 00:50:37,258 --> 00:50:39,716 You could draw, like-- you could draw an arrow there, and-- 1220 00:50:39,716 --> 00:50:40,500 I don't know. 1221 00:50:40,500 --> 00:50:41,000 OK. 1222 00:50:41,000 --> 00:50:44,450 So I'll talk about pros and cons, and some of this 1223 00:50:44,450 --> 00:50:49,538 gets into not as objective and somewhat subjective ideas. 1224 00:50:49,538 --> 00:50:51,830 But it's an interesting thing to talk about, especially 1225 00:50:51,830 --> 00:50:52,860 in context of money. 1226 00:50:52,860 --> 00:50:53,360 OK. 1227 00:50:53,360 --> 00:50:53,990 So pros. 1228 00:50:53,990 --> 00:50:56,150 Anonymous, member lists, scalable, non-interactive. 1229 00:50:56,150 --> 00:50:57,240 I'll go through all of these. 1230 00:50:57,240 --> 00:50:58,198 Tied to the real world. 1231 00:50:58,198 --> 00:50:59,360 Cons. 1232 00:50:59,360 --> 00:51:00,590 Pretty much all nonces fail. 1233 00:51:00,590 --> 00:51:01,520 It uses watts. 1234 00:51:01,520 --> 00:51:02,150 It uses chips. 1235 00:51:02,150 --> 00:51:03,758 There's 51% attacks. 1236 00:51:03,758 --> 00:51:04,550 And people hate it. 1237 00:51:04,550 --> 00:51:06,740 [LAUGHTER] 1238 00:51:06,740 --> 00:51:08,700 So the pros. 1239 00:51:08,700 --> 00:51:11,210 They're quite good. 1240 00:51:11,210 --> 00:51:12,680 It is anonymous, right? 1241 00:51:12,680 --> 00:51:15,770 You can mine without any kind of identity. 1242 00:51:15,770 --> 00:51:17,870 Even after you've mined, you don't really 1243 00:51:17,870 --> 00:51:20,870 have to say who you are. 1244 00:51:20,870 --> 00:51:22,320 There's no pre-known keys. 1245 00:51:22,320 --> 00:51:24,290 There's actually no signatures involved, right? 1246 00:51:24,290 --> 00:51:26,510 There's no public key system at all. 1247 00:51:26,510 --> 00:51:29,240 You're just trying different nonces. 1248 00:51:29,240 --> 00:51:31,070 Anyone can go for it. 1249 00:51:31,070 --> 00:51:35,090 Every attempt is equally likely to succeed, since it's random, 1250 00:51:35,090 --> 00:51:36,410 and it's not limited to humans. 1251 00:51:36,410 --> 00:51:38,320 So you could have-- 1252 00:51:38,320 --> 00:51:40,370 you don't need a social security number. 1253 00:51:40,370 --> 00:51:42,900 Bots are welcome. 1254 00:51:42,900 --> 00:51:44,330 Anything can mine. 1255 00:51:44,330 --> 00:51:47,960 And everyone doesn't really care who mined it. 1256 00:51:47,960 --> 00:51:48,860 It's not about who. 1257 00:51:48,860 --> 00:51:49,890 It's just oh, there's a nonce. 1258 00:51:49,890 --> 00:51:50,432 There's work. 1259 00:51:50,432 --> 00:51:51,710 OK, this is valid. 1260 00:51:51,710 --> 00:51:53,930 So that's really cool. 1261 00:51:53,930 --> 00:51:55,290 It's memory-less. 1262 00:51:55,290 --> 00:52:00,030 This is important, and a little counter-intuitive in some ways. 1263 00:52:00,030 --> 00:52:01,470 There's no progress. 1264 00:52:01,470 --> 00:52:05,540 So if you have 10 trillion failed nonces, 1265 00:52:05,540 --> 00:52:07,970 your next nonce is just as likely to fail, 1266 00:52:07,970 --> 00:52:10,820 which is extremely likely. 1267 00:52:10,820 --> 00:52:12,740 So that makes it a Poisson process, right? 1268 00:52:12,740 --> 00:52:15,830 Which is-- you know, it's a certain probability 1269 00:52:15,830 --> 00:52:17,630 distribution, kind of thing. 1270 00:52:17,630 --> 00:52:21,780 You will always expect the next block in 10 minutes from now. 1271 00:52:21,780 --> 00:52:24,678 So, hey, it's been 20 minutes since the last block came out. 1272 00:52:24,678 --> 00:52:25,970 When's the next one coming out? 1273 00:52:25,970 --> 00:52:29,180 Probably 10 minutes. 1274 00:52:29,180 --> 00:52:31,942 And there's no-- it's sort of like-- 1275 00:52:31,942 --> 00:52:33,650 you know, there's no progress being made. 1276 00:52:33,650 --> 00:52:36,440 You always have no memory of what 1277 00:52:36,440 --> 00:52:38,000 the last few minutes have had. 1278 00:52:38,000 --> 00:52:39,770 So the fact that it's been 10 minutes, 1279 00:52:39,770 --> 00:52:41,990 the fact that it's-- or it's been two seconds, 1280 00:52:41,990 --> 00:52:44,157 you still think it's going to take about 10 minutes. 1281 00:52:46,020 --> 00:52:47,660 Which is nice, because it means there's 1282 00:52:47,660 --> 00:52:50,390 a linear trade off between how many attempts you're making 1283 00:52:50,390 --> 00:52:53,420 and what your chances of finding the next block are. 1284 00:52:53,420 --> 00:52:55,220 So if you attempt twice as many, you 1285 00:52:55,220 --> 00:52:57,920 have twice as good a chance of finding the next block. 1286 00:52:57,920 --> 00:53:00,350 Which is good, because if there is progress, right, 1287 00:53:00,350 --> 00:53:05,360 if you had some kind of function where the probability was not 1288 00:53:05,360 --> 00:53:07,280 just linear number of chances, but if it 1289 00:53:07,280 --> 00:53:11,600 was super linear, exponential or something like that, you-- 1290 00:53:11,600 --> 00:53:15,050 the fastest person would always win, right? 1291 00:53:15,050 --> 00:53:17,360 So if it's like, OK, I need to compute this thing, 1292 00:53:17,360 --> 00:53:22,490 and it takes a couple trillion computations. 1293 00:53:22,490 --> 00:53:25,190 And so for some computers, it takes five minutes. 1294 00:53:25,190 --> 00:53:27,448 For some computers, it only takes two minutes. 1295 00:53:27,448 --> 00:53:29,240 The computers that can do it in two minutes 1296 00:53:29,240 --> 00:53:31,730 are just always going to win, because the people who 1297 00:53:31,730 --> 00:53:34,310 take five minutes to finish it, well, they just 1298 00:53:34,310 --> 00:53:37,220 did it in two minutes, and I can't keep up with them. 1299 00:53:37,220 --> 00:53:39,740 So this is really nice, and it makes it competitive. 1300 00:53:39,740 --> 00:53:41,860 Otherwise, it would end up being like whoever 1301 00:53:41,860 --> 00:53:44,950 is fastest just consistently can perform the work. 1302 00:53:47,630 --> 00:53:49,190 Any questions about memory lists? 1303 00:53:49,190 --> 00:53:51,020 It's kind of-- this-- 1304 00:53:51,020 --> 00:53:54,800 I mean, you guys actually know computers, and stuff, and math. 1305 00:53:54,800 --> 00:53:55,580 You know, MIT. 1306 00:53:55,580 --> 00:53:59,900 But this is a fairly common misconception in Bitcoin 1307 00:53:59,900 --> 00:54:03,230 and other systems like this, where people get mad. 1308 00:54:03,230 --> 00:54:05,420 Like, it's been an hour and no block's come out. 1309 00:54:05,420 --> 00:54:06,980 It's like well, yeah, you know? 1310 00:54:06,980 --> 00:54:08,450 Poisson process. 1311 00:54:08,450 --> 00:54:13,130 On average, every day and a half there will be a one hour gap. 1312 00:54:13,130 --> 00:54:14,810 And then people have been, like, well, 1313 00:54:14,810 --> 00:54:17,420 the last three blocks came out in like, two minutes. 1314 00:54:17,420 --> 00:54:19,670 So there's going to be a awhile before the next block. 1315 00:54:19,670 --> 00:54:20,378 It's like no, no. 1316 00:54:20,378 --> 00:54:20,878 There's-- 1317 00:54:20,878 --> 00:54:21,560 [LAUGHTER] 1318 00:54:21,560 --> 00:54:24,440 There's no memory. 1319 00:54:24,440 --> 00:54:27,320 So there's a lot of misconceptions 1320 00:54:27,320 --> 00:54:30,290 when it's a purely random system, that people are not 1321 00:54:30,290 --> 00:54:32,240 used to this kind of thing. 1322 00:54:32,240 --> 00:54:33,950 But it's counter-intuitive, right? 1323 00:54:33,950 --> 00:54:35,770 Even I think, like, oh, well-- 1324 00:54:35,770 --> 00:54:36,330 no, no. 1325 00:54:36,330 --> 00:54:36,830 Memory-less. 1326 00:54:36,830 --> 00:54:38,390 Got to remember that. 1327 00:54:38,390 --> 00:54:40,350 Got to remember that it's memory-less. 1328 00:54:40,350 --> 00:54:40,850 OK. 1329 00:54:40,850 --> 00:54:44,000 So scalability is actually amazing. 1330 00:54:44,000 --> 00:54:47,720 So this is a block hash from this morning, 1331 00:54:47,720 --> 00:54:52,010 or late last night, that actually happened in Bitcoin, 1332 00:54:52,010 --> 00:54:53,840 and there's a lot of zeros. 1333 00:54:53,840 --> 00:54:58,940 There's 18 of them, and 9 bytes, and actually more, 1334 00:54:58,940 --> 00:55:02,870 because it starts with a three instead of an f or something. 1335 00:55:02,870 --> 00:55:05,420 So what's really cool about this is it takes just as long 1336 00:55:05,420 --> 00:55:08,730 to verify this work as it did with the one with my name, 1337 00:55:08,730 --> 00:55:09,230 right? 1338 00:55:09,230 --> 00:55:13,130 Which only had 4 bytes of work, you know? 1339 00:55:13,130 --> 00:55:16,100 And the one with my name, it took my computer, 1340 00:55:16,100 --> 00:55:18,200 I don't know, 20 minutes or whatever to do. 1341 00:55:18,200 --> 00:55:21,290 This took computer-- you know, this one 1342 00:55:21,290 --> 00:55:22,442 took 10 minutes, right? 1343 00:55:22,442 --> 00:55:23,900 But it took the network 10 minutes, 1344 00:55:23,900 --> 00:55:27,570 because everyone's participating at the same time. 1345 00:55:27,570 --> 00:55:28,070 So yeah. 1346 00:55:28,070 --> 00:55:29,570 And it's a trillion times more work, 1347 00:55:29,570 --> 00:55:31,370 and takes no more time to verify. 1348 00:55:31,370 --> 00:55:34,730 That's really cool, and it is kind of amazing, 1349 00:55:34,730 --> 00:55:39,770 because this is almost a mole of attempts. 1350 00:55:39,770 --> 00:55:41,190 Like, Avogadro's number. 1351 00:55:41,190 --> 00:55:43,160 So you're getting into numbers that like, 1352 00:55:43,160 --> 00:55:47,030 you never deal with these scales of numbers in-- 1353 00:55:47,030 --> 00:55:51,350 I mean, you do in chemistry, but, like, whoa. 1354 00:55:51,350 --> 00:55:54,620 So that's a nice property. 1355 00:55:54,620 --> 00:55:57,410 Also, it's non-interactive, and that helps as well. 1356 00:55:57,410 --> 00:56:01,100 So you never have to report your failed attempts, right? 1357 00:56:01,100 --> 00:56:03,590 So you can have a thousand different computers all 1358 00:56:03,590 --> 00:56:07,460 trying one nonce with different messages, 1359 00:56:07,460 --> 00:56:09,290 or one chip trying a thousand times, 1360 00:56:09,290 --> 00:56:12,290 and you don't need any communication between them. 1361 00:56:12,290 --> 00:56:14,870 So the only communication between in the network 1362 00:56:14,870 --> 00:56:16,590 is when a block is actually found. 1363 00:56:16,590 --> 00:56:18,915 So there's no real setup needed. 1364 00:56:18,915 --> 00:56:21,290 So it's a very simple message protocol where you say hey, 1365 00:56:21,290 --> 00:56:21,915 here's a block. 1366 00:56:21,915 --> 00:56:23,410 Everyone just broadcasts. 1367 00:56:23,410 --> 00:56:24,442 That's really cool, too. 1368 00:56:24,442 --> 00:56:26,150 So these are all really useful properties 1369 00:56:26,150 --> 00:56:28,976 for our network and our consensus system. 1370 00:56:28,976 --> 00:56:29,750 Oh, also. 1371 00:56:29,750 --> 00:56:32,650 It uses real world resources. 1372 00:56:32,650 --> 00:56:37,300 So when you want to go back and rewrite history, 1373 00:56:37,300 --> 00:56:40,990 even if a majority of participants want to do that, 1374 00:56:40,990 --> 00:56:43,120 there's still going to be a cost. 1375 00:56:43,120 --> 00:56:46,690 So that's pretty unique compared to many different says 1376 00:56:46,690 --> 00:56:47,740 consensus systems. 1377 00:56:47,740 --> 00:56:51,340 In many systems, say, OK, well, we have unanimous agreement. 1378 00:56:51,340 --> 00:56:54,753 All participants in the system are going to rewrite history. 1379 00:56:54,753 --> 00:56:56,920 We're going to go back, pretend that never happened, 1380 00:56:56,920 --> 00:57:00,640 and branch off and create a new history. 1381 00:57:00,640 --> 00:57:03,670 Even if everyone in Bitcoin, every participant, 1382 00:57:03,670 --> 00:57:05,240 tries to do that, they're still going 1383 00:57:05,240 --> 00:57:09,340 to have to spend that energy and that work. 1384 00:57:09,340 --> 00:57:12,820 And so that really discourages reorging 1385 00:57:12,820 --> 00:57:15,790 and trying to rewrite history, even when everyone wants to. 1386 00:57:15,790 --> 00:57:18,940 So that's cool in that you're tied down 1387 00:57:18,940 --> 00:57:21,040 not just by the other participants in the system, 1388 00:57:21,040 --> 00:57:24,270 but by physics itself and the way the world works. 1389 00:57:24,270 --> 00:57:27,100 We are going to have to do work to rewrite this. 1390 00:57:27,100 --> 00:57:30,512 So that's-- and also, it shows that people are sort 1391 00:57:30,512 --> 00:57:31,970 of invested, and they've done work. 1392 00:57:31,970 --> 00:57:33,240 So that's cool, too. 1393 00:57:33,240 --> 00:57:33,740 OK. 1394 00:57:33,740 --> 00:57:36,573 So any questions about all these pros? 1395 00:57:36,573 --> 00:57:38,240 Or if you want to say some of these pros 1396 00:57:38,240 --> 00:57:40,032 are actually cons before I get to the cons? 1397 00:57:43,870 --> 00:57:44,610 OK. 1398 00:57:44,610 --> 00:57:45,360 We can go to cons. 1399 00:57:45,360 --> 00:57:48,180 And this-- it's always more fun to complain about stuff. 1400 00:57:48,180 --> 00:57:50,250 So we can go into cons, and I'm sure people 1401 00:57:50,250 --> 00:57:54,930 can jump in with other things that, oh, yeah, this is bad. 1402 00:57:54,930 --> 00:57:58,790 So one problem is that it's inefficient. 1403 00:57:58,790 --> 00:58:00,840 Almost every attempt fails. 1404 00:58:00,840 --> 00:58:01,840 So that's no fun, right? 1405 00:58:01,840 --> 00:58:04,490 So the proof of work from a few hours 1406 00:58:04,490 --> 00:58:08,480 ago, this is 10 to the 22 attempts. 1407 00:58:08,480 --> 00:58:13,520 And all-- you know, there's 10 to 22 failed attempts that 1408 00:58:13,520 --> 00:58:16,310 were required, that happened, in order to get that one. 1409 00:58:16,310 --> 00:58:19,430 So that's extremely inefficient, you know? 1410 00:58:19,430 --> 00:58:22,100 I don't know how to express that as a percentage, 1411 00:58:22,100 --> 00:58:24,950 but the actual things moving the system 1412 00:58:24,950 --> 00:58:27,200 are some incredibly small percentage 1413 00:58:27,200 --> 00:58:30,360 of the actual things happening. 1414 00:58:30,360 --> 00:58:33,230 It's also a problem because you're not 1415 00:58:33,230 --> 00:58:35,870 going to be able to get a valid block, right? 1416 00:58:35,870 --> 00:58:39,048 If you have to 2 to the 72 attempts, 1417 00:58:39,048 --> 00:58:40,340 you're just not going to do it. 1418 00:58:40,340 --> 00:58:41,090 Like, ever. 1419 00:58:41,090 --> 00:58:44,060 You can run your laptop for your entire life 1420 00:58:44,060 --> 00:58:47,540 and you will not be able to do two to the 72 work, which 1421 00:58:47,540 --> 00:58:48,920 is kind of depressing. 1422 00:58:48,920 --> 00:58:51,590 Even if you buy specialized hardware, yeah, 1423 00:58:51,590 --> 00:58:52,610 you're not going to-- 1424 00:58:52,610 --> 00:58:54,750 you're not going to find a block. 1425 00:58:54,750 --> 00:58:58,777 It consolidates into-- you need a factory. 1426 00:58:58,777 --> 00:59:00,860 You need a warehouse full of equipment, basically, 1427 00:59:00,860 --> 00:59:03,200 in order to do this now. 1428 00:59:03,200 --> 00:59:05,270 So that's kind of annoying, right? 1429 00:59:05,270 --> 00:59:06,170 It's not as fun. 1430 00:59:06,170 --> 00:59:08,720 Like, the small players have been pushed out of the game 1431 00:59:08,720 --> 00:59:11,540 because you need to do so much work in order 1432 00:59:11,540 --> 00:59:14,180 to have-- you can't get, hey, I came close. 1433 00:59:14,180 --> 00:59:15,590 Can I get partial credit? 1434 00:59:15,590 --> 00:59:18,290 Can I-- you know, I did 2 to the 50 work. 1435 00:59:18,290 --> 00:59:20,540 Can I get anything for that? 1436 00:59:20,540 --> 00:59:23,520 The system doesn't recognize partial work. 1437 00:59:23,520 --> 00:59:24,020 OK. 1438 00:59:24,020 --> 00:59:25,610 Other cons. 1439 00:59:25,610 --> 00:59:29,570 It uses watts and chips, uses lots of electricity. 1440 00:59:29,570 --> 00:59:31,810 You could use that electricity to charge your car 1441 00:59:31,810 --> 00:59:34,790 or do something cool. 1442 00:59:34,790 --> 00:59:39,230 It uses fabs to make microchips, which could make more CPUs 1443 00:59:39,230 --> 00:59:42,290 or make cool phones or something. 1444 00:59:42,290 --> 00:59:43,910 Once it gets big enough, it actually 1445 00:59:43,910 --> 00:59:45,650 starts affecting markets. 1446 00:59:45,650 --> 00:59:46,970 So I don't know if-- 1447 00:59:46,970 --> 00:59:51,707 I just know in Micro Center, down there, many times-- 1448 00:59:51,707 --> 00:59:52,790 because I live near there. 1449 00:59:52,790 --> 00:59:55,760 And you go around, and there's the GPU section, 1450 00:59:55,760 --> 00:59:57,950 and everyone complains about Bitcoin 1451 00:59:57,950 --> 01:00:00,350 in Micro Center near the GPUs. 1452 01:00:00,350 --> 01:00:01,250 It's a Bitcoin. 1453 01:00:01,250 --> 01:00:06,050 It's usually Ethereum and other coins that use GPUs for mining, 1454 01:00:06,050 --> 01:00:10,940 but that has had a really big effect on the market for GPUs. 1455 01:00:10,940 --> 01:00:13,232 A lot of people-- because you can make money with them. 1456 01:00:13,232 --> 01:00:14,648 So people are like, yeah, I'll buy 1457 01:00:14,648 --> 01:00:16,640 one of these things for $500, because I'll 1458 01:00:16,640 --> 01:00:19,700 make back my $500 in a year. 1459 01:00:19,700 --> 01:00:22,370 And then I'll still have the GPU, 1460 01:00:22,370 --> 01:00:24,380 and maybe I can sell it used, and get a couple 1461 01:00:24,380 --> 01:00:27,140 hundred dollars back, and then I profited. 1462 01:00:27,140 --> 01:00:28,460 So these things affect-- 1463 01:00:28,460 --> 01:00:30,470 it's big enough that it affects markets. 1464 01:00:30,470 --> 01:00:32,450 Initially it didn't, because it was just 1465 01:00:32,450 --> 01:00:34,100 a couple of nerds running Bitcoin, 1466 01:00:34,100 --> 01:00:35,540 and so like, who cares? 1467 01:00:35,540 --> 01:00:37,610 You know, a couple of people buying GPUs. 1468 01:00:37,610 --> 01:00:38,690 But now it's big enough. 1469 01:00:38,690 --> 01:00:40,430 These are like billion dollar markets, 1470 01:00:40,430 --> 01:00:46,880 and it's getting to be the same sort of scale as the gamer 1471 01:00:46,880 --> 01:00:50,210 market-- or gamer, or whatever-- 1472 01:00:50,210 --> 01:00:52,470 CUDA, or whatever people use GPUs for. 1473 01:00:52,470 --> 01:00:54,990 But you know, mining is significant, 1474 01:00:54,990 --> 01:00:56,520 and so it affects the market. 1475 01:00:56,520 --> 01:00:57,020 Who knows? 1476 01:00:57,020 --> 01:00:59,600 Someday you could start to affect electricity prices 1477 01:00:59,600 --> 01:01:03,560 if you get big enough, where a significant portion of all 1478 01:01:03,560 --> 01:01:06,320 the electrical usage in the world or the country 1479 01:01:06,320 --> 01:01:09,260 is going into doing this sha256. 1480 01:01:09,260 --> 01:01:11,380 And so that makes electricity prices go up. 1481 01:01:11,380 --> 01:01:13,130 And then everyone starts complaining like, 1482 01:01:13,130 --> 01:01:15,033 man, electricity is twice as much 1483 01:01:15,033 --> 01:01:17,450 as it used to be because all these people mining Bitcoins. 1484 01:01:17,450 --> 01:01:21,230 And it's possible if it gets big enough, instead of just people 1485 01:01:21,230 --> 01:01:22,490 complaining about GPUs. 1486 01:01:22,490 --> 01:01:23,930 So that's sort of a con, right? 1487 01:01:23,930 --> 01:01:29,360 That's-- it starts affecting the real world in big ways. 1488 01:01:29,360 --> 01:01:32,480 The corollary of it being a memory-less process 1489 01:01:32,480 --> 01:01:34,520 is that it's irregular. 1490 01:01:34,520 --> 01:01:36,740 It's a Poisson process, which means 1491 01:01:36,740 --> 01:01:38,570 sometimes you get in a few seconds, 1492 01:01:38,570 --> 01:01:39,990 and sometimes it takes an hour. 1493 01:01:39,990 --> 01:01:43,130 And people don't like that, right? 1494 01:01:43,130 --> 01:01:46,607 I can see how you'd rather have something come out regularly. 1495 01:01:46,607 --> 01:01:48,440 A lot of people think, yeah, blocks come out 1496 01:01:48,440 --> 01:01:50,030 every 10 minutes. 1497 01:01:50,030 --> 01:01:52,760 Well, on average, every 10 minutes, but it can be hours. 1498 01:01:52,760 --> 01:01:54,590 It can be seconds. 1499 01:01:54,590 --> 01:01:57,740 And so that's hard. 1500 01:01:57,740 --> 01:01:59,660 In some cases, you can't really use it. 1501 01:01:59,660 --> 01:02:01,740 Like, hey, I want a regular clock, 1502 01:02:01,740 --> 01:02:04,692 or I want messages that come out in some kind of-- 1503 01:02:04,692 --> 01:02:05,900 I want some assurance, right? 1504 01:02:05,900 --> 01:02:08,420 If I make a transaction, I want it 1505 01:02:08,420 --> 01:02:09,920 to be included in the system. 1506 01:02:09,920 --> 01:02:12,890 I want some assurance it will be included in the next 20 1507 01:02:12,890 --> 01:02:13,700 minutes. 1508 01:02:13,700 --> 01:02:16,160 You don't get that assurance, right? 1509 01:02:16,160 --> 01:02:19,010 It can be 30 minutes before anything gets included. 1510 01:02:19,010 --> 01:02:20,690 And in fact, we'll get into it later, 1511 01:02:20,690 --> 01:02:23,030 but there's even worse assurance properties, 1512 01:02:23,030 --> 01:02:26,030 in that just because five blocks came out 1513 01:02:26,030 --> 01:02:29,615 doesn't mean your transaction got into any of them. 1514 01:02:29,615 --> 01:02:30,740 It might have been ignored. 1515 01:02:30,740 --> 01:02:32,850 It might-- there's all sorts of reasons. 1516 01:02:32,850 --> 01:02:35,060 So you can deal with this, but it is annoying, 1517 01:02:35,060 --> 01:02:36,740 and it precludes some use cases. 1518 01:02:36,740 --> 01:02:39,440 And other consensus systems do not have this problem. 1519 01:02:39,440 --> 01:02:42,980 Other consensus systems can have much more regular clocks. 1520 01:02:42,980 --> 01:02:45,850 So this is kind of annoying as well. 1521 01:02:45,850 --> 01:02:49,052 Any questions about the irregularity aspects? 1522 01:02:49,052 --> 01:02:51,770 OK. 1523 01:02:51,770 --> 01:02:55,590 OK, big con. 1524 01:02:55,590 --> 01:02:57,150 It's like 51% attacks. 1525 01:02:57,150 --> 01:02:57,660 OK. 1526 01:02:57,660 --> 01:03:01,200 Part of the problem with anonymity 1527 01:03:01,200 --> 01:03:06,050 is you have no idea who's doing this stuff, right? 1528 01:03:06,050 --> 01:03:09,110 Even if they say who-- even if they claim-- 1529 01:03:09,110 --> 01:03:12,680 so one of the interesting parts of anonymity, 1530 01:03:12,680 --> 01:03:16,840 despite this being designed as a really cool hacker-y, cyber 1531 01:03:16,840 --> 01:03:20,570 punk, anonymous system, one of the first things people 1532 01:03:20,570 --> 01:03:23,020 did was put their name in it, right? 1533 01:03:23,020 --> 01:03:25,520 So if you mine a block, you've got space 1534 01:03:25,520 --> 01:03:28,850 where you can put 32 bytes or so that are undefined, 1535 01:03:28,850 --> 01:03:31,550 and people would start putting the names of their mining pools 1536 01:03:31,550 --> 01:03:33,610 or the names of their cat or whatever. 1537 01:03:33,610 --> 01:03:35,373 They just put their names in it. 1538 01:03:35,373 --> 01:03:37,790 So it's kind of like they're showing who they are, and you 1539 01:03:37,790 --> 01:03:39,530 can look at distribution of who are 1540 01:03:39,530 --> 01:03:41,420 the different miners, and stuff like that, 1541 01:03:41,420 --> 01:03:44,060 even though it's supposed to be anonymous. 1542 01:03:44,060 --> 01:03:46,940 So they claim-- but they can claim a name, 1543 01:03:46,940 --> 01:03:49,550 and they can claim this block was mined by F2Pool, 1544 01:03:49,550 --> 01:03:52,610 or this block was mined by BTC.com, 1545 01:03:52,610 --> 01:03:54,320 you're not 100% sure, right? 1546 01:03:54,320 --> 01:03:56,090 It's all-- I could also mine a block 1547 01:03:56,090 --> 01:03:58,770 and claim that it's from F2Pool. 1548 01:03:58,770 --> 01:04:01,020 And it's hard to disprove. 1549 01:04:01,020 --> 01:04:03,010 So you don't really know who's mining, 1550 01:04:03,010 --> 01:04:07,490 and an attacker with 51% of the total network power 1551 01:04:07,490 --> 01:04:11,120 can write a chain faster than everyone else combined. 1552 01:04:11,120 --> 01:04:13,910 So that means they can rewrite history, right? 1553 01:04:13,910 --> 01:04:16,880 So like in the example before, where hey, I made this 1554 01:04:16,880 --> 01:04:20,600 three blocks longer than these two blocks, 1555 01:04:20,600 --> 01:04:25,880 I had to either get lucky or everyone else stopped mining 1556 01:04:25,880 --> 01:04:29,270 for a second, but that's not really possible, 1557 01:04:29,270 --> 01:04:33,500 long term, if I have a minority of the hash power, right? 1558 01:04:33,500 --> 01:04:35,830 Because everyone's just going to start-- 1559 01:04:35,830 --> 01:04:38,810 you know, if the majority is honest and playing 1560 01:04:38,810 --> 01:04:40,430 by the right rules, they're just going 1561 01:04:40,430 --> 01:04:42,260 to see what the most, the longest 1562 01:04:42,260 --> 01:04:44,290 worked-- the most worked, the longest chain 1563 01:04:44,290 --> 01:04:47,640 is, and start throwing blocks on top of that. 1564 01:04:47,640 --> 01:04:51,290 And if I go back and try to make a branch, 1565 01:04:51,290 --> 01:04:54,500 the main branch will grow faster than my sub branch, 1566 01:04:54,500 --> 01:04:57,260 and so I'll never overtake the main branch, 1567 01:04:57,260 --> 01:05:00,810 and so I'll never be able to reorg out a transaction. 1568 01:05:00,810 --> 01:05:04,820 However, if I am faster than everyone else put together, 1569 01:05:04,820 --> 01:05:07,190 it's assured that I will eventually 1570 01:05:07,190 --> 01:05:09,445 catch up and overtake the rest of the network, 1571 01:05:09,445 --> 01:05:11,570 and then everyone will have to reorg out onto mine. 1572 01:05:11,570 --> 01:05:15,710 So here's the main chain, and then I branch off here, 1573 01:05:15,710 --> 01:05:20,290 and I'm faster, so I overtake them and then, that's sort of-- 1574 01:05:20,290 --> 01:05:21,290 everyone's stuck, right? 1575 01:05:21,290 --> 01:05:24,170 Even if they want to keep mining, 1576 01:05:24,170 --> 01:05:28,270 I can just reorg them out every time, because I'm bigger. 1577 01:05:28,270 --> 01:05:30,910 This is called a 51% attack. 1578 01:05:30,910 --> 01:05:32,560 It's pretty bad. 1579 01:05:32,560 --> 01:05:37,360 An attacker can rewrite history, can undo transactions. 1580 01:05:37,360 --> 01:05:40,090 They can't forge transactions, right? 1581 01:05:40,090 --> 01:05:43,390 So they can't necessarily reorg out a message 1582 01:05:43,390 --> 01:05:46,120 and replace it with a message of their choosing. 1583 01:05:46,120 --> 01:05:48,775 All they can do is, you know, if they-- 1584 01:05:48,775 --> 01:05:50,650 but they can do that with their own messages. 1585 01:05:50,650 --> 01:05:55,420 So you need to have this as part of an attack 1586 01:05:55,420 --> 01:05:59,230 where they reorg their own messages out. 1587 01:05:59,230 --> 01:06:02,380 By default, when a reorg occurs, so like-- 1588 01:06:02,380 --> 01:06:05,360 I can-- go here. 1589 01:06:05,360 --> 01:06:08,390 So by default, when a reorg occurs, 1590 01:06:08,390 --> 01:06:14,000 like say, these two blocks of messages have been invalidated, 1591 01:06:14,000 --> 01:06:17,030 software will attempt to include all the transactions 1592 01:06:17,030 --> 01:06:20,120 in these blocks into the next blocks, right? 1593 01:06:20,120 --> 01:06:22,910 It's not-- just because this got reorged out, 1594 01:06:22,910 --> 01:06:24,080 doesn't mean it was invalid. 1595 01:06:24,080 --> 01:06:27,750 It just means it didn't get into a block. 1596 01:06:27,750 --> 01:06:30,620 And so we can try to include this message later, as 1597 01:06:30,620 --> 01:06:33,290 long as nothing in here conflicts with it. 1598 01:06:33,290 --> 01:06:38,090 So just doing a 51% attack to reorg on its own 1599 01:06:38,090 --> 01:06:39,830 doesn't actually do very much damage. 1600 01:06:39,830 --> 01:06:43,820 However, it's not too hard to combine that with other attacks 1601 01:06:43,820 --> 01:06:46,160 where whoever's doing this mining 1602 01:06:46,160 --> 01:06:50,330 says, oh, I'll pay someone here, and then pay myself here. 1603 01:06:50,330 --> 01:06:54,270 And then undo the payment that they made to someone. 1604 01:06:54,270 --> 01:06:56,210 So that's a big, big con. 1605 01:06:56,210 --> 01:06:57,780 51% attacks. 1606 01:06:57,780 --> 01:07:01,100 Not only is it very disruptive to the system, 1607 01:07:01,100 --> 01:07:03,380 it's very hard to predict when it will happen, 1608 01:07:03,380 --> 01:07:05,900 since it's anonymous. 1609 01:07:05,900 --> 01:07:09,320 It could be the case that all the people mining Bitcoin now 1610 01:07:09,320 --> 01:07:13,333 are friends and they're a 51% group, 1611 01:07:13,333 --> 01:07:15,500 and they could just get together and say, hey, let's 1612 01:07:15,500 --> 01:07:17,990 reorg out these things. 1613 01:07:17,990 --> 01:07:20,230 That said, there is a cost to do so. 1614 01:07:20,230 --> 01:07:20,900 Yeah? 1615 01:07:20,900 --> 01:07:23,440 AUDIENCE: There seems to be some requirement of momentum 1616 01:07:23,440 --> 01:07:27,170 of messages to not able to trick the system. 1617 01:07:27,170 --> 01:07:30,380 So if you're setting up a new currency, 1618 01:07:30,380 --> 01:07:34,970 it must be much, much easier to work the chain. 1619 01:07:34,970 --> 01:07:35,720 TADGE DRYJA: Yeah. 1620 01:07:35,720 --> 01:07:39,212 I mean, if there's very little work being done in the system, 1621 01:07:39,212 --> 01:07:41,420 it's probably pretty cheap to get a bunch of hardware 1622 01:07:41,420 --> 01:07:43,800 and be 51% of that system. 1623 01:07:43,800 --> 01:07:44,300 True. 1624 01:07:44,300 --> 01:07:46,730 So like-- and in the case of Bitcoin, 1625 01:07:46,730 --> 01:07:52,340 if you have to 2 the 72 work, well, every 10 minutes, 1626 01:07:52,340 --> 01:07:55,910 that means if I want to be 51%, I have to do 2 to the 71 work 1627 01:07:55,910 --> 01:07:57,290 every 10 minutes, which-- 1628 01:07:57,290 --> 01:07:58,310 that's a lot of work. 1629 01:07:58,310 --> 01:08:00,830 And so you're going to need enormous amounts of resources 1630 01:08:00,830 --> 01:08:03,830 to become a 51% attacker. 1631 01:08:03,830 --> 01:08:06,260 There's two ways this attack can happen. 1632 01:08:06,260 --> 01:08:09,363 Either some attacker comes out of nowhere 1633 01:08:09,363 --> 01:08:11,030 and says, OK, I'm just going to build up 1634 01:08:11,030 --> 01:08:13,610 an enormous amount of attack power, 1635 01:08:13,610 --> 01:08:16,430 or the existing actors in the system 1636 01:08:16,430 --> 01:08:19,250 go bad, which seems more likely, where they're like, 1637 01:08:19,250 --> 01:08:20,640 OK, we're already-- 1638 01:08:20,640 --> 01:08:21,800 you know, I'm 5%. 1639 01:08:21,800 --> 01:08:22,540 He's 10%. 1640 01:08:22,540 --> 01:08:23,569 And she's 20%. 1641 01:08:23,569 --> 01:08:26,210 And they all get together and try to do an attack. 1642 01:08:26,210 --> 01:08:28,840 So both of those different ways are possible. 1643 01:08:28,840 --> 01:08:29,979 Yes? 1644 01:08:29,979 --> 01:08:32,399 AUDIENCE: But [INAUDIBLE] mining downsides? 1645 01:08:32,399 --> 01:08:33,740 Like, we join some other pool? 1646 01:08:33,740 --> 01:08:34,490 TADGE DRYJA: Wait. 1647 01:08:34,490 --> 01:08:34,740 Wait. 1648 01:08:34,740 --> 01:08:35,120 Sorry. 1649 01:08:35,120 --> 01:08:35,649 Who does? 1650 01:08:35,649 --> 01:08:37,100 AUDIENCE: Like, small players. 1651 01:08:37,100 --> 01:08:37,880 TADGE DRYJA: Yes. 1652 01:08:37,880 --> 01:08:41,210 AUDIENCE: So like, [INAUDIBLE] of [INAUDIBLE].. 1653 01:08:41,210 --> 01:08:43,529 If the miner pool rollback-- like for example, 1654 01:08:43,529 --> 01:08:48,410 I'm in a miner [INAUDIBLE],, and the software is malicious, 1655 01:08:48,410 --> 01:08:51,120 so one of the players can roll back simultaneously? 1656 01:08:51,120 --> 01:08:51,870 TADGE DRYJA: Yeah. 1657 01:08:51,870 --> 01:08:55,670 So pools, we haven't mentioned pools, but the idea-- 1658 01:08:55,670 --> 01:08:59,840 part of the con of you're never going to find a valid proof 1659 01:08:59,840 --> 01:09:02,840 of work, is the way they mitigate that, 1660 01:09:02,840 --> 01:09:07,430 is people get together in pools and they will prove partial 1661 01:09:07,430 --> 01:09:11,689 work to each other, and there's one entity that's then-- 1662 01:09:11,689 --> 01:09:14,090 controls a lot of different miners 1663 01:09:14,090 --> 01:09:16,700 and gives out partial rewards. 1664 01:09:16,700 --> 01:09:20,330 So OK, there's a thousand different people mining, 1665 01:09:20,330 --> 01:09:24,585 and one of them found the block, but I'll distribute that reward 1666 01:09:24,585 --> 01:09:26,960 to all the thousand people for all the work they've done. 1667 01:09:26,960 --> 01:09:28,850 And so that does concentrate power 1668 01:09:28,850 --> 01:09:31,520 in that mining pool, whoever's running it. 1669 01:09:31,520 --> 01:09:34,340 So that can also be a big problem. 1670 01:09:34,340 --> 01:09:35,630 Yeah. 1671 01:09:35,630 --> 01:09:37,689 Because if you're doing it solo now. 1672 01:09:37,689 --> 01:09:40,430 So solo mining is saying, I'm just mining on my own. 1673 01:09:40,430 --> 01:09:43,069 I'm going to try to find a valid proof of work. 1674 01:09:43,069 --> 01:09:45,800 That's very difficult, because of the amount of work needed. 1675 01:09:45,800 --> 01:09:47,960 So many people pool together. 1676 01:09:47,960 --> 01:09:50,260 So yeah, that's another issue. 1677 01:09:50,260 --> 01:09:50,760 Yeah? 1678 01:09:50,760 --> 01:09:53,020 AUDIENCE: So [INAUDIBLE]. 1679 01:09:53,020 --> 01:09:53,770 TADGE DRYJA: Yeah. 1680 01:09:53,770 --> 01:09:56,720 There's also protocols, one called P2Pool, 1681 01:09:56,720 --> 01:10:00,680 where you can have another layer of block chain-y kind 1682 01:10:00,680 --> 01:10:05,120 of messages, which allows you to pool together resources 1683 01:10:05,120 --> 01:10:08,810 without having a single entity responsible for getting 1684 01:10:08,810 --> 01:10:11,520 the rewards and distributing them back up. 1685 01:10:11,520 --> 01:10:14,060 I mean, I haven't really talked about the rewards. 1686 01:10:14,060 --> 01:10:17,480 The Bitcoin-specific stuff will be in next week, probably. 1687 01:10:17,480 --> 01:10:18,500 But yeah. 1688 01:10:18,500 --> 01:10:19,640 There's all sorts of-- 1689 01:10:19,640 --> 01:10:21,290 this gets really complicated and crazy. 1690 01:10:21,290 --> 01:10:23,600 And like, pools, there's so many attacks on pools, 1691 01:10:23,600 --> 01:10:26,010 and it's a mess. 1692 01:10:26,010 --> 01:10:27,460 OK. 1693 01:10:27,460 --> 01:10:29,540 Last con. 1694 01:10:29,540 --> 01:10:30,890 People hate it. 1695 01:10:30,890 --> 01:10:34,730 And this is not a quantitative, objective reason, 1696 01:10:34,730 --> 01:10:37,100 but it is a problem. 1697 01:10:37,100 --> 01:10:40,760 And people don't like proof of work. 1698 01:10:40,760 --> 01:10:43,400 Some people are fine with it, but a lot of-- 1699 01:10:43,400 --> 01:10:44,880 especially in academia. 1700 01:10:44,880 --> 01:10:46,490 I've talked to a lot of people. 1701 01:10:46,490 --> 01:10:49,550 They're just like, ah, this this is horrible. 1702 01:10:49,550 --> 01:10:51,980 The whole point of sha256 is you can't find collisions, 1703 01:10:51,980 --> 01:10:55,130 and you've designed an entire system where all we're doing is 1704 01:10:55,130 --> 01:10:58,130 trying to find collisions in this non-collidable system, 1705 01:10:58,130 --> 01:11:01,190 and you've got giant warehouses full-- 1706 01:11:01,190 --> 01:11:02,900 uses so much electricity, and you've 1707 01:11:02,900 --> 01:11:05,850 got giant warehouses full of chips that are just 1708 01:11:05,850 --> 01:11:07,920 doing this pointless thing. 1709 01:11:07,920 --> 01:11:10,980 And it's-- you know, it offends the sensibilities of many 1710 01:11:10,980 --> 01:11:12,540 people. 1711 01:11:12,540 --> 01:11:14,250 And it probably is getting worse, 1712 01:11:14,250 --> 01:11:18,150 because it keeps getting bigger, and so a lot of people 1713 01:11:18,150 --> 01:11:18,870 don't like it. 1714 01:11:18,870 --> 01:11:21,000 And I can understand that. 1715 01:11:21,000 --> 01:11:22,710 When I first read about this stuff, 1716 01:11:22,710 --> 01:11:24,600 I was like, that's kind of cool. 1717 01:11:24,600 --> 01:11:25,590 That's kind of stupid. 1718 01:11:25,590 --> 01:11:28,830 And then I was like, oh, man what if this really takes off? 1719 01:11:28,830 --> 01:11:31,950 There's just going to be so much power usage and so many chips 1720 01:11:31,950 --> 01:11:36,180 dedicated to kind of a pointless thing. 1721 01:11:36,180 --> 01:11:40,110 I would say that I acknowledge this as a big problem, 1722 01:11:40,110 --> 01:11:43,860 and I think the best analogy is something like gold or silver, 1723 01:11:43,860 --> 01:11:46,680 precious metal mining where you could 1724 01:11:46,680 --> 01:11:50,580 make very similar arguments, that all these you know 1725 01:11:50,580 --> 01:11:53,340 Spanish or Portuguese people sailed over 1726 01:11:53,340 --> 01:11:56,280 to South America 500 years ago, and it 1727 01:11:56,280 --> 01:11:59,070 was sort of-- it was horrible and all these people were 1728 01:11:59,070 --> 01:12:01,170 working in these mines, and it's a mess, 1729 01:12:01,170 --> 01:12:04,510 just to get silver or gold or whatever. 1730 01:12:04,510 --> 01:12:06,100 And it's like, why? 1731 01:12:06,100 --> 01:12:07,350 Why are you doing this, right? 1732 01:12:07,350 --> 01:12:09,390 Just to get some gold? 1733 01:12:09,390 --> 01:12:15,410 So similarly, the bitcoin and the proof of work in general 1734 01:12:15,410 --> 01:12:17,550 has a lot of people who don't like it. 1735 01:12:17,550 --> 01:12:19,830 And so that's why there's a lot of research in, OK, 1736 01:12:19,830 --> 01:12:23,510 can we have the same kind of system, but without the work? 1737 01:12:23,510 --> 01:12:26,690 Or alternatively, can we have some kind of proof of work 1738 01:12:26,690 --> 01:12:30,412 that's also useful for other things? 1739 01:12:30,412 --> 01:12:32,120 So can we have some kind of proof of work 1740 01:12:32,120 --> 01:12:33,340 that cures cancer? 1741 01:12:33,340 --> 01:12:36,290 And it's like, well, I mean-- there's actually, right, 1742 01:12:36,290 --> 01:12:38,630 papers about protein folding proof of work. 1743 01:12:38,630 --> 01:12:42,560 And I haven't seen a ton-- there's 1744 01:12:42,560 --> 01:12:45,740 one where you like find sequences of prime numbers, 1745 01:12:45,740 --> 01:12:46,760 and it sort of worked. 1746 01:12:46,760 --> 01:12:48,790 It sort of has most of the properties you want. 1747 01:12:48,790 --> 01:12:51,227 And it's like, OK, but it's like, well. 1748 01:12:51,227 --> 01:12:52,810 You found five prime numbers in a row. 1749 01:12:52,810 --> 01:12:54,060 Like, eh. 1750 01:12:54,060 --> 01:12:54,670 Yeah? 1751 01:12:54,670 --> 01:12:56,490 AUDIENCE: The fundamental problem with those [INAUDIBLE] 1752 01:12:56,490 --> 01:12:58,115 that's different from this is generally 1753 01:12:58,115 --> 01:13:01,325 the same amount of time to verify as they do to generate, 1754 01:13:01,325 --> 01:13:04,197 whereas the advantage of this is it takes ages to generate, 1755 01:13:04,197 --> 01:13:05,530 but it's really quick to verify. 1756 01:13:05,530 --> 01:13:06,280 TADGE DRYJA: Yeah. 1757 01:13:06,280 --> 01:13:07,370 So that's another-- yeah. 1758 01:13:07,370 --> 01:13:08,810 People want useful proof work. 1759 01:13:08,810 --> 01:13:11,120 A lot of times with useful proofs of work, 1760 01:13:11,120 --> 01:13:15,200 it's hard to tell that it's a valid proof, 1761 01:13:15,200 --> 01:13:16,940 or there's not as much of a gap. 1762 01:13:16,940 --> 01:13:19,750 Like, the gap in Bitcoin is enormous, right? 1763 01:13:19,750 --> 01:13:23,240 O of n takes O of 1 to verify, which is perfect. 1764 01:13:25,830 --> 01:13:27,820 Yeah, you can't get better than that. 1765 01:13:27,820 --> 01:13:29,040 So yeah, it's hard to verify. 1766 01:13:29,040 --> 01:13:32,940 There's also-- that also applies to many different proofs 1767 01:13:32,940 --> 01:13:33,990 of work. 1768 01:13:33,990 --> 01:13:36,282 So one of the things with 51% attacks 1769 01:13:36,282 --> 01:13:37,740 is if, like you were saying, if you 1770 01:13:37,740 --> 01:13:41,610 want to build your own coin, if you use the same proof of work 1771 01:13:41,610 --> 01:13:45,420 algorithm as Bitcoin, you are in a very risky situation, 1772 01:13:45,420 --> 01:13:48,030 because you've started your own new coin that-- 1773 01:13:48,030 --> 01:13:52,080 your own new message network that very few people are using, 1774 01:13:52,080 --> 01:13:55,680 and there's very little work being done in this network. 1775 01:13:55,680 --> 01:13:58,158 And then there's this huge Bitcoin network. 1776 01:13:58,158 --> 01:13:59,700 And as soon as they see your network, 1777 01:13:59,700 --> 01:14:02,770 they could easily overpower it, right? 1778 01:14:02,770 --> 01:14:05,280 One actor, one person who's mining, 1779 01:14:05,280 --> 01:14:08,370 could become more than 51% of your network, just 1780 01:14:08,370 --> 01:14:09,240 with the flip of a-- 1781 01:14:09,240 --> 01:14:10,320 pressing of a button. 1782 01:14:10,320 --> 01:14:12,300 And so it's very dangerous to be running 1783 01:14:12,300 --> 01:14:14,910 a very small network that shares a proof of work 1784 01:14:14,910 --> 01:14:16,710 with the larger network. 1785 01:14:16,710 --> 01:14:19,770 And so most of the different coins, when people say, hey, 1786 01:14:19,770 --> 01:14:22,860 I'm going to make my own derivative of Bitcoin 1787 01:14:22,860 --> 01:14:25,800 or my own new coin, I'm going to have a different proof of work. 1788 01:14:25,800 --> 01:14:28,080 And so there's all sorts of different hash. 1789 01:14:28,080 --> 01:14:30,480 Maybe I'll use sha3 instead of sha256. 1790 01:14:30,480 --> 01:14:31,050 OK. 1791 01:14:31,050 --> 01:14:36,900 Or I'll use some other hash function, or some other usually 1792 01:14:36,900 --> 01:14:39,690 iterative hash function, like for password hashing, 1793 01:14:39,690 --> 01:14:43,130 where you actually end up hashing several million times. 1794 01:14:43,130 --> 01:14:44,880 And the disadvantage there, as well, is it 1795 01:14:44,880 --> 01:14:48,810 can take quite a while to verify the work. 1796 01:14:48,810 --> 01:14:51,690 Not too much, but noticeable, where 1797 01:14:51,690 --> 01:14:54,210 if you're running different clients like Lightcoin, 1798 01:14:54,210 --> 01:14:56,190 for example, it uses a proof of work 1799 01:14:56,190 --> 01:14:59,820 which takes thousands of times longer to verify. 1800 01:14:59,820 --> 01:15:03,830 Still fast enough, but some of them are pretty heavy. 1801 01:15:03,830 --> 01:15:07,260 So those are all the different-- you know, it gets pretty messy, 1802 01:15:07,260 --> 01:15:08,160 and I'm-- 1803 01:15:08,160 --> 01:15:10,290 ask-- probably James and some other people 1804 01:15:10,290 --> 01:15:14,290 are much more familiar with all the horrible intricacies 1805 01:15:14,290 --> 01:15:15,010 of proof of work. 1806 01:15:18,232 --> 01:15:19,954 AUDIENCE: [INAUDIBLE] if you back 1807 01:15:19,954 --> 01:15:22,420 to the part about [INAUDIBLE],, like back when 1808 01:15:22,420 --> 01:15:25,380 Bitcoin was first made, it just spawned the longest chain, 1809 01:15:25,380 --> 01:15:26,588 by absolute number or blocks. 1810 01:15:26,588 --> 01:15:27,505 TADGE DRYJA: Oh, yeah. 1811 01:15:27,505 --> 01:15:28,110 Well, yeah. 1812 01:15:28,110 --> 01:15:30,090 AUDIENCE: [INAUDIBLE] 1813 01:15:30,090 --> 01:15:30,840 TADGE DRYJA: Yeah. 1814 01:15:30,840 --> 01:15:33,870 So there's one-- wait. 1815 01:15:33,870 --> 01:15:35,220 So I said the longest-- 1816 01:15:35,220 --> 01:15:37,410 so if you say the longest chain is the valid one, 1817 01:15:37,410 --> 01:15:40,830 I think I mostly said most work, right? 1818 01:15:40,830 --> 01:15:42,630 They're not necessarily the same, right? 1819 01:15:42,630 --> 01:15:45,690 In this case, where we have a fixed target, a fixed 1820 01:15:45,690 --> 01:15:48,640 amount of work per block, they are the same. 1821 01:15:48,640 --> 01:15:50,890 But in the case of Bitcoin and most of these networks, 1822 01:15:50,890 --> 01:15:53,550 the target and the amount of work required for a block 1823 01:15:53,550 --> 01:15:57,990 can change with that 2016 period. 1824 01:15:57,990 --> 01:16:00,133 And so there are attacks where you can say, 1825 01:16:00,133 --> 01:16:01,800 well, I'm going to make something that's 1826 01:16:01,800 --> 01:16:05,130 longer, but actually has less work, 1827 01:16:05,130 --> 01:16:07,740 because I've forged all these-- 1828 01:16:07,740 --> 01:16:09,150 You know, I go back in time. 1829 01:16:09,150 --> 01:16:11,460 I pretend it took me a long time, 1830 01:16:11,460 --> 01:16:13,500 and I changed the timestamps so it 1831 01:16:13,500 --> 01:16:17,190 looks like it took a long time and the difficulty decreased, 1832 01:16:17,190 --> 01:16:20,287 but I actually have more blocks, but less total work. 1833 01:16:20,287 --> 01:16:21,870 And then I can have some weird attacks 1834 01:16:21,870 --> 01:16:23,850 where I reorg out things. 1835 01:16:23,850 --> 01:16:27,090 So in the case of Bitcoin, I think-- yeah. 1836 01:16:27,090 --> 01:16:27,642 Pretty early. 1837 01:16:27,642 --> 01:16:29,100 AUDIENCE: Like, version one point-- 1838 01:16:29,100 --> 01:16:30,433 TADGE DRYJA: Version one point-- 1839 01:16:30,433 --> 01:16:32,100 Version 0.1, it actually just looked 1840 01:16:32,100 --> 01:16:34,470 at number of blocks, because it's so much easier 1841 01:16:34,470 --> 01:16:37,200 in the code to just do number of blocks. 1842 01:16:37,200 --> 01:16:40,100 Otherwise, you have to treat all the hashes as big ints 1843 01:16:40,100 --> 01:16:41,850 and figure out how much work was done 1844 01:16:41,850 --> 01:16:44,040 on each one, and this annoying stuff. 1845 01:16:44,040 --> 01:16:46,585 But that attack was thought of. 1846 01:16:46,585 --> 01:16:48,210 I don't think the attack ever happened, 1847 01:16:48,210 --> 01:16:50,760 but whoever designed it was like, oh, wait. 1848 01:16:50,760 --> 01:16:51,420 Yeah. 1849 01:16:51,420 --> 01:16:52,620 Longest is not quite right. 1850 01:16:52,620 --> 01:16:53,520 Has to be most work. 1851 01:16:53,520 --> 01:16:54,960 And so they changed the code. 1852 01:16:57,460 --> 01:16:57,960 OK. 1853 01:16:57,960 --> 01:16:58,780 So proof of work. 1854 01:16:58,780 --> 01:16:59,405 People hate it. 1855 01:16:59,405 --> 01:17:02,860 Yeah, but the thing is, it does work. 1856 01:17:02,860 --> 01:17:04,500 It's been working for nine years. 1857 01:17:04,500 --> 01:17:06,120 The blocks keep on coming. 1858 01:17:06,120 --> 01:17:09,440 Not regularly, but over the course of a day, 1859 01:17:09,440 --> 01:17:12,210 about 144 will come out. 1860 01:17:12,210 --> 01:17:15,390 In practice, it's infeasible to write old messages, right? 1861 01:17:15,390 --> 01:17:18,300 There are all these known attacks, 1862 01:17:18,300 --> 01:17:21,708 but they're very costly, and either you 1863 01:17:21,708 --> 01:17:23,250 have to do an enormous amount of work 1864 01:17:23,250 --> 01:17:24,708 and get all these resources, or you 1865 01:17:24,708 --> 01:17:28,440 have to have a lot of collusion between the different actors. 1866 01:17:28,440 --> 01:17:31,140 One nice part is that in these systems, 1867 01:17:31,140 --> 01:17:34,600 people are very adversarial, and so they don't want to collude, 1868 01:17:34,600 --> 01:17:37,560 and they always are attacking each other and hate each other. 1869 01:17:37,560 --> 01:17:40,590 So that keeps the system working. 1870 01:17:40,590 --> 01:17:44,580 In practice, with Bitcoin, there are very few block reorgs. 1871 01:17:44,580 --> 01:17:47,390 This happens-- I don't know. 1872 01:17:47,390 --> 01:17:50,660 When's the last time an actual reorg happened, instead 1873 01:17:50,660 --> 01:17:51,770 of just two? 1874 01:17:51,770 --> 01:17:52,970 Like, years. 1875 01:17:52,970 --> 01:17:55,250 This just never happens. 1876 01:17:55,250 --> 01:17:56,570 Most, one or two blocks. 1877 01:17:56,570 --> 01:17:59,600 So you can have a one block where two blocks come out 1878 01:17:59,600 --> 01:18:02,190 at the same time and point to the same parent, 1879 01:18:02,190 --> 01:18:03,440 but that's not a reorg, right? 1880 01:18:03,440 --> 01:18:04,520 Because then your software sees it, 1881 01:18:04,520 --> 01:18:06,590 and it's like, well, which is going to be right? 1882 01:18:06,590 --> 01:18:08,930 And then one of them pulls ahead. 1883 01:18:08,930 --> 01:18:11,180 So that happens every couple days. 1884 01:18:11,180 --> 01:18:14,900 It used to be more frequently, but now it's fairly infrequent. 1885 01:18:14,900 --> 01:18:17,340 And like, two blocks reorg sometimes. 1886 01:18:17,340 --> 01:18:20,990 It has happened, but it's very rare now. 1887 01:18:20,990 --> 01:18:23,040 So you can build on these things. 1888 01:18:23,040 --> 01:18:24,970 OK I'm almost done. 1889 01:18:24,970 --> 01:18:28,260 We'll do one last fun fact, and then questions. 1890 01:18:28,260 --> 01:18:29,690 OK, so fun facts. 1891 01:18:29,690 --> 01:18:33,170 How to estimate the total work done throughout history 1892 01:18:33,170 --> 01:18:34,790 of the network. 1893 01:18:34,790 --> 01:18:36,860 Well, you just look at the lowest hash. 1894 01:18:36,860 --> 01:18:39,230 This is kind of counter-intuitive, like whoa, 1895 01:18:39,230 --> 01:18:40,880 kind of thing. 1896 01:18:40,880 --> 01:18:43,160 You can prove all the work ever done 1897 01:18:43,160 --> 01:18:47,660 in the history of the system with just one hash, the lowest. 1898 01:18:47,660 --> 01:18:49,760 Because probabilistically, well, I've 1899 01:18:49,760 --> 01:18:52,040 been doing work the whole time. 1900 01:18:52,040 --> 01:18:53,990 Probabilistically, I guess the way 1901 01:18:53,990 --> 01:18:56,900 this works is that whether we were all 1902 01:18:56,900 --> 01:18:59,960 trying for the same block or whether we're 1903 01:18:59,960 --> 01:19:01,970 trying for all these different blocks, 1904 01:19:01,970 --> 01:19:03,260 it doesn't matter, right? 1905 01:19:03,260 --> 01:19:05,180 We're still doing attempts. 1906 01:19:05,180 --> 01:19:08,720 And the best attempts will have the most zeros in front of it. 1907 01:19:08,720 --> 01:19:12,080 And that holds true for whatever configuration, 1908 01:19:12,080 --> 01:19:13,880 graph configuration, whether there's forks, 1909 01:19:13,880 --> 01:19:16,790 whether there's a single chain, whether we all just work 1910 01:19:16,790 --> 01:19:19,220 on the same thing and never make any progress 1911 01:19:19,220 --> 01:19:20,570 and just admit the best hash. 1912 01:19:20,570 --> 01:19:21,600 So that's kind of cool. 1913 01:19:21,600 --> 01:19:23,300 You can just look at a single hash 1914 01:19:23,300 --> 01:19:26,660 and see all the work that's ever been done in the system. 1915 01:19:26,660 --> 01:19:28,850 Kind of cool. 1916 01:19:28,850 --> 01:19:31,760 With pretty crummy accuracy, of course, 1917 01:19:31,760 --> 01:19:34,040 but actually not too bad. 1918 01:19:34,040 --> 01:19:36,230 And so there's a paper that's pretty interesting. 1919 01:19:36,230 --> 01:19:38,855 If you're interested in it this and want to look into the math, 1920 01:19:38,855 --> 01:19:40,970 there's a paper called HyperLogLog 1921 01:19:40,970 --> 01:19:44,630 that uses this fact for something completely different, 1922 01:19:44,630 --> 01:19:47,420 to count set cardinalities and stuff, 1923 01:19:47,420 --> 01:19:50,010 and it's kind of a cool math paper. 1924 01:19:50,010 --> 01:19:52,940 But I think the Bitcoin software does do that, 1925 01:19:52,940 --> 01:19:54,972 and it'll say best hash. 1926 01:19:54,972 --> 01:19:56,930 And it's in there, and you can say, like, well, 1927 01:19:56,930 --> 01:19:58,710 this is how much work we all have done. 1928 01:19:58,710 --> 01:20:01,250 There's also some papers in Bitcoin 1929 01:20:01,250 --> 01:20:03,140 where you can try to use these facts, 1930 01:20:03,140 --> 01:20:05,150 like the lucky blocks that happen 1931 01:20:05,150 --> 01:20:07,610 to have much more work than they needed, 1932 01:20:07,610 --> 01:20:09,860 and you can look back through history 1933 01:20:09,860 --> 01:20:12,800 and give an abridged version of history that 1934 01:20:12,800 --> 01:20:15,440 still took as much-- that would still take about as 1935 01:20:15,440 --> 01:20:18,200 much work to rewrite, without providing 1936 01:20:18,200 --> 01:20:23,110 all of the different blocks and stuff. 1937 01:20:23,110 --> 01:20:24,520 You can also prove close calls. 1938 01:20:24,520 --> 01:20:28,480 So with pools and mining, one way you can do it is you 1939 01:20:28,480 --> 01:20:32,320 can prove that you were trying but didn't quite make it. 1940 01:20:32,320 --> 01:20:36,820 So if the requirement is you need 2 to the 40 leading zeros, 1941 01:20:36,820 --> 01:20:39,080 and you get 2 to the 39, you can show. 1942 01:20:39,080 --> 01:20:39,580 Like, hey. 1943 01:20:39,580 --> 01:20:44,140 I got 2 to the 39 and I didn't quite make it, but I tried. 1944 01:20:44,140 --> 01:20:46,720 And then people can verify that work as well, 1945 01:20:46,720 --> 01:20:48,760 and credit you for it. 1946 01:20:48,760 --> 01:20:50,410 So the way a mining pool works will 1947 01:20:50,410 --> 01:20:53,020 be you give what's called shares, which 1948 01:20:53,020 --> 01:20:57,100 is like close calls that were not sufficient to meet 1949 01:20:57,100 --> 01:21:01,180 the proof of work, but you keep giving them every few seconds, 1950 01:21:01,180 --> 01:21:02,380 or every few minutes. 1951 01:21:02,380 --> 01:21:04,300 And then the central pool operator 1952 01:21:04,300 --> 01:21:06,520 says, OK, well, this person did this many shares. 1953 01:21:06,520 --> 01:21:07,980 This person did this many shares. 1954 01:21:07,980 --> 01:21:11,110 I have-- the central operator has a very good estimation 1955 01:21:11,110 --> 01:21:13,570 of how much work different people are doing, 1956 01:21:13,570 --> 01:21:14,650 and so credits them. 1957 01:21:14,650 --> 01:21:16,970 And said, OK, well, he's doing this much work. 1958 01:21:16,970 --> 01:21:18,520 She's doing this much work. 1959 01:21:18,520 --> 01:21:21,010 And then when someone actually finds the block, 1960 01:21:21,010 --> 01:21:23,830 distributes the rewards from the block proportionately 1961 01:21:23,830 --> 01:21:26,540 to how much work everyone's been doing. 1962 01:21:26,540 --> 01:21:29,420 So that's trusted, and not great. 1963 01:21:29,420 --> 01:21:31,550 And there's also a bunch of attacks. 1964 01:21:31,550 --> 01:21:36,200 The sort of sneakiest of which is keep submitting 1965 01:21:36,200 --> 01:21:38,000 shares, submitting close calls. 1966 01:21:38,000 --> 01:21:40,520 But when you actually do find a valid proof work, 1967 01:21:40,520 --> 01:21:41,840 immediately forget about it. 1968 01:21:41,840 --> 01:21:44,600 Drop it, and never tell anyone. 1969 01:21:44,600 --> 01:21:48,560 The reason that's a good attack is fairly counter-intuitive, 1970 01:21:48,560 --> 01:21:51,260 but it's a good attack, even though it seems like, well, you 1971 01:21:51,260 --> 01:21:52,700 just found the block. 1972 01:21:52,700 --> 01:21:53,300 Tell everyone. 1973 01:21:53,300 --> 01:21:54,830 You get this reward. 1974 01:21:54,830 --> 01:21:55,880 You get-- 1975 01:21:55,880 --> 01:21:56,470 It's like no. 1976 01:21:56,470 --> 01:21:57,303 No, I found a block. 1977 01:21:57,303 --> 01:21:58,100 Throw it away. 1978 01:21:58,100 --> 01:21:59,390 But oh, I got a close call. 1979 01:21:59,390 --> 01:22:01,280 OK, keep telling the central operator. 1980 01:22:01,280 --> 01:22:03,020 What that does is that really screws 1981 01:22:03,020 --> 01:22:05,450 over the central operator, who now thinks you're 1982 01:22:05,450 --> 01:22:09,140 doing a lot of work, but you never find an actual block. 1983 01:22:09,140 --> 01:22:11,240 And eventually, the central operator will be like, 1984 01:22:11,240 --> 01:22:13,190 this person is really unlucky, huh? 1985 01:22:13,190 --> 01:22:16,400 He's found so many close calls, but never 1986 01:22:16,400 --> 01:22:18,560 seems to actually get over the line 1987 01:22:18,560 --> 01:22:20,382 and find a valid proof work. 1988 01:22:20,382 --> 01:22:22,340 And so maybe they can kick you off, eventually, 1989 01:22:22,340 --> 01:22:24,220 but it's not something you can prove. 1990 01:22:24,220 --> 01:22:27,360 You're like, well, I got unlucky. 1991 01:22:27,360 --> 01:22:29,040 So there's all sorts of things. 1992 01:22:29,040 --> 01:22:30,498 There's all sorts of fun things you 1993 01:22:30,498 --> 01:22:34,360 can do with the proof of work and just these hash functions.