path: root/transcripts/london-bitcoin-devs/2021-08-10-socratic-seminar-dlcs.mdwn

Name: Socratic Seminar

Topic: Discreet Log Contracts

Location: London BitDevs (online)

Date: August 10th 2021

Video: <https://www.youtube.com/watch?v=h6SkBwOCFsA>

Gist of resources discussed: <https://gist.github.com/michaelfolkson/f5da6774c24f99dba5c6c16ec8d499e9>

This event was livestreamed on YouTube and so comments are attributed to specific individuals by the name or pseudonym that was visible on the livestream. If you were a participant and would like your comments to be anonymized please get in touch.

# Intro

Michael Folkson (MF): Welcome to everyone on the call, welcome to people watching on YouTube. This is a Socratic Seminar, we’ve got a Zoom call and it is being livestreamed on YouTube. Anybody watching on YouTube, feel free to comment, questions and there is a reading list that I’ll share the link to and that give us some structure for the discussion, we don’t have to stick to it but we’ll see where it takes us. Let’s do intros first. We’ll start with the Suredbits guys.

Chris Stewart (CS): I’m Chris Stewart, I’m the Founder of Suredbits. We do discreet log contracts.

Ben Carman (BC): I’m Ben, been at Suredbits for almost 2 years doing Bitcoin development stuff and DLCs. 

Patrick (P): I’m non-technical, just an enthusiast and here to soak up some knowledge.

Roman (R): I also work at Suredbits working on DLCs.

# Basic concept of a DLC

MF: Let’s start with the basic concept. As we were saying before there are tonnes of resources out there and I don’t want to just redo some of the conversations and interviews that have already been had. But I feel we have to go over the basic concept first before we go into the advanced stuff. What is a DLC? 

P: It is a way to have an oracle system I guess via the Lightning Network?

CS: I think we should publicly shame him for not being an expert in 20 minutes of watching videos on YouTube (joke). How do you not know everything?

MF: From your watching of the videos is there anything that makes you interested in DLCs? Is this an interesting concept to you?

P: Yeah. I’ve been looking into the different things you can do… The other day I bumped into secure multiparty computation and that blew my mind. I don’t know what those things really mean but I’m trying to understand it a bit more. This seems like another one of those applications that sounds very interesting.

MF: So let’s go to one of our experts. What is the concept of a DLC? How is it different to say a smart contract on Ethereum? Is it a bet? What types of contracts are we talking about?

CS: Very simply put, DLCs are a way to make Bitcoin transactions contingent on things that are happening in the real world. Bitcoin’s scripting system, any blockchain system for that matter, only can check and know about data that’s within its actual code I guess. It can’t reach out into the real world and determine who won the Presidential election. Even simple things like what’s the Bitcoin price or what’s the hash rate that Bitcoin has currently or what’s the last block hash, even or odd… Those are things that are almost native to the Bitcoin scripting system but with Bitcoin’s limitations it can’t build Bitcoin transactions based on that information. DLCs are a way to allow transactions that are contingent on real world events or even Bitcoin network specific information in a trust transparent way is what I call it. It is definitely contingent on an oracle attesting to something that happened. You do need to trust that oracle but you can clearly tell when that oracle has misbehaved or lied. There is cryptographic evidence at least that you can use to show that this oracle was misbehaving. 

MF: Cool, everyone should know this but Discreet Log Contracts is in a play on words. It is a play on “discrete log” and being “discreet” or being private with what you are actually doing.

CS: Most people seem to spell “discrete” but again going on the play on words it is actually “discreet”. This is the pun that Tadge (Dryja) has in his [white paper](https://adiabat.github.io/dlc.pdf) which was phenomenal of course, Tadge is great.

# How DLCs compare to Ethereum smart contracts

MF: But you curse him for the naming, maybe. So why are we only now talking about discreet log contracts on Bitcoin when supposedly Ethereum has taken the smart contract use case? Why has it taken so long to start doing these kinds of smart contracts on Bitcoin? What is the difference between a DLC on Bitcoin and a smart contract on Ethereum?

BC: I would say the reason it has taken so long is for one, that Tadge Dryja [paper](https://adiabat.github.io/dlc.pdf) didn’t come out until 2017. There wasn’t really too much development on making these things a reality until 2019, 2020. Now with us and Crypto Garage and a couple of other open source guys we actually have working clients. It has taken a while to build out all this infrastructure to make it happen but it is becoming a reality now, we are no longer larping. What is the difference between Ethereum? An Ethereum contract, if you code it up in Solidity and post it to the blockchain, if I want to use that I will always use the same contract that everybody else is using. It is very explicit that I am using this contract. Whereas with the DLC I am just entering into a 2-of-2 multisig and all of my contract logic is done offchain. If an oracle signs then it is possible to produce one transaction that spends that 2-of-2 multisig. It is a lot different model versus publishing to the blockchain your actual contract execution, verification. A DLC is a lot more client side, execution and verification which makes it a lot more scalable and a lot more private. As Bitcoiners we definitely want that.

MF: The trade-off Ethereum took, the term they used was “rich statefulness”. We are pushing everything offchain and trying to touch the chain as little as possible while they are able to have an oracle built within the Ethereum virtual machine and that does have some benefits. The contract can automatically update rather than going to an oracle, getting a signature and sending an updated transaction to the chain. But the trade-off that you get with that is obviously that it is completely unscalable because everything is done with the virtual machine and you are not pushing anything offchain whatsoever. Would you agree with that?

CS: What Ben is saying is right. DLCs are vastly superior in scalability and privacy. The thing we give up though with the UTXO model versus the account model is the market actually existing onchain which is what has led to the rise of things like Uniswap with their automated market makers. That’s functionality that is very hard to replicate in the UTXO model. We are still figuring out how can you facilitate a liquid market that trades 24/7 without having jurisdictional requirements impressed upon on you because you are a centralized company in whatever jurisdiction you are in. One of the more interesting developments lately has been the whole Uniswap company versus protocol saga where they ended up delisting securities via their web interface but the underlying Uniswap protocol, as far as I know, still has grey market or black market liquidity pools available to them. Putting aside the Ethereum stuff, in DLC land it is very hard for us to have this market structure exist on a third party collective resource like a blockchain and give people these abilities to trade 24/7. That is another one of these fundamental architecture differences here. They give up on privacy, scalability, they get this liveliness 24/7 that people really like. We are still working on, we’ve got 2 of these great principles but still the market infrastructure piece is an open question.

BC: This isn’t a DLC specific problem. Things like Joinmarket, Bisq, Lightning Pool, all have the same problem. Bisq has a different model, Joinmarket has a different model. These are solvable things, it is picking one or picking all of them and seeing what works.

MF: It is the problem of the matching engine. What Chris was saying is that you can have the matching engine onchain and that brings certain benefits even though it is totally unscalable. Otherwise if you are doing that offchain you are having to build that whole matching engine independently without automatic writes to the blockchain whenever you want?

CS: Matching engines can be built and that is a pretty well understood space. It is the regulatory, legal, compliance restrictions that come with if I was to host these things on Suredbits servers I’d need to comply with United States regulations for offering DLCs. If Michael, you were to host these things in London, you’re the person who is hosting a centralized server where trades are being matched. You have legal requirements there too. Now if it is hosted on a blockchain it is a collective resource. So you are not necessarily liable, I’m not necessarily liable if I’m running a validator. It is this network that is hosting the market rather than a single company’s servers. It is very unscalable, it is very not private but there are certain benefits to that model when it comes to the legal and regulatory world, at least as it stands now. Maybe this changes in the United States and certain three letter agencies decide to try to hold validators liable which is a contemporary issue I guess. It definitely is on stronger footing when it comes to legal and regulatory stuff compared to the UTXO model in that regard.

MF: I don’t want to get into regulation… but if you are uploading data onto the Ethereum blockchain why is that any different to an oracle offchain uploading data to a website? I never thought the matching engine would be subject to similar regulation as a custodian, that didn’t even occur to me. You are not taking any funds, it is like a dating service. You are just matching two parties that want the opposite things. I suspect you’ve looked at the regulation more than I have.

CS: Maybe this is United States compared to the rest of the world, maybe it is different. It is still an active area of debate. I guess I’m turning this into a regulatory talk now rather than a technical one so I’ll stop talking about that.

MF: London Bitcoin Regulators can discuss that conversation. London Bitcoin Devs will stick to the technical part. 

# Examples of DLCs in the wild

MF: I’ve got this reading list up. We’ve kind of covered the basic concept of a discreet log contract. Z-man has some excellent [thoughts](https://zmnscpxj.github.io/bitcoin/unchained.html) on smart contracts on Bitcoin. We’ve covered the differences between Bitcoin and Ethereum. Some of the examples that I could find, you can tell me if there are others the Suredbits guys, one was Nicolas Dorier and Chris (Stewart) entering into a [bet](https://suredbits.com/settlement-of-election-dlc/) on the election. That was organized via Twitter so does that make Twitter a matching engine? Should Twitter be under regulation? That was an election bet. Who took the oracle in that case between you and Nicolas?

CS: I don’t think the oracle has revealed himself publicly yet so I won’t dox him. He does have a Twitter account, OutcomeObserver on Twitter I believe is his handle. He distributed his oracle information via Twitter so that we could take the information embedded in his tweets and start constructing DLCs based off the cryptographic information he published. He followed up after the fact and also revealed what we call attestations, a fancy word for signatures, that corresponded to the outcome of the election. In this case I believe it was a bet on the US Presidential election in 2020, the two candidates running were Joe Biden and Donald Trump. Nicolas took 60/40 odds where I put up 0.6 Bitcoin for Joe Biden winning and Nicolas put up 0.4 Bitcoin for Donald Trump winning. We built a DLC that encoded these conditions inside of a set of Bitcoin transactions. The way this is done with DLCs is you end up publishing a funding transaction that is a 2-of-2 multisig output and then you have encrypted versions of the settlement transactions that correspond to every outcome that can possible occur during the bet. If I recall correctly during this bet the three outcomes were Joe Biden winning, one transaction, Donald Trump winning, another transaction, and then I believe that we had a tie case or a draw case. It is always good to have a backup case for either the oracle going haywire… In this case it wouldn’t be oracle going haywire, just an unresolved bet. It is unclear who won the election so it is always good to have a draw or another case, that was the third encrypted transaction.

MF: We’ll get into how DLCs have evolved from Tadge’s initial design to now. I just wanted to go through a few of the examples, the parameters of these contracts before we do that, to give some examples to people who are new to this. The next one I had up was Chris and Nadav on [price volatility](https://suredbits.com/settlement-of-volatility-dlc/). There are various derivatives that you can just copy straight from the financial sector and substitute Bitcoin in for whatever fiat currency or asset price that you are interested in. This one was a bet on the volatility of the Bitcoin price, I think one of you bet that there would be a lot of volatility and the other one bet that there would be less volatility?

CS: Yeah. If you go back to that graph up there at the top I can add a little bit of commentary to this graph. For people who are new to DLCs this graph here represents what we call a payout curve. On the x axis of this graph you have US dollars, you can see it starts all the way down at 12,000 dollars. The triangle that we have here hits the x axis at 19,000 dollars and it goes all the way up to 28,000 dollars on the far right hand side of the x axis. What this is saying here is “We’re creating this volatility contract at a strike price of 19,000 US dollars.” If I remember correctly in this contract Nadav was short volatility which means that he wants the Bitcoin price to stay around 19,000 dollars when we settle. If it is still close to 19,000 dollars that means there wasn’t very much volatility during the interval or the period that we were monitoring for. However, me on the other side of the trade was long volatility. I want to get paid more as the Bitcoin price diverges from 19,000 US dollars. As the Bitcoin price hits 20,000 dollars I start getting paid more satoshis on the y axis. On the y axis it specifies the payouts in satoshis that I receive if the oracle attests to a certain outcome. If the price that the oracle attests to was 19,000 dollars I get zero satoshis. That sucks, I don’t want 19,000 dollars to be attested to. However if the oracle attests to the price being 17,000 dollars that is very good for me. I am getting all the money in the DLC here. I get 200,000 satoshis if you look at the y axis. Depending on what the oracle attests to, the more volatile the Bitcoin market is the more profitable this DLC is for me. However, if the Bitcoin price doesn’t move at all that is not very good for me and I end up losing the amount of money I contributed into the DLC. I am realizing now I didn’t specify how much collateral I contributed upfront. If I remember correctly Nadav contributed 100,00 sats of collateral and I contributed another 100,000 sats of collateral. We are equally collateralized. If the Bitcoin price doesn’t move Nadav gets all the money. If the Bitcoin price moves a lot I get all of his money. That’s the financial conditions for this DLC.

MF: It sounds esoteric but anybody who has followed derivatives in financial markets knows that in the fiat economy this is billions and billions of dollars traded everyday on this kind of stuff, on price volatility of various assets. But as you say Chris, the big difference at least with how DLCs are set up now is we do have that limited collateral within the DLC. You can only lose the collateral that you post. In the conventional financial industry you can lose your shirt, you can lose everything. You do a leveraged trade betting that a price is going to go up or down or that it is going to be particularly volatile or less volatile. If you get it completely wrong you can lose a lot more than your initial collateral. That is the big difference.

BC: Something important too is you can only gain as much as your other counterparty puts up too. In the fiat system you can 100x leverage and get a million dollars. Versus this, if your counterparty only puts up 1 Bitcoin you can only win 1 Bitcoin.

MF: But maybe as this matures, if there was a big enough market with everyone betting their collateral then perhaps you then expand into where there is custodianship and you can win more than the initial collateral posted. That was volatility, the next one I had up was Blockstream and Crypto Garage on the [Bitcoin price](https://blockstream.com/2019/04/19/en-transacting-bitcoin-based-p2p-derivatives/). Again this is derivatives, this was a forward contract?

CS: This was published in 2019 from Blockstream. As far as I know this is the first DLC executed on the Bitcoin main chain. We have come quite a ways from what is detailed in this blog post from a technical perspective I think. The actual financial engineering side of things here is pretty straightforward. If I recall correctly it is just a linear payout based on what the oracle attests to. I have to admit I did not look through this old blog post before I jumped on. Sorry about that.

Nadav Kohen (NK): The forward contract they executed pretty manually using handwritten scripts as opposed to libraries that autogenerate things. This was also before the use of adaptor signatures. They used quite a bit more script and more complicated stuff.

MF: They used the Japanese Yen stablecoin on Liquid as part of the derivative? 

CS: I think that is in the more to come section.

MF: Ok it was purely a Bitcoin…

NK: It was a proof of concept.

CS: Maybe we are saving technical stuff for later but this would be a fun topic to touch on when we get to the technical discussion because it really shows the iterations that we’ve taken on designing the DLC protocol. If I remember correctly this is almost word for word what Tadge has in his white paper and we have diverged a bit from the original white paper as we find more innovations in the space. We can talk about that in the technical section. 

MF: Let’s get onto that. There are tonnes of examples but I think that gives a flavor of some of the examples that you can do with DLCs. Let’s get onto the technical stuff, let’s get onto the evolution since Tadge’s initial… Just before we do that this looked cool. I just saw this earlier today. Lloyd Fournier wrote a [paper](https://github.com/LLFourn/gun/blob/master/docs/bet.md) on how to make a prediction market on Twitter with Bitcoin. Similar to what you and Nicolas did on Twitter. He has also made a betting [wallet](https://github.com/LLFourn/gun) for betting on the Bitcoin price for “plebs, degenerates and revolutionaries”. I just found that earlier, that looked cool.

CS: Ben gave this a try this morning? Ben, do you want to add any color on that?

BC: He put it in our DLC chat the other day asking for people to test it out. I tested it out last night. I did a simple bet against Lloyd on a coin flip. It happens in two days so we’ll see if I win. It is pretty cool. It is only a command line tool at the moment. It is not too easy to use yet but I think it is pretty cool. I think it has a lot of potential.

NK: Just out of curiosity is Lloyd’s tool for binary option stuff or does it work for more general stuff?

BC: I don’t know.

MF: It seems very early, I think he just posted it today or yesterday. It looked cool so I added it to the reading list.

# Evolution of the DLC: adaptor signatures

MF: Let’s go through the evolution of the DLC because that hasn’t really been covered I think on other forums, other podcasts, videos etc. The very first resource is Tadge’s original DLC [white paper](https://adiabat.github.io/dlc.pdf). What was the initial concept of a discreet log contract when Tadge initially released this paper?

NK: I highly recommend people read the white paper if you are interested. It is only 5 pages, it is written very clearly. There is a little bit of math in there but that is about it, that second page. If you are comfortable with the math it is also a decent place to learn about Schnorr signatures. This is where I learnt about Schnorr signatures, they were defined here, the idea. There are two ideas going on: the higher level one and the technical trick that enables it. Up on page 1 I think he states it pretty well in the abstract. Essentially the goal, he mentions financial use, but more generally speaking it is a private contract scheme that is scalable. It addresses scalability and privacy concerns. You also want to minimize the amount of trust. It has a very specific oracle model in mind where you have oblivious oracles that are being used to execute contracts on Bitcoin. As the name puns out we use a discrete log and it is private hence the misspelling with two e’s and a t. Essentially the trick that is used, I don’t know if it is Tadge’s innovation or if it is more so putting things together here, the idea is that you can with Schnorr signatures and other kinds of schemes you can anticipate a signature of a specific message by some entity such as an oracle. You can have an oracle whose public keys are known, they publish some commitments to an event and you can essentially create encryption keys that anticipate a specific event. You can create one for each possible event. This is what is used in order to construct contracts. In the initial white paper it really doesn’t go much further than that. The idea is you have some list of outcomes and you have a payout for each one, that is about where it ends. It is mentioned at the end about further optimizations, how you can do some other tricks but they are not very fleshed out. They are not exactly what we ended up using but they are the right general idea for how you would begin if you were to try to generalize this to more interesting kinds of contracts. It is short and sweet, 5 pages, explains the motivation, the model for the oracles that they don’t know anything and they just broadcast and that they can’t even see themselves after things have gone onchain. There is a section lower down about how you can anticipate a signature for each possible outcome. There is actually a rather vague section in which it says that you can then use this anticipation point in order to construct a contract in Bitcoin. This vagueness is where the older versions of DLCs diverge from the newer ones. The original ones took a more literal approach. You take this anticipation point for a given event and you use it as a tweak on an onchain key. There is always messiness involved with that and proving that it is secure is rather tricky. Newer iterations use these things that I’m sure that we’ll talk about later called adaptor signatures which are a much fancier, much more elegant solution to how we take this property of Schnorr signatures that you can anticipate signatures and use them to actually build out our contracts.

MF: Just to be clear, it doesn’t use adaptor signatures? Tadge is the co-author of the Lightning [white paper](https://lightning.network/lightning-network-paper.pdf) as well. This is only shortly after Lightning. It is not using adaptor signatures, it is not using Lightning and Schnorr obviously was years away from being activated. It is using Schnorr?

NK: It is using Schnorr. It is using Schnorr offchain. The oracle signatures are Schnorr signatures but you can use the oracle Schnorr signatures to then create ECDSA things. These anticipation points are derived from offchain Schnorr stuff. But you can still then use that for onchain Schnorr or onchain ECDSA or in theory other signature schemes. The original DLCs that were executed with this paper’s publication on testnet and later with Blockstream and Crypto Garage and then later with us, were all actually using ECDSA onchain, everything works today. But we are actually using a Schnorr variant offchain.

MF: That hasn’t quite clicked for me, how you can have a Schnorr signature…

NK: Oracles are not related to the Bitcoin blockchain in this model. An oracle is just an entity that signs things, it announces “In the future I am going to sign X”, “I am going to sign the Bitcoin price on this weekend, on Saturday”. On Saturday it broadcasts the signature of what the Bitcoin price is. Those are the only two functions it has. It doesn’t have anything to do with the blockchain, it doesn’t look at a blockchain, it doesn’t need a blockchain. Then what it is doing is it is using Schnorr signatures, it is posting announcements with pubkeys and then the signature of the price is actually a Schnorr signature. This isn’t a thing that is going on the blockchain, you can use whatever signature scheme that admits an anticipation thing that you want. Schnorr just happens to be a really convenient compact efficient nice one that has libraries in Bitcoin now. So essentially the oracle is just using Schnorr and then the fancy trick that is in this paper explains how from the Schnorr stuff we can get this public key that we can use in anything. In ECDSA we can use this public key to tweak our signatures that are ECDSA signatures in order to enforce our contracts. Tadge was actually using Schnorr signatures in the paper and we do use Schnorr signatures for DLCs generally speaking.

MF: This is a different trick of an oracle signature feeding into who gets paid, different to an adaptor signature?

NK: An adaptor signature actually is a version… There are a couple of different ways you can do this. One way that is the original way is you can use your public key literally to add it to other public keys. That gets kind of nasty. With adaptor signatures you use it as an encryption key. Either way you are using this Schnorr stuff and you are using it to tweak or do some variant scheme on your normal onchain signatures. The original way of doing that was kind of nasty, that is for example what Crypto Garage and Blockstream did and what we did initially. Then adaptor signatures only came later on as an improved way to use these pubkeys that correspond to real life events.

MF: I think I am going to have to read the paper again. I thought it wasn’t using adaptor signatures but it sounds like it is using a flavor of adaptor signatures that isn’t quite the adaptor signatures we use today.

NK: Adjacent. It has a similar interface to adaptor signatures but it is actually vague, it doesn’t say. It is very easy these days to read it and be like “He is talking about adaptor signatures right now”. When really he was saying something much more vague. You need something that acts like this and then doesn’t state which one it is or how you have something that acts like that. These days we use adaptor signatures because they act like that. But the initial iterations did not use adaptor signatures. They used other things that were similar, probably less secure and definitely worse in other ways.

MF: You also have this [blog post](https://suredbits.com/discreet-log-contracts-part-2-how-they-work/) where you explain how they work before the latest adaptor signatures that are used currently with DLCs.

CS: I believe one of the key things that came along for us in April 2020 was Lloyd figuring out how to do ECDSA adaptor signatures which is a primitive that is available on the Bitcoin blockchain so that we can enforce these things actually onchain for settlement of transactions.

NK: Lloyd figured out that this was likely possible in December 2019 and posted under a pseudonym to the mailing list. Then he fleshed it out a bit more and published an actual GitHub [paper](https://github.com/LLFourn/one-time-VES/blob/master/main.pdf) draft of how this works and what the security is like. That was, I want to say, February or March 2020. Then there was an online [Lightning Hack Day](https://bitcoinops.org/en/newsletters/2020/04/08/#work-on-ptlcs-for-ln-using-simplified-ecdsa-adaptor-signatures) that me, Jonas Nick and a bunch of other folks from Suredbits and some others, Waxwing (Adam Gibson) and Lloyd was also involved. We got together and we implemented ECDSA adaptor signatures and a little thing built on top of them. That was the first implementation of ECDSA adaptor signatures in April 2020. Then it was cleaned up, tests were added, it was made more production ready and it was [merged](https://github.com/ElementsProject/secp256k1-zkp/pull/117) into libsecp256k1-zkp maybe 4 months ago. That was Jesse Posner who picked up nickler’s work, tidied it up and took it over the finish line. When we were originally working on DLCs we had about a year before ECDSA adaptor signatures existed and could be used. We were doing other nastier tricks that are explained in that [blog post](https://suredbits.com/discreet-log-contracts-part-2-how-they-work/). They are not terribly nasty or anything but from a code perspective it was 4 times as much code to get it to work. If I recall when we switched to ECDSA adaptor signatures it cut the codebase into a quarter of the size.

MF: Wow, interesting. This is just you saying “We’ve got a better design than what Tadge initially put in the white paper. We want to use this flavor of adaptor signatures, we don’t have Schnorr yet, can we do this with ECDSA? It turns out we can in a convoluted way but once we have Schnorr it will be a bit easier.

NK: That’s right. The way we are doing it now we are using ECDSA adaptor signatures is going to make it much easier to transfer to using Schnorr because we are already using all of the same interfaces as Schnorr adaptor signatures and the like. It will be much closer to just swapping out ECDSA for Schnorr than it would have been if we had to do all of these changes all at once. It also helps from a development perspective where we’ve moved to the thing that’s more Schnorr like even though it is not Schnorr yet. It is better in every other way too because Schnorr is great.

# Evolution of the DLC: Onchain, payment channels and Lightning routed

MF: Let’s continue with the evolution of DLCs for a moment. There are a bunch of different evolutions here. There is the adaptor signatures that you’ve just covered Nadav. Then there is the “Do we do this onchain? Do we do this in a payment channel? Perhaps in the future do we do this on a routed payment across the Lightning Network?” The examples that we showed earlier were within a payment channel were they? With no routing? Is that right?

CS: I think the examples that we were talking about earlier were strict onchain DLCs. As of now we have not begun development on a Layer 2 DLC. We are starting to get some inbound interest from Lightning implementations looking to support at least rudimentary DLCs between a counterparty and another person. But yeah where we are at with development today is we have an onchain wallet that works well. You can go download at [suredbits.com](https://suredbits.com/bitcoin-s-0-1-0-release/) and play around with this stuff. We have got a lot of improvements on the engineering front in the pipeline but we have also published videos out there that Ben made to show how to do a DLC between two counterparties. To be explicit it is just onchain currently and we are trying to get our code solidified in that regard and the spec solidified in that regard before going up to Layer 2.

NK: There has been a lot of work on offchain DLCs but all offchain DLCs are paper DLCs. They haven’t actually existed on computers yet. But we have a pretty good idea on what that is going to look like when it is done. There are a couple of barriers before that work can actually begin. My understanding is that most of the work that needs to happen to unblock offchain DLC work is on the Lightning implementation side of things. There is a lot more generalization that needs to happen. Hopefully the move to Taproot will be a good motivator to start this work. That is our hope. 

MF: The first thing that you would do to take advantage of Schnorr and Taproot would be to just use Schnorr in an onchain setting. Use Schnorr adaptor signatures if DLCs are currently all onchain you will be using Schnorr onchain to begin with?

NK: Certainly. Schnorr/Taproot will certainly be something that benefits DLCs even onchain. More so what I was referencing is that there are going to be changes coming to the implementation structure of Lightning nodes in the near future because they are going to be moving to Taproot and they are still going to have to support old channels for some period of time. That is going to force them to have to be able to do more than one thing. Right now Lightning implementations are quite hardcoded to do just the one thing they do. There is a lot of generalization that needs to happen in order to allow other kinds of things to live in Lightning channels other than just payments. In order to have DLCs we need a more general state machine, the internals need to be able to handle more general kinds of things than just payments. My hope is that the first step in this direction will be when Lightning implementations have to support both pre and post Taproot. Their internals are going to have to be more flexible. Once they are more flexible it should be much easier for us to start doing other things inside of Lightning channels.

MF: I see two possible alternative directions. One which is you try to get integrated into Lightning implementations so that you can work within existing… I think this was the approach Tadge was doing initially with his Lightning implementation [Lit](https://github.com/mit-dci/lit) which was just to do payment channels and set up a network of payment channels, not do the routing and almost set up a new network that is almost separate to Lightning. To get off the ground given that you are not taking advantage of the routing to begin with.

NK: From an engineer’s perspective the thing we hate most is redoing work. If we gut a Lightning implementation and put DLCs in there and then later in the future we are also going to put DLCs into normal more [generalized channels](https://suredbits.com/generalized-bitcoin-channels/)… I’m not saying we wouldn’t necessarily do the first thing but we’d want to make sure we were doing the first thing in a way that is compatible in the future with these more [generalized channels](https://eprint.iacr.org/2020/476.pdf). It feels like we are just a year, maybe two years or something like this away from having an actual framework for what it is going to look like to have more generalized channels. We are hesitant to start work that might have to be thrown away in the future when we know that soon enough we are going to know what direction is the right one to take.

MF: I get that. There are going to be various upgrades to Lightning. At which upgrade to Lightning is best for the DLC people to jump in?

NK: I would argue PTLCs.

MF: Yes it is probably going to be PTLCs rather than the MuSig(2) upgrade which will probably happen earlier before the PTLC upgrade.

CS: On what Nadav was saying, the oldest parts of these Lightning implementations are their HTLC state machines. There is a very strong resistance to changing these things because a) it is dangerous, you might introduce bugs, b) sometimes the people have left these companies that wrote this initial code and now there are newcomers that have to maintain this and are scared of introducing these bugs because they aren’t the initial people that wrote this stuff. It is going to be a long conversation I think in the Lightning community to get them comfortable with changing these core state machines specifically their HTLC state machines and incorporating these more general channels. I think when talking about more general channels I don’t know if there is a clear winner in that regard unless you are just talking about PTLCs as your more general channel?

NK: The ideal would be more general channels which would obviously let you do PTLCs on top of other things. But I imagine PTLCs are a good first generalizing step so they’ll probably happen prior to that. It will happen in that direction. Also I want to add a c), another reason why people don’t want to change the Lightning state machines, for the things it does right now it is provably optimal. Everyone is always like “Changing things comes at a slight disadvantage to the current use case”.

MF: You mean the scripts are optimal? What do you mean by provably optimal?

NK: I mean the actual internals for how they handle… From a computer science perspective the algorithm that they use is provably optimal and as fast as possible if the only thing you are doing is HTLCs. The HTLC state machine that is implemented in the current Lightning implementations is optimal. What we call for is less optimal for HTLCs but can do much more. There is that trade-off. I don’t think there is significant pushback but it is more an inertia that has to be overcome. People need to be convinced that it is very much worth it to be working on changing these things when what we have is so nice for this one thing that it does.

MF: To play devil’s advocate, if it is going to take a while for Lightning to get MuSig and PTLCs is that not an argument for bootstrapping a DLC network of payment channels. Then you could start with everything that you want. You are not sitting there waiting for Lightning to implement what you want them to implement. That always takes longer than you’d hope.

NK: I still think it is totally possible to take that approach but I would again just say we would probably wait to start that work until we actually see how we are supposed to do it. There are a couple of different ways that this can be done, how you would gut it and replace it. We want to make sure that we do it in a way that can be reused in the future. That is something that I think will be much clearer in less than 2 or 3 years.

CS: I was talking with some Lightning folks this weekend and talking about what’s on the roadmap for various Lightning companies. My argument to them is we need more adoption on the Lightning Network, I think everybody agrees with this, and number is going up currently and that is great. One of the reasons that number go up could be attributed to lnd adding new features like [keysend](https://bitcoinops.org/en/topics/spontaneous-payments/). I have issues with keysend but I don’t think it can be argued that there is a lot more applications that are enabled by this. I think we need to pitch them the same way as PTLCs. We have written a whole [archive](https://suredbits.com/category/payment-points/) about things you can do with PTLCs, it is going to enhance the expressiveness of the Lightning Network which is going to make number go up even more on the Lightning Network. We need to pitch them on this new feature set, your last features didn’t really go through the consensus process for Lightning to integrate. You’ve got some interesting apps out there for that. The same thing can happen in PTLC world. Unfortunately going back to what we already hashed over was it is much more invasive to do PTLC stuff around the core HTLC state machine logic that already exists.

NK: I posted an [update](https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002647.html) to the Lightning dev mailing list around a year ago, after the hack day had happened and we had ECDSA adaptor signatures. I posted an update on PTLCs, what work had been done, onchain proofs of concept that we had executed and the set of things that needed to be changed in the Lightning Network were. And I believe roasbeef [responded](https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002659.html) to this mailing list “I wouldn’t call this a minimal change, this is the largest change that would have ever happened to the Lightning Network. You are changing the state machine.” And I was like “Ok I guess you are right.” For context roasbeef once said this would be the biggest change to Lightning that has ever happened. Not DLCs to be clear, something much smaller than DLCs that are a required first step, changing the state machine at all which has not happened yet.

MF: I get the sense roasbeef is more on the disruptive side rather than the conservative side.

NK: I have talked to him quite a bit since about generalizing channels. It is something he wants to do and it is something that he is working on. It will certainly happen, I am not worried. I think the consensus is that it is the right approach, it is just a lot of work and the work is happening slowly.

# How the DLC use case could increase usage of the Lightning Network

Fode Diop (FD): First of all, hello everybody. I just wanted to add to what Chris was saying about number go up in Lightning. I think it will happen. Especially in Central America, we are only 3 and a half weeks away from the government wallet being released here. It is not just El Salvador, it is all the neighboring countries. If you think about it, most of the banks here are owned by foreign banks. The three major banks here are owned by Colombian banks which means that as they help the banks integrate with Lightning they are also themselves getting ready to integrate with Lightning as well. We have Colombia next door, we have Guatemala which is right next door and all exchanges here are pretty much integrating with Lightning as well. I think it is just a matter of time until we see an explosion of usage here. El Salvador alone is 6,7 million people. If you onboard an entire nation on it I think there will be an increase in usage but also a good way to stress test the Lightning Network.

MF: I don’t know how much of it is literally on Lightning. Is there a big uptick in terms of Lightning channels because of this adoption or are they all just doing a custodial service?

FD: It is custodial in the beginning, nobody even knows yet if the wallet is going to be onchain or a Lightning wallet, the wallet coming up on September 7th. We are hearing that it will have an integration with Lightning from the get go. Whether it is a custodial or a non-custodial wallet I think it doesn’t really matter because ultimately if the wallet can allow for people to withdraw onchain or through Lightning then anyone can use any wallet out here. That is what the government is trying to push forward, for anybody to use any wallet that is available. There is Bitcoin Beach, Wallet of Satoshi, some people are using Muun and Strike of course. I think over time as people get more comfortable and they understand how to use wallets they will use whatever wallet works for them. I think there will be increased level of usage. I don’t want to be a prophet and say something that might not happen but what I can see here there is going to be an explosion of usage.

MF: This might seem like a diversion from DLCs but it is not actually as a diversion. AJ Towns’ idea that he posted on the [mailing list](https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-January/002937.html) and he also spoke at the [Sydney Socratic](https://btctranscripts.com/sydney-bitcoin-meetup/2021-02-23-socratic-seminar/#lightning-dice-aj-towns) on this, AJ is trying to get more adoption on Lightning, more people using Lightning. AJ’s argument was that in the early days of Bitcoin Satoshi Dice was the biggest use case of Bitcoin. There were tonnes and tonnes of transactions. Now we look back and go “How terrible it was. My node has to verify all these terrible transactions”. But you could argue back then any adoption… Bitcoin was nothing, no one was using it. It had a purpose that people were actually using Bitcoin for something. AJ’s argument was, you can read the mailing list post, that you could do similar Satoshi Dice gambling on dice, gambling on coin tosses on Lightning to get the adoption up on Lightning if your objective is to get adoption up on Lightning, more people using Lightning. It sounds like from your perspective Fode that we don’t need to be as concerned with adoption on Lightning, people are going to be using Lightning for payments.

FD: Not at all.

MF: We don’t need the DLCs to get that adoption up. 

FD: I think we need every kind of technology out there because usually the markets will determine what they want. The market will say what is needed. To me we try it all, throw the kitchen sink at it and see what happens. Whatever sticks sticks and whatever doesn’t will be discarded like natural selection. I am not saying DLCs will not be needed per se, I am curious about DLCs. Since I met Chris in Miami I really need to see how this works.

MF: Just to be clear I think DLCs have got a definite use case. It is just whether they are the first killer use case for Lightning or whether it is a separate network and Lightning is going to be fine on its own. DLCs take advantage of Lightning or set their own network up, whatever works for DLCs.

CS: I think since the earliest days of us working on DLCs we’ve always had the implicit assumption that eventually Bitcoin blockchain space is going to fill, it is going to be uneconomical for lower value DLCs to happen on Bitcoin so let’s use our Layer 2 solution for what it is. With DLCs in channels, if you are doing smaller DLCs, less than a Bitcoin, I think doing them on Lightning makes a lot of sense. If you are doing hundreds or thousands of Bitcoin in your DLC the same security incentives that apply with Lightning also apply with DLCs. They are just another output in your Lightning channel. You need to be mindful of very large DLCs on Lightning in the same way as you need to be mindful of very large HTLCs on Lightning as well. Going back a step or two, I always try not to be judgmental of the economic activity that is happening on the chain assuming that it is not parasitic to the underlying blockchain. I don’t think we need as Bitcoin developers or the Bitcoin community need to get in the business of judging whether this is worthy to be on the Bitcoin blockchain or if it isn’t. The fee market is there to determine that. That is the whole purpose of fees onchain, to price out things that don’t have as much economic value and it needs to go to a Layer 2 solution. That’s fine in my opinion. 

MF: The downsides are totally different now. If we are doing parallels with Satoshi Dice and DLCs on Lightning, every single transaction was onchain. We are talking about a potential future where there are tonnes of DLCs going over Lightning with barely any touching the chain. On the downsides it is very different but perhaps there are the upsides in terms of this could be a use case to get more people using Lightning, I don’t know.

NK: I also think DLCs are a nice test run for doing more generalized offchain stuff. Layer 2 currently is in its first iteration where it is just payments that are happening. I think in the future, as Chris mentioned, almost everything is going to happen offchain, it is going to have to. Certainly nothing cooperative should ever happen onchain, that is a principle. There is no reason to be using a blockchain directly for anything other than assurance that if things stop being cooperative then you have a backup. As a first resort you should never actually be using a blockchain if any activity that you are doing is cooperative. In the future we are actually going to need Layer 2 to handle almost everything. We have payments down as the first step and I think DLCs are an ideal second step. They are pretty minimal in their package for what you need in a technical sense, they have immediate use cases so they are marketable to people. You can have these things get implemented and integrated, and they are not as trivial as a payment. It is not that a payment is trivial, Layer 2 took quite a while to come around, but as far as contingent payments go it is about as simple as it gets. I think in some sense it can be viewed as the natural next step after payment channels, introducing things like DLCs into offchain ecosystems.

# The challenges of a routed DLC on Lightning

MF: I do want to have a final section on oracles before we wrap up. Just to finish the Lightning section, this is looking forward to when there are DLCs on Lightning. When we get to routed DLCs, this is looking very far ahead, not only a DLC within a payment channel but routed across multiple payment channels, the problem there is if you do a bet that settles in 6-12 months then the capital would be locked up on every hop. That is not ideal. We are kind of in the same space as [HODL invoices](https://bitcoinops.org/en/topics/hold-invoices/) with capital being locked up.

NK: I would argue that it is the exactly the same space.

MF: So there are good reasons not to like that, if capital is locked up for no reason. When they want to be doing payments settling very quickly all the time. You’ve said [barrier escrows](https://suredbits.com/payment-points-and-barrier-escrows/) could potentially be a solution to this?

NK: There are two separate things. With HODL invoices there is the current problem, the model under which we operate Lightning is a model in which the use case is fast payments that are executed and then resolved. HODL HTLCs or HODL invoices are essentially payments that are longstanding so they don’t complete immediately. They get set up and then they stay in that state of being set up locking up the capital along the route until some future date when the payment actually gets settled. It is a delayed settlement Lightning payment in which all of this capital gets locked up. In the current model this is essentially indistinguishable from spam. If I was going to spam attack the Lightning Network I would just set up a bunch of very long route payments to myself and never complete them. For each satoshi I have to lock up I can lock up 20 satoshis of other people’s capital because of the routing. You have this huge leveraged power where you can spam the Lightning Network. I would say today the Lightning Network is not generally spam resistant. There are I think four different competing proposals that are in the works right now for how to solve this problem. All of these problems essentially boil down to you have to pay people for their capital lockup, not just on a one time basis as it is right now. But also in some sense you have to compensate them either probabilistically or otherwise. You have to take into account the amount of time that capital is locked up. You are paying for the use of other people’s capital in routing and you are using the capital much more if it is a HODL invoice than if it is a normal one. Essentially there are a bunch of different proposals out there for how to price this in. These people who are holding and locking up their collateral are getting paid compensation that is proportional to that cost for them. Once this problem is solved it is fundamentally a problem of spam. Secondarily a problem for HODL invoice HTLCs and I would say only tertiary it happens to also be true for things like routed DLCs and other contracts. If you solve the problem for spam then the problem also becomes solved for DLCs. It will just be priced in, DLCs will be a little more expensive to do if you are routing them than they would be to route them today. But it wouldn’t be bad for the network. There is some stuff that isn’t priced in under the current Lightning Network model. In the future it will be. I think that essentially this problem reduces to the problem of spam which is a problem a lot of people are working on.

CS: Maybe DLCs would even be good for Lightning in this regard if the spam problem is solved because then people who are putting their capital on Lightning, maybe they want to route DLCs because they can have longer standing DLCs on their Lightning channels rather than these HTLCS that appear quickly and then should be cleared quickly too. Maybe it is a longer term source of income for Lightning node routers when they are routing these larger DLCs that are hanging off the channel for a while.

NK: The problem that barrier escrows solve is a related but different one.

MF: I misunderstood this. There is the capital lockup problem and there is also the problem of getting a free option. You enter into an agreement, the price swings and then you leave that agreement because you’ve basically got a free option.

NK: A simple example. Say I want to bet with Chris whether or not it is going to rain where I am tomorrow. I say it won’t rain, he says it will. We want to do a routed DLC over Lightning. What needs to happen is I need to set up a payment to him contingent on it raining. I set up a payment to him and the point associated with that payment, the tweak, is the oracle anticipation for the event “It is raining”. We’ll say it is for 1 Bitcoin just for simple numbers. Then he needs to set up a payment to me for 1 Bitcoin contingent on it won’t rain. Only one of those two things is going to happen. Say it does rain, then Chris can claim his payment and I am never going to be able to claim my payment. The oracle is never going to publish “It didn’t rain”. I can just fail that payment and return the collateral. The problem here though is there are these two payments that need to be set up from one to the other. The question is who moves first? If I set up my payment to Chris he can never set up a payment to me and now that’s a free option. If it does rain he gets paid and if it doesn’t rain he doesn’t lose anything. He hasn’t set this up in return. This notion of a barrier escrow which came out of a discussion between me and ZmnSCPxj was a solution to a similar problem that happens to also solve this problem where we can essentially atomically set up two payments. How it works is we have the payment I am going to set up to Chris and the payment Chris is going to set up to me. We add one extra lock to both of them that’s the same lock with some other point, say E, that belongs to this barrier escrow. Then what me and Chris do is we do an AMP, an atomic multipath payment to this third party. They don’t know who we are, they don’t know what they are being used for. All they do is they accept payments. Once both me and Chris’ payments have been set up to them then it releases. How this looks is rather than I set up a payment to Chris and he sets one up to me, what we do is we both set up payments to each other that go through each other and to some shared point elsewhere on the network. That shared point happens atomically using the existing thing which is AMP. Using just AMP we can essentially bootstrap AMP into helping with atomic multipayment setup. You can set up as many different consecutive payments as you want for all the different possible outcomes. You can get fancy with it, that essentially lets you do DLCs routed over Lightning if you have PTLCs. 

MF: With that problem where I make an offer to you Nadav and then you have time to either decide whether to accept it or if something swings in your favor… Say you bet on the rain. While you are deciding whether you want to enter into the bet on whether it rains or not you are looking out the window to see if it rains.

NK: Something like that.

MF: You’ve got this information where you can decide whether to agree or disagree. The solution is to introduce a third party so is there is no advantage or no delay where one of the parties can collect more information.

NK: In general this is what it is like. In this particular example it is actually even a bit worse since there are just two outcomes. Chris can always accept my payment and never send one back. In a normal DLC there are more than two outcomes and there are multiple payments being set up between two parties. You could interweave them and stop at some other point which would be more analogous to what you are saying. In some sense that is exactly the problem, that someone can verbally agree to something online and then during the process of actually committing to it they can take advantage of the other person if you are not careful. Barrier escrows solve this problem in a trust minimized way. You don’t have to trust your counterparty in any way anymore. You have a much smaller amount of trust that is much more economically motivated that you put into some third party that is publicly auditable. Especially if you are already doing DLCs arguably there is much less trust that is required in a barrier escrow than in an oracle. It seems like an acceptable thing to do at least for the DLC use case.

MF: The solution to the long term capital lockup problem is either you do it in a payment channel where both parties in the payment channel are happy to lock it up between each other as you would onchain. If you are locking it up onchain you are not getting anything for that capital while it is locked up. Or you are paying higher routing fees effectively.

NK: Exactly. Presumably the longer it will take to execute the contract the more proportionally you’ll have to pay in routing fees. Then it becomes a calculation of is it worth it to do it offchain or onchain? If onchain fees are super high it is still going to be worth it to pay those higher routing fees.

MF: I saw Thibaut has opened a [PR](https://github.com/rust-bitcoin/rust-lightning/pull/1031) for rust-lightning on DLCs. It looks like there is some activity on rust-lightning from Thibaut. You guys are Scala guys right so are you trying to get DLC stuff into eclair?

CS: We would love to. The eclair guys are not the most friendly guys for merging code that is not theirs. Funnily enough Roman actually implemented the Postgres support that they have in eclair so they do have a different database backend now mostly thanks to Roman. Roman has also done work on demoing ECDSA adaptor signatures on Lightning as well to see how invasive these changes to this HTLC state machine are. If people want to look at what that world might look like I can dump a link to the implementation to the chat here.

R: The HTLC is the core thing in eclair. Recently I tried to rebase my branch with PTLCs with their current branch. It is a nightmare. There are so many changes in so many places. It is impossible to track. That is probably one of the reasons we need some kind of general concept for channels.

MF: It is complicated. Just to correct Chris the eclair guys are very friendly but it is hard to get stuff in and it should be hard to get stuff in.

NK: Are they still a smaller team than Lightning Labs? They used to be, I don’t know if they still are. They have finite resources and a lot of work and currently generalizing channels is not at the top of their priority list. Not much progress happening there. But we do have DLCs implemented in Scala so if they ever want it it is pretty easy to plug in. That is the easy part. The hard part is the actual making it possible to plug in.

MF: I was looking through some of the work Tadge and other people had done in his Lit implementation. There are a bunch of [PRs](https://github.com/mit-dci/lit/pulls) on DLCs. If you were to go down the different implementation approach rather than trying to get it integrated into an existing implementation.

NK: This is the pre adaptor signature implementation by the way.

# Oracles

MF: So let’s go onto oracles. The oracles in DLCs, this was what Tadge initially described in his paper… With a 2-of-3 multisig all the participants need to identify who the oracle is. The oracle is going to be signing in the 2-of-3. The two participants in the contract have to find an oracle who is willing to sign in case they don’t come to agreement. Tadge’s concept was that instead the oracle is just going to sign various statements and not actually know they are participating in any of these contracts. That’s what you have gone with, there are various reasons why you’ve gone with that approach. Why is it better if the oracle doesn’t know that their signed statements are being used in contracts?

BC: The first one you were talking about, the 2-of-3 multisig, your third party will know the exact UTXOs you are using onchain, they can see your transaction, they have to sign it. They can track which party won the money, they know where the funds are going, where the funds are coming from. It is really not private and you have an extra public key onchain so it is a little less scalable. For the actual oracle or your third party helper, they have a lot more regulatory risk. They might need to KYC your users, they might need to be a public entity. It makes it harder to do. Versus with the DLC model the oracle just signs “It is raining outside” or signs the Bitcoin price or “Biden won the Presidency”. That single signature can be used for every single user that is using them as an oracle. It is a lot easier for the oracle, they just put it out. For the users it is better because the oracle doesn’t know they are being used, they are hiding from the oracle, it is only between them and their counterparty.

NK: In some sense it is the difference between the “don’t be evil” and “can’t be evil” models. The 2-of-3 is the “don’t be evil” trust model. I guess it is not “can’t be evil” but the DLC oracle model is that it is much harder to be evil because you know so much less and you are essentially telling everyone the same thing.

MF: So let me take the evil case, take the devil’s advocate case. The disadvantages are that it is hard to incentivize the oracle to sign a lot of statements. You need an exact statement to be signed. If it is raining it needs to be exactly “Yes” or “No”. It can’t be “Yes it was raining” that was signed. You need the exact statement to be signed perfectly. If there is any difference then that signature won’t be a valid signature to feed into the DLC.

NK: This is actually one of the biggest motivations for writing a specification rather than just using this technology. The first month we built out fully functioning DLCs and since then it has been “Ok but everyone needs to be doing the same thing and working together” so this is nice and standardized. In the future this won’t be a problem because we will have standards that everyone can follow for announcing what messages they might sign and then signing exactly those messages. Signing a slightly different message is considered fraud in this world where we have these standards. In the same way that lying is considered fraud. I do think it is true that it is harder to pay an oblivious entity but this is actually a problem Lightning solves. There are a few different ways that one could end up incentivizing oracles. At the end of the day as long as one way works the market will make sure that it does. It does become more feasible once you also realize that there is a lot less overhead required to be a DLC oracle than to be a 2-of-3 signer where you have to be dealing with individuals directly. As opposed to just broadcasting messages. If you look at the DLC code that has been written there is a tonne of client side code and just a couple of files of DLC oracle side code. Essentially all the complexity in DLCs goes to the client, goes to the DLC participants and the oracle does the bare minimum. They are slightly harder to incentivize, I think that is universally true because of the constraints but I think it is still possible and it is cheaper to operate a DLC oracle. I think it works out.

BC: To highlight the complexity of creating the oracle. Nadav and me probably spent a couple of months writing the actual DLC wallet code.

NK: At least a year.

BC: The initial spec. For the initial oracle I did it in a weekend.

MF: These downsides, I think they are all manageable. The other downside I could think of… [Oracle announcements](https://oracle.suredbits.com/), rather than the flow being “Chris I want to enter into a bet on whether it is going to rain where I currently am” and us going through the oracle announcements and going “But there is no oracle that is willing to be part of this contract because the oracle doesn’t know whether it is raining where I live”. That’s the other downside. The flow is you go to the oracle announcements and you see what contract you want to enter into rather than Chris and me saying “Let’s do a contract on some weird bet that there isn’t an oracle announcement on.”

NK: There is certainly a bootstrapping problem when it comes to oracles with DLCs. That is one thing that we are working a lot on in this [site](https://oracle.suredbits.com/). It is not just us posting these things, anyone can come post oracle stuff on this site. You can think of it like a forum, everyone is posting stuff on here that they can attest to. I think this is maybe a slightly more transient problem. In the future you could imagine weather.com, all their data is signed on top of just published. It is not that much more work for them necessarily. If they are doing any kind of oracle stuff, making it so that all of their stuff is signed isn’t a big next step. I hope in the future that finding an oracle isn’t the hardest problem. The hardest problem will be finding a counterparty which has its own struggles though this is also true for the 2-of-3 case. The other thing worth noting is that you can still ask someone to be your oracle even if they know you. Essentially the trust model reduces down to the 2-of-3 in that case. I would say DLCs do just as well as 2-of-3 in that case. They do better in cases where oracles already exist for other things. In the 2-of-3 case you still have to find someone who was willing to sign off on whatever is happening. You can do that and find them, tell them to be a DLC oracle, you are just not really using them like a DLC oracle at that point. Your trust model has reduced down to that of a 2-of-3.

BC: You still have some benefits. You and Chris enter into a bet, I don’t need to know how big your bet is or what your UTXOs are.

NK: It is a slight improvement.

MF: So it is just getting that bootstrap flow right. Perhaps the oracle announcements should all be “respectable”. Or people who everyone knows that are saying what the price is. Rather than a random person like me coming onto your oracle site and saying “It is raining outside my house now” when nobody cares.

NK: One consideration is that on this oracle site, one goal is to actually show someone’s past as well. You can see things they’ve done before and stuff like that. Maybe in the future there will be a more explicit reputation built into things. I think this is one of Lloyd’s motivations in using Twitter. You can bootstrap on Twitter reliability, whatever metrics exist there, they are faulty there as well. If someone has got a blue checkmark maybe it is worth a little bit more. But yeah, essentially I think Lloyd is using Twitter to get around various problems to do with verification and reputation when it comes to oracles.

MF: There is some very cool cryptographic stuff with oracles. You’ve talked about this on other things, we don’t need to go into too much detail, the signing two statements and losing your private key is a really cool trick. You can only sign one of the two statements. That’s the punishment. There is also the possibility to have [multiple oracles](https://suredbits.com/multi-oracle-dlc-deep-dive/). A multisig on statements.

NK: That works today.

MF: That works today in your current implementation of adaptor signatures onchain?

NK: Yes and that is in the [specification](https://github.com/discreetlogcontracts/dlcspecs/blob/master/MultiOracle.md).

MF: That is using what for the multisig?

NK: A lot of math.

MF: Can you use MuSig for that?

NK: We aren’t using direct public key… You don’t want to think of it like a multisignature. We are essentially combining anticipated… What you get from an oracle is their pubkey information and their potential outcomes. From that you can do some math using Tadge’s trick to compute an elliptic curve point. You can think of it like a public key but it is a point on an elliptic curve. That’s the anticipation for a specific event. Traditionally what you do with that is you use it as an encryption key for your signatures, that is what adaptor signatures do. What we are doing for multi oracle is you take not just one oracle’s point for one event but you combine a bunch of different oracles’ points for a bunch of different events in fancy ways. Then you do elliptic curve math on them to create this aggregate point that is associated with an event. It is a bit more complicated. Rather than Alice said “It is raining” you can have a point for the event “Alice says it is raining and Bob says it is raining and Chris says that it is either raining or it is partly cloudy”. You can create these kinds of ANDs and ORs of these points and create new ones and then use those to lock up the actual transactions that pay out to those events. It is quite a bit more complicated. This is one of the biggest things we’ve done that isn’t outlined how to do it in the white paper or even mentioned really what approaches can be taken. We had to develop our own algorithms and approaches. Multi oracle support and numeric contract support more generally uses some clever tricks that I and a couple of others have come up with to essentially enable multi oracle numeric contracts that even allow oracles to not be exactly the same number to the last digit. They can have some variants that you get to specify as the DLC participant for what is acceptable differences between oracles.

MF: This is adaptor signatures, this isn’t multisig with all the signatures going onchain or MuSig where it is key aggregation. This is math that kinds of work out as multisig.

NK: That’s right. The generalization of multisig in computer science is called a monotone access structure if anyone is curious.

MF: That’s one to look up. The oracle stuff is very cool. [Oracle failure cases](https://suredbits.com/dlc-oracle-failure-cases/), we didn’t go into this but obviously if you are only using one oracle and the oracle lies then you’ve got problems. That is where a reputation system comes in or using multiple oracles.

# The impact of possible future soft forks on DLCs

MF: There is tonnes of stuff to do with Schnorr and Taproot. Is there anything for future soft forks that would be cool for DLCs? I saw one [blog post](https://blog.bitmex.com/taproot-you-betcha/) from Jeremy Rubin on betting on Taproot activation. This wasn’t actually using CHECKTEMPLATEVERIFY, I think he was just using his Sapio programming language to do a bet on whether Taproot would activate. I think Ben put up a Taproot activation oracle at one point on Suredbits. 

BC: On our most recent spec call Lloyd actually detailed a way of how to do DLCs not using adaptor signatures or anything, just using covenants. That is another potential way to do it but it is an alternative way, you don’t really get new functionality. There are some improvements with things like SIGHASH_ANYPREVOUT where you can make them more composable.

NK: It will be much easier to put DLCs in eltoo Lightning channels than in penalty Lightning channels. It is not that it will be easier. Today if we found a way to hack together and create a slightly more generalized Lightning channel and put a DLC in it, just between two parties, no routing, having that DLC in your channel would slow down your channel operation. Because every time you want to do something else with that channel like a payment you have to re-sign all of the stuff to do with the DLC. If it is a small contract, only two outcomes or something, it is not a big deal. But if you have a large numeric contract that depends on the Bitcoin price or something inside of your Lightning channel then every single update that you make to your Lightning channel is going to take a couple of seconds, it is not great, even more sometimes. With eltoo this isn’t the case. You can use SIGHASH_ANYPREVOUT to dynamically bind your DLC into your channel so you don’t have to re-sign the DLC every time. The DLC can be a part of all future channels until it is kicked out or settled or whatever. You can think at a very high level, SIGHASH_ANYPREVOUT lets you dynamically rebind transactions so they don’t just spend this output, they can spend any of the future outputs. That is how the Lightning update stuff works. Any transaction can spend any previous commitment transaction in an eltoo channel. Likewise any DLC output, you don’t have to re-sign all the time because you can dynamically rebind it onto future channel states without re-entering into the DLC from scratch. I think that is going to be a big improvement once we have DLCs in Lightning channels, to have SIGHASH_ANYPREVOUT. I think there are other tricks Ben that you know more about for how SIGHASH_ANYPREVOUT can be used to optimize DLCS.

BC: I think you can do more complex things. Say when I get paid to this address from a DLC, instead of it being issued to me I could have an already transaction that signs it from that address to 50 other parties. That way my DLC only needs one key to sign but the payout goes to 50 people. There are other fancy things you can do. In Chris’ [blog post](https://suredbits.com/hashrate-derivatives-with-dlcs-coinbase-put-contracts/) on DLC put contracts that would help as well, you don’t need to constantly renegotiate it.

CS: With the coinbase put contract example the tough part for creating a DLC predicated on the coinbase transaction is the fact that miners tweak the scriptSig and the witness commitment which ends up changing the funding transaction ID for your DLC every time a hash is performed. With ANYPREVOUT you abstract away what the specific funding transaction is, rather you say it just has to match this template. You can bind it to any transaction that follows this template which makes things like what I talk about in this blog post more viable in the market.

# Upcoming releases

MF: At some point in the future we’ll be doing DLCs between all of us in a channel factory. There is a lot of work to do. We’ll wrap up. What would you want people to do? Do you want people to find friends to do DLCs with, to use your software? I saw various videos of tutorials. Do you need oracles? Do you need people entering into DLCs? What do you need?

CS: We definitely need people entering into DLCs. We are about to land a pretty major upgrade to the user experience of the DLC process courtesy of a lot of hard work by Ben and Roman, streamlining the negotiation process of DLCs. It is going to look much more like Lightning channel openings now rather than the very complicated copy, paste message back and forth process that we had previously. It is going to be a much more streamlined experience. We should have that out in the next week or two. That’s when we really want people to get off to the races and really start trying out these things. The demo [video](https://www.youtube.com/watch?v=aoHBCm3_0uA) you have up here is for becoming an oracle which isn’t going to change significantly in the next 3-6 months. That’s something you can do today. You don’t even need to know anything about a chain state data source. You can just start posting oracles on [oracle.suredbits.com](https://oracle.suredbits.com/) and telling your friends to enter into DLCs that are predicated off you being an oracle if they trust you of course.

NK: And if anyone out there is super into Rust I know Thibaut (Le Guilly) who is the maintainer of [rust-dlc](https://github.com/p2pderivatives/rust-dlc), he just needs review on his thousands of lines of his code. That sounds daunting, there is always room for contribution on rust-dlc these days if you know any Rust.

BC: Check out the [spec](https://github.com/discreetlogcontracts/dlcspecs). We have a bunch of small issues, lazy things that we haven’t done yet, adding pretty pictures, correctly linking things around. There is other basic stuff. There is also high level stuff that we’d love review on too. Anything would help.

NK: If something is unreadable post an issue asking questions. Maybe we will get around to fixing it and making it easier to understand. We are adding lots of pictures, stuff like that. It is coming together.

MF: And lobby the eclair guys to support DLCs in eclair soon.

NK: Bother all your Lightning developer friends until they generalize their Lightning channels and put PTLCs into them.

CS: Or until they hate the Suredbits team.

MF: Great work guys, thanks for coming on. I’ll get a transcript up. I look forward to seeing the latest UX that comes out in a week or two.