In previous posts we have explained what Discreet Log Contracts (DLCs) are and why they are so great, and even gave a demo on a work in progress implementation. Today we are going to look into the future of DLCs and how they can be done on the Lightning Network.
If you are unfamiliar with what the Lightning Network is or would like to learn more about it, I recommend checking out our full Discreet Log Contract blog series.
Before explaining how DLCs can be done on Lightning, I think it is best to start off with asking why put DLCs on Lightning in the first place if we can already do them on-chain?
Lightning provides two main advantages to on-chain transactions: scalability and privacy. These are perfect for DLCs as a DLC will require at least 2 transactions which can be expensive and privacy is part of the security model of DLCs so why not add more? The tradeoff that Lightning takes is that the two parties must both be online to make a payment and capital is locked up between the parties. This trade off comes at almost no cost for DLCs as setting them up as well as mutual closes requires both parties be online and if either party was offline when the contract was being closed they would be diverting to an on-chain transaction anyways and DLCs already require the parties to lock up funds between them. In summary, the Lightning Network is a perfect place to execute DLCs.
Doing DLCs on Lightning Today
A Lightning DLC can be executed today but it has some limitations. First, let’s explain how it works. Let’s say Alice is betting Bob 10,000 sats that the price of BTC will be over $10k at the end of the week and lucky for them, they already have a Lightning channel between them with Alice having a balance of 20,000 sats and Bob having a balance of 30,000 sats. After both parties have agreed to the terms of the contract – which oracle, potential outcomes and their respective payouts – and exchanged a few public keys, they can start constructing the transactions.
- First, they need to create a new commitment transaction where Alice and Bob’s outputs have been reduced by the amount they are putting up for this DLC (in our case 10,000 sats each) and where that value goes into a new output that is identical to a standard funding output of an on-chain DLC – a 2-of-2 multisig with keys from Alice and Bob.
- Second, they need to construct their Contract Execution Transactions (CETs). These are the transactions that Alice or Bob will use if they get a signature from their oracle and claim their winnings when the other party is not cooperating. If you would like a more detailed description of what is in a CET, checkout our post about a DLC’s construction.
After constructing these transactions, they will first sign the CETs and then the new commitment transaction (which has the funding output) so the other party cannot publish them before and hold the other party’s funds hostage. Finally, they can revoke their previous commitment transaction.
At the end of the week, bitcoin’s price is now over $10k and Alice wants to claim her precious sats. If Bob is being cooperative then they can simply create a new commitment transaction that moves 10,000 sats to Alice and their Lightning channel can continue on as if Bob simply paid Alice her winnings. However, if Bob is not being cooperative because he is offline or grumpy that he lost, Alice will still be safe and able to claim her winnings. She can simply close their channel and execute the DLC using her CETs the same way as is done with on-chain DLCs.
This is the basic construction for how to do Lightning DLCs today, but it does come with some drawbacks. You may have noticed that this can only be done between parties that already have a channel between each other. You cannot route a DLC payment on Lightning yet. However, if you do already have a Lightning channel with a party you are doing a DLC with, it will save you fees as well as increase privacy as you may not need to broadcast anything to the chain or even reveal that a DLC happened.
Future of Lightning DLCs
As a preface to this section I want to note the proposal below requires a change to the bitcoin protocol as well as to the Lightning Network. Specifically, the ability to use Schnorr signatures and PTLCs (point time locked contracts). Luckily for us, it is likely that this will be added in the form of BIP 340 and thereafter it is generally agreed upon that PTLCs will be a no-brainer upgrade given that schnorr is added to bitcoin. Another thing to note is this section will have the understanding that you know what payment points and barrier escrows are. If you are not familiar with these concepts or want to brush up on the topics, check out our complete Payment Points series.
To start, let’s use the same scenario as before where Alice is betting Bob that the price of BTC will be over $10k by the end of the week.
The set up is, in a way, similar to what is done for an on-chain DLC, we still need to put up funds and we are still adding an oracle signature to a point to enforce that the winner gets their deserved funds. However, how we do this will all be using scriptless constructions in place of bitcoin transactions.
First, we will have both parties create invoices for the other party to fulfill. To do this in a trust-minimized fashion we are going to need to use a barrier escrow to make all of the payments atomic, so Alice and Bob will:
- Each generates a scalar and shares their points with each other. Alice creates point A and Bob creates point B.
- Each approach the Barrier Escrow with both a new point they generate and a new point they receive from the other party, the Barrier Escrow will then send both E. E will be the same for both parties.
After both parties have E, they will create a payment point P by adding their own point (A or B) to the sum of E and M (where M is the point for the oracle’s signature of the event in which this payment is completed). Now they can create invoices with point P as their payment point. This guarantees that neither party can spend the resulting payment without first getting the scalar to E from the escrow. After both parties have set up and accepted the invoices and the funds have been locked up along the route, Alice and Bob can go to the barrier escrow to get the scalar behind E, they will save this for later if they win the bet to claim their payment.
A week later the results are in and the bitcoin price is over $10k, Alice has won! She can now claim her funds by revealing the scalar for her payment by adding the scalar of A tweaked by the scalar of E, and the oracles signature. This will allow her Lightning invoice to be successfully completed and she will receive her winnings from Bob. Since routed payments have the atomic property (all payments fail or all succeed), making the last hop depend on the oracle makes the rest of the route as well as not needing cooperation from Bob.
This construction will only allow a binary set of outcomes; either Alice wins or Bob wins. If we want to support a larger number of outcomes we can use some tricks to allow this. Specifically we will need to create OR-points similar to how they are described in our exploration of monotone access structures.
We can create multiple payments of smaller denominations that will be combined, depending on the oracle outcome, to make multiple outcomes possible without over-collateralization. For example, let’s say Alice gets 10,000 sats if the price is over $10k (where this event has signature point U) and 12,000 sats if the price is over $12k (where this event has signature point V). Bob can create two payments to Alice, one for 10,000 sats and one for 2,000 sats. The payment for 2,000 sats would be the same as previously constructed (by adding V to Alice’s point and the Barrier Escrow’s point). But the payment for 10,000 sats will need something clever. We will need a construction that allows us to have a point that can be completed if either the signature behind U OR V is revealed. This way, if the scalar to U is learned then the 10,000 sats can be claimed, but if the scalar to V is learned, both the 10,000 sats payment and the 2,000 sats payments can be claimed.
We will need to use verifiable encryption. At a high level, this lets others verify that we have encrypted the scalar to a specific point with a specific public key without decrypting anything. Bob can generate a scalar x with point X and then encrypt the scalar x twice, once with U and once with V to create Enc_U(x) and Enc_V(x). Bob can then send X, Enc_U(x), and Enc_V(x) to Alice, who can verify that x has been correctly encrypted. Bob’s payment to Alice can now be set up using point X as the point for U OR V, because if the oracle signs a message revealing the scalar to V, Alice can use it to decrypt Enc_V(x) to reveal x and if the oracle signs a message revealing the scalar to U, she can use Enc_U(x) to reveal x. Once she knows x, she can claim the funds for the 10,000 sats. And if the oracle published the signature for V, she can claim the other 2,000 sats payment by simply adding v to her scalar and the scalar to E as described in the last section.
We can take this technique of constructing points that can be satisfied if one of any number of oracle signatures is revealed to extend this technique to arbitrary numbers of payments. If we have outcomes O_1, O_2, …, O_n ordered by increasing value, we can always create n lightning payments with values value(O_1), value(O_2) – value(O_1), value(O_3) – value(O_2), …, value(O_n) – value(O_n-1) with respective signature points (S_1 OR … OR S_n), (S_2 OR … OR S_n), …, (S_n-1 OR S_n), S_n where S_i is the point corresponding to the oracle signature of outcome O_i. Furthermore, both parties can set up any arbitrary number of payments in this way so that they can accomplish any contract that can be accomplished with a normal DLC on-chain.
This is a great setup for DLCs because it allows people to execute them in a trust-minimized fashion on the Lightning Network, where the users can preserve their privacy and save tons on fees. However, there are a few pain points that should be noted. Capital will be locked up along the route while the parties are waiting for the contract to mature and to receive the resulting signature from the oracle. This can cause problems as it is expected that routing nodes will not appreciate this. This problem is not just specific to DLCs but many other Lightning constructs that use this (i.e. HODL invoices) so it is a problem that is being worked on actively and there are solutions being discussed.
We now have a more in-depth understanding of DLCs on Lightning and how they could work today and how they can be done in the future. Most of this work is still in the research phase as there are no implementations for either construct working today to the best of our knowledge. However, if you’d like to track the work being done for on-chain DLCs feel free to checkout or contribute to the DLC spec repository.
If you’re interested in learning more, hit us up:
Contact us @Suredbits
Contact Ben @benthecarman or email at [email protected].
To discuss all things Bitcoin and Lightning, feel free to join our Suredbits Slack channel here.
All of our API services, for both Cryptocurrency APIs as well as Sports APIs, are built using Lightning technology and the Lightning Network. All API services are live on Bitcoin’s mainnet. Our fully customizable data service allows customers to stream as much or as little data as they wish and pay using bitcoin.
You can connect to our Lightning node at the url:
038bdb5538a4e415c42f8fb09750729752c1a1800d321f4bb056a9f582569fbf8e@ln.suredbits.com
To learn more about how our Lightning APIs work please visit our API documentation or checkout our Websocket Playground to start exploring fully customized data feeds.
If you are a company or cryptocurrency exchange interested in learning more about how Lightning can help grow your business, contact us at [email protected].