In the past couple weeks we’ve discussed how to execute Discreet Log Contracts (DLCs) on Lightning and how to transfer Lightning payments using Payment Points and barrier escrows. Today we are going to join these two concepts and discuss how to transfer/sell a DLC position on Lightning. It is recommended that you are familiar with what was discussed in these posts so you may need to brush up on the concepts first.
To transfer or sell a Lightning DLC position you must first be in one. The initial setup will be the same as described in the previous post. We’ll use a similar example here, Alice is betting Bob 10,000 sats that the price of BTC will be over $10k at the end of the week.
First, we will have both parties create invoices for each other to fulfill. To do this setup in a trust-minimized fashion we are going to need a barrier escrow (BE) to make the payments atomic. But before this, Alice and Bob will need to share points between each other. They individually generate a scalar and share the resulting point with the other party. Alice creates point A and Bob creates point B. Then, Alice and Bob will each generate another new point A’ and B’, which they share with each other, and then approach the BE with both A’ and B’. The Barrier Escrow will then respond to both with the same point E1.
After both parties have E1, they will each create their payment points PA and PB by adding their counter-party’s point (A or B) to the sum of E1 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 their personal payment points.
This process guarantees that neither party can spend the resulting payment without first getting the scalar to E1 from the escrow. After both parties have set up and accepted their 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 E1, they will save this for later in case they win the bet to claim their payment. Additionally, the use of the oracle signature points guarantee that no party can claim their payment without a valid oracle signature.
Now, Carol wants to buy Alice’s position in the bet, Alice no longer thinks bitcoin’s price will be over $10k at the end of the week and Carol is offering to buy her position for 5,000 sats. To do so, Carol will need to set up a payment to Alice for 5,000 satoshis, and Bob and Carol will need to construct DLC payments between each other, and all of these payments will need to be atomic, meaning that either all of them happen or none of them happen.
To make all the payments atomic we will again need to use a barrier escrow, that will give everyone E2, and our payments will use a similar design described in our blog about transferring lightning payments. Carol will make a payment of 5,000 sats to Alice contingent on E2 as well as a payment to Bob for 10,000 sats that is also contingent on E2. Carol’s payment to Bob is the one that will be used for the DLC so it should use the same oracle signature point for the setup that Alice had used and can use verifiable encryption to allow for the ORing of points (more on this in our Lightning DLC blog). Bob will also need to make a similar payment to Carol which will be used for the DLC that is contingent on E2. Alice and Bob will need a payment between each other that is the difference between their payments between each other, this will allow them to end with all of their funds back between each other minus some routing fees, this payment will be contingent on E2. Finally, Alice and Bob will need to add a new outcome path to their payments to each other that is verifiably encrypted using E2 so on barrier reveal they can execute their payments immediately to get their funds back instead of waiting for the contract to hit its maturity date. After all the payments have been set up and each party has independently verified that they are correct, they can go to the barrier escrow to initiate the barrier reveal and receive scalar e2. With e2 Alice can execute her payment from Carol, and Alice and Bob are safe to end their previous DLC payments.
Bob and Carol can now continue in their new position just as they would have if this had been a normal Lightning DLC (with no transferring). Whichever party wins, due to an oracle’s signature, is now able to claim their winnings.
Now, whenever we talk about something in Bitcoin we always need to talk about the trade-offs. The main threat in transferring a DLC using this construction is Bob must agree to the transfer and could be subject to fees because of this which may deter his cooperation. However, this can easily be remedied, Carol or Alice can make a payment to Bob that pays him a fee he demands in order to agree to this trade. This payment can also be made along with the rest of the transfer payments so it is still atomic with the others.
In the worst case scenario where Bob will not agree no matter what you offer to pay him, Alice and Carol can simply set up a DLC between them that leaves Alice being net 0 on execution minus some routing fees, the drawback being Alice will have to be double collateralized for a neutral position. However, if Bob is rational he should be looking to collect even a small premium for being compliant in the swap between Alice and Carol as he has nothing to lose. This problem is not specific to Lightning DLCs with barrier escrows but rather is a fundamental downside for any kind of DLC novation due to the self-custodial nature of DLCs.
We now have a more in-depth understanding of DLCs on Lightning and how they can be transferred and even sold between parties. Most of this work is still in the research phase as there are no implementations 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 repo.
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.