WEBVTT 00:00:00.790 --> 00:00:03.160 The following content is provided under a Creative 00:00:03.160 --> 00:00:04.550 Commons license. 00:00:04.550 --> 00:00:06.760 Your support will help MIT OpenCourseWare 00:00:06.760 --> 00:00:10.850 continue to offer high-quality educational resources for free. 00:00:10.850 --> 00:00:13.390 To make a donation, or to view additional materials 00:00:13.390 --> 00:00:17.350 from hundreds of MIT courses, visit MIT OpenCourseWare 00:00:17.350 --> 00:00:18.250 at ocw.mit.edu. 00:00:22.310 --> 00:00:25.100 TADGE DRYJA: And that brings us to today's lecture, 00:00:25.100 --> 00:00:28.550 which is also something I was not as familiar with. 00:00:28.550 --> 00:00:30.303 So sort of a disclaimer-- 00:00:30.303 --> 00:00:31.970 I might have gotten little things wrong, 00:00:31.970 --> 00:00:33.990 or it might not be quite as clear. 00:00:33.990 --> 00:00:36.098 But do ask questions. 00:00:36.098 --> 00:00:38.390 So if it's stuff like Lightning Network or Discreet Log 00:00:38.390 --> 00:00:40.307 Contracts, well, for me-- that's sort of easy, 00:00:40.307 --> 00:00:42.740 because I know it really well. 00:00:42.740 --> 00:00:45.110 This stuff is things I've known about, 00:00:45.110 --> 00:00:49.170 but I've never really went as into the details. 00:00:49.170 --> 00:00:51.988 So it's a little bit like, OK, figure 00:00:51.988 --> 00:00:54.530 it out well enough to explain it rather than just well enough 00:00:54.530 --> 00:00:56.235 to understand how it works. 00:00:56.235 --> 00:00:58.610 So the basic idea is you want to hide the output amounts. 00:00:58.610 --> 00:01:03.380 So we saw last week how looking at output amounts 00:01:03.380 --> 00:01:07.170 can deanonymize and let you link a lot of different things. 00:01:07.170 --> 00:01:08.910 And so we'll look at how to do that. 00:01:08.910 --> 00:01:10.850 How do we hide output amounts? 00:01:10.850 --> 00:01:12.520 And so we'll talk about commitments. 00:01:12.520 --> 00:01:15.020 So first, we'll talk about the reasons why and how to do it. 00:01:15.020 --> 00:01:17.360 Then we'll talk about the definition of commitments. 00:01:17.360 --> 00:01:19.520 What is a commitment in cryptography? 00:01:19.520 --> 00:01:21.770 And then we'll talk about Pedersen commitments, 00:01:21.770 --> 00:01:23.420 and then we'll talk about range proofs 00:01:23.420 --> 00:01:25.070 and put it together to get what's 00:01:25.070 --> 00:01:28.010 called "confidential transactions," which 00:01:28.010 --> 00:01:31.880 is a vaguely confidential transaction-- it just means 00:01:31.880 --> 00:01:36.010 the output amounts are secret. 00:01:36.010 --> 00:01:39.100 So interrupt with any questions at any point of the way 00:01:39.100 --> 00:01:40.950 if something's not clear. 00:01:40.950 --> 00:01:43.480 So coinjoin-- last time we talked 00:01:43.480 --> 00:01:46.757 about combining transactions with other people 00:01:46.757 --> 00:01:48.840 where you have your input-- they have their input. 00:01:48.840 --> 00:01:50.930 You have your output-- they have their output. 00:01:50.930 --> 00:01:55.540 And if you shuffle the ordering of the inputs and outputs, 00:01:55.540 --> 00:01:58.270 it might not be clear who's sending what where. 00:01:58.270 --> 00:02:00.550 You're aggregating it, and in the process, 00:02:00.550 --> 00:02:03.640 you're losing information, because no one 00:02:03.640 --> 00:02:05.940 gets to see the border lines between-- hey, 00:02:05.940 --> 00:02:08.440 this is one transaction-- this is another transaction-- it's 00:02:08.440 --> 00:02:11.740 all in the same transaction, so you can't really tell. 00:02:11.740 --> 00:02:13.840 But one issue-- and a really big issue-- 00:02:13.840 --> 00:02:16.720 was that the output amounts can often reveal 00:02:16.720 --> 00:02:18.460 who's sending what where. 00:02:18.460 --> 00:02:21.190 So in this example-- 00:02:21.190 --> 00:02:23.680 well, maybe I don't know who's A, 00:02:23.680 --> 00:02:25.420 who's B, who's C, who's D-- these all 00:02:25.420 --> 00:02:29.320 look like uniformly, random addresses or pubkeys. 00:02:29.320 --> 00:02:31.510 But if I see an input with 10 coins-- 00:02:31.510 --> 00:02:33.348 an input with 2 coins, and then an output 00:02:33.348 --> 00:02:35.140 with 2 coins, and an output with 10 coins-- 00:02:35.140 --> 00:02:39.250 well, there's probably something like this going on. 00:02:39.250 --> 00:02:41.470 Why else would you do this? 00:02:41.470 --> 00:02:44.380 If you were trying to send 2 coins somewhere, 00:02:44.380 --> 00:02:46.520 why even involve this 10-coin input? 00:02:46.520 --> 00:02:49.390 Why not just say 2 coins to 2 coins, and you're done? 00:02:49.390 --> 00:02:53.890 So if the goal is to obscure the transaction graph 00:02:53.890 --> 00:02:56.140 and have better anonymity because no one can 00:02:56.140 --> 00:02:58.790 tell what's going where-- well, this doesn't really work. 00:02:58.790 --> 00:03:00.392 I think it's going like that. 00:03:00.392 --> 00:03:02.350 And then I showed that there is a way to do it, 00:03:02.350 --> 00:03:07.540 whereas if you have 2 to 8, then the 8 is obviously 00:03:07.540 --> 00:03:08.920 from the person with 10. 00:03:08.920 --> 00:03:13.990 But the 2 different 2 coin outputs are unlinkable. 00:03:13.990 --> 00:03:17.030 So that helps, but it's not great. 00:03:17.030 --> 00:03:21.310 And then for things like the aggregate signatures, maybe 00:03:21.310 --> 00:03:23.920 you can get people to aggregate their transactions together 00:03:23.920 --> 00:03:27.020 because it's cheaper and smaller. 00:03:27.020 --> 00:03:29.685 But in general, they'll have totally different input sizes, 00:03:29.685 --> 00:03:31.810 totally different output sizes, and it won't really 00:03:31.810 --> 00:03:33.483 give you any anonymity. 00:03:33.483 --> 00:03:34.900 And it won't give you any privacy, 00:03:34.900 --> 00:03:36.880 and it hurts fungibility. 00:03:36.880 --> 00:03:39.280 So how can we do this? 00:03:39.280 --> 00:03:44.487 Wouldn't it be great if we could hide the output amounts? 00:03:44.487 --> 00:03:45.570 That would be really cool. 00:03:45.570 --> 00:03:47.430 So instead of having it like this-- 00:03:47.430 --> 00:03:52.560 it's just you don't see how many coins there are. 00:03:52.560 --> 00:03:55.890 Why don't we just delete the output amounts entirely? 00:03:55.890 --> 00:03:59.590 Why even that saves 8 bytes. 00:03:59.590 --> 00:04:01.420 So we can't just delete it. 00:04:01.420 --> 00:04:04.180 So what does this mean? 00:04:04.180 --> 00:04:05.830 This would be really cool, though, 00:04:05.830 --> 00:04:09.790 if we could somehow obscure this so that no one can 00:04:09.790 --> 00:04:12.232 tell what the amounts are. 00:04:12.232 --> 00:04:13.690 And, I guess, initially, so they're 00:04:13.690 --> 00:04:16.060 going to be some transition since Bitcoin wasn't built 00:04:16.060 --> 00:04:19.089 with this from the get-go. 00:04:19.089 --> 00:04:21.250 At some point, there will be a transaction where 00:04:21.250 --> 00:04:23.740 you can see the input amounts, but then you 00:04:23.740 --> 00:04:26.890 can't see the output amounts. 00:04:26.890 --> 00:04:30.040 But then you can have bounds and say, well, neither of these 00:04:30.040 --> 00:04:32.620 can be more than 12. 00:04:32.620 --> 00:04:35.740 And then as it goes forward, and if the transaction graph gets 00:04:35.740 --> 00:04:38.320 bigger, those bounds start getting really wide 00:04:38.320 --> 00:04:40.960 because you're like, well, this might have been 11, 00:04:40.960 --> 00:04:43.430 and this might have been 1, and then the next transaction 00:04:43.430 --> 00:04:45.130 if it's mixed in with a bunch of things that have a pretty 00:04:45.130 --> 00:04:47.143 wide range, you have to take the max 00:04:47.143 --> 00:04:48.310 and min of all those things. 00:04:48.310 --> 00:04:50.230 And, the min is always going to be 0, 00:04:50.230 --> 00:04:53.260 so it works pretty well even with this transaction. 00:04:53.260 --> 00:04:54.790 You could also think of a new system 00:04:54.790 --> 00:05:03.940 where either you start with obscured amounts, 00:05:03.940 --> 00:05:06.533 or the first mining amounts are non-obscured, 00:05:06.533 --> 00:05:07.450 and then you mix them. 00:05:07.450 --> 00:05:11.230 Anyway, so this seems like it'd be really useful because it 00:05:11.230 --> 00:05:14.080 would allow you to combine transactions and get 00:05:14.080 --> 00:05:16.810 better privacy. 00:05:16.810 --> 00:05:18.638 Also, just really nice in general, 00:05:18.638 --> 00:05:20.930 even if you're not trying to combine with anyone else-- 00:05:20.930 --> 00:05:22.347 it's really cool that people can't 00:05:22.347 --> 00:05:24.480 see how much money you have. 00:05:24.480 --> 00:05:26.230 If people can see how many coins you have, 00:05:26.230 --> 00:05:28.040 they can try to charge you more-- 00:05:28.040 --> 00:05:29.350 they can try to rob you-- 00:05:29.350 --> 00:05:32.410 there's all sorts of reasons why people don't usually 00:05:32.410 --> 00:05:35.380 say how much money they're carrying around, 00:05:35.380 --> 00:05:37.072 or how much they make, or how-- 00:05:37.072 --> 00:05:37.780 things like that. 00:05:37.780 --> 00:05:41.470 People are sensitive about pricing information, 00:05:41.470 --> 00:05:44.710 and some of it's societal taboo, but also a lot of it's 00:05:44.710 --> 00:05:48.100 like I don't want people to know how much money I have. 00:05:48.100 --> 00:05:49.370 And I think there's-- 00:05:49.370 --> 00:05:51.257 I've read recently like Uber doing 00:05:51.257 --> 00:05:52.840 this thing where they like, oh, you're 00:05:52.840 --> 00:05:54.423 rich-- we're going to charge you more. 00:05:54.423 --> 00:05:56.650 And people don't like that. 00:05:56.650 --> 00:06:00.580 It has been historically doable. 00:06:00.580 --> 00:06:02.488 Companies segment things, but often the way 00:06:02.488 --> 00:06:04.030 they do it is they're like, OK, well, 00:06:04.030 --> 00:06:07.750 we're going to make first-class seats and then economy seats. 00:06:07.750 --> 00:06:10.030 And the first class seats don't take up 00:06:10.030 --> 00:06:12.700 the space of 10 economy seats-- they take up the space of maybe 00:06:12.700 --> 00:06:15.115 2, but they cost like 10x. 00:06:15.115 --> 00:06:16.990 And the idea is, well, if you're rich-- we're 00:06:16.990 --> 00:06:18.032 going to charge you more. 00:06:18.032 --> 00:06:20.110 You can have the fancy stuff, and we're 00:06:20.110 --> 00:06:22.240 going to make more profit off of that. 00:06:22.240 --> 00:06:25.237 That's more OK, I guess, but if it's just-- no, 00:06:25.237 --> 00:06:27.820 you're getting the same economy seat, but we know you're rich, 00:06:27.820 --> 00:06:29.560 so we're going to charge you more-- 00:06:29.560 --> 00:06:31.810 that-- I don't know. 00:06:31.810 --> 00:06:34.120 And we're getting into that future 00:06:34.120 --> 00:06:37.330 where there's enough data that a lot of companies can do this. 00:06:37.330 --> 00:06:39.760 And some people, probably myself included, 00:06:39.760 --> 00:06:41.260 is like wait, no, I don't like that. 00:06:41.260 --> 00:06:43.677 I like the way it was before where companies didn't really 00:06:43.677 --> 00:06:45.040 know that much about me. 00:06:45.040 --> 00:06:48.880 So this is an effort to try to keep things obscured-- 00:06:48.880 --> 00:06:52.467 try to keep the customer a bit more anonymous with respect 00:06:52.467 --> 00:06:54.800 to merchants so that they don't have as much information 00:06:54.800 --> 00:06:56.740 to charge more. 00:06:56.740 --> 00:06:57.610 And then-- rob you-- 00:06:57.610 --> 00:07:02.110 that's maybe more Bitcoin-specific where like-- 00:07:02.110 --> 00:07:03.730 yeah, I mean if you're walking around 00:07:03.730 --> 00:07:05.950 in an area that's sort of high-crime 00:07:05.950 --> 00:07:08.710 with a bunch of money hanging out of your pocket-- that's 00:07:08.710 --> 00:07:11.030 a bad idea. 00:07:11.030 --> 00:07:13.720 The internet is sort of a high-crime area, especially, 00:07:13.720 --> 00:07:14.830 with respect to Bitcoin. 00:07:14.830 --> 00:07:17.920 And it's really easy to see how much people have. 00:07:17.920 --> 00:07:22.810 And so people-- the hackers know who to target, 00:07:22.810 --> 00:07:24.370 especially if it's like an exchange-- 00:07:24.370 --> 00:07:25.300 they're pretty clear-- 00:07:25.300 --> 00:07:27.903 OK, this exchange has tons of money. 00:07:27.903 --> 00:07:29.320 So it might not help the exchanges 00:07:29.320 --> 00:07:32.050 that much-- it obviously has a lot of money, but anyway. 00:07:32.050 --> 00:07:34.870 So this would be really cool to do. 00:07:34.870 --> 00:07:38.602 I think people sort of agree-- this would be really cool. 00:07:38.602 --> 00:07:39.810 This is a nice thing to have. 00:07:43.840 --> 00:07:46.160 And it also helps with privacy. 00:07:46.160 --> 00:07:49.090 You're trying to make it hard to link 00:07:49.090 --> 00:07:52.120 different outputs to each other or link the outputs 00:07:52.120 --> 00:07:54.310 to a specific person. 00:07:54.310 --> 00:07:56.920 And hiding the amounts makes them really hard 00:07:56.920 --> 00:07:57.640 to distinguish. 00:07:57.640 --> 00:07:59.980 So if you don't know the amounts, 00:07:59.980 --> 00:08:02.860 they become completely uniform where this 00:08:02.860 --> 00:08:05.690 is a completely random address. 00:08:05.690 --> 00:08:07.490 I have no idea how many coins there are. 00:08:07.490 --> 00:08:09.800 I have very little way to distinguish 00:08:09.800 --> 00:08:11.510 between these outputs. 00:08:11.510 --> 00:08:13.600 I can try to trace the graph and say, OK, well, 00:08:13.600 --> 00:08:15.350 this came from here-- this came from here, 00:08:15.350 --> 00:08:16.890 but they all look the same. 00:08:16.890 --> 00:08:19.970 So I've got this big graph with no real information 00:08:19.970 --> 00:08:22.610 other than the links between the notes, 00:08:22.610 --> 00:08:23.750 which is still information. 00:08:23.750 --> 00:08:28.100 But it's much harder to tell what's going on. 00:08:28.100 --> 00:08:31.640 So we're sold-- how do we do it? 00:08:31.640 --> 00:08:33.094 First, we need to define-- 00:08:33.094 --> 00:08:35.742 what exactly are we trying to do? 00:08:35.742 --> 00:08:36.950 What are we hiding from whom? 00:08:36.950 --> 00:08:39.740 Who knows what and when kind of thing? 00:08:39.740 --> 00:08:44.159 So the long-term state of the system-- 00:08:44.159 --> 00:08:46.180 no one can see any-- 00:08:46.180 --> 00:08:47.960 no one can see it in the amounts. 00:08:47.960 --> 00:08:50.080 A has signed a signature from key A-- 00:08:50.080 --> 00:08:51.520 a signature from key B-- 00:08:51.520 --> 00:08:52.510 some amount of coins. 00:08:52.510 --> 00:08:55.780 You don't see it. you don't see any of this. 00:08:55.780 --> 00:08:57.490 So that's the long-term state. 00:08:57.490 --> 00:09:00.160 But wait, people receiving the payments 00:09:00.160 --> 00:09:02.830 should probably know how much they're receiving, right? 00:09:02.830 --> 00:09:05.348 And they should probably know how much they have. 00:09:05.348 --> 00:09:07.390 If you don't know how much money you're getting-- 00:09:07.390 --> 00:09:09.955 that's not a very useful payment system. 00:09:09.955 --> 00:09:11.830 People sending should-- they should also know 00:09:11.830 --> 00:09:13.360 how much money they're sending. 00:09:13.360 --> 00:09:17.230 If the amount can be completely determined by the receiver-- 00:09:17.230 --> 00:09:19.000 that's also not a good payment system. 00:09:19.000 --> 00:09:22.150 I'm just going to take lots of money. 00:09:22.150 --> 00:09:25.270 So we can have two views. 00:09:25.270 --> 00:09:30.040 We can say, OK, only the sender and receiver know the amounts. 00:09:30.040 --> 00:09:32.900 How about that-- where from the network's point of view-- 00:09:32.900 --> 00:09:35.950 so if I'm just the third party looking at this transaction-- 00:09:35.950 --> 00:09:37.510 I don't see any of the amounts. 00:09:37.510 --> 00:09:38.770 I just see there's no-- 00:09:38.770 --> 00:09:41.200 I have no idea how many coins are being sent. 00:09:41.200 --> 00:09:43.330 But from the sender's view, the sender 00:09:43.330 --> 00:09:45.190 says, OK, I know I have 2 coins here. 00:09:45.190 --> 00:09:48.340 7 coins-- I changed it from 2 and 10 on that line-- 00:09:48.340 --> 00:09:49.980 2 coins here, 7 coins here. 00:09:49.980 --> 00:09:52.870 And I'm sending 7 coins here and 2 coins there. 00:09:52.870 --> 00:09:54.580 So the sender knows the whole thing 00:09:54.580 --> 00:09:56.980 because they're the ones creating this transaction. 00:09:56.980 --> 00:10:02.980 And then maybe the receiver doesn't see everything. 00:10:02.980 --> 00:10:07.900 Maybe the sender can prove to the receiver a single amount 00:10:07.900 --> 00:10:09.860 but hide everything else. 00:10:09.860 --> 00:10:11.080 That would be ideal. 00:10:11.080 --> 00:10:16.460 So the receiver only sees, oh, I'm receiving 2 coins, 00:10:16.460 --> 00:10:19.120 but I don't know. 00:10:19.120 --> 00:10:21.580 If I know this, then I can figure out 00:10:21.580 --> 00:10:24.012 what these are, or at least the sum of them. 00:10:24.012 --> 00:10:25.720 But if I don't know any of these things-- 00:10:25.720 --> 00:10:29.140 I don't know how much the person sending me money has. 00:10:29.140 --> 00:10:30.820 I just know, oh, I got 2 coins. 00:10:30.820 --> 00:10:32.350 Cool, that's what I wanted. 00:10:32.350 --> 00:10:35.470 But I don't learn anything about their inputs 00:10:35.470 --> 00:10:37.570 or their other outputs within the transaction. 00:10:37.570 --> 00:10:39.820 So that would be ideal if we can do that. 00:10:39.820 --> 00:10:43.180 So what we want is a system where network 00:10:43.180 --> 00:10:45.130 doesn't see any of the amounts. 00:10:45.130 --> 00:10:48.010 The sender presumably sees all of it. 00:10:48.010 --> 00:10:51.353 Now, there could be cases where there's multiple senders, 00:10:51.353 --> 00:10:54.020 and there are two people working together to make a transaction, 00:10:54.020 --> 00:10:56.410 and maybe we don't see each other's inputs, 00:10:56.410 --> 00:10:59.890 but we'll keep it simple for now where there's a single sender. 00:10:59.890 --> 00:11:03.460 And then the receiver only sees their own output. 00:11:03.460 --> 00:11:05.650 So that would be a really powerful system. 00:11:05.650 --> 00:11:07.270 Then the receiver would only know 00:11:07.270 --> 00:11:09.160 they're getting the right amount and not 00:11:09.160 --> 00:11:13.240 learn anything else about the sender's coins. 00:11:13.240 --> 00:11:15.250 So we might want to-- like I was saying, 00:11:15.250 --> 00:11:17.440 you might want to hide per output. 00:11:17.440 --> 00:11:18.580 So if you have a-- 00:11:18.580 --> 00:11:20.605 if it's a global-- 00:11:20.605 --> 00:11:23.230 either you see everything or you see-- sorry-- you see nothing, 00:11:23.230 --> 00:11:25.870 or you see everything-- that's still pretty good. 00:11:25.870 --> 00:11:28.380 That's still better than what we have 00:11:28.380 --> 00:11:31.330 when everyone sees everything, but it is better 00:11:31.330 --> 00:11:33.940 if you can hide the rest of these three things 00:11:33.940 --> 00:11:36.670 from the receiver. 00:11:36.670 --> 00:11:39.270 So any ideas? 00:11:39.270 --> 00:11:41.152 Some kind of encryption? 00:11:41.152 --> 00:11:42.610 Hide the amounts so the only people 00:11:42.610 --> 00:11:44.720 with the right private key can see the numbers? 00:11:47.920 --> 00:11:51.460 So, I don't think I've even talked about encryption ever 00:11:51.460 --> 00:11:55.270 in this class, because there is no encryption in blockchains. 00:11:55.270 --> 00:11:57.257 [LAUGHS] Which is something you-- 00:11:57.257 --> 00:11:58.840 if you read something about blockchain 00:11:58.840 --> 00:12:00.190 and you're like blockchain is encrypted. 00:12:00.190 --> 00:12:01.857 And you're like no, no-- they don't know 00:12:01.857 --> 00:12:03.190 what they're talking about. 00:12:03.190 --> 00:12:05.710 So I haven't defined encryption. 00:12:05.710 --> 00:12:08.560 But encryption is-- generally, you have some kind of private 00:12:08.560 --> 00:12:09.430 key-- 00:12:09.430 --> 00:12:12.450 you take a clear text, you apply-- you do some-- 00:12:15.490 --> 00:12:18.610 so like I had with signatures, you have a set of functions. 00:12:18.610 --> 00:12:22.240 So encryption is-- you've got some encryption function which 00:12:22.240 --> 00:12:28.512 takes a key and a message and outputs a ciphertext. 00:12:28.512 --> 00:12:30.970 And then you've got some kind of decryption function, which 00:12:30.970 --> 00:12:34.810 takes off in the same key or something and then 00:12:34.810 --> 00:12:37.592 the ciphertext and outputs the same message. 00:12:37.592 --> 00:12:39.550 And this is symmetric encryption because you're 00:12:39.550 --> 00:12:41.560 using the same key. 00:12:41.560 --> 00:12:43.750 You can also have asymmetric encryption 00:12:43.750 --> 00:12:45.970 where this could be a public key, 00:12:45.970 --> 00:12:48.200 and this could be a private key. 00:12:48.200 --> 00:12:50.920 So in order to decrypt, you need the private key, 00:12:50.920 --> 00:12:53.680 but in order to encrypt, you only need someone's public key. 00:12:56.200 --> 00:13:01.210 So, in practice, all the things that people-- 00:13:01.210 --> 00:13:02.650 in practice, you usually stage it, 00:13:02.650 --> 00:13:06.730 so you have an asymmetric algorithm to agree on a key, 00:13:06.730 --> 00:13:09.580 and then you just use the symmetric encryption 00:13:09.580 --> 00:13:11.980 and decryption where the keys are the same because it's 00:13:11.980 --> 00:13:14.080 way faster. 00:13:14.080 --> 00:13:17.800 So you can do this operation on the order of hundreds 00:13:17.800 --> 00:13:22.100 of megabytes a second, whereas the asymmetric ones are slow-- 00:13:22.100 --> 00:13:23.843 it's sort of like signing. 00:13:23.843 --> 00:13:25.010 Maybe I'll go into it later. 00:13:25.010 --> 00:13:27.400 But if you understand all the signing and stuff, 00:13:27.400 --> 00:13:29.818 it's not too bad. 00:13:29.818 --> 00:13:31.360 But so maybe you could say, OK, well, 00:13:31.360 --> 00:13:34.310 there's some kind of private key that the sender creates-- 00:13:34.310 --> 00:13:38.560 encrypts the amounts, and then they put the encrypted amounts 00:13:38.560 --> 00:13:45.550 in the transaction, and they reveal the key to the receiver. 00:13:45.550 --> 00:13:48.040 And, potentially, you could have different keys 00:13:48.040 --> 00:13:50.470 for each amount-- 00:13:50.470 --> 00:13:52.873 that would work. 00:13:52.873 --> 00:13:54.040 Any problems with that idea? 00:13:57.705 --> 00:13:58.830 You can encrypt everything. 00:13:58.830 --> 00:14:00.335 Yeah, you know? 00:14:00.335 --> 00:14:03.060 AUDIENCE: You would need to send over a public key or something 00:14:03.060 --> 00:14:04.570 so they can decrypt it. 00:14:04.570 --> 00:14:08.800 TADGE DRYJA: Yeah, oh, OK, so that is a sort of problem-- 00:14:08.800 --> 00:14:09.540 it's a limit. 00:14:09.540 --> 00:14:13.230 But that limit will carry forward to the stuff we do. 00:14:13.230 --> 00:14:14.640 So you're going to have to-- 00:14:14.640 --> 00:14:18.090 right now, in Bitcoin, you can find someone's address, 00:14:18.090 --> 00:14:19.710 send them the coins-- you're good. 00:14:19.710 --> 00:14:21.210 With this system, there will be more 00:14:21.210 --> 00:14:23.190 interactivity between sender and receiver. 00:14:23.190 --> 00:14:26.770 So that's not great, but not a deal breaker. 00:14:26.770 --> 00:14:28.647 So we will need to do that. 00:14:28.647 --> 00:14:29.230 Other problem? 00:14:29.230 --> 00:14:29.570 Yeah. 00:14:29.570 --> 00:14:30.490 AUDIENCE: A key for every amount. 00:14:30.490 --> 00:14:31.496 TADGE DRYJA: Yeah. 00:14:31.496 --> 00:14:35.187 AUDIENCE: [INAUDIBLE] because of the fact that there can be 00:14:35.187 --> 00:14:38.591 a lot of different ways to split up the-- 00:14:38.591 --> 00:14:41.670 TADGE DRYJA: Yeah, it could get bigger. 00:14:41.670 --> 00:14:44.290 And the actual solution gets big. 00:14:44.290 --> 00:14:46.110 So that's not great either. 00:14:46.110 --> 00:14:48.456 But the one that really screws it up. 00:14:48.456 --> 00:14:49.157 [LAUGHS] Yeah. 00:14:49.157 --> 00:14:51.240 AUDIENCE: How do the nodes verify the transaction? 00:14:51.240 --> 00:14:54.090 TADGE DRYJA: So the nodes don't verify the transaction at all 00:14:54.090 --> 00:14:55.680 because they can't see anything. 00:14:55.680 --> 00:14:57.660 Well, I can do that. 00:14:57.660 --> 00:15:01.770 Well, how about I just make 70 coins and 2,000 coins? 00:15:01.770 --> 00:15:03.600 I can make as many coins as I want. 00:15:03.600 --> 00:15:08.490 No one can see anything because the network just sees nothing-- 00:15:08.490 --> 00:15:10.410 have no idea how many coins are being sent. 00:15:10.410 --> 00:15:12.480 But I'd be like, hey, hey, I'm making 00:15:12.480 --> 00:15:14.400 more coins all over the place. 00:15:14.400 --> 00:15:17.250 [LAUGHS] And this doesn't work. 00:15:17.250 --> 00:15:20.490 Because if I can send coins to myself 00:15:20.490 --> 00:15:25.620 and multiply them indefinitely, and it's hidden-- 00:15:25.620 --> 00:15:27.120 so to some extent, you're like well, 00:15:27.120 --> 00:15:29.130 maybe the network doesn't care. 00:15:29.130 --> 00:15:36.073 Because well, I'm making them, but they're only my own coins. 00:15:36.073 --> 00:15:37.740 But if the network doesn't see anything, 00:15:37.740 --> 00:15:39.300 it's easy to create the coins. 00:15:39.300 --> 00:15:41.760 And if those coins are later used, 00:15:41.760 --> 00:15:43.480 I can't tell if they were made up or not. 00:15:43.480 --> 00:15:45.220 So if I'm accepting-- 00:15:45.220 --> 00:15:49.500 so if I see this, and someone's like, hey, here's 2,000 coins-- 00:15:49.500 --> 00:15:51.610 I'm like dude, you're making them up. 00:15:51.610 --> 00:15:54.470 You can't write extra zeros on $100 bill 00:15:54.470 --> 00:15:55.470 and be like here you go. 00:15:55.470 --> 00:15:56.868 This is-- come on. 00:15:56.868 --> 00:15:58.410 No one's going to accept these later. 00:16:03.290 --> 00:16:04.710 I won't even know. 00:16:04.710 --> 00:16:06.150 Did you even have 7? 00:16:06.150 --> 00:16:08.360 Does this 7 coins come from something 00:16:08.360 --> 00:16:10.680 where you did the same kind of thing before? 00:16:10.680 --> 00:16:13.710 So, basically, if we do that where we completely 00:16:13.710 --> 00:16:16.520 obscure the amounts from the network 00:16:16.520 --> 00:16:19.500 and from all third parties, then anytime I'm 00:16:19.500 --> 00:16:21.780 going to accept this, I'm going to have 00:16:21.780 --> 00:16:24.030 to enforce the rules myself. 00:16:24.030 --> 00:16:28.170 And then retroactively enforce the rules for all transactions 00:16:28.170 --> 00:16:32.100 beforehand to make sure nothing like this happened. 00:16:32.100 --> 00:16:33.840 So we could do that. 00:16:33.840 --> 00:16:34.740 It's all obscured. 00:16:34.740 --> 00:16:37.230 The third-party-- the network doesn't see anything. 00:16:37.230 --> 00:16:39.390 And it's up to the participants themselves 00:16:39.390 --> 00:16:41.910 to say, well, if you're going to send me coins-- 00:16:41.910 --> 00:16:44.242 since I know if I'm sending it to someone later, 00:16:44.242 --> 00:16:46.200 I'm going to have to provide some kind of proof 00:16:46.200 --> 00:16:49.080 that this kind of nonsense didn't happen. 00:16:49.080 --> 00:16:51.180 I'm also going to need proof that all 00:16:51.180 --> 00:16:52.770 of the ancestor transactions that 00:16:52.770 --> 00:16:55.210 led to these 2 and 7 coins-- 00:16:55.210 --> 00:16:57.300 I'm going to need those amounts. 00:16:57.300 --> 00:16:59.700 And, so, yeah, you could maybe do that. 00:16:59.700 --> 00:17:05.599 You could provide the decryption keys for all previous amounts. 00:17:05.599 --> 00:17:08.599 But that basically gets you back to where we are right now-- 00:17:08.599 --> 00:17:10.849 not quite, but pretty close. 00:17:14.883 --> 00:17:16.550 Either you allow people to create coins, 00:17:16.550 --> 00:17:19.730 or you basically are revealing close to all previous amounts 00:17:19.730 --> 00:17:21.380 eventually to everyone. 00:17:21.380 --> 00:17:24.359 Because as that transaction graph gets bigger and bigger, 00:17:24.359 --> 00:17:27.410 I'm going to start having all these thousands and thousands 00:17:27.410 --> 00:17:29.660 of ancestor transactions that I'm going 00:17:29.660 --> 00:17:31.553 to have to require proof for. 00:17:31.553 --> 00:17:33.470 I'm going to require all those decryption keys 00:17:33.470 --> 00:17:35.630 to make sure nothing like this happened. 00:17:35.630 --> 00:17:37.940 And then eventually, all the people receiving money 00:17:37.940 --> 00:17:39.770 will be able to see everything-- well, not 00:17:39.770 --> 00:17:42.020 quite everything, but a lot. 00:17:42.020 --> 00:17:44.570 So it's like well, third-parties-- 00:17:44.570 --> 00:17:47.600 the miners or maybe people who are just looking 00:17:47.600 --> 00:17:50.810 at the blockchain who aren't really receiving any funds-- 00:17:50.810 --> 00:17:53.280 maybe it's hidden from them. 00:17:53.280 --> 00:17:55.190 But once you start using the system, 00:17:55.190 --> 00:17:57.747 you're going to basically be able to see everything. 00:17:57.747 --> 00:17:58.580 So that's not great. 00:18:01.130 --> 00:18:03.227 And it would also be really annoying 00:18:03.227 --> 00:18:05.060 because then when you have to receive coins, 00:18:05.060 --> 00:18:07.310 you have to go back through thousands of transactions 00:18:07.310 --> 00:18:09.090 to make sure that didn't happen. 00:18:09.090 --> 00:18:14.450 So we need to prevent coin creation while still 00:18:14.450 --> 00:18:16.870 keeping the amount secret. 00:18:16.870 --> 00:18:19.120 This is a tricky problem-- 00:18:19.120 --> 00:18:23.810 any general ideas here? 00:18:23.810 --> 00:18:27.250 So wouldn't it be cool if we could 00:18:27.250 --> 00:18:32.102 do this where the network sees there's w coins here, 00:18:32.102 --> 00:18:34.060 there's x coins here, and there's y coins here, 00:18:34.060 --> 00:18:35.470 there's z coins here? 00:18:35.470 --> 00:18:38.170 And then we have a proof-- 00:18:38.170 --> 00:18:41.500 w plus x equals y plus z, without telling you 00:18:41.500 --> 00:18:43.630 what w, x, y, and z are. 00:18:46.260 --> 00:18:47.070 Cool. 00:18:47.070 --> 00:18:48.330 Let's do it. 00:18:48.330 --> 00:18:48.830 Any ideas? 00:18:48.830 --> 00:18:52.290 [LAUGHS] 00:18:52.290 --> 00:18:56.670 So this seems like this would work. 00:18:56.670 --> 00:19:00.130 This would do it in that if we can reveal like say, hey, 00:19:00.130 --> 00:19:02.370 the person d-- 00:19:02.370 --> 00:19:03.930 z is 2. 00:19:03.930 --> 00:19:05.050 Cool. 00:19:05.050 --> 00:19:06.390 So I got 2 coins. 00:19:06.390 --> 00:19:11.130 And they can also verify that these amounts are correct. 00:19:11.130 --> 00:19:12.150 And then if you're-- 00:19:12.150 --> 00:19:15.490 you could either keep this proof only to the receiver, 00:19:15.490 --> 00:19:17.310 but then you'd have to give proofs 00:19:17.310 --> 00:19:19.140 about all the previous transactions, 00:19:19.140 --> 00:19:21.307 or you can just, say no-- the whole network enforces 00:19:21.307 --> 00:19:21.870 these groups. 00:19:21.870 --> 00:19:25.500 This is now a consensus rule where if you want-- 00:19:25.500 --> 00:19:27.390 even if it's not your transaction, 00:19:27.390 --> 00:19:30.180 it might be a parent of your transaction someday. 00:19:30.180 --> 00:19:31.440 So you have to verify it. 00:19:31.440 --> 00:19:33.180 If you're going to accept the block-- 00:19:33.180 --> 00:19:37.360 verify these proofs for every transaction. 00:19:37.360 --> 00:19:38.842 So that would work. 00:19:38.842 --> 00:19:41.590 AUDIENCE: So that's essentially a minor deal, right? 00:19:41.590 --> 00:19:44.640 TADGE DRYJA: Yeah, a miner, or-- 00:19:44.640 --> 00:19:47.340 the miners would do it and also the full nodes. 00:19:47.340 --> 00:19:48.600 If you're running a node-- 00:19:48.600 --> 00:19:50.280 well, I'm not receiving anything here, 00:19:50.280 --> 00:19:53.070 but I still need to make sure this is a valid transaction 00:19:53.070 --> 00:19:54.030 in order to accept it. 00:19:54.030 --> 00:19:56.610 AUDIENCE: Isn't that a problem then, because what if a miner 00:19:56.610 --> 00:19:59.415 is in that transaction? 00:19:59.415 --> 00:20:01.330 TADGE DRYJA: If the miner's receive-- 00:20:01.330 --> 00:20:03.170 the miners D in receiving this coin? 00:20:03.170 --> 00:20:03.956 AUDIENCE: Yeah. 00:20:03.956 --> 00:20:05.570 TADGE DRYJA: Then they'll know-- 00:20:05.570 --> 00:20:08.250 then they'll both get the proof, which 00:20:08.250 --> 00:20:09.540 is sort of redundant for them. 00:20:09.540 --> 00:20:12.180 And they'll also get the actual amount-- z. 00:20:12.180 --> 00:20:15.830 So they'll know this is 2. 00:20:15.830 --> 00:20:18.380 So that miner would know more, but that's OK. 00:20:18.380 --> 00:20:23.290 I guess other miners wouldn't-- or other nodes wouldn't. 00:20:23.290 --> 00:20:26.260 So if you're participating, you'll potentially know more. 00:20:26.260 --> 00:20:28.550 But the idea is third-parties see a proof 00:20:28.550 --> 00:20:31.150 and don't see the amounts. 00:20:31.150 --> 00:20:31.842 Yeah. 00:20:31.842 --> 00:20:33.827 AUDIENCE: So SPV will have no way 00:20:33.827 --> 00:20:36.930 of knowing if a transaction was valid until it was [INAUDIBLE]?? 00:20:36.930 --> 00:20:39.190 TADGE DRYJA: They already know. 00:20:39.190 --> 00:20:41.140 So SPV, while it's already have no idea 00:20:41.140 --> 00:20:43.300 how many coins are coming in on the inputs 00:20:43.300 --> 00:20:45.430 because they don't have a UTXO set. 00:20:45.430 --> 00:20:47.290 And the coin-- so if you see an input, 00:20:47.290 --> 00:20:49.577 you see it's pointing to some txid. 00:20:49.577 --> 00:20:51.160 I don't know how many coins there are. 00:20:51.160 --> 00:20:52.390 I would have to-- 00:20:52.390 --> 00:20:55.210 you could provide a proof to an SPV wallet 00:20:55.210 --> 00:20:56.830 that, hey, there were-- 00:20:56.830 --> 00:20:58.840 I can give you that previous transaction, 00:20:58.840 --> 00:21:02.230 and you can see how many coins, but then what about the one 00:21:02.230 --> 00:21:02.750 before that? 00:21:02.750 --> 00:21:05.710 So, generally, SPV wallets can't enforce 00:21:05.710 --> 00:21:08.080 that amounts are correct or verify signatures, 00:21:08.080 --> 00:21:11.740 because they don't know enough about these inputs, 00:21:11.740 --> 00:21:13.870 whereas full nodes-- 00:21:13.870 --> 00:21:16.210 when you tell me to input 0, I know how much. 00:21:16.210 --> 00:21:18.370 I know what keys-- things like that. 00:21:18.370 --> 00:21:21.430 So SPV can't well-- 00:21:21.430 --> 00:21:24.490 no there's maybe some way to make the SPV 00:21:24.490 --> 00:21:27.100 have it so that SPV proofs are compatible with this. 00:21:27.100 --> 00:21:30.270 But it's-- you already don't have that. 00:21:30.270 --> 00:21:34.300 So I don't think there's much idea-- 00:21:34.300 --> 00:21:36.640 there's much much research into how 00:21:36.640 --> 00:21:39.670 to make this SPV compatible. 00:21:39.670 --> 00:21:41.050 But yeah, it's a good question. 00:21:41.050 --> 00:21:43.600 Other basic ideas? 00:21:43.600 --> 00:21:44.920 So how do we do this? 00:21:44.920 --> 00:21:48.580 [LAUGHS] So this will take a little-- 00:21:48.580 --> 00:21:53.390 the actual way to do this will take the rest of the class. 00:21:53.390 --> 00:21:56.790 Because there's a lot of things where that seems like 00:21:56.790 --> 00:21:59.590 it'll work, and it's like oh, no, it doesn't. 00:21:59.590 --> 00:22:04.240 And this is sort of replaying the ideas from several years 00:22:04.240 --> 00:22:06.612 of people trying to do this. 00:22:06.612 --> 00:22:07.570 So how will we do this? 00:22:07.570 --> 00:22:11.030 So there's an idea called commitments. 00:22:11.030 --> 00:22:13.690 And the simplest form of a commitment is you 00:22:13.690 --> 00:22:15.560 commit to some value-- 00:22:15.560 --> 00:22:17.380 you ouput it-- call it c-- 00:22:17.380 --> 00:22:20.590 and then you reveal the value and then someone can verify. 00:22:20.590 --> 00:22:25.630 Well, given c and the value you just revealed, 00:22:25.630 --> 00:22:29.020 is that a correct commitment? 00:22:29.020 --> 00:22:32.820 So I'm committing to the value 2. 00:22:32.820 --> 00:22:36.700 I'm outputting something c and then revealing it was 2. 00:22:36.700 --> 00:22:39.220 And let me throw this into my function. 00:22:39.220 --> 00:22:42.010 2 and c-- do those match? 00:22:42.010 --> 00:22:43.270 Oh, it's true-- we're good. 00:22:46.402 --> 00:22:48.360 And then there's certain properties you'd want. 00:22:48.360 --> 00:22:50.760 You don't want people to-- 00:22:50.760 --> 00:22:52.650 I think I have slides about that. 00:22:52.650 --> 00:22:56.340 So the hash function is a commitment. 00:22:56.340 --> 00:23:00.310 I can say the hash of 5 is 68 empty-- whatever. 00:23:00.310 --> 00:23:02.700 And then I commit to 68 something. 00:23:02.700 --> 00:23:04.533 I publish this, and I tell everyone 00:23:04.533 --> 00:23:05.700 I'm committing to something. 00:23:05.700 --> 00:23:08.075 I'm not going to tell you what I'm committing to exactly, 00:23:08.075 --> 00:23:10.350 but here's this 68fde0b7-- 00:23:10.350 --> 00:23:12.630 some long hash output. 00:23:12.630 --> 00:23:18.610 And then I reveal days later the thing 00:23:18.610 --> 00:23:21.100 I was committing to-- that was 5. 00:23:21.100 --> 00:23:23.410 And then everyone can check. 00:23:23.410 --> 00:23:25.490 Let me throw 5 into my hash function. 00:23:25.490 --> 00:23:27.190 Oh, yeah, it was this. 00:23:27.190 --> 00:23:28.070 True. 00:23:28.070 --> 00:23:29.320 So that's a commitment scheme. 00:23:32.510 --> 00:23:33.350 It is binding. 00:23:33.350 --> 00:23:35.660 So there's binding and hiding, and there's 00:23:35.660 --> 00:23:37.970 different properties of commitment schemes. 00:23:37.970 --> 00:23:41.570 So this we could say is a computationally binding 00:23:41.570 --> 00:23:43.700 commitment scheme. 00:23:43.700 --> 00:23:46.040 Once I've committed to this, I'm not 00:23:46.040 --> 00:23:48.960 going to be able to find another number. 00:23:48.960 --> 00:23:52.390 So I'm not going to be able to say, oh, it was 6 00:23:52.390 --> 00:23:55.750 And then get the same commitment out. 00:23:55.750 --> 00:23:58.750 So I'm not going to-- so in practice, this is really long. 00:23:58.750 --> 00:24:01.905 This is a shot 2 output. 00:24:01.905 --> 00:24:03.530 I didn't want to write the whole thing, 00:24:03.530 --> 00:24:06.380 but it goes to here, or two lines. 00:24:06.380 --> 00:24:10.100 So the idea is I can't find another number, especially 00:24:10.100 --> 00:24:11.240 exactly the number I want. 00:24:11.240 --> 00:24:13.880 But I can't find any other number that will get me 00:24:13.880 --> 00:24:15.950 to that same hash output. 00:24:15.950 --> 00:24:18.650 That's a collision, and I'm going to have to try it. 00:24:18.650 --> 00:24:22.970 Wait, so for a specific number, I'd have to try 2 to the 256. 00:24:22.970 --> 00:24:26.180 For any collision, I only have to do 2 the 128. 00:24:26.180 --> 00:24:29.660 But still, both of those are really big numbers. 00:24:29.660 --> 00:24:30.830 I can't do it. 00:24:30.830 --> 00:24:32.660 So it's computationally binding. 00:24:32.660 --> 00:24:35.690 If I had some amazing computer that 00:24:35.690 --> 00:24:40.820 could perform an infinite calculation, 00:24:40.820 --> 00:24:44.120 I could find a collision. 00:24:44.120 --> 00:24:47.000 So there's the distinction between computationally 00:24:47.000 --> 00:24:49.070 and information theoretically. 00:24:49.070 --> 00:24:50.990 Information theoretically is stronger 00:24:50.990 --> 00:24:55.550 where even if I had the most powerful computer, 00:24:55.550 --> 00:24:59.150 I still couldn't do this, whereas binding, in this case, 00:24:59.150 --> 00:25:00.470 it's computationally binding-- 00:25:00.470 --> 00:25:02.533 computationally is good enough. 00:25:02.533 --> 00:25:03.950 Everything in Bitcoin is already-- 00:25:03.950 --> 00:25:05.300 everything in all these systems is already 00:25:05.300 --> 00:25:06.590 basically computational. 00:25:06.590 --> 00:25:11.460 There are some schemes, which are not computationally bound. 00:25:11.460 --> 00:25:13.970 So one of the parts here-- 00:25:13.970 --> 00:25:17.780 and the Pedersen commitments are not computationally-- 00:25:17.780 --> 00:25:20.810 and things like severe secret sharing and a couple 00:25:20.810 --> 00:25:25.190 other things where this is not dependent on processing power. 00:25:25.190 --> 00:25:27.110 Even if you have infinite processing power, 00:25:27.110 --> 00:25:30.230 you just can't figure out what the values are, 00:25:30.230 --> 00:25:33.450 which is cooler, but it's nice to have. 00:25:33.450 --> 00:25:36.810 It's not a requirement for our systems. 00:25:36.810 --> 00:25:38.520 So this is binding. 00:25:38.520 --> 00:25:41.940 Any ideas of what this is not-- why this would not 00:25:41.940 --> 00:25:44.830 be a good commitment scheme? 00:25:44.830 --> 00:25:49.620 You want to commit to a value and then later reveal it. 00:25:49.620 --> 00:25:51.780 You don't want the person who's committing 00:25:51.780 --> 00:25:54.570 to be able to change their commitment. 00:25:54.570 --> 00:25:58.090 What else might you want that this probably doesn't provide? 00:26:02.110 --> 00:26:03.610 AUDIENCE: Do you need some way to be 00:26:03.610 --> 00:26:05.614 able to hash the commitment? 00:26:05.614 --> 00:26:06.920 TADGE DRYJA: Yep. 00:26:06.920 --> 00:26:09.015 So you want to be able to do fancy stuff 00:26:09.015 --> 00:26:09.890 with the commitments. 00:26:09.890 --> 00:26:13.370 Before we even get there, that's in 5 or 6 slides-- 00:26:13.370 --> 00:26:15.050 before we even get there, this doesn't 00:26:15.050 --> 00:26:16.700 satisfy something else we want. 00:26:19.240 --> 00:26:19.740 Yeah. 00:26:19.740 --> 00:26:22.100 AUDIENCE: All but like 5 is such a common number? 00:26:22.100 --> 00:26:24.210 TADGE DRYJA: This is easy to guess. 00:26:24.210 --> 00:26:27.150 So if I'm committing to a number, 00:26:27.150 --> 00:26:29.220 I'm going to commit to the number of pizzas 00:26:29.220 --> 00:26:30.990 I'm ordering at my party. 00:26:30.990 --> 00:26:32.490 And everyone's wondering how many 00:26:32.490 --> 00:26:35.130 pieces are you going to order? 00:26:35.130 --> 00:26:37.470 I try things. 00:26:37.470 --> 00:26:39.450 It's binding, but it's not hiding. 00:26:39.450 --> 00:26:44.790 So verifier can easily guess and check the committed value. 00:26:44.790 --> 00:26:49.000 So for i equals 0. 00:26:49.000 --> 00:26:52.000 Just keep trying different i's and see 00:26:52.000 --> 00:26:54.880 if the hash matches 68fd even. 00:26:54.880 --> 00:26:56.500 And this will take very little time 00:26:56.500 --> 00:26:59.180 because 5 is going to happen pretty quick. 00:26:59.180 --> 00:27:01.750 And then everyone will know he's ordering five pizzas-- 00:27:01.750 --> 00:27:03.460 sounds like a decent party, but not 00:27:03.460 --> 00:27:07.560 really worth going out of my way to go to. 00:27:07.560 --> 00:27:10.590 If it was fffff pizzas-- that would be something else. 00:27:10.590 --> 00:27:15.250 So solution-- pretty straightforward solution. 00:27:15.250 --> 00:27:17.370 Add a blinding factor. 00:27:17.370 --> 00:27:22.620 So we're going to call that, r I guess, r is random. 00:27:22.620 --> 00:27:26.760 So r is b8bc7579. 00:27:26.760 --> 00:27:30.590 And now I'm going to take the hash of 5 and concatenate r, 00:27:30.590 --> 00:27:32.970 and now this is a different hash. 00:27:32.970 --> 00:27:37.240 And now to reveal what I was committing to-- 00:27:37.240 --> 00:27:39.120 you reveal both 5 and r. 00:27:44.120 --> 00:27:48.010 And you need to tell people what order you're doing things in. 00:27:48.010 --> 00:27:50.920 The system needs to be predefined. 00:27:50.920 --> 00:27:52.840 When you're committing, you also have 00:27:52.840 --> 00:27:56.200 to commit to the algorithms or have pre-agreed 00:27:56.200 --> 00:27:57.910 upon algorithms, because otherwise, you 00:27:57.910 --> 00:28:00.310 could do something-- no, I committed to r. 00:28:00.310 --> 00:28:02.080 5 was my blinding factor. 00:28:02.080 --> 00:28:07.210 You need to have protocols set up beforehand, which you never 00:28:07.210 --> 00:28:08.320 know, that could be some-- 00:28:08.320 --> 00:28:09.445 if you say, I'm committing. 00:28:09.445 --> 00:28:10.872 Here's this value. 00:28:10.872 --> 00:28:11.830 How are you committing? 00:28:11.830 --> 00:28:13.380 What hash functions? 00:28:13.380 --> 00:28:14.920 What are you doing? 00:28:14.920 --> 00:28:16.948 But that's obvious. 00:28:16.948 --> 00:28:18.490 It might not be super obvious, so you 00:28:18.490 --> 00:28:21.580 have to be careful on that. 00:28:21.580 --> 00:28:23.090 So this is now blinding. 00:28:23.090 --> 00:28:29.350 And it's hidden, and it's still binding. 00:28:29.350 --> 00:28:31.240 You can't change it to 6. 00:28:31.240 --> 00:28:34.500 I think that's the next slide, wait. 00:28:34.500 --> 00:28:39.030 So you can't change this to 6 and change to a different r. 00:28:39.030 --> 00:28:40.470 I mean, you could, but you'd still 00:28:40.470 --> 00:28:43.370 have to do a lot of computation. 00:28:43.370 --> 00:28:46.680 And this is now-- 00:28:46.680 --> 00:28:47.880 some things get easier. 00:28:47.880 --> 00:28:56.590 So before if you really wanted to reveal that it was 6, 00:28:56.590 --> 00:28:58.380 you basically can. 00:28:58.380 --> 00:29:02.010 Because there's a single output for 6, and it just 00:29:02.010 --> 00:29:02.900 doesn't match this. 00:29:02.900 --> 00:29:06.210 So there's not-- if you have a single chosen value that you 00:29:06.210 --> 00:29:09.218 want to reveal that's not the one that you committed to-- 00:29:09.218 --> 00:29:10.260 you're basically stopped. 00:29:10.260 --> 00:29:12.990 There's no way to get around it even computationally. 00:29:12.990 --> 00:29:15.030 With this-- that's not true. 00:29:15.030 --> 00:29:17.640 It's like I really want to reveal 6, 00:29:17.640 --> 00:29:21.480 I can come up with a different r such that the hash of 6 00:29:21.480 --> 00:29:23.400 and our prime is that. 00:29:23.400 --> 00:29:26.620 And then that's now computational-- 00:29:26.620 --> 00:29:28.900 slight distinction. 00:29:28.900 --> 00:29:31.340 It's still binding computationally. 00:29:31.340 --> 00:29:35.342 But before, chosen values may not have been. 00:29:35.342 --> 00:29:36.800 So that's, I guess, the difference. 00:29:36.800 --> 00:29:38.750 It's computationally binding for any value. 00:29:38.750 --> 00:29:41.773 But for a specific value, it might be-- 00:29:41.773 --> 00:29:43.190 not information theoretic, but you 00:29:43.190 --> 00:29:46.130 can't do it, because the hash function doesn't help you 00:29:46.130 --> 00:29:47.300 there. 00:29:47.300 --> 00:29:48.950 So what else do we want to do? 00:29:48.950 --> 00:29:52.620 You're saying we need more. 00:29:52.620 --> 00:29:56.180 We want to be able to prove things about the commitments. 00:29:56.180 --> 00:29:59.120 So we need some kind of homomorphic commitments. 00:29:59.120 --> 00:30:01.880 And we've seen the homomorphic properties 00:30:01.880 --> 00:30:04.760 of these elliptic curve points, which are really nice-- 00:30:04.760 --> 00:30:06.800 where you can add private keys or add 00:30:06.800 --> 00:30:10.310 scalars, and that's the same as adding these points on a curve. 00:30:10.310 --> 00:30:14.010 So let's try that. 00:30:14.010 --> 00:30:15.360 We want something like this. 00:30:15.360 --> 00:30:18.780 We want a-- commit to x, commit to y, 00:30:18.780 --> 00:30:21.350 and get these commitments-- a and b. 00:30:21.350 --> 00:30:25.260 And then we want to reveal z, which is x plus y. 00:30:28.910 --> 00:30:30.840 And then we want the verify function 00:30:30.840 --> 00:30:35.160 that's put z in and a and b-- either a plus b 00:30:35.160 --> 00:30:38.310 or a and b separately and return true. 00:30:38.310 --> 00:30:41.940 So we don't want to reveal x and y separately. 00:30:41.940 --> 00:30:45.540 We will reveal the sum of x plus y. 00:30:45.540 --> 00:30:48.450 And then we will reveal-- 00:30:48.450 --> 00:30:51.120 and then we'll have the commitments themselves. 00:30:51.120 --> 00:30:53.400 So since these are the same operators, 00:30:53.400 --> 00:30:55.985 it'd be cool if that worked. 00:30:55.985 --> 00:30:56.860 This is what we want. 00:31:01.030 --> 00:31:02.110 So that's not that bad. 00:31:02.110 --> 00:31:04.780 But we also want all those properties where it's hiding, 00:31:04.780 --> 00:31:07.100 and it's binding and things like that. 00:31:07.100 --> 00:31:10.160 So what should we try? 00:31:13.350 --> 00:31:18.063 First idea is-- this would be useful. 00:31:18.063 --> 00:31:18.980 How can we build this? 00:31:18.980 --> 00:31:21.680 We want to-- we can reveal sums without revealing 00:31:21.680 --> 00:31:24.720 individual parts that we've committed to. 00:31:24.720 --> 00:31:29.330 So probably the first idea is let's just use 00:31:29.330 --> 00:31:30.650 private keys and public keys. 00:31:30.650 --> 00:31:33.740 Let's use a times g-- 00:31:33.740 --> 00:31:35.080 that kind of thing. 00:31:35.080 --> 00:31:37.000 Oh, oh-- I forgot the joke-- 00:31:37.000 --> 00:31:39.986 was going to say, gee, how can we build this? g-- 00:31:39.986 --> 00:31:43.370 it's g. 00:31:43.370 --> 00:31:44.585 You want a commitment to act. 00:31:44.585 --> 00:31:45.710 You want a commitment to y. 00:31:45.710 --> 00:31:48.020 You want to reveal z is x plus y. 00:31:48.020 --> 00:31:49.100 So what if you did this? 00:31:49.100 --> 00:31:51.890 You said, I'm going to make a point on the curve-- 00:31:51.890 --> 00:31:55.100 x, which is just my value x times g-- 00:31:55.100 --> 00:31:59.240 point on the curve y, which is my value y times g. 00:31:59.240 --> 00:32:03.120 This does have that homomorphic property. 00:32:03.120 --> 00:32:05.395 But is this binding? 00:32:12.440 --> 00:32:14.110 It is. 00:32:14.110 --> 00:32:18.700 I can't come up with a different x that gets me to that point. 00:32:18.700 --> 00:32:20.680 So multiplying by the generator point 00:32:20.680 --> 00:32:23.690 is a hash function in that you're not going 00:32:23.690 --> 00:32:25.590 to be able to find collisions. 00:32:25.590 --> 00:32:28.300 So you can't find two different private keys that 00:32:28.300 --> 00:32:29.700 give you the same public key. 00:32:32.020 --> 00:32:32.770 Sometimes you can. 00:32:32.770 --> 00:32:37.030 [LAUGHS] So I don't want-- 00:32:37.030 --> 00:32:41.740 in this specific case, this is binding. 00:32:41.740 --> 00:32:43.660 There's a bunch of asterisks that's there. 00:32:43.660 --> 00:32:46.730 I probably shouldn't. 00:32:46.730 --> 00:32:47.600 It gets complicated. 00:32:47.600 --> 00:32:51.237 There are some curves where it's not. 00:32:51.237 --> 00:32:52.570 And some systems where it's not. 00:32:52.570 --> 00:32:54.320 And there have been problems in currencies 00:32:54.320 --> 00:32:56.700 where people assume that this is the case-- 00:32:56.700 --> 00:32:57.800 I think in Monero. 00:32:57.800 --> 00:32:58.300 But, yeah. 00:32:58.300 --> 00:33:00.260 AUDIENCE: Can you draw an example of curve? 00:33:00.260 --> 00:33:01.010 TADGE DRYJA: Yeah. 00:33:01.010 --> 00:33:15.470 So they-- the curve for Bitcoin, I think it's y q? 00:33:15.470 --> 00:33:19.630 No, y squared equals x cubed plus or minus? 00:33:19.630 --> 00:33:20.980 Minus 7, I think. 00:33:20.980 --> 00:33:22.470 That's it. 00:33:22.470 --> 00:33:26.050 It looks sort of like this. 00:33:26.050 --> 00:33:29.320 It's symmetric, which that isn't. 00:33:29.320 --> 00:33:32.930 I think I had it in an earlier one. 00:33:32.930 --> 00:33:36.950 And then the x-axis is like this is the origin-ish. 00:33:36.950 --> 00:33:40.310 And then the idea is you have points and you can-- 00:33:40.310 --> 00:33:46.490 the sum is if you have the sum there 00:33:46.490 --> 00:33:49.670 it's going to be here, except it's here. 00:33:49.670 --> 00:33:51.260 So the idea is 3. 00:33:51.260 --> 00:33:56.750 Any line you draw more or less will intersect at 3 points 00:33:56.750 --> 00:33:59.120 unless it intersects at a tangent, 00:33:59.120 --> 00:34:02.870 or if it's straight up, then you say 00:34:02.870 --> 00:34:07.050 it intersects at the point at infinity. 00:34:07.050 --> 00:34:10.520 But any random line you make will probably 00:34:10.520 --> 00:34:14.030 intersect in 3 different points. 00:34:14.030 --> 00:34:17.989 And so then if this is a, b, and c, 00:34:17.989 --> 00:34:20.840 we define a plus b plus c to be 0. 00:34:20.840 --> 00:34:24.199 So then we would define b plus c to be here-- 00:34:24.199 --> 00:34:26.538 negative a. 00:34:26.538 --> 00:34:30.710 And the negation is you flip it over the x-axis. 00:34:30.710 --> 00:34:34.060 So I talked about this a little bit before. 00:34:34.060 --> 00:34:39.219 But the idea is you've still got this nice property where you 00:34:39.219 --> 00:34:41.260 pick a point on here-- g-- 00:34:41.260 --> 00:34:44.860 everyone picks a random point, and it's a generator. 00:34:44.860 --> 00:34:46.570 Because if you keep adding. 00:34:46.570 --> 00:34:49.920 So here's g-- sorry-- and take the tangent-- 00:34:49.920 --> 00:34:52.030 find this is 2g. 00:34:52.030 --> 00:34:53.480 Take the tangent here-- 00:34:53.480 --> 00:34:56.020 maybe it goes here to 3g. 00:34:56.020 --> 00:35:00.100 Take the tangent here-- or no, that would be 4g-- sorry-- 00:35:00.100 --> 00:35:00.920 this would be 8g. 00:35:00.920 --> 00:35:05.310 So you can keep adding the g, and you'll eventually 00:35:05.310 --> 00:35:08.197 cover the entire curve and get back to g. 00:35:08.197 --> 00:35:09.780 So that's why it's sort of a generator 00:35:09.780 --> 00:35:14.420 because it lets you get to every point by just multiplying. 00:35:14.420 --> 00:35:19.410 So the nice property here is if you have some number x times 00:35:19.410 --> 00:35:24.570 g, and some number y times g-- 00:35:24.570 --> 00:35:34.470 you can also do x plus y times g, and that equals xg plus yg. 00:35:34.470 --> 00:35:36.970 So you can add the points. 00:35:36.970 --> 00:35:39.690 And that's the same as adding the scalars 00:35:39.690 --> 00:35:41.810 before you multiply by g. 00:35:41.810 --> 00:35:47.810 And that's what basically we use for everything. 00:35:47.810 --> 00:35:50.490 And then the idea is you can't go back. 00:35:50.490 --> 00:35:53.870 Given a point, let's say we call this big X-- 00:35:53.870 --> 00:35:56.960 given a point-- big X, which is little x times g-- 00:35:56.960 --> 00:35:58.370 you can't figure out what x is. 00:35:58.370 --> 00:36:00.205 So you can't divide by a point. 00:36:00.205 --> 00:36:01.580 You can't say oh, given x, I want 00:36:01.580 --> 00:36:05.570 to do x divided by g, which is little x. 00:36:05.570 --> 00:36:07.520 I can't divide some stuff. 00:36:07.520 --> 00:36:10.210 I can multiply by repeatedly adding. 00:36:10.210 --> 00:36:13.340 But division is not defined. 00:36:13.340 --> 00:36:18.390 So this is binding, but I don't want to-- 00:36:18.390 --> 00:36:20.040 there's asterisks that's there. 00:36:20.040 --> 00:36:23.520 But it's not blinded. 00:36:23.520 --> 00:36:26.940 So same problem is the raw hash-based commitment 00:36:26.940 --> 00:36:31.140 where if I want to commit to the number 5, and 5 times g, 00:36:31.140 --> 00:36:35.760 and that's my point that I'm going to use for my commitment. 00:36:35.760 --> 00:36:38.250 Same problem-- 4-loop will pretty quickly 00:36:38.250 --> 00:36:41.500 show you that was 5. 00:36:41.500 --> 00:36:48.980 How about-- this seems like a good idea. 00:36:48.980 --> 00:36:50.870 I should say it in the less obviously-- 00:36:50.870 --> 00:36:52.018 it's not a good idea way. 00:36:52.018 --> 00:36:54.110 [LAUGHS] 00:36:54.110 --> 00:36:59.508 So why don't we add a blinding factor? 00:36:59.508 --> 00:37:00.800 What would the problem be here? 00:37:03.870 --> 00:37:05.250 I want to commit to 5. 00:37:05.250 --> 00:37:07.770 I'm going to add some random number r 00:37:07.770 --> 00:37:11.310 and then multiply that sum by g, and then 00:37:11.310 --> 00:37:13.800 when I want to reveal that I was committed to 5-- 00:37:13.800 --> 00:37:17.035 I reveal 5 and r. 00:37:17.035 --> 00:37:20.304 AUDIENCE: You don't know which one is [INAUDIBLE]?? 00:37:20.304 --> 00:37:22.600 TADGE DRYJA: No, but I can say, look, the first-- 00:37:22.600 --> 00:37:28.570 well, yeah, the problem is addition is easy to break. 00:37:31.370 --> 00:37:36.180 When I committed to 5 plus r, I revealed 5 and r, 00:37:36.180 --> 00:37:37.330 but it's not binding. 00:37:37.330 --> 00:37:41.140 I can find r prime, which is 5 plus r minus 6. 00:37:41.140 --> 00:37:44.440 And then 6 plus that r prime is going to be 6 plus 5 00:37:44.440 --> 00:37:46.450 plus r minus 6. 00:37:46.450 --> 00:37:49.030 I can compute whatever r prime I want 00:37:49.030 --> 00:37:52.000 and whatever number I want to reveal later. 00:37:52.000 --> 00:37:55.590 So this isn't binding anymore. 00:37:55.590 --> 00:37:57.880 I'm now adding a random thing in, 00:37:57.880 --> 00:37:59.980 and I'm committing to the sum of the thing I want 00:37:59.980 --> 00:38:00.790 and a random thing. 00:38:00.790 --> 00:38:07.520 But it's not binding because that addition, I can play with. 00:38:07.520 --> 00:38:10.850 So how about this? 00:38:10.850 --> 00:38:13.970 I'll hash 5 and concatenate r and then 00:38:13.970 --> 00:38:16.880 multiply that hashed output by g. 00:38:20.400 --> 00:38:23.700 Maybe, but then it's no longer homomorphic-- 00:38:23.700 --> 00:38:25.920 then I can't add. 00:38:25.920 --> 00:38:33.420 So if I have the hash of 5 and r1 times g and then 00:38:33.420 --> 00:38:37.905 the hash of 7 and r 2 times g-- 00:38:37.905 --> 00:38:42.270 I can't add these anymore And then have the 5s 00:38:42.270 --> 00:38:44.777 and 7s add up to 12-- 00:38:44.777 --> 00:38:45.360 it won't work. 00:38:45.360 --> 00:38:46.987 Because now it's a hash. 00:38:46.987 --> 00:38:48.570 And I've just got these hashes adding, 00:38:48.570 --> 00:38:50.590 and you don't really get any meaning there. 00:38:50.590 --> 00:38:52.445 So that doesn't work either. 00:38:52.445 --> 00:38:53.070 So we're stuck. 00:38:56.220 --> 00:38:58.720 Then the way you do it is totally non-obvious. 00:38:58.720 --> 00:39:03.570 And introducing g's fraternal twin-- h. 00:39:03.570 --> 00:39:07.342 [LAUGHS] You make another point on the curve, 00:39:07.342 --> 00:39:09.300 and you call it h, which is the letter after g. 00:39:12.380 --> 00:39:15.050 It's another generator point distinct from g. 00:39:15.050 --> 00:39:17.720 So you pick one-- 00:39:17.720 --> 00:39:20.390 here's h. 00:39:20.390 --> 00:39:23.270 You also need to make sure that nobody knows 00:39:23.270 --> 00:39:27.150 n such that n times g equals h. 00:39:27.150 --> 00:39:29.223 That n might exist, but you want to be sure 00:39:29.223 --> 00:39:30.890 that no one knows what it is because you 00:39:30.890 --> 00:39:38.010 know how to move between g and h, then that'll break this. 00:39:38.010 --> 00:39:41.760 But if you take two random points, g was randomly chosen, 00:39:41.760 --> 00:39:45.360 and you chose a random h, this shouldn't be possible. 00:39:45.360 --> 00:39:47.370 That would be breaking the discreet log problem. 00:39:47.370 --> 00:39:52.227 So I shouldn't be able to compute h divided by g-- 00:39:52.227 --> 00:39:53.810 you shouldn't be able to compute that. 00:39:56.720 --> 00:40:00.860 And so I think in a lot of cases, they'll define h as-- 00:40:00.860 --> 00:40:04.730 take the hash of g's x-coordinate and then assign 00:40:04.730 --> 00:40:06.877 that to the x-coordinate for h-- 00:40:06.877 --> 00:40:07.710 something like that. 00:40:07.710 --> 00:40:10.065 So it looks pretty random-- 00:40:10.065 --> 00:40:11.600 should be able to find it. 00:40:11.600 --> 00:40:15.380 So we've got another arbitrary point on the curve 00:40:15.380 --> 00:40:19.670 that we're going to start using for multiplying things. 00:40:19.670 --> 00:40:21.800 And so this is basically a Pedersen commitment, 00:40:21.800 --> 00:40:24.990 which sounds involved and it gets involved, 00:40:24.990 --> 00:40:27.750 but really it's not. 00:40:27.750 --> 00:40:29.130 At its core, it's not too bad. 00:40:29.130 --> 00:40:31.230 It's saying we're going to have a blinding 00:40:31.230 --> 00:40:34.290 factor in the actual value we're committing to. 00:40:34.290 --> 00:40:36.810 And so now I'm multiplying the blinding factor 00:40:36.810 --> 00:40:41.040 by g and the actual value by h. 00:40:41.040 --> 00:40:43.500 And I'm just adding those two up. 00:40:43.500 --> 00:40:46.890 So you know how we can do that? 00:40:46.890 --> 00:40:51.210 If my actual value is 5, I take 5h by taking the tangent-- 00:40:51.210 --> 00:40:54.720 getting 2h-- take the tangent again-- getting 4h, 00:40:54.720 --> 00:40:58.380 and then adding 4h and h by drawing the line between them-- 00:40:58.380 --> 00:40:59.970 I'll get 5h. 00:40:59.970 --> 00:41:01.470 And then I'll also get r. r's going 00:41:01.470 --> 00:41:04.230 to be some giant random thing. 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 00:41:07.440 --> 00:41:13.680 number, and that will obscure what h was-- 00:41:13.680 --> 00:41:17.970 sorry. what v was because I added them together. 00:41:17.970 --> 00:41:21.880 So this is binding unless I know the ratio. 00:41:21.880 --> 00:41:24.760 Unless I know h over g, or g over h-- whatever-- 00:41:24.760 --> 00:41:27.870 same thing-- 00:41:27.870 --> 00:41:30.130 I can't come up with another r and v 00:41:30.130 --> 00:41:32.200 pair that gets me back to x. 00:41:34.950 --> 00:41:37.112 So I can try. 00:41:37.112 --> 00:41:39.390 There is one. 00:41:39.390 --> 00:41:42.000 There's probably bazillions of-- 00:41:42.000 --> 00:41:43.860 if I could find a different r, I could then 00:41:43.860 --> 00:41:47.730 reveal that v was 8 instead of 7. 00:41:47.730 --> 00:41:51.060 But I can't find that r, because I need to know some way 00:41:51.060 --> 00:41:52.590 to get between g and h-- 00:41:52.590 --> 00:41:55.490 some factor n where n times g equals h. 00:41:55.490 --> 00:41:58.720 If I don't know that, I can't do this. 00:41:58.720 --> 00:42:00.360 It is binding. 00:42:00.360 --> 00:42:01.890 It's also hiding. 00:42:01.890 --> 00:42:05.010 So you might successfully guess-- 00:42:05.010 --> 00:42:06.870 I might commit vehicles 5-- 00:42:06.870 --> 00:42:10.870 do some random number r times g plus 5h, 00:42:10.870 --> 00:42:12.670 and you might guess correctly. 00:42:12.670 --> 00:42:16.450 But this should have been g-- oops-- sorry. 00:42:16.450 --> 00:42:17.700 This is g. 00:42:17.700 --> 00:42:21.210 But if I have some really long, random number times g, 00:42:21.210 --> 00:42:25.590 it's also an x, and you're not going to be able to guess that. 00:42:25.590 --> 00:42:29.020 So this is also hiding. 00:42:29.020 --> 00:42:31.640 And it's homomorphic. 00:42:31.640 --> 00:42:36.980 So x is r1g plus v1h. 00:42:36.980 --> 00:42:41.300 y is r2g plus v2h. 00:42:41.300 --> 00:42:47.060 And what if I want to prove that z is value 1 plus value 2 00:42:47.060 --> 00:42:50.970 without revealing them individually? 00:42:50.970 --> 00:42:52.680 Can you see how I could do that? 00:42:58.860 --> 00:43:00.660 I can reveal both r's individually. 00:43:00.660 --> 00:43:03.480 Well, no, sorry-- I cannot reveal both r's individually 00:43:03.480 --> 00:43:08.090 because then you might be able to figure out the values. 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. 00:43:11.730 --> 00:43:15.480 So I'm going to define a point z, which 00:43:15.480 --> 00:43:18.150 is point x plus point y. 00:43:18.150 --> 00:43:20.640 And that's just going to be the sum of the r values-- 00:43:20.640 --> 00:43:22.830 the sum of those random values times 00:43:22.830 --> 00:43:25.620 g plus the sum of the actual values 00:43:25.620 --> 00:43:28.890 I've committed to times h. 00:43:28.890 --> 00:43:30.760 And then I reveal the sums. 00:43:30.760 --> 00:43:31.910 I reveal this-- 00:43:31.910 --> 00:43:33.150 I reveal that. 00:43:33.150 --> 00:43:37.590 And then the verifier can do the math themselves. 00:43:40.650 --> 00:43:41.820 It's a little hard. 00:43:41.820 --> 00:43:44.670 I'm revealing r and v, which is equal to this. 00:43:44.670 --> 00:43:47.280 But I'm not revealing these separately. 00:43:47.280 --> 00:43:49.500 I only reveal the sums. 00:43:49.500 --> 00:43:51.330 And then the verifier can check-- 00:43:51.330 --> 00:43:54.480 is this r they gave times g plus this v they gave times 00:43:54.480 --> 00:43:59.780 h equal to these two points added together? 00:43:59.780 --> 00:44:04.700 And if it is, they've proven the sum. 00:44:04.700 --> 00:44:11.170 So, for example, it's binding, hiding, and homomorphic. 00:44:11.170 --> 00:44:14.500 So this would allow us to make proofs. 00:44:23.310 --> 00:44:27.240 Binding, hiding, homomorphic-- you reveal the sum of the r's. 00:44:27.240 --> 00:44:30.852 You reveal the sum of the v's-- 00:44:30.852 --> 00:44:32.480 it works. 00:44:32.480 --> 00:44:40.810 So basically now instead of coin amounts, which are 8-byte-- 00:44:40.810 --> 00:44:43.010 they're in 64s-- 00:44:43.010 --> 00:44:45.050 I just provide elliptic curve points, 00:44:45.050 --> 00:44:48.530 which are 33 bytes, so it's a bit bigger-- 00:44:48.530 --> 00:44:49.580 not a huge deal. 00:44:49.580 --> 00:44:52.010 I can put another 20-something bytes 00:44:52.010 --> 00:44:54.930 in my outputs-- no big deal. 00:44:54.930 --> 00:45:01.590 And then I provide a proof by revealing these sums each time. 00:45:01.590 --> 00:45:05.200 So I prove that w plus x equals y plus z. 00:45:05.200 --> 00:45:09.600 And everyone can see this little w amount of coins-- 00:45:09.600 --> 00:45:10.830 there's actually y coins. 00:45:10.830 --> 00:45:12.030 There's actually x coins. 00:45:12.030 --> 00:45:13.560 There's actually z coins. 00:45:13.560 --> 00:45:20.000 And there's a blinding factor that all the participants 00:45:20.000 --> 00:45:22.190 have to keep track of. 00:45:22.190 --> 00:45:23.800 So the receiver's views-- 00:45:23.800 --> 00:45:26.410 they learn their own v and r. 00:45:29.302 --> 00:45:30.760 When someone sends, they would have 00:45:30.760 --> 00:45:34.800 to tell the receiver, hey, here's r4. 00:45:34.800 --> 00:45:36.840 The sender makes up r4. 00:45:36.840 --> 00:45:39.960 And they can just compute-- let's make a random r3. 00:45:39.960 --> 00:45:47.370 And then compute r4 such that r4 plus r3 equals r1 plus r2. 00:45:47.370 --> 00:45:50.860 They need to make sure that the randomnesses add up, 00:45:50.860 --> 00:45:53.430 which is easy because they're regular scalars, 00:45:53.430 --> 00:45:56.980 and the sender has full control over r3 and r4. 00:45:56.980 --> 00:45:59.760 So, basically, make random ones until you get to the last one. 00:45:59.760 --> 00:46:01.890 And then make the last one such that they all 00:46:01.890 --> 00:46:03.015 add up to the right number. 00:46:05.250 --> 00:46:11.970 And then the sender can say, here's your r4 and here's 2. 00:46:11.970 --> 00:46:13.380 You're getting 2 coins. 00:46:13.380 --> 00:46:16.050 And the receiver gets those two numbers and says, 00:46:16.050 --> 00:46:19.100 I can see that this transaction commits to z-- 00:46:19.100 --> 00:46:20.310 a point. 00:46:20.310 --> 00:46:25.980 And you gave me an r and a v that when I do the operation-- 00:46:25.980 --> 00:46:26.730 I get z. 00:46:26.730 --> 00:46:28.890 So I know that successfully, you've 00:46:28.890 --> 00:46:30.990 revealed that these are two coins. 00:46:30.990 --> 00:46:33.180 And I can use these values later when 00:46:33.180 --> 00:46:34.380 I want to send my own coins. 00:46:38.400 --> 00:46:42.490 So this works, but there's more problems. 00:46:42.490 --> 00:46:44.890 [LAUGHS] Any idea what the next big problem is? 00:46:44.890 --> 00:46:45.390 Yeah. 00:46:45.390 --> 00:46:47.324 AUDIENCE: If there are only two outputs, 00:46:47.324 --> 00:46:50.770 and then c's r4 and d4-- 00:46:50.770 --> 00:46:53.770 they could be able to [INAUDIBLE] r3 and d3, right? 00:46:53.770 --> 00:46:55.300 TADGE DRYJA: Yeah. 00:46:55.300 --> 00:46:56.620 But that's OK. 00:46:56.620 --> 00:46:58.840 I mean, there's no way around that. 00:46:58.840 --> 00:47:00.670 If there's only one input-- 00:47:00.670 --> 00:47:08.620 or wait-- if there's only two outputs, 00:47:08.620 --> 00:47:12.830 so if the receiver learns these, they 00:47:12.830 --> 00:47:14.540 will be able to distinguish-- if you 00:47:14.540 --> 00:47:18.260 know the total amount of inputs, and there's only one other. 00:47:18.260 --> 00:47:21.438 You can just subtract and figure it out. 00:47:21.438 --> 00:47:22.730 So there's all sorts of things. 00:47:22.730 --> 00:47:25.610 If there's only one output, that person 00:47:25.610 --> 00:47:27.170 knows it's the sum of all the inputs. 00:47:27.170 --> 00:47:29.270 AUDIENCE: You don't know-- in this case, 00:47:29.270 --> 00:47:31.346 you don't know the total input, right? 00:47:31.346 --> 00:47:32.210 TADGE DRYJA: Right. 00:47:32.210 --> 00:47:36.830 In this case, they don't have to reveal to you the v's-- they 00:47:36.830 --> 00:47:43.330 just have to reveal that 2 plus y equals w plus x. 00:47:43.330 --> 00:47:46.330 So you don't have to learn their input amounts. 00:47:49.340 --> 00:47:54.700 If there's only one output, then you learn if this is 2, 00:47:54.700 --> 00:47:56.080 these must have added up to 2. 00:47:56.080 --> 00:47:59.585 But I don't learn exactly which. 00:47:59.585 --> 00:48:01.403 So this is useful. 00:48:01.403 --> 00:48:02.570 There's still a big problem. 00:48:08.322 --> 00:48:12.080 r1 plus r2 is r3 plus r4-- you can prove w plus x equals y 00:48:12.080 --> 00:48:12.840 plus c-- 00:48:12.840 --> 00:48:13.900 it works. 00:48:13.900 --> 00:48:14.400 It's great. 00:48:14.400 --> 00:48:17.475 AUDIENCE: Do nodes only mean the bigger transaction-- 00:48:17.475 --> 00:48:20.250 to know that the inputs you put [INAUDIBLE]?? 00:48:20.250 --> 00:48:21.900 TADGE DRYJA: Yep. 00:48:21.900 --> 00:48:26.637 nodes can just compute these numbers, and they're good. 00:48:26.637 --> 00:48:27.970 So one thing you could do here-- 00:48:30.410 --> 00:48:30.910 OK, wait. 00:48:30.910 --> 00:48:33.580 So there's one thing that you can do to break it. 00:48:33.580 --> 00:48:35.030 But it's not a big deal. 00:48:35.030 --> 00:48:36.340 And then there's another thing-- you need a break that's 00:48:36.340 --> 00:48:37.090 a really big deal. 00:48:37.090 --> 00:48:37.590 Yeah. 00:48:37.590 --> 00:48:39.190 AUDIENCE: Since you're proving sums, 00:48:39.190 --> 00:48:41.857 is it that you can have a higher likelihood of proving something 00:48:41.857 --> 00:48:42.580 that doesn't-- 00:48:42.580 --> 00:48:46.570 like that wasn't actually true? 00:48:46.570 --> 00:48:50.620 TADGE DRYJA: Yeah, but how exactly? 00:48:50.620 --> 00:48:55.800 So one thing you could do is-- 00:48:55.800 --> 00:48:56.508 I think, I said-- 00:48:56.508 --> 00:48:58.717 so, basically, you can verify it and put in outputs-- 00:48:58.717 --> 00:49:00.870 add up all the points-- make sure they're equal. 00:49:00.870 --> 00:49:03.360 You reveal r and v to the person receiving. 00:49:03.360 --> 00:49:04.740 And you don't want to forget r. 00:49:04.740 --> 00:49:06.280 r is now a private key. 00:49:06.280 --> 00:49:07.610 If you forget r-- 00:49:07.610 --> 00:49:08.380 you're stuck. 00:49:08.380 --> 00:49:10.620 You can't prove anything anymore. 00:49:10.620 --> 00:49:12.840 You can make invalid outputs, which 00:49:12.840 --> 00:49:15.600 are just points with no known r and v. 00:49:15.600 --> 00:49:17.400 But nobody should accept those. 00:49:17.400 --> 00:49:20.270 So you can do this where-- 00:49:20.270 --> 00:49:21.230 I have no idea what-- 00:49:21.230 --> 00:49:22.397 there is no commitment here. 00:49:22.397 --> 00:49:24.020 Maybe these have valid commitments, 00:49:24.020 --> 00:49:27.720 but this is a point, which is w plus x minus y. 00:49:27.720 --> 00:49:33.590 And there's no known r values or v values for these things. 00:49:33.590 --> 00:49:37.040 And from the network's point of view, this will still be valid. 00:49:37.040 --> 00:49:40.880 The networks are saying, well, w plus x equals y plus z-- 00:49:40.880 --> 00:49:42.480 we're good. 00:49:42.480 --> 00:49:45.140 But then anyone accepting that transaction-- 00:49:45.140 --> 00:49:48.060 you're not going to be able to give them an r value. 00:49:48.060 --> 00:49:50.600 And so they're not going to say this is actual money. 00:49:50.600 --> 00:49:54.060 So this is possible, but it's not a huge problem 00:49:54.060 --> 00:49:57.845 because you can destroy your own money. 00:49:57.845 --> 00:49:59.970 You can already do that in a million different ways 00:49:59.970 --> 00:50:01.170 in Bitcoin. 00:50:01.170 --> 00:50:04.590 But if you send to it to an output amount that 00:50:04.590 --> 00:50:07.260 doesn't have an actual r and v value-- that doesn't have 00:50:07.260 --> 00:50:09.180 a valid Pedersen commitment-- those coins 00:50:09.180 --> 00:50:11.210 can essentially be destroyed because no one's 00:50:11.210 --> 00:50:16.720 going to be able to figure out r's and stuff for here. 00:50:16.720 --> 00:50:18.280 So that's one issue-- 00:50:18.280 --> 00:50:19.280 not a big issue. 00:50:19.280 --> 00:50:20.950 Just don't do that. 00:50:20.950 --> 00:50:22.297 Don't ruin your own money. 00:50:22.297 --> 00:50:24.130 Make sure you always have valid commitments. 00:50:24.130 --> 00:50:26.500 And when you're accepting payments always 00:50:26.500 --> 00:50:32.440 make sure that you're given the values and the random blinding 00:50:32.440 --> 00:50:33.530 factors. 00:50:33.530 --> 00:50:38.190 So that's one little risk but not the big problem. 00:50:38.190 --> 00:50:39.940 Anyone have an idea about the big problem? 00:50:39.940 --> 00:50:42.550 So as a hint-- 00:50:42.550 --> 00:50:45.010 all of these things, and I haven't written it because it 00:50:45.010 --> 00:50:49.620 gets really redundant-- all of these things are like mod p, 00:50:49.620 --> 00:50:57.990 which is some giant prime number that's 2 to 56 minus 17, 00:50:57.990 --> 00:51:00.090 or it's not-- 00:51:00.090 --> 00:51:06.593 in the curve, ed25509 it's 2 to the 255 minus 19. 00:51:06.593 --> 00:51:08.010 So that's an easy one to remember. 00:51:08.010 --> 00:51:10.880 So that's why they call it curve 22519. 00:51:10.880 --> 00:51:16.130 In bitcoin, it's 2 to the 256 minus some numbers that 00:51:16.130 --> 00:51:18.860 are not too huge. 00:51:18.860 --> 00:51:22.680 So since all of these things are modulo-- 00:51:22.680 --> 00:51:24.650 some big prime number-- 00:51:24.650 --> 00:51:28.242 what's a potential problem here? 00:51:28.242 --> 00:51:31.230 It's a big problem or in some ways 00:51:31.230 --> 00:51:34.748 the opposite of a big problem. 00:51:34.748 --> 00:51:35.770 Not a small problem. 00:51:35.770 --> 00:51:39.925 [LAUGHS] The opposite of a big problem but not small-- 00:51:42.700 --> 00:51:43.890 big negative problem. 00:51:43.890 --> 00:51:47.410 [LAUGHS] 00:51:47.410 --> 00:51:51.190 You can basically commit to negative values. 00:51:51.190 --> 00:51:59.460 So I send negative 99 coins here, positive 108 coins here-- 00:51:59.460 --> 00:52:01.620 the numbers all work out. 00:52:01.620 --> 00:52:03.030 So you don't have negative. 00:52:03.030 --> 00:52:06.980 Usually, if you're doing mod-some integer, 00:52:06.980 --> 00:52:08.670 you don't think of it as negative, 00:52:08.670 --> 00:52:11.250 but you can think of being almost 00:52:11.250 --> 00:52:14.280 right at the top of that modulo range 00:52:14.280 --> 00:52:16.620 as being equivalent to being a negative 1. 00:52:16.620 --> 00:52:21.060 So if you say, I'm going to have p minus 1-- 00:52:21.060 --> 00:52:24.120 that's some huge number that's within the very 00:52:24.120 --> 00:52:25.950 allowable range. 00:52:25.950 --> 00:52:28.830 But it also will let you treat it 00:52:28.830 --> 00:52:30.990 as a negative 1 for operations like addition 00:52:30.990 --> 00:52:33.940 and multiplication. 00:52:33.940 --> 00:52:36.090 So this would work, and you can calculate 00:52:36.090 --> 00:52:40.740 what negative 99 is-- that's just going to be p minus 99, 00:52:40.740 --> 00:52:41.550 or minus 100. 00:52:41.550 --> 00:52:44.957 I always am off by 1 when I do these things. 00:52:44.957 --> 00:52:47.280 [LAUGHS] Wait, is it 100? 00:52:47.280 --> 00:52:50.130 Anyway, so you can calculate-- 00:52:50.130 --> 00:52:52.020 it's not really minus 99-- 00:52:52.020 --> 00:52:55.260 it's some big number that's going to be 32-bytes 00:52:55.260 --> 00:52:56.720 long-- that's modulo. 00:52:59.350 --> 00:53:03.460 Modulo p doesn't change, but it's equivalent to minus 99. 00:53:03.460 --> 00:53:06.850 So that if I do add these to this huge number 00:53:06.850 --> 00:53:11.020 plus this other small number, it loops over that modulo 00:53:11.020 --> 00:53:13.480 and then gets back to-- 00:53:13.480 --> 00:53:15.365 what, 9. 00:53:15.365 --> 00:53:17.490 So this plus this is going to be 9 even though this 00:53:17.490 --> 00:53:19.920 is some really long number. 00:53:19.920 --> 00:53:23.910 This plus-- this is going to be nine, and then it all adds up. 00:53:23.910 --> 00:53:27.120 And then I've got this either negative or implausibly 00:53:27.120 --> 00:53:32.910 large value that I've committed to, but I can just ignore that. 00:53:32.910 --> 00:53:35.810 I can get rid of that. 00:53:35.810 --> 00:53:38.120 That negative output will be hidden. 00:53:38.120 --> 00:53:41.610 No one will see that I've got this negative 99 here-- 00:53:41.610 --> 00:53:44.810 then I can toss it and end up with a whole bunch 00:53:44.810 --> 00:53:48.950 of negative values that are anti-coins 00:53:48.950 --> 00:53:51.800 and a whole bunch of more new coins. 00:53:51.800 --> 00:53:55.400 And later on, I can prove I've got valid proofs-- 00:53:55.400 --> 00:54:01.930 all these w plus x equals y plus z proofs worked the whole time. 00:54:01.930 --> 00:54:04.960 Shoot-- [LAUGHS] so we're stuck. 00:54:08.360 --> 00:54:13.240 We need more than a proof that the sums are equal-- 00:54:13.240 --> 00:54:14.550 was working really well. 00:54:14.550 --> 00:54:16.420 But just a proof that the sums are equal 00:54:16.420 --> 00:54:18.990 is not enough because we're modulo-- 00:54:18.990 --> 00:54:20.680 this big prime number. 00:54:20.680 --> 00:54:23.302 And so you can make these negations. 00:54:23.302 --> 00:54:25.260 We also need a proof that they're non-negative, 00:54:25.260 --> 00:54:30.090 and not just not negative, because that negative 99 is 00:54:30.090 --> 00:54:34.380 essentially p minus 99, which is some huge-- 00:54:34.380 --> 00:54:37.467 it's 2 to the 256 minus 99-ish. 00:54:37.467 --> 00:54:39.300 So it's not just that they're non-negative-- 00:54:39.300 --> 00:54:41.760 we have to prove that they're reasonably sized-- 00:54:41.760 --> 00:54:43.050 that they're fairly small. 00:54:43.050 --> 00:54:45.510 So if you could prove this number is non-negative, 00:54:45.510 --> 00:54:49.790 and it's less than 2 to the 64-- 00:54:49.790 --> 00:54:51.590 that would be cool. 00:54:51.590 --> 00:54:53.805 How can we prove something about the number itself 00:54:53.805 --> 00:54:54.680 without revealing it? 00:54:54.680 --> 00:54:56.630 So now this is an even trickier problem, 00:54:56.630 --> 00:54:59.840 because, before, we wanted to prove a sum. 00:54:59.840 --> 00:55:04.210 We wanted to prove that z equals x plus y. 00:55:04.210 --> 00:55:05.960 I don't want to tell you what x plus y is, 00:55:05.960 --> 00:55:08.120 but I'll tell you what z is. 00:55:08.120 --> 00:55:11.310 That was proving a relation between these numbers. 00:55:11.310 --> 00:55:14.150 This is just proving something about that number 00:55:14.150 --> 00:55:15.920 itself individually. 00:55:15.920 --> 00:55:18.850 We have to prove individual numbers-- 00:55:18.850 --> 00:55:19.820 ranges. 00:55:19.820 --> 00:55:22.780 So we have to say, this to 2h-- 00:55:22.780 --> 00:55:25.610 there's a 2h in there, and I can't show you it, because I'm 00:55:25.610 --> 00:55:26.720 just committing a w. 00:55:26.720 --> 00:55:29.630 But I want to somehow show you that the v here-- 00:55:29.630 --> 00:55:31.505 which should happen to be 2, although I'm not 00:55:31.505 --> 00:55:32.480 going to tell you-- 00:55:32.480 --> 00:55:36.240 the v there is within a small range-- 00:55:36.240 --> 00:55:38.340 without telling you what it is-- 00:55:38.340 --> 00:55:42.216 without revealing it-- tricky. 00:55:45.880 --> 00:55:51.640 So what you can try to do is sign with the points. 00:55:51.640 --> 00:55:55.670 Somehow, this is what'll get us there. 00:55:55.670 --> 00:55:58.640 The idea of we've got these Pedersen commitments-- 00:55:58.640 --> 00:56:00.480 we've got these points on a curve-- 00:56:00.480 --> 00:56:01.760 those are public keys. 00:56:01.760 --> 00:56:04.200 That's how we used to usually think of them. 00:56:04.200 --> 00:56:04.700 Can we sign? 00:56:07.570 --> 00:56:09.070 We know the private keys. 00:56:09.070 --> 00:56:10.060 We know r1. 00:56:10.060 --> 00:56:11.440 We know 2. 00:56:11.440 --> 00:56:14.560 Can we make signatures somehow and somehow use 00:56:14.560 --> 00:56:21.140 that to reveal some information about h but not too much? 00:56:21.140 --> 00:56:23.422 So the signature equation-- 00:56:26.170 --> 00:56:28.170 I didn't really review as much, but we've talked 00:56:28.170 --> 00:56:29.310 about this a couple times. 00:56:29.310 --> 00:56:32.280 Come up with a random value k-- 00:56:32.280 --> 00:56:34.980 take the hash of k times g and the message 00:56:34.980 --> 00:56:37.290 to be signed times your private key-- 00:56:37.290 --> 00:56:40.230 that's your signature s. 00:56:40.230 --> 00:56:42.180 The problem is x. 00:56:42.180 --> 00:56:44.610 Your value that you've got committed to here-- 00:56:44.610 --> 00:56:48.610 it's r2g plus 7h. 00:56:48.610 --> 00:56:50.120 What's your private key here? 00:56:50.120 --> 00:56:51.510 Well, it's our 2 plus 7. 00:56:51.510 --> 00:56:54.690 But, no, because you know the private scaler's here. 00:56:54.690 --> 00:56:57.810 But there's 2 points involved in this key. 00:56:57.810 --> 00:56:59.370 So you can't make a signature. 00:56:59.370 --> 00:57:00.960 Generally, signatures are with respect 00:57:00.960 --> 00:57:02.670 to a single generator point. 00:57:02.670 --> 00:57:06.420 The way to verify this is to multiply both sides by g. 00:57:06.420 --> 00:57:09.360 s times g should be k times g minus the hash of k times 00:57:09.360 --> 00:57:12.900 g, message times 8 times g which is a public key-- that works. 00:57:12.900 --> 00:57:15.270 But now you've got h in here. 00:57:15.270 --> 00:57:19.930 So we're stuck. 00:57:19.930 --> 00:57:22.420 We could try to define another signature thing with both h 00:57:22.420 --> 00:57:23.890 and g, but that doesn't work. 00:57:23.890 --> 00:57:29.790 But what we can show, which is kind of interesting, well, 00:57:29.790 --> 00:57:32.760 what if v is 0? 00:57:32.760 --> 00:57:41.780 Then x is r2 times g plus 0h, which is just r2 times g. 00:57:41.780 --> 00:57:43.100 This is nothing. 00:57:43.100 --> 00:57:46.440 There is no h here. 00:57:46.440 --> 00:57:49.000 And that means my private key's going to be r2. 00:57:49.000 --> 00:57:51.320 Well, now I can sign-- 00:57:51.320 --> 00:57:54.100 now I can re-sign with respect to g with this point 00:57:54.100 --> 00:57:57.100 x that I've committed to because the value is zero. 00:57:59.850 --> 00:58:03.405 The value-- the thing that I'm multiplying by h is 0. 00:58:06.390 --> 00:58:08.220 So it'll work for a signature system. 00:58:08.220 --> 00:58:09.900 The same regular old signature equation 00:58:09.900 --> 00:58:16.080 that we use, I can sign a message with key "big X." 00:58:16.080 --> 00:58:19.300 And so this is a proof of a 0 value-- 00:58:19.300 --> 00:58:21.700 I'll sign with my own key. 00:58:21.700 --> 00:58:28.660 So if x is some random blinding factor times g plus 0 times h-- 00:58:28.660 --> 00:58:31.420 where v, the value you're committing to is 0-- 00:58:31.420 --> 00:58:34.750 well, that means that the signature is just-- 00:58:34.750 --> 00:58:36.730 so, the question is, what message do you sign? 00:58:36.730 --> 00:58:39.280 Well, maybe sign the message which is the pubkey itself. 00:58:39.280 --> 00:58:42.310 You don't need to sign a message but throw that in there. 00:58:45.000 --> 00:58:47.460 And then this will work. 00:58:47.460 --> 00:58:51.830 And someone can say, hey, here's a signature from key x. 00:58:51.830 --> 00:58:53.603 And the signature is arbitrary. 00:58:53.603 --> 00:58:55.520 It can be a signature of any message you want. 00:58:55.520 --> 00:58:58.040 But the fact that they are able to produce a signature 00:58:58.040 --> 00:59:05.910 reveals to you that v is 0. 00:59:05.910 --> 00:59:07.050 So that's cool. 00:59:07.050 --> 00:59:09.030 It's not that cool, right? 00:59:09.030 --> 00:59:11.040 Because, well, I just revealed my value, 00:59:11.040 --> 00:59:12.420 and it revealed to be 0. 00:59:12.420 --> 00:59:15.000 But I did it without revealing r. 00:59:15.000 --> 00:59:16.620 So that is cool, right? 00:59:16.620 --> 00:59:20.578 I could do it by saying, hey, here's my r and v values-- 00:59:20.578 --> 00:59:22.620 multiply them and add them up to see that it gets 00:59:22.620 --> 00:59:23.790 to the point I committed to. 00:59:23.790 --> 00:59:26.850 But I can now prove that-- 00:59:26.850 --> 00:59:30.870 I can prove something about v without revealing anything 00:59:30.870 --> 00:59:32.060 about r. 00:59:32.060 --> 00:59:34.950 Before-- we were saying, the way you reveal these commitments is 00:59:34.950 --> 00:59:36.750 you reveal the blinding factor, and you 00:59:36.750 --> 00:59:37.950 reveal the value itself. 00:59:37.950 --> 00:59:40.710 Well, now I can keep the blinding factor secret 00:59:40.710 --> 00:59:44.160 and reveal a little bit of information about v. 00:59:44.160 --> 00:59:48.337 This works, and you can't sign if h is non-zero. 00:59:48.337 --> 00:59:49.670 You're not going to be able to-- 00:59:49.670 --> 00:59:52.830 you're not going to be able to calculate any valid signature 00:59:52.830 --> 00:59:54.610 unless v is-- 00:59:54.610 --> 00:59:55.110 ah. 00:59:55.110 --> 00:59:55.830 V is non-zero. 00:59:55.830 --> 00:59:56.330 Sorry. 00:59:59.470 --> 01:00:04.710 So you can also do this with a proof of v equals 1. 01:00:04.710 --> 01:00:05.790 Again, sign your own key. 01:00:05.790 --> 01:00:10.350 So you define x prime to be just x minus h. 01:00:10.350 --> 01:00:15.870 And then you can say, well, look, 01:00:15.870 --> 01:00:17.840 I'm going to prove to you that v is 1, 01:00:17.840 --> 01:00:21.090 and the way I do that is take the point I've committed to x, 01:00:21.090 --> 01:00:25.030 subtract h from it, and I'll 01:00:25.030 --> 01:00:28.150 provide a signature on that new point. 01:00:28.150 --> 01:00:33.490 Well, this should be v. I can't do that unless v is 1. 01:00:33.490 --> 01:00:36.130 So if I have this, and then I subtract h, 01:00:36.130 --> 01:00:38.080 then I get back to r times g. 01:00:38.080 --> 01:00:41.780 I can now provide a signature just using r-- 01:00:41.780 --> 01:00:43.870 it'll work. 01:00:43.870 --> 01:00:47.600 So what does this get us? 01:00:47.600 --> 01:00:51.070 We can prove that v is 0, or we can prove that v is 1, 01:00:51.070 --> 01:00:53.150 or, really, we can prove that v is anything. 01:00:53.150 --> 01:00:58.940 Just subtract a whole bunch of h's and subtract 7,000 h 01:00:58.940 --> 01:01:00.750 and now provide a signature. 01:01:00.750 --> 01:01:03.492 And that proves that v was 7,000. 01:01:03.492 --> 01:01:06.790 But wait, we just revealed v, so what's the point? 01:01:06.790 --> 01:01:08.260 Did that really get us anywhere? 01:01:08.260 --> 01:01:13.570 If we can make a signature that reveals the value 01:01:13.570 --> 01:01:18.030 we've committed to with hiding the rest of the stuff-- 01:01:18.030 --> 01:01:19.580 is that useful? 01:01:19.580 --> 01:01:24.360 If it's kind of cool, but what can we do with this? 01:01:24.360 --> 01:01:24.880 Any ideas? 01:01:27.500 --> 01:01:33.680 So there's another part that I didn't have time to introduce, 01:01:33.680 --> 01:01:36.150 but maybe will at some point, and you can read about it. 01:01:36.150 --> 01:01:37.460 It's really cool. 01:01:37.460 --> 01:01:40.840 Ring signatures-- a ring signature 01:01:40.840 --> 01:01:43.490 is similar to a normal signature. 01:01:43.490 --> 01:01:45.020 You've got key pairs. 01:01:45.020 --> 01:01:48.410 You've got sign, verify, but there's 01:01:48.410 --> 01:01:52.070 a set of public keys during the signing and verification 01:01:52.070 --> 01:01:53.420 process. 01:01:53.420 --> 01:01:55.580 So the basic idea is, I sign a message 01:01:55.580 --> 01:01:59.330 with one of the public keys, but I don't tell you which one. 01:01:59.330 --> 01:02:02.280 And you verify that, yep, there was a signature here. 01:02:02.280 --> 01:02:03.750 I'm not quite sure who signed it. 01:02:03.750 --> 01:02:05.708 There's possibly three or four different people 01:02:05.708 --> 01:02:07.440 who may have signed it. 01:02:07.440 --> 01:02:10.290 But I know one of them signed it but not which. 01:02:10.290 --> 01:02:13.650 So, basically, it's the key-generation step-- 01:02:13.650 --> 01:02:14.820 same as before. 01:02:14.820 --> 01:02:16.320 You have some keygen-- 01:02:16.320 --> 01:02:18.788 takes in some randomness, and it spits out a private key 01:02:18.788 --> 01:02:19.830 and a public key for you. 01:02:19.830 --> 01:02:22.290 And you can use those later. 01:02:22.290 --> 01:02:23.910 Sign, on the other hand-- 01:02:23.910 --> 01:02:26.220 sign function used to have the message 01:02:26.220 --> 01:02:29.970 to sign in your private key, and it would output a signature. 01:02:29.970 --> 01:02:32.760 In ring signatures, you sign with the message 01:02:32.760 --> 01:02:33.900 you want to sign-- 01:02:33.900 --> 01:02:36.930 your private key and then pick a list 01:02:36.930 --> 01:02:40.680 of other people's public keys. 01:02:40.680 --> 01:02:43.110 And this list can be just a single one. 01:02:43.110 --> 01:02:45.570 It can be 1,000. 01:02:45.570 --> 01:02:48.000 You pick a bunch of other people's public keys, 01:02:48.000 --> 01:02:49.380 and you generate a signature. 01:02:49.380 --> 01:02:53.480 And then verify, you use the signature to-- 01:02:53.480 --> 01:02:54.740 take the signature in-- 01:02:54.740 --> 01:02:59.040 the message that's been signed, and that list of pubkeys. 01:02:59.040 --> 01:03:01.670 And it outputs a Boolean of, yep, that signature worked, 01:03:01.670 --> 01:03:05.030 or, no, it didn't but it doesn't tell you which 01:03:05.030 --> 01:03:07.540 of the public keys is signed. 01:03:07.540 --> 01:03:10.620 So this is a really cool idea. 01:03:10.620 --> 01:03:12.090 I think the initial paper was How 01:03:12.090 --> 01:03:15.516 to Leak a Secret, which was-- 01:03:15.516 --> 01:03:18.780 and then there's different papers about different more 01:03:18.780 --> 01:03:20.970 efficient ring signatures. 01:03:20.970 --> 01:03:24.785 But this is a really cool thing to use. 01:03:24.785 --> 01:03:26.160 I think this could be really cool 01:03:26.160 --> 01:03:28.570 for a lot of different things. 01:03:28.570 --> 01:03:32.700 If people had public keys that they were associated with 01:03:32.700 --> 01:03:36.420 and wrote them on their business cards and stuff like I do-- 01:03:36.420 --> 01:03:39.210 you could then have leaking information 01:03:39.210 --> 01:03:40.780 that's more credible. 01:03:40.780 --> 01:03:42.930 So instead of just the newspaper saying, 01:03:42.930 --> 01:03:45.420 sources close to the matter said x, y, z, 01:03:45.420 --> 01:03:49.410 or a top official at the White House said this. 01:03:49.410 --> 01:03:52.680 You could have it being signed, and we've 01:03:52.680 --> 01:03:55.830 got all these different White House officials' public keys-- 01:03:55.830 --> 01:03:57.240 one of them signed this message. 01:03:57.240 --> 01:03:59.408 So either there was a key compromise, 01:03:59.408 --> 01:04:01.950 and they all lost their keys, which is, in practice, probably 01:04:01.950 --> 01:04:05.520 more likely in that case, or one of these people signed 01:04:05.520 --> 01:04:08.460 this message, and I know it's one of them, 01:04:08.460 --> 01:04:10.710 but it doesn't reveal anything about which 01:04:10.710 --> 01:04:12.182 of the public keys-- 01:04:12.182 --> 01:04:14.100 so, that's pretty cool. 01:04:14.100 --> 01:04:17.490 So you can verify it's from a key in the array of public keys 01:04:17.490 --> 01:04:19.460 but not which. 01:04:19.460 --> 01:04:23.030 So let's put these together. 01:04:23.030 --> 01:04:29.060 I can sign with x to prove that v is 0. 01:04:29.060 --> 01:04:33.110 I could also sign with x prime, which I'm defining as x minus h 01:04:33.110 --> 01:04:35.760 to prove that v is 1. 01:04:35.760 --> 01:04:38.590 Well, what if I have a ring signature where 01:04:38.590 --> 01:04:42.610 I say I'm going to produce a signature from both of these-- 01:04:42.610 --> 01:04:46.020 from one of these 2 public keys. 01:04:46.020 --> 01:04:49.365 And that would prove that v is either 0 or 1. 01:04:49.365 --> 01:04:50.490 But it doesn't prove which. 01:04:54.250 --> 01:04:54.920 Make sense? 01:04:54.920 --> 01:04:57.910 So the idea is, I can make these signatures that essentially 01:04:57.910 --> 01:05:00.530 reveal what v is. 01:05:00.530 --> 01:05:04.460 They indirectly reveal what v is by saying there's no way I 01:05:04.460 --> 01:05:07.790 could have made this signature unless v was 0, 01:05:07.790 --> 01:05:10.500 or unless v was 1 because you're-- 01:05:10.500 --> 01:05:13.880 you know that the h component-- 01:05:13.880 --> 01:05:15.530 v is the coefficient for h. 01:05:15.530 --> 01:05:18.830 So you need to know that I don't have an h component in there 01:05:18.830 --> 01:05:22.550 if I'm going to make a signature with respect to g. 01:05:22.550 --> 01:05:27.710 And I can make any number of different x primes 01:05:27.710 --> 01:05:31.280 by subtracting different amounts of h. 01:05:31.280 --> 01:05:32.810 But a single signature would just 01:05:32.810 --> 01:05:35.310 reveal what v was, which isn't useful. 01:05:35.310 --> 01:05:39.200 But a ring signature, whereas there's 2 different pubkeys-- 01:05:39.200 --> 01:05:42.740 one of them's x-- one of them's x prime, we just subtract h. 01:05:42.740 --> 01:05:44.870 And I'm going to provide a ring signature 01:05:44.870 --> 01:05:46.700 from one of these 2 pubkeys. 01:05:46.700 --> 01:05:48.630 Now I've proven to you-- 01:05:48.630 --> 01:05:51.350 well, v is either 0 or 1-- 01:05:51.350 --> 01:05:54.120 it can't be both. 01:05:54.120 --> 01:05:55.040 But it can't be 2. 01:05:55.040 --> 01:05:55.700 It can't be 3. 01:05:55.700 --> 01:05:58.050 It's got to be one of those two values. 01:05:58.050 --> 01:05:59.740 So does this make sense? 01:05:59.740 --> 01:06:01.060 Questions on this? 01:06:01.060 --> 01:06:01.560 Yes. 01:06:01.560 --> 01:06:03.610 AUDIENCE: What does unverified look like? 01:06:03.610 --> 01:06:05.616 How does it verify that? 01:06:05.616 --> 01:06:12.710 TADGE DRYJA: Oh, well, the original scheme 01:06:12.710 --> 01:06:14.660 is kind of complicated. 01:06:14.660 --> 01:06:17.240 The one used in confidential transactions 01:06:17.240 --> 01:06:19.010 is Borromean ring signatures. 01:06:25.320 --> 01:06:27.375 You do a bunch of hash functions. 01:06:30.090 --> 01:06:30.870 I don't know it. 01:06:30.870 --> 01:06:33.328 I don't even really know it well enough myself to really be 01:06:33.328 --> 01:06:35.490 able to explain it in a minute. 01:06:35.490 --> 01:06:37.290 But, basically, you compute something 01:06:37.290 --> 01:06:39.720 on all of the pubkeys, and then verify 01:06:39.720 --> 01:06:42.930 the signature on the aggregate pubkey as a way 01:06:42.930 --> 01:06:45.390 to think about it. 01:06:45.390 --> 01:06:49.320 The signatures can-- the computing time 01:06:49.320 --> 01:06:52.950 gets big with a number of pubkeys. 01:06:52.950 --> 01:06:55.500 So if you have millions of pubkeys that could possibly 01:06:55.500 --> 01:06:57.740 be signing-- 01:06:57.740 --> 01:07:03.030 the verification algorithm gets really time-consuming. 01:07:03.030 --> 01:07:06.550 So I can maybe go into ring signatures another time. 01:07:06.550 --> 01:07:07.050 Yeah. 01:07:07.050 --> 01:07:08.592 AUDIENCE: I thought the point of this 01:07:08.592 --> 01:07:11.590 was to prove that v is non-negative. 01:07:11.590 --> 01:07:14.750 So right now, we're just saying it's not-- 01:07:14.750 --> 01:07:16.635 it could be two values. 01:07:16.635 --> 01:07:19.180 How does it help us through the signs? 01:07:19.180 --> 01:07:21.610 TADGE DRYJA: Well, neither of these are any good. 01:07:21.610 --> 01:07:22.570 So we've just proven-- 01:07:22.570 --> 01:07:25.210 we've done quite a bit more than prove it's non-negative. 01:07:25.210 --> 01:07:29.310 We've proved that it's exactly 0 or exactly 1. 01:07:29.310 --> 01:07:32.160 We might want more values. 01:07:32.160 --> 01:07:35.040 So make a ring signature from a million 01:07:35.040 --> 01:07:39.210 different public keys where the pub n is just 01:07:39.210 --> 01:07:41.730 pub n minus 1 minus h. 01:07:41.730 --> 01:07:44.310 And then I just proved that v is somewhere in the range 01:07:44.310 --> 01:07:46.630 from 0 to 99999. 01:07:46.630 --> 01:07:47.130 Yeah. 01:07:47.130 --> 01:07:50.370 AUDIENCE: What is computation time for ring signatures 01:07:50.370 --> 01:07:51.900 as the number of public keys? 01:07:51.900 --> 01:07:53.220 TADGE DRYJA: Yeah, it goes up. 01:07:53.220 --> 01:07:56.670 The best is linear, or, no, there might be-- sorry-- 01:07:56.670 --> 01:07:58.050 there's probably sublinear now. 01:07:58.050 --> 01:07:59.190 But this is not feasible. 01:07:59.190 --> 01:08:01.300 [LAUGHS] 01:08:01.300 --> 01:08:03.390 The traditional ring signatures are 01:08:03.390 --> 01:08:06.520 linear with the number of public keys to be verified. 01:08:06.520 --> 01:08:10.130 So if you did this-- 01:08:10.130 --> 01:08:14.010 well, all even then, you'd have to throw, though, because-- 01:08:14.010 --> 01:08:16.500 you have to at least throw the public key 01:08:16.500 --> 01:08:19.175 into the verification function. 01:08:19.175 --> 01:08:21.550 And so that means you need to compute a million pubkeys-- 01:08:21.550 --> 01:08:22.717 throw it into that function. 01:08:22.717 --> 01:08:24.670 It's going to take a long time. 01:08:24.670 --> 01:08:30.240 So this is not itself going to work. 01:08:30.240 --> 01:08:30.740 Yeah. 01:08:30.740 --> 01:08:33.280 AUDIENCE: Just Monero uses ring signatures? 01:08:33.280 --> 01:08:37.920 TADGE DRYJA: Yes, Monero uses ring signatures 01:08:37.920 --> 01:08:39.350 for a different reason. 01:08:39.350 --> 01:08:41.779 Well, now they use it for this kind of thing, too. 01:08:41.779 --> 01:08:44.390 The Monero ring signature was initially 01:08:44.390 --> 01:08:48.979 used for not hiding the amounts but hiding 01:08:48.979 --> 01:08:52.060 which outputs were being spent. 01:08:52.060 --> 01:08:55.540 So in Bitcoin, everyone should-- 01:09:05.460 --> 01:09:08.029 So in Bitcoin if you have a transaction-- 01:09:08.029 --> 01:09:10.990 here's my input, here's my output. 01:09:10.990 --> 01:09:12.609 And the simplest one is just-- 01:09:12.609 --> 01:09:17.245 this points to tx5 or something, and then my output is address-- 01:09:21.010 --> 01:09:25.689 and it's address b, and it's got 7 coins. 01:09:25.689 --> 01:09:27.399 Everyone can see what you're spending. 01:09:27.399 --> 01:09:33.580 The idea in Monero is, I don't point to an input-- 01:09:33.580 --> 01:09:35.728 I just provide a signature. 01:09:35.728 --> 01:09:38.270 And it's up to you to figure out where that signature's from. 01:09:38.270 --> 01:09:41.479 So I provide a signature and a list of pubkeys-- 01:09:41.479 --> 01:09:43.090 pub a-- pub b. 01:09:43.090 --> 01:09:44.960 So the smallest would be 2. 01:09:44.960 --> 01:09:48.294 And then I provide a key-- 01:09:48.294 --> 01:09:49.580 key in a number. 01:09:49.580 --> 01:09:53.729 So the idea is instead of thinking of it as outputs, 01:09:53.729 --> 01:09:56.880 you think pubkeys have associated values. 01:09:56.880 --> 01:09:59.130 You don't look at the transactions themselves. 01:09:59.130 --> 01:10:01.460 This is key c. 01:10:01.460 --> 01:10:06.620 And there previously have been-- pubkey a and pubkey b have had 01:10:06.620 --> 01:10:07.640 values-- 01:10:07.640 --> 01:10:09.560 7 coins sent to them. 01:10:09.560 --> 01:10:11.120 And I can now say, look, I'm going 01:10:11.120 --> 01:10:17.490 to provide a ring signature from either pubkey a or pubkey b. 01:10:17.490 --> 01:10:19.410 And I'm not going to tell you which, 01:10:19.410 --> 01:10:23.730 but you can see that both pubkey a and pubkey b have 01:10:23.730 --> 01:10:25.710 received 7 coins in the past. 01:10:25.710 --> 01:10:27.810 I want to send 7 coins over here. 01:10:27.810 --> 01:10:30.270 I'm going to prove that I own one of those two. 01:10:30.270 --> 01:10:34.560 And then you can validate that the transaction's valid. 01:10:34.560 --> 01:10:40.400 And then if later, you see another transaction with a ring 01:10:40.400 --> 01:10:43.946 signature from pub a-- 01:10:43.946 --> 01:10:49.072 pub b-- also sending to the key d-- 01:10:49.072 --> 01:10:50.970 7 coins. 01:10:50.970 --> 01:10:53.360 Now, I can delete pub a and pub b. 01:10:53.360 --> 01:10:54.890 I don't know which, this-- 01:10:54.890 --> 01:10:59.288 so in transaction 1, I don't know whether a or b was spent, 01:10:59.288 --> 01:11:00.330 but one of those two was. 01:11:00.330 --> 01:11:02.310 And then in transaction 2, I don't know whether a or b 01:11:02.310 --> 01:11:03.477 are spent-- one of them was. 01:11:03.477 --> 01:11:05.610 But anyway, they've both been spent now. 01:11:05.610 --> 01:11:09.090 And so I can delete them from my storage. 01:11:09.090 --> 01:11:10.650 But the ring signature's in Monero 01:11:10.650 --> 01:11:14.010 were used to obscure the transaction graph itself-- 01:11:14.010 --> 01:11:16.560 where you can see that there's a bunch of different keys 01:11:16.560 --> 01:11:18.540 that have money associated with them. 01:11:18.540 --> 01:11:20.040 And I'm going to provide a signature 01:11:20.040 --> 01:11:23.820 that I own one of them, but I don't tell you which. 01:11:23.820 --> 01:11:26.370 And now they also do confidential transactions 01:11:26.370 --> 01:11:29.590 to obscure the outputs using ring signatures as well. 01:11:29.590 --> 01:11:32.600 So I don't-- well, it's interesting. 01:11:32.600 --> 01:11:35.737 I haven't looked at it that closely. 01:11:35.737 --> 01:11:37.070 So I know that's the basic idea. 01:11:37.070 --> 01:11:39.620 But there's a lot of subtle details involved 01:11:39.620 --> 01:11:41.996 in how that works, and I'm not super familiar with that. 01:11:44.580 --> 01:11:47.560 So I can finish up. 01:11:47.560 --> 01:11:51.220 So the way to make this practical 01:11:51.220 --> 01:11:54.322 is, let's say you have a ring signature for each bit, 01:11:54.322 --> 01:11:56.530 so you're going to have to have a different signature 01:11:56.530 --> 01:11:59.650 for each bit in your value. 01:11:59.650 --> 01:12:03.350 So the pubkey x0-- 01:12:03.350 --> 01:12:05.350 well, I'm going to have a ring signature where I 01:12:05.350 --> 01:12:07.478 prove that it's either 0 or 1. 01:12:07.478 --> 01:12:09.520 And here I'm going to prove it's either a 0 or 2. 01:12:09.520 --> 01:12:11.470 Here I'm going to prove it's either 0 or 4. 01:12:11.470 --> 01:12:16.030 And so if I have 32 signatures, I 01:12:16.030 --> 01:12:18.160 can now prove a 32-bit number. 01:12:18.160 --> 01:12:19.720 Each of those individual signatures 01:12:19.720 --> 01:12:22.690 only has 2 public keys associated with it. 01:12:22.690 --> 01:12:25.800 So that's now more feasible. 01:12:25.800 --> 01:12:30.030 There's a total of 32 public keys, 32 signatures-- 01:12:30.030 --> 01:12:32.730 not the end of the world-- still kind of ugly. 01:12:32.730 --> 01:12:35.160 And then there's optimizations where 01:12:35.160 --> 01:12:41.150 since these pubkeys are all the same, the 0 value for that 01:12:41.150 --> 01:12:41.990 bit-- 01:12:41.990 --> 01:12:43.567 we can squish them together and stuff 01:12:43.567 --> 01:12:44.900 to make it a little bit smaller. 01:12:48.150 --> 01:12:51.990 So you have a signature per bit of your output. 01:12:51.990 --> 01:12:54.460 If your values are not too big-- this works. 01:12:54.460 --> 01:12:56.130 We're going to limit it to 32-bits. 01:12:56.130 --> 01:12:59.310 So from 0 to 4 billion. 01:12:59.310 --> 01:13:05.340 Now you can prove that each bit was either a 0 or 1, 01:13:05.340 --> 01:13:10.170 essentially, without revealing whether it was a 0 or 1. 01:13:10.170 --> 01:13:12.390 And then it's a couple of kilobytes per output. 01:13:12.390 --> 01:13:15.000 So it's a little bit annoying. 01:13:15.000 --> 01:13:16.020 It used to be 8 bytes. 01:13:16.020 --> 01:13:18.960 You said, hey, I've got 37 points. 01:13:18.960 --> 01:13:23.220 Also, these 8 bytes are very sparse in that they rarely 01:13:23.220 --> 01:13:26.440 exceed 4 bytes. 01:13:26.440 --> 01:13:30.400 So you can compact it down on disk. 01:13:30.400 --> 01:13:31.380 So this is a little-- 01:13:31.380 --> 01:13:33.510 scalability-wise, it's an issue. 01:13:33.510 --> 01:13:36.980 You're now going from what used to be 8 bytes is now a couple 01:13:36.980 --> 01:13:37.650 kilobytes. 01:13:37.650 --> 01:13:40.080 I think they've got it down to 2 kilobytes. 01:13:40.080 --> 01:13:41.890 But still, that's 2 kilobytes. 01:13:41.890 --> 01:13:44.940 And it takes a bit more CPU time to verify. 01:13:44.940 --> 01:13:47.340 Because now, instead of verifying one signature 01:13:47.340 --> 01:13:49.990 to see that the coins are moving to the right place, 01:13:49.990 --> 01:13:54.360 you're verifying 30-plus signatures 01:13:54.360 --> 01:13:59.480 for every input and output. 01:13:59.480 --> 01:14:01.320 Also, the real problem is it's not really 01:14:01.320 --> 01:14:02.760 compatible with Bitcoin-- 01:14:02.760 --> 01:14:05.340 this would be a really tricky fork to implement. 01:14:05.340 --> 01:14:08.310 How do you implement this such that the old software 01:14:08.310 --> 01:14:11.460 on the network is OK with these transactions 01:14:11.460 --> 01:14:16.297 where they're expecting a transaction that has a value? 01:14:16.297 --> 01:14:17.880 Here's how many coins are being moved. 01:14:17.880 --> 01:14:19.790 If you say, no, I'm not going to tell you anymore. 01:14:19.790 --> 01:14:21.998 Well, old software doesn't know how to deal with this 01:14:21.998 --> 01:14:24.810 and by default, will reject these transactions. 01:14:24.810 --> 01:14:29.610 So there's ways to do it that doesn't break compatibility, 01:14:29.610 --> 01:14:32.760 but they're pretty ugly. 01:14:32.760 --> 01:14:34.500 One of the ways is to say, OK, from now 01:14:34.500 --> 01:14:38.490 on, all these transactions-- all output values have to be 0. 01:14:38.490 --> 01:14:40.300 So the old software will still work, 01:14:40.300 --> 01:14:43.140 but it will be pretty confused and say, 01:14:43.140 --> 01:14:44.340 I see all these values. 01:14:44.340 --> 01:14:45.990 I see thousands of transactions. 01:14:45.990 --> 01:14:48.330 No one seems to be sending anyone any money. 01:14:48.330 --> 01:14:50.190 So they seem to be pointless. 01:14:50.190 --> 01:14:52.530 And then there's this hidden value 01:14:52.530 --> 01:14:54.990 that's in a different data structure that would 01:14:54.990 --> 01:14:56.250 look something like segwit. 01:14:56.250 --> 01:15:00.060 And segwit was a little bit ugly-- this would be real ugly. 01:15:00.060 --> 01:15:03.750 Those are the trade-offs we're dealing with here-- 01:15:03.750 --> 01:15:06.090 tricky fork. 01:15:06.090 --> 01:15:08.070 But you get this. 01:15:08.070 --> 01:15:12.150 This is what you get when you use confidential transactions. 01:15:12.150 --> 01:15:13.740 You got it, right? 01:15:13.740 --> 01:15:15.270 We have private, unlinkable amounts 01:15:15.270 --> 01:15:17.590 where the network can verify-- 01:15:17.590 --> 01:15:20.790 OK, let me verify that w plus x equals y plus z-- 01:15:20.790 --> 01:15:22.660 that's the easy part. 01:15:22.660 --> 01:15:27.390 Now, let me verify for every individual w, x, y, and z 01:15:27.390 --> 01:15:31.192 that it is within the range of 0 to 6223222232-- 01:15:31.192 --> 01:15:33.770 02 to the 32-- 01:15:33.770 --> 01:15:37.193 it's a tongue-twister-- by verifying 01:15:37.193 --> 01:15:38.610 all these separate ring signatures 01:15:38.610 --> 01:15:39.735 for each bit of the amount. 01:15:42.098 --> 01:15:43.140 But you can do it, right? 01:15:43.140 --> 01:15:47.070 You can verify-- input amounts equal output amounts. 01:15:47.070 --> 01:15:49.890 All these input amounts and output amounts 01:15:49.890 --> 01:15:51.630 are normal looking numbers that aren't 01:15:51.630 --> 01:15:53.910 too big that aren't right up near the modulos 01:15:53.910 --> 01:15:55.590 to wrap around. 01:15:55.590 --> 01:15:59.610 And it works-- it's just big and slow-- 01:15:59.610 --> 01:16:02.280 we're trying to make that faster. 01:16:02.280 --> 01:16:05.460 So probably not going to go-- if you're interested in this, 01:16:05.460 --> 01:16:07.530 though, there's a lot of research about this kind 01:16:07.530 --> 01:16:08.730 of thing right now. 01:16:08.730 --> 01:16:12.060 It's really cool getting in the crazy, interesting math. 01:16:12.060 --> 01:16:16.800 So there's bulletproofs, which was Benedict's at Stanford. 01:16:16.800 --> 01:16:19.080 He wrote up-- I mean, a bunch of people wrote it, 01:16:19.080 --> 01:16:21.660 but I think it was sort of his idea, 01:16:21.660 --> 01:16:25.320 or his thing working with other people, too. 01:16:25.320 --> 01:16:27.570 That's more efficient range proofs. 01:16:27.570 --> 01:16:29.220 I do not know how bulletproofs work. 01:16:29.220 --> 01:16:32.160 I tried to read the paper and got two pages in, 01:16:32.160 --> 01:16:33.150 and I don't know. 01:16:33.150 --> 01:16:36.780 [LAUGHS] But I'm sure I could figure it out-- 01:16:36.780 --> 01:16:39.000 it would just take me a long time. 01:16:39.000 --> 01:16:40.860 And then the Borromean ring signatures-- 01:16:40.860 --> 01:16:42.480 the more efficient ring signatures 01:16:42.480 --> 01:16:46.930 that can compact a lot of data so that you're not-- 01:16:46.930 --> 01:16:49.380 so you get it down to two kilobytes 01:16:49.380 --> 01:16:53.610 for these range proofs in confidential transactions. 01:16:53.610 --> 01:16:56.730 And then I may try to give a class 01:16:56.730 --> 01:16:58.380 about this in a week or two-- 01:16:58.380 --> 01:17:00.000 MimbleWimble. 01:17:00.000 --> 01:17:04.350 The idea is that when all of the transactions in the network 01:17:04.350 --> 01:17:06.900 are like this and that have confidential inputs and outputs 01:17:06.900 --> 01:17:09.600 amounts, the transactions can be canceled out 01:17:09.600 --> 01:17:11.880 in an interesting way. 01:17:11.880 --> 01:17:14.495 Because the output amounts are unique. 01:17:14.495 --> 01:17:15.870 They have these blinding factors. 01:17:15.870 --> 01:17:17.640 They have these range proofs. 01:17:17.640 --> 01:17:20.820 And so if you're in a block-- 01:17:20.820 --> 01:17:22.740 so just a hint about MimbleWimble-- 01:17:22.740 --> 01:17:27.990 the idea is if you have a transaction and amounts 01:17:27.990 --> 01:17:28.920 are all obscured. 01:17:28.920 --> 01:17:32.760 But a is being consumed, b is being consumed, 01:17:32.760 --> 01:17:34.920 c is being created, d is being created. 01:17:34.920 --> 01:17:38.830 These are amounts. 01:17:38.830 --> 01:17:40.950 And then I see later in the block 01:17:40.950 --> 01:17:44.560 there is another transaction which spends d coins 01:17:44.560 --> 01:17:45.790 and sends to e coins. 01:17:50.350 --> 01:17:55.270 I don't have to verify that a plus b equal c plus d. 01:17:55.270 --> 01:17:57.730 And d equals e kind of thing-- 01:17:57.730 --> 01:17:59.470 I can just cross these out. 01:17:59.470 --> 01:18:01.630 And I can verify on a block-level instead 01:18:01.630 --> 01:18:04.750 of a transaction-level that the input amounts and output 01:18:04.750 --> 01:18:10.110 amounts all matched up because I don't know what d is. 01:18:10.110 --> 01:18:12.040 But, anyway, it was on an output side 01:18:12.040 --> 01:18:14.690 and on an input side within the same block. 01:18:14.690 --> 01:18:17.350 So, anyway, it's gone. 01:18:17.350 --> 01:18:19.810 It's being added to and subtracted in this block. 01:18:19.810 --> 01:18:20.825 So I can do that. 01:18:20.825 --> 01:18:22.450 And I can do that over multiple blocks. 01:18:22.450 --> 01:18:25.240 And I can basically keep a tally of how many coins 01:18:25.240 --> 01:18:30.160 are in the system and cancel things out. 01:18:30.160 --> 01:18:32.710 So that lets you do some really cool things where 01:18:32.710 --> 01:18:35.020 you can skip a lot of verification 01:18:35.020 --> 01:18:37.220 at no loss of security. 01:18:37.220 --> 01:18:39.370 So that's the idea of a MimbleWimble, which 01:18:39.370 --> 01:18:42.830 is really a fun paper because it was written by Lord Voldemort. 01:18:45.910 --> 01:18:49.320 Someone posted a Pastebin link on IRC. 01:18:49.320 --> 01:18:50.920 And who knows who wrote this-- 01:18:50.920 --> 01:18:51.640 Lord Voldemort. 01:18:51.640 --> 01:18:53.550 Except it was Lord Voldemort-- 01:18:53.550 --> 01:18:56.200 the French word for Lord Voldemort. 01:18:56.200 --> 01:18:58.870 So when they translated Harry Potter into French, 01:18:58.870 --> 01:19:01.210 they changed the names around, I guess, 01:19:01.210 --> 01:19:04.600 and it was the French equivalent of Lord Voldemort. 01:19:04.600 --> 01:19:07.780 And so now there's a bunch of people programming MimbleWimble 01:19:07.780 --> 01:19:09.070 and implementing it. 01:19:09.070 --> 01:19:10.450 And they all use Harry Potter-- 01:19:10.450 --> 01:19:11.680 not all of them, but a lot of them 01:19:11.680 --> 01:19:13.055 use Harry Potter names on GitHub. 01:19:13.055 --> 01:19:14.920 So it's kind of funny. 01:19:14.920 --> 01:19:18.580 It's also really funny that it was one of the most-- 01:19:18.580 --> 01:19:21.420 I would say, the most-- 01:19:21.420 --> 01:19:26.660 whoa, kind of paper of 2016 now. 01:19:26.660 --> 01:19:28.920 And so it's of an interesting indicator 01:19:28.920 --> 01:19:32.010 of the space we're working in that you've got IBM and all 01:19:32.010 --> 01:19:35.430 these big companies, and they're working on blockchain research, 01:19:35.430 --> 01:19:38.760 and, honestly, not a ton of awesome stuff, 01:19:38.760 --> 01:19:40.770 whereas like, whoa, MimbleWimble, OK, 01:19:40.770 --> 01:19:42.160 Lord Voldemort-- 01:19:42.160 --> 01:19:43.302 he really showed everyone. 01:19:43.302 --> 01:19:48.690 [LAUGHS] So it's fun that it's still a very out-there hackery 01:19:48.690 --> 01:19:49.860 system. 01:19:49.860 --> 01:19:54.320 So that's-- hopefully, most people got most of the idea. 01:19:54.320 --> 01:19:56.430 It's a little bit fast. 01:19:56.430 --> 01:19:59.580 It sort of explained all the Pedersen commitments and range 01:19:59.580 --> 01:20:01.672 proofs and everything in a little bit of time. 01:20:01.672 --> 01:20:02.880 But I think you got the idea. 01:20:02.880 --> 01:20:04.505 And if you're interested in it, there's 01:20:04.505 --> 01:20:06.240 a lot of current research on this 01:20:06.240 --> 01:20:07.500 and people implementing it. 01:20:07.500 --> 01:20:10.250 And there's a lot of cool things you can do with it, so.