1 00:00:00,790 --> 00:00:03,160 The following content is provided under a Creative 2 00:00:03,160 --> 00:00:04,550 Commons license. 3 00:00:04,550 --> 00:00:06,760 Your support will help MIT OpenCourseWare 4 00:00:06,760 --> 00:00:10,850 continue to offer high-quality educational resources for free. 5 00:00:10,850 --> 00:00:13,390 To make a donation, or to view additional materials 6 00:00:13,390 --> 00:00:17,350 from hundreds of MIT courses, visit MIT OpenCourseWare 7 00:00:17,350 --> 00:00:18,250 at ocw.mit.edu. 8 00:00:22,310 --> 00:00:25,100 TADGE DRYJA: And that brings us to today's lecture, 9 00:00:25,100 --> 00:00:28,550 which is also something I was not as familiar with. 10 00:00:28,550 --> 00:00:30,303 So sort of a disclaimer-- 11 00:00:30,303 --> 00:00:31,970 I might have gotten little things wrong, 12 00:00:31,970 --> 00:00:33,990 or it might not be quite as clear. 13 00:00:33,990 --> 00:00:36,098 But do ask questions. 14 00:00:36,098 --> 00:00:38,390 So if it's stuff like Lightning Network or Discreet Log 15 00:00:38,390 --> 00:00:40,307 Contracts, well, for me-- that's sort of easy, 16 00:00:40,307 --> 00:00:42,740 because I know it really well. 17 00:00:42,740 --> 00:00:45,110 This stuff is things I've known about, 18 00:00:45,110 --> 00:00:49,170 but I've never really went as into the details. 19 00:00:49,170 --> 00:00:51,988 So it's a little bit like, OK, figure 20 00:00:51,988 --> 00:00:54,530 it out well enough to explain it rather than just well enough 21 00:00:54,530 --> 00:00:56,235 to understand how it works. 22 00:00:56,235 --> 00:00:58,610 So the basic idea is you want to hide the output amounts. 23 00:00:58,610 --> 00:01:03,380 So we saw last week how looking at output amounts 24 00:01:03,380 --> 00:01:07,170 can deanonymize and let you link a lot of different things. 25 00:01:07,170 --> 00:01:08,910 And so we'll look at how to do that. 26 00:01:08,910 --> 00:01:10,850 How do we hide output amounts? 27 00:01:10,850 --> 00:01:12,520 And so we'll talk about commitments. 28 00:01:12,520 --> 00:01:15,020 So first, we'll talk about the reasons why and how to do it. 29 00:01:15,020 --> 00:01:17,360 Then we'll talk about the definition of commitments. 30 00:01:17,360 --> 00:01:19,520 What is a commitment in cryptography? 31 00:01:19,520 --> 00:01:21,770 And then we'll talk about Pedersen commitments, 32 00:01:21,770 --> 00:01:23,420 and then we'll talk about range proofs 33 00:01:23,420 --> 00:01:25,070 and put it together to get what's 34 00:01:25,070 --> 00:01:28,010 called "confidential transactions," which 35 00:01:28,010 --> 00:01:31,880 is a vaguely confidential transaction-- it just means 36 00:01:31,880 --> 00:01:36,010 the output amounts are secret. 37 00:01:36,010 --> 00:01:39,100 So interrupt with any questions at any point of the way 38 00:01:39,100 --> 00:01:40,950 if something's not clear. 39 00:01:40,950 --> 00:01:43,480 So coinjoin-- last time we talked 40 00:01:43,480 --> 00:01:46,757 about combining transactions with other people 41 00:01:46,757 --> 00:01:48,840 where you have your input-- they have their input. 42 00:01:48,840 --> 00:01:50,930 You have your output-- they have their output. 43 00:01:50,930 --> 00:01:55,540 And if you shuffle the ordering of the inputs and outputs, 44 00:01:55,540 --> 00:01:58,270 it might not be clear who's sending what where. 45 00:01:58,270 --> 00:02:00,550 You're aggregating it, and in the process, 46 00:02:00,550 --> 00:02:03,640 you're losing information, because no one 47 00:02:03,640 --> 00:02:05,940 gets to see the border lines between-- hey, 48 00:02:05,940 --> 00:02:08,440 this is one transaction-- this is another transaction-- it's 49 00:02:08,440 --> 00:02:11,740 all in the same transaction, so you can't really tell. 50 00:02:11,740 --> 00:02:13,840 But one issue-- and a really big issue-- 51 00:02:13,840 --> 00:02:16,720 was that the output amounts can often reveal 52 00:02:16,720 --> 00:02:18,460 who's sending what where. 53 00:02:18,460 --> 00:02:21,190 So in this example-- 54 00:02:21,190 --> 00:02:23,680 well, maybe I don't know who's A, 55 00:02:23,680 --> 00:02:25,420 who's B, who's C, who's D-- these all 56 00:02:25,420 --> 00:02:29,320 look like uniformly, random addresses or pubkeys. 57 00:02:29,320 --> 00:02:31,510 But if I see an input with 10 coins-- 58 00:02:31,510 --> 00:02:33,348 an input with 2 coins, and then an output 59 00:02:33,348 --> 00:02:35,140 with 2 coins, and an output with 10 coins-- 60 00:02:35,140 --> 00:02:39,250 well, there's probably something like this going on. 61 00:02:39,250 --> 00:02:41,470 Why else would you do this? 62 00:02:41,470 --> 00:02:44,380 If you were trying to send 2 coins somewhere, 63 00:02:44,380 --> 00:02:46,520 why even involve this 10-coin input? 64 00:02:46,520 --> 00:02:49,390 Why not just say 2 coins to 2 coins, and you're done? 65 00:02:49,390 --> 00:02:53,890 So if the goal is to obscure the transaction graph 66 00:02:53,890 --> 00:02:56,140 and have better anonymity because no one can 67 00:02:56,140 --> 00:02:58,790 tell what's going where-- well, this doesn't really work. 68 00:02:58,790 --> 00:03:00,392 I think it's going like that. 69 00:03:00,392 --> 00:03:02,350 And then I showed that there is a way to do it, 70 00:03:02,350 --> 00:03:07,540 whereas if you have 2 to 8, then the 8 is obviously 71 00:03:07,540 --> 00:03:08,920 from the person with 10. 72 00:03:08,920 --> 00:03:13,990 But the 2 different 2 coin outputs are unlinkable. 73 00:03:13,990 --> 00:03:17,030 So that helps, but it's not great. 74 00:03:17,030 --> 00:03:21,310 And then for things like the aggregate signatures, maybe 75 00:03:21,310 --> 00:03:23,920 you can get people to aggregate their transactions together 76 00:03:23,920 --> 00:03:27,020 because it's cheaper and smaller. 77 00:03:27,020 --> 00:03:29,685 But in general, they'll have totally different input sizes, 78 00:03:29,685 --> 00:03:31,810 totally different output sizes, and it won't really 79 00:03:31,810 --> 00:03:33,483 give you any anonymity. 80 00:03:33,483 --> 00:03:34,900 And it won't give you any privacy, 81 00:03:34,900 --> 00:03:36,880 and it hurts fungibility. 82 00:03:36,880 --> 00:03:39,280 So how can we do this? 83 00:03:39,280 --> 00:03:44,487 Wouldn't it be great if we could hide the output amounts? 84 00:03:44,487 --> 00:03:45,570 That would be really cool. 85 00:03:45,570 --> 00:03:47,430 So instead of having it like this-- 86 00:03:47,430 --> 00:03:52,560 it's just you don't see how many coins there are. 87 00:03:52,560 --> 00:03:55,890 Why don't we just delete the output amounts entirely? 88 00:03:55,890 --> 00:03:59,590 Why even that saves 8 bytes. 89 00:03:59,590 --> 00:04:01,420 So we can't just delete it. 90 00:04:01,420 --> 00:04:04,180 So what does this mean? 91 00:04:04,180 --> 00:04:05,830 This would be really cool, though, 92 00:04:05,830 --> 00:04:09,790 if we could somehow obscure this so that no one can 93 00:04:09,790 --> 00:04:12,232 tell what the amounts are. 94 00:04:12,232 --> 00:04:13,690 And, I guess, initially, so they're 95 00:04:13,690 --> 00:04:16,060 going to be some transition since Bitcoin wasn't built 96 00:04:16,060 --> 00:04:19,089 with this from the get-go. 97 00:04:19,089 --> 00:04:21,250 At some point, there will be a transaction where 98 00:04:21,250 --> 00:04:23,740 you can see the input amounts, but then you 99 00:04:23,740 --> 00:04:26,890 can't see the output amounts. 100 00:04:26,890 --> 00:04:30,040 But then you can have bounds and say, well, neither of these 101 00:04:30,040 --> 00:04:32,620 can be more than 12. 102 00:04:32,620 --> 00:04:35,740 And then as it goes forward, and if the transaction graph gets 103 00:04:35,740 --> 00:04:38,320 bigger, those bounds start getting really wide 104 00:04:38,320 --> 00:04:40,960 because you're like, well, this might have been 11, 105 00:04:40,960 --> 00:04:43,430 and this might have been 1, and then the next transaction 106 00:04:43,430 --> 00:04:45,130 if it's mixed in with a bunch of things that have a pretty 107 00:04:45,130 --> 00:04:47,143 wide range, you have to take the max 108 00:04:47,143 --> 00:04:48,310 and min of all those things. 109 00:04:48,310 --> 00:04:50,230 And, the min is always going to be 0, 110 00:04:50,230 --> 00:04:53,260 so it works pretty well even with this transaction. 111 00:04:53,260 --> 00:04:54,790 You could also think of a new system 112 00:04:54,790 --> 00:05:03,940 where either you start with obscured amounts, 113 00:05:03,940 --> 00:05:06,533 or the first mining amounts are non-obscured, 114 00:05:06,533 --> 00:05:07,450 and then you mix them. 115 00:05:07,450 --> 00:05:11,230 Anyway, so this seems like it'd be really useful because it 116 00:05:11,230 --> 00:05:14,080 would allow you to combine transactions and get 117 00:05:14,080 --> 00:05:16,810 better privacy. 118 00:05:16,810 --> 00:05:18,638 Also, just really nice in general, 119 00:05:18,638 --> 00:05:20,930 even if you're not trying to combine with anyone else-- 120 00:05:20,930 --> 00:05:22,347 it's really cool that people can't 121 00:05:22,347 --> 00:05:24,480 see how much money you have. 122 00:05:24,480 --> 00:05:26,230 If people can see how many coins you have, 123 00:05:26,230 --> 00:05:28,040 they can try to charge you more-- 124 00:05:28,040 --> 00:05:29,350 they can try to rob you-- 125 00:05:29,350 --> 00:05:32,410 there's all sorts of reasons why people don't usually 126 00:05:32,410 --> 00:05:35,380 say how much money they're carrying around, 127 00:05:35,380 --> 00:05:37,072 or how much they make, or how-- 128 00:05:37,072 --> 00:05:37,780 things like that. 129 00:05:37,780 --> 00:05:41,470 People are sensitive about pricing information, 130 00:05:41,470 --> 00:05:44,710 and some of it's societal taboo, but also a lot of it's 131 00:05:44,710 --> 00:05:48,100 like I don't want people to know how much money I have. 132 00:05:48,100 --> 00:05:49,370 And I think there's-- 133 00:05:49,370 --> 00:05:51,257 I've read recently like Uber doing 134 00:05:51,257 --> 00:05:52,840 this thing where they like, oh, you're 135 00:05:52,840 --> 00:05:54,423 rich-- we're going to charge you more. 136 00:05:54,423 --> 00:05:56,650 And people don't like that. 137 00:05:56,650 --> 00:06:00,580 It has been historically doable. 138 00:06:00,580 --> 00:06:02,488 Companies segment things, but often the way 139 00:06:02,488 --> 00:06:04,030 they do it is they're like, OK, well, 140 00:06:04,030 --> 00:06:07,750 we're going to make first-class seats and then economy seats. 141 00:06:07,750 --> 00:06:10,030 And the first class seats don't take up 142 00:06:10,030 --> 00:06:12,700 the space of 10 economy seats-- they take up the space of maybe 143 00:06:12,700 --> 00:06:15,115 2, but they cost like 10x. 144 00:06:15,115 --> 00:06:16,990 And the idea is, well, if you're rich-- we're 145 00:06:16,990 --> 00:06:18,032 going to charge you more. 146 00:06:18,032 --> 00:06:20,110 You can have the fancy stuff, and we're 147 00:06:20,110 --> 00:06:22,240 going to make more profit off of that. 148 00:06:22,240 --> 00:06:25,237 That's more OK, I guess, but if it's just-- no, 149 00:06:25,237 --> 00:06:27,820 you're getting the same economy seat, but we know you're rich, 150 00:06:27,820 --> 00:06:29,560 so we're going to charge you more-- 151 00:06:29,560 --> 00:06:31,810 that-- I don't know. 152 00:06:31,810 --> 00:06:34,120 And we're getting into that future 153 00:06:34,120 --> 00:06:37,330 where there's enough data that a lot of companies can do this. 154 00:06:37,330 --> 00:06:39,760 And some people, probably myself included, 155 00:06:39,760 --> 00:06:41,260 is like wait, no, I don't like that. 156 00:06:41,260 --> 00:06:43,677 I like the way it was before where companies didn't really 157 00:06:43,677 --> 00:06:45,040 know that much about me. 158 00:06:45,040 --> 00:06:48,880 So this is an effort to try to keep things obscured-- 159 00:06:48,880 --> 00:06:52,467 try to keep the customer a bit more anonymous with respect 160 00:06:52,467 --> 00:06:54,800 to merchants so that they don't have as much information 161 00:06:54,800 --> 00:06:56,740 to charge more. 162 00:06:56,740 --> 00:06:57,610 And then-- rob you-- 163 00:06:57,610 --> 00:07:02,110 that's maybe more Bitcoin-specific where like-- 164 00:07:02,110 --> 00:07:03,730 yeah, I mean if you're walking around 165 00:07:03,730 --> 00:07:05,950 in an area that's sort of high-crime 166 00:07:05,950 --> 00:07:08,710 with a bunch of money hanging out of your pocket-- that's 167 00:07:08,710 --> 00:07:11,030 a bad idea. 168 00:07:11,030 --> 00:07:13,720 The internet is sort of a high-crime area, especially, 169 00:07:13,720 --> 00:07:14,830 with respect to Bitcoin. 170 00:07:14,830 --> 00:07:17,920 And it's really easy to see how much people have. 171 00:07:17,920 --> 00:07:22,810 And so people-- the hackers know who to target, 172 00:07:22,810 --> 00:07:24,370 especially if it's like an exchange-- 173 00:07:24,370 --> 00:07:25,300 they're pretty clear-- 174 00:07:25,300 --> 00:07:27,903 OK, this exchange has tons of money. 175 00:07:27,903 --> 00:07:29,320 So it might not help the exchanges 176 00:07:29,320 --> 00:07:32,050 that much-- it obviously has a lot of money, but anyway. 177 00:07:32,050 --> 00:07:34,870 So this would be really cool to do. 178 00:07:34,870 --> 00:07:38,602 I think people sort of agree-- this would be really cool. 179 00:07:38,602 --> 00:07:39,810 This is a nice thing to have. 180 00:07:43,840 --> 00:07:46,160 And it also helps with privacy. 181 00:07:46,160 --> 00:07:49,090 You're trying to make it hard to link 182 00:07:49,090 --> 00:07:52,120 different outputs to each other or link the outputs 183 00:07:52,120 --> 00:07:54,310 to a specific person. 184 00:07:54,310 --> 00:07:56,920 And hiding the amounts makes them really hard 185 00:07:56,920 --> 00:07:57,640 to distinguish. 186 00:07:57,640 --> 00:07:59,980 So if you don't know the amounts, 187 00:07:59,980 --> 00:08:02,860 they become completely uniform where this 188 00:08:02,860 --> 00:08:05,690 is a completely random address. 189 00:08:05,690 --> 00:08:07,490 I have no idea how many coins there are. 190 00:08:07,490 --> 00:08:09,800 I have very little way to distinguish 191 00:08:09,800 --> 00:08:11,510 between these outputs. 192 00:08:11,510 --> 00:08:13,600 I can try to trace the graph and say, OK, well, 193 00:08:13,600 --> 00:08:15,350 this came from here-- this came from here, 194 00:08:15,350 --> 00:08:16,890 but they all look the same. 195 00:08:16,890 --> 00:08:19,970 So I've got this big graph with no real information 196 00:08:19,970 --> 00:08:22,610 other than the links between the notes, 197 00:08:22,610 --> 00:08:23,750 which is still information. 198 00:08:23,750 --> 00:08:28,100 But it's much harder to tell what's going on. 199 00:08:28,100 --> 00:08:31,640 So we're sold-- how do we do it? 200 00:08:31,640 --> 00:08:33,094 First, we need to define-- 201 00:08:33,094 --> 00:08:35,742 what exactly are we trying to do? 202 00:08:35,742 --> 00:08:36,950 What are we hiding from whom? 203 00:08:36,950 --> 00:08:39,740 Who knows what and when kind of thing? 204 00:08:39,740 --> 00:08:44,159 So the long-term state of the system-- 205 00:08:44,159 --> 00:08:46,180 no one can see any-- 206 00:08:46,180 --> 00:08:47,960 no one can see it in the amounts. 207 00:08:47,960 --> 00:08:50,080 A has signed a signature from key A-- 208 00:08:50,080 --> 00:08:51,520 a signature from key B-- 209 00:08:51,520 --> 00:08:52,510 some amount of coins. 210 00:08:52,510 --> 00:08:55,780 You don't see it. you don't see any of this. 211 00:08:55,780 --> 00:08:57,490 So that's the long-term state. 212 00:08:57,490 --> 00:09:00,160 But wait, people receiving the payments 213 00:09:00,160 --> 00:09:02,830 should probably know how much they're receiving, right? 214 00:09:02,830 --> 00:09:05,348 And they should probably know how much they have. 215 00:09:05,348 --> 00:09:07,390 If you don't know how much money you're getting-- 216 00:09:07,390 --> 00:09:09,955 that's not a very useful payment system. 217 00:09:09,955 --> 00:09:11,830 People sending should-- they should also know 218 00:09:11,830 --> 00:09:13,360 how much money they're sending. 219 00:09:13,360 --> 00:09:17,230 If the amount can be completely determined by the receiver-- 220 00:09:17,230 --> 00:09:19,000 that's also not a good payment system. 221 00:09:19,000 --> 00:09:22,150 I'm just going to take lots of money. 222 00:09:22,150 --> 00:09:25,270 So we can have two views. 223 00:09:25,270 --> 00:09:30,040 We can say, OK, only the sender and receiver know the amounts. 224 00:09:30,040 --> 00:09:32,900 How about that-- where from the network's point of view-- 225 00:09:32,900 --> 00:09:35,950 so if I'm just the third party looking at this transaction-- 226 00:09:35,950 --> 00:09:37,510 I don't see any of the amounts. 227 00:09:37,510 --> 00:09:38,770 I just see there's no-- 228 00:09:38,770 --> 00:09:41,200 I have no idea how many coins are being sent. 229 00:09:41,200 --> 00:09:43,330 But from the sender's view, the sender 230 00:09:43,330 --> 00:09:45,190 says, OK, I know I have 2 coins here. 231 00:09:45,190 --> 00:09:48,340 7 coins-- I changed it from 2 and 10 on that line-- 232 00:09:48,340 --> 00:09:49,980 2 coins here, 7 coins here. 233 00:09:49,980 --> 00:09:52,870 And I'm sending 7 coins here and 2 coins there. 234 00:09:52,870 --> 00:09:54,580 So the sender knows the whole thing 235 00:09:54,580 --> 00:09:56,980 because they're the ones creating this transaction. 236 00:09:56,980 --> 00:10:02,980 And then maybe the receiver doesn't see everything. 237 00:10:02,980 --> 00:10:07,900 Maybe the sender can prove to the receiver a single amount 238 00:10:07,900 --> 00:10:09,860 but hide everything else. 239 00:10:09,860 --> 00:10:11,080 That would be ideal. 240 00:10:11,080 --> 00:10:16,460 So the receiver only sees, oh, I'm receiving 2 coins, 241 00:10:16,460 --> 00:10:19,120 but I don't know. 242 00:10:19,120 --> 00:10:21,580 If I know this, then I can figure out 243 00:10:21,580 --> 00:10:24,012 what these are, or at least the sum of them. 244 00:10:24,012 --> 00:10:25,720 But if I don't know any of these things-- 245 00:10:25,720 --> 00:10:29,140 I don't know how much the person sending me money has. 246 00:10:29,140 --> 00:10:30,820 I just know, oh, I got 2 coins. 247 00:10:30,820 --> 00:10:32,350 Cool, that's what I wanted. 248 00:10:32,350 --> 00:10:35,470 But I don't learn anything about their inputs 249 00:10:35,470 --> 00:10:37,570 or their other outputs within the transaction. 250 00:10:37,570 --> 00:10:39,820 So that would be ideal if we can do that. 251 00:10:39,820 --> 00:10:43,180 So what we want is a system where network 252 00:10:43,180 --> 00:10:45,130 doesn't see any of the amounts. 253 00:10:45,130 --> 00:10:48,010 The sender presumably sees all of it. 254 00:10:48,010 --> 00:10:51,353 Now, there could be cases where there's multiple senders, 255 00:10:51,353 --> 00:10:54,020 and there are two people working together to make a transaction, 256 00:10:54,020 --> 00:10:56,410 and maybe we don't see each other's inputs, 257 00:10:56,410 --> 00:10:59,890 but we'll keep it simple for now where there's a single sender. 258 00:10:59,890 --> 00:11:03,460 And then the receiver only sees their own output. 259 00:11:03,460 --> 00:11:05,650 So that would be a really powerful system. 260 00:11:05,650 --> 00:11:07,270 Then the receiver would only know 261 00:11:07,270 --> 00:11:09,160 they're getting the right amount and not 262 00:11:09,160 --> 00:11:13,240 learn anything else about the sender's coins. 263 00:11:13,240 --> 00:11:15,250 So we might want to-- like I was saying, 264 00:11:15,250 --> 00:11:17,440 you might want to hide per output. 265 00:11:17,440 --> 00:11:18,580 So if you have a-- 266 00:11:18,580 --> 00:11:20,605 if it's a global-- 267 00:11:20,605 --> 00:11:23,230 either you see everything or you see-- sorry-- you see nothing, 268 00:11:23,230 --> 00:11:25,870 or you see everything-- that's still pretty good. 269 00:11:25,870 --> 00:11:28,380 That's still better than what we have 270 00:11:28,380 --> 00:11:31,330 when everyone sees everything, but it is better 271 00:11:31,330 --> 00:11:33,940 if you can hide the rest of these three things 272 00:11:33,940 --> 00:11:36,670 from the receiver. 273 00:11:36,670 --> 00:11:39,270 So any ideas? 274 00:11:39,270 --> 00:11:41,152 Some kind of encryption? 275 00:11:41,152 --> 00:11:42,610 Hide the amounts so the only people 276 00:11:42,610 --> 00:11:44,720 with the right private key can see the numbers? 277 00:11:47,920 --> 00:11:51,460 So, I don't think I've even talked about encryption ever 278 00:11:51,460 --> 00:11:55,270 in this class, because there is no encryption in blockchains. 279 00:11:55,270 --> 00:11:57,257 [LAUGHS] Which is something you-- 280 00:11:57,257 --> 00:11:58,840 if you read something about blockchain 281 00:11:58,840 --> 00:12:00,190 and you're like blockchain is encrypted. 282 00:12:00,190 --> 00:12:01,857 And you're like no, no-- they don't know 283 00:12:01,857 --> 00:12:03,190 what they're talking about. 284 00:12:03,190 --> 00:12:05,710 So I haven't defined encryption. 285 00:12:05,710 --> 00:12:08,560 But encryption is-- generally, you have some kind of private 286 00:12:08,560 --> 00:12:09,430 key-- 287 00:12:09,430 --> 00:12:12,450 you take a clear text, you apply-- you do some-- 288 00:12:15,490 --> 00:12:18,610 so like I had with signatures, you have a set of functions. 289 00:12:18,610 --> 00:12:22,240 So encryption is-- you've got some encryption function which 290 00:12:22,240 --> 00:12:28,512 takes a key and a message and outputs a ciphertext. 291 00:12:28,512 --> 00:12:30,970 And then you've got some kind of decryption function, which 292 00:12:30,970 --> 00:12:34,810 takes off in the same key or something and then 293 00:12:34,810 --> 00:12:37,592 the ciphertext and outputs the same message. 294 00:12:37,592 --> 00:12:39,550 And this is symmetric encryption because you're 295 00:12:39,550 --> 00:12:41,560 using the same key. 296 00:12:41,560 --> 00:12:43,750 You can also have asymmetric encryption 297 00:12:43,750 --> 00:12:45,970 where this could be a public key, 298 00:12:45,970 --> 00:12:48,200 and this could be a private key. 299 00:12:48,200 --> 00:12:50,920 So in order to decrypt, you need the private key, 300 00:12:50,920 --> 00:12:53,680 but in order to encrypt, you only need someone's public key. 301 00:12:56,200 --> 00:13:01,210 So, in practice, all the things that people-- 302 00:13:01,210 --> 00:13:02,650 in practice, you usually stage it, 303 00:13:02,650 --> 00:13:06,730 so you have an asymmetric algorithm to agree on a key, 304 00:13:06,730 --> 00:13:09,580 and then you just use the symmetric encryption 305 00:13:09,580 --> 00:13:11,980 and decryption where the keys are the same because it's 306 00:13:11,980 --> 00:13:14,080 way faster. 307 00:13:14,080 --> 00:13:17,800 So you can do this operation on the order of hundreds 308 00:13:17,800 --> 00:13:22,100 of megabytes a second, whereas the asymmetric ones are slow-- 309 00:13:22,100 --> 00:13:23,843 it's sort of like signing. 310 00:13:23,843 --> 00:13:25,010 Maybe I'll go into it later. 311 00:13:25,010 --> 00:13:27,400 But if you understand all the signing and stuff, 312 00:13:27,400 --> 00:13:29,818 it's not too bad. 313 00:13:29,818 --> 00:13:31,360 But so maybe you could say, OK, well, 314 00:13:31,360 --> 00:13:34,310 there's some kind of private key that the sender creates-- 315 00:13:34,310 --> 00:13:38,560 encrypts the amounts, and then they put the encrypted amounts 316 00:13:38,560 --> 00:13:45,550 in the transaction, and they reveal the key to the receiver. 317 00:13:45,550 --> 00:13:48,040 And, potentially, you could have different keys 318 00:13:48,040 --> 00:13:50,470 for each amount-- 319 00:13:50,470 --> 00:13:52,873 that would work. 320 00:13:52,873 --> 00:13:54,040 Any problems with that idea? 321 00:13:57,705 --> 00:13:58,830 You can encrypt everything. 322 00:13:58,830 --> 00:14:00,335 Yeah, you know? 323 00:14:00,335 --> 00:14:03,060 AUDIENCE: You would need to send over a public key or something 324 00:14:03,060 --> 00:14:04,570 so they can decrypt it. 325 00:14:04,570 --> 00:14:08,800 TADGE DRYJA: Yeah, oh, OK, so that is a sort of problem-- 326 00:14:08,800 --> 00:14:09,540 it's a limit. 327 00:14:09,540 --> 00:14:13,230 But that limit will carry forward to the stuff we do. 328 00:14:13,230 --> 00:14:14,640 So you're going to have to-- 329 00:14:14,640 --> 00:14:18,090 right now, in Bitcoin, you can find someone's address, 330 00:14:18,090 --> 00:14:19,710 send them the coins-- you're good. 331 00:14:19,710 --> 00:14:21,210 With this system, there will be more 332 00:14:21,210 --> 00:14:23,190 interactivity between sender and receiver. 333 00:14:23,190 --> 00:14:26,770 So that's not great, but not a deal breaker. 334 00:14:26,770 --> 00:14:28,647 So we will need to do that. 335 00:14:28,647 --> 00:14:29,230 Other problem? 336 00:14:29,230 --> 00:14:29,570 Yeah. 337 00:14:29,570 --> 00:14:30,490 AUDIENCE: A key for every amount. 338 00:14:30,490 --> 00:14:31,496 TADGE DRYJA: Yeah. 339 00:14:31,496 --> 00:14:35,187 AUDIENCE: [INAUDIBLE] because of the fact that there can be 340 00:14:35,187 --> 00:14:38,591 a lot of different ways to split up the-- 341 00:14:38,591 --> 00:14:41,670 TADGE DRYJA: Yeah, it could get bigger. 342 00:14:41,670 --> 00:14:44,290 And the actual solution gets big. 343 00:14:44,290 --> 00:14:46,110 So that's not great either. 344 00:14:46,110 --> 00:14:48,456 But the one that really screws it up. 345 00:14:48,456 --> 00:14:49,157 [LAUGHS] Yeah. 346 00:14:49,157 --> 00:14:51,240 AUDIENCE: How do the nodes verify the transaction? 347 00:14:51,240 --> 00:14:54,090 TADGE DRYJA: So the nodes don't verify the transaction at all 348 00:14:54,090 --> 00:14:55,680 because they can't see anything. 349 00:14:55,680 --> 00:14:57,660 Well, I can do that. 350 00:14:57,660 --> 00:15:01,770 Well, how about I just make 70 coins and 2,000 coins? 351 00:15:01,770 --> 00:15:03,600 I can make as many coins as I want. 352 00:15:03,600 --> 00:15:08,490 No one can see anything because the network just sees nothing-- 353 00:15:08,490 --> 00:15:10,410 have no idea how many coins are being sent. 354 00:15:10,410 --> 00:15:12,480 But I'd be like, hey, hey, I'm making 355 00:15:12,480 --> 00:15:14,400 more coins all over the place. 356 00:15:14,400 --> 00:15:17,250 [LAUGHS] And this doesn't work. 357 00:15:17,250 --> 00:15:20,490 Because if I can send coins to myself 358 00:15:20,490 --> 00:15:25,620 and multiply them indefinitely, and it's hidden-- 359 00:15:25,620 --> 00:15:27,120 so to some extent, you're like well, 360 00:15:27,120 --> 00:15:29,130 maybe the network doesn't care. 361 00:15:29,130 --> 00:15:36,073 Because well, I'm making them, but they're only my own coins. 362 00:15:36,073 --> 00:15:37,740 But if the network doesn't see anything, 363 00:15:37,740 --> 00:15:39,300 it's easy to create the coins. 364 00:15:39,300 --> 00:15:41,760 And if those coins are later used, 365 00:15:41,760 --> 00:15:43,480 I can't tell if they were made up or not. 366 00:15:43,480 --> 00:15:45,220 So if I'm accepting-- 367 00:15:45,220 --> 00:15:49,500 so if I see this, and someone's like, hey, here's 2,000 coins-- 368 00:15:49,500 --> 00:15:51,610 I'm like dude, you're making them up. 369 00:15:51,610 --> 00:15:54,470 You can't write extra zeros on $100 bill 370 00:15:54,470 --> 00:15:55,470 and be like here you go. 371 00:15:55,470 --> 00:15:56,868 This is-- come on. 372 00:15:56,868 --> 00:15:58,410 No one's going to accept these later. 373 00:16:03,290 --> 00:16:04,710 I won't even know. 374 00:16:04,710 --> 00:16:06,150 Did you even have 7? 375 00:16:06,150 --> 00:16:08,360 Does this 7 coins come from something 376 00:16:08,360 --> 00:16:10,680 where you did the same kind of thing before? 377 00:16:10,680 --> 00:16:13,710 So, basically, if we do that where we completely 378 00:16:13,710 --> 00:16:16,520 obscure the amounts from the network 379 00:16:16,520 --> 00:16:19,500 and from all third parties, then anytime I'm 380 00:16:19,500 --> 00:16:21,780 going to accept this, I'm going to have 381 00:16:21,780 --> 00:16:24,030 to enforce the rules myself. 382 00:16:24,030 --> 00:16:28,170 And then retroactively enforce the rules for all transactions 383 00:16:28,170 --> 00:16:32,100 beforehand to make sure nothing like this happened. 384 00:16:32,100 --> 00:16:33,840 So we could do that. 385 00:16:33,840 --> 00:16:34,740 It's all obscured. 386 00:16:34,740 --> 00:16:37,230 The third-party-- the network doesn't see anything. 387 00:16:37,230 --> 00:16:39,390 And it's up to the participants themselves 388 00:16:39,390 --> 00:16:41,910 to say, well, if you're going to send me coins-- 389 00:16:41,910 --> 00:16:44,242 since I know if I'm sending it to someone later, 390 00:16:44,242 --> 00:16:46,200 I'm going to have to provide some kind of proof 391 00:16:46,200 --> 00:16:49,080 that this kind of nonsense didn't happen. 392 00:16:49,080 --> 00:16:51,180 I'm also going to need proof that all 393 00:16:51,180 --> 00:16:52,770 of the ancestor transactions that 394 00:16:52,770 --> 00:16:55,210 led to these 2 and 7 coins-- 395 00:16:55,210 --> 00:16:57,300 I'm going to need those amounts. 396 00:16:57,300 --> 00:16:59,700 And, so, yeah, you could maybe do that. 397 00:16:59,700 --> 00:17:05,599 You could provide the decryption keys for all previous amounts. 398 00:17:05,599 --> 00:17:08,599 But that basically gets you back to where we are right now-- 399 00:17:08,599 --> 00:17:10,849 not quite, but pretty close. 400 00:17:14,883 --> 00:17:16,550 Either you allow people to create coins, 401 00:17:16,550 --> 00:17:19,730 or you basically are revealing close to all previous amounts 402 00:17:19,730 --> 00:17:21,380 eventually to everyone. 403 00:17:21,380 --> 00:17:24,359 Because as that transaction graph gets bigger and bigger, 404 00:17:24,359 --> 00:17:27,410 I'm going to start having all these thousands and thousands 405 00:17:27,410 --> 00:17:29,660 of ancestor transactions that I'm going 406 00:17:29,660 --> 00:17:31,553 to have to require proof for. 407 00:17:31,553 --> 00:17:33,470 I'm going to require all those decryption keys 408 00:17:33,470 --> 00:17:35,630 to make sure nothing like this happened. 409 00:17:35,630 --> 00:17:37,940 And then eventually, all the people receiving money 410 00:17:37,940 --> 00:17:39,770 will be able to see everything-- well, not 411 00:17:39,770 --> 00:17:42,020 quite everything, but a lot. 412 00:17:42,020 --> 00:17:44,570 So it's like well, third-parties-- 413 00:17:44,570 --> 00:17:47,600 the miners or maybe people who are just looking 414 00:17:47,600 --> 00:17:50,810 at the blockchain who aren't really receiving any funds-- 415 00:17:50,810 --> 00:17:53,280 maybe it's hidden from them. 416 00:17:53,280 --> 00:17:55,190 But once you start using the system, 417 00:17:55,190 --> 00:17:57,747 you're going to basically be able to see everything. 418 00:17:57,747 --> 00:17:58,580 So that's not great. 419 00:18:01,130 --> 00:18:03,227 And it would also be really annoying 420 00:18:03,227 --> 00:18:05,060 because then when you have to receive coins, 421 00:18:05,060 --> 00:18:07,310 you have to go back through thousands of transactions 422 00:18:07,310 --> 00:18:09,090 to make sure that didn't happen. 423 00:18:09,090 --> 00:18:14,450 So we need to prevent coin creation while still 424 00:18:14,450 --> 00:18:16,870 keeping the amount secret. 425 00:18:16,870 --> 00:18:19,120 This is a tricky problem-- 426 00:18:19,120 --> 00:18:23,810 any general ideas here? 427 00:18:23,810 --> 00:18:27,250 So wouldn't it be cool if we could 428 00:18:27,250 --> 00:18:32,102 do this where the network sees there's w coins here, 429 00:18:32,102 --> 00:18:34,060 there's x coins here, and there's y coins here, 430 00:18:34,060 --> 00:18:35,470 there's z coins here? 431 00:18:35,470 --> 00:18:38,170 And then we have a proof-- 432 00:18:38,170 --> 00:18:41,500 w plus x equals y plus z, without telling you 433 00:18:41,500 --> 00:18:43,630 what w, x, y, and z are. 434 00:18:46,260 --> 00:18:47,070 Cool. 435 00:18:47,070 --> 00:18:48,330 Let's do it. 436 00:18:48,330 --> 00:18:48,830 Any ideas? 437 00:18:48,830 --> 00:18:52,290 [LAUGHS] 438 00:18:52,290 --> 00:18:56,670 So this seems like this would work. 439 00:18:56,670 --> 00:19:00,130 This would do it in that if we can reveal like say, hey, 440 00:19:00,130 --> 00:19:02,370 the person d-- 441 00:19:02,370 --> 00:19:03,930 z is 2. 442 00:19:03,930 --> 00:19:05,050 Cool. 443 00:19:05,050 --> 00:19:06,390 So I got 2 coins. 444 00:19:06,390 --> 00:19:11,130 And they can also verify that these amounts are correct. 445 00:19:11,130 --> 00:19:12,150 And then if you're-- 446 00:19:12,150 --> 00:19:15,490 you could either keep this proof only to the receiver, 447 00:19:15,490 --> 00:19:17,310 but then you'd have to give proofs 448 00:19:17,310 --> 00:19:19,140 about all the previous transactions, 449 00:19:19,140 --> 00:19:21,307 or you can just, say no-- the whole network enforces 450 00:19:21,307 --> 00:19:21,870 these groups. 451 00:19:21,870 --> 00:19:25,500 This is now a consensus rule where if you want-- 452 00:19:25,500 --> 00:19:27,390 even if it's not your transaction, 453 00:19:27,390 --> 00:19:30,180 it might be a parent of your transaction someday. 454 00:19:30,180 --> 00:19:31,440 So you have to verify it. 455 00:19:31,440 --> 00:19:33,180 If you're going to accept the block-- 456 00:19:33,180 --> 00:19:37,360 verify these proofs for every transaction. 457 00:19:37,360 --> 00:19:38,842 So that would work. 458 00:19:38,842 --> 00:19:41,590 AUDIENCE: So that's essentially a minor deal, right? 459 00:19:41,590 --> 00:19:44,640 TADGE DRYJA: Yeah, a miner, or-- 460 00:19:44,640 --> 00:19:47,340 the miners would do it and also the full nodes. 461 00:19:47,340 --> 00:19:48,600 If you're running a node-- 462 00:19:48,600 --> 00:19:50,280 well, I'm not receiving anything here, 463 00:19:50,280 --> 00:19:53,070 but I still need to make sure this is a valid transaction 464 00:19:53,070 --> 00:19:54,030 in order to accept it. 465 00:19:54,030 --> 00:19:56,610 AUDIENCE: Isn't that a problem then, because what if a miner 466 00:19:56,610 --> 00:19:59,415 is in that transaction? 467 00:19:59,415 --> 00:20:01,330 TADGE DRYJA: If the miner's receive-- 468 00:20:01,330 --> 00:20:03,170 the miners D in receiving this coin? 469 00:20:03,170 --> 00:20:03,956 AUDIENCE: Yeah. 470 00:20:03,956 --> 00:20:05,570 TADGE DRYJA: Then they'll know-- 471 00:20:05,570 --> 00:20:08,250 then they'll both get the proof, which 472 00:20:08,250 --> 00:20:09,540 is sort of redundant for them. 473 00:20:09,540 --> 00:20:12,180 And they'll also get the actual amount-- z. 474 00:20:12,180 --> 00:20:15,830 So they'll know this is 2. 475 00:20:15,830 --> 00:20:18,380 So that miner would know more, but that's OK. 476 00:20:18,380 --> 00:20:23,290 I guess other miners wouldn't-- or other nodes wouldn't. 477 00:20:23,290 --> 00:20:26,260 So if you're participating, you'll potentially know more. 478 00:20:26,260 --> 00:20:28,550 But the idea is third-parties see a proof 479 00:20:28,550 --> 00:20:31,150 and don't see the amounts. 480 00:20:31,150 --> 00:20:31,842 Yeah. 481 00:20:31,842 --> 00:20:33,827 AUDIENCE: So SPV will have no way 482 00:20:33,827 --> 00:20:36,930 of knowing if a transaction was valid until it was [INAUDIBLE]?? 483 00:20:36,930 --> 00:20:39,190 TADGE DRYJA: They already know. 484 00:20:39,190 --> 00:20:41,140 So SPV, while it's already have no idea 485 00:20:41,140 --> 00:20:43,300 how many coins are coming in on the inputs 486 00:20:43,300 --> 00:20:45,430 because they don't have a UTXO set. 487 00:20:45,430 --> 00:20:47,290 And the coin-- so if you see an input, 488 00:20:47,290 --> 00:20:49,577 you see it's pointing to some txid. 489 00:20:49,577 --> 00:20:51,160 I don't know how many coins there are. 490 00:20:51,160 --> 00:20:52,390 I would have to-- 491 00:20:52,390 --> 00:20:55,210 you could provide a proof to an SPV wallet 492 00:20:55,210 --> 00:20:56,830 that, hey, there were-- 493 00:20:56,830 --> 00:20:58,840 I can give you that previous transaction, 494 00:20:58,840 --> 00:21:02,230 and you can see how many coins, but then what about the one 495 00:21:02,230 --> 00:21:02,750 before that? 496 00:21:02,750 --> 00:21:05,710 So, generally, SPV wallets can't enforce 497 00:21:05,710 --> 00:21:08,080 that amounts are correct or verify signatures, 498 00:21:08,080 --> 00:21:11,740 because they don't know enough about these inputs, 499 00:21:11,740 --> 00:21:13,870 whereas full nodes-- 500 00:21:13,870 --> 00:21:16,210 when you tell me to input 0, I know how much. 501 00:21:16,210 --> 00:21:18,370 I know what keys-- things like that. 502 00:21:18,370 --> 00:21:21,430 So SPV can't well-- 503 00:21:21,430 --> 00:21:24,490 no there's maybe some way to make the SPV 504 00:21:24,490 --> 00:21:27,100 have it so that SPV proofs are compatible with this. 505 00:21:27,100 --> 00:21:30,270 But it's-- you already don't have that. 506 00:21:30,270 --> 00:21:34,300 So I don't think there's much idea-- 507 00:21:34,300 --> 00:21:36,640 there's much much research into how 508 00:21:36,640 --> 00:21:39,670 to make this SPV compatible. 509 00:21:39,670 --> 00:21:41,050 But yeah, it's a good question. 510 00:21:41,050 --> 00:21:43,600 Other basic ideas? 511 00:21:43,600 --> 00:21:44,920 So how do we do this? 512 00:21:44,920 --> 00:21:48,580 [LAUGHS] So this will take a little-- 513 00:21:48,580 --> 00:21:53,390 the actual way to do this will take the rest of the class. 514 00:21:53,390 --> 00:21:56,790 Because there's a lot of things where that seems like 515 00:21:56,790 --> 00:21:59,590 it'll work, and it's like oh, no, it doesn't. 516 00:21:59,590 --> 00:22:04,240 And this is sort of replaying the ideas from several years 517 00:22:04,240 --> 00:22:06,612 of people trying to do this. 518 00:22:06,612 --> 00:22:07,570 So how will we do this? 519 00:22:07,570 --> 00:22:11,030 So there's an idea called commitments. 520 00:22:11,030 --> 00:22:13,690 And the simplest form of a commitment is you 521 00:22:13,690 --> 00:22:15,560 commit to some value-- 522 00:22:15,560 --> 00:22:17,380 you ouput it-- call it c-- 523 00:22:17,380 --> 00:22:20,590 and then you reveal the value and then someone can verify. 524 00:22:20,590 --> 00:22:25,630 Well, given c and the value you just revealed, 525 00:22:25,630 --> 00:22:29,020 is that a correct commitment? 526 00:22:29,020 --> 00:22:32,820 So I'm committing to the value 2. 527 00:22:32,820 --> 00:22:36,700 I'm outputting something c and then revealing it was 2. 528 00:22:36,700 --> 00:22:39,220 And let me throw this into my function. 529 00:22:39,220 --> 00:22:42,010 2 and c-- do those match? 530 00:22:42,010 --> 00:22:43,270 Oh, it's true-- we're good. 531 00:22:46,402 --> 00:22:48,360 And then there's certain properties you'd want. 532 00:22:48,360 --> 00:22:50,760 You don't want people to-- 533 00:22:50,760 --> 00:22:52,650 I think I have slides about that. 534 00:22:52,650 --> 00:22:56,340 So the hash function is a commitment. 535 00:22:56,340 --> 00:23:00,310 I can say the hash of 5 is 68 empty-- whatever. 536 00:23:00,310 --> 00:23:02,700 And then I commit to 68 something. 537 00:23:02,700 --> 00:23:04,533 I publish this, and I tell everyone 538 00:23:04,533 --> 00:23:05,700 I'm committing to something. 539 00:23:05,700 --> 00:23:08,075 I'm not going to tell you what I'm committing to exactly, 540 00:23:08,075 --> 00:23:10,350 but here's this 68fde0b7-- 541 00:23:10,350 --> 00:23:12,630 some long hash output. 542 00:23:12,630 --> 00:23:18,610 And then I reveal days later the thing 543 00:23:18,610 --> 00:23:21,100 I was committing to-- that was 5. 544 00:23:21,100 --> 00:23:23,410 And then everyone can check. 545 00:23:23,410 --> 00:23:25,490 Let me throw 5 into my hash function. 546 00:23:25,490 --> 00:23:27,190 Oh, yeah, it was this. 547 00:23:27,190 --> 00:23:28,070 True. 548 00:23:28,070 --> 00:23:29,320 So that's a commitment scheme. 549 00:23:32,510 --> 00:23:33,350 It is binding. 550 00:23:33,350 --> 00:23:35,660 So there's binding and hiding, and there's 551 00:23:35,660 --> 00:23:37,970 different properties of commitment schemes. 552 00:23:37,970 --> 00:23:41,570 So this we could say is a computationally binding 553 00:23:41,570 --> 00:23:43,700 commitment scheme. 554 00:23:43,700 --> 00:23:46,040 Once I've committed to this, I'm not 555 00:23:46,040 --> 00:23:48,960 going to be able to find another number. 556 00:23:48,960 --> 00:23:52,390 So I'm not going to be able to say, oh, it was 6 557 00:23:52,390 --> 00:23:55,750 And then get the same commitment out. 558 00:23:55,750 --> 00:23:58,750 So I'm not going to-- so in practice, this is really long. 559 00:23:58,750 --> 00:24:01,905 This is a shot 2 output. 560 00:24:01,905 --> 00:24:03,530 I didn't want to write the whole thing, 561 00:24:03,530 --> 00:24:06,380 but it goes to here, or two lines. 562 00:24:06,380 --> 00:24:10,100 So the idea is I can't find another number, especially 563 00:24:10,100 --> 00:24:11,240 exactly the number I want. 564 00:24:11,240 --> 00:24:13,880 But I can't find any other number that will get me 565 00:24:13,880 --> 00:24:15,950 to that same hash output. 566 00:24:15,950 --> 00:24:18,650 That's a collision, and I'm going to have to try it. 567 00:24:18,650 --> 00:24:22,970 Wait, so for a specific number, I'd have to try 2 to the 256. 568 00:24:22,970 --> 00:24:26,180 For any collision, I only have to do 2 the 128. 569 00:24:26,180 --> 00:24:29,660 But still, both of those are really big numbers. 570 00:24:29,660 --> 00:24:30,830 I can't do it. 571 00:24:30,830 --> 00:24:32,660 So it's computationally binding. 572 00:24:32,660 --> 00:24:35,690 If I had some amazing computer that 573 00:24:35,690 --> 00:24:40,820 could perform an infinite calculation, 574 00:24:40,820 --> 00:24:44,120 I could find a collision. 575 00:24:44,120 --> 00:24:47,000 So there's the distinction between computationally 576 00:24:47,000 --> 00:24:49,070 and information theoretically. 577 00:24:49,070 --> 00:24:50,990 Information theoretically is stronger 578 00:24:50,990 --> 00:24:55,550 where even if I had the most powerful computer, 579 00:24:55,550 --> 00:24:59,150 I still couldn't do this, whereas binding, in this case, 580 00:24:59,150 --> 00:25:00,470 it's computationally binding-- 581 00:25:00,470 --> 00:25:02,533 computationally is good enough. 582 00:25:02,533 --> 00:25:03,950 Everything in Bitcoin is already-- 583 00:25:03,950 --> 00:25:05,300 everything in all these systems is already 584 00:25:05,300 --> 00:25:06,590 basically computational. 585 00:25:06,590 --> 00:25:11,460 There are some schemes, which are not computationally bound. 586 00:25:11,460 --> 00:25:13,970 So one of the parts here-- 587 00:25:13,970 --> 00:25:17,780 and the Pedersen commitments are not computationally-- 588 00:25:17,780 --> 00:25:20,810 and things like severe secret sharing and a couple 589 00:25:20,810 --> 00:25:25,190 other things where this is not dependent on processing power. 590 00:25:25,190 --> 00:25:27,110 Even if you have infinite processing power, 591 00:25:27,110 --> 00:25:30,230 you just can't figure out what the values are, 592 00:25:30,230 --> 00:25:33,450 which is cooler, but it's nice to have. 593 00:25:33,450 --> 00:25:36,810 It's not a requirement for our systems. 594 00:25:36,810 --> 00:25:38,520 So this is binding. 595 00:25:38,520 --> 00:25:41,940 Any ideas of what this is not-- why this would not 596 00:25:41,940 --> 00:25:44,830 be a good commitment scheme? 597 00:25:44,830 --> 00:25:49,620 You want to commit to a value and then later reveal it. 598 00:25:49,620 --> 00:25:51,780 You don't want the person who's committing 599 00:25:51,780 --> 00:25:54,570 to be able to change their commitment. 600 00:25:54,570 --> 00:25:58,090 What else might you want that this probably doesn't provide? 601 00:26:02,110 --> 00:26:03,610 AUDIENCE: Do you need some way to be 602 00:26:03,610 --> 00:26:05,614 able to hash the commitment? 603 00:26:05,614 --> 00:26:06,920 TADGE DRYJA: Yep. 604 00:26:06,920 --> 00:26:09,015 So you want to be able to do fancy stuff 605 00:26:09,015 --> 00:26:09,890 with the commitments. 606 00:26:09,890 --> 00:26:13,370 Before we even get there, that's in 5 or 6 slides-- 607 00:26:13,370 --> 00:26:15,050 before we even get there, this doesn't 608 00:26:15,050 --> 00:26:16,700 satisfy something else we want. 609 00:26:19,240 --> 00:26:19,740 Yeah. 610 00:26:19,740 --> 00:26:22,100 AUDIENCE: All but like 5 is such a common number? 611 00:26:22,100 --> 00:26:24,210 TADGE DRYJA: This is easy to guess. 612 00:26:24,210 --> 00:26:27,150 So if I'm committing to a number, 613 00:26:27,150 --> 00:26:29,220 I'm going to commit to the number of pizzas 614 00:26:29,220 --> 00:26:30,990 I'm ordering at my party. 615 00:26:30,990 --> 00:26:32,490 And everyone's wondering how many 616 00:26:32,490 --> 00:26:35,130 pieces are you going to order? 617 00:26:35,130 --> 00:26:37,470 I try things. 618 00:26:37,470 --> 00:26:39,450 It's binding, but it's not hiding. 619 00:26:39,450 --> 00:26:44,790 So verifier can easily guess and check the committed value. 620 00:26:44,790 --> 00:26:49,000 So for i equals 0. 621 00:26:49,000 --> 00:26:52,000 Just keep trying different i's and see 622 00:26:52,000 --> 00:26:54,880 if the hash matches 68fd even. 623 00:26:54,880 --> 00:26:56,500 And this will take very little time 624 00:26:56,500 --> 00:26:59,180 because 5 is going to happen pretty quick. 625 00:26:59,180 --> 00:27:01,750 And then everyone will know he's ordering five pizzas-- 626 00:27:01,750 --> 00:27:03,460 sounds like a decent party, but not 627 00:27:03,460 --> 00:27:07,560 really worth going out of my way to go to. 628 00:27:07,560 --> 00:27:10,590 If it was fffff pizzas-- that would be something else. 629 00:27:10,590 --> 00:27:15,250 So solution-- pretty straightforward solution. 630 00:27:15,250 --> 00:27:17,370 Add a blinding factor. 631 00:27:17,370 --> 00:27:22,620 So we're going to call that, r I guess, r is random. 632 00:27:22,620 --> 00:27:26,760 So r is b8bc7579. 633 00:27:26,760 --> 00:27:30,590 And now I'm going to take the hash of 5 and concatenate r, 634 00:27:30,590 --> 00:27:32,970 and now this is a different hash. 635 00:27:32,970 --> 00:27:37,240 And now to reveal what I was committing to-- 636 00:27:37,240 --> 00:27:39,120 you reveal both 5 and r. 637 00:27:44,120 --> 00:27:48,010 And you need to tell people what order you're doing things in. 638 00:27:48,010 --> 00:27:50,920 The system needs to be predefined. 639 00:27:50,920 --> 00:27:52,840 When you're committing, you also have 640 00:27:52,840 --> 00:27:56,200 to commit to the algorithms or have pre-agreed 641 00:27:56,200 --> 00:27:57,910 upon algorithms, because otherwise, you 642 00:27:57,910 --> 00:28:00,310 could do something-- no, I committed to r. 643 00:28:00,310 --> 00:28:02,080 5 was my blinding factor. 644 00:28:02,080 --> 00:28:07,210 You need to have protocols set up beforehand, which you never 645 00:28:07,210 --> 00:28:08,320 know, that could be some-- 646 00:28:08,320 --> 00:28:09,445 if you say, I'm committing. 647 00:28:09,445 --> 00:28:10,872 Here's this value. 648 00:28:10,872 --> 00:28:11,830 How are you committing? 649 00:28:11,830 --> 00:28:13,380 What hash functions? 650 00:28:13,380 --> 00:28:14,920 What are you doing? 651 00:28:14,920 --> 00:28:16,948 But that's obvious. 652 00:28:16,948 --> 00:28:18,490 It might not be super obvious, so you 653 00:28:18,490 --> 00:28:21,580 have to be careful on that. 654 00:28:21,580 --> 00:28:23,090 So this is now blinding. 655 00:28:23,090 --> 00:28:29,350 And it's hidden, and it's still binding. 656 00:28:29,350 --> 00:28:31,240 You can't change it to 6. 657 00:28:31,240 --> 00:28:34,500 I think that's the next slide, wait. 658 00:28:34,500 --> 00:28:39,030 So you can't change this to 6 and change to a different r. 659 00:28:39,030 --> 00:28:40,470 I mean, you could, but you'd still 660 00:28:40,470 --> 00:28:43,370 have to do a lot of computation. 661 00:28:43,370 --> 00:28:46,680 And this is now-- 662 00:28:46,680 --> 00:28:47,880 some things get easier. 663 00:28:47,880 --> 00:28:56,590 So before if you really wanted to reveal that it was 6, 664 00:28:56,590 --> 00:28:58,380 you basically can. 665 00:28:58,380 --> 00:29:02,010 Because there's a single output for 6, and it just 666 00:29:02,010 --> 00:29:02,900 doesn't match this. 667 00:29:02,900 --> 00:29:06,210 So there's not-- if you have a single chosen value that you 668 00:29:06,210 --> 00:29:09,218 want to reveal that's not the one that you committed to-- 669 00:29:09,218 --> 00:29:10,260 you're basically stopped. 670 00:29:10,260 --> 00:29:12,990 There's no way to get around it even computationally. 671 00:29:12,990 --> 00:29:15,030 With this-- that's not true. 672 00:29:15,030 --> 00:29:17,640 It's like I really want to reveal 6, 673 00:29:17,640 --> 00:29:21,480 I can come up with a different r such that the hash of 6 674 00:29:21,480 --> 00:29:23,400 and our prime is that. 675 00:29:23,400 --> 00:29:26,620 And then that's now computational-- 676 00:29:26,620 --> 00:29:28,900 slight distinction. 677 00:29:28,900 --> 00:29:31,340 It's still binding computationally. 678 00:29:31,340 --> 00:29:35,342 But before, chosen values may not have been. 679 00:29:35,342 --> 00:29:36,800 So that's, I guess, the difference. 680 00:29:36,800 --> 00:29:38,750 It's computationally binding for any value. 681 00:29:38,750 --> 00:29:41,773 But for a specific value, it might be-- 682 00:29:41,773 --> 00:29:43,190 not information theoretic, but you 683 00:29:43,190 --> 00:29:46,130 can't do it, because the hash function doesn't help you 684 00:29:46,130 --> 00:29:47,300 there. 685 00:29:47,300 --> 00:29:48,950 So what else do we want to do? 686 00:29:48,950 --> 00:29:52,620 You're saying we need more. 687 00:29:52,620 --> 00:29:56,180 We want to be able to prove things about the commitments. 688 00:29:56,180 --> 00:29:59,120 So we need some kind of homomorphic commitments. 689 00:29:59,120 --> 00:30:01,880 And we've seen the homomorphic properties 690 00:30:01,880 --> 00:30:04,760 of these elliptic curve points, which are really nice-- 691 00:30:04,760 --> 00:30:06,800 where you can add private keys or add 692 00:30:06,800 --> 00:30:10,310 scalars, and that's the same as adding these points on a curve. 693 00:30:10,310 --> 00:30:14,010 So let's try that. 694 00:30:14,010 --> 00:30:15,360 We want something like this. 695 00:30:15,360 --> 00:30:18,780 We want a-- commit to x, commit to y, 696 00:30:18,780 --> 00:30:21,350 and get these commitments-- a and b. 697 00:30:21,350 --> 00:30:25,260 And then we want to reveal z, which is x plus y. 698 00:30:28,910 --> 00:30:30,840 And then we want the verify function 699 00:30:30,840 --> 00:30:35,160 that's put z in and a and b-- either a plus b 700 00:30:35,160 --> 00:30:38,310 or a and b separately and return true. 701 00:30:38,310 --> 00:30:41,940 So we don't want to reveal x and y separately. 702 00:30:41,940 --> 00:30:45,540 We will reveal the sum of x plus y. 703 00:30:45,540 --> 00:30:48,450 And then we will reveal-- 704 00:30:48,450 --> 00:30:51,120 and then we'll have the commitments themselves. 705 00:30:51,120 --> 00:30:53,400 So since these are the same operators, 706 00:30:53,400 --> 00:30:55,985 it'd be cool if that worked. 707 00:30:55,985 --> 00:30:56,860 This is what we want. 708 00:31:01,030 --> 00:31:02,110 So that's not that bad. 709 00:31:02,110 --> 00:31:04,780 But we also want all those properties where it's hiding, 710 00:31:04,780 --> 00:31:07,100 and it's binding and things like that. 711 00:31:07,100 --> 00:31:10,160 So what should we try? 712 00:31:13,350 --> 00:31:18,063 First idea is-- this would be useful. 713 00:31:18,063 --> 00:31:18,980 How can we build this? 714 00:31:18,980 --> 00:31:21,680 We want to-- we can reveal sums without revealing 715 00:31:21,680 --> 00:31:24,720 individual parts that we've committed to. 716 00:31:24,720 --> 00:31:29,330 So probably the first idea is let's just use 717 00:31:29,330 --> 00:31:30,650 private keys and public keys. 718 00:31:30,650 --> 00:31:33,740 Let's use a times g-- 719 00:31:33,740 --> 00:31:35,080 that kind of thing. 720 00:31:35,080 --> 00:31:37,000 Oh, oh-- I forgot the joke-- 721 00:31:37,000 --> 00:31:39,986 was going to say, gee, how can we build this? g-- 722 00:31:39,986 --> 00:31:43,370 it's g. 723 00:31:43,370 --> 00:31:44,585 You want a commitment to act. 724 00:31:44,585 --> 00:31:45,710 You want a commitment to y. 725 00:31:45,710 --> 00:31:48,020 You want to reveal z is x plus y. 726 00:31:48,020 --> 00:31:49,100 So what if you did this? 727 00:31:49,100 --> 00:31:51,890 You said, I'm going to make a point on the curve-- 728 00:31:51,890 --> 00:31:55,100 x, which is just my value x times g-- 729 00:31:55,100 --> 00:31:59,240 point on the curve y, which is my value y times g. 730 00:31:59,240 --> 00:32:03,120 This does have that homomorphic property. 731 00:32:03,120 --> 00:32:05,395 But is this binding? 732 00:32:12,440 --> 00:32:14,110 It is. 733 00:32:14,110 --> 00:32:18,700 I can't come up with a different x that gets me to that point. 734 00:32:18,700 --> 00:32:20,680 So multiplying by the generator point 735 00:32:20,680 --> 00:32:23,690 is a hash function in that you're not going 736 00:32:23,690 --> 00:32:25,590 to be able to find collisions. 737 00:32:25,590 --> 00:32:28,300 So you can't find two different private keys that 738 00:32:28,300 --> 00:32:29,700 give you the same public key. 739 00:32:32,020 --> 00:32:32,770 Sometimes you can. 740 00:32:32,770 --> 00:32:37,030 [LAUGHS] So I don't want-- 741 00:32:37,030 --> 00:32:41,740 in this specific case, this is binding. 742 00:32:41,740 --> 00:32:43,660 There's a bunch of asterisks that's there. 743 00:32:43,660 --> 00:32:46,730 I probably shouldn't. 744 00:32:46,730 --> 00:32:47,600 It gets complicated. 745 00:32:47,600 --> 00:32:51,237 There are some curves where it's not. 746 00:32:51,237 --> 00:32:52,570 And some systems where it's not. 747 00:32:52,570 --> 00:32:54,320 And there have been problems in currencies 748 00:32:54,320 --> 00:32:56,700 where people assume that this is the case-- 749 00:32:56,700 --> 00:32:57,800 I think in Monero. 750 00:32:57,800 --> 00:32:58,300 But, yeah. 751 00:32:58,300 --> 00:33:00,260 AUDIENCE: Can you draw an example of curve? 752 00:33:00,260 --> 00:33:01,010 TADGE DRYJA: Yeah. 753 00:33:01,010 --> 00:33:15,470 So they-- the curve for Bitcoin, I think it's y q? 754 00:33:15,470 --> 00:33:19,630 No, y squared equals x cubed plus or minus? 755 00:33:19,630 --> 00:33:20,980 Minus 7, I think. 756 00:33:20,980 --> 00:33:22,470 That's it. 757 00:33:22,470 --> 00:33:26,050 It looks sort of like this. 758 00:33:26,050 --> 00:33:29,320 It's symmetric, which that isn't. 759 00:33:29,320 --> 00:33:32,930 I think I had it in an earlier one. 760 00:33:32,930 --> 00:33:36,950 And then the x-axis is like this is the origin-ish. 761 00:33:36,950 --> 00:33:40,310 And then the idea is you have points and you can-- 762 00:33:40,310 --> 00:33:46,490 the sum is if you have the sum there 763 00:33:46,490 --> 00:33:49,670 it's going to be here, except it's here. 764 00:33:49,670 --> 00:33:51,260 So the idea is 3. 765 00:33:51,260 --> 00:33:56,750 Any line you draw more or less will intersect at 3 points 766 00:33:56,750 --> 00:33:59,120 unless it intersects at a tangent, 767 00:33:59,120 --> 00:34:02,870 or if it's straight up, then you say 768 00:34:02,870 --> 00:34:07,050 it intersects at the point at infinity. 769 00:34:07,050 --> 00:34:10,520 But any random line you make will probably 770 00:34:10,520 --> 00:34:14,030 intersect in 3 different points. 771 00:34:14,030 --> 00:34:17,989 And so then if this is a, b, and c, 772 00:34:17,989 --> 00:34:20,840 we define a plus b plus c to be 0. 773 00:34:20,840 --> 00:34:24,199 So then we would define b plus c to be here-- 774 00:34:24,199 --> 00:34:26,538 negative a. 775 00:34:26,538 --> 00:34:30,710 And the negation is you flip it over the x-axis. 776 00:34:30,710 --> 00:34:34,060 So I talked about this a little bit before. 777 00:34:34,060 --> 00:34:39,219 But the idea is you've still got this nice property where you 778 00:34:39,219 --> 00:34:41,260 pick a point on here-- g-- 779 00:34:41,260 --> 00:34:44,860 everyone picks a random point, and it's a generator. 780 00:34:44,860 --> 00:34:46,570 Because if you keep adding. 781 00:34:46,570 --> 00:34:49,920 So here's g-- sorry-- and take the tangent-- 782 00:34:49,920 --> 00:34:52,030 find this is 2g. 783 00:34:52,030 --> 00:34:53,480 Take the tangent here-- 784 00:34:53,480 --> 00:34:56,020 maybe it goes here to 3g. 785 00:34:56,020 --> 00:35:00,100 Take the tangent here-- or no, that would be 4g-- sorry-- 786 00:35:00,100 --> 00:35:00,920 this would be 8g. 787 00:35:00,920 --> 00:35:05,310 So you can keep adding the g, and you'll eventually 788 00:35:05,310 --> 00:35:08,197 cover the entire curve and get back to g. 789 00:35:08,197 --> 00:35:09,780 So that's why it's sort of a generator 790 00:35:09,780 --> 00:35:14,420 because it lets you get to every point by just multiplying. 791 00:35:14,420 --> 00:35:19,410 So the nice property here is if you have some number x times 792 00:35:19,410 --> 00:35:24,570 g, and some number y times g-- 793 00:35:24,570 --> 00:35:34,470 you can also do x plus y times g, and that equals xg plus yg. 794 00:35:34,470 --> 00:35:36,970 So you can add the points. 795 00:35:36,970 --> 00:35:39,690 And that's the same as adding the scalars 796 00:35:39,690 --> 00:35:41,810 before you multiply by g. 797 00:35:41,810 --> 00:35:47,810 And that's what basically we use for everything. 798 00:35:47,810 --> 00:35:50,490 And then the idea is you can't go back. 799 00:35:50,490 --> 00:35:53,870 Given a point, let's say we call this big X-- 800 00:35:53,870 --> 00:35:56,960 given a point-- big X, which is little x times g-- 801 00:35:56,960 --> 00:35:58,370 you can't figure out what x is. 802 00:35:58,370 --> 00:36:00,205 So you can't divide by a point. 803 00:36:00,205 --> 00:36:01,580 You can't say oh, given x, I want 804 00:36:01,580 --> 00:36:05,570 to do x divided by g, which is little x. 805 00:36:05,570 --> 00:36:07,520 I can't divide some stuff. 806 00:36:07,520 --> 00:36:10,210 I can multiply by repeatedly adding. 807 00:36:10,210 --> 00:36:13,340 But division is not defined. 808 00:36:13,340 --> 00:36:18,390 So this is binding, but I don't want to-- 809 00:36:18,390 --> 00:36:20,040 there's asterisks that's there. 810 00:36:20,040 --> 00:36:23,520 But it's not blinded. 811 00:36:23,520 --> 00:36:26,940 So same problem is the raw hash-based commitment 812 00:36:26,940 --> 00:36:31,140 where if I want to commit to the number 5, and 5 times g, 813 00:36:31,140 --> 00:36:35,760 and that's my point that I'm going to use for my commitment. 814 00:36:35,760 --> 00:36:38,250 Same problem-- 4-loop will pretty quickly 815 00:36:38,250 --> 00:36:41,500 show you that was 5. 816 00:36:41,500 --> 00:36:48,980 How about-- this seems like a good idea. 817 00:36:48,980 --> 00:36:50,870 I should say it in the less obviously-- 818 00:36:50,870 --> 00:36:52,018 it's not a good idea way. 819 00:36:52,018 --> 00:36:54,110 [LAUGHS] 820 00:36:54,110 --> 00:36:59,508 So why don't we add a blinding factor? 821 00:36:59,508 --> 00:37:00,800 What would the problem be here? 822 00:37:03,870 --> 00:37:05,250 I want to commit to 5. 823 00:37:05,250 --> 00:37:07,770 I'm going to add some random number r 824 00:37:07,770 --> 00:37:11,310 and then multiply that sum by g, and then 825 00:37:11,310 --> 00:37:13,800 when I want to reveal that I was committed to 5-- 826 00:37:13,800 --> 00:37:17,035 I reveal 5 and r. 827 00:37:17,035 --> 00:37:20,304 AUDIENCE: You don't know which one is [INAUDIBLE]?? 828 00:37:20,304 --> 00:37:22,600 TADGE DRYJA: No, but I can say, look, the first-- 829 00:37:22,600 --> 00:37:28,570 well, yeah, the problem is addition is easy to break. 830 00:37:31,370 --> 00:37:36,180 When I committed to 5 plus r, I revealed 5 and r, 831 00:37:36,180 --> 00:37:37,330 but it's not binding. 832 00:37:37,330 --> 00:37:41,140 I can find r prime, which is 5 plus r minus 6. 833 00:37:41,140 --> 00:37:44,440 And then 6 plus that r prime is going to be 6 plus 5 834 00:37:44,440 --> 00:37:46,450 plus r minus 6. 835 00:37:46,450 --> 00:37:49,030 I can compute whatever r prime I want 836 00:37:49,030 --> 00:37:52,000 and whatever number I want to reveal later. 837 00:37:52,000 --> 00:37:55,590 So this isn't binding anymore. 838 00:37:55,590 --> 00:37:57,880 I'm now adding a random thing in, 839 00:37:57,880 --> 00:37:59,980 and I'm committing to the sum of the thing I want 840 00:37:59,980 --> 00:38:00,790 and a random thing. 841 00:38:00,790 --> 00:38:07,520 But it's not binding because that addition, I can play with. 842 00:38:07,520 --> 00:38:10,850 So how about this? 843 00:38:10,850 --> 00:38:13,970 I'll hash 5 and concatenate r and then 844 00:38:13,970 --> 00:38:16,880 multiply that hashed output by g. 845 00:38:20,400 --> 00:38:23,700 Maybe, but then it's no longer homomorphic-- 846 00:38:23,700 --> 00:38:25,920 then I can't add. 847 00:38:25,920 --> 00:38:33,420 So if I have the hash of 5 and r1 times g and then 848 00:38:33,420 --> 00:38:37,905 the hash of 7 and r 2 times g-- 849 00:38:37,905 --> 00:38:42,270 I can't add these anymore And then have the 5s 850 00:38:42,270 --> 00:38:44,777 and 7s add up to 12-- 851 00:38:44,777 --> 00:38:45,360 it won't work. 852 00:38:45,360 --> 00:38:46,987 Because now it's a hash. 853 00:38:46,987 --> 00:38:48,570 And I've just got these hashes adding, 854 00:38:48,570 --> 00:38:50,590 and you don't really get any meaning there. 855 00:38:50,590 --> 00:38:52,445 So that doesn't work either. 856 00:38:52,445 --> 00:38:53,070 So we're stuck. 857 00:38:56,220 --> 00:38:58,720 Then the way you do it is totally non-obvious. 858 00:38:58,720 --> 00:39:03,570 And introducing g's fraternal twin-- h. 859 00:39:03,570 --> 00:39:07,342 [LAUGHS] You make another point on the curve, 860 00:39:07,342 --> 00:39:09,300 and you call it h, which is the letter after g. 861 00:39:12,380 --> 00:39:15,050 It's another generator point distinct from g. 862 00:39:15,050 --> 00:39:17,720 So you pick one-- 863 00:39:17,720 --> 00:39:20,390 here's h. 864 00:39:20,390 --> 00:39:23,270 You also need to make sure that nobody knows 865 00:39:23,270 --> 00:39:27,150 n such that n times g equals h. 866 00:39:27,150 --> 00:39:29,223 That n might exist, but you want to be sure 867 00:39:29,223 --> 00:39:30,890 that no one knows what it is because you 868 00:39:30,890 --> 00:39:38,010 know how to move between g and h, then that'll break this. 869 00:39:38,010 --> 00:39:41,760 But if you take two random points, g was randomly chosen, 870 00:39:41,760 --> 00:39:45,360 and you chose a random h, this shouldn't be possible. 871 00:39:45,360 --> 00:39:47,370 That would be breaking the discreet log problem. 872 00:39:47,370 --> 00:39:52,227 So I shouldn't be able to compute h divided by g-- 873 00:39:52,227 --> 00:39:53,810 you shouldn't be able to compute that. 874 00:39:56,720 --> 00:40:00,860 And so I think in a lot of cases, they'll define h as-- 875 00:40:00,860 --> 00:40:04,730 take the hash of g's x-coordinate and then assign 876 00:40:04,730 --> 00:40:06,877 that to the x-coordinate for h-- 877 00:40:06,877 --> 00:40:07,710 something like that. 878 00:40:07,710 --> 00:40:10,065 So it looks pretty random-- 879 00:40:10,065 --> 00:40:11,600 should be able to find it. 880 00:40:11,600 --> 00:40:15,380 So we've got another arbitrary point on the curve 881 00:40:15,380 --> 00:40:19,670 that we're going to start using for multiplying things. 882 00:40:19,670 --> 00:40:21,800 And so this is basically a Pedersen commitment, 883 00:40:21,800 --> 00:40:24,990 which sounds involved and it gets involved, 884 00:40:24,990 --> 00:40:27,750 but really it's not. 885 00:40:27,750 --> 00:40:29,130 At its core, it's not too bad. 886 00:40:29,130 --> 00:40:31,230 It's saying we're going to have a blinding 887 00:40:31,230 --> 00:40:34,290 factor in the actual value we're committing to. 888 00:40:34,290 --> 00:40:36,810 And so now I'm multiplying the blinding factor 889 00:40:36,810 --> 00:40:41,040 by g and the actual value by h. 890 00:40:41,040 --> 00:40:43,500 And I'm just adding those two up. 891 00:40:43,500 --> 00:40:46,890 So you know how we can do that? 892 00:40:46,890 --> 00:40:51,210 If my actual value is 5, I take 5h by taking the tangent-- 893 00:40:51,210 --> 00:40:54,720 getting 2h-- take the tangent again-- getting 4h, 894 00:40:54,720 --> 00:40:58,380 and then adding 4h and h by drawing the line between them-- 895 00:40:58,380 --> 00:40:59,970 I'll get 5h. 896 00:40:59,970 --> 00:41:01,470 And then I'll also get r. r's going 897 00:41:01,470 --> 00:41:04,230 to be some giant random thing. 898 00:41:04,230 --> 00:41:07,440 R's not going to be like 5. r's going to be a 256-bit random 899 00:41:07,440 --> 00:41:13,680 number, and that will obscure what h was-- 900 00:41:13,680 --> 00:41:17,970 sorry. what v was because I added them together. 901 00:41:17,970 --> 00:41:21,880 So this is binding unless I know the ratio. 902 00:41:21,880 --> 00:41:24,760 Unless I know h over g, or g over h-- whatever-- 903 00:41:24,760 --> 00:41:27,870 same thing-- 904 00:41:27,870 --> 00:41:30,130 I can't come up with another r and v 905 00:41:30,130 --> 00:41:32,200 pair that gets me back to x. 906 00:41:34,950 --> 00:41:37,112 So I can try. 907 00:41:37,112 --> 00:41:39,390 There is one. 908 00:41:39,390 --> 00:41:42,000 There's probably bazillions of-- 909 00:41:42,000 --> 00:41:43,860 if I could find a different r, I could then 910 00:41:43,860 --> 00:41:47,730 reveal that v was 8 instead of 7. 911 00:41:47,730 --> 00:41:51,060 But I can't find that r, because I need to know some way 912 00:41:51,060 --> 00:41:52,590 to get between g and h-- 913 00:41:52,590 --> 00:41:55,490 some factor n where n times g equals h. 914 00:41:55,490 --> 00:41:58,720 If I don't know that, I can't do this. 915 00:41:58,720 --> 00:42:00,360 It is binding. 916 00:42:00,360 --> 00:42:01,890 It's also hiding. 917 00:42:01,890 --> 00:42:05,010 So you might successfully guess-- 918 00:42:05,010 --> 00:42:06,870 I might commit vehicles 5-- 919 00:42:06,870 --> 00:42:10,870 do some random number r times g plus 5h, 920 00:42:10,870 --> 00:42:12,670 and you might guess correctly. 921 00:42:12,670 --> 00:42:16,450 But this should have been g-- oops-- sorry. 922 00:42:16,450 --> 00:42:17,700 This is g. 923 00:42:17,700 --> 00:42:21,210 But if I have some really long, random number times g, 924 00:42:21,210 --> 00:42:25,590 it's also an x, and you're not going to be able to guess that. 925 00:42:25,590 --> 00:42:29,020 So this is also hiding. 926 00:42:29,020 --> 00:42:31,640 And it's homomorphic. 927 00:42:31,640 --> 00:42:36,980 So x is r1g plus v1h. 928 00:42:36,980 --> 00:42:41,300 y is r2g plus v2h. 929 00:42:41,300 --> 00:42:47,060 And what if I want to prove that z is value 1 plus value 2 930 00:42:47,060 --> 00:42:50,970 without revealing them individually? 931 00:42:50,970 --> 00:42:52,680 Can you see how I could do that? 932 00:42:58,860 --> 00:43:00,660 I can reveal both r's individually. 933 00:43:00,660 --> 00:43:03,480 Well, no, sorry-- I cannot reveal both r's individually 934 00:43:03,480 --> 00:43:08,090 because then you might be able to figure out the values. 935 00:43:08,090 --> 00:43:11,730 But I can reveal the sum of the r's and the sum of the v's. 936 00:43:11,730 --> 00:43:15,480 So I'm going to define a point z, which 937 00:43:15,480 --> 00:43:18,150 is point x plus point y. 938 00:43:18,150 --> 00:43:20,640 And that's just going to be the sum of the r values-- 939 00:43:20,640 --> 00:43:22,830 the sum of those random values times 940 00:43:22,830 --> 00:43:25,620 g plus the sum of the actual values 941 00:43:25,620 --> 00:43:28,890 I've committed to times h. 942 00:43:28,890 --> 00:43:30,760 And then I reveal the sums. 943 00:43:30,760 --> 00:43:31,910 I reveal this-- 944 00:43:31,910 --> 00:43:33,150 I reveal that. 945 00:43:33,150 --> 00:43:37,590 And then the verifier can do the math themselves. 946 00:43:40,650 --> 00:43:41,820 It's a little hard. 947 00:43:41,820 --> 00:43:44,670 I'm revealing r and v, which is equal to this. 948 00:43:44,670 --> 00:43:47,280 But I'm not revealing these separately. 949 00:43:47,280 --> 00:43:49,500 I only reveal the sums. 950 00:43:49,500 --> 00:43:51,330 And then the verifier can check-- 951 00:43:51,330 --> 00:43:54,480 is this r they gave times g plus this v they gave times 952 00:43:54,480 --> 00:43:59,780 h equal to these two points added together? 953 00:43:59,780 --> 00:44:04,700 And if it is, they've proven the sum. 954 00:44:04,700 --> 00:44:11,170 So, for example, it's binding, hiding, and homomorphic. 955 00:44:11,170 --> 00:44:14,500 So this would allow us to make proofs. 956 00:44:23,310 --> 00:44:27,240 Binding, hiding, homomorphic-- you reveal the sum of the r's. 957 00:44:27,240 --> 00:44:30,852 You reveal the sum of the v's-- 958 00:44:30,852 --> 00:44:32,480 it works. 959 00:44:32,480 --> 00:44:40,810 So basically now instead of coin amounts, which are 8-byte-- 960 00:44:40,810 --> 00:44:43,010 they're in 64s-- 961 00:44:43,010 --> 00:44:45,050 I just provide elliptic curve points, 962 00:44:45,050 --> 00:44:48,530 which are 33 bytes, so it's a bit bigger-- 963 00:44:48,530 --> 00:44:49,580 not a huge deal. 964 00:44:49,580 --> 00:44:52,010 I can put another 20-something bytes 965 00:44:52,010 --> 00:44:54,930 in my outputs-- no big deal. 966 00:44:54,930 --> 00:45:01,590 And then I provide a proof by revealing these sums each time. 967 00:45:01,590 --> 00:45:05,200 So I prove that w plus x equals y plus z. 968 00:45:05,200 --> 00:45:09,600 And everyone can see this little w amount of coins-- 969 00:45:09,600 --> 00:45:10,830 there's actually y coins. 970 00:45:10,830 --> 00:45:12,030 There's actually x coins. 971 00:45:12,030 --> 00:45:13,560 There's actually z coins. 972 00:45:13,560 --> 00:45:20,000 And there's a blinding factor that all the participants 973 00:45:20,000 --> 00:45:22,190 have to keep track of. 974 00:45:22,190 --> 00:45:23,800 So the receiver's views-- 975 00:45:23,800 --> 00:45:26,410 they learn their own v and r. 976 00:45:29,302 --> 00:45:30,760 When someone sends, they would have 977 00:45:30,760 --> 00:45:34,800 to tell the receiver, hey, here's r4. 978 00:45:34,800 --> 00:45:36,840 The sender makes up r4. 979 00:45:36,840 --> 00:45:39,960 And they can just compute-- let's make a random r3. 980 00:45:39,960 --> 00:45:47,370 And then compute r4 such that r4 plus r3 equals r1 plus r2. 981 00:45:47,370 --> 00:45:50,860 They need to make sure that the randomnesses add up, 982 00:45:50,860 --> 00:45:53,430 which is easy because they're regular scalars, 983 00:45:53,430 --> 00:45:56,980 and the sender has full control over r3 and r4. 984 00:45:56,980 --> 00:45:59,760 So, basically, make random ones until you get to the last one. 985 00:45:59,760 --> 00:46:01,890 And then make the last one such that they all 986 00:46:01,890 --> 00:46:03,015 add up to the right number. 987 00:46:05,250 --> 00:46:11,970 And then the sender can say, here's your r4 and here's 2. 988 00:46:11,970 --> 00:46:13,380 You're getting 2 coins. 989 00:46:13,380 --> 00:46:16,050 And the receiver gets those two numbers and says, 990 00:46:16,050 --> 00:46:19,100 I can see that this transaction commits to z-- 991 00:46:19,100 --> 00:46:20,310 a point. 992 00:46:20,310 --> 00:46:25,980 And you gave me an r and a v that when I do the operation-- 993 00:46:25,980 --> 00:46:26,730 I get z. 994 00:46:26,730 --> 00:46:28,890 So I know that successfully, you've 995 00:46:28,890 --> 00:46:30,990 revealed that these are two coins. 996 00:46:30,990 --> 00:46:33,180 And I can use these values later when 997 00:46:33,180 --> 00:46:34,380 I want to send my own coins. 998 00:46:38,400 --> 00:46:42,490 So this works, but there's more problems. 999 00:46:42,490 --> 00:46:44,890 [LAUGHS] Any idea what the next big problem is? 1000 00:46:44,890 --> 00:46:45,390 Yeah. 1001 00:46:45,390 --> 00:46:47,324 AUDIENCE: If there are only two outputs, 1002 00:46:47,324 --> 00:46:50,770 and then c's r4 and d4-- 1003 00:46:50,770 --> 00:46:53,770 they could be able to [INAUDIBLE] r3 and d3, right? 1004 00:46:53,770 --> 00:46:55,300 TADGE DRYJA: Yeah. 1005 00:46:55,300 --> 00:46:56,620 But that's OK. 1006 00:46:56,620 --> 00:46:58,840 I mean, there's no way around that. 1007 00:46:58,840 --> 00:47:00,670 If there's only one input-- 1008 00:47:00,670 --> 00:47:08,620 or wait-- if there's only two outputs, 1009 00:47:08,620 --> 00:47:12,830 so if the receiver learns these, they 1010 00:47:12,830 --> 00:47:14,540 will be able to distinguish-- if you 1011 00:47:14,540 --> 00:47:18,260 know the total amount of inputs, and there's only one other. 1012 00:47:18,260 --> 00:47:21,438 You can just subtract and figure it out. 1013 00:47:21,438 --> 00:47:22,730 So there's all sorts of things. 1014 00:47:22,730 --> 00:47:25,610 If there's only one output, that person 1015 00:47:25,610 --> 00:47:27,170 knows it's the sum of all the inputs. 1016 00:47:27,170 --> 00:47:29,270 AUDIENCE: You don't know-- in this case, 1017 00:47:29,270 --> 00:47:31,346 you don't know the total input, right? 1018 00:47:31,346 --> 00:47:32,210 TADGE DRYJA: Right. 1019 00:47:32,210 --> 00:47:36,830 In this case, they don't have to reveal to you the v's-- they 1020 00:47:36,830 --> 00:47:43,330 just have to reveal that 2 plus y equals w plus x. 1021 00:47:43,330 --> 00:47:46,330 So you don't have to learn their input amounts. 1022 00:47:49,340 --> 00:47:54,700 If there's only one output, then you learn if this is 2, 1023 00:47:54,700 --> 00:47:56,080 these must have added up to 2. 1024 00:47:56,080 --> 00:47:59,585 But I don't learn exactly which. 1025 00:47:59,585 --> 00:48:01,403 So this is useful. 1026 00:48:01,403 --> 00:48:02,570 There's still a big problem. 1027 00:48:08,322 --> 00:48:12,080 r1 plus r2 is r3 plus r4-- you can prove w plus x equals y 1028 00:48:12,080 --> 00:48:12,840 plus c-- 1029 00:48:12,840 --> 00:48:13,900 it works. 1030 00:48:13,900 --> 00:48:14,400 It's great. 1031 00:48:14,400 --> 00:48:17,475 AUDIENCE: Do nodes only mean the bigger transaction-- 1032 00:48:17,475 --> 00:48:20,250 to know that the inputs you put [INAUDIBLE]?? 1033 00:48:20,250 --> 00:48:21,900 TADGE DRYJA: Yep. 1034 00:48:21,900 --> 00:48:26,637 nodes can just compute these numbers, and they're good. 1035 00:48:26,637 --> 00:48:27,970 So one thing you could do here-- 1036 00:48:30,410 --> 00:48:30,910 OK, wait. 1037 00:48:30,910 --> 00:48:33,580 So there's one thing that you can do to break it. 1038 00:48:33,580 --> 00:48:35,030 But it's not a big deal. 1039 00:48:35,030 --> 00:48:36,340 And then there's another thing-- you need a break that's 1040 00:48:36,340 --> 00:48:37,090 a really big deal. 1041 00:48:37,090 --> 00:48:37,590 Yeah. 1042 00:48:37,590 --> 00:48:39,190 AUDIENCE: Since you're proving sums, 1043 00:48:39,190 --> 00:48:41,857 is it that you can have a higher likelihood of proving something 1044 00:48:41,857 --> 00:48:42,580 that doesn't-- 1045 00:48:42,580 --> 00:48:46,570 like that wasn't actually true? 1046 00:48:46,570 --> 00:48:50,620 TADGE DRYJA: Yeah, but how exactly? 1047 00:48:50,620 --> 00:48:55,800 So one thing you could do is-- 1048 00:48:55,800 --> 00:48:56,508 I think, I said-- 1049 00:48:56,508 --> 00:48:58,717 so, basically, you can verify it and put in outputs-- 1050 00:48:58,717 --> 00:49:00,870 add up all the points-- make sure they're equal. 1051 00:49:00,870 --> 00:49:03,360 You reveal r and v to the person receiving. 1052 00:49:03,360 --> 00:49:04,740 And you don't want to forget r. 1053 00:49:04,740 --> 00:49:06,280 r is now a private key. 1054 00:49:06,280 --> 00:49:07,610 If you forget r-- 1055 00:49:07,610 --> 00:49:08,380 you're stuck. 1056 00:49:08,380 --> 00:49:10,620 You can't prove anything anymore. 1057 00:49:10,620 --> 00:49:12,840 You can make invalid outputs, which 1058 00:49:12,840 --> 00:49:15,600 are just points with no known r and v. 1059 00:49:15,600 --> 00:49:17,400 But nobody should accept those. 1060 00:49:17,400 --> 00:49:20,270 So you can do this where-- 1061 00:49:20,270 --> 00:49:21,230 I have no idea what-- 1062 00:49:21,230 --> 00:49:22,397 there is no commitment here. 1063 00:49:22,397 --> 00:49:24,020 Maybe these have valid commitments, 1064 00:49:24,020 --> 00:49:27,720 but this is a point, which is w plus x minus y. 1065 00:49:27,720 --> 00:49:33,590 And there's no known r values or v values for these things. 1066 00:49:33,590 --> 00:49:37,040 And from the network's point of view, this will still be valid. 1067 00:49:37,040 --> 00:49:40,880 The networks are saying, well, w plus x equals y plus z-- 1068 00:49:40,880 --> 00:49:42,480 we're good. 1069 00:49:42,480 --> 00:49:45,140 But then anyone accepting that transaction-- 1070 00:49:45,140 --> 00:49:48,060 you're not going to be able to give them an r value. 1071 00:49:48,060 --> 00:49:50,600 And so they're not going to say this is actual money. 1072 00:49:50,600 --> 00:49:54,060 So this is possible, but it's not a huge problem 1073 00:49:54,060 --> 00:49:57,845 because you can destroy your own money. 1074 00:49:57,845 --> 00:49:59,970 You can already do that in a million different ways 1075 00:49:59,970 --> 00:50:01,170 in Bitcoin. 1076 00:50:01,170 --> 00:50:04,590 But if you send to it to an output amount that 1077 00:50:04,590 --> 00:50:07,260 doesn't have an actual r and v value-- that doesn't have 1078 00:50:07,260 --> 00:50:09,180 a valid Pedersen commitment-- those coins 1079 00:50:09,180 --> 00:50:11,210 can essentially be destroyed because no one's 1080 00:50:11,210 --> 00:50:16,720 going to be able to figure out r's and stuff for here. 1081 00:50:16,720 --> 00:50:18,280 So that's one issue-- 1082 00:50:18,280 --> 00:50:19,280 not a big issue. 1083 00:50:19,280 --> 00:50:20,950 Just don't do that. 1084 00:50:20,950 --> 00:50:22,297 Don't ruin your own money. 1085 00:50:22,297 --> 00:50:24,130 Make sure you always have valid commitments. 1086 00:50:24,130 --> 00:50:26,500 And when you're accepting payments always 1087 00:50:26,500 --> 00:50:32,440 make sure that you're given the values and the random blinding 1088 00:50:32,440 --> 00:50:33,530 factors. 1089 00:50:33,530 --> 00:50:38,190 So that's one little risk but not the big problem. 1090 00:50:38,190 --> 00:50:39,940 Anyone have an idea about the big problem? 1091 00:50:39,940 --> 00:50:42,550 So as a hint-- 1092 00:50:42,550 --> 00:50:45,010 all of these things, and I haven't written it because it 1093 00:50:45,010 --> 00:50:49,620 gets really redundant-- all of these things are like mod p, 1094 00:50:49,620 --> 00:50:57,990 which is some giant prime number that's 2 to 56 minus 17, 1095 00:50:57,990 --> 00:51:00,090 or it's not-- 1096 00:51:00,090 --> 00:51:06,593 in the curve, ed25509 it's 2 to the 255 minus 19. 1097 00:51:06,593 --> 00:51:08,010 So that's an easy one to remember. 1098 00:51:08,010 --> 00:51:10,880 So that's why they call it curve 22519. 1099 00:51:10,880 --> 00:51:16,130 In bitcoin, it's 2 to the 256 minus some numbers that 1100 00:51:16,130 --> 00:51:18,860 are not too huge. 1101 00:51:18,860 --> 00:51:22,680 So since all of these things are modulo-- 1102 00:51:22,680 --> 00:51:24,650 some big prime number-- 1103 00:51:24,650 --> 00:51:28,242 what's a potential problem here? 1104 00:51:28,242 --> 00:51:31,230 It's a big problem or in some ways 1105 00:51:31,230 --> 00:51:34,748 the opposite of a big problem. 1106 00:51:34,748 --> 00:51:35,770 Not a small problem. 1107 00:51:35,770 --> 00:51:39,925 [LAUGHS] The opposite of a big problem but not small-- 1108 00:51:42,700 --> 00:51:43,890 big negative problem. 1109 00:51:43,890 --> 00:51:47,410 [LAUGHS] 1110 00:51:47,410 --> 00:51:51,190 You can basically commit to negative values. 1111 00:51:51,190 --> 00:51:59,460 So I send negative 99 coins here, positive 108 coins here-- 1112 00:51:59,460 --> 00:52:01,620 the numbers all work out. 1113 00:52:01,620 --> 00:52:03,030 So you don't have negative. 1114 00:52:03,030 --> 00:52:06,980 Usually, if you're doing mod-some integer, 1115 00:52:06,980 --> 00:52:08,670 you don't think of it as negative, 1116 00:52:08,670 --> 00:52:11,250 but you can think of being almost 1117 00:52:11,250 --> 00:52:14,280 right at the top of that modulo range 1118 00:52:14,280 --> 00:52:16,620 as being equivalent to being a negative 1. 1119 00:52:16,620 --> 00:52:21,060 So if you say, I'm going to have p minus 1-- 1120 00:52:21,060 --> 00:52:24,120 that's some huge number that's within the very 1121 00:52:24,120 --> 00:52:25,950 allowable range. 1122 00:52:25,950 --> 00:52:28,830 But it also will let you treat it 1123 00:52:28,830 --> 00:52:30,990 as a negative 1 for operations like addition 1124 00:52:30,990 --> 00:52:33,940 and multiplication. 1125 00:52:33,940 --> 00:52:36,090 So this would work, and you can calculate 1126 00:52:36,090 --> 00:52:40,740 what negative 99 is-- that's just going to be p minus 99, 1127 00:52:40,740 --> 00:52:41,550 or minus 100. 1128 00:52:41,550 --> 00:52:44,957 I always am off by 1 when I do these things. 1129 00:52:44,957 --> 00:52:47,280 [LAUGHS] Wait, is it 100? 1130 00:52:47,280 --> 00:52:50,130 Anyway, so you can calculate-- 1131 00:52:50,130 --> 00:52:52,020 it's not really minus 99-- 1132 00:52:52,020 --> 00:52:55,260 it's some big number that's going to be 32-bytes 1133 00:52:55,260 --> 00:52:56,720 long-- that's modulo. 1134 00:52:59,350 --> 00:53:03,460 Modulo p doesn't change, but it's equivalent to minus 99. 1135 00:53:03,460 --> 00:53:06,850 So that if I do add these to this huge number 1136 00:53:06,850 --> 00:53:11,020 plus this other small number, it loops over that modulo 1137 00:53:11,020 --> 00:53:13,480 and then gets back to-- 1138 00:53:13,480 --> 00:53:15,365 what, 9. 1139 00:53:15,365 --> 00:53:17,490 So this plus this is going to be 9 even though this 1140 00:53:17,490 --> 00:53:19,920 is some really long number. 1141 00:53:19,920 --> 00:53:23,910 This plus-- this is going to be nine, and then it all adds up. 1142 00:53:23,910 --> 00:53:27,120 And then I've got this either negative or implausibly 1143 00:53:27,120 --> 00:53:32,910 large value that I've committed to, but I can just ignore that. 1144 00:53:32,910 --> 00:53:35,810 I can get rid of that. 1145 00:53:35,810 --> 00:53:38,120 That negative output will be hidden. 1146 00:53:38,120 --> 00:53:41,610 No one will see that I've got this negative 99 here-- 1147 00:53:41,610 --> 00:53:44,810 then I can toss it and end up with a whole bunch 1148 00:53:44,810 --> 00:53:48,950 of negative values that are anti-coins 1149 00:53:48,950 --> 00:53:51,800 and a whole bunch of more new coins. 1150 00:53:51,800 --> 00:53:55,400 And later on, I can prove I've got valid proofs-- 1151 00:53:55,400 --> 00:54:01,930 all these w plus x equals y plus z proofs worked the whole time. 1152 00:54:01,930 --> 00:54:04,960 Shoot-- [LAUGHS] so we're stuck. 1153 00:54:08,360 --> 00:54:13,240 We need more than a proof that the sums are equal-- 1154 00:54:13,240 --> 00:54:14,550 was working really well. 1155 00:54:14,550 --> 00:54:16,420 But just a proof that the sums are equal 1156 00:54:16,420 --> 00:54:18,990 is not enough because we're modulo-- 1157 00:54:18,990 --> 00:54:20,680 this big prime number. 1158 00:54:20,680 --> 00:54:23,302 And so you can make these negations. 1159 00:54:23,302 --> 00:54:25,260 We also need a proof that they're non-negative, 1160 00:54:25,260 --> 00:54:30,090 and not just not negative, because that negative 99 is 1161 00:54:30,090 --> 00:54:34,380 essentially p minus 99, which is some huge-- 1162 00:54:34,380 --> 00:54:37,467 it's 2 to the 256 minus 99-ish. 1163 00:54:37,467 --> 00:54:39,300 So it's not just that they're non-negative-- 1164 00:54:39,300 --> 00:54:41,760 we have to prove that they're reasonably sized-- 1165 00:54:41,760 --> 00:54:43,050 that they're fairly small. 1166 00:54:43,050 --> 00:54:45,510 So if you could prove this number is non-negative, 1167 00:54:45,510 --> 00:54:49,790 and it's less than 2 to the 64-- 1168 00:54:49,790 --> 00:54:51,590 that would be cool. 1169 00:54:51,590 --> 00:54:53,805 How can we prove something about the number itself 1170 00:54:53,805 --> 00:54:54,680 without revealing it? 1171 00:54:54,680 --> 00:54:56,630 So now this is an even trickier problem, 1172 00:54:56,630 --> 00:54:59,840 because, before, we wanted to prove a sum. 1173 00:54:59,840 --> 00:55:04,210 We wanted to prove that z equals x plus y. 1174 00:55:04,210 --> 00:55:05,960 I don't want to tell you what x plus y is, 1175 00:55:05,960 --> 00:55:08,120 but I'll tell you what z is. 1176 00:55:08,120 --> 00:55:11,310 That was proving a relation between these numbers. 1177 00:55:11,310 --> 00:55:14,150 This is just proving something about that number 1178 00:55:14,150 --> 00:55:15,920 itself individually. 1179 00:55:15,920 --> 00:55:18,850 We have to prove individual numbers-- 1180 00:55:18,850 --> 00:55:19,820 ranges. 1181 00:55:19,820 --> 00:55:22,780 So we have to say, this to 2h-- 1182 00:55:22,780 --> 00:55:25,610 there's a 2h in there, and I can't show you it, because I'm 1183 00:55:25,610 --> 00:55:26,720 just committing a w. 1184 00:55:26,720 --> 00:55:29,630 But I want to somehow show you that the v here-- 1185 00:55:29,630 --> 00:55:31,505 which should happen to be 2, although I'm not 1186 00:55:31,505 --> 00:55:32,480 going to tell you-- 1187 00:55:32,480 --> 00:55:36,240 the v there is within a small range-- 1188 00:55:36,240 --> 00:55:38,340 without telling you what it is-- 1189 00:55:38,340 --> 00:55:42,216 without revealing it-- tricky. 1190 00:55:45,880 --> 00:55:51,640 So what you can try to do is sign with the points. 1191 00:55:51,640 --> 00:55:55,670 Somehow, this is what'll get us there. 1192 00:55:55,670 --> 00:55:58,640 The idea of we've got these Pedersen commitments-- 1193 00:55:58,640 --> 00:56:00,480 we've got these points on a curve-- 1194 00:56:00,480 --> 00:56:01,760 those are public keys. 1195 00:56:01,760 --> 00:56:04,200 That's how we used to usually think of them. 1196 00:56:04,200 --> 00:56:04,700 Can we sign? 1197 00:56:07,570 --> 00:56:09,070 We know the private keys. 1198 00:56:09,070 --> 00:56:10,060 We know r1. 1199 00:56:10,060 --> 00:56:11,440 We know 2. 1200 00:56:11,440 --> 00:56:14,560 Can we make signatures somehow and somehow use 1201 00:56:14,560 --> 00:56:21,140 that to reveal some information about h but not too much? 1202 00:56:21,140 --> 00:56:23,422 So the signature equation-- 1203 00:56:26,170 --> 00:56:28,170 I didn't really review as much, but we've talked 1204 00:56:28,170 --> 00:56:29,310 about this a couple times. 1205 00:56:29,310 --> 00:56:32,280 Come up with a random value k-- 1206 00:56:32,280 --> 00:56:34,980 take the hash of k times g and the message 1207 00:56:34,980 --> 00:56:37,290 to be signed times your private key-- 1208 00:56:37,290 --> 00:56:40,230 that's your signature s. 1209 00:56:40,230 --> 00:56:42,180 The problem is x. 1210 00:56:42,180 --> 00:56:44,610 Your value that you've got committed to here-- 1211 00:56:44,610 --> 00:56:48,610 it's r2g plus 7h. 1212 00:56:48,610 --> 00:56:50,120 What's your private key here? 1213 00:56:50,120 --> 00:56:51,510 Well, it's our 2 plus 7. 1214 00:56:51,510 --> 00:56:54,690 But, no, because you know the private scaler's here. 1215 00:56:54,690 --> 00:56:57,810 But there's 2 points involved in this key. 1216 00:56:57,810 --> 00:56:59,370 So you can't make a signature. 1217 00:56:59,370 --> 00:57:00,960 Generally, signatures are with respect 1218 00:57:00,960 --> 00:57:02,670 to a single generator point. 1219 00:57:02,670 --> 00:57:06,420 The way to verify this is to multiply both sides by g. 1220 00:57:06,420 --> 00:57:09,360 s times g should be k times g minus the hash of k times 1221 00:57:09,360 --> 00:57:12,900 g, message times 8 times g which is a public key-- that works. 1222 00:57:12,900 --> 00:57:15,270 But now you've got h in here. 1223 00:57:15,270 --> 00:57:19,930 So we're stuck. 1224 00:57:19,930 --> 00:57:22,420 We could try to define another signature thing with both h 1225 00:57:22,420 --> 00:57:23,890 and g, but that doesn't work. 1226 00:57:23,890 --> 00:57:29,790 But what we can show, which is kind of interesting, well, 1227 00:57:29,790 --> 00:57:32,760 what if v is 0? 1228 00:57:32,760 --> 00:57:41,780 Then x is r2 times g plus 0h, which is just r2 times g. 1229 00:57:41,780 --> 00:57:43,100 This is nothing. 1230 00:57:43,100 --> 00:57:46,440 There is no h here. 1231 00:57:46,440 --> 00:57:49,000 And that means my private key's going to be r2. 1232 00:57:49,000 --> 00:57:51,320 Well, now I can sign-- 1233 00:57:51,320 --> 00:57:54,100 now I can re-sign with respect to g with this point 1234 00:57:54,100 --> 00:57:57,100 x that I've committed to because the value is zero. 1235 00:57:59,850 --> 00:58:03,405 The value-- the thing that I'm multiplying by h is 0. 1236 00:58:06,390 --> 00:58:08,220 So it'll work for a signature system. 1237 00:58:08,220 --> 00:58:09,900 The same regular old signature equation 1238 00:58:09,900 --> 00:58:16,080 that we use, I can sign a message with key "big X." 1239 00:58:16,080 --> 00:58:19,300 And so this is a proof of a 0 value-- 1240 00:58:19,300 --> 00:58:21,700 I'll sign with my own key. 1241 00:58:21,700 --> 00:58:28,660 So if x is some random blinding factor times g plus 0 times h-- 1242 00:58:28,660 --> 00:58:31,420 where v, the value you're committing to is 0-- 1243 00:58:31,420 --> 00:58:34,750 well, that means that the signature is just-- 1244 00:58:34,750 --> 00:58:36,730 so, the question is, what message do you sign? 1245 00:58:36,730 --> 00:58:39,280 Well, maybe sign the message which is the pubkey itself. 1246 00:58:39,280 --> 00:58:42,310 You don't need to sign a message but throw that in there. 1247 00:58:45,000 --> 00:58:47,460 And then this will work. 1248 00:58:47,460 --> 00:58:51,830 And someone can say, hey, here's a signature from key x. 1249 00:58:51,830 --> 00:58:53,603 And the signature is arbitrary. 1250 00:58:53,603 --> 00:58:55,520 It can be a signature of any message you want. 1251 00:58:55,520 --> 00:58:58,040 But the fact that they are able to produce a signature 1252 00:58:58,040 --> 00:59:05,910 reveals to you that v is 0. 1253 00:59:05,910 --> 00:59:07,050 So that's cool. 1254 00:59:07,050 --> 00:59:09,030 It's not that cool, right? 1255 00:59:09,030 --> 00:59:11,040 Because, well, I just revealed my value, 1256 00:59:11,040 --> 00:59:12,420 and it revealed to be 0. 1257 00:59:12,420 --> 00:59:15,000 But I did it without revealing r. 1258 00:59:15,000 --> 00:59:16,620 So that is cool, right? 1259 00:59:16,620 --> 00:59:20,578 I could do it by saying, hey, here's my r and v values-- 1260 00:59:20,578 --> 00:59:22,620 multiply them and add them up to see that it gets 1261 00:59:22,620 --> 00:59:23,790 to the point I committed to. 1262 00:59:23,790 --> 00:59:26,850 But I can now prove that-- 1263 00:59:26,850 --> 00:59:30,870 I can prove something about v without revealing anything 1264 00:59:30,870 --> 00:59:32,060 about r. 1265 00:59:32,060 --> 00:59:34,950 Before-- we were saying, the way you reveal these commitments is 1266 00:59:34,950 --> 00:59:36,750 you reveal the blinding factor, and you 1267 00:59:36,750 --> 00:59:37,950 reveal the value itself. 1268 00:59:37,950 --> 00:59:40,710 Well, now I can keep the blinding factor secret 1269 00:59:40,710 --> 00:59:44,160 and reveal a little bit of information about v. 1270 00:59:44,160 --> 00:59:48,337 This works, and you can't sign if h is non-zero. 1271 00:59:48,337 --> 00:59:49,670 You're not going to be able to-- 1272 00:59:49,670 --> 00:59:52,830 you're not going to be able to calculate any valid signature 1273 00:59:52,830 --> 00:59:54,610 unless v is-- 1274 00:59:54,610 --> 00:59:55,110 ah. 1275 00:59:55,110 --> 00:59:55,830 V is non-zero. 1276 00:59:55,830 --> 00:59:56,330 Sorry. 1277 00:59:59,470 --> 01:00:04,710 So you can also do this with a proof of v equals 1. 1278 01:00:04,710 --> 01:00:05,790 Again, sign your own key. 1279 01:00:05,790 --> 01:00:10,350 So you define x prime to be just x minus h. 1280 01:00:10,350 --> 01:00:15,870 And then you can say, well, look, 1281 01:00:15,870 --> 01:00:17,840 I'm going to prove to you that v is 1, 1282 01:00:17,840 --> 01:00:21,090 and the way I do that is take the point I've committed to x, 1283 01:00:21,090 --> 01:00:25,030 subtract h from it, and I'll 1284 01:00:25,030 --> 01:00:28,150 provide a signature on that new point. 1285 01:00:28,150 --> 01:00:33,490 Well, this should be v. I can't do that unless v is 1. 1286 01:00:33,490 --> 01:00:36,130 So if I have this, and then I subtract h, 1287 01:00:36,130 --> 01:00:38,080 then I get back to r times g. 1288 01:00:38,080 --> 01:00:41,780 I can now provide a signature just using r-- 1289 01:00:41,780 --> 01:00:43,870 it'll work. 1290 01:00:43,870 --> 01:00:47,600 So what does this get us? 1291 01:00:47,600 --> 01:00:51,070 We can prove that v is 0, or we can prove that v is 1, 1292 01:00:51,070 --> 01:00:53,150 or, really, we can prove that v is anything. 1293 01:00:53,150 --> 01:00:58,940 Just subtract a whole bunch of h's and subtract 7,000 h 1294 01:00:58,940 --> 01:01:00,750 and now provide a signature. 1295 01:01:00,750 --> 01:01:03,492 And that proves that v was 7,000. 1296 01:01:03,492 --> 01:01:06,790 But wait, we just revealed v, so what's the point? 1297 01:01:06,790 --> 01:01:08,260 Did that really get us anywhere? 1298 01:01:08,260 --> 01:01:13,570 If we can make a signature that reveals the value 1299 01:01:13,570 --> 01:01:18,030 we've committed to with hiding the rest of the stuff-- 1300 01:01:18,030 --> 01:01:19,580 is that useful? 1301 01:01:19,580 --> 01:01:24,360 If it's kind of cool, but what can we do with this? 1302 01:01:24,360 --> 01:01:24,880 Any ideas? 1303 01:01:27,500 --> 01:01:33,680 So there's another part that I didn't have time to introduce, 1304 01:01:33,680 --> 01:01:36,150 but maybe will at some point, and you can read about it. 1305 01:01:36,150 --> 01:01:37,460 It's really cool. 1306 01:01:37,460 --> 01:01:40,840 Ring signatures-- a ring signature 1307 01:01:40,840 --> 01:01:43,490 is similar to a normal signature. 1308 01:01:43,490 --> 01:01:45,020 You've got key pairs. 1309 01:01:45,020 --> 01:01:48,410 You've got sign, verify, but there's 1310 01:01:48,410 --> 01:01:52,070 a set of public keys during the signing and verification 1311 01:01:52,070 --> 01:01:53,420 process. 1312 01:01:53,420 --> 01:01:55,580 So the basic idea is, I sign a message 1313 01:01:55,580 --> 01:01:59,330 with one of the public keys, but I don't tell you which one. 1314 01:01:59,330 --> 01:02:02,280 And you verify that, yep, there was a signature here. 1315 01:02:02,280 --> 01:02:03,750 I'm not quite sure who signed it. 1316 01:02:03,750 --> 01:02:05,708 There's possibly three or four different people 1317 01:02:05,708 --> 01:02:07,440 who may have signed it. 1318 01:02:07,440 --> 01:02:10,290 But I know one of them signed it but not which. 1319 01:02:10,290 --> 01:02:13,650 So, basically, it's the key-generation step-- 1320 01:02:13,650 --> 01:02:14,820 same as before. 1321 01:02:14,820 --> 01:02:16,320 You have some keygen-- 1322 01:02:16,320 --> 01:02:18,788 takes in some randomness, and it spits out a private key 1323 01:02:18,788 --> 01:02:19,830 and a public key for you. 1324 01:02:19,830 --> 01:02:22,290 And you can use those later. 1325 01:02:22,290 --> 01:02:23,910 Sign, on the other hand-- 1326 01:02:23,910 --> 01:02:26,220 sign function used to have the message 1327 01:02:26,220 --> 01:02:29,970 to sign in your private key, and it would output a signature. 1328 01:02:29,970 --> 01:02:32,760 In ring signatures, you sign with the message 1329 01:02:32,760 --> 01:02:33,900 you want to sign-- 1330 01:02:33,900 --> 01:02:36,930 your private key and then pick a list 1331 01:02:36,930 --> 01:02:40,680 of other people's public keys. 1332 01:02:40,680 --> 01:02:43,110 And this list can be just a single one. 1333 01:02:43,110 --> 01:02:45,570 It can be 1,000. 1334 01:02:45,570 --> 01:02:48,000 You pick a bunch of other people's public keys, 1335 01:02:48,000 --> 01:02:49,380 and you generate a signature. 1336 01:02:49,380 --> 01:02:53,480 And then verify, you use the signature to-- 1337 01:02:53,480 --> 01:02:54,740 take the signature in-- 1338 01:02:54,740 --> 01:02:59,040 the message that's been signed, and that list of pubkeys. 1339 01:02:59,040 --> 01:03:01,670 And it outputs a Boolean of, yep, that signature worked, 1340 01:03:01,670 --> 01:03:05,030 or, no, it didn't but it doesn't tell you which 1341 01:03:05,030 --> 01:03:07,540 of the public keys is signed. 1342 01:03:07,540 --> 01:03:10,620 So this is a really cool idea. 1343 01:03:10,620 --> 01:03:12,090 I think the initial paper was How 1344 01:03:12,090 --> 01:03:15,516 to Leak a Secret, which was-- 1345 01:03:15,516 --> 01:03:18,780 and then there's different papers about different more 1346 01:03:18,780 --> 01:03:20,970 efficient ring signatures. 1347 01:03:20,970 --> 01:03:24,785 But this is a really cool thing to use. 1348 01:03:24,785 --> 01:03:26,160 I think this could be really cool 1349 01:03:26,160 --> 01:03:28,570 for a lot of different things. 1350 01:03:28,570 --> 01:03:32,700 If people had public keys that they were associated with 1351 01:03:32,700 --> 01:03:36,420 and wrote them on their business cards and stuff like I do-- 1352 01:03:36,420 --> 01:03:39,210 you could then have leaking information 1353 01:03:39,210 --> 01:03:40,780 that's more credible. 1354 01:03:40,780 --> 01:03:42,930 So instead of just the newspaper saying, 1355 01:03:42,930 --> 01:03:45,420 sources close to the matter said x, y, z, 1356 01:03:45,420 --> 01:03:49,410 or a top official at the White House said this. 1357 01:03:49,410 --> 01:03:52,680 You could have it being signed, and we've 1358 01:03:52,680 --> 01:03:55,830 got all these different White House officials' public keys-- 1359 01:03:55,830 --> 01:03:57,240 one of them signed this message. 1360 01:03:57,240 --> 01:03:59,408 So either there was a key compromise, 1361 01:03:59,408 --> 01:04:01,950 and they all lost their keys, which is, in practice, probably 1362 01:04:01,950 --> 01:04:05,520 more likely in that case, or one of these people signed 1363 01:04:05,520 --> 01:04:08,460 this message, and I know it's one of them, 1364 01:04:08,460 --> 01:04:10,710 but it doesn't reveal anything about which 1365 01:04:10,710 --> 01:04:12,182 of the public keys-- 1366 01:04:12,182 --> 01:04:14,100 so, that's pretty cool. 1367 01:04:14,100 --> 01:04:17,490 So you can verify it's from a key in the array of public keys 1368 01:04:17,490 --> 01:04:19,460 but not which. 1369 01:04:19,460 --> 01:04:23,030 So let's put these together. 1370 01:04:23,030 --> 01:04:29,060 I can sign with x to prove that v is 0. 1371 01:04:29,060 --> 01:04:33,110 I could also sign with x prime, which I'm defining as x minus h 1372 01:04:33,110 --> 01:04:35,760 to prove that v is 1. 1373 01:04:35,760 --> 01:04:38,590 Well, what if I have a ring signature where 1374 01:04:38,590 --> 01:04:42,610 I say I'm going to produce a signature from both of these-- 1375 01:04:42,610 --> 01:04:46,020 from one of these 2 public keys. 1376 01:04:46,020 --> 01:04:49,365 And that would prove that v is either 0 or 1. 1377 01:04:49,365 --> 01:04:50,490 But it doesn't prove which. 1378 01:04:54,250 --> 01:04:54,920 Make sense? 1379 01:04:54,920 --> 01:04:57,910 So the idea is, I can make these signatures that essentially 1380 01:04:57,910 --> 01:05:00,530 reveal what v is. 1381 01:05:00,530 --> 01:05:04,460 They indirectly reveal what v is by saying there's no way I 1382 01:05:04,460 --> 01:05:07,790 could have made this signature unless v was 0, 1383 01:05:07,790 --> 01:05:10,500 or unless v was 1 because you're-- 1384 01:05:10,500 --> 01:05:13,880 you know that the h component-- 1385 01:05:13,880 --> 01:05:15,530 v is the coefficient for h. 1386 01:05:15,530 --> 01:05:18,830 So you need to know that I don't have an h component in there 1387 01:05:18,830 --> 01:05:22,550 if I'm going to make a signature with respect to g. 1388 01:05:22,550 --> 01:05:27,710 And I can make any number of different x primes 1389 01:05:27,710 --> 01:05:31,280 by subtracting different amounts of h. 1390 01:05:31,280 --> 01:05:32,810 But a single signature would just 1391 01:05:32,810 --> 01:05:35,310 reveal what v was, which isn't useful. 1392 01:05:35,310 --> 01:05:39,200 But a ring signature, whereas there's 2 different pubkeys-- 1393 01:05:39,200 --> 01:05:42,740 one of them's x-- one of them's x prime, we just subtract h. 1394 01:05:42,740 --> 01:05:44,870 And I'm going to provide a ring signature 1395 01:05:44,870 --> 01:05:46,700 from one of these 2 pubkeys. 1396 01:05:46,700 --> 01:05:48,630 Now I've proven to you-- 1397 01:05:48,630 --> 01:05:51,350 well, v is either 0 or 1-- 1398 01:05:51,350 --> 01:05:54,120 it can't be both. 1399 01:05:54,120 --> 01:05:55,040 But it can't be 2. 1400 01:05:55,040 --> 01:05:55,700 It can't be 3. 1401 01:05:55,700 --> 01:05:58,050 It's got to be one of those two values. 1402 01:05:58,050 --> 01:05:59,740 So does this make sense? 1403 01:05:59,740 --> 01:06:01,060 Questions on this? 1404 01:06:01,060 --> 01:06:01,560 Yes. 1405 01:06:01,560 --> 01:06:03,610 AUDIENCE: What does unverified look like? 1406 01:06:03,610 --> 01:06:05,616 How does it verify that? 1407 01:06:05,616 --> 01:06:12,710 TADGE DRYJA: Oh, well, the original scheme 1408 01:06:12,710 --> 01:06:14,660 is kind of complicated. 1409 01:06:14,660 --> 01:06:17,240 The one used in confidential transactions 1410 01:06:17,240 --> 01:06:19,010 is Borromean ring signatures. 1411 01:06:25,320 --> 01:06:27,375 You do a bunch of hash functions. 1412 01:06:30,090 --> 01:06:30,870 I don't know it. 1413 01:06:30,870 --> 01:06:33,328 I don't even really know it well enough myself to really be 1414 01:06:33,328 --> 01:06:35,490 able to explain it in a minute. 1415 01:06:35,490 --> 01:06:37,290 But, basically, you compute something 1416 01:06:37,290 --> 01:06:39,720 on all of the pubkeys, and then verify 1417 01:06:39,720 --> 01:06:42,930 the signature on the aggregate pubkey as a way 1418 01:06:42,930 --> 01:06:45,390 to think about it. 1419 01:06:45,390 --> 01:06:49,320 The signatures can-- the computing time 1420 01:06:49,320 --> 01:06:52,950 gets big with a number of pubkeys. 1421 01:06:52,950 --> 01:06:55,500 So if you have millions of pubkeys that could possibly 1422 01:06:55,500 --> 01:06:57,740 be signing-- 1423 01:06:57,740 --> 01:07:03,030 the verification algorithm gets really time-consuming. 1424 01:07:03,030 --> 01:07:06,550 So I can maybe go into ring signatures another time. 1425 01:07:06,550 --> 01:07:07,050 Yeah. 1426 01:07:07,050 --> 01:07:08,592 AUDIENCE: I thought the point of this 1427 01:07:08,592 --> 01:07:11,590 was to prove that v is non-negative. 1428 01:07:11,590 --> 01:07:14,750 So right now, we're just saying it's not-- 1429 01:07:14,750 --> 01:07:16,635 it could be two values. 1430 01:07:16,635 --> 01:07:19,180 How does it help us through the signs? 1431 01:07:19,180 --> 01:07:21,610 TADGE DRYJA: Well, neither of these are any good. 1432 01:07:21,610 --> 01:07:22,570 So we've just proven-- 1433 01:07:22,570 --> 01:07:25,210 we've done quite a bit more than prove it's non-negative. 1434 01:07:25,210 --> 01:07:29,310 We've proved that it's exactly 0 or exactly 1. 1435 01:07:29,310 --> 01:07:32,160 We might want more values. 1436 01:07:32,160 --> 01:07:35,040 So make a ring signature from a million 1437 01:07:35,040 --> 01:07:39,210 different public keys where the pub n is just 1438 01:07:39,210 --> 01:07:41,730 pub n minus 1 minus h. 1439 01:07:41,730 --> 01:07:44,310 And then I just proved that v is somewhere in the range 1440 01:07:44,310 --> 01:07:46,630 from 0 to 99999. 1441 01:07:46,630 --> 01:07:47,130 Yeah. 1442 01:07:47,130 --> 01:07:50,370 AUDIENCE: What is computation time for ring signatures 1443 01:07:50,370 --> 01:07:51,900 as the number of public keys? 1444 01:07:51,900 --> 01:07:53,220 TADGE DRYJA: Yeah, it goes up. 1445 01:07:53,220 --> 01:07:56,670 The best is linear, or, no, there might be-- sorry-- 1446 01:07:56,670 --> 01:07:58,050 there's probably sublinear now. 1447 01:07:58,050 --> 01:07:59,190 But this is not feasible. 1448 01:07:59,190 --> 01:08:01,300 [LAUGHS] 1449 01:08:01,300 --> 01:08:03,390 The traditional ring signatures are 1450 01:08:03,390 --> 01:08:06,520 linear with the number of public keys to be verified. 1451 01:08:06,520 --> 01:08:10,130 So if you did this-- 1452 01:08:10,130 --> 01:08:14,010 well, all even then, you'd have to throw, though, because-- 1453 01:08:14,010 --> 01:08:16,500 you have to at least throw the public key 1454 01:08:16,500 --> 01:08:19,175 into the verification function. 1455 01:08:19,175 --> 01:08:21,550 And so that means you need to compute a million pubkeys-- 1456 01:08:21,550 --> 01:08:22,717 throw it into that function. 1457 01:08:22,717 --> 01:08:24,670 It's going to take a long time. 1458 01:08:24,670 --> 01:08:30,240 So this is not itself going to work. 1459 01:08:30,240 --> 01:08:30,740 Yeah. 1460 01:08:30,740 --> 01:08:33,280 AUDIENCE: Just Monero uses ring signatures? 1461 01:08:33,280 --> 01:08:37,920 TADGE DRYJA: Yes, Monero uses ring signatures 1462 01:08:37,920 --> 01:08:39,350 for a different reason. 1463 01:08:39,350 --> 01:08:41,779 Well, now they use it for this kind of thing, too. 1464 01:08:41,779 --> 01:08:44,390 The Monero ring signature was initially 1465 01:08:44,390 --> 01:08:48,979 used for not hiding the amounts but hiding 1466 01:08:48,979 --> 01:08:52,060 which outputs were being spent. 1467 01:08:52,060 --> 01:08:55,540 So in Bitcoin, everyone should-- 1468 01:09:05,460 --> 01:09:08,029 So in Bitcoin if you have a transaction-- 1469 01:09:08,029 --> 01:09:10,990 here's my input, here's my output. 1470 01:09:10,990 --> 01:09:12,609 And the simplest one is just-- 1471 01:09:12,609 --> 01:09:17,245 this points to tx5 or something, and then my output is address-- 1472 01:09:21,010 --> 01:09:25,689 and it's address b, and it's got 7 coins. 1473 01:09:25,689 --> 01:09:27,399 Everyone can see what you're spending. 1474 01:09:27,399 --> 01:09:33,580 The idea in Monero is, I don't point to an input-- 1475 01:09:33,580 --> 01:09:35,728 I just provide a signature. 1476 01:09:35,728 --> 01:09:38,270 And it's up to you to figure out where that signature's from. 1477 01:09:38,270 --> 01:09:41,479 So I provide a signature and a list of pubkeys-- 1478 01:09:41,479 --> 01:09:43,090 pub a-- pub b. 1479 01:09:43,090 --> 01:09:44,960 So the smallest would be 2. 1480 01:09:44,960 --> 01:09:48,294 And then I provide a key-- 1481 01:09:48,294 --> 01:09:49,580 key in a number. 1482 01:09:49,580 --> 01:09:53,729 So the idea is instead of thinking of it as outputs, 1483 01:09:53,729 --> 01:09:56,880 you think pubkeys have associated values. 1484 01:09:56,880 --> 01:09:59,130 You don't look at the transactions themselves. 1485 01:09:59,130 --> 01:10:01,460 This is key c. 1486 01:10:01,460 --> 01:10:06,620 And there previously have been-- pubkey a and pubkey b have had 1487 01:10:06,620 --> 01:10:07,640 values-- 1488 01:10:07,640 --> 01:10:09,560 7 coins sent to them. 1489 01:10:09,560 --> 01:10:11,120 And I can now say, look, I'm going 1490 01:10:11,120 --> 01:10:17,490 to provide a ring signature from either pubkey a or pubkey b. 1491 01:10:17,490 --> 01:10:19,410 And I'm not going to tell you which, 1492 01:10:19,410 --> 01:10:23,730 but you can see that both pubkey a and pubkey b have 1493 01:10:23,730 --> 01:10:25,710 received 7 coins in the past. 1494 01:10:25,710 --> 01:10:27,810 I want to send 7 coins over here. 1495 01:10:27,810 --> 01:10:30,270 I'm going to prove that I own one of those two. 1496 01:10:30,270 --> 01:10:34,560 And then you can validate that the transaction's valid. 1497 01:10:34,560 --> 01:10:40,400 And then if later, you see another transaction with a ring 1498 01:10:40,400 --> 01:10:43,946 signature from pub a-- 1499 01:10:43,946 --> 01:10:49,072 pub b-- also sending to the key d-- 1500 01:10:49,072 --> 01:10:50,970 7 coins. 1501 01:10:50,970 --> 01:10:53,360 Now, I can delete pub a and pub b. 1502 01:10:53,360 --> 01:10:54,890 I don't know which, this-- 1503 01:10:54,890 --> 01:10:59,288 so in transaction 1, I don't know whether a or b was spent, 1504 01:10:59,288 --> 01:11:00,330 but one of those two was. 1505 01:11:00,330 --> 01:11:02,310 And then in transaction 2, I don't know whether a or b 1506 01:11:02,310 --> 01:11:03,477 are spent-- one of them was. 1507 01:11:03,477 --> 01:11:05,610 But anyway, they've both been spent now. 1508 01:11:05,610 --> 01:11:09,090 And so I can delete them from my storage. 1509 01:11:09,090 --> 01:11:10,650 But the ring signature's in Monero 1510 01:11:10,650 --> 01:11:14,010 were used to obscure the transaction graph itself-- 1511 01:11:14,010 --> 01:11:16,560 where you can see that there's a bunch of different keys 1512 01:11:16,560 --> 01:11:18,540 that have money associated with them. 1513 01:11:18,540 --> 01:11:20,040 And I'm going to provide a signature 1514 01:11:20,040 --> 01:11:23,820 that I own one of them, but I don't tell you which. 1515 01:11:23,820 --> 01:11:26,370 And now they also do confidential transactions 1516 01:11:26,370 --> 01:11:29,590 to obscure the outputs using ring signatures as well. 1517 01:11:29,590 --> 01:11:32,600 So I don't-- well, it's interesting. 1518 01:11:32,600 --> 01:11:35,737 I haven't looked at it that closely. 1519 01:11:35,737 --> 01:11:37,070 So I know that's the basic idea. 1520 01:11:37,070 --> 01:11:39,620 But there's a lot of subtle details involved 1521 01:11:39,620 --> 01:11:41,996 in how that works, and I'm not super familiar with that. 1522 01:11:44,580 --> 01:11:47,560 So I can finish up. 1523 01:11:47,560 --> 01:11:51,220 So the way to make this practical 1524 01:11:51,220 --> 01:11:54,322 is, let's say you have a ring signature for each bit, 1525 01:11:54,322 --> 01:11:56,530 so you're going to have to have a different signature 1526 01:11:56,530 --> 01:11:59,650 for each bit in your value. 1527 01:11:59,650 --> 01:12:03,350 So the pubkey x0-- 1528 01:12:03,350 --> 01:12:05,350 well, I'm going to have a ring signature where I 1529 01:12:05,350 --> 01:12:07,478 prove that it's either 0 or 1. 1530 01:12:07,478 --> 01:12:09,520 And here I'm going to prove it's either a 0 or 2. 1531 01:12:09,520 --> 01:12:11,470 Here I'm going to prove it's either 0 or 4. 1532 01:12:11,470 --> 01:12:16,030 And so if I have 32 signatures, I 1533 01:12:16,030 --> 01:12:18,160 can now prove a 32-bit number. 1534 01:12:18,160 --> 01:12:19,720 Each of those individual signatures 1535 01:12:19,720 --> 01:12:22,690 only has 2 public keys associated with it. 1536 01:12:22,690 --> 01:12:25,800 So that's now more feasible. 1537 01:12:25,800 --> 01:12:30,030 There's a total of 32 public keys, 32 signatures-- 1538 01:12:30,030 --> 01:12:32,730 not the end of the world-- still kind of ugly. 1539 01:12:32,730 --> 01:12:35,160 And then there's optimizations where 1540 01:12:35,160 --> 01:12:41,150 since these pubkeys are all the same, the 0 value for that 1541 01:12:41,150 --> 01:12:41,990 bit-- 1542 01:12:41,990 --> 01:12:43,567 we can squish them together and stuff 1543 01:12:43,567 --> 01:12:44,900 to make it a little bit smaller. 1544 01:12:48,150 --> 01:12:51,990 So you have a signature per bit of your output. 1545 01:12:51,990 --> 01:12:54,460 If your values are not too big-- this works. 1546 01:12:54,460 --> 01:12:56,130 We're going to limit it to 32-bits. 1547 01:12:56,130 --> 01:12:59,310 So from 0 to 4 billion. 1548 01:12:59,310 --> 01:13:05,340 Now you can prove that each bit was either a 0 or 1, 1549 01:13:05,340 --> 01:13:10,170 essentially, without revealing whether it was a 0 or 1. 1550 01:13:10,170 --> 01:13:12,390 And then it's a couple of kilobytes per output. 1551 01:13:12,390 --> 01:13:15,000 So it's a little bit annoying. 1552 01:13:15,000 --> 01:13:16,020 It used to be 8 bytes. 1553 01:13:16,020 --> 01:13:18,960 You said, hey, I've got 37 points. 1554 01:13:18,960 --> 01:13:23,220 Also, these 8 bytes are very sparse in that they rarely 1555 01:13:23,220 --> 01:13:26,440 exceed 4 bytes. 1556 01:13:26,440 --> 01:13:30,400 So you can compact it down on disk. 1557 01:13:30,400 --> 01:13:31,380 So this is a little-- 1558 01:13:31,380 --> 01:13:33,510 scalability-wise, it's an issue. 1559 01:13:33,510 --> 01:13:36,980 You're now going from what used to be 8 bytes is now a couple 1560 01:13:36,980 --> 01:13:37,650 kilobytes. 1561 01:13:37,650 --> 01:13:40,080 I think they've got it down to 2 kilobytes. 1562 01:13:40,080 --> 01:13:41,890 But still, that's 2 kilobytes. 1563 01:13:41,890 --> 01:13:44,940 And it takes a bit more CPU time to verify. 1564 01:13:44,940 --> 01:13:47,340 Because now, instead of verifying one signature 1565 01:13:47,340 --> 01:13:49,990 to see that the coins are moving to the right place, 1566 01:13:49,990 --> 01:13:54,360 you're verifying 30-plus signatures 1567 01:13:54,360 --> 01:13:59,480 for every input and output. 1568 01:13:59,480 --> 01:14:01,320 Also, the real problem is it's not really 1569 01:14:01,320 --> 01:14:02,760 compatible with Bitcoin-- 1570 01:14:02,760 --> 01:14:05,340 this would be a really tricky fork to implement. 1571 01:14:05,340 --> 01:14:08,310 How do you implement this such that the old software 1572 01:14:08,310 --> 01:14:11,460 on the network is OK with these transactions 1573 01:14:11,460 --> 01:14:16,297 where they're expecting a transaction that has a value? 1574 01:14:16,297 --> 01:14:17,880 Here's how many coins are being moved. 1575 01:14:17,880 --> 01:14:19,790 If you say, no, I'm not going to tell you anymore. 1576 01:14:19,790 --> 01:14:21,998 Well, old software doesn't know how to deal with this 1577 01:14:21,998 --> 01:14:24,810 and by default, will reject these transactions. 1578 01:14:24,810 --> 01:14:29,610 So there's ways to do it that doesn't break compatibility, 1579 01:14:29,610 --> 01:14:32,760 but they're pretty ugly. 1580 01:14:32,760 --> 01:14:34,500 One of the ways is to say, OK, from now 1581 01:14:34,500 --> 01:14:38,490 on, all these transactions-- all output values have to be 0. 1582 01:14:38,490 --> 01:14:40,300 So the old software will still work, 1583 01:14:40,300 --> 01:14:43,140 but it will be pretty confused and say, 1584 01:14:43,140 --> 01:14:44,340 I see all these values. 1585 01:14:44,340 --> 01:14:45,990 I see thousands of transactions. 1586 01:14:45,990 --> 01:14:48,330 No one seems to be sending anyone any money. 1587 01:14:48,330 --> 01:14:50,190 So they seem to be pointless. 1588 01:14:50,190 --> 01:14:52,530 And then there's this hidden value 1589 01:14:52,530 --> 01:14:54,990 that's in a different data structure that would 1590 01:14:54,990 --> 01:14:56,250 look something like segwit. 1591 01:14:56,250 --> 01:15:00,060 And segwit was a little bit ugly-- this would be real ugly. 1592 01:15:00,060 --> 01:15:03,750 Those are the trade-offs we're dealing with here-- 1593 01:15:03,750 --> 01:15:06,090 tricky fork. 1594 01:15:06,090 --> 01:15:08,070 But you get this. 1595 01:15:08,070 --> 01:15:12,150 This is what you get when you use confidential transactions. 1596 01:15:12,150 --> 01:15:13,740 You got it, right? 1597 01:15:13,740 --> 01:15:15,270 We have private, unlinkable amounts 1598 01:15:15,270 --> 01:15:17,590 where the network can verify-- 1599 01:15:17,590 --> 01:15:20,790 OK, let me verify that w plus x equals y plus z-- 1600 01:15:20,790 --> 01:15:22,660 that's the easy part. 1601 01:15:22,660 --> 01:15:27,390 Now, let me verify for every individual w, x, y, and z 1602 01:15:27,390 --> 01:15:31,192 that it is within the range of 0 to 6223222232-- 1603 01:15:31,192 --> 01:15:33,770 02 to the 32-- 1604 01:15:33,770 --> 01:15:37,193 it's a tongue-twister-- by verifying 1605 01:15:37,193 --> 01:15:38,610 all these separate ring signatures 1606 01:15:38,610 --> 01:15:39,735 for each bit of the amount. 1607 01:15:42,098 --> 01:15:43,140 But you can do it, right? 1608 01:15:43,140 --> 01:15:47,070 You can verify-- input amounts equal output amounts. 1609 01:15:47,070 --> 01:15:49,890 All these input amounts and output amounts 1610 01:15:49,890 --> 01:15:51,630 are normal looking numbers that aren't 1611 01:15:51,630 --> 01:15:53,910 too big that aren't right up near the modulos 1612 01:15:53,910 --> 01:15:55,590 to wrap around. 1613 01:15:55,590 --> 01:15:59,610 And it works-- it's just big and slow-- 1614 01:15:59,610 --> 01:16:02,280 we're trying to make that faster. 1615 01:16:02,280 --> 01:16:05,460 So probably not going to go-- if you're interested in this, 1616 01:16:05,460 --> 01:16:07,530 though, there's a lot of research about this kind 1617 01:16:07,530 --> 01:16:08,730 of thing right now. 1618 01:16:08,730 --> 01:16:12,060 It's really cool getting in the crazy, interesting math. 1619 01:16:12,060 --> 01:16:16,800 So there's bulletproofs, which was Benedict's at Stanford. 1620 01:16:16,800 --> 01:16:19,080 He wrote up-- I mean, a bunch of people wrote it, 1621 01:16:19,080 --> 01:16:21,660 but I think it was sort of his idea, 1622 01:16:21,660 --> 01:16:25,320 or his thing working with other people, too. 1623 01:16:25,320 --> 01:16:27,570 That's more efficient range proofs. 1624 01:16:27,570 --> 01:16:29,220 I do not know how bulletproofs work. 1625 01:16:29,220 --> 01:16:32,160 I tried to read the paper and got two pages in, 1626 01:16:32,160 --> 01:16:33,150 and I don't know. 1627 01:16:33,150 --> 01:16:36,780 [LAUGHS] But I'm sure I could figure it out-- 1628 01:16:36,780 --> 01:16:39,000 it would just take me a long time. 1629 01:16:39,000 --> 01:16:40,860 And then the Borromean ring signatures-- 1630 01:16:40,860 --> 01:16:42,480 the more efficient ring signatures 1631 01:16:42,480 --> 01:16:46,930 that can compact a lot of data so that you're not-- 1632 01:16:46,930 --> 01:16:49,380 so you get it down to two kilobytes 1633 01:16:49,380 --> 01:16:53,610 for these range proofs in confidential transactions. 1634 01:16:53,610 --> 01:16:56,730 And then I may try to give a class 1635 01:16:56,730 --> 01:16:58,380 about this in a week or two-- 1636 01:16:58,380 --> 01:17:00,000 MimbleWimble. 1637 01:17:00,000 --> 01:17:04,350 The idea is that when all of the transactions in the network 1638 01:17:04,350 --> 01:17:06,900 are like this and that have confidential inputs and outputs 1639 01:17:06,900 --> 01:17:09,600 amounts, the transactions can be canceled out 1640 01:17:09,600 --> 01:17:11,880 in an interesting way. 1641 01:17:11,880 --> 01:17:14,495 Because the output amounts are unique. 1642 01:17:14,495 --> 01:17:15,870 They have these blinding factors. 1643 01:17:15,870 --> 01:17:17,640 They have these range proofs. 1644 01:17:17,640 --> 01:17:20,820 And so if you're in a block-- 1645 01:17:20,820 --> 01:17:22,740 so just a hint about MimbleWimble-- 1646 01:17:22,740 --> 01:17:27,990 the idea is if you have a transaction and amounts 1647 01:17:27,990 --> 01:17:28,920 are all obscured. 1648 01:17:28,920 --> 01:17:32,760 But a is being consumed, b is being consumed, 1649 01:17:32,760 --> 01:17:34,920 c is being created, d is being created. 1650 01:17:34,920 --> 01:17:38,830 These are amounts. 1651 01:17:38,830 --> 01:17:40,950 And then I see later in the block 1652 01:17:40,950 --> 01:17:44,560 there is another transaction which spends d coins 1653 01:17:44,560 --> 01:17:45,790 and sends to e coins. 1654 01:17:50,350 --> 01:17:55,270 I don't have to verify that a plus b equal c plus d. 1655 01:17:55,270 --> 01:17:57,730 And d equals e kind of thing-- 1656 01:17:57,730 --> 01:17:59,470 I can just cross these out. 1657 01:17:59,470 --> 01:18:01,630 And I can verify on a block-level instead 1658 01:18:01,630 --> 01:18:04,750 of a transaction-level that the input amounts and output 1659 01:18:04,750 --> 01:18:10,110 amounts all matched up because I don't know what d is. 1660 01:18:10,110 --> 01:18:12,040 But, anyway, it was on an output side 1661 01:18:12,040 --> 01:18:14,690 and on an input side within the same block. 1662 01:18:14,690 --> 01:18:17,350 So, anyway, it's gone. 1663 01:18:17,350 --> 01:18:19,810 It's being added to and subtracted in this block. 1664 01:18:19,810 --> 01:18:20,825 So I can do that. 1665 01:18:20,825 --> 01:18:22,450 And I can do that over multiple blocks. 1666 01:18:22,450 --> 01:18:25,240 And I can basically keep a tally of how many coins 1667 01:18:25,240 --> 01:18:30,160 are in the system and cancel things out. 1668 01:18:30,160 --> 01:18:32,710 So that lets you do some really cool things where 1669 01:18:32,710 --> 01:18:35,020 you can skip a lot of verification 1670 01:18:35,020 --> 01:18:37,220 at no loss of security. 1671 01:18:37,220 --> 01:18:39,370 So that's the idea of a MimbleWimble, which 1672 01:18:39,370 --> 01:18:42,830 is really a fun paper because it was written by Lord Voldemort. 1673 01:18:45,910 --> 01:18:49,320 Someone posted a Pastebin link on IRC. 1674 01:18:49,320 --> 01:18:50,920 And who knows who wrote this-- 1675 01:18:50,920 --> 01:18:51,640 Lord Voldemort. 1676 01:18:51,640 --> 01:18:53,550 Except it was Lord Voldemort-- 1677 01:18:53,550 --> 01:18:56,200 the French word for Lord Voldemort. 1678 01:18:56,200 --> 01:18:58,870 So when they translated Harry Potter into French, 1679 01:18:58,870 --> 01:19:01,210 they changed the names around, I guess, 1680 01:19:01,210 --> 01:19:04,600 and it was the French equivalent of Lord Voldemort. 1681 01:19:04,600 --> 01:19:07,780 And so now there's a bunch of people programming MimbleWimble 1682 01:19:07,780 --> 01:19:09,070 and implementing it. 1683 01:19:09,070 --> 01:19:10,450 And they all use Harry Potter-- 1684 01:19:10,450 --> 01:19:11,680 not all of them, but a lot of them 1685 01:19:11,680 --> 01:19:13,055 use Harry Potter names on GitHub. 1686 01:19:13,055 --> 01:19:14,920 So it's kind of funny. 1687 01:19:14,920 --> 01:19:18,580 It's also really funny that it was one of the most-- 1688 01:19:18,580 --> 01:19:21,420 I would say, the most-- 1689 01:19:21,420 --> 01:19:26,660 whoa, kind of paper of 2016 now. 1690 01:19:26,660 --> 01:19:28,920 And so it's of an interesting indicator 1691 01:19:28,920 --> 01:19:32,010 of the space we're working in that you've got IBM and all 1692 01:19:32,010 --> 01:19:35,430 these big companies, and they're working on blockchain research, 1693 01:19:35,430 --> 01:19:38,760 and, honestly, not a ton of awesome stuff, 1694 01:19:38,760 --> 01:19:40,770 whereas like, whoa, MimbleWimble, OK, 1695 01:19:40,770 --> 01:19:42,160 Lord Voldemort-- 1696 01:19:42,160 --> 01:19:43,302 he really showed everyone. 1697 01:19:43,302 --> 01:19:48,690 [LAUGHS] So it's fun that it's still a very out-there hackery 1698 01:19:48,690 --> 01:19:49,860 system. 1699 01:19:49,860 --> 01:19:54,320 So that's-- hopefully, most people got most of the idea. 1700 01:19:54,320 --> 01:19:56,430 It's a little bit fast. 1701 01:19:56,430 --> 01:19:59,580 It sort of explained all the Pedersen commitments and range 1702 01:19:59,580 --> 01:20:01,672 proofs and everything in a little bit of time. 1703 01:20:01,672 --> 01:20:02,880 But I think you got the idea. 1704 01:20:02,880 --> 01:20:04,505 And if you're interested in it, there's 1705 01:20:04,505 --> 01:20:06,240 a lot of current research on this 1706 01:20:06,240 --> 01:20:07,500 and people implementing it. 1707 01:20:07,500 --> 01:20:10,250 And there's a lot of cool things you can do with it, so.