WEBVTT - Automatic transcript; recognition may contain errors. Reviewed for technical wording and speaker labels. Times match the published episode. 00:00:19.380 --> 00:00:22.860 Live from Utrecht, this is Bitcoin Explained. 00:00:23.120 --> 00:00:23.380 Hello. 00:00:24.000 --> 00:00:24.500 Hey, Sjors. 00:00:24.880 --> 00:00:25.200 What's up? 00:00:25.660 --> 00:00:28.470 I'm good. And welcome back, Ruben. 00:00:28.970 --> 00:00:30.130 Thank you. Good to be back. 00:00:30.450 --> 00:00:31.790 Back-to-back episodes for you? 00:00:32.310 --> 00:00:36.330 Yeah, sure. Almost. Or has there not been an episode in between? I don't even know. 00:00:36.590 --> 00:00:40.690 We skipped last one. So yeah, no, it's truly back-to-back for you this time. 00:00:40.680 --> 00:00:41.060 All right, cool. 00:00:41.650 --> 00:00:46.580 Happy you are back because we're going to discuss a particularly... interesting 00:00:46.580 --> 00:00:51.820 and at least in my opinion, pretty complex topic. We did have a, we had a call 00:00:51.820 --> 00:00:57.680 the three of us before we started recording this, this afternoon, and uh, it was 00:00:57.680 --> 00:01:02.340 basically a call between the two of you because I tapped out after like a minute 00:01:02.340 --> 00:01:08.090 and especially when it became mathematical, when the mathematics came into 00:01:08.090 --> 00:01:13.210 play, that's where it went a little bit over my head. So let's see how we can 00:01:13.210 --> 00:01:14.370 manage this episode today. 00:01:14.590 --> 00:01:18.210 Yeah, for me, it was also just confusing initially, especially reading some of 00:01:18.210 --> 00:01:22.870 the documentation that explains some of the assumptions behind it and then just 00:01:22.870 --> 00:01:27.010 skips all the details that I care about to actually understand it. It's not the 00:01:27.010 --> 00:01:31.330 full math, but it's like, ah, tell me one more thing, tell me one more thing. But 00:01:31.330 --> 00:01:35.130 then if you're listening to a high-level talk by somebody who's not trying to 00:01:35.130 --> 00:01:38.610 make it technical, they're not filling out the details. And then if you want to 00:01:38.610 --> 00:01:40.750 read... an actual spec gets too technical. 00:01:41.710 --> 00:01:47.670 So the thing we are going to discuss is Discreet log contracts, also 00:01:47.670 --> 00:01:49.630 known as DLCs. 00:01:49.910 --> 00:01:53.810 Yeah, and it's spelled discreet E-E-T, which kind of means 00:01:53.810 --> 00:01:59.710 careful in what you're saying, versus 00:01:59.710 --> 00:02:05.090 discrete with E-T-E, which is single digits, like 00:02:05.090 --> 00:02:10.880 a discrete number. But it's a pun. Yeah, you cannot say 00:02:10.880 --> 00:02:12.340 in audio because it sounds the same. 00:02:12.340 --> 00:02:17.600 I think the end result is that people are just confused, but it's a, it's funny 00:02:17.600 --> 00:02:18.580 for those who are in the know. 00:02:18.580 --> 00:02:23.400 Yeah, anyway, so let's start with a short summary of what Discreet long—log 00:02:23.400 --> 00:02:29.120 contracts actually are. I would summarize it as there are, they are essentially 00:02:29.120 --> 00:02:34.280 smart contracts for Bitcoin and a little bit more specifically they are bets, 00:02:34.280 --> 00:02:40.130 essentially. Yeah. And the interesting thing about bets is that many types of 00:02:40.130 --> 00:02:44.810 financial contracts are essentially bets, even if we don't 00:02:45.660 --> 00:02:49.740 normally think of them as bets. You, you can sort of distill them as bets 00:02:49.740 --> 00:02:53.200 like, right, they're not gambling necessarily. They could just be saying I think 00:02:53.200 --> 00:02:57.400 the dollar is going to go up, uh, so I want a derivative project, uh, product 00:02:57.400 --> 00:03:01.040 that follows the dollar price and you could call that betting, but it's, it's, 00:03:01.040 --> 00:03:03.680 it's a sane thing to do even as, as a non-gambler 00:03:03.680 --> 00:03:08.660 Yeah, yeah, exactly. Or like an insurance, if you, if you're insuring your house 00:03:08.660 --> 00:03:13.980 in a way you're sort of betting that your house will burn down. And then if you 00:03:13.980 --> 00:03:18.100 lose the bet and you didn't, your house is still there, you're kind of happy, but 00:03:18.100 --> 00:03:22.320 it did cost a little bit of money. So that's sort of the down payment. Well, if 00:03:22.320 --> 00:03:26.400 your house burns down, you win the bet and you get all this money. So a lot of 00:03:26.400 --> 00:03:31.700 financial products are essentially bets. So that's why it's interesting to think 00:03:31.700 --> 00:03:37.400 of how can we bring this sort of betting to Bitcoin. And then what we 00:03:37.400 --> 00:03:41.220 really want or, you know, the essence of smart contracts, what smart contracts 00:03:41.220 --> 00:03:47.160 are ideally at least, is that these bets are executed automatically, right? 00:03:48.120 --> 00:03:52.680 Yes. And in the case of blockchain, not just automatically, but also in a way 00:03:52.680 --> 00:03:58.660 that does not require any trust. Now, just a spoiler. There is this thing 00:03:58.660 --> 00:04:03.340 called the Oracle problem. And we are not solving the Oracle problem. The Oracle 00:04:03.340 --> 00:04:07.500 problem basically means that if you have anything that relies on information 00:04:07.500 --> 00:04:12.220 outside the blockchain, well, anything except the knowledge of a private key or hash, 00:04:13.530 --> 00:04:16.550 If you need any kind of information from outside the blockchain, like the weather 00:04:16.550 --> 00:04:20.790 or the dollar price, there has to be an oracle that knows this thing. And the 00:04:20.790 --> 00:04:24.070 blockchain has no idea if the oracle is lying or not. And we're not going to 00:04:24.070 --> 00:04:27.870 solve that. So everything we're doing here still assumes that the oracle is 00:04:27.870 --> 00:04:31.810 honest. And then there are some tricks that you can use to make it slightly more 00:04:31.810 --> 00:04:34.060 honest. But it's not a perfect solution. 00:04:34.300 --> 00:04:37.960 Well, that is kind of what we're doing, right? We're sort of trying to minimize 00:04:37.960 --> 00:04:40.900 the trust in the Oracle or at least a little bit. 00:04:41.400 --> 00:04:46.110 Well, we're also trying to reduce the workload for the Oracle, and increase the 00:04:46.110 --> 00:04:47.770 plausible deniability for the oracle. 00:04:47.970 --> 00:04:51.590 Yeah, that's I think an important point where the oracle doesn't have to be 00:04:51.590 --> 00:04:56.410 directly involved with your bets. It can just post the outcome and then you take 00:04:56.410 --> 00:04:59.970 the outcome and you resolve your bets with that outcome without the oracle 00:04:59.970 --> 00:05:02.230 specifically having to know that you were even betting. 00:05:02.710 --> 00:05:06.610 Right, and that also makes the oracle hopefully more neutral. So again, you 00:05:06.610 --> 00:05:07.490 cannot guarantee that. 00:05:07.670 --> 00:05:07.750 Yeah. 00:05:08.270 --> 00:05:12.810 Okay, so... Before we get into it, let's pick a very nice and easy sort of bet 00:05:12.810 --> 00:05:14.610 that everyone will understand is a bet. 00:05:14.770 --> 00:05:15.990 If it's going to rain tomorrow. 00:05:16.890 --> 00:05:17.910 I don't like that one. 00:05:18.810 --> 00:05:20.750 Especially because the answer tends to be yes here. 00:05:22.570 --> 00:05:27.430 Let's go for the World Cup final. We'll have the World Cup later this year. Let's 00:05:27.430 --> 00:05:31.370 assume the World Cup final is the Netherlands versus Germany, and now we're gonna 00:05:31.370 --> 00:05:33.950 bet on the winner of the World Cup final. Yeah, all right. 00:05:33.950 --> 00:05:36.570 Yeah, all right. Trivial, but yeah. 00:05:36.570 --> 00:05:39.110 That will be the bet throughout this episode. 00:05:39.110 --> 00:05:40.930 Obviously, the Netherlands is gonna win, but okay. 00:05:40.930 --> 00:05:46.390 The Netherlands versus Germany. All right, in the World Cup final. So the very— 00:05:46.390 --> 00:05:51.730 let's start at the beginning. We want to solve this problem, um, Ruben and Sjors, 00:05:51.850 --> 00:05:55.190 you want to bet against each other. Ruben, you're betting on the Netherlands 00:05:55.190 --> 00:05:59.790 apparently. Sjors, you're betting on Germany. Now we need to make this trustless 00:05:59.790 --> 00:06:05.230 somehow. I think the most basic solution is to create a multisig. 00:06:05.530 --> 00:06:10.110 Well, you could create a multisig between the two of you, two of two, but then 00:06:10.110 --> 00:06:13.610 you have the obvious problem that the loser might not cooperate, right? 00:06:13.810 --> 00:06:13.950 Yeah. 00:06:14.510 --> 00:06:18.900 So if we take the next step... we'll take it one step further. We'll introduce 00:06:18.900 --> 00:06:23.500 the oracle that's gonna be me. Both of you trust me. So now we create a two out 00:06:23.500 --> 00:06:29.480 of three multisig and now the final has been played. The Netherlands 00:06:29.480 --> 00:06:35.460 has won at this point. Either Sjors can cooperate with Ruben to get all the money 00:06:35.460 --> 00:06:41.160 in the multisig to Ruben, or if Sjors doesn't cooperate, then Ruben can contact 00:06:41.160 --> 00:06:42.400 me. I'll step in. 00:06:43.900 --> 00:06:47.700 I'll acknowledge that the Netherlands won the final. So I'll provide my signature 00:06:47.700 --> 00:06:52.620 and I'll help Ruben get the money. Now, because I can do this, and because both 00:06:52.620 --> 00:06:55.940 of you know I can do this, and Sjors in particular, you know for a fact that I 00:06:55.940 --> 00:06:59.640 can do this. So at this point, there's really no reason for you to obstruct. You 00:06:59.640 --> 00:07:01.020 might as well just cooperate, right? 00:07:01.300 --> 00:07:07.080 Yeah, exactly. And so this could just be a trusted friend or this could be the 00:07:07.080 --> 00:07:12.180 actual organization that runs the soccer match that has no reason to lie about 00:07:12.180 --> 00:07:16.140 the result and is subject to some scrutiny. But the problem is then, of course, 00:07:16.500 --> 00:07:22.400 if you want to do a contract with this World Cup organizer, you know... You 00:07:22.400 --> 00:07:26.060 need to involve them. They actually need to sign something specifically for you. 00:07:26.220 --> 00:07:29.300 And they may not want to do that because, hey, then they're cooperating with 00:07:29.300 --> 00:07:34.670 sports betting. Or they don't feel like doing that. I don't know. 00:07:35.620 --> 00:07:41.040 Yeah, what you're saying is that there are a number of problems with this 00:07:41.040 --> 00:07:46.100 solution. One of them is it requires me to actually be actively involved in your 00:07:46.100 --> 00:07:50.660 bet, even before the bet is made. I need to provide my public key and I sort of 00:07:50.660 --> 00:07:53.960 need to know what you guys are doing and I need to agree with that. And then 00:07:53.960 --> 00:07:56.760 after the bet, you might need my help and I might do stuff. 00:07:59.320 --> 00:08:04.380 If it's just two of you, that's maybe acceptable, but now tens of thousands of 00:08:04.380 --> 00:08:08.580 people want to make the same bet, and I would have to provide my public key to 00:08:08.580 --> 00:08:12.040 tens of thousands of people, and now it starts to become a lot of work, right? 00:08:12.240 --> 00:08:16.340 And they don't even know what you exactly are betting, right? So they would have 00:08:16.340 --> 00:08:20.370 to read the terms and conditions of each of your bets to even know which side to 00:08:20.370 --> 00:08:24.710 have to sign. Because you can't tell by the public key which side I, Ruben, bet 00:08:24.710 --> 00:08:26.870 it on. So yeah, it's pretty tedious. 00:08:27.230 --> 00:08:30.430 Yeah, and then there's the problem that I need to know what you guys are doing, 00:08:30.450 --> 00:08:34.550 which is sort of bad for your privacy. I need to know which coins are yours and 00:08:34.550 --> 00:08:37.750 what they're used for. Are there more problems? 00:08:38.970 --> 00:08:41.070 Well, I think you summed it up pretty well. 00:08:41.700 --> 00:08:44.780 That said, I think it's possible. It's not impossible. 00:08:45.300 --> 00:08:50.520 Yeah. Obviously, I could try to cheat by, for example, 00:08:51.380 --> 00:08:56.560 Sjors could try to bribe me. He could contact me, say, hey, Aaron, let's share 00:08:56.560 --> 00:09:00.160 the prize and forget about Ruben. Let's share the prize between us. And, you 00:09:00.160 --> 00:09:04.100 know, I could be corrupted in this way. It's not a problem. Lots of problems with 00:09:04.100 --> 00:09:05.900 this solution, even though it technically works. 00:09:06.490 --> 00:09:06.890 Yes. 00:09:07.070 --> 00:09:11.750 I will say there's an upside to it as well, which is that if the bet somehow is 00:09:11.750 --> 00:09:16.210 unclear or I don't know, there's a meteor crashes on earth and the finals are 00:09:16.210 --> 00:09:21.330 canceled. And now we're like, oh, what are we going to do with our bets? Then you 00:09:21.330 --> 00:09:26.510 being a human, you can maybe, you know, sort of have, you can make a decision on 00:09:26.510 --> 00:09:31.710 our behalf. That's maybe one small advantage, but I don't think it's a great one. 00:09:32.080 --> 00:09:34.200 Okay, method two. Method one. 00:09:34.360 --> 00:09:38.340 Yeah, so let's try to improve on this solution. Sjors, you wanted to improve on 00:09:38.340 --> 00:09:38.780 the solution. 00:09:39.920 --> 00:09:45.380 Yes. So today I learned about a concept, which I had not followed, and it's 00:09:45.380 --> 00:09:46.460 called Reality Keys. 00:09:46.580 --> 00:09:46.760 Yeah. 00:09:47.140 --> 00:09:51.600 And this is actually a pretty simple idea. It takes it one step further. 00:09:52.390 --> 00:09:54.270 This is an existing thing. 00:09:54.490 --> 00:09:55.630 It was an existing thing. 00:09:55.630 --> 00:09:56.650 This was an existing thing. 00:09:56.650 --> 00:10:02.350 It existed between 2014 and 2018, and it just disappeared. And I don't think a 00:10:02.350 --> 00:10:06.170 lot of Bitcoiners remember, but it was actually kind of a really awesome little 00:10:06.170 --> 00:10:06.650 platform. 00:10:08.170 --> 00:10:13.890 But the general idea still exists. Of course, you can do this. So what the World 00:10:13.890 --> 00:10:16.850 Cup leaders in this case probably, they would be the Oracle, what they would do 00:10:16.850 --> 00:10:22.500 is they would say, here is two public keys. Public key A, or public key 00:10:22.500 --> 00:10:28.100 N, I guess, and public key D, as in the Netherlands public key and the Germany 00:10:28.100 --> 00:10:33.900 public key. And depending on who wins, we will publish one of those keys. We will 00:10:33.900 --> 00:10:36.100 publish the private key of one of those two keys. 00:10:36.420 --> 00:10:41.500 Right. So either winner, both winners, have a public key attributed to them, 00:10:41.640 --> 00:10:45.720 essentially, by Reality Keys, by whoever is running this. 00:10:47.400 --> 00:10:52.260 And... based on the winner, depending on who wins, they will publish one of the 00:10:52.260 --> 00:10:53.400 corresponding private keys. 00:10:53.580 --> 00:10:57.500 Yeah, and they promised to only publish one. So in that case, Ruben and I set up 00:10:57.500 --> 00:11:02.800 our little multisig with, again, two out of three, I think, the threshold, 00:11:03.140 --> 00:11:05.820 one key of you, one key of me, and then... 00:11:07.760 --> 00:11:12.400 The Germany key, I guess, would send it to me and the Netherlands key would send 00:11:12.400 --> 00:11:14.160 it to you. It's a little bit more complicated. 00:11:14.660 --> 00:11:18.700 Well, essentially, I guess you would set up two out of three multisigs, right? 00:11:18.840 --> 00:11:23.600 You can do, well, you can make it a two of two where one is my key plus the 00:11:23.600 --> 00:11:27.120 Netherlands key and the other key is Sjors plus the Germany key. 00:11:27.220 --> 00:11:28.280 That also makes sense, yeah. 00:11:28.480 --> 00:11:33.240 But the thing is that Reality Keys doesn't care. They're just going to issue the 00:11:33.240 --> 00:11:37.910 key, and we get to deal with that key whatever we want. So we can set it up in 00:11:37.910 --> 00:11:40.710 any way that we like, but that would be a plausible way for it. 00:11:40.730 --> 00:11:44.770 Yeah, I guess we put the money into the multisig and then we take it out. We have 00:11:44.770 --> 00:11:49.250 two different pre-signed transactions, right? One that takes it out or something like that. 00:11:49.270 --> 00:11:54.850 Yeah, you probably want two out of three where the third key is you and me 00:11:54.850 --> 00:11:58.950 together. So, well, no, that might also not make sense. Yeah, I'm not sure. But 00:11:58.950 --> 00:12:03.670 anyway, you need to have a fallback for if Reality Keys doesn't issue any key 00:12:03.670 --> 00:12:07.490 whatsoever. So you need to take that into account as well, which we didn't thus far. 00:12:07.570 --> 00:12:12.310 And there's another problem that they might actually reveal both keys, which is a 00:12:12.310 --> 00:12:16.970 problem. And that's not a problem in the first situation because they're just 00:12:16.970 --> 00:12:21.010 putting the signature. I guess they could also just sign two transactions. Then 00:12:21.010 --> 00:12:23.340 you have to fight over it, with, you know, replaced by fee. 00:12:23.560 --> 00:12:27.740 Well, yeah, you could have two bets with the interactive Oracle and it could 00:12:27.740 --> 00:12:30.860 resolve those two bets in a different way, right? Even though there's one 00:12:30.860 --> 00:12:31.480 outcome. 00:12:32.260 --> 00:12:35.640 I think we're botching this. I think the simple solution would be to have three 00:12:35.640 --> 00:12:40.480 out of four, right? And then you both sign. Am I saying this right? What's the 00:12:40.480 --> 00:12:41.240 solution there, Ruben? 00:12:42.260 --> 00:12:45.820 There has to be a different result depending on which public key gets published. 00:12:46.100 --> 00:12:46.460 Yeah. 00:12:46.640 --> 00:12:51.350 If it's just three out of four, the script doesn't care which three. So it would 00:12:51.350 --> 00:12:55.790 just send the money to one person regardless of who wins. So you need to think 00:12:55.790 --> 00:12:56.510 about this a little bit. 00:12:56.750 --> 00:12:57.770 Two out of four, I think. 00:12:58.620 --> 00:12:58.860 Anyway. 00:13:00.280 --> 00:13:01.560 Two out of four, that makes sense. 00:13:01.560 --> 00:13:03.460 I think that works. I think I sold it. 00:13:03.780 --> 00:13:04.480 That's the one. 00:13:04.760 --> 00:13:04.960 Okay. 00:13:05.420 --> 00:13:10.360 All right, we figure it out. Two out of four. However, we're still not... So 00:13:10.360 --> 00:13:12.300 yeah, to clarify two out of four because... 00:13:12.300 --> 00:13:15.940 Then Oracle can steal though. There's still a problem. Oh yeah. 00:13:16.400 --> 00:13:20.580 It sounded very simple on paper until we started to actually figure this out live 00:13:20.580 --> 00:13:21.240 on the podcast. 00:13:22.200 --> 00:13:25.900 Yeah, the platform is down. You can't really test it anymore. But what was 00:13:25.900 --> 00:13:29.200 interesting about the platform is that it actually worked with APIs. So it was 00:13:29.200 --> 00:13:33.280 just connected to a bunch of APIs. And you could then just tell it to pay 00:13:33.280 --> 00:13:37.900 attention to that API and publish a key depending on an event from that API. So 00:13:37.900 --> 00:13:42.840 it was semi-automated in that regard. So it was kind of a nifty little platform 00:13:42.840 --> 00:13:47.740 that I think is very similar. But one sort of downside, I think, to that platform 00:13:47.740 --> 00:13:52.320 that we're going to address as well is that it was mostly centered around binary 00:13:52.320 --> 00:13:53.260 bets, right? 00:13:54.640 --> 00:13:58.600 Either one party or the other party is going to win or the price of Bitcoin is 00:13:58.600 --> 00:14:04.100 going to be X at this date, things like that. But so not very, you wouldn't have 00:14:04.100 --> 00:14:08.620 these kind of bets with a granular outcome where depending on the price, I get 00:14:08.620 --> 00:14:11.400 this amount of Bitcoin and Sjors gets some other amount of Bitcoin. 00:14:11.780 --> 00:14:15.800 Right. And especially when you're talking about, say, the US dollar price, if 00:14:15.800 --> 00:14:19.140 that's what you're betting on, then it could be have all sorts of numbers 00:14:19.140 --> 00:14:20.500 involved. Okay. 00:14:21.120 --> 00:14:25.120 So anyways, Reality Keys. I don't understand how it would actually work, but 00:14:25.120 --> 00:14:26.960 there's probably some way to make it work. 00:14:27.260 --> 00:14:27.840 I'm sure there's a way. 00:14:28.080 --> 00:14:31.980 Where the Oracle just publishes a private key depending on the winner. But we 00:14:31.980 --> 00:14:36.500 just discussed that as a sort of stepping stone for the actual subject of this 00:14:36.500 --> 00:14:40.520 specific podcast, which is DLCs. And that's sort of what we're getting at now, 00:14:40.680 --> 00:14:44.240 right? So who wants to give DLCs a first go? 00:14:47.000 --> 00:14:51.840 I'll start and then maybe Sjors can continue from where I begin. 00:14:52.100 --> 00:14:52.420 Right. 00:14:53.320 --> 00:14:59.280 So I think the DLC paper came from Tadge Dryja, who currently works on 00:14:59.280 --> 00:15:02.640 Utreexo, so a very interesting project as well, which I think we discussed. 00:15:03.000 --> 00:15:03.340 We have. 00:15:03.480 --> 00:15:03.640 Yeah. 00:15:04.160 --> 00:15:07.180 Also one of the co-authors of the Lightning White Paper. 00:15:07.320 --> 00:15:09.600 Yeah, and Lightning Network Paper as well. Yeah, good points. 00:15:11.140 --> 00:15:17.000 So the idea there is to basically have the bets 00:15:17.000 --> 00:15:22.200 be a channel where you lock up your funds together with a counterparty. And then 00:15:22.200 --> 00:15:26.580 from that state where you have a channel. So it's very similar to a Lightning 00:15:26.580 --> 00:15:30.180 channel, right? There's two of two, and you would have to have some kind of 00:15:30.180 --> 00:15:34.560 transaction where you can exit out of it in case you disagree or something. 00:15:34.900 --> 00:15:39.380 So hang on. In this specific case, essentially Ruben and Sjors, the two of you 00:15:39.380 --> 00:15:44.500 would open a payment channel, which looks a little bit like a Lightning channel. 00:15:44.680 --> 00:15:44.900 Yeah. 00:15:45.180 --> 00:15:46.020 Right? Okay, go on. 00:15:46.120 --> 00:15:47.280 The initial setup is the two of two. 00:15:47.280 --> 00:15:50.420 Which essentially means you're both depositing funds in this channel, right? 00:15:50.560 --> 00:15:54.860 Yes. But the way that you can get the funds out is sort of the key difference. 00:15:55.180 --> 00:16:00.880 Where now in order to get your funds out, you have a bunch of transactions that 00:16:00.880 --> 00:16:06.280 are basically bet outcomes. And so in our example, a World Cup, Netherlands 00:16:06.280 --> 00:16:11.590 versus Germany, we would have two transactions basically. One transaction 00:16:12.170 --> 00:16:17.530 would be a transaction where Sjors wins. So he can publish his version of the 00:16:17.530 --> 00:16:23.070 transaction and then he can spend that money with both his key 00:16:23.070 --> 00:16:29.030 plus the key of the oracle where the oracle says that Germany won. 00:16:29.870 --> 00:16:35.510 But then there's also a time lock because if Sjors publishes his transaction, 00:16:35.770 --> 00:16:40.870 but that transaction is actually not the one that the Oracle published, 00:16:41.150 --> 00:16:45.610 well, then basically what happens is that he can't spend it because he doesn't 00:16:45.610 --> 00:16:49.170 have both keys. He only has one of the keys. And then the time lock expires. And 00:16:49.170 --> 00:16:52.230 the time lock says that after the time lock expires, I get to take the money. 00:16:52.650 --> 00:16:58.150 Okay, so hang on. In a Lightning channel, if I'm remembering correctly, which I 00:16:58.150 --> 00:17:03.570 think I am, both of you would essentially, you've exchanged signed 00:17:03.570 --> 00:17:08.790 transactions, right? You both have a different version of the redemption 00:17:08.790 --> 00:17:10.250 transaction. Am I saying that right? 00:17:10.470 --> 00:17:11.110 Yeah, yeah. 00:17:11.250 --> 00:17:17.230 And so in this case, both of these transactions depend on the outcome of the 00:17:17.230 --> 00:17:22.720 match, essentially. So you would have the transaction that should be broadcast if 00:17:22.720 --> 00:17:27.000 the Netherlands wins, Ruben. And then Sjors has a slightly different version of 00:17:27.000 --> 00:17:32.820 an almost identical transaction that he should broadcast if Germany wins. Right? 00:17:33.120 --> 00:17:33.240 Yeah. 00:17:33.660 --> 00:17:39.550 And in both cases, if we happen to broadcast the wrong one... which, you know, we 00:17:39.550 --> 00:17:42.290 don't have to do, but then the other side can just take the... 00:17:42.290 --> 00:17:45.570 Yes, this is what Ruben was just explaining. So the Netherlands won in our 00:17:45.570 --> 00:17:51.370 example and Sjors bet on Germany. So Sjors has the transaction that he should 00:17:51.370 --> 00:17:56.870 broadcast only if Germany wins, but he broadcasts it anyways. The reason he can't 00:17:56.870 --> 00:18:02.250 actually claim the funds is because he needs something from the Oracle in 00:18:02.250 --> 00:18:05.910 combination with his own signature in order to actually claim the funds, right? 00:18:06.310 --> 00:18:06.430 Yes. 00:18:06.370 --> 00:18:11.990 So he— because he can't do that now a time lock is ticking, yeah, it's going to 00:18:11.990 --> 00:18:16.110 clock out at which point the money is sent to you Ruben. 00:18:16.110 --> 00:18:16.410 Yes. 00:18:16.350 --> 00:18:21.910 So that's sort of a strong disincentive for Sjors to try to claim the money even 00:18:21.910 --> 00:18:22.690 though he didn't win. 00:18:22.850 --> 00:18:23.230 Yes. 00:18:23.430 --> 00:18:24.510 Okay, so this... 00:18:24.430 --> 00:18:28.350 It's useful to know here that a transaction has inputs and outputs and so the 00:18:28.350 --> 00:18:32.850 transaction that both of the transactions that go out of this pot that we put the 00:18:32.850 --> 00:18:38.330 money in or this channel both of them have the same inputs so both of us can just 00:18:38.330 --> 00:18:42.160 throw it on the chain because they you know. But the outputs are different. And 00:18:42.160 --> 00:18:45.640 so we need another transaction to actually take the money to really own it. And 00:18:45.640 --> 00:18:47.560 that's where the Oracle signature comes in. 00:18:47.860 --> 00:18:51.800 Right. So let me ask about it. So the Netherlands won. Ruben, you bet on the Netherlands. 00:18:52.040 --> 00:18:52.140 Yeah. 00:18:52.300 --> 00:18:55.600 So we just gave the example where Sjors is trying to cheat. Let's forget about 00:18:55.600 --> 00:18:58.840 that. Now you're just broadcasting the legitimate transaction. 00:18:59.100 --> 00:18:59.260 Yeah. 00:18:59.620 --> 00:19:05.420 Which requires now a signature from you. As well as what's the other 00:19:05.420 --> 00:19:06.080 thing exactly? 00:19:06.420 --> 00:19:10.480 Yeah. So really what it is, and we have to go into more detail here, but 00:19:10.480 --> 00:19:15.700 essentially it is two keys. One is mine and the other key comes from the Oracle. 00:19:16.940 --> 00:19:20.500 Wait, wait, wait. You're saying key. Do you mean key or do you mean signature? 00:19:20.720 --> 00:19:26.140 I mean an actual key. Yeah. So when I send my transaction to the Bitcoin 00:19:26.140 --> 00:19:30.860 blockchain, there's going to be an output and the output is encumbered by a key. 00:19:31.260 --> 00:19:35.740 And that key is the combination of my key and a key that is provided by the Oracle. 00:19:37.070 --> 00:19:42.210 And I basically take both keys. When the Oracle reveals his private key, 00:19:42.410 --> 00:19:47.570 I get that private key. I combine it with my private key. And that combined 00:19:47.570 --> 00:19:51.750 number is what I use to sign the transaction and then actually take the money. 00:19:52.010 --> 00:19:55.270 And I have to do that because if I don't do that, then the time lock expires and 00:19:55.270 --> 00:19:56.070 Sjors gets to take it. 00:19:56.040 --> 00:19:59.220 Yeah, to go back to that encumbering it's, it's encumbered, of course, by the 00:19:59.220 --> 00:20:03.860 public key. Well, it's encumbered by… So it's basically saying anybody with this 00:20:03.860 --> 00:20:08.180 public key can spend it and this public key happens to be your public key plus a 00:20:08.180 --> 00:20:11.360 public key that we have pre-computed that belongs to the Oracle. 00:20:11.780 --> 00:20:12.140 Yeah. 00:20:13.820 --> 00:20:17.800 And this is sort of where the magic comes in because it's not the same as the 00:20:17.800 --> 00:20:22.260 previous mechanism. The Oracle is not actually publishing a private key like a 00:20:22.260 --> 00:20:23.280 private key that holds funds. 00:20:25.030 --> 00:20:30.050 But we're actually getting it from the signature. And this is kind of where 00:20:30.050 --> 00:20:35.690 things get a little funky, because a signature is really two numbers. 00:20:36.210 --> 00:20:41.970 It is essentially a public key, or it's not a public key, but it's a point, a 00:20:41.970 --> 00:20:47.760 point on the elliptic curve, and it is a number. And in general, 00:20:48.080 --> 00:20:52.200 when you have a number, you can treat that as a private key. And when you have a 00:20:52.200 --> 00:20:55.680 point, you can treat that as a public key. And the reason is that you can very 00:20:55.680 --> 00:21:00.270 easily go from a number to a point. but you cannot go from a point to the 00:21:00.270 --> 00:21:05.210 corresponding number. So that's why the private key is the number and the point 00:21:05.210 --> 00:21:06.770 is the public key. 00:21:08.400 --> 00:21:11.600 But in the case of the signature, we don't interpret it that way. So we're seeing 00:21:11.600 --> 00:21:16.580 a point and we're seeing a number, but we can if we want to, and that's actually 00:21:16.580 --> 00:21:21.460 what we're doing here. So we're interpreting the second part of the signature, 00:21:21.740 --> 00:21:26.630 which is a number. We're interpreting that as a private key. And that is the 00:21:26.630 --> 00:21:31.590 private key that we're missing. And now the nice thing is that the Oracle can 00:21:31.590 --> 00:21:37.010 sign anything, really. They can publish any signature they want. And depending on 00:21:37.010 --> 00:21:41.900 exactly what message they sign, we're going to get a different private key in 00:21:41.960 --> 00:21:42.460 that signature. 00:21:43.760 --> 00:21:49.330 And so if they publish Germany, then I get a private key. 00:21:49.570 --> 00:21:53.270 Then that private key that the Oracle just published is useful for me. It allows 00:21:53.270 --> 00:21:58.190 me to redeem the coins. If the oracle wrote Germany in the message, then Ruben 00:21:58.190 --> 00:22:02.510 gets the private key that is useful for him and of no use to me. 00:22:03.710 --> 00:22:09.690 And to make it even nicer is if they publish both, well, now we can actually 00:22:09.690 --> 00:22:15.570 punish the oracle because the oracle also has its own private key. 00:22:15.730 --> 00:22:20.240 And by this, I mean the real private key that he would use to protect his own 00:22:20.240 --> 00:22:24.170 funds. And that now becomes known. Because there's a rule that if you publish, 00:22:24.350 --> 00:22:29.230 basically, if you make two, if you sign two different messages this way, you're 00:22:29.230 --> 00:22:30.650 giving away your private key. 00:22:31.010 --> 00:22:35.330 Yeah, that's exactly right. So maybe to sort of give a... 00:22:35.330 --> 00:22:37.130 But that's maybe a little bit tangential. 00:22:37.450 --> 00:22:43.430 Yeah, to give sort of a high-level summary here is that basically we just 00:22:43.430 --> 00:22:48.330 get the Oracle to pre-commit to what it's going to sign. So it's going to say 00:22:48.330 --> 00:22:53.770 like, look, I'm going to sign either Germany or the Netherlands. And we 00:22:53.770 --> 00:22:59.490 calculate ahead of time what that signature is going to look like. And we use 00:22:59.490 --> 00:23:03.430 that in our scripts, in our transactions. 00:23:03.670 --> 00:23:06.450 Well, you can know what the signature will look like exactly, right? 00:23:06.550 --> 00:23:08.930 No, we know one part of that signature, what it's going to look like. 00:23:09.070 --> 00:23:14.650 Yeah, we know sort of, we know the, as Sjors stated, you can treat the signature 00:23:14.650 --> 00:23:18.710 as a key. And so we know the public key, but we don't know the private key, 00:23:18.890 --> 00:23:24.450 basically, of the signature. So we treat the signature as a key. And we only know 00:23:24.450 --> 00:23:28.390 the public key. We don't know the private key until the Oracle actually signs. 00:23:32.970 --> 00:23:37.410 All right, well, I didn't get all of that. Maybe some of our listeners did. I do 00:23:37.410 --> 00:23:43.370 want to, at the risk of confusing our listeners even more, I actually want to 00:23:43.370 --> 00:23:48.130 take one step back. So we were discussing this Reality Keys idea where the Oracle 00:23:48.130 --> 00:23:53.510 would just publish a private key. Why can't we just use that in this setup? So 00:23:53.510 --> 00:23:57.930 the Netherlands won, Ruben, you're now publishing your transaction that allowed 00:23:57.930 --> 00:24:03.550 you to withdraw the funds, which... requires your signature. And why don't we 00:24:03.550 --> 00:24:09.150 just say it also requires a signature from a private key, which is for the 00:24:09.150 --> 00:24:09.810 [unclear] specifically. 00:24:10.090 --> 00:24:10.390 Yeah. 00:24:10.610 --> 00:24:14.650 Like we were speaking out loud where we were at that step of the podcast and we 00:24:14.650 --> 00:24:17.790 were budging it, but this actually seems to make sense to me. Like this would 00:24:17.790 --> 00:24:18.750 actually work, right? Yeah. 00:24:18.990 --> 00:24:23.050 So I think the first thing to point out is that, yes, that works. So if you're 00:24:23.050 --> 00:24:26.030 confused about everything that we said, you can just think of it in that way. 00:24:26.230 --> 00:24:26.450 Right. 00:24:26.610 --> 00:24:31.270 So that's, I think, like the first point. Second point is there are two subtle 00:24:31.270 --> 00:24:36.230 differences. And the first difference is what Sjors explained earlier, where if 00:24:36.230 --> 00:24:42.510 the Oracle signs two things, we can punish the Oracle by extracting their private key. 00:24:42.710 --> 00:24:45.450 Right, yeah. So if... 00:24:45.840 --> 00:24:47.880 So the Oracle would say in this case... 00:24:47.880 --> 00:24:52.160 If the Oracle would publish both results for whatever reason, then there's this 00:24:52.160 --> 00:24:56.880 mathematical trick where you can combine the signatures and from there derive the 00:24:56.880 --> 00:25:02.240 actual private key from the actual Oracle. Assuming that the Oracle put up some 00:25:02.240 --> 00:25:08.040 funds there to prove that it won't cheat, that's how you're sure that the Oracle 00:25:08.040 --> 00:25:10.880 will only publish one result, right? That's the point here. 00:25:11.120 --> 00:25:11.280 Yeah. 00:25:11.680 --> 00:25:15.000 Right. And then there was another solid point I think you were going to mention, Ruben. 00:25:15.120 --> 00:25:19.100 Yeah. And the second point is sort of a smaller one that probably not everybody 00:25:19.100 --> 00:25:24.960 appreciates, but it's just less data, basically. So the Oracle can basically 00:25:24.960 --> 00:25:30.560 commit to what it's going to reveal in less data than you would 00:25:30.560 --> 00:25:35.760 need if you would create a public key for every bet event. 00:25:35.980 --> 00:25:38.960 Well, and this becomes especially important if you're doing something like 00:25:38.960 --> 00:25:42.380 predicting the price of the US dollar in Bitcoin. Because you might want to 00:25:42.380 --> 00:25:46.200 publish a six-digit number. And that means, you know, hundreds of thousands of 00:25:46.200 --> 00:25:49.940 public keys that you would have to publish for each possible value. And you'd 00:25:49.940 --> 00:25:52.560 have to pre-sign transactions for each of these possible values. 00:25:52.840 --> 00:25:58.000 Yeah. Well, not necessarily because you can do it in binary, which makes it a lot less. 00:25:58.160 --> 00:25:58.900 I guess we'll get to that. 00:25:58.980 --> 00:26:00.420 We'll get to that later. Yes. 00:26:00.940 --> 00:26:06.180 Okay. So maybe... Fun to just dive into a little bit more detail for those who do 00:26:06.180 --> 00:26:08.180 understand the math better than we. 00:26:10.540 --> 00:26:15.020 Do we? Yeah, so there's a couple of things that the Oracle publishes or that are 00:26:15.020 --> 00:26:20.120 known here. If you look at what a signature is, it's like an equation, 00:26:20.140 --> 00:26:24.120 essentially. If I can read it out loud, you have on the left side of the 00:26:24.120 --> 00:26:29.700