This is the third and last part of the series on how to bring DLCs to Lightning. Check out the first two blog posts if you haven't already.

• Part 1: A quick overview of Lightning, Adaptor Signatures and DLCs.
• Part 2: Discusses an approach of expanding the commitment transaction with a custom output.

In part 3, we are going to show you how 10101 is utilizing virtual channels to bring DLCs to Lightning.

DLC Channel​

In order to bring DLCs to Lightning we have to firstly bring them off-chain. (Note, we have done this in the past at ItchySats¹) That is so that we do not have to go on-chain directly after a DLC has been been expired (after the oracle attested to the outcome of an event) or renewed.

A simple approach would be to make the CETs revocable, but that can't be done without putting the side revoking first at a disadvantage. The counterparty could then choose to publish the CETs from the previous or the current contract while they cannot, since they have already revoked them. For that reason we are using a revocable buffer transaction.

The buffer transaction is a simple transaction that takes the funding transaction output as an input and is itself the input of every CET. Now if the counterparty acting second is not revoking the buffer transaction in a timely manner, the party revoking first is able to broadcast the buffer transaction and settle the contract unilaterally.

But how to revoke the buffer transaction?​

We can again make use of adaptor signatures. When a contract is set up, both parties give each other an adaptor signature for the buffer transaction input, encrypted with their counterparty publish (public) key.

If either party wants to broadcast the buffer transaction, they need to decrypt the adaptor signature received from their counterparty using the publish (secret) key. By broadcasting the buffer transaction the publish secret key is revealed, which is fine as long as the buffer transaction hasn't been revoked yet. However, if it has been revoked the counterparty is also in possession of the revocation secret and will be able to get the entire output funds. Note that CETs have a relative timelock, giving the cheated party time to punish the counterparty for broadcasting a revoked buffer transaction.

Embed DLC Channel into a Lightning Channel​

In part 2 we talked about adding a custom output to the commitment transaction. This approach had the significant disadvantage that the CETs would have to be recalculated on every payment received or sent. That resulted in a lot of overhead that we did not want to have for our 10101 solution.

Consequently, we opted to split the Lightning funding transaction into a Lightning channel and a DLC channel. We are achieving that by spending the funding transaction into a split transaction containing two outputs: One for the Lightning channel and one for the DLC channel.

Lightning Channel​

This split transaction is again revocable in the same manner as the buffer transaction described before. Unfortunately, this raises an issue if one party is publishing a revoked split transaction. The cheated party needs to have some time to notice the broadcasted transaction and punish the counter party, but the Lightning commitment transaction already uses both the nLockTime and nSequence fields². To circumvent that issue an additional "glue" transaction is added, spending the Lightning commitment transaction and allowing to add the required timelock.

The following diagram illustrates the complete transaction structure of a DLC-enabled Lightning channel. Note that different publish and revocation keys are used for the split transaction and the buffer transaction.

Closing Thoughts​

With a DLC channel living alongside the Lightning channel we are bringing DLCs to Lightning while still keeping a fully-functional Lightning wallet. However, while the proposed solution is certainly feasible there are still challenges that have to be addressed in future work.

• On-chain footprint: Lightning and DLC channels are secure because either party can go on-chain unilaterally at any point. But the split channel setup involves so many transactions that the associated fee costs are considerable. It can be very expensive to go on-chain without collaboration.

• Splicing: Managing channel capacity dynamically for two channels to the user's demands would really benefit from splicing capabilities. Interestingly our solution is already implicitly supporting a splice out, as we could for instance only close the DLC channel on-chain independently of the Lightning channel. However, a more ergonomic solution is required.

• Anchor Outputs: The current transaction structure does not care for updating transaction fees. As there are multiple timelocks involved a simple CPFP is unfortunately not possible. One way to approach that issue is to add anchor outputs to the split and buffer transaction, but that would again increase the on-chain footprint significantly if the counterparty is not collaborative.

Acknowledgements & References​

Our work is heavily inspired by our colleagues at CryptoGarage who were the first to open and close a DLC on Lighting. See https://medium.com/crypto-garage/dlc-on-lightning-cb5d191f6e64 to read about that in more detail. We are also happy to build upon their work to further improve DLCs on Lightning contributing to the open-source project rust-dlc.

¹ https://comit.network/blog/2022/01/11/cfd-protocol-explained/

² https://github.com/lightning/bolts/blob/master/03-transactions.md#commitment-transaction

In the first part of this series, we provided an overview of Lightning, Adaptor Signatures and DLCs. If you need a refresher, you can find it here.

In part 2, we will now delve into the approach of expanding the commitment transaction with a custom output. This was our first attempt at bringing DLCs to Lightning.

Adding a DLC to a Lightning commitment transaction​

A Lightning commitment transaction, which represents the state of your Lightning channel off-chain, can only contain three kinds of outputs:

• Simple outputs that pay to either party.
• Revocable outputs that pay to either party, after a timelock expires.
• Revocable HTLCs, used to route payments through the network.

This means that we need to extend what the commitment transaction supports in order to introduce a DLC.

This design involves adding a revocable output with arbitrary spend conditions, something that we've called custom output. We offload the responsibility of managing the custom output to the layer above the Lightning node. But the Lightning node is still responsible for revoking the output as the state of the channel progresses.

Other than the arbitrary script, the custom output also differs from standard Lightning outputs in being created with coins from both parties involved in the channel. This is important as DLCs commonly lock up funds from two parties.

Collaborative settlement of a DLC​

When settling a DLC, the Lightning node doesn't need to know the specifics. It just needs to be instructed to collaboratively remove a custom output, splitting its coins in a particular way.

This is analogous to what happens when a HTLC is removed after a payment has been claimed.

Force-closing a channel containing a DLC​

Force-closure must be supported so that you don't have to trust your counterparty in the DLC. You must be able to unilaterally close the channel, committing the DLC to the blockchain in the process.

Once the oracle (or oracles) attests to a particular outcome for the relevant event, one CET becomes spendable and is published, splitting the funds according to the original terms of the contract.

Since the Lightning node does not understand the DLC protocol, it is still the responsibility of the layer above to get the right CET on-chain before the DLC can be refunded

Staying compatible with vanilla Lightning nodes​

When coming up with the design, we knew that our modified Lightning node must still be compatible with all other regular Lightning nodes. One of the main appeals of integrating with Lightning is becoming part of the network, tapping into its fast-growing userbase.

Since we are only making additive changes, it follows that this DLC-compatible Lightning node is still able to send and receive payments with anyone else on the network.

Lessons learned and future work​

After implementing that approach as PoC for the Legends of Lightning tournament, we've learnt a few things which influenced how we approached our next steps with 10101.

Updating a channel that contains an externally-managed custom output is cumbersome​

It is nice to be able to ignore the specifics of DLCs at the Lightning node level, but it makes it quite complex to update the channel state. For instance, every time a new payment is routed, there needs to be a lot of communication between the Lightning node, the layer managing the DLC and the counterparty.

Dual-funded channels​

As mentioned, a DLC is a shared output with funds coming from two parties. As Lightning currently only supports opening unilaterally-funded channels ¹, it is impractical to set up the channel in such a way that creating the desired DLC is possible.

Next​

In the next and last blog post of this series we are going to write about how we are using virtual channels alongside the Lightning channel in 10101 to bring DLCs to Lightning.

The recent mempool situation reminded us all about the scarcity of blocksize. The mempool is full, transaction fees are soaring, which makes small on-chain transaction not viable anymore. This is a problem as we can't scale Bitcoin to billions of users.

At 10101 we are working on extending the Lightning network to support DLCs, allowing Bitcoiners not only to pay and receive payments, but also to trade right from their channels.

In this series of blog posts, we will delve into how 10101 brings DLCs to the Lightning Network. The series will consist of three parts:

• Part 1: A recap on Lightning and DLCs.
• Part 2: Exploring the incorporation of a Custom DLC Output on top of the Lightning commitment transaction.
• Part 3: Discussing the integration of a Virtual DLC channel alongside the Lightning channel.

Teaser: At 10101, we ultimately opted to develop virtual channels as our solution.

A recap on Lightning​

In order to understand the process of setting up a Discreet Log Contract (DLC) within a Lightning channel, it is essential to have a basic understanding of the transaction structure associated with regular Lightning channels. Let us briefly review this structure, focusing solely on the aspects relevant to our discussion and omitting details like routing, liquidity, etc.

When two Lightning nodes establish a channel, they collaboratively construct and sign two types of transactions: the funding transaction and the commitment transactions.

1. Funding Transaction: takes a number of UTXOs from one of the two parties as inputs. These funds are locked within a 2-of-2 output, which necessitates the signatures of both parties to be spent. This output is known as the funding output and serves as a repository for the channel's funds.

2. Commitment transaction: references the funding output as its input and incorporates two outputs, each reflecting the balance held by the respective parties. It is important to note that these balances are subject to change throughout the channel's lifespan, thus requiring the commitment transaction to be updatable to accurately reflect these modifications. To achieve this, the commitment transaction is designed to be revocable. In practical terms, each party maintains a distinct version of the commitment transaction, with the output paying to themselves secured by a script that can be unlocked either by their own signature after a specific period or by their counterpart possessing a secret. When the parties reach an agreement to adjust the channel balance (e.g. one party intends to transfer a certain amount of sats to the other), they generate and exchange signatures for the updated commitment transactions while simultaneously revealing the secrets used in the previous versions. In the event of a party attempting to cheat the other by broadcasting an outdated commitment transaction, the opposing party has a window of time to respond and employ the revealed secret to claim all the channel's funds.

The following diagram illustrates the transaction structure of a lightning channel.

If you want to read up in more detail how Lightning works have a look at this blog post

A recap on Adaptor Signatures​

An adaptor signature is a signature that has been encrypted with a secret, and for which we can prove that after decryption (or with knowledge of the secret) we obtained a valid signature for a given message.

For a DLC we use the oracle's signature as a secret to encrypt the counterparty's signature which unlocks a certain Contract Execution Transaction (CET). These signatures are created as adaptor signatures using the oracle's announcement that it will attest to an event outcome in the future. Using this publically available information both parties generate all possible signature points that could be released by the oracle and use them to encrypt their signatures. Upon exchanging and verifying these adaptor signatures, both parties have collected all data required to eventually broadcast the only valid CET.

If you want to read up in more detail about Adaptor Signatures and how they are used in the context of DLCs have a look at this blog post

A recap on DLCs​

Discreet Log Contracts (DLCs) are a type of smart contract protocol that operates on the Bitcoin blockchain, allowing for the execution and settlement of contracts based on events external to the blockchain.

During the setup of a DLC both parties lock up funds in a DLC output. This output can only be spent with signatures from both parties. At the time of the DLC setup the actual event outcome is not know yet, but the oracle has announced that it will attest to its outcome at a specific point in the future. Both parties generate multiple CETs, each defining how to split up the locked up funds based on a specific potential future event outcome. After agreeing on the CETs, both parties exchange adaptor signatures on each of them. An adaptor signature for any given CET will only be unlocked if the oracle attests to the specific event outcome associated with the corresponding CET.

The key characteristics of a CET are the following:

• Only one CET will become valid after the attestation of one or multiple oracles.
• Neither party can publish a valid CET without having the oracle's attestation.
• Publishing a CET is unilateral after the oracle's attestation.

The most simple example of a DLC is a binary option. The diagram below illustrates the transaction structure of such a DLC. As the potential future event outcomes can only be true or false, only two CETs have to be generated.

Note, in case of a numerical outcome, a CET would have to be created for every possible outcome or a range of outcomes.

Next​

In the next blog post we are going to write about the first approach we tried to bringing DLCs to Lightning using a Custom DLC Output on the commitment transaction.

References​

• https://adiabat.github.io/dlc.pdf
• https://medium.com/crypto-garage/optimizing-numeric-outcome-dlc-creation-6d6091ac0e47#96e9
• https://medium.com/crypto-garage/dlc-on-lightning-cb5d191f6e64
• https://raw.githubusercontent.com/LLFourn/one-time-VES/master/main.pdf
• https://medium.com/softblocks/lightning-network-in-depth-part-1-payment-channels-b943607950dd

In a previous blogpost we talked about self-custodial settlement paths in 10101. In this blogpost we explore how the 10101 app will enable you to stay self-sovereign in your self-custodial trade setup.

Without a certain level of self-sovereignty, your self-custodial setup might not be as protective as you think. If you depend on a single service provider too much, then you might not be able to act in a worst case scenario.

At 10101, we are dedicated to developing a cutting-edge self-custodial synthetic stablecoin powered by Discreet Log Contracts (DLCs).

What sets our stablecoin apart is its complete absence of issuers and the eradication of counterparty risk.

In our previous blogpost we wrote about the motivation for self-custodial trading and when it matters. In this blogpost we explore how the self-custodial setup works and what happens when you click the button to close a position.

When you trade in 10101 there are three phases:

1. Discovery: Finding a trading partner through the 10101 orderbook

2. Execution: Opening the position by setting a P2P smart contract on Bitcoin

3. Settlement: Closing the position by resolving the contract

This is the first in a series of blogposts that explores self-custodial trading with 10101 - why and when self-custody really matters, and how it works.

Bitcoin is objectively the best ledger out there. But, as great as Bitcoin is at solving the problem of self-custodial ownership, when it comes to using your coins you depend on centralized platforms. On an exchange you deposit your funds giving up custody - you rely on the exchange to be honest and return your funds once you want to exit. What if there could be a financial system where nobody can lie of cheat?

With 10101 you never give up custody. The app empowers you to trade self-custodial, eliminating the need for a centralized custodian, and enabling autonomy. You stay in charge at all times: Your keys, your coins.

Midjourney: crypto exchange app, white background, minimalistic, 8k, clean

Hello Awesome People! 🚀​

Drum-roll, please... 🥁 Today marks the beginning of an incredible journey as we proudly commence rolling out the much-awaited 10101 beta to the lucky few from our ever-growing wait list! We truly appreciate your enthusiasm and are grateful for your participation.

As much as we'd love to include everyone at once, we're staggering the access to make sure each one of you enjoys the smoothest experience with no hiccups.

In case you were not contacted as part of the first batch just yet- don't worry! We'll be continually adding more delighted users while we iron out any issues and power up our infrastructure further. So hold tight, your turn is just around the corner! 🎢

Did you miss signing up for our beta program? 😳 Don't fret! Time is still on your side - sign up right away! 🕐

👉 Follow this link to join the party:

Once again, thank you for being part of bringing self-custodial trading to the world - the future is here! Let's enjoy the ride together! 🎉

Team 10101

Thanks for reading 10101 - you can subscribe to our blog on substack to get informed about new posts via email!

Welcome to the world of decentralized trading, where the power of self-sovereign Bitcoin finance is unleashed! At 10101, we are passionate about creating an economy that is free from central authority. Our mission is to empower individuals like you to take control of your own finances and make the most of the incredible opportunities that the crypto world has to offer.

We know that choosing the right platform for decentralized trading can be a challenge, but we are confident that 10101 is the only real solution. Why? Because 10101 will never ask you to hand over control of your funds! In this blog post, we dive into the segmented USPs of 10101. From our brand (in green) to our product (in blue) and our team (in purple), we have everything you need to succeed in the world of crypto trading. Join us on this exciting journey and discover for yourself why 10101 is the ultimate choice for decentralized trading!