Combine DLCs and Lightning Channels

[holzeis]

Goal

We want to build a wallet which speaks lightning and is able to do DLCs.

Possible approaches

Virtual channels

Probably the most complex solution is to have 2 virtual channels. One speaking lightning, the other one speaking DLCs.
E.g. something like this:

Diagram

flowchart LR
    A1((Alice))
    B1((Bob))
   

    txf[tx_fund]
    
    txc_outer[tx_commit]
    
    txs[tx_settle]
    
    txcis[tx_commit_itchysats]
    txcln[tx_commit_ln]
    or{or}
    and{and}


    A1 -- fund --> txf
    B1 -- fund --> txf
    txf --> or
    or --> txs
    or --> txc_outer
    txc_outer --> and
    and --> txcis
    and --> txcln
    
    subgraph ItchySats
      txcet_is[tx_cetN]
      txr_is[tx_refund]
      txp_is[tx_punish]
      or_is{or}
      
      txcis --> or_is
      or_is --> txp_is
      or_is --> txcet_is
      or_is --> txr_is
    end
    
    
    subgraph LN
      htlc1((htlc1))
      htlc2((htlc2))
      htlcN((htlcN))
      txp_ln[tx_punish]

      txcln --> txp_ln
      txcln --> htlc1
      txcln --> htlc2
      txcln --> htlcN

    end

Loading

Advantages:

• we might be able to use ldk, this needs to be evaluated.
• we might be able to use maia.
• we should be able to receive standard LN payments from anyone in LN.

Disadvantage:

• clearly complex
• channels can only be opened to nodes running the same code because of the custom transaction structure. i.e. you can't open a channel to other LN nodes (LND or CLightning) with this.

Maia speak LN

We could implement the needed bolts into https://github.com/comit-network/maia/

Advantage:

• full control over the code base. We can decide to only implement what we really need
• we should be able to receive standard LN payments from anyone in LN.

Disadvantage:

• complexity
• only compatible with our own nodes, i.e. you can't open channels to other LN nodes (LND, Clightning) with this.

LN speak DLC

We could add the DLC feature to a lightning implementation (e.g. use LDK and extend it). The it's ok to be odd would allow us to add features to our client without breaking compatibility with other LN implementations.

Advantage:

• we can open a channel with other LN nodes
• we speak native lightning out of the box

Disadvantage:

• Complexity
• If we build on LDK we probably will need to fork the library to add what we need which could become a nightmare in pulling in upstream changes.

[holzeis]

blocked by #10

[bonomat]

I propose to not go for this approach.
It would be better to either make https://github.com/comit-network/maia/ speak lightning or go for a virtual channel solution.

[bonomat]

I propose to not go for this approach.

It would be better to either make https://github.com/comit-network/maia/ speak lightning or go for a virtual channel solution.

Note: if we do this, we won't be able to open channels to other Lightning Nodes. If we want to support this, we will need to speak native lightning and add DLCs to a normal lightning channel.

[bonomat]

@luckysori : what do you think of going for option 3: make LN speak DLCs. There was an attempt in the past which never made it into the library. The PR is completely outdated but it doesn't look to complex. We could then build a LN wallet from LDK with this additional feature.

[luckysori]

what do you think of going for option 3: make LN speak DLCs. There was an attempt in the past which never made it into the library. The PR is completely outdated but it doesn't look to complex. We could then build a LN wallet from LDK with this additional feature.

My intuition tells me that option 3 is the hardest because we would have to integrate it into an existing codebase which we (I) don't understand. Potentially it is also the one that would reap the most benefits.

I think I have a rough idea of how each option would be implemented, but I do not fully understand how they compare in terms of functionality. Could you expand that information in the original post?

As an example of my confusion: I seem to remember that option 1 included making the fund transaction "look like" a Lightning funding transaction. But then the disadvantages talk about incompatibility with pre-existing Lightning nodes. What would be the point of that solution then if we cannot use it with other Lightning nodes in any way?

[bonomat]

@luckysori : I've added a few more words to the initial description.

My intuition tells me that option 3 is the hardest because we would have to integrate it into an existing codebase which we (I) don't understand. Potentially it is also the one that would reap the most benefits.

I think we should give it a try. I had a look at their source code and it looks a bit scary to be honest 😬 The thing I'm most afraid of is keeping our fork up2date. I think this is though the best solution longterm.

As an example of my confusion: I seem to remember that option 1 included making the fund transaction "look like" a Lightning funding transaction. But then the disadvantages talk about incompatibility with pre-existing Lightning nodes. What would be the point of that solution then if we cannot use it with other Lightning nodes in any way?

I've updated the description: we are able to receive payments from any LN node but we can only open channels to nodes with our implementation because of the custom transaction structure.

[luckysori]

The thing I'm most afraid of is keeping our fork up2date. I think this is though the best solution longterm.

Perhaps we shouldn't try to build something that we will need to maintain longterm. Maybe it's sufficient if we treat the protocol as a PoC, aiming to replace it with a more sustainable integration down the line.

---

@bonomat: I understand that for DLCs on Lightning to work we also need to implement dual-funded channels. Would it make sense to start with that? This is not yet implemented in rust-lightning, primarily because the BOLT hasn't merged yet.

[luckysori]

Meeting minutes of the discussion about Lightning DLC protocol

Attendants: @bonomat and @luckysori.

1. Choosing a protocol

Decision

We have settled on Option 3 aka LN speak DLC.

Reasoning

It is the only protocol out of the 3 outlined which would allow other Lightning Nodes not written by us to connect to our nodes and do all regular Lightning things. We thought it was insufficient to just be able to receive Lightning payments.

This approach is also the one that best aligns with our vision: extending the Lightning Network to support DLCs. We are not alone in this vision, as this is a topic that is frequently discussed among people involved in dlcspecs.

2. Approach

Extending the Rust LDK

We intend to extend the Rust LDK library to support DLC protocols including:

• Adding a DLC output.
• Collaboratively settling a DLC output.
• Non-collaboratively settling a DLC output.

In the context of CFD trading, we purposefully leave out the rollover protocol for the time being because:

• It would increase the scope of this work too much.
• It is unclear where and how the rollover protocol should be implemented (it's not really a DLC protocol, but rather a CFD protocol).
• We can build a useful, illustrative product without it ("non-perpetual" CFDs).

It is important to highlight that we do not expect to write code that will be maintainable. We intend to fork the repository and relatively quickly extend the codebase to support DLCs. We think this is acceptable because we understand that it would be okay to rewrite most of the code that we produce for the Legend of Lightning tournament.

The Rust LDK is a complex project and it is challenging to upstream new features. There have been previous efforts to add DLC support to it and very likely in the medium term we could help with that (after the Legends of Lightning tournament).

Rough plan

1. Spend 2 iterations (weeks) hacking on our fork of the Rust LDK to add the DLC protocols mentioned above. Prove that it works in a Rust test.

• As a very first sub-step, we are gonna work on adding a protocol which just adds an arbitrary output (not a HTLC or a DLC).

2. Write a blog post for Legends of Lightning about our intermediate work.
3. If we are successful with step 1, we would now be ready to build our own Lightning Node using our own extensions.

A note on dependencies

We think we need to be careful with using external dependencies because:

• We worry that they could make it hard to build our Rust code for other platforms (a key focus of this project).
• The Rust LDK rejects PRs that add new dependencies. Obviously this is only important beyond the Legends of Lightning tournament, as we don't intend to upstream anything yet.

[luckysori]

I've generated a couple of transaction diagrams to illustrate what we are building:

Add a DLC to a Lightning channel

Collaboratively settle a Lightning DLC into the channel

Notes

No need to draw anything for non-collaborative settlement, because it just entails unilaterally publishing the transactions displayed in the first diagram, closing the overall Lightning channel in the process.

[luckysori]

Punishing the publication of revoked commitment transactions

We are familiar with this concept because we had to deal with a similar problem in itchysats. The difference lies in the fact that itchysats employed Generalized Bitcoin-Compatible Channels to create perpetual CFDs, whereas Lightning uses Lightning (duh) channels to create payment channels.

Since our approach is to effectively add new features to a full-fledged Lightning node, it appears to be necessary to conform to the ways in which Lightning deals with revoked state. In Lightning, when the state of the channel is updated the two parties also exchange revocation secret keys. The corresponding revocation public keys enable punish spend paths on particular outputs on the transaction ("all outputs that return funds to the owner of the commitment transaction"). For example, in the following diagram taken from the previous comment

the output that pays to Bob is called RSMC B, because it uses a Revocable Sequence Maturity Contract. This contract allows Bob to spend it after a timeout, if Alice doesn't use the revocation path first to punish Bob.

Similarly, HTLC outputs that pay to the owner of the commit transaction are also protected by a revocation key, although this is done in a "second-stage HTLC transaction".

This is all to say that our newly introduced DLC output will also need to be spendable by the counterparty of the owner of the commit transaction, if they provide the necessary revocation secret key. This just means we will have to design the DLC script to include that path. This is similar to what we already do in itchysats, but the format is different.

The nice thing is that, once we introduce the new CFD rollover protocol, we will already be covered for punisment since a rollover will just be replacing the DLC output on the commitment transaction with a new one, revoking the previous commitment transaction by sharing the revocation key (like any other Lightning channel update).

A note on terminology

Lightning calls punishment transactions penalty transactions. We should adopt this terminology when working with Lightning.