[dlc-dev] Reducing on-chain footprint of LN/DLC channels
Thibaut Le Guilly
thibaut at cryptogarage.co.jp
Fri Sep 29 13:10:53 CEST 2023
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.
# The two approaches
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.
## Extra output
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.
## Split transaction
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]).
# Improvement to the split transaction approach
## Getting rid of the glue transaction
At the moment, a “glue” transaction is used between the output of the split
transaction and the commitment transaction in order to circumvent the fact
that the Lightning protocol makes use of both the nSequence and nLockTime
fields. While the implementation implications are unclear, it is
theoretically possible to get rid of this glue transaction by finding a
different mechanism to number commitment transactions attached to a split
transaction.
## (Almost) getting rid of the buffer transaction
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.
## Going further: the summary transactions
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).
# Conclusion
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
[1]: https://mailmanlists.org/pipermail/dlc-dev/2021-November/000091.html
[2]: https://medium.com/crypto-garage/dlc-on-lightning-cb5d191f6e64
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20230929/80da7183/attachment.htm>
More information about the dlc-dev
mailing list