[REPOST - for better visibility]

Hi list,

TLDR; LN/DLC split channels but cheaper by using less transactions.

Discussing recently with the 10101 team, it became apparent that the approach to LN/DLC channel currently implemented in rust-dlc suffers from having a too big on-chain footprint when force closing. In the following I summarize the current situation and propose improvements that could help alleviate this issue.

As discussed previously on this list[1], there are mainly two possible ways of implementing LN/DLC channels. The first is to add an extra output to commitment transactions, the second splits the channel in two independent sub channels.

The extra output version simply adds an output to the commitment transaction and attaches the CETs to that output. The upside of this approach is that the number of transactions is low(er). The downside is that it requires double the number of adaptor signatures to be generated since each party holds a different commitment transaction and will thus need a different set of CETs. In addition, adaptor signatures have to be re-generated every time a commitment transaction is updated. But since the discussion here is around reducing on-chain footprint, let’s note that in the worst case, a force close with this approach requires three transactions to be broadcast: the commitment transaction, the spend of the commitment transaction and the CET closing the DLC.

The split transaction attaches a transaction to the funding output, splitting the funds into two: one allocated to the Lightning Channel, the other allocated to a DLC channel. The upside of this approach is that both channels can be updated independently (except for rebalancing the amounts between both). The downside is that it uses more transactions, and is thus more costly to force close. Indeed, going on-chain requires broadcasting six transactions: the split transaction, the glue transaction, the commitment transaction, the spend of the commitment transaction, the buffer transaction and finally the CET.

(To get more details about this approach, have a look at [2]).

At the moment, a “glue” transaction is used between the output of the splittransaction and the commitment transaction in order to circumvent the factthat the Lightning protocol makes use of both the nSequence and nLockTimefields. While the implementation implications are unclear, it istheoretically possible to get rid of this glue transaction by finding adifferent mechanism to number commitment transactions attached to a splittransaction.

The buffer transaction’s main purpose is to prevent, during the renewal of a contract in a DLC channel, one party from being able to choose between closing the previous contract and the new one, while the other party is only able to close the new one because of having revoked the CETs for the previous one. If the party that already revoked the previous contract doesn’t receive the revocation from their counterparty, they can broadcast the buffer transaction and force the closing of the channel on the new contract. However, once both parties have revoked the previous contract, the buffer transaction doesn’t really serve any purpose anymore. Thus one possibility is for both parties to exchange a new set of CETs that directly attach to the split transaction. Note that this means having to generate adaptor signatures two times, similar to the extra output approach, but the channels are kept independent.

We are now down to five transactions in the worst case (when we need to broadcast the buffer transaction), and four in the best case (when we don’t need to). Can we do better? What about closing the channel with a single transaction? Wouldn’t that be ideal? One idea would be for parties to create yet another set of transactions, whose outputs would be the sum of the lightning channel balance and that of the CETs.The parties would then exchange adaptor signatures for these transactions in the same way as they do for the CETs, giving them the possibility to unlock one of them once the attestation for the event of the contract setup in the DLC channel is released. I coined these transaction summary transactions as they summarize the amounts that each party can obtain on force closing the whole channel. These transactions must of course be revocable, and could be revoked together with the commitment transactions. One limitation is that I cannot come up with a way to incorporate HTLCs in the picture at the moment, so these summary transactions could only be used when there is no in-flight HTLC in the channel. Still it feels like this could be a very nice thing to have as it would enable force closing the entire channel with a single transaction (though not in all cases).

The two currently possible approaches to implementing DLC/LN channels both have pros and cons. While I think it would be interesting to have an implementation of the extra output version to be able to compare it properly, I tried to propose some possible improvements to the split transaction version that could hopefully make it more viable even for contracts with lower value, and I would love to hear feedback or criticisms on these!

Cheers,

Thibaut