Skip to main content

3 posts tagged with "DLC"

View All Tags

· 5 min read

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 ItchySats1) 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 fields2. 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.

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

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

· 4 min read

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 1, 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.


  1. Certain implementations of Lightning such as Core Lightning (aka C-Lightning) do support dual-funded channels

· 5 min read

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