Discreet Log Contracts - Episode 53

Aaron van Wirdum Live from Utrecht, this is Bitcoin Explained.

Sjors Provoost Hello.

Aaron van Wirdum Hey, Sjors.

Sjors Provoost What's up?

Aaron van Wirdum I'm good. And welcome back, Ruben.

Ruben Somsen Thank you. Good to be back.

Aaron van Wirdum Back-to-back episodes for you?

Ruben Somsen Yeah, sure. Almost. Or has there not been an episode in between? I don't even know.

Aaron van Wirdum We skipped last one. So yeah, no, it's truly back-to-back for you this time.

Ruben Somsen All right, cool.

Aaron van Wirdum Happy you are back because we're going to discuss a particularly... interesting and at least in my opinion, pretty complex topic. We did have a, we had a call the three of us before we started recording this, this afternoon, and uh, it was basically a call between the two of you because I tapped out after like a minute and especially when it became mathematical, when the mathematics came into play, that's where it went a little bit over my head. So let's see how we can manage this episode today.

Sjors Provoost Yeah, for me, it was also just confusing initially, especially reading some of the documentation that explains some of the assumptions behind it and then just skips all the details that I care about to actually understand it. It's not the full math, but it's like, ah, tell me one more thing, tell me one more thing. But then if you're listening to a high-level talk by somebody who's not trying to make it technical, they're not filling out the details. And then if you want to read... an actual spec gets too technical.

Aaron van Wirdum So the thing we are going to discuss is Discreet log contracts, also known as DLCs.

Sjors Provoost Yeah, and it's spelled discreet E-E-T, which kind of means careful in what you're saying, versus discrete with E-T-E, which is single digits, like a discrete number. But it's a pun. Yeah, you cannot say in audio because it sounds the same.

Ruben Somsen I think the end result is that people are just confused, but it's a, it's funny for those who are in the know.

Aaron van Wirdum Yeah, anyway, so let's start with a short summary of what Discreet long—log contracts actually are. I would summarize it as there are, they are essentially smart contracts for Bitcoin and a little bit more specifically they are bets, essentially. Yeah. And the interesting thing about bets is that many types of financial contracts are essentially bets, even if we don't normally think of them as bets. You, you can sort of distill them as bets

Sjors Provoost like, right, they're not gambling necessarily. They could just be saying I think the dollar is going to go up, uh, so I want a derivative project, uh, product that follows the dollar price and you could call that betting, but it's, it's, it's a sane thing to do even as, as a non-gambler

Aaron van Wirdum Yeah, yeah, exactly. Or like an insurance, if you, if you're insuring your house in a way you're sort of betting that your house will burn down. And then if you lose the bet and you didn't, your house is still there, you're kind of happy, but it did cost a little bit of money. So that's sort of the down payment. Well, if your house burns down, you win the bet and you get all this money. So a lot of financial products are essentially bets. So that's why it's interesting to think of how can we bring this sort of betting to Bitcoin. And then what we really want or, you know, the essence of smart contracts, what smart contracts are ideally at least, is that these bets are executed automatically, right?

Sjors Provoost Yes. And in the case of blockchain, not just automatically, but also in a way that does not require any trust. Now, just a spoiler. There is this thing called the Oracle problem. And we are not solving the Oracle problem. The Oracle problem basically means that if you have anything that relies on information outside the blockchain, well, anything except the knowledge of a private key or hash, If you need any kind of information from outside the blockchain, like the weather or the dollar price, there has to be an oracle that knows this thing. And the blockchain has no idea if the oracle is lying or not. And we're not going to solve that. So everything we're doing here still assumes that the oracle is honest. And then there are some tricks that you can use to make it slightly more honest. But it's not a perfect solution.

Aaron van Wirdum Well, that is kind of what we're doing, right? We're sort of trying to minimize the trust in the Oracle or at least a little bit.

Sjors Provoost Well, we're also trying to reduce the workload for the Oracle, and increase the plausible deniability for the oracle.

Ruben Somsen Yeah, that's I think an important point where the oracle doesn't have to be directly involved with your bets. It can just post the outcome and then you take the outcome and you resolve your bets with that outcome without the oracle specifically having to know that you were even betting.

Sjors Provoost Right, and that also makes the oracle hopefully more neutral. So again, you cannot guarantee that.

Ruben Somsen Yeah.

Aaron van Wirdum Okay, so... Before we get into it, let's pick a very nice and easy sort of bet that everyone will understand is a bet.

Sjors Provoost If it's going to rain tomorrow.

Aaron van Wirdum I don't like that one.

Sjors Provoost Especially because the answer tends to be yes here.

Aaron van Wirdum Let's go for the World Cup final. We'll have the World Cup later this year. Let's assume the World Cup final is the Netherlands versus Germany, and now we're gonna bet on the winner of the World Cup final. Yeah, all right.

Sjors Provoost Yeah, all right. Trivial, but yeah.

Aaron van Wirdum That will be the bet throughout this episode.

Ruben Somsen Obviously, the Netherlands is gonna win, but okay.

Aaron van Wirdum The Netherlands versus Germany. All right, in the World Cup final. So the very— let's start at the beginning. We want to solve this problem, um, Ruben and Sjors, you want to bet against each other. Ruben, you're betting on the Netherlands apparently. Sjors, you're betting on Germany. Now we need to make this trustless somehow. I think the most basic solution is to create a multisig. Well, you could create a multisig between the two of you, two of two, but then you have the obvious problem that the loser might not cooperate, right?

Ruben Somsen Yeah.

Aaron van Wirdum So if we take the next step... we'll take it one step further. We'll introduce the oracle that's gonna be me. Both of you trust me. So now we create a two out of three multisig and now the final has been played. The Netherlands has won at this point. Either Sjors can cooperate with Ruben to get all the money in the multisig to Ruben, or if Sjors doesn't cooperate, then Ruben can contact me. I'll step in. I'll acknowledge that the Netherlands won the final. So I'll provide my signature and I'll help Ruben get the money. Now, because I can do this, and because both of you know I can do this, and Sjors in particular, you know for a fact that I can do this. So at this point, there's really no reason for you to obstruct. You might as well just cooperate, right?

Sjors Provoost Yeah, exactly. And so this could just be a trusted friend or this could be the actual organization that runs the soccer match that has no reason to lie about the result and is subject to some scrutiny. But the problem is then, of course, if you want to do a contract with this World Cup organizer, you know... You need to involve them. They actually need to sign something specifically for you. And they may not want to do that because, hey, then they're cooperating with sports betting. Or they don't feel like doing that. I don't know.

Aaron van Wirdum Yeah, what you're saying is that there are a number of problems with this solution. One of them is it requires me to actually be actively involved in your bet, even before the bet is made. I need to provide my public key and I sort of need to know what you guys are doing and I need to agree with that. And then after the bet, you might need my help and I might do stuff. If it's just two of you, that's maybe acceptable, but now tens of thousands of people want to make the same bet, and I would have to provide my public key to tens of thousands of people, and now it starts to become a lot of work, right?

Sjors Provoost And they don't even know what you exactly are betting, right? So they would have to read the terms and conditions of each of your bets to even know which side to have to sign. Because you can't tell by the public key which side I, Ruben, bet it on. So yeah, it's pretty tedious.

Aaron van Wirdum Yeah, and then there's the problem that I need to know what you guys are doing, which is sort of bad for your privacy. I need to know which coins are yours and what they're used for. Are there more problems?

Ruben Somsen Well, I think you summed it up pretty well.

Sjors Provoost That said, I think it's possible. It's not impossible.

Aaron van Wirdum Yeah. Obviously, I could try to cheat by, for example, Sjors could try to bribe me. He could contact me, say, hey, Aaron, let's share the prize and forget about Ruben. Let's share the prize between us. And, you know, I could be corrupted in this way. It's not a problem. Lots of problems with this solution, even though it technically works.

Sjors Provoost Yes.

Ruben Somsen I will say there's an upside to it as well, which is that if the bet somehow is unclear or I don't know, there's a meteor crashes on earth and the finals are canceled. And now we're like, oh, what are we going to do with our bets? Then you being a human, you can maybe, you know, sort of have, you can make a decision on our behalf. That's maybe one small advantage, but I don't think it's a great one.

Sjors Provoost Okay, method two. Method one.

Aaron van Wirdum Yeah, so let's try to improve on this solution. Sjors, you wanted to improve on the solution.

Sjors Provoost Yes. So today I learned about a concept, which I had not followed, and it's called Reality Keys.

Ruben Somsen Yeah.

Sjors Provoost And this is actually a pretty simple idea. It takes it one step further.

Aaron van Wirdum This is an existing thing.

Ruben Somsen It was an existing thing.

Aaron van Wirdum This was an existing thing.

Ruben Somsen It existed between 2014 and 2018, and it just disappeared. And I don't think a lot of Bitcoiners remember, but it was actually kind of a really awesome little platform.

Sjors Provoost But the general idea still exists. Of course, you can do this. So what the World Cup leaders in this case probably, they would be the Oracle, what they would do is they would say, here is two public keys. Public key A, or public key N, I guess, and public key D, as in the Netherlands public key and the Germany public key. And depending on who wins, we will publish one of those keys. We will publish the private key of one of those two keys.

Aaron van Wirdum Right. So either winner, both winners, have a public key attributed to them, essentially, by Reality Keys, by whoever is running this. And... based on the winner, depending on who wins, they will publish one of the corresponding private keys.

Sjors Provoost Yeah, and they promised to only publish one. So in that case, Ruben and I set up our little multisig with, again, two out of three, I think, the threshold, one key of you, one key of me, and then... The Germany key, I guess, would send it to me and the Netherlands key would send it to you. It's a little bit more complicated.

Aaron van Wirdum Well, essentially, I guess you would set up two out of three multisigs, right?

Ruben Somsen You can do, well, you can make it a two of two where one is my key plus the Netherlands key and the other key is Sjors plus the Germany key.

Aaron van Wirdum That also makes sense, yeah.

Ruben Somsen But the thing is that Reality Keys doesn't care. They're just going to issue the key, and we get to deal with that key whatever we want. So we can set it up in any way that we like, but that would be a plausible way for it.

Sjors Provoost Yeah, I guess we put the money into the multisig and then we take it out. We have two different pre-signed transactions, right? One that takes it out or something like that.

Ruben Somsen Yeah, you probably want two out of three where the third key is you and me together. So, well, no, that might also not make sense. Yeah, I'm not sure. But anyway, you need to have a fallback for if Reality Keys doesn't issue any key whatsoever. So you need to take that into account as well, which we didn't thus far.

Sjors Provoost And there's another problem that they might actually reveal both keys, which is a problem. And that's not a problem in the first situation because they're just putting the signature. I guess they could also just sign two transactions. Then you have to fight over it, with, you know, replaced by fee.

Ruben Somsen Well, yeah, you could have two bets with the interactive Oracle and it could resolve those two bets in a different way, right? Even though there's one outcome.

Aaron van Wirdum I think we're botching this. I think the simple solution would be to have three out of four, right? And then you both sign. Am I saying this right? What's the solution there, Ruben?

Sjors Provoost There has to be a different result depending on which public key gets published.

Aaron van Wirdum Yeah.

Sjors Provoost If it's just three out of four, the script doesn't care which three. So it would just send the money to one person regardless of who wins. So you need to think about this a little bit.

Ruben Somsen Two out of four, I think.

Sjors Provoost Anyway.

Aaron van Wirdum Two out of four, that makes sense.

Ruben Somsen I think that works. I think I sold it.

Aaron van Wirdum That's the one.

Ruben Somsen Okay.

Aaron van Wirdum All right, we figure it out. Two out of four. However, we're still not... So yeah, to clarify two out of four because...

Ruben Somsen Then Oracle can steal though. There's still a problem. Oh yeah.

Aaron van Wirdum It sounded very simple on paper until we started to actually figure this out live on the podcast.

Ruben Somsen Yeah, the platform is down. You can't really test it anymore. But what was interesting about the platform is that it actually worked with APIs. So it was just connected to a bunch of APIs. And you could then just tell it to pay attention to that API and publish a key depending on an event from that API. So it was semi-automated in that regard. So it was kind of a nifty little platform that I think is very similar. But one sort of downside, I think, to that platform that we're going to address as well is that it was mostly centered around binary bets, right? Either one party or the other party is going to win or the price of Bitcoin is going to be X at this date, things like that. But so not very, you wouldn't have these kind of bets with a granular outcome where depending on the price, I get this amount of Bitcoin and Sjors gets some other amount of Bitcoin.

Sjors Provoost Right. And especially when you're talking about, say, the US dollar price, if that's what you're betting on, then it could be have all sorts of numbers involved. Okay.

Aaron van Wirdum So anyways, Reality Keys. I don't understand how it would actually work, but there's probably some way to make it work.

Ruben Somsen I'm sure there's a way.

Aaron van Wirdum Where the Oracle just publishes a private key depending on the winner. But we just discussed that as a sort of stepping stone for the actual subject of this specific podcast, which is DLCs. And that's sort of what we're getting at now, right? So who wants to give DLCs a first go?

Ruben Somsen I'll start and then maybe Sjors can continue from where I begin.

Aaron van Wirdum Right.

Ruben Somsen So I think the DLC paper came from Tadge Dryja, who currently works on Utreexo, so a very interesting project as well, which I think we discussed.

Sjors Provoost We have.

Ruben Somsen Yeah.

Aaron van Wirdum Also one of the co-authors of the Lightning White Paper.

Ruben Somsen Yeah, and Lightning Network Paper as well. Yeah, good points. So the idea there is to basically have the bets be a channel where you lock up your funds together with a counterparty. And then from that state where you have a channel. So it's very similar to a Lightning channel, right? There's two of two, and you would have to have some kind of transaction where you can exit out of it in case you disagree or something.

Aaron van Wirdum So hang on. In this specific case, essentially Ruben and Sjors, the two of you would open a payment channel, which looks a little bit like a Lightning channel.

Ruben Somsen Yeah.

Aaron van Wirdum Right? Okay, go on.

Ruben Somsen The initial setup is the two of two.

Aaron van Wirdum Which essentially means you're both depositing funds in this channel, right?

Ruben Somsen Yes. But the way that you can get the funds out is sort of the key difference. Where now in order to get your funds out, you have a bunch of transactions that are basically bet outcomes. And so in our example, a World Cup, Netherlands versus Germany, we would have two transactions basically. One transaction would be a transaction where Sjors wins. So he can publish his version of the transaction and then he can spend that money with both his key plus the key of the oracle where the oracle says that Germany won. But then there's also a time lock because if Sjors publishes his transaction, but that transaction is actually not the one that the Oracle published, well, then basically what happens is that he can't spend it because he doesn't have both keys. He only has one of the keys. And then the time lock expires. And the time lock says that after the time lock expires, I get to take the money.

Aaron van Wirdum Okay, so hang on. In a Lightning channel, if I'm remembering correctly, which I think I am, both of you would essentially, you've exchanged signed transactions, right? You both have a different version of the redemption transaction. Am I saying that right?

Ruben Somsen Yeah, yeah.

Aaron van Wirdum And so in this case, both of these transactions depend on the outcome of the match, essentially. So you would have the transaction that should be broadcast if the Netherlands wins, Ruben. And then Sjors has a slightly different version of an almost identical transaction that he should broadcast if Germany wins. Right?

Ruben Somsen Yeah.

Sjors Provoost And in both cases, if we happen to broadcast the wrong one... which, you know, we don't have to do, but then the other side can just take the...

Aaron van Wirdum Yes, this is what Ruben was just explaining. So the Netherlands won in our example and Sjors bet on Germany. So Sjors has the transaction that he should broadcast only if Germany wins, but he broadcasts it anyways. The reason he can't actually claim the funds is because he needs something from the Oracle in combination with his own signature in order to actually claim the funds, right?

Ruben Somsen Yes.

Aaron van Wirdum So he— because he can't do that now a time lock is ticking, yeah, it's going to clock out at which point the money is sent to you Ruben.

Ruben Somsen Yes.

Aaron van Wirdum So that's sort of a strong disincentive for Sjors to try to claim the money even though he didn't win.

Ruben Somsen Yes.

Aaron van Wirdum Okay, so this...

Sjors Provoost It's useful to know here that a transaction has inputs and outputs and so the transaction that both of the transactions that go out of this pot that we put the money in or this channel both of them have the same inputs so both of us can just throw it on the chain because they you know. But the outputs are different. And so we need another transaction to actually take the money to really own it. And that's where the Oracle signature comes in.

Aaron van Wirdum Right. So let me ask about it. So the Netherlands won. Ruben, you bet on the Netherlands.

Ruben Somsen Yeah.

Aaron van Wirdum So we just gave the example where Sjors is trying to cheat. Let's forget about that. Now you're just broadcasting the legitimate transaction.

Ruben Somsen Yeah.

Aaron van Wirdum Which requires now a signature from you. As well as what's the other thing exactly?

Ruben Somsen Yeah. So really what it is, and we have to go into more detail here, but essentially it is two keys. One is mine and the other key comes from the Oracle.

Aaron van Wirdum Wait, wait, wait. You're saying key. Do you mean key or do you mean signature?

Ruben Somsen I mean an actual key. Yeah. So when I send my transaction to the Bitcoin blockchain, there's going to be an output and the output is encumbered by a key. And that key is the combination of my key and a key that is provided by the Oracle. And I basically take both keys. When the Oracle reveals his private key, I get that private key. I combine it with my private key. And that combined number is what I use to sign the transaction and then actually take the money. And I have to do that because if I don't do that, then the time lock expires and Sjors gets to take it.

Sjors Provoost Yeah, to go back to that encumbering it's, it's encumbered, of course, by the public key. Well, it's encumbered by… So it's basically saying anybody with this public key can spend it and this public key happens to be your public key plus a public key that we have pre-computed that belongs to the Oracle.

Ruben Somsen Yeah.

Sjors Provoost And this is sort of where the magic comes in because it's not the same as the previous mechanism. The Oracle is not actually publishing a private key like a private key that holds funds. But we're actually getting it from the signature. And this is kind of where things get a little funky, because a signature is really two numbers. It is essentially a public key, or it's not a public key, but it's a point, a point on the elliptic curve, and it is a number. And in general, when you have a number, you can treat that as a private key. And when you have a point, you can treat that as a public key. And the reason is that you can very easily go from a number to a point. but you cannot go from a point to the corresponding number. So that's why the private key is the number and the point is the public key. But in the case of the signature, we don't interpret it that way. So we're seeing a point and we're seeing a number, but we can if we want to, and that's actually what we're doing here. So we're interpreting the second part of the signature, which is a number. We're interpreting that as a private key. And that is the private key that we're missing. And now the nice thing is that the Oracle can sign anything, really. They can publish any signature they want. And depending on exactly what message they sign, we're going to get a different private key in that signature. And so if they publish Germany, then I get a private key. Then that private key that the Oracle just published is useful for me. It allows me to redeem the coins. If the oracle wrote Germany in the message, then Ruben gets the private key that is useful for him and of no use to me. And to make it even nicer is if they publish both, well, now we can actually punish the oracle because the oracle also has its own private key. And by this, I mean the real private key that he would use to protect his own funds. And that now becomes known. Because there's a rule that if you publish, basically, if you make two, if you sign two different messages this way, you're giving away your private key.

Ruben Somsen Yeah, that's exactly right. So maybe to sort of give a...

Sjors Provoost But that's maybe a little bit tangential.

Ruben Somsen Yeah, to give sort of a high-level summary here is that basically we just get the Oracle to pre-commit to what it's going to sign. So it's going to say like, look, I'm going to sign either Germany or the Netherlands. And we calculate ahead of time what that signature is going to look like. And we use that in our scripts, in our transactions.

Aaron van Wirdum Well, you can know what the signature will look like exactly, right?

Sjors Provoost No, we know one part of that signature, what it's going to look like.

Ruben Somsen Yeah, we know sort of, we know the, as Sjors stated, you can treat the signature as a key. And so we know the public key, but we don't know the private key, basically, of the signature. So we treat the signature as a key. And we only know the public key. We don't know the private key until the Oracle actually signs.

Aaron van Wirdum All right, well, I didn't get all of that. Maybe some of our listeners did. I do want to, at the risk of confusing our listeners even more, I actually want to take one step back. So we were discussing this Reality Keys idea where the Oracle would just publish a private key. Why can't we just use that in this setup? So the Netherlands won, Ruben, you're now publishing your transaction that allowed you to withdraw the funds, which... requires your signature. And why don't we just say it also requires a signature from a private key, which is for the [unclear] specifically.

Ruben Somsen Yeah.

Aaron van Wirdum Like we were speaking out loud where we were at that step of the podcast and we were budging it, but this actually seems to make sense to me. Like this would actually work, right? Yeah.

Ruben Somsen So I think the first thing to point out is that, yes, that works. So if you're confused about everything that we said, you can just think of it in that way.

Aaron van Wirdum Right.

Ruben Somsen So that's, I think, like the first point. Second point is there are two subtle differences. And the first difference is what Sjors explained earlier, where if the Oracle signs two things, we can punish the Oracle by extracting their private key.

Aaron van Wirdum Right, yeah. So if...

Sjors Provoost So the Oracle would say in this case...

Aaron van Wirdum If the Oracle would publish both results for whatever reason, then there's this mathematical trick where you can combine the signatures and from there derive the actual private key from the actual Oracle. Assuming that the Oracle put up some funds there to prove that it won't cheat, that's how you're sure that the Oracle will only publish one result, right? That's the point here.

Ruben Somsen Yeah.

Aaron van Wirdum Right. And then there was another solid point I think you were going to mention, Ruben.

Ruben Somsen Yeah. And the second point is sort of a smaller one that probably not everybody appreciates, but it's just less data, basically. So the Oracle can basically commit to what it's going to reveal in less data than you would need if you would create a public key for every bet event.

Sjors Provoost Well, and this becomes especially important if you're doing something like predicting the price of the US dollar in Bitcoin. Because you might want to publish a six-digit number. And that means, you know, hundreds of thousands of public keys that you would have to publish for each possible value. And you'd have to pre-sign transactions for each of these possible values.

Ruben Somsen Yeah. Well, not necessarily because you can do it in binary, which makes it a lot less.

Sjors Provoost I guess we'll get to that.

Ruben Somsen We'll get to that later. Yes.

Sjors Provoost Okay. So maybe... Fun to just dive into a little bit more detail for those who do understand the math better than we. Do we? Yeah, so there's a couple of things that the Oracle publishes or that are known here. If you look at what a signature is, it's like an equation, essentially. If I can read it out loud, you have on the left side of the equation, you have S times G, where S is the signature. G is the, what's it called?

Ruben Somsen Generator.

Sjors Provoost Is a generator. Now, the generator is a publicly known universal number that all of Bitcoin uses. So that's a number that everybody knows. So we only have one unknown thing on the left side.

Ruben Somsen Yeah.

Sjors Provoost And then on the right side, we have capital R. And R is actually... something that the oracle is going to reveal before the bet. So they're going to say, this is my R. So again, we have something that we already know. Then we have...

Ruben Somsen The capital R meaning it's a curve point.

Sjors Provoost Yes. And then the next part of the equation is plus the hash of R concatenated by the message. So the message is something we already said. We don't know what the message will be, but we can enumerate all the possible messages. We can enumerate M is Germany or M is Netherlands. And we're hashing that with R and we know R. So that's all known. And then there's times P, capital P. And P is the public key of the Oracle, which they've also published. So the Oracle will say, hey, I'm a Bitcoin related Oracle. So you have to assume G is the generator as we know it in Bitcoin. Here's my public key. And by the way, this public key belongs to a Bitcoin address and there's a million dollars on it. So I'm not going to do anything bad. And here's an R that I'm going to use for this specific bet. So you have to have a new R for every bet. But in this case, if it's Netherlands, Germany, here's the R for that. And so that equation that I just read out loud really only has one real unknown, and that's lowercase s. And if you have an equation with only one unknown, well, then you're quite happy. Right?

Ruben Somsen Yeah.

Sjors Provoost Except in this case, you cannot actually derive the private key because as we said, you cannot go from a public key to a private key. So anyway, that's just to say that if you really looked at it and you had a little bit more time and you could see it in front of you, you could just see it's an equation with some unknowns and it's not that hard.

Ruben Somsen Yeah.

Sjors Provoost And so then when the oracle actually signs a message, they let you know which M they picked. That's not going to be too much of a surprise. It's going to be the Netherlands. And then it's going to actually put down the signature, and that reveals this lowercase s. That was the only missing part from our equation. And we use that to do our own signature.

Ruben Somsen Yeah.

Aaron van Wirdum Okay, so let's bring this back to the real world a little bit. We started with the example where Sjors and Ruben, the two of you, are betting on the winner of the World Cup and I was part of a multisig who would help in case one of you tried to obstruct. And then we mentioned some of the problems with that. Now we have this new solution which we just described, which I sort of get and the two of you seem to get it pretty well. So the benefits here are that the FIFA who's organizing the World Cup, they can always just publish a signed message of the winner.

Ruben Somsen Yeah.

Aaron van Wirdum And this can be used by anyone, right? So the FIFA does not need to be part of any multisig. They do not need to have any active involvement. They do not even need to know that a bet took place at all.

Ruben Somsen Yeah.

Aaron van Wirdum All they need to know is that they need to sign a message and this will allow anyone to create bets on their own accord, right?

Ruben Somsen That is correct.

Aaron van Wirdum Is that...

Sjors Provoost And optionally, they can publish, they can post a collateral that if they cheat... then they lose a collateral. But that's not essential for the algorithm.

Ruben Somsen Yeah.

Aaron van Wirdum Right. And then I think another benefit here is that if the FIFA would try to cheat for whatever reason, if they would announce the wrong winner, then that's also very obvious and publicly known to anyone. So now everyone knows we shouldn't rely on them to settle our bets for the next World Cup.

Sjors Provoost Yeah, which might be more difficult to prove in the earlier scenarios, right, where they... where they just manually sign one of our sides. We don't really, you know, you don't really know what was going on there.

Ruben Somsen I think it's still solvable because you can get them to commit to what they're going to do and then you can reveal that they said they were going to do x if this happened and they didn't. So, okay, it's probably solvable either way, but uh, it's a little nicer here, it's more formalized.

Aaron van Wirdum Okay, okay, so this message that FIFA is broadcasting this can be used as we explained in combination with your own bets, depending on who won, you publish the original transaction that you have. Then you use this signature from the FIFA, combine it with your own signature. Does this require Schnorr, by the way? Does this require Schnorr signatures?

Sjors Provoost It's easier.

Ruben Somsen It— so the, the oracle signs with Schnorr signatures because, uh, that's the, because Schnorr signatures are linear and that's how you can do the thing that Sjors just explained. Well, that's how you can, that's how you can calculate ahead of time what the expected signature is going to be, the public key of the expected signature.

Aaron van Wirdum Right.

Ruben Somsen And you need Schnorr for that. You can't do that with the ECDSA, I believe. But on the side of the betters, you can use ECDSA.

Sjors Provoost But we're not going to because we're cool people and we use Schnorr.

Ruben Somsen That's right.

Sjors Provoost Anyway, but there's more.

Aaron van Wirdum Okay, yeah. I was almost done with sort of reiterating the point of how it actually works. So the FIFA broadcasts a message saying the Netherlands won in this case. Then Ruben can take that message. He broadcasts the transaction that he had. Sjors cannot because then he might lose his money. So Ruben is broadcasting that message, that transaction, and then he uses this signed message from FIFA, combines it with his own signature, and now... Yeah, with some key. And now you're withdrawing the funds for yourself and you won the bet. That's right. And the FIFA doesn't even need to know that there was a bet at all.

Ruben Somsen Yep.

Aaron van Wirdum Right? Great. So that gets us one step ahead. And then I think there's another incremental improvement, which we're also going to discuss. Is that right?

Sjors Provoost Yeah. And that basically gets rid of a bunch of transactions and makes it look even more... inconspicuous.

Aaron van Wirdum So hang on, what I just explained, what we just discussed are Discreet log contracts, right?

Ruben Somsen From the, from the paper by Tadge Dryja. So this is the original design and not the design that it's currently in use.

Aaron van Wirdum Okay, so now there has been an improvement on the original design. Yeah. Is it still called Discreet log contract?

Ruben Somsen Yes.

Aaron van Wirdum All right, just an improved version of it.

Ruben Somsen It is, it is just I would say it's a slight tweak that was kind of obvious, but makes things a lot easier.

Aaron van Wirdum All right. Who wants to...

Sjors Provoost I think I'm going to go give this one to Ruben.

Ruben Somsen Okay.

Sjors Provoost Because he wrote a mailing list post about it.

Ruben Somsen That is true, yeah. So to my knowledge, I'm the first person who actually wrote it up. I don't think it was super novel because it's literally just... I just realized, oh, you can combine adaptor signatures with the DLC protocol that Tadge Dryja came up with.

Aaron van Wirdum Wait, you're being modest probably, but are you saying, did you invent this? Was it your original idea?

Ruben Somsen I don't think, because it's literally just, yes, I'm probably the first person who mentioned it, but it wasn't an invention, I would say, because it's literally just you're taking adaptor signatures, which was invented, I guess, by Andrew Poelstra, and applying it to the DLC protocol. And there's nothing, like it's a very straightforward one-to-one conversion. So I guess I'm the first person who maybe saw the connection, maybe. I'm sure other people must have seen it too, but just didn't mention it. I'm at least maybe the first person to actually mention it. Let's put it like that.

Aaron van Wirdum Okay, so let's start at the beginning. Adaptor signatures, what are they?

Ruben Somsen So adaptor signatures at a high level, the way I would explain them is that it's a way to do a signature that is incomplete. So you create a signature, but it's not actually valid. It's missing something. And what it's missing, you can know the public key of what is missing. So there's a number that is missing. That number is basically a private key, but you only know the public key of what is missing. So if someone reveals the private key, then you can complete the signature. And now the signature becomes valid.

Aaron van Wirdum Right, I see. I think when I was trying to summarize DLCs earlier, this was kind of what I had in mind. Okay, but this is actually what that is.

Ruben Somsen Yes.

Aaron van Wirdum All right, got it.

Ruben Somsen And it makes a whole lot of sense because it makes things a lot easier. So what we had earlier was this mechanism where you publish a transaction. If you publish the wrong transaction, you get punished. And now we can basically get rid of that with adaptor signatures because what we can do is we can again start from our two of two multisig that me and Sjors have. And then we can create a bunch of transactions, in this case, two transactions, right? Sjors wins or I win. We put our signature on that transaction, but we do it in such a way that it's incomplete. We do it with an adaptor signature. And the signature where Sjors wins can be completed if the Oracle signs Germany wins.

Aaron van Wirdum Right.

Ruben Somsen And my transaction... that signature can be completed if the oracle signs the Netherlands wins. And now we, we completely circumvent that issue of having to go back and having to punish, uh, if Sjors publish the wrong transaction, having to publish him, because he can't publish his transaction because the oracle never revealed, uh, that secret.

Aaron van Wirdum Right, so, so in the previous example I explained that's like in a payment channel both of you essentially have a mirror version of the transaction. Yeah, you both have sort of your own version of the transaction. And then you publish that. And then from that transaction, you can withdraw the funds. And in this case, you still kind of have these mirror versions of the transactions. However, you can't even publish it in the first place if you don't have the adaptor signature. Is that right?

Sjors Provoost And that's also because the inputs are different in this case. So in the previous thing that we described are basically the money that takes it out of the multisig, the transaction that takes it out of the multisig is the same. The input side of the transaction is the same. It has the same signatures, essentially, because it's just taking out of a regular multisig. And what adaptor signatures do is they kind of create broken signatures to get it out of the multisig. So you're not actually getting it out of the multisig, but once you've got it out of the multisig, you can just send it straight to your own wallet. The only thing is you can't get it out of the multisig, because you need this thing from the Oracle. And we both do this. We both have this broken transaction that cannot spend any coins. And then we just hope that we get the private key.

Ruben Somsen Yeah.

Sjors Provoost So there's nothing we need to keep secret for each other. Well, except, you know, our own private keys, but yes.

Aaron van Wirdum Right. Yeah. So this does sound like a streamlined version of the previous example. So in this case, to clarify this, if I'm getting it right, is the Netherlands won, the FIFA broadcasts a message that says the Netherlands won and this time you actually use that message itself, Ruben, to combine that with your own signature.

Ruben Somsen Yeah, and Sjors's signature specifically, right? Because that's the one I need to complete. I can complete my own signature. That's not hard because I have my own key. But Sjors also had to put a signature on that transaction and that's the one I want to complete.

Aaron van Wirdum Right. Yeah. When I said your signature, I kind of meant the transaction that you're holding. Is that right? Yeah.

Ruben Somsen Yes.

Aaron van Wirdum But it is technically Sjors's signature. Right. Got it. All right. Is there anything else? Do you want to get into the P's and the G's and the math like you did before?

Sjors Provoost No, we try to. And I think conceptually, you know, it's again, you just have an equation with something on the left and something on the right. And you can see what the Oracle knows and what you know. And that's all straightforward. The only thing I got confused of is because, you know, we're doing this fancy Lightning-like thing. The multisig, the transaction that goes out of the multisig is a joint, sort of a joint signature with something like MuSig2 as a protocol.

Ruben Somsen Ideally.

Sjors Provoost And I was wondering whether you can actually combine that with this, with this moon math.

Ruben Somsen Yeah.

Sjors Provoost And I'm pretty sure the answer is yes.

Ruben Somsen Yeah.

Sjors Provoost And then you think the answer is super straightforward. Yes. And I looked at some, some comments by Nick. What's his last name?

Ruben Somsen Jonas. Jonas Nick.

Sjors Provoost Jonas Nick from Blockstream. And he said complicated things about security proofs, but he also said it was possible.

Ruben Somsen Yeah.

Sjors Provoost So maybe that, you know, you want to talk to your local cryptographer before implementing something.

Ruben Somsen That is always wise, for sure.

Sjors Provoost That is always wise. Okay, but that's pretty much...

Aaron van Wirdum Yeah, I do have one more question.

Sjors Provoost Oh, no, we have a bonus section.

Ruben Somsen Yeah.

Aaron van Wirdum Well, you touched on this throughout the episode at some point, but I do want to get back to this point towards the end, which is now.

Ruben Somsen Yeah.

Aaron van Wirdum So in the example so far, we've used this very simple bet of the Netherlands versus Germany. But now we want to bet on something like the price of Bitcoin in the future. So now there's not two outcomes, but there's... I don't know. Unlimited? Endless?

Sjors Provoost No, not endless, but N.

Aaron van Wirdum N. Oh, yeah, sure. So how would this translate to these solutions? How are we going to...

Sjors Provoost Well, naively, if you say you want to do the dollar price, and let's say it's a five-digit binary number, just to make it simple and to sort of anticipate where we're going. So that's not a huge precision, but that's fine. For every combination, so for 2 to the power of 5, that's the number of combinations, we would write a contract that redeems the correct amount for me and the correct amount for Ruben. So this is no longer completely binary, but if the dollar price is 00001, then you get a little bit of satoshi. If the dollar price is 1000, you get more satoshi. That's the idea. So we could just sign all these transactions. But if you want to have a bit more precision, we have to pre-sign a lot of transactions. But for the Oracle's point of view, it's very simple. The Oracle just produces, publishes a binary number and signs that.

Aaron van Wirdum All right.

Sjors Provoost That's one way to do it.

Aaron van Wirdum The Oracle, in this case, would only have to sign one message. For the Oracle nothing changes. It's very simple. However, the two of you would need to do a lot more preparation for all the different amounts.

Sjors Provoost And this works with both the proposals we just talked about, right? With the adaptor signatures, but also without the adaptor signatures. But we can do better.

Ruben Somsen Yeah, so hopefully I'm not lost here. But OK, so what you described thus far is you just get the Oracle to sign a specific number, and that number is in binary in this case.

Sjors Provoost Yeah, I already made it in binary, so it's easier to introduce your optimization.

Ruben Somsen In this case, you could have every possible number. So five bits would be 32 possible outcomes. So you could have 32 transactions that with each and every outcome, Sjors and I get a different amount of Bitcoin depending on the bet outcome. That's what you described thus far basically, right?

Sjors Provoost Yeah.

Ruben Somsen Okay. Yeah. So the thing that the Oracle can do is literally sign every bit. So there are five bits in this example. And the bit can be either one or it can be zero. So there are 10 possible outcomes that the Oracle can basically sign. And out of those 10 outcomes, it is only allowed to sign five of them because we use the same trick where if it signs something twice, you can punish the Oracle. So for every bit, it can sign either zero or a one, but never both. Because if it signs both, then we can punish the Oracle because we get their key. And so basically we get the Oracle to publish these five numbers, which is the binary outcome of the dollar amount that we want. And with that, Sjors and I can now create our transactions that we want to create to resolve our bets. But we can now, because we have the binary number, we can actually do some cool stuff with it. What we can do is, so hopefully this is followable. I'm not sure if this is going to be easy, but basically, we have five bits and let's say my bet number was, like the bet is that if it's seven or higher, I win, for instance.

Sjors Provoost Yeah, that's what I was wrong in my example because I made it like a dollar derivative. But in this case, it's more like if it's more than, if the dollar price is more than one satoshi, you win, or if it's less than one satoshi, I win. But we want the dollar price with high precision.

Ruben Somsen Yeah, but you could still have a bet where it's like between three and seven, we get paid out different amounts. And seven or more, I get paid out everything. Three or less, you get paid out everything.

Sjors Provoost Yeah, the key here is that the Oracle does not want to make a custom bet for everybody. It just wants to publish the actual dollar price. It doesn't care what ranges you have in mind. So, yeah.

Ruben Somsen So the nice thing is that you can sort of have these, you can have multiple outcomes. You can combine them in a single bet by just adding the points together. So in this case, what we could do is if we want the outcome seven specifically, that means that the first three bits, the lowest three bits have to be one. And so we can make an outcome where we just combine the key for first bit is one, second bit is one, third bit is one. We combine those three. And that, if the Oracle reveals all three, then that specific bet outcome becomes valid.

Sjors Provoost And that means seven or higher.

Ruben Somsen So in this case, what I described thus far is just seven. If we want seven or higher, then we need another transaction where we say, or instead of the first three bits, it's also okay if the Oracle signed the fourth bit, or it's also okay if the Oracle signed the fifth bit.

Sjors Provoost Yeah, so maybe we can make the example a little bit simpler if we wanted to say one or higher.

Ruben Somsen Yeah, that works. Well, then if it's one or higher...

Sjors Provoost Then you can basically say if the first bit is signed, then you win. Basically, regardless of what the other bits are.

Ruben Somsen Well, no, not regardless of what the other bits are, because if the second bit is signed, if the answer is two, then the first bit is zero. So that's not sufficient.

Sjors Provoost Ah, crap. Yeah.

Ruben Somsen So that's the problem. So it is quite complicated.

Sjors Provoost Anyway, you can basically say, like, if these and these bits are signed, that means this and this number range.

Ruben Somsen Yeah.

Sjors Provoost You can make bets like that, and each digit represents a public key, essentially. So before, the Oracle had only one public key. Now the Oracle might have, I don't know, how many bits you want. Maybe they have 32 public keys.

Ruben Somsen Yeah.

Sjors Provoost And so you can actually make a smart contract, quote, unquote, that... that says something about which public keys have to be present. And this is very cool.

Ruben Somsen Yeah. And so this is why this is a bonus segment, basically, because it is complicated. And I'm sure we're losing a lot of the audience. But for those who are still with us, basically, really at a high level, what we've been describing here is that you can have these and and or statements with the oracles. So you can even combine multiple oracle outcomes. And you can say this and this and this outcome and this and this and this outcome, or this and this and this and this. And you can basically make a whole bunch of bets based on whatever you want. So it just allows for a lot of custom contracts, whereas the Oracle itself doesn't have to do a lot of complex things. It just has to sign the outcome in binary.

Sjors Provoost Exactly. And I guess we're not even going to explain anything about it because I haven't even read it. But the bonus, bonus, bonus, bonus section would be that with OP_CTV, this template thing where you can pre-commit to a whole series of child transactions, you can do even fancier things.

Ruben Somsen Yeah. So I can maybe very briefly try to summarize it. Basically what we've done so far is we've been pre-signing all these transactions. And if you have a lot of bet outcomes, that's a lot of signatures, and you can sort of get rid of those signatures by using OP_CTV, because OP_CTV you can have, in tapscripts, you can have a bunch of OP_CTV branches. And then every branch commits to a different oracle outcome, and then together with the signature of the oracle for that specific outcome you can publish that specific OP_CTV branch. And what that means is that you only have to sign one specific tapscript with one signature from both of us, and that commits to every possible bet outcome. And so what that means is that it is just much faster to generate our bets. Other than that, it doesn't really change anything.

Sjors Provoost Okay, I don't understand that, but maybe if I listen back to the episode, I will.

Ruben Somsen I'm sure someone will.

Sjors Provoost Okay, out there.

Aaron van Wirdum Back to Earth one last time. What's the status of all of these DLCs? Is anyone working on this? Is there any progress?

Ruben Somsen So I know there's a work group that has a mailing list that you can follow. I think it's DLC-dev, but you'd have to Google for that. I know Chris Stewart is working on it. Lloyd Fournier is working on it. Lloyd Fournier.

Aaron van Wirdum Okay.

Ruben Somsen He actually, he came up with a way to do adaptor signatures for ECDSA. So that's sort of the kind of the way in which it's being used today. Even though we have Schnorr, I don't think the DLC project has switched from ECDSA to Schnorr yet. So I would check out their projects. I think it's DLCS, I think is Chris Stewart's project. And I know Lloyd Fournier has gun.fun, which is a very funny name. But he has a little DLC project where he can basically create a bet and you can publish it on Twitter. And he sort of came up with a way to sort of encode it in Twitter. So it's quite a bit of data, but it fits into a tweet because it uses all these weird characters. It's a fun little project. So if you want to mess around with it, I definitely recommend that one.

Aaron van Wirdum Yeah, I think Nicolas Dorier is also working on something. I think it's called NDLC.

Ruben Somsen Oh, okay. I'm not familiar with that, but that's cool.

Aaron van Wirdum Yeah, they did it. He used that, and Chris Stewart used his own implementation, I guess. They've done this one bet on the presidency, on the presidential elections last year, a year ago. That's the only example that I know of that it was actually used in some way or another.

Ruben Somsen Yeah. I used both projects on test nets, but not main nets.

Aaron van Wirdum Right. Well, I think that covers it.

Sjors Provoost I think so too.

Aaron van Wirdum Ruben, thanks a lot for coming again. I don't think we could have done this without you.

Ruben Somsen It was a…

Sjors Provoost Sure, we could not have.

Ruben Somsen It was a tough one, yeah, for sure. It's hard to explain it as well. But I think we did a decent job, even though I'm sure not everything was clear.

Sjors Provoost At least I understand it better.

Ruben Somsen Great.

Aaron van Wirdum So do I, Sjors.

Sjors Provoost So that's good.

Aaron van Wirdum We won something today.

Sjors Provoost All righty. In that case, thank you for listening to Bitcoin Explained.

Aaron van Wirdum There you go.