1 00:00:01,270 --> 00:00:05,600 The following content is provided under a Creative Commons license. Your support will 2 00:00:05,600 --> 00:00:11,200 help MIT Open CourseWare continue to offer high-quality educational resources for free. 3 00:00:11,200 --> 00:00:17,260 To make a donation or to view additional materials from hundreds of MIT courses, visit MIT Open 4 00:00:17,260 --> 00:00:20,570 CourseWare at ocw.mit.edu. 5 00:00:20,570 --> 00:00:29,110 I'm going to talk about alternate consensus mechanisms. And there's a bunch of them. And 6 00:00:29,110 --> 00:00:32,689 some of them are variants on proof of work. Some of them are proof of stake-- all these 7 00:00:32,689 --> 00:00:34,390 different things. 8 00:00:34,390 --> 00:00:39,720 So unique node lists-- this is something that Ripple and Stellar use. I'm not sure if there's 9 00:00:39,720 --> 00:00:46,511 others. Proof of stake is this huge research topic that lots of things fall under. There's 10 00:00:46,511 --> 00:00:51,130 lots of variance. One of them I'll talk about is delegated proof of stake. 11 00:00:51,130 --> 00:00:57,000 Proof of space is an interesting thing that is basically a form of proof of work that 12 00:00:57,000 --> 00:01:05,239 doesn't use CPU as much. There's the idea of directed acyclic graphs, which IOTA is 13 00:01:05,239 --> 00:01:11,920 a great example of. And then one that I came up with a few years ago and is kind of fun-- 14 00:01:11,920 --> 00:01:18,590 proof of idol, which is sort of silly but some of these others are silly, too. 15 00:01:18,590 --> 00:01:27,869 OK. And so disclaimer-- I'm OK with proof of work. So I think if you were at the class 16 00:01:27,869 --> 00:01:34,319 on Monday, it's a great segue into this, where, clearly, proof of work has, I don't know if 17 00:01:34,319 --> 00:01:39,469 you want to call it problems, but it's kind of crazy, right, all the stuff David was saying 18 00:01:39,469 --> 00:01:46,560 on Monday. It's not an egalitarian-- and I think in the Satoshi White Paper, he says 19 00:01:46,560 --> 00:01:48,158 one CPU, one vote. 20 00:01:48,158 --> 00:01:56,251 Well, that's not really how it works. Define CPU. Maybe you have your own CPU. Someone 21 00:01:56,251 --> 00:02:03,210 else has a different view. And there's that huge industry of building all these chips. 22 00:02:03,210 --> 00:02:07,139 So there's a lot of issues with proof of work. It's certainly not ideal. 23 00:02:07,139 --> 00:02:12,810 That's probably not why most people don't like it. So I, generally, in academia, in 24 00:02:12,810 --> 00:02:18,950 a lot of business places, people don't like the Bitcoin proof of work mechanism-- not 25 00:02:18,950 --> 00:02:24,280 everyone, but it's a pretty widespread. Oh, Bitcoin is bad because it uses as much electricity 26 00:02:24,280 --> 00:02:27,650 as Denmark or something. 27 00:02:27,650 --> 00:02:34,071 And I think that's a sort of early, I don't like it because it uses electricity. There's 28 00:02:34,071 --> 00:02:37,810 other reasons not to like it, which I think you have to go into much more depth. Like 29 00:02:37,810 --> 00:02:41,920 with David's talk yesterday, sure, it uses a lot of electricity. But it also uses a lot 30 00:02:41,920 --> 00:02:49,810 of fabrication plants, and it uses all these other distribution networks. So anyway, I 31 00:02:49,810 --> 00:02:54,300 get that there's a lot of-- one of the first things with Bitcoin is, OK, how can we improve 32 00:02:54,300 --> 00:02:59,430 upon this? How can we get rid of this huge energy sink? 33 00:02:59,430 --> 00:03:05,250 On the other hand, I'm sort of OK with it, right? The first thing that I thought with 34 00:03:05,250 --> 00:03:08,040 Bitcoin is, wow, this is going to be huge. This is going to take a lot of electricity. 35 00:03:08,040 --> 00:03:10,440 But it's kind of cool that it works that way. 36 00:03:10,440 --> 00:03:16,630 So I'm sort of OK with people-- to me, you can't really get mad at people doing things 37 00:03:16,630 --> 00:03:22,360 you think are stupid because you'll just get mad all the time. People mine gold. People 38 00:03:22,360 --> 00:03:27,270 spend billions of dollars on diamonds. I think diamonds are really stupid. But hey, if you 39 00:03:27,270 --> 00:03:34,170 want to dig up diamonds, oh, whatever. Yeah. There's entire cultural areas that I just 40 00:03:34,170 --> 00:03:36,260 have no interest in. But hey. 41 00:03:36,260 --> 00:03:42,060 OK. So I'll try to explain these other methods in a neutral way. But I do have my own biases, 42 00:03:42,060 --> 00:03:46,290 where I think like, hey, proof of work pretty much works. I think it's a cool system. And 43 00:03:46,290 --> 00:03:52,930 I'm somewhat skeptical of various different algorithms and mechanisms here. 44 00:03:52,930 --> 00:03:57,930 And also, I'm most familiar with the proof of work system and all the intricacies of 45 00:03:57,930 --> 00:04:02,000 it. So like with David's talk yesterday, there was some new stuff, but I sort of knew because 46 00:04:02,000 --> 00:04:05,790 I've talked to these people for a long time, and this is how this system works. 47 00:04:05,790 --> 00:04:11,950 Proof of stake-- I've seen it implemented in altcoins. But I haven't followed them that 48 00:04:11,950 --> 00:04:17,649 closely. So I don't know as intimately what goes wrong and all the weird details. Anyway. 49 00:04:17,649 --> 00:04:24,490 OK. So the first one, UNL, or unique node list. This is, essentially, the consensus 50 00:04:24,490 --> 00:04:34,919 mechanism used by Ripple and Stellar. For history, Ripple started in 2013? No, 2011. 51 00:04:34,919 --> 00:04:36,740 I don't know. It was a while ago. 52 00:04:36,740 --> 00:04:40,669 AUDIENCE: [? Dennis ?] says [INAUDIBLE] January 1, 2013. 53 00:04:40,669 --> 00:04:46,919 TADGE DRYJA: 2013, OK. So actually, the name Ripple and the idea of these debt obligations 54 00:04:46,919 --> 00:04:53,930 through this network actually predates Bitcoin. And then Jed McCaleb started the company. 55 00:04:53,930 --> 00:05:02,439 He's also the guy who started Mt. Gox. So he started Mt. Gox, I believe, in 2011 or 56 00:05:02,439 --> 00:05:10,741 '10-- late 2010, sold it to the Mark Karpelés, started Ripple, hired a bunch of people, sort 57 00:05:10,741 --> 00:05:12,689 of got fired from Ripple. 58 00:05:12,689 --> 00:05:18,389 There's a lot of bad-- everyone fighting. Because it was all these people who used to 59 00:05:18,389 --> 00:05:25,300 play Magic-- the Gathering and were friends. And now they're not friends anymore. And then, 60 00:05:25,300 --> 00:05:28,629 he started Stellar, which he called "Secret Bitcoin Project." 61 00:05:28,629 --> 00:05:34,990 And I was thinking of joining it, but he wouldn't tell me what it was. And also, I knew that 62 00:05:34,990 --> 00:05:39,849 other people knew what it was, like my friends, and if they weren't telling me because they're 63 00:05:39,849 --> 00:05:43,979 not supposed to, it was like, well, it must not be that cool. Because nobody can actually 64 00:05:43,979 --> 00:05:47,050 keep a secret if it's really cool. 65 00:05:47,050 --> 00:05:48,960 [LAUGHING] 66 00:05:48,960 --> 00:05:55,069 So that was my, mm, I'll just go work somewhere else. And Stellar was, more or less, a copy 67 00:05:55,069 --> 00:05:58,810 of the Ripple code, which was open source, so it was totally fine to do this. And then 68 00:05:58,810 --> 00:06:08,249 it diverged, and they added their own different parts of the consensus algorithm 69 00:06:08,249 --> 00:06:10,330 than Ripple did. 70 00:06:10,330 --> 00:06:17,520 So it's account-based, somewhat like Ethereum. Transactions have senders, receivers. What's 71 00:06:17,520 --> 00:06:20,270 interesting is in the Stellar case, and possibly Ripple, there's a minimum balance. So I actually 72 00:06:20,270 --> 00:06:25,960 had some Stellar last year, or up until last year, because I went to the initial release 73 00:06:25,960 --> 00:06:31,620 party, and they gave out Stellar. And I had some. 74 00:06:31,620 --> 00:06:37,370 And then, it wasn't much. But then, last year, I looked, and it was like, oh, this is like 75 00:06:37,370 --> 00:06:42,860 $200 worth. I'll sell it. And I sold it and got some bitcoins. But it was weird because 76 00:06:42,860 --> 00:06:50,610 they enforced a minimum balance, which seems weird to me. Because you had to retain some 77 00:06:50,610 --> 00:06:56,080 number of stellar units in every account, which, to me, seems sort of weird. 78 00:06:56,080 --> 00:07:02,469 Because that means those stellars, they're gone, in a way, in that if you open a new 79 00:07:02,469 --> 00:07:11,210 account and it must have 50 stellar in it forever. Well, so Stellar effectively destroyed, 80 00:07:11,210 --> 00:07:15,960 it just seemed-- which is a fine thing to do. It's sort of a transaction fee. But from 81 00:07:15,960 --> 00:07:20,629 a computer science database standpoint, it's like, why not just have it cost money to create 82 00:07:20,629 --> 00:07:28,729 a new account instead of have a minimum balance? So just interacting with it, it was like, 83 00:07:28,729 --> 00:07:29,729 huh. 84 00:07:29,729 --> 00:07:33,789 So there's no work. But the idea is that nodes sign transactions that they've seen. Everyone 85 00:07:33,789 --> 00:07:38,419 makes blocks. And you sign them, so you've got some kind of identity. Your node has a 86 00:07:38,419 --> 00:07:43,759 key. When you start a new node, you've got a public key/private key pair. You can sign 87 00:07:43,759 --> 00:07:46,229 off on transactions. 88 00:07:46,229 --> 00:07:51,169 This is not the case in Bitcoin, right? In Bitcoin, you have a full node. Your full node 89 00:07:51,169 --> 00:07:55,580 might have a wallet associated with it with public keys and private keys, but the node 90 00:07:55,580 --> 00:08:03,259 itself does not. Possibly in the future, there's BIP 150, I believe, which the idea is to have 91 00:08:03,259 --> 00:08:09,289 encrypted communications between nodes, which would have some kind of authentication. 92 00:08:09,289 --> 00:08:15,789 There's BIP and BIP 151. I might have them backwards. 151, I believe, is just encryption, 93 00:08:15,789 --> 00:08:22,160 so for privacy, confidentiality. And then, BIT 150 is for authenticity. So you connect 94 00:08:22,160 --> 00:08:25,419 to a node. You're like, oh, this is the same node at the same IP address that I connected 95 00:08:25,419 --> 00:08:31,059 to before. They're not implemented yet that I'm aware of. 96 00:08:31,059 --> 00:08:34,830 So right now, in Bitcoin, when you connect to people, you just use their IP address. 97 00:08:34,830 --> 00:08:40,150 You don't really know who they are. There's no authentication there. But in these, in 98 00:08:40,150 --> 00:08:44,690 Ripple and Stellar, you do know. OK. I'm connecting to this node. It's got a key. It's got an 99 00:08:44,690 --> 00:08:45,690 identity. 100 00:08:45,690 --> 00:08:52,240 So to sync, instead of verifying all the work, you verify the signatures on blocks. And the 101 00:08:52,240 --> 00:08:59,530 question is, whose signatures, right? So if you assume, OK, well, if we have a majority 102 00:08:59,530 --> 00:09:05,120 that's honest and is not trying to create transactions that are invalidated or something 103 00:09:05,120 --> 00:09:11,440 like that, then it might work. But majority is hard to define when you're subject to civil 104 00:09:11,440 --> 00:09:12,500 attacks, right? 105 00:09:12,500 --> 00:09:17,760 The obvious attack is I just make thousands of nodes, or maybe these nodes don't even 106 00:09:17,760 --> 00:09:21,750 really exist. I just make thousands of key pairs, have them pretend to be nodes in my 107 00:09:21,750 --> 00:09:27,870 own subnetwork, and they all endorse blocks that are different than the rest of the network 108 00:09:27,870 --> 00:09:29,030 is endorsing. 109 00:09:29,030 --> 00:09:34,410 So majority is the tricky part. How do you know who's the majority if you don't know 110 00:09:34,410 --> 00:09:42,160 who these people are? You need some kind of way to identify humans or computers, even. 111 00:09:42,160 --> 00:09:47,400 And this is a problem akin to certificate authorities. 112 00:09:47,400 --> 00:09:52,850 So a lot of the problems that you see in blockchain, bitcoin, these kind of things, are not exactly 113 00:09:52,850 --> 00:09:57,940 new problems and have sort of already been, quote unquote, "solved." So does everyone 114 00:09:57,940 --> 00:10:06,370 know how CAs work, or do people have some idea? Or who's like, what's a CA? 115 00:10:06,370 --> 00:10:11,290 OK. So it's kind of interesting. I can give a little demo. 116 00:10:11,290 --> 00:10:16,190 AUDIENCE: Did you say CA stands for certificate authority? 117 00:10:16,190 --> 00:10:24,220 TADGE DRYJA: Yes. Uh-oh. This doesn't work. Hold on. OK. So if you have a computer, I 118 00:10:24,220 --> 00:10:27,220 don't know where it is in Windows, but I think in Mac and Linux, it's in the same place. 119 00:10:27,220 --> 00:10:36,380 You go to etc and then-- shoot, I forget where it is. Yeah. Where's the certificates? Cert-- 120 00:10:36,380 --> 00:10:37,380 tru-- 121 00:10:37,380 --> 00:10:42,050 AUDIENCE: CA certificates right under the mouse. 122 00:10:42,050 --> 00:10:53,240 TADGE DRYJA: There it is. OK. So in your computer, and whether you have Linux or Mac, you've 123 00:10:53,240 --> 00:10:59,670 got a folder somewhere, etc/ca-certificates. It's something like that in Mac, as well. 124 00:10:59,670 --> 00:11:09,050 And, oh, no, that's not it. Where are they? Shoot. Wait, wait, wait-- what is in update.dn? 125 00:11:09,050 --> 00:11:13,690 And there's nothing there. 126 00:11:13,690 --> 00:11:32,670 Hold on. I need to find this. Because this is kind of cool. Where are X? Ah, SSL-- is 127 00:11:32,670 --> 00:11:43,490 that-- there we go. OK. So sorry. etc/ssl, and then you've got certs. And this folder 128 00:11:43,490 --> 00:11:46,680 has a bunch of certs. 129 00:11:46,680 --> 00:11:55,530 I trust all of these entities. Well, my computer does and, by extension, my browsers and my 130 00:11:55,530 --> 00:12:01,280 computer, which is crazy because I have no idea who these people are. TURKTRUST? I don't 131 00:12:01,280 --> 00:12:09,720 really trust Turkey. Swisscom-- Swiss people seem nice, I guess. I don't know. OK. Staat-- 132 00:12:09,720 --> 00:12:12,600 they're in Netherlands somewhere. 133 00:12:12,600 --> 00:12:20,260 There's a bunch of, just things you've never heard of. Hellenic Academic and Research Institute, 134 00:12:20,260 --> 00:12:24,540 Hong Kong Post. Well, Hong Kong Post Office seems trustworthy. Yeah? 135 00:12:24,540 --> 00:12:31,630 AUDIENCE: On the TURKTRUST one, you pointed out they have [INAUDIBLE] certificates with 136 00:12:31,630 --> 00:12:35,440 google.com when they're not supposed to. [INAUDIBLE]. 137 00:12:35,440 --> 00:12:43,440 TADGE DRYJA: And then, CNNIC is one which is like-- is that still in here? Maybe they 138 00:12:43,440 --> 00:12:46,300 got rid of it. And then some of them just have these numbers, and you don't even know. 139 00:12:46,300 --> 00:12:47,300 You have to go in. 140 00:12:47,300 --> 00:12:48,300 AUDIENCE: [INAUDIBLE] 141 00:12:48,300 --> 00:12:56,750 TADGE DRYJA: Yeah. China Internet Network Information Center EB certificates root. I 142 00:12:56,750 --> 00:13:06,630 actually really don't trust them to endorse-- pseudo arm-- there we go. OK, it's gone-- 143 00:13:06,630 --> 00:13:11,430 solved it, solved the distributed internet trust problem. 144 00:13:11,430 --> 00:13:15,880 AUDIENCE: Now part of the internet doesn't work for you. 145 00:13:15,880 --> 00:13:22,160 TADGE DRYJA: Yeah, well, I might get invalid certificate errors for some Chinese sites 146 00:13:22,160 --> 00:13:30,750 now. I don't go to many Chinese sites. Anyway, so that's the basic idea of certificate authorities. 147 00:13:30,750 --> 00:13:36,170 And this started in mid-'90s, when they wanted to make public key infrastructure for secure 148 00:13:36,170 --> 00:13:37,650 websites. 149 00:13:37,650 --> 00:13:43,110 One of the problems is how do you know-- so you've got-- oh, we didn't talk about Diffie-Hellman, 150 00:13:43,110 --> 00:13:47,910 or maybe I mentioned it. But you've got public keys, private keys. You've got ways to do 151 00:13:47,910 --> 00:13:53,510 signatures. Diffie-Hellman is a way to do key exchange. So if I know you're a public 152 00:13:53,510 --> 00:13:59,180 key, and I give you my public key, we can form a third, basically, key that we can then 153 00:13:59,180 --> 00:14:03,120 use for encryption and secure messaging. 154 00:14:03,120 --> 00:14:09,690 This works, but how do you know, given a key, who is on the other end? So that's the idea 155 00:14:09,690 --> 00:14:14,010 of certificate authorities. You have this sort of root of trust. And these certificate 156 00:14:14,010 --> 00:14:19,260 authorities sign certificates in websites and let you know, oh, this is the person who 157 00:14:19,260 --> 00:14:21,010 you think it is. 158 00:14:21,010 --> 00:14:27,450 So for example, Google-- secure connection. Really? How do I know? Verified by Google 159 00:14:27,450 --> 00:14:34,260 Trust. Well, Google has verified that Google is trustworthy, which is somewhat circular. 160 00:14:34,260 --> 00:14:41,760 But no, that's sort of how it works. Yeah, so Google Trust Services is a certificate 161 00:14:41,760 --> 00:14:48,820 authority. And they signed off their own certificate for their own website. That's maybe not the 162 00:14:48,820 --> 00:14:52,540 best example. 163 00:14:52,540 --> 00:15:02,070 OK, The New York Times, they are certified by Comodo CA, who also has had-- Comodo has 164 00:15:02,070 --> 00:15:07,500 gotten in a lot of trouble for signing the wrong things. So yeah. New York Times does 165 00:15:07,500 --> 00:15:14,780 not have an EB cert. I think Washington Post does. So there's also EB certs where-- you've 166 00:15:14,780 --> 00:15:17,780 got now The Washington Post, WP Company LLC. 167 00:15:17,780 --> 00:15:22,450 That's like an extended validation cert, which, then, the CA is saying, we didn't just check 168 00:15:22,450 --> 00:15:26,090 that they had an IP address and a domain name. We actually checked that they had some kind 169 00:15:26,090 --> 00:15:31,180 of legal corporate entity. And they sent it on their letterhead, and we, I don't know, 170 00:15:31,180 --> 00:15:36,880 emailed someone in Delaware to make sure they actually had a company. And this is verified 171 00:15:36,880 --> 00:15:43,410 by Entrust. OK. So Entrust, Comodo, those are all going to be in here. Yeah, there's 172 00:15:43,410 --> 00:15:46,460 Comodo. 173 00:15:46,460 --> 00:15:52,380 So you've got these companies called CAs that have some kind of agreement with each other. 174 00:15:52,380 --> 00:15:57,029 There's these standards where you make some kind of standards where, OK, don't sign the 175 00:15:57,029 --> 00:16:05,560 wrong thing. If you do, we're going to delete you. And then they all endorse entities' identity, 176 00:16:05,560 --> 00:16:06,670 usually for companies. 177 00:16:06,670 --> 00:16:11,910 There's also stuff now-- Let's Encrypt, which does it for free and without really endorsing 178 00:16:11,910 --> 00:16:21,110 anything. This whole thing, it sort of felt like it was like the big scam of the late 179 00:16:21,110 --> 00:16:27,730 '90s because they made billions of dollars. But then again, we got Ubuntu out of it, right? 180 00:16:27,730 --> 00:16:37,500 So yeah, Ubuntu was funded by Mark Shuttleworth, who started this one, I believe, and made 181 00:16:37,500 --> 00:16:45,360 a couple hundred million, went on the spaceship, went into orbit, had some fun. Eccentric billionaires 182 00:16:45,360 --> 00:16:53,240 are what fund a lot of technology development. And this is how we get them. 183 00:16:53,240 --> 00:16:57,070 A lot of the people who work on Bitcoin and these systems feel that the current-- it's 184 00:16:57,070 --> 00:17:02,411 called X.509 is the name of this whole system with these certificate authorities-- and I 185 00:17:02,411 --> 00:17:07,359 also sort of feel that this is a suboptimal solution in that there's a lot of problems 186 00:17:07,359 --> 00:17:14,970 with certificates being signed inappropriately. It works, in a way. But it's not great. 187 00:17:14,970 --> 00:17:20,220 So this is a problem. So the problem that these systems like Ripple and Stellar have 188 00:17:20,220 --> 00:17:25,069 to deal with are, in some ways, similar to the problem that is solved by CAs. So what 189 00:17:25,069 --> 00:17:29,690 they do is they say, we have a unique node list. We're not actually endorsing an identity 190 00:17:29,690 --> 00:17:37,320 from, here's a public key, here's a human name or a company name or something like that. 191 00:17:37,320 --> 00:17:39,600 It's we're just saying that they're unique. 192 00:17:39,600 --> 00:17:44,130 So it's more limited than a certificate authority. It's just saying we're certifying that these 193 00:17:44,130 --> 00:17:50,930 two keys belong to different people or different companies, which seems easier than the job 194 00:17:50,930 --> 00:17:56,800 of a CA, right? The CA has to verify that The Washington Post is actually-- whoever's 195 00:17:56,800 --> 00:18:01,540 presenting a public key is actually The Washington Post. So the actual certificate is just, basically, 196 00:18:01,540 --> 00:18:08,850 here's a pubkey, here's a name, and then the CA sign. And you can look at those and stuff. 197 00:18:08,850 --> 00:18:15,210 OK. So for synchronization, you wait for a majority of nodes in your unique node list 198 00:18:15,210 --> 00:18:21,730 to sign and, if they've signed, accept. So there's some recent papers from Ripple. And 199 00:18:21,730 --> 00:18:26,890 in order to really get consensus, you need, basically, a 90% overlap in your own unique 200 00:18:26,890 --> 00:18:27,890 node list. 201 00:18:27,890 --> 00:18:32,470 So if I have a unique node list of Alice and Bob and Carol, and you have a unique node 202 00:18:32,470 --> 00:18:41,980 list of Carol and Dave and Edna-- I don't know-- we might diverge. We might not agree 203 00:18:41,980 --> 00:18:47,780 on the same chain of transactions because we've got different people that were looking 204 00:18:47,780 --> 00:18:52,540 at their signatures. They may all be unique. But if we have different unique people we're 205 00:18:52,540 --> 00:18:54,990 looking to, it might not converge. 206 00:18:54,990 --> 00:19:01,620 So they have a newer paper that reduces that to 60%-ish, where the overlap of what unique 207 00:19:01,620 --> 00:19:07,250 nodes everyone needs to look at is not as large but still quite large. And then, the 208 00:19:07,250 --> 00:19:13,610 real question is, OK, well, who provides the unique node list? Because that's not really 209 00:19:13,610 --> 00:19:14,610 a job I can do. 210 00:19:14,610 --> 00:19:19,740 Maybe it is, in a way. If I know you, and we do some kind of web of trust thing where 211 00:19:19,740 --> 00:19:23,840 I'm like, oh, what's your Ripple nodes pubkey? OK. Cool, I know you. And what's your Ripple 212 00:19:23,840 --> 00:19:27,670 nodes pubkey? We meet in person. We sign each other's pubkeys. We do the whole PGP kind 213 00:19:27,670 --> 00:19:32,830 of thing, which I do. And the Bitcoin people actually do this. 214 00:19:32,830 --> 00:19:44,050 So if I go to-- hold on. So I've got a bunch of keys, and everyone signed them. And there's 215 00:19:44,050 --> 00:19:49,960 Andrew Chow and Suhas and [INAUDIBLE] and all these Bitcoin people. And I've signed 216 00:19:49,960 --> 00:19:54,210 their keys and they've signed my keys because we meet in person and do that kind of thing. 217 00:19:54,210 --> 00:20:01,590 So we've established not just a unique node list, but we've done a CA-free validation 218 00:20:01,590 --> 00:20:05,940 of each other's keys. We just meet in person, read each other's keys off. 219 00:20:05,940 --> 00:20:12,260 So you can do that, in practice. It's really nerdy, and no one does that. And it would 220 00:20:12,260 --> 00:20:20,830 be cool if we could get it to be easier and maybe cooler somehow. But it's been an uphill 221 00:20:20,830 --> 00:20:21,830 battle. 222 00:20:21,830 --> 00:20:27,840 So who provides the UNL? It's probably kind of obvious. Well, the Ripple company provides 223 00:20:27,840 --> 00:20:34,809 the UNL, right? So when you download Ripple, it has a list of unique nodes. Those are essentially 224 00:20:34,809 --> 00:20:41,040 de facto, the nodes that run Ripple. And at the current time, those nodes are run by the 225 00:20:41,040 --> 00:20:43,890 Ripple corporation, or Ripple apps. 226 00:20:43,890 --> 00:20:50,440 Stellar, similarly, it comes with a default UNL. It sort of acts like the CAs, right? 227 00:20:50,440 --> 00:20:57,429 It's sort of how when you start your computer, you've got this. This comes with your OS. 228 00:20:57,429 --> 00:21:04,160 And you don't really have a choice. I just deleted the CNNIC one. But nobody looks at 229 00:21:04,160 --> 00:21:10,340 this stuff. Everyone just goes with the defaults. So that's the problem centralization-wise. 230 00:21:10,340 --> 00:21:11,340 Yes? 231 00:21:11,340 --> 00:21:12,860 AUDIENCE: You said Ripple or Stellar actually run the nodes? Because I understand that they 232 00:21:12,860 --> 00:21:19,450 might sign off on the UNL if you're saying that-- 233 00:21:19,450 --> 00:21:26,090 TADGE DRYJA: In Ripple's-- at least a year or two ago, and they may have changed that, 234 00:21:26,090 --> 00:21:32,280 I think they're trying to-- but in Ripple's case, yeah. They ran their own Ripple nodes. 235 00:21:32,280 --> 00:21:34,760 AUDIENCE: So it's not these bank partners or anything? 236 00:21:34,760 --> 00:21:40,400 TADGE DRYJA: They may have some. They may now. But I know that two years ago, it was 237 00:21:40,400 --> 00:21:49,330 just Ripple, or majority Ripple. Because they also put in things like they can freeze funds. 238 00:21:49,330 --> 00:21:53,480 Because Ripple got in trouble with FinCEN. And part of the thing is they modified their 239 00:21:53,480 --> 00:21:58,570 code to be able to freeze people's funds if they did something bad. 240 00:21:58,570 --> 00:22:06,480 That's definitely not something that the Bitcoin developers, or even the Ethereum Foundation-- 241 00:22:06,480 --> 00:22:10,870 it's not as direct, anyway. The Ethereum Foundation did freeze funds and move them against the 242 00:22:10,870 --> 00:22:17,090 rules of the system in the case of the Dow. But that was, in a lot of ways, with support 243 00:22:17,090 --> 00:22:23,880 of a lot of the people running Ethereum. With Ripple, they can do it without much brouhaha. 244 00:22:23,880 --> 00:22:28,000 They just freeze these funds. 245 00:22:28,000 --> 00:22:34,240 So it's fast. There's no work involved. There's no worry about propagating blocks and miners 246 00:22:34,240 --> 00:22:40,200 getting advantages. But there's also known identities, and so it's more susceptible to 247 00:22:40,200 --> 00:22:44,240 subpoenas and things like that. 248 00:22:44,240 --> 00:22:49,360 In these cases, all the coins existed at the genesis block. So in the case of Ripple, I 249 00:22:49,360 --> 00:22:55,820 think it was 100 billion or something. And they just started with all the coins and distributed 250 00:22:55,820 --> 00:22:57,880 them as they saw fit. 251 00:22:57,880 --> 00:23:02,340 Same with Stellar. Stellar had this thing where they had this party, and they would 252 00:23:02,340 --> 00:23:07,110 give them away if you signed up on Facebook. A really interesting article about people 253 00:23:07,110 --> 00:23:14,290 in Manila getting thousands of used SIM cards from the US, registering for new Facebook 254 00:23:14,290 --> 00:23:18,970 accounts, selling those Facebook accounts to people in China, the people in China then 255 00:23:18,970 --> 00:23:24,990 registering with Stellar as unique people to get more stellars. 256 00:23:24,990 --> 00:23:30,970 When you incentivize things, weird things happen, be it either giant warehouses full 257 00:23:30,970 --> 00:23:39,530 of SHA256 chips or giant warehouses full of 20-year-old girls in Manila putting SIM cards 258 00:23:39,530 --> 00:23:45,360 in cell phones all day. Yeah. I should link to that article. It's really interesting. 259 00:23:45,360 --> 00:23:48,190 So anyway, this is the Stellar one. And Stellar also had this thing where they were going 260 00:23:48,190 --> 00:23:55,640 to give 20% of the stellar to people who held bitcoin, sort of an airdrop. I didn't get 261 00:23:55,640 --> 00:24:01,460 any from that. I was sort of hoping. I'm like, hey, cool-- air drop. I have bitcoin. I'll 262 00:24:01,460 --> 00:24:05,710 get some stellar. I didn't because you basically had to KYC with them. 263 00:24:05,710 --> 00:24:10,270 They said, OK, send in your-- I don't know if it was the social security number-- but 264 00:24:10,270 --> 00:24:15,670 send in your documents and prove that you have these bitcoins, and we will credit some 265 00:24:15,670 --> 00:24:23,100 stellar to the same keys. And I'm not going to do that. Yeah. Some people did. Some people 266 00:24:23,100 --> 00:24:26,740 got some stellar that way. Yeah. So anyway. Yeah? 267 00:24:26,740 --> 00:24:29,429 AUDIENCE: If Stellar's just freezing coins-- 268 00:24:29,429 --> 00:24:34,670 TADGE DRYJA: No. I don't know if Stellar has that capability. Ripple does. Ripple put that 269 00:24:34,670 --> 00:24:39,740 in. Stellar is a different-- it's similar software. They certainly argue about how different 270 00:24:39,740 --> 00:24:40,970 they are. 271 00:24:40,970 --> 00:24:49,610 Stellar had a bug in 2015, I believe, where the consensus broke. And then they said, oh, 272 00:24:49,610 --> 00:24:55,670 it's Ripple's code's fault. This is a fault with all this code base. And then Ripple said, 273 00:24:55,670 --> 00:24:58,600 no, no, no. It's because you changed it. And you don't know what you're doing. 274 00:24:58,600 --> 00:25:03,429 AUDIENCE: I was talking about, I guess, the minimums. You said there was a minimum. 275 00:25:03,429 --> 00:25:06,820 TADGE DRYJA: Yeah, there's a minimum account balance. 276 00:25:06,820 --> 00:25:13,240 AUDIENCE: And if there's a set number of coins, then eventually, accounts will just get-- 277 00:25:13,240 --> 00:25:19,150 TADGE DRYJA: Yeah. It's a lot, though. Also, there's enough forever. There's a lot of coins. 278 00:25:19,150 --> 00:25:24,100 But yeah. But the idea is not that you have UTXOs, like in Bitcoin, and you make new addresses 279 00:25:24,100 --> 00:25:29,760 each time. The idea is you have an address. You keep that forever. So why would you have 280 00:25:29,760 --> 00:25:32,300 multiple different addresses, that kind of thing. 281 00:25:32,300 --> 00:25:38,340 Anyway. So it's a pretty different system. In some ways, you could argue it's one of 282 00:25:38,340 --> 00:25:43,320 the first ICOs-- Ripple-- because it was pretty early. They just came up with all their coins 283 00:25:43,320 --> 00:25:49,270 and gave them out and then started selling them. And they continue to do that to this 284 00:25:49,270 --> 00:25:50,270 day. 285 00:25:50,270 --> 00:25:54,820 Stellar is a nonprofit, which is also sort of weird. Because if you make a billion dollars 286 00:25:54,820 --> 00:26:02,650 off of something, is it really a nonprofit? I don't know. The organization didn't directly 287 00:26:02,650 --> 00:26:08,330 make the money and then pay it to the employees or anything. But the people who have all the 288 00:26:08,330 --> 00:26:15,430 stellar tokens made a lot of money. Interesting sort of ways to do it. 289 00:26:15,430 --> 00:26:25,000 So I think both Ripple and Stellar argue that it's decentralized, distributed. But I think 290 00:26:25,000 --> 00:26:31,080 a lot of people say, well, maybe to some extent. But on the spectrum of completely decentralized 291 00:26:31,080 --> 00:26:37,110 versus one server handles it all, it's a lot further on the centralized side. 292 00:26:37,110 --> 00:26:42,840 And Bitcoin is also kind of centralized, too, like we were talking about on Monday. But 293 00:26:42,840 --> 00:26:50,120 I would argue these are more so. So anyway. Any questions about Ripple, Stellar? Pretty 294 00:26:50,120 --> 00:26:51,120 fun. 295 00:26:51,120 --> 00:26:56,500 OK. Next, the big one-- proof of stake. So this we've mentioned a little bit. It's a 296 00:26:56,500 --> 00:27:01,929 popular alternative where people really don't like the proof of work stuff. So instead of 297 00:27:01,929 --> 00:27:09,910 proving work, have the people who hold coins sign the blocks. So that bootstraps, in a 298 00:27:09,910 --> 00:27:12,910 way, your unique node list or your list of who's who. 299 00:27:12,910 --> 00:27:18,190 Well, you don't really care who they are. But if they have coins, if you already have 300 00:27:18,190 --> 00:27:23,059 a set of who owns what coins, you can use that to say, OK, well, the people who own 301 00:27:23,059 --> 00:27:27,280 coins now signed. And they, presumably, have incentives not to destroy the network they 302 00:27:27,280 --> 00:27:28,280 have coins in. 303 00:27:28,280 --> 00:27:34,620 So if you have a given genesis block with some kind of initial distribution, you can 304 00:27:34,620 --> 00:27:40,010 make it deterministic. You can say, I'm just going to go with whatever has the most stake, 305 00:27:40,010 --> 00:27:46,540 whoever has the most coins, signing off on the next block. And given two or three different 306 00:27:46,540 --> 00:27:52,700 histories, you can see, OK, from the start, which has the most total stakes signing off 307 00:27:52,700 --> 00:27:56,770 on these things? So that seems pretty cool. 308 00:27:56,770 --> 00:28:02,430 Here's some issues. Stake grinding-- so for example, let's say you have a system where 309 00:28:02,430 --> 00:28:07,800 the signer of the next block is determined by the public key nearest to the previous 310 00:28:07,800 --> 00:28:12,620 block hash. So for example, OK, I'm looking at the current block hash. Who gets to sign 311 00:28:12,620 --> 00:28:20,400 next? Well, whoever's key is closest. Use X or just treat the hash as a number and treat 312 00:28:20,400 --> 00:28:24,530 the pubkey as a number and see which is closest. 313 00:28:24,530 --> 00:28:30,419 You can do that. But the problem is if the next hash is determined by the current signer, 314 00:28:30,419 --> 00:28:35,080 that current signer can make a new signature each time and try to make sure that the block 315 00:28:35,080 --> 00:28:40,360 after is also going to be one where they are, again, the next signer. And they can make 316 00:28:40,360 --> 00:28:47,410 a couple hundred different accounts with their keys and then keep grinding stake. 317 00:28:47,410 --> 00:28:53,450 And this basically means that it turns into proof of work. Because if you can influence 318 00:28:53,450 --> 00:29:00,400 who's going to be the next block signer-- yourself-- keep trying different ways to sign, 319 00:29:00,400 --> 00:29:05,220 OK, that's basically proof of work, but instead of hashing, you're signing. 320 00:29:05,220 --> 00:29:10,929 And this has happened in many altcoins. One that I think was kind of interesting was Nxt, 321 00:29:10,929 --> 00:29:18,010 which is the people who later went on to make IOTA. They said, OK, well, we have a deterministic 322 00:29:18,010 --> 00:29:27,080 signature scheme, and so this can't happen, right? Given a message and a private key, 323 00:29:27,080 --> 00:29:29,730 there's only one signature that can be produced. 324 00:29:29,730 --> 00:29:36,549 And this is true. So Bitcoin uses this. It's called rfc6979. Basically, the random nonce 325 00:29:36,549 --> 00:29:40,200 can be deterministically created from your private key and message. 326 00:29:40,200 --> 00:29:46,790 The problem is-- I don't know if they realized, probably not-- but you can't enforce this. 327 00:29:46,790 --> 00:29:51,750 It's a policy that says, OK, I'm going to make a deterministic signature. But given 328 00:29:51,750 --> 00:29:58,040 a signature, you can't tell if someone did this or not, right? So it's up to you to obey 329 00:29:58,040 --> 00:30:03,650 this rule. But you can't verify that anyone did it. 330 00:30:03,650 --> 00:30:08,890 So that one also quickly devolved into proof of work and in a tricky way because a lot 331 00:30:08,890 --> 00:30:13,960 of people read the documentation and said, OK, well, there is no way to keep signing. 332 00:30:13,960 --> 00:30:18,050 Their function that they wrote, there's only one way to sign. When you sign a message with 333 00:30:18,050 --> 00:30:20,840 a public key, you get a single signature. 334 00:30:20,840 --> 00:30:25,160 But people who knew how it worked under the hood said, oh, I can change this code. It 335 00:30:25,160 --> 00:30:28,390 will still be accepted as a valid signature even though I'm using a different signing 336 00:30:28,390 --> 00:30:35,830 scheme. So this is one issue, stake grinding. There's ways to get around it. 337 00:30:35,830 --> 00:30:42,330 So let's say you make it deterministic. You have some way to enforce that a signer can 338 00:30:42,330 --> 00:30:46,230 only create one message. There are certain signature schemes where you can verifiably 339 00:30:46,230 --> 00:30:52,350 make sure that a single key can only make a single signature on a message. 340 00:30:52,350 --> 00:30:58,539 Other ways to do it is to, say, have this big lead time, where the people who are signing 341 00:30:58,539 --> 00:31:05,530 the next block are determined by entropy created days or weeks ago. So it's hard to know what's 342 00:31:05,530 --> 00:31:10,910 going to happen in a week because it's a long period of time's worth of entropy going into 343 00:31:10,910 --> 00:31:11,910 it. 344 00:31:11,910 --> 00:31:22,080 OK. There's another issue with proof of stake called nothing at stake. So rehash-- rehash-- 345 00:31:22,080 --> 00:31:28,441 ha ha. So in proof of work, this happens, right? This happens just by accident, where 346 00:31:28,441 --> 00:31:33,230 OK, there's a block. And then two people are mining on top of it. Oh, they both got this 347 00:31:33,230 --> 00:31:38,750 and then sometimes even this. That almost never happens in Bitcoin, but sometimes, where 348 00:31:38,750 --> 00:31:44,559 you just randomly get two split chains coming out at the same time. 349 00:31:44,559 --> 00:31:52,039 But then this happens, right? Someone builds on this one. OK, you get rid of those two. 350 00:31:52,039 --> 00:31:58,010 And that's just because this is a random process. You can mine on whichever you want. One of 351 00:31:58,010 --> 00:31:59,010 them is going to happen first. 352 00:31:59,010 --> 00:32:03,289 You can mine on both. You can split your hash bar. If you have a billion hashes per second, 353 00:32:03,289 --> 00:32:08,100 you can say, well, I'll do 500 million here and 500 million here. You can equivocate. 354 00:32:08,100 --> 00:32:15,419 It's sort of equivocation that way. But one of them will finish first, with very high 355 00:32:15,419 --> 00:32:18,900 probability. So eventually, this happens. And then everyone just starts building off 356 00:32:18,900 --> 00:32:21,830 this 00a3. 357 00:32:21,830 --> 00:32:30,289 Proof of stake-- so this happens. Also, notice that the hashes don't-- they don't start with 358 00:32:30,289 --> 00:32:37,240 zeros. So this happens. But then this happens. And then this happens. And then it just keeps 359 00:32:37,240 --> 00:32:41,780 going. Because why not sign both, right? 360 00:32:41,780 --> 00:32:48,690 I don't know which one's going to win, right? As a proof of stake miner or staker, I don't 361 00:32:48,690 --> 00:32:52,460 really know which one's going to win, which is the same case and proof of work. In proof 362 00:32:52,460 --> 00:32:56,789 of work, I just flip a coin and pick, right? I don't know what's going to win. 363 00:32:56,789 --> 00:33:01,591 I think in bitcoin, the default is go with the one I saw first. Because whatever. It 364 00:33:01,591 --> 00:33:07,120 doesn't matter who wins, right? Basically, I win, whichever I pick. If I'm the next one 365 00:33:07,120 --> 00:33:11,289 making the block, I win. 366 00:33:11,289 --> 00:33:17,809 But what I don't want is I don't want to be this this-- wait a sec. What I don't want 367 00:33:17,809 --> 00:33:23,610 to be in proof of work is I don't want to be 008a, right? I don't want to be the last 368 00:33:23,610 --> 00:33:29,190 one to make a block, and then something else comes out here. 369 00:33:29,190 --> 00:33:36,820 So I'd rather be 00f2. But you don't know here, right? So you just pick one. OK. Well, 370 00:33:36,820 --> 00:33:42,290 we lost. In proof of stake, you don't have to worry about that. I'll just build both, 371 00:33:42,290 --> 00:33:49,120 right? It takes me no work to sign. So I just sign off on both of them and make parallel 372 00:33:49,120 --> 00:33:55,530 chain. And then everyone just keeps doing that. Because if I pick one, I might be wrong. 373 00:33:55,530 --> 00:33:57,809 If I pick both, I can't be wrong. 374 00:33:57,809 --> 00:34:01,010 So this is a problem called nothing at stake. You have no risk here. You're not actually 375 00:34:01,010 --> 00:34:07,200 doing any work. You might as well just keep going. So yeah. Faced with two blocks, why 376 00:34:07,200 --> 00:34:08,329 not sign both? 377 00:34:08,329 --> 00:34:14,090 So the mitigations-- one of the ideas early in Ethereum was, OK, this thing called Slasher, 378 00:34:14,090 --> 00:34:22,149 where if you can prove that a signature from a different chain-- so the idea is on chain 379 00:34:22,149 --> 00:34:30,379 00a3-- oh, wait-- oops. Sorry. On this chain, you say, hey, look. This guy equivocated. 380 00:34:30,379 --> 00:34:36,668 He signed off on two blocks, one of which exists in my history that I can point to, 381 00:34:36,668 --> 00:34:40,730 one of which doesn't exist in my history, but I can provide that signature. I can say, 382 00:34:40,730 --> 00:34:46,710 look, here's two signatures at the same block height from the same person, but they're signing 383 00:34:46,710 --> 00:34:52,379 different things. Let's not invalidate this block, but let's take all the rewards from 384 00:34:52,379 --> 00:34:53,750 the person who signed. 385 00:34:53,750 --> 00:35:02,599 OK. So yeah. This is called Slasher. I believe in Ethereum, like, 2014, they were saying, 386 00:35:02,599 --> 00:35:06,849 hey, we're going to do proof of stake. And then they tried all these things and sort 387 00:35:06,849 --> 00:35:10,700 of, oh, it's non-trivial. Let's start with proof of work, and then we'll move to proof 388 00:35:10,700 --> 00:35:15,630 of stake later. And that's currently their plan. So this was one of their early algorithms, 389 00:35:15,630 --> 00:35:17,280 their early ideas. 390 00:35:17,280 --> 00:35:26,840 There's also issues with the mitigation because maybe it's hard to get this proof into the 391 00:35:26,840 --> 00:35:31,580 blockchain. Because the miners, or the stakers, are the ones who determine what gets in and 392 00:35:31,580 --> 00:35:32,580 what doesn't. 393 00:35:32,580 --> 00:35:47,770 And so they certainly could say, look, if the person who created this block then sees 394 00:35:47,770 --> 00:35:54,830 in this block that there's a Slasher proof where, hey, I just now proved that you equivocated 395 00:35:54,830 --> 00:35:59,090 and destroy your account, well, the person who signed this doesn't build on this and 396 00:35:59,090 --> 00:36:04,020 instead forks off and builds their own, right? Why would I continue to mine on a chain where 397 00:36:04,020 --> 00:36:06,360 I just lost all my money? 398 00:36:06,360 --> 00:36:10,070 So there's all sorts of weird-- and there's mitigations for that. So it's a little bit 399 00:36:10,070 --> 00:36:14,320 whack-a-mole, where there's all these weird problems, and you have to try to fix them. 400 00:36:14,320 --> 00:36:19,130 And then fixing them introduces new weird things. So there's a lot of people working 401 00:36:19,130 --> 00:36:20,980 on it. 402 00:36:20,980 --> 00:36:27,950 Yeah. Long-range attacks is another big one. Let's say you go back to the genesis block, 403 00:36:27,950 --> 00:36:35,050 and you rewrite history. In Bitcoin, you can also do this. It's just really hard, right? 404 00:36:35,050 --> 00:36:40,849 You could say, I'm going to get a bunch of miners, rewrite all nine years of Bitcoin's 405 00:36:40,849 --> 00:36:44,880 blocks, and we know exactly how long that will take. 406 00:36:44,880 --> 00:36:50,570 sipa has a nice graph of it, I think. And sometimes it's not very long. Sometimes it's 407 00:36:50,570 --> 00:37:03,260 actually pretty easy to do that. Yeah, that's the other site. Hash rate-- this-- wait-- 408 00:37:03,260 --> 00:37:08,860 yes. Bitcoin network proof of work equivalent days. That's this year. This is since the 409 00:37:08,860 --> 00:37:11,630 beginning. 410 00:37:11,630 --> 00:37:16,280 What this means is, OK, given the current hash rate in Bitcoin, how long would it take 411 00:37:16,280 --> 00:37:22,150 to rewrite the entire history of Bitcoin? Because the hash rate goes up, right? And 412 00:37:22,150 --> 00:37:28,950 sometimes it goes up in-- so this is the all-time hash rate. It basically always looks like 413 00:37:28,950 --> 00:37:32,760 this because it's exponential. So if you looked at it three years ago, it would look pretty 414 00:37:32,760 --> 00:37:33,760 much the same. 415 00:37:33,760 --> 00:37:40,310 And then this is a log chart. So this actually does show some interesting detail, where, 416 00:37:40,310 --> 00:37:45,620 OK, this is when the GPUs came out. This is when nothing much happened in 2012. This is 417 00:37:45,620 --> 00:37:52,910 when ASICs came out. And then it just keeps going up. And this is log scale, where each 418 00:37:52,910 --> 00:37:58,020 number is 100 or 1,000 times. So it's big. 419 00:37:58,020 --> 00:38:06,780 So when you have these really sharp upticks, like in mid-2010, the current power of the 420 00:38:06,780 --> 00:38:11,150 network is so high-- that probably corresponds to this, the lowest point there, because that's 421 00:38:11,150 --> 00:38:17,440 the steepest slope, where I don't know what this is, a week?-- you could rewrite the entire 422 00:38:17,440 --> 00:38:25,010 history of Bitcoin in a week and destroy everyone's currency and have all the coins yourself if 423 00:38:25,010 --> 00:38:30,180 you had enough power under your control, which you could probably do. 424 00:38:30,180 --> 00:38:35,870 And today, it sits at around 200, a little less than 200, so a little over six months 425 00:38:35,870 --> 00:38:40,820 where, if you devoted all the current hash power, you could rewrite all the previous 426 00:38:40,820 --> 00:38:49,230 history. Still, six months-- it's a lot. And it's interesting how this changes. This is, 427 00:38:49,230 --> 00:38:54,570 I guess, when the ASICs first came out, and then the slope [INAUDIBLE]. 428 00:38:54,570 --> 00:39:01,020 So that is an issue in proof of work that can happen. It's not clear what would happen. 429 00:39:01,020 --> 00:39:06,470 The software, at least in theory, the idea is if something like that happens, where there's 430 00:39:06,470 --> 00:39:16,700 a reorg that spans nine years, well, extend this out to 500,000 and say, OK, all the stuff 431 00:39:16,700 --> 00:39:21,109 you've been dealing with the last nine years, it's out. We've got this new history now with 432 00:39:21,109 --> 00:39:24,160 one person owning all the money, presumably. 433 00:39:24,160 --> 00:39:31,660 The software will do that, probably, or it'll just crash or something. It's sort of seen 434 00:39:31,660 --> 00:39:37,210 as like, well, if there's a reorg that spans weeks or months, the whole system's broken, 435 00:39:37,210 --> 00:39:40,349 kind of. But probably. 436 00:39:40,349 --> 00:39:48,610 So this is an issue for Bitcoin. But it's a big issue in proof of stake because it seems 437 00:39:48,610 --> 00:39:52,660 possibly more feasible, right? In Bitcoin, there have been times when it's like, whoa, 438 00:39:52,660 --> 00:39:57,440 a week, yeah, that's feasible, whereas right now, it's like, OK, it would take all the 439 00:39:57,440 --> 00:40:01,599 hash power in existence maybe seven or eight months. So that means that Bitcoin would just 440 00:40:01,599 --> 00:40:10,540 halt for seven months, and then you'd see this reorg happen. And also, it assumes 51% 441 00:40:10,540 --> 00:40:13,890 of the miners are doing this. 442 00:40:13,890 --> 00:40:19,790 However, proof of stake, it might not be that expensive, especially if you can get old keys. 443 00:40:19,790 --> 00:40:25,970 So if you've got the keys from the genesis block in this proof of stake currency, you 444 00:40:25,970 --> 00:40:33,349 can rewrite a history from those with different transactions. So yeah. So a lot of the times, 445 00:40:33,349 --> 00:40:36,680 the solution is, OK, well, delete old keys and assume 50% honest. 446 00:40:36,680 --> 00:40:43,140 That's tricky. Because old keys can be sold. And I know that people have asked, hey, can 447 00:40:43,140 --> 00:40:48,200 I buy your old Ethereum keys? Why do you want these? Well, if proof of stake happens, they 448 00:40:48,200 --> 00:40:53,990 might be worth something. Currently, if you have keys that are for addresses or accounts 449 00:40:53,990 --> 00:40:59,100 that don't have any money anymore, it's not very useful but possibly can be sold. Yeah? 450 00:40:59,100 --> 00:41:00,100 AUDIENCE: Most proof of work schemes that I'm aware of use a [INAUDIBLE]. 451 00:41:00,100 --> 00:41:01,540 TADGE DRYJA: A proof of stake? 452 00:41:01,540 --> 00:41:03,590 AUDIENCE: Yeah. 453 00:41:03,590 --> 00:41:10,440 TADGE DRYJA: Yeah. So you checkpoint it. So basically, to prevent long-range attacks, 454 00:41:10,440 --> 00:41:18,350 the developers, usually, in GitHub, will just say, OK, well, the block hash here is this. 455 00:41:18,350 --> 00:41:23,450 And so you can't reorg before that. But then, what's the mechanism for that? If it's the 456 00:41:23,450 --> 00:41:32,619 developers just sticking in a checkpoint, that's not really decentralized. 457 00:41:32,619 --> 00:41:36,940 AUDIENCE: In the example of Aircoin, there's actually a checkpointing [? software ?] that, 458 00:41:36,940 --> 00:41:37,940 every few hours, forces a [INAUDIBLE]. 459 00:41:37,940 --> 00:41:40,730 TADGE DRYJA: OK. Well, that's even more not very decentralized. You've now got a pubkey 460 00:41:40,730 --> 00:41:45,760 hardcoded into the code, which then calls out to somewhere and says, OK, what's the 461 00:41:45,760 --> 00:41:53,090 correct block to be on? And then that key signs something, says, oh, go here. OK. Yeah. 462 00:41:53,090 --> 00:41:54,660 That's pretty centralized. 463 00:41:54,660 --> 00:42:02,580 So this is one that I think is-- it's hard, right? Because before these things happen, 464 00:42:02,580 --> 00:42:06,060 it's easy to dismiss as like, this is crazy. That's never going to happen. Who's going 465 00:42:06,060 --> 00:42:12,421 to go back and buy up all these old keys that people were supposed to have deleted? People 466 00:42:12,421 --> 00:42:16,760 probably did delete them. You can't assume that they haven't. 467 00:42:16,760 --> 00:42:20,750 And even if they did and you made this big reorg, well, everyone would know in practice 468 00:42:20,750 --> 00:42:27,099 that that's not the right chain, similar to if there's a nine-year block reorg in Bitcoin, 469 00:42:27,099 --> 00:42:33,360 everyone would know, OK, come on. We all knew what the blocks were yesterday. You can't 470 00:42:33,360 --> 00:42:36,410 just tell me there's this entirely new history today. 471 00:42:36,410 --> 00:42:41,300 And in practice, that's probably true, right? If there was a nine-year block reorg in Bitcoin, 472 00:42:41,300 --> 00:42:47,970 probably, people would just ignore it. Similarly, in these systems, probably, they would ignore 473 00:42:47,970 --> 00:42:55,380 it. But it's harder to reason about in these systems, I think. 474 00:42:55,380 --> 00:43:00,760 But anyway. So proof of stake, there is a bunch of coins that use it. In a lot of cases, 475 00:43:00,760 --> 00:43:06,820 they have centralization that's hidden in certain ways. I like the term Greg Maxwell 476 00:43:06,820 --> 00:43:10,960 came up called trust laundering. It's not money laundering. It's trust laundering. You 477 00:43:10,960 --> 00:43:15,520 sort of move where you're trusting and try to hide it. 478 00:43:15,520 --> 00:43:23,170 Yeah. So very common. But this also deals with, OK, who gets the initial coins? Because 479 00:43:23,170 --> 00:43:28,839 they have an enormous power over the system. So very common for altcoins-- less so now, 480 00:43:28,839 --> 00:43:35,980 I think-- was start with proof of work, then transition to proof of stake. Do they still? 481 00:43:35,980 --> 00:43:37,690 Not as much. 482 00:43:37,690 --> 00:43:43,700 AUDIENCE: Now you don't need to do that because you [INAUDIBLE]. 483 00:43:43,700 --> 00:43:47,160 TADGE DRYJA: Right. So you just do ERC-20. Yeah. But it used to be, like 2014, 2015, 484 00:43:47,160 --> 00:43:53,390 a lot of the coins would be, OK, proof of work for the first month, two months, whatever 485 00:43:53,390 --> 00:43:57,740 it was, with some weird algorithm and Comodo gravity well and all sorts of weird stuff. 486 00:43:57,740 --> 00:44:00,630 And then it would switch at a certain point to proof of stake. 487 00:44:00,630 --> 00:44:06,990 So that proof of work period builds out the list of who owns what in a sort of provable 488 00:44:06,990 --> 00:44:12,240 way. And then, from there, you can use proof of stake. Because you've got a, hopefully, 489 00:44:12,240 --> 00:44:15,740 fairly well distributed set of who owns what. 490 00:44:15,740 --> 00:44:21,450 Yeah. Some things still do this. And some things have hybrid, where you still have to 491 00:44:21,450 --> 00:44:25,099 do work each block. But depending on how much stake you have, depending on how many coins 492 00:44:25,099 --> 00:44:27,010 you have, you have to do less work. 493 00:44:27,010 --> 00:44:31,609 I think decred is something like that. That actually can make sense. Because you've still 494 00:44:31,609 --> 00:44:41,830 got work, and you can mix them in ways that negate some of the downsides of both. 495 00:44:41,830 --> 00:44:47,040 Delegated proof of stake. Well, signing requires you to actually do something and be online. 496 00:44:47,040 --> 00:44:52,340 So in a lot of proof of stake currencies, very few people actually stake because they 497 00:44:52,340 --> 00:44:57,580 don't care. And they leave money on the table, sure. But they don't want to run their own 498 00:44:57,580 --> 00:45:01,660 node. They don't want to deal with this stuff. They just buy it, keep it on exchange, or 499 00:45:01,660 --> 00:45:04,369 maybe keep it on their own computer. 500 00:45:04,369 --> 00:45:09,560 So instead, you can endorse a leader by signing with your coins and saying, hey, I'm not going 501 00:45:09,560 --> 00:45:14,750 to actually sign off on blocks, but I'll sign off on a different key, who now can sign on 502 00:45:14,750 --> 00:45:22,570 my behalf. And so this can be called supernodes, masternodes. And then is it peer-to-peer, 503 00:45:22,570 --> 00:45:25,830 or is it client server is what it becomes. 504 00:45:25,830 --> 00:45:30,330 So the current one that's pretty popular is called EOS, where I think they're doing this 505 00:45:30,330 --> 00:45:35,839 kind of thing. And they're like, well, there's 20 computers that run the network. And you 506 00:45:35,839 --> 00:45:41,010 can endorse one of them, and they'll give you some kind of profit back or something. 507 00:45:41,010 --> 00:45:44,140 And you need a million dollars to run one of these computers. Because it's going to 508 00:45:44,140 --> 00:45:49,450 be super powerful, and you can do free transactions that way. 509 00:45:49,450 --> 00:45:54,110 So this gets pretty far into client server territory, where you're not up here. You're 510 00:45:54,110 --> 00:46:01,650 just the client, and you ask them what is going on, which, in many cases, works, right? 511 00:46:01,650 --> 00:46:04,200 But then again, it's not quite as interesting because that's sort of the system we already 512 00:46:04,200 --> 00:46:07,170 have with banks. So meh. 513 00:46:07,170 --> 00:46:10,450 But in a lot of cases, yeah, that's what people want. I sort of joke that I should just make 514 00:46:10,450 --> 00:46:13,670 one called Central Coin, where there's just a nice server, and it just keeps track of 515 00:46:13,670 --> 00:46:22,119 who owns what, and then have an ICO. And people would use it. It's like, hey. So I think people 516 00:46:22,119 --> 00:46:27,000 would be into it. Anyway, so that's distributed proof of stake. 517 00:46:27,000 --> 00:46:31,040 OK. So proof of stake, in general, it's hard to resolve conflicts using only the system 518 00:46:31,040 --> 00:46:34,700 itself. Proof of work has this really nice property where it's taking something from 519 00:46:34,700 --> 00:46:44,000 the external world, be it CPU time, be it chips, and using that to get a dead reckoning 520 00:46:44,000 --> 00:46:46,720 on the system itself. That's nice. 521 00:46:46,720 --> 00:46:51,440 Proof of stake, the really difficult part is it's a closed system. You're trying to 522 00:46:51,440 --> 00:46:57,170 resolve conflicts within the system using no external data. That's really hard. 523 00:46:57,170 --> 00:47:01,910 Another problem people complain about is that the rich get richer. I agree it's a problem. 524 00:47:01,910 --> 00:47:07,370 It kind of sucks. But proof of work is the same. I don't feel like any of these systems 525 00:47:07,370 --> 00:47:13,170 will change the inherent Pareto distribution of wealth in the universe. That just seems 526 00:47:13,170 --> 00:47:16,470 to be how things work. It'd be cool if everyone had the same amount of money, I guess, maybe. 527 00:47:16,470 --> 00:47:20,070 But I don't think it's going to happen. 528 00:47:20,070 --> 00:47:26,400 Yeah. And then it relies on different assumptions. So the assumption in Bitcoin is 51% of miners 529 00:47:26,400 --> 00:47:32,650 can destroy the system. So in some cases, people say, well, you assume 51% honest in 530 00:47:32,650 --> 00:47:39,670 Bitcoin. Kind of. It's more like 51% rational. In Bitcoin, you could have miners with 51% 531 00:47:39,670 --> 00:47:46,109 attack the system, but they make more money by doing the right thing. 532 00:47:46,109 --> 00:47:51,730 So there are certain cases in proof of stake where honesty is not as profitable. And if 533 00:47:51,730 --> 00:47:57,170 honesty is not profitable, well, maybe there's a lot more incentive to be not honest in the 534 00:47:57,170 --> 00:48:01,000 terms of the system, whereas in Bitcoin, it's like you've got this nice system where it 535 00:48:01,000 --> 00:48:04,530 seems like the honesty is not just enforced by people trying to be nice. It's enforced 536 00:48:04,530 --> 00:48:11,010 by people being greedy, which seems more common than being nice in the world. 537 00:48:11,010 --> 00:48:16,970 So there's tons of research in proof of stake. Some of it's pretty interesting, pretty clever. 538 00:48:16,970 --> 00:48:26,079 I'm not super hopeful. But the thing is it works until it doesn't. And so it's really 539 00:48:26,079 --> 00:48:30,290 hard to show security under different attacks. 540 00:48:30,290 --> 00:48:33,760 So what I would worry about is you've got this proof of stake system. It seems to be 541 00:48:33,760 --> 00:48:37,589 working. And then something weird happens. And it's revealed as, oh, actually, this was 542 00:48:37,589 --> 00:48:44,410 a lot more centralized than it seemed to be, which is also a worry in proof of work. OK. 543 00:48:44,410 --> 00:48:45,410 Any questions, proof of stake? Yes? 544 00:48:45,410 --> 00:48:53,200 AUDIENCE: A quick one on the economics. Is the stake the nodes have. Yeah, right. So 545 00:48:53,200 --> 00:48:58,280 in essence, if it was on EOS, it's how many eos coins you have. 546 00:48:58,280 --> 00:48:59,280 TADGE DRYJA: Yes, yes. 547 00:48:59,280 --> 00:49:07,329 AUDIENCE: So then there's probably some economics where people who are not miners will lend 548 00:49:07,329 --> 00:49:10,491 their stake to get a return. 549 00:49:10,491 --> 00:49:13,690 TADGE DRYJA: Basically, yeah. And a lot of coins, the majority of the coins, are held 550 00:49:13,690 --> 00:49:18,920 on different exchanges. And so that means the exchanges would possibly be able to then 551 00:49:18,920 --> 00:49:20,450 stake and get some kind of revenue. 552 00:49:20,450 --> 00:49:21,450 AUDIENCE: Right. So they would be taking their customer funds that are in wallets-- they 553 00:49:21,450 --> 00:49:23,230 would have to be, probably, hot wallets-- and then the exchanges would have a leg up 554 00:49:23,230 --> 00:49:25,910 to be the miners. 555 00:49:25,910 --> 00:49:30,849 TADGE DRYJA: Yes. 556 00:49:30,849 --> 00:49:34,511 AUDIENCE: Or a [INAUDIBLE]. 557 00:49:34,511 --> 00:49:38,460 TADGE DRYJA: Yeah. And so that's also an issue, that there's all different ways to mitigate. 558 00:49:38,460 --> 00:49:44,810 And you can say, oh, I'm in an exchange, but I get to sign and delegate my stake to someone 559 00:49:44,810 --> 00:49:49,630 else. And then I get some kind of revenue sharing from that. 560 00:49:49,630 --> 00:49:56,119 But yeah. It's also tricky, how do you incentivize it in terms of how much new coins get issued 561 00:49:56,119 --> 00:50:00,930 to the people staking? If it's zero, then there's no real incentive to do it. You could 562 00:50:00,930 --> 00:50:02,520 have a lot of different chain ports. 563 00:50:02,520 --> 00:50:10,630 If it's very high, then it's very, I don't know, Gini net curve goes way crazy because 564 00:50:10,630 --> 00:50:13,690 the rich really get richer. Because the more coins you have, you have an enormous amount 565 00:50:13,690 --> 00:50:19,200 of revenue. So you need a balance there that's also a bit difficult, economically. 566 00:50:19,200 --> 00:50:22,630 That's also a problem in proof of work. I feel like one of the big issues with Bitcoin 567 00:50:22,630 --> 00:50:28,140 is half the coins came out in the first four years, where hardly anyone was aware of it. 568 00:50:28,140 --> 00:50:33,700 And that makes people not want to adopt the system. Because it's like, well, wait. You 569 00:50:33,700 --> 00:50:38,740 guys just got all this coin for, basically, free. You were just running your computer 570 00:50:38,740 --> 00:50:42,640 in 2011. I'm not going to be part of that system. 571 00:50:42,640 --> 00:50:48,050 So I feel like it would have been nicer if it was more of an S curve and less of a log 572 00:50:48,050 --> 00:50:54,609 curve. Because then, maybe it would ramp up to 2015, and then lots of coins were coming 573 00:50:54,609 --> 00:50:55,609 out. But anyway. 574 00:50:55,609 --> 00:51:00,650 So Ripple or Stellar are sort of an extreme case of that, where all the coins were initially 575 00:51:00,650 --> 00:51:05,940 made by one entity. And so to me, I'm like, I don't want these. That's your money. You 576 00:51:05,940 --> 00:51:07,270 just made it up yourself. 577 00:51:07,270 --> 00:51:13,240 I don't know. It just feels like kids being like, I have a bazillion dollars, and I write 578 00:51:13,240 --> 00:51:17,780 a bazillion dollars. It's like, OK. Well, you just wrote that. I'm not going to honor 579 00:51:17,780 --> 00:51:18,780 that. 580 00:51:18,780 --> 00:51:26,820 Anyway. OK. So proof of stake, kind of interesting. Proof of space, there's a bunch of ideas here. 581 00:51:26,820 --> 00:51:36,910 Some of them-- SpaceMint was some people here. I know Bram Cohen, who is the author of BitTorrent, 582 00:51:36,910 --> 00:51:43,480 right-- he made BitTorrent whatever 10, almost 15 years ago now-- he's now working on some 583 00:51:43,480 --> 00:51:44,630 of these kind of things. 584 00:51:44,630 --> 00:51:50,490 He's working on a proof of space coin called Chia. And the idea, it's still similar to 585 00:51:50,490 --> 00:51:54,290 proof of work. But you're using some kind of memory or storage space, rather than your 586 00:51:54,290 --> 00:51:59,079 CPU. And the idea is the benefit is, well, maybe it doesn't use as much electricity. 587 00:51:59,079 --> 00:52:06,450 And also, from talking to Bram with his, he's saying there's much more dead storage space 588 00:52:06,450 --> 00:52:11,840 than dead CPU. So every computer has a CPU, but the CPU here is not that powerful. It 589 00:52:11,840 --> 00:52:17,320 can't really compete with ASICs. But lots of people have empty hard drive space. 590 00:52:17,320 --> 00:52:22,240 And you might have a terabyte of empty hard drive space, and one terabyte's as good as 591 00:52:22,240 --> 00:52:29,000 another. And it's also empty is what you need. Because you need to fill in space for these 592 00:52:29,000 --> 00:52:30,090 systems. 593 00:52:30,090 --> 00:52:35,099 And so if you're like, well, I'm AWS, I've got tons of hard drives-- right, but people 594 00:52:35,099 --> 00:52:41,260 are using them. So you're not able to then just fill it in for these kinds of systems-- 595 00:52:41,260 --> 00:52:45,310 well, to some extent. They do have a lot of slack, and they can probably do it. But several 596 00:52:45,310 --> 00:52:46,990 ideas. Some are pretty cool. 597 00:52:46,990 --> 00:52:51,960 So one example-- this is sort of an example idea. It's not fully fleshed out, but to give 598 00:52:51,960 --> 00:52:59,079 you an idea. So you buy a 10-terabyte drive, OK? You precompute 100 billion key pairs. 599 00:52:59,079 --> 00:53:03,119 And this takes a long time. And this is work, right? You're doing 100 billion computations 600 00:53:03,119 --> 00:53:08,609 of coming up with the random private key, multiplying by G, getting the pubkey. 601 00:53:08,609 --> 00:53:13,390 And you store it in a key-value store, like a database-- LevelDB or something-- on your 602 00:53:13,390 --> 00:53:19,490 hard drive. And the key is the pubkey. And the value is the private key. So you remember 603 00:53:19,490 --> 00:53:24,990 your key pairs. But you've sorted it in a way so that you can quickly go through the 604 00:53:24,990 --> 00:53:30,109 pubkeys, right? So you have logins, search time, some kind of binary tree-- whatever 605 00:53:30,109 --> 00:53:31,800 it is-- in your database. 606 00:53:31,800 --> 00:53:37,300 And so then, the idea is, to create the next block, you want the key closest to the current 607 00:53:37,300 --> 00:53:42,940 block hash can sign. So a valid proof of work-- you have some threshold, maybe-- a valid proof 608 00:53:42,940 --> 00:53:52,610 of work is whoever's got a key that's very close to this, they're able to sign. And those 609 00:53:52,610 --> 00:53:57,010 keys do not exist on the network prior to the signing procedure. They exist just hidden 610 00:53:57,010 --> 00:53:58,339 on people's hard drives. 611 00:53:58,339 --> 00:54:04,630 And so the idea is you could just try to keep computing keys till you find one and then 612 00:54:04,630 --> 00:54:08,339 sign with it. And that would just make it completely proof of work. So it is proof of 613 00:54:08,339 --> 00:54:12,099 work. But the idea is you can precompute. You can do all the work beforehand. 614 00:54:12,099 --> 00:54:17,280 And then you can use that precomputed proof of work later on and possibly multiple times. 615 00:54:17,280 --> 00:54:21,310 In practice, it's not going to be multiple times. Because you've got 100 billion, and 616 00:54:21,310 --> 00:54:24,530 you're never going to use the same key twice. 617 00:54:24,530 --> 00:54:28,701 The idea is everyone does this, right? So you have trillions, quadrillions, however 618 00:54:28,701 --> 00:54:33,200 many keys out there that everyone's generated. And every block that comes out, someone will 619 00:54:33,200 --> 00:54:39,220 say, ah, I was lucky, and I made a key that can now sign the next block. 620 00:54:39,220 --> 00:54:46,490 So it's work, but it's amortized over weeks, months, years. And it's basically how big 621 00:54:46,490 --> 00:54:51,099 is your storage. If you have a lot of storage, you can precompute a lot of this stuff and 622 00:54:51,099 --> 00:54:56,210 then use it. So it's kind of a cool system. 623 00:54:56,210 --> 00:55:01,609 There's other asterisks that actually get a little more complex because you need some 624 00:55:01,609 --> 00:55:09,980 timing mechanisms, as well. But I think it's a cool idea. Hard drives then maybe get more 625 00:55:09,980 --> 00:55:14,050 expensive instead of graphics cards getting more expensive. I don't know. 626 00:55:14,050 --> 00:55:18,690 But the idea is like, yeah. You use the work but later on. So I don't know. Any questions 627 00:55:18,690 --> 00:55:23,720 about that one? Kind of cool. There's a SpaceMint-- it's a cool paper-- about how to do this cryptographically. 628 00:55:23,720 --> 00:55:28,940 And then Chia is another one doing this kind of idea. I like it because it doesn't really 629 00:55:28,940 --> 00:55:33,849 change the assumptions of proof of work, right? It is still a form of proof of work. But instead 630 00:55:33,849 --> 00:55:38,580 of burning electricity, you're using hard drives. Kind of cool. 631 00:55:38,580 --> 00:55:45,339 AUDIENCE: Wouldn't you still have the same issues, like you'd have to have ASICs just 632 00:55:45,339 --> 00:55:48,440 filling racks and racks and racks of hard drives for keys. Is it different? 633 00:55:48,440 --> 00:55:53,099 TADGE DRYJA: You already have that, right? There's server farms where they're just storage 634 00:55:53,099 --> 00:55:56,670 farms, and they just have tons of hard drives. So that's already a thing. 635 00:55:56,670 --> 00:56:01,940 AUDIENCE: But I'm saying it isn't any different. You'd still be-- it would be [INAUDIBLE]-- 636 00:56:01,940 --> 00:56:06,890 TADGE DRYJA: I guess the idea is the economies of scale are not quite as bad in that hard 637 00:56:06,890 --> 00:56:11,260 drives are already, basically, optimal at doing this. And if you can make a system that's 638 00:56:11,260 --> 00:56:15,001 better at doing this, you've just made a better hard drive, which, hey, great. You made a 639 00:56:15,001 --> 00:56:20,751 better hard drive. Everyone can use it. So I guess the idea is it's not as specific because 640 00:56:20,751 --> 00:56:24,171 it's just, hey, store a bunch of data and then [? seq ?] quickly through it. 641 00:56:24,171 --> 00:56:28,380 AUDIENCE: It still seems CPU-bound, right, compute-bound. 642 00:56:28,380 --> 00:56:34,770 TADGE DRYJA: No. Once you generate this-- OK, generating this is compute-bound, right? 643 00:56:34,770 --> 00:56:39,089 You need to populate your 10 terabyte drive. But that might only take a few hours, right? 644 00:56:39,089 --> 00:56:45,740 To make 100 billion key pairs, I'm guessing less than a day, right? Yeah. And you can 645 00:56:45,740 --> 00:56:50,920 do that in parallel. So you make it. And then once you've made it, you leave it there. And 646 00:56:50,920 --> 00:56:52,569 then you're going to be able to mine with that forever. 647 00:56:52,569 --> 00:56:59,530 AUDIENCE: But see, the winner would be whoever can fill the most number of keys per second 648 00:56:59,530 --> 00:57:00,530 going forward. 649 00:57:00,530 --> 00:57:04,930 TADGE DRYJA: But you need something to fill. I think the hard drive cost is much higher 650 00:57:04,930 --> 00:57:11,450 than the cost to fill it, right? Because a 10 terabyte hard drive is going to be, like, 651 00:57:11,450 --> 00:57:15,970 $200. And with a cheap CPU, you can fill a 10 terabyte hard drive every few hours. So 652 00:57:15,970 --> 00:57:19,819 yeah, the CPU is a factor, but I think it's going to be smaller. Yeah? 653 00:57:19,819 --> 00:57:29,060 AUDIENCE: At least from what I understand about SpaceMint, the idea is to make it not 654 00:57:29,060 --> 00:57:34,609 I/O bound [INAUDIBLE]. So if I have a better or faster hard drive, that's not [INAUDIBLE]. 655 00:57:34,609 --> 00:57:35,609 It's just [? another ?] space. 656 00:57:35,609 --> 00:57:39,690 TADGE DRYJA: Because yeah. This is just a seq, right? And even a crummy hard drive, 657 00:57:39,690 --> 00:57:44,660 you just read through your binary trainer. You're like, oh, found it. 658 00:57:44,660 --> 00:57:48,210 AUDIENCE: I think the point is that you're only supposed to do one with those pub [INAUDIBLE]. 659 00:57:48,210 --> 00:57:49,210 AUDIENCE: Yes. [INAUDIBLE]. 660 00:57:49,210 --> 00:57:51,460 TADGE DRYJA: So you look at, OK, here's the current block hash. What do I have that's 661 00:57:51,460 --> 00:57:55,050 close? Seq to that on my drive. Nope. I'm not going to win this one. OK. Let someone 662 00:57:55,050 --> 00:57:59,349 else do it. Or you seq, and you find it. You're like, hey, cool. I can sign. Yeah? 663 00:57:59,349 --> 00:58:04,490 AUDIENCE: Is this also known as proof of space and time? 664 00:58:04,490 --> 00:58:11,950 TADGE DRYJA: Yeah. So in Chia, they add this time component, which I'm not 100% clear on 665 00:58:11,950 --> 00:58:17,430 how it works. It's changed a little bit. But the idea of a time beacon is you want some 666 00:58:17,430 --> 00:58:24,380 function that cannot be parallelized so that if you have 100 computers doing it, it's not 667 00:58:24,380 --> 00:58:28,980 going to be any faster than one computer doing it. So basically, whoever's got the fastest 668 00:58:28,980 --> 00:58:35,730 single CPU will always win this. And that can be a time beacon for these space things. 669 00:58:35,730 --> 00:58:36,730 Yeah? 670 00:58:36,730 --> 00:58:37,730 AUDIENCE: Once you start to have a lot of storage, if you're in a search will find [INAUDIBLE], 671 00:58:37,730 --> 00:58:38,730 do you kind of go back to-- you're almost getting hurt. [INAUDIBLE] So what I'm saying, 672 00:58:38,730 --> 00:58:42,510 you're just doing the same thing again? 673 00:58:42,510 --> 00:58:59,000 TADGE DRYJA: I think that's a [INAUDIBLE]. If you have tons of hard drives, and you want 674 00:58:59,000 --> 00:59:04,790 tons of key values, and you just want to find one or find the closest match, you can do 675 00:59:04,790 --> 00:59:08,250 that in log n time, even over a whole data center. Google, you just search, and it's 676 00:59:08,250 --> 00:59:12,900 like, hey. It comes up in a fraction of a second. 677 00:59:12,900 --> 00:59:17,740 So that's doable. You need good software, and you need a good infrastructure to do it. 678 00:59:17,740 --> 00:59:21,340 But I think it's doable. It scales pretty well, I think. 679 00:59:21,340 --> 00:59:25,819 But yeah, it has the same issues where you just end up with people buying a whole bunch 680 00:59:25,819 --> 00:59:31,180 of hard drives. And what are the economies of scale there? There's arguments that it 681 00:59:31,180 --> 00:59:35,160 might be better than the economies of scale with, like, ASICs, that we heard about on 682 00:59:35,160 --> 00:59:43,370 Monday. Maybe not. I don't know. We'll see if this takes off. It's fairly new. It's an 683 00:59:43,370 --> 00:59:44,631 idea that's been talked about for a few years. 684 00:59:44,631 --> 00:59:48,240 AUDIENCE: It's [INAUDIBLE] space. And they've been around for years in this [INAUDIBLE]. 685 00:59:48,240 --> 00:59:57,560 TADGE DRYJA: OK. Well, so there's different ideas. I don't know. It seems like one of 686 00:59:57,560 --> 01:00:04,410 the more interesting. There's cool math and cool crypto involved. OK. So it'll work but 687 01:00:04,410 --> 01:00:05,430 amortized. 688 01:00:05,430 --> 01:00:12,630 So and perennial MIT favorite, IOTA, they use a directed acyclic graph. And now, a chain 689 01:00:12,630 --> 01:00:19,380 is also a DAG. Because it's directed. There's no cycles. It's a graph. But it's a pretty 690 01:00:19,380 --> 01:00:24,180 simple one. But the ideas have multiple parents, right? 691 01:00:24,180 --> 01:00:31,651 So if you have a block, instead of just pointing to one, you could say, well, now, this can 692 01:00:31,651 --> 01:00:37,050 happen in Bitcoin, right, where you've got two blocks, both supporting the same thing. 693 01:00:37,050 --> 01:00:42,230 But this cannot happen in Bitcoin, where you say, oh, I'm coming off, and I'm referring 694 01:00:42,230 --> 01:00:47,180 to both of these. But in a directed acyclic graph, you can do that. 695 01:00:47,180 --> 01:00:53,280 So Ethereum actually does it. I think Joe Bonneau was mentioning that. And so what happens 696 01:00:53,280 --> 01:00:57,441 is you endorse one as the correct one and one as the uncle. So you're saying, no, this 697 01:00:57,441 --> 01:01:02,910 is the real one. But I also saw this one. And give this one a little bit of money, right, 698 01:01:02,910 --> 01:01:06,930 maybe not the whole reward they were hoping for. But they get something. 699 01:01:06,930 --> 01:01:13,369 And so then, something like IOTA says, OK, we have lots. And every node points to two 700 01:01:13,369 --> 01:01:18,010 previous. And so you get this whole map. They could even point to different heights. So 701 01:01:18,010 --> 01:01:30,030 I can point to here and here. I don't really know why you'd do this. 702 01:01:30,030 --> 01:01:33,950 So there's some ways it could reduce latency, right? So one of the trade-offs in Bitcoin 703 01:01:33,950 --> 01:01:41,480 is 10-minute block time seems fairly arbitrary. It's kind of slow. Latency-- people don't 704 01:01:41,480 --> 01:01:44,640 like latency because they have to wait. Fine. 705 01:01:44,640 --> 01:01:48,980 The more important metric, I think, is that it leads to miner centralization and miner 706 01:01:48,980 --> 01:01:56,089 pools. Because if there's only 144 blocks a day, like in Bitcoin, if you have a millionth 707 01:01:56,089 --> 01:02:00,339 of the hash power of the network, you're just never going to find anything, right? 708 01:02:00,339 --> 01:02:04,309 If you're just mining on your own, over the course of a year, you're probably not going 709 01:02:04,309 --> 01:02:07,900 to find a single block, and you'll have wasted all of that effort. So instead, you join a 710 01:02:07,900 --> 01:02:11,890 pool and try to pool with other people to distribute those rewards. 711 01:02:11,890 --> 01:02:17,880 However, if there's, like in Ethereum, a block every 15 seconds, and there's millions of 712 01:02:17,880 --> 01:02:22,050 blocks that come out, if you have a millionth of the hash power, you might find a block. 713 01:02:22,050 --> 01:02:26,540 The blocks have smaller rewards, but chopping it up more finely is a nice way to do it. 714 01:02:26,540 --> 01:02:32,630 So like P2Pool, which you were gone, is a way to try to make that. And it's important 715 01:02:32,630 --> 01:02:36,580 to get it more decentralized. But it's hard. Yeah? 716 01:02:36,580 --> 01:02:38,000 AUDIENCE: P2Pool does that? 717 01:02:38,000 --> 01:02:45,910 TADGE DRYJA: Yeah. Yeah. P2Pool sort of does this as a layer on top. So it could help latency. 718 01:02:45,910 --> 01:02:51,030 And then, it could help reduce the amount of orphans in the blockchain, which then helps 719 01:02:51,030 --> 01:02:55,250 miner centralization. So there are interesting ideas for it. 720 01:02:55,250 --> 01:02:59,210 But it doesn't help scalability at all, right? It actually hurts scalability. Because now 721 01:02:59,210 --> 01:03:04,560 I have to keep track of all these things instead of just one chain. And I'm going to have to 722 01:03:04,560 --> 01:03:08,720 keep track of all the data, anyway, if I've got the UTXO set. I can't just ignore parts 723 01:03:08,720 --> 01:03:09,720 of it. 724 01:03:09,720 --> 01:03:14,730 So it doesn't help scalability at all. And in the case of IOTA, their custom ternary 725 01:03:14,730 --> 01:03:19,170 hash functions also don't help much, either. So that was what we wrote about last year. 726 01:03:19,170 --> 01:03:23,450 They made all their own weird stuff. I don't know. 727 01:03:23,450 --> 01:03:29,131 So there are interesting ideas between directly acyclic graphs. But it feels like when they 728 01:03:29,131 --> 01:03:33,780 say, hey, this is more scalable, I get very suspicious. Because it doesn't seem to help 729 01:03:33,780 --> 01:03:36,220 scalability. It does possibly help some other things. Yeah? 730 01:03:36,220 --> 01:03:40,260 AUDIENCE: Is, effectively, Bitcoin refreshing [? test? ?] They've made it so every block 731 01:03:40,260 --> 01:03:46,700 has min difficulty. And so the transactions are instant because, right, it doesn't change-- 732 01:03:46,700 --> 01:03:48,480 TADGE DRYJA: What, in IOTA, or in-- 733 01:03:48,480 --> 01:03:54,030 AUDIENCE: In any of these stack coins. So it doesn't cost much to make a new block and 734 01:03:54,030 --> 01:04:00,819 make a transaction. And if everyone's competing to do that, then they're just another ton 735 01:04:00,819 --> 01:04:01,819 of orphans, and [INAUDIBLE]. 736 01:04:01,819 --> 01:04:04,260 TADGE DRYJA: Yeah, yeah. So also, in the case of IOTA, the idea is-- well, they don't call 737 01:04:04,260 --> 01:04:11,090 it this-- but it's the equivalent of saying every block must have one and only one transaction. 738 01:04:11,090 --> 01:04:15,599 The transactions themselves have proof of work on them, and they point to each other, 739 01:04:15,599 --> 01:04:20,740 which, basically, is the same as blocks have one transaction, and you do the work yourself 740 01:04:20,740 --> 01:04:22,440 instead of paying a miner to do it. 741 01:04:22,440 --> 01:04:28,010 I think that's not a great deal. And they say that that means there's no fees. I think 742 01:04:28,010 --> 01:04:32,240 there's still fees. Because you're just doing the work yourself. I think that's equivalent 743 01:04:32,240 --> 01:04:37,770 to saying, there is a refrigerator at Home Depot that doesn't use electricity. So hey, 744 01:04:37,770 --> 01:04:42,160 it's electricity-free. But there's a crank on the back, and you have to crank it to make 745 01:04:42,160 --> 01:04:43,920 the refrigerator cold. 746 01:04:43,920 --> 01:04:48,210 Yeah, you could make a refrigerator that way. I don't think people would want it. You're 747 01:04:48,210 --> 01:04:52,830 still doing the work. You just have to crank it instead of plugging in it. So the idea 748 01:04:52,830 --> 01:04:56,020 of you don't have to pay miners a fee to get into a block because you just mine the block 749 01:04:56,020 --> 01:05:00,800 yourself or, in this case, you mine the transaction yourself. Doesn't seem that useful. 750 01:05:00,800 --> 01:05:09,720 Anyway, so IOTA's fun. We talked about them a while ago. OK. Last one, and it's fun-- 751 01:05:09,720 --> 01:05:16,040 proof of idle. It's an old idea that I wrote up four years ago, almost. It probably doesn't 752 01:05:16,040 --> 01:05:19,099 actually work that well. But a lot of these things don't work that well. Even if it works, 753 01:05:19,099 --> 01:05:22,170 it would just move the costs from opex to capex. 754 01:05:22,170 --> 01:05:27,750 But what you do is you prove that you're not mining, and you get paid. And the other fun 755 01:05:27,750 --> 01:05:32,470 thing about this is it led to some of the ideas in Lightning Network. So the idea is, 756 01:05:32,470 --> 01:05:36,910 in Bitcoin, the difficulty adjusts so that blocks come out every 10 minutes, right? Every 757 01:05:36,910 --> 01:05:40,979 2016 blocks, you look at the timestamps, adjust the difficulty. 758 01:05:40,979 --> 01:05:45,270 So new miners coming in make it harder for the existing miners. So if you're a miner, 759 01:05:45,270 --> 01:05:49,619 you really don't want anyone else to start joining this network and mining. You really 760 01:05:49,619 --> 01:05:54,240 like it as it is. So if you have the first ASICs, you're good, and you don't want everyone 761 01:05:54,240 --> 01:05:55,240 to come in. 762 01:05:55,240 --> 01:06:00,349 And this is why so many people buy mining equipment and lose money. Because they look 763 01:06:00,349 --> 01:06:05,440 at the current difficulty, and they say, hey, here's this device. Here's how much electricity 764 01:06:05,440 --> 01:06:07,040 it uses, how many coins it generates. 765 01:06:07,040 --> 01:06:10,859 This is profitable. I'm going to buy this thing. And what they don't realize is that 766 01:06:10,859 --> 01:06:15,869 by the time they actually get it, or maybe a few weeks later, the difficulty is doubled. 767 01:06:15,869 --> 01:06:20,160 And now it's making half as many coins for the exact same amount of electricity. 768 01:06:20,160 --> 01:06:27,230 So yeah. And that's a fairly unique property of bitcoin that's not the case in, say, gold 769 01:06:27,230 --> 01:06:33,359 mining or other extractive industries. There's some kind of curve in gold mining where if 770 01:06:33,359 --> 01:06:38,290 you pay twice as much money to have twice as many people dig holes and mine gold, you 771 01:06:38,290 --> 01:06:43,390 won't get twice as much gold. Maybe you'll only get 10% more gold. But you will get some 772 01:06:43,390 --> 01:06:49,529 more, right? And if you drill for oil, you pay twice as much, you'll get some more. But 773 01:06:49,529 --> 01:06:50,529 yeah? 774 01:06:50,529 --> 01:06:52,690 AUDIENCE: And it's worse than that. Because you're still obligated to mine. Because making 775 01:06:52,690 --> 01:06:57,510 $0.50, they're making half as much as they're going to make, it's still better than making 776 01:06:57,510 --> 01:06:58,510 nothing. 777 01:06:58,510 --> 01:07:02,960 TADGE DRYJA: Yeah. So that happens, too. So yeah, in Bitcoin, two times the mining leads 778 01:07:02,960 --> 01:07:08,890 to 1X the coins mined, right? There is zero marginal product of labor in this system, 779 01:07:08,890 --> 01:07:13,849 which is weird and counterintuitive and doesn't really exist in normal life. 780 01:07:13,849 --> 01:07:20,150 Most things have some kind of sublinear curve, where, yeah, the first low-hanging fruit-- 781 01:07:20,150 --> 01:07:24,599 if you're mining coal, and you start in Pittsburgh, and it's just sitting there on the hill, and 782 01:07:24,599 --> 01:07:27,890 you're like, hey, that was easy. And then, eventually, you have to start open pit mines 783 01:07:27,890 --> 01:07:33,660 and digging holes. And it's expensive, and you don't get as good. But you still, if you 784 01:07:33,660 --> 01:07:37,559 double your effort, you're going to get some extra stuff out. 785 01:07:37,559 --> 01:07:42,460 Then again, there might be cases, I'm sure, in economics, where eventually, it goes negative, 786 01:07:42,460 --> 01:07:46,430 where if you continue adding members to an organization, eventually, they're just like 787 01:07:46,430 --> 01:07:51,079 deadweight, and they make it less efficient or something. But in Bitcoin, it doesn't matter 788 01:07:51,079 --> 01:07:54,540 how much you mine. You always get the same number of coins. 789 01:07:54,540 --> 01:08:01,119 So the obvious thing there is, well, we should all just stop mining. And then we'll have 790 01:08:01,119 --> 01:08:07,839 zero electricity usage, and we'll still get the same amount of coins. 791 01:08:07,839 --> 01:08:13,500 AUDIENCE: The example is Nobel prizes. It doesn't matter how many academics chase them, 792 01:08:13,500 --> 01:08:14,500 there's a unique number [INAUDIBLE]. 793 01:08:14,500 --> 01:08:17,290 TADGE DRYJA: OK, yeah. Yeah, that's another. Yeah. However good the science is, you just 794 01:08:17,290 --> 01:08:24,870 get one Nobel Prize. So OK. So let's say there's two miners. And there's, obviously, more. 795 01:08:24,870 --> 01:08:27,330 And they're each mining with 2 gigawatts. 796 01:08:27,330 --> 01:08:34,149 And they both think, well, wait. If we both turned our mining down 5%, we'd still get 797 01:08:34,149 --> 01:08:40,380 the same amount of coins, but we'd be using 5% less electricity. We should have a meeting, 798 01:08:40,380 --> 01:08:43,549 maybe some kind of cartel. 799 01:08:43,549 --> 01:08:50,359 So this is sort of OPEC, right? This is a classic cartel. If we all restrict our output, 800 01:08:50,359 --> 01:08:55,870 we can raise prices and reduce our costs. In Bitcoin, it's the perfect cartel environment. 801 01:08:55,870 --> 01:09:02,020 Because if we all reduce our output, we get the same output, sort of, right? If we all 802 01:09:02,020 --> 01:09:06,750 turned down mining 50%, we all still get the same number of coins. The network still works 803 01:09:06,750 --> 01:09:14,690 fine. Maybe nobody even knows we're doing this. This is ideal cartel scenario. 804 01:09:14,690 --> 01:09:19,809 Problem for cartels, generally, is that cartels are hard to maintain, especially when there's 805 01:09:19,809 --> 01:09:25,220 not a lot of trust. Because there's so much profit in defecting and going against the 806 01:09:25,220 --> 01:09:29,969 rules of the cartel. And OPEC has this all the time, where one of the OPEC countries 807 01:09:29,969 --> 01:09:34,299 says, we're just going to pump a bunch of oil and sell it. Because everyone else reducing 808 01:09:34,299 --> 01:09:38,969 their output raises the prices. And now we can sell more with higher prices. 809 01:09:38,969 --> 01:09:43,890 So in this kind of system, if all the miners said, hey, let's all turn down 50%, the one 810 01:09:43,890 --> 01:09:49,819 miner who then mines at full blast is going to make a lot of coins. So this is the problem. 811 01:09:49,819 --> 01:09:51,899 In Bitcoin, nobody trusts anyone, right? 812 01:09:51,899 --> 01:09:57,550 So the solution here is trustless collusion. And in the papers, I was like, well, is it 813 01:09:57,550 --> 01:10:00,960 collusion or cooperation? They both sort of mean the same thing. And collusion is just 814 01:10:00,960 --> 01:10:07,130 a bad word for cooperation. Cooperation's good. It's on Sesame Street. 815 01:10:07,130 --> 01:10:15,390 OK. So the basic system is Alice pays Bob not to mine. So first thing, Alice needs to 816 01:10:15,390 --> 01:10:19,400 prove that Bob can mine. Because she doesn't want to pay Bob if Bob doesn't have any mining 817 01:10:19,400 --> 01:10:25,890 capacity that he's taking offline. She only wants to pay Bob for having the ability to 818 01:10:25,890 --> 01:10:27,390 mine and then not doing. 819 01:10:27,390 --> 01:10:33,470 So A posts a block header at a specified time and says, OK, B, mine for 10 seconds, and 820 01:10:33,470 --> 01:10:39,420 give me your 100 best shots, right? So in Bitcoin, you have this fixed difficulty. And 821 01:10:39,420 --> 01:10:43,949 you just say, OK, anything below this block hash is valid. 822 01:10:43,949 --> 01:10:48,620 But you could make one where you say, hey, give me your best 100, and I can then extrapolate, 823 01:10:48,620 --> 01:10:53,860 or interpolate, from that what your hash rate is. And you can get pretty accurate. So they 824 01:10:53,860 --> 01:10:55,390 have to do some work, right? 825 01:10:55,390 --> 01:11:01,350 Bob does some work but for a brief period-- I don't know, 10 seconds. You don't want latency 826 01:11:01,350 --> 01:11:06,220 to be an issue, so maybe 10 seconds, maybe a minute-- whatever-- some small amount of 827 01:11:06,220 --> 01:11:10,350 work to prove that they have the capability to do the work. They respond with that. And 828 01:11:10,350 --> 01:11:13,850 Alice validates it and says, OK, you've got X amount of work capacity. 829 01:11:13,850 --> 01:11:19,750 Alice then creates a 2 of 2 multisig transaction and sends one bitcoin to this address and 830 01:11:19,750 --> 01:11:25,100 builds two transactions with Bob. This is sort of like, how Lightning Network looks, 831 01:11:25,100 --> 01:11:28,890 Lightning Channels. But this predates it by a year or two. 832 01:11:28,890 --> 01:11:33,711 So the idea is you've got this funding, and then you've got two transactions. They're 833 01:11:33,711 --> 01:11:41,150 both signed by both parties and held by both parties, although in practice the one that 834 01:11:41,150 --> 01:11:45,481 pays out to Alice, Bob doesn't really need to store. He doesn't like it. And the one 835 01:11:45,481 --> 01:11:47,340 that pays out to Bob, Alice doesn't need to store. 836 01:11:47,340 --> 01:11:52,130 But the idea is they have conflicting locktimes. So in the transaction header, you can have 837 01:11:52,130 --> 01:11:57,670 a locktime, say, OK, this transaction is only valid after this point. So the one that pays 838 01:11:57,670 --> 01:12:06,040 Alice is height plus 144. So the current height of the blockchain plus 144, well, that should 839 01:12:06,040 --> 01:12:08,920 take about a day, right? If blocks come out every 10 minutes, 144 blocks is one day. 840 01:12:08,920 --> 01:12:17,210 For Bob, Bob gets a coin with the current locktime plus 24 hours. So in Bitcoin, you 841 01:12:17,210 --> 01:12:24,330 can specify either Unix time or block height. And I think everything above 500 million is 842 01:12:24,330 --> 01:12:29,530 a time. Everything below 500 million is interpreted as a height, which means this whole system 843 01:12:29,530 --> 01:12:34,380 runs out in a couple thousand years. 844 01:12:34,380 --> 01:12:41,980 So this is a race, right? There's two transactions. One of them can be broadcast first, depending 845 01:12:41,980 --> 01:12:47,250 on how fast blocks come up. So if blocks come out very quickly, this will be valid first-- 846 01:12:47,250 --> 01:12:53,800 144 blocks. Maybe it only takes 20 hours, and these 144 blocks have come out. And Alice 847 01:12:53,800 --> 01:12:58,630 can post this transaction and get all of her money back, get her one coin back. 848 01:12:58,630 --> 01:13:05,390 However, if blocks come out slowly and, after 24 hours, only 120 blocks have come out, Bob 849 01:13:05,390 --> 01:13:09,640 can post this transaction first. And it will be valid and confirmed, and Bob gets the coin. 850 01:13:09,640 --> 01:13:16,380 So now Bob's incentives are, well, I'd like 144 blocks to take longer than 24 hours. Because 851 01:13:16,380 --> 01:13:18,520 then I'll get this coin. 852 01:13:18,520 --> 01:13:23,980 And Bob has the means to influence this, right? Bob's a miner. So Bob can say, well, I'll 853 01:13:23,980 --> 01:13:30,400 just mine less. And if I mine such that, in 24 hours, only 130 blocks come out, I get 854 01:13:30,400 --> 01:13:33,670 the coin. Cool, right? 855 01:13:33,670 --> 01:13:37,330 If blocks come out fast, on the other hand, Alice gets her money back. So Alice has no 856 01:13:37,330 --> 01:13:43,360 real risk here that Bob will run away with the money without doing his part of the job. 857 01:13:43,360 --> 01:13:50,309 So Bob can slow down his mining in order to get the bounty coins. If Alice estimates incorrectly 858 01:13:50,309 --> 01:13:58,989 how much profitability Bob has, Bob just keeps mining. Alice gets her money back. This collusion 859 01:13:58,989 --> 01:14:03,910 didn't occur, at very little cost, right? Bob had to prove a little bit. There's some 860 01:14:03,910 --> 01:14:06,640 coordination costs. But basically, nobody loses the money. 861 01:14:06,640 --> 01:14:12,250 So Alice can put whatever bounty she thinks is beneficial to her. OK, I'll pay you three 862 01:14:12,250 --> 01:14:16,719 coins not to mine as much. And you can chop this up. You can have a lot of different, 863 01:14:16,719 --> 01:14:22,110 smaller transactions and make a curve. If you mine a lot less, I'll pay you more-- things 864 01:14:22,110 --> 01:14:24,460 like that. 865 01:14:24,460 --> 01:14:36,410 Yeah. So that's the idea behind proof of idle. It feels like it might happen, to some extent, 866 01:14:36,410 --> 01:14:42,320 long-term. It feels sort of like nuclear weapons, where everyone's got them, but they don't 867 01:14:42,320 --> 01:14:44,340 really use them. They just threaten. 868 01:14:44,340 --> 01:14:48,050 So it feels like mining could be that kind of thing, where, well, we've all got all this 869 01:14:48,050 --> 01:14:54,800 mining capacity, but we just threaten each other with it, and we don't really mine. Because 870 01:14:54,800 --> 01:15:00,320 the mining's actually really expensive, and it's just the threat of mining that you need. 871 01:15:00,320 --> 01:15:05,480 And if someone tries to do, say, a 51% attack and reorg, the existing mining infrastructure 872 01:15:05,480 --> 01:15:10,360 can spin up and say, oh, no. You thought you were 51%. You were actually 5.1%. And we're 873 01:15:10,360 --> 01:15:15,510 90% offline. And we all come back online and reorg you out. 874 01:15:15,510 --> 01:15:21,929 It's an interesting-- I think it's a fun idea. In practice, it doesn't work now because it's 875 01:15:21,929 --> 01:15:28,719 mostly capex. So this doesn't help if your main constraint is building the chips, which 876 01:15:28,719 --> 01:15:34,590 it sounds like it still is, from David's talk on Monday, right? Yeah, you need to get electricity, 877 01:15:34,590 --> 01:15:39,640 sure. But also, the really big problem is getting a supply of all these chips. 878 01:15:39,640 --> 01:15:44,469 And this would just exacerbate that. This would make it so that I don't even need electricity. 879 01:15:44,469 --> 01:15:47,170 I just get the chips. I don't really care how much I'm paying in electricity because 880 01:15:47,170 --> 01:15:51,470 most of the time, my chips sit off. I just need to occasionally prove I have them and 881 01:15:51,470 --> 01:15:55,650 have the ability to mine with them. 882 01:15:55,650 --> 01:16:02,309 So it wouldn't solve the problem of proof of work in terms of people spending tons of 883 01:16:02,309 --> 01:16:09,620 money on it. But it would move it towards less electricity usage, more fabrication plant 884 01:16:09,620 --> 01:16:14,280 usage. Is that a good thing? Is that a bad? I don't know. 885 01:16:14,280 --> 01:16:20,910 And in certain cases, it may be that it saves people money. It may be that, hey, if we can 886 01:16:20,910 --> 01:16:26,860 collude in this way, actually, we save money. And then we can use it to build more hash 887 01:16:26,860 --> 01:16:28,920 power. 888 01:16:28,920 --> 01:16:34,610 So this might happen. I was sort of convinced in 2014. I'm like, oh, I think this is going 889 01:16:34,610 --> 01:16:40,980 to happen. I also thought that it would become predominantly opex in 2015 or '16. And it 890 01:16:40,980 --> 01:16:48,780 just didn't-- not even close. So who knows? But it's, I don't know, kind of a fun idea. 891 01:16:48,780 --> 01:16:55,760 OK. So in general, lots of new ideas out there. Proof of work does seem to work. But I think 892 01:16:55,760 --> 01:17:01,950 one of the big issues is it's not really compatible with the Kurzweil/Roddenberry future idea. 893 01:17:01,950 --> 01:17:08,570 Has anyone read Ray Kurzweil, like, Age of Spiritual Machines? 894 01:17:08,570 --> 01:17:14,059 It's sort of this futurey AI is going to make everything great, and we're all going to live 895 01:17:14,059 --> 01:17:17,860 forever, and computers are going to be our best friends, and we're going to take over 896 01:17:17,860 --> 01:17:24,960 the universe. And Gene Roddenberry of Star Trek is sort of a popular, not quite as crazy-- 897 01:17:24,960 --> 01:17:26,739 maybe just as crazy-- view of that. 898 01:17:26,739 --> 01:17:32,260 In Star Trek, they don't have money. They just sort of explore the universe and make 899 01:17:32,260 --> 01:17:35,790 the world a better place and stuff like that. And it's like, cool. And there's a lot of 900 01:17:35,790 --> 01:17:43,230 people who are into technology and research who are, maybe not consciously, but identify 901 01:17:43,230 --> 01:17:48,940 with these ideas, like, yeah, we're making the world a better place. Computers are going 902 01:17:48,940 --> 01:17:50,650 to help people, and it's going to be great. 903 01:17:50,650 --> 01:17:55,370 And I think one of the issues with Bitcoin and proof of work is it doesn't fit into that, 904 01:17:55,370 --> 01:18:00,179 right? It's sort of dystopian, in a way. And then, it's like, wait. We're going to have 905 01:18:00,179 --> 01:18:08,050 giant server farms performing SHA256 for the next 50 years? Like how? How does the benevolent 906 01:18:08,050 --> 01:18:13,100 AI fit into this system? 907 01:18:13,100 --> 01:18:19,320 So that's one of the reasons people-- the proof of idle idea was-- I was at University 908 01:18:19,320 --> 01:18:25,660 of Virginia, and Avi Shalot, who's now at Northeastern, he was like, I hate Bitcoin. 909 01:18:25,660 --> 01:18:31,590 Because the whole point of SHA256 is that you can't find collisions. That was the design-- 910 01:18:31,590 --> 01:18:33,510 collision-resistant hash function. 911 01:18:33,510 --> 01:18:37,760 And now, you've built this giant system, which the whole point of the system is to find collisions. 912 01:18:37,760 --> 01:18:41,679 Like, ah. That's the opposite of what it was supposed to be. And so it was just sort of 913 01:18:41,679 --> 01:18:45,460 inelegant and ugly. And that was where I'm like, well, maybe you don't really have to 914 01:18:45,460 --> 01:18:49,480 mine that much. And so I wrote this thing about proof of idle. 915 01:18:49,480 --> 01:18:53,100 But anyway, that's one of the issues that people have with proof of work. And that's, 916 01:18:53,100 --> 01:18:58,880 I think, one of the big motivating factors for all this other research into different 917 01:18:58,880 --> 01:19:04,370 consensus algorithms. And further research is required, maybe. 918 01:19:04,370 --> 01:19:09,409 The interesting thing is a lot of the people doing proof of work are fine with it, right? 919 01:19:09,409 --> 01:19:15,800 So like David, Monday, he's not interested in proof of stake. Despite the proof of work 920 01:19:15,800 --> 01:19:19,100 ecosystem being so crazy, he's just like, nope, this is what I'm doing. 921 01:19:19,100 --> 01:19:24,400 So none of the miners are interested-- I mean, miners, their job is to mine. So they're usually 922 01:19:24,400 --> 01:19:29,200 not interested in proof of stake. And then Bitcoin, in general, a lot of it's like, no, 923 01:19:29,200 --> 01:19:33,410 this seems to work. We're OK with it. This is the cost we're willing to bear. 924 01:19:33,410 --> 01:19:37,920 But other people want to do other systems. So further research is required, or not. But 925 01:19:37,920 --> 01:19:42,660 it's happening. There's tons of research into different consensus mechanisms. I would say 926 01:19:42,660 --> 01:19:48,120 in academic research, that's the biggest thing. 927 01:19:48,120 --> 01:19:53,390 What I would like to see more of is more academic research in proof of work. Because there's 928 01:19:53,390 --> 01:19:58,650 a little bit, but there's all sorts of interesting things with proof of work where it's like, 929 01:19:58,650 --> 01:20:02,739 oh, something like proof of idle or something like the stuff David was talking about on 930 01:20:02,739 --> 01:20:05,650 Monday. There's not much economics research into this. 931 01:20:05,650 --> 01:20:09,450 And I think it's a really interesting question, where you've got, hey, I've got a device that 932 01:20:09,450 --> 01:20:15,230 prints money, and I want to sell it to you. What? How does that work in terms of economics? 933 01:20:15,230 --> 01:20:20,570 How much should I sell it for? How much should I buy it for-- things like that. So there's 934 01:20:20,570 --> 01:20:24,380 a lot of new research into new proof of stake, different consensus mechanisms, economics 935 01:20:24,380 --> 01:20:30,750 that way and not as much into new forms or how proof of work works, which I think is, 936 01:20:30,750 --> 01:20:32,100 actually, really interesting.