[dlc-dev] DLC over Lightning
Thibaut Le Guilly
thibaut at cryptogarage.co.jp
Fri Nov 5 03:04:17 CET 2021
Hi all,
I’ve been researching about integrating DLC with LN channels lately, and
Antoine had the good idea to suggest having a discussion on this mailing
list to gather ideas and opinions. In this post I will try to summarize
what I think are the current possibilities, what each of them require, and
what are their pros and cons. Please correct any mistakes I might have made
or suggest things I might have omitted. But first, some motivations (skip
this section if you’re in a hurry!).
Motivations
=========
Why would we want to do DLCs off-chain when they work really well on-chain?
Of course the first answer is that doing so removes some interactions with
the blockchain and can thus be more cost efficient (under certain
conditions). A second one is that it also enables early closing of DLCs
more easily, securely and efficiently than what can be done on-chain. A
third one is that it might eventually make it possible to have routed DLCs
(more on that later).
Let’s also note that doing single channel DLCs off-chain is not in itself
particularly challenging (at least in theory). You use commitment
transactions on top of the funding transaction which tracks each party’s
balance and are used as inputs to CETs, and at contract expiry (or earlier
if both parties agree) you update the commitment transactions based on the
event outcome and revoke the previous ones.
Then why do we want to integrate with LN? First because we don’t want to
re-invent (and mostly re-implement) the wheel, and LN already has a lot of
the tools required for off-chain DLCs. But also because being able to use
your LN channel to do DLCs is pretty convenient rather than having to open
separate ones.
Now onto the different possibilities that we have to integrate off-chain
DLCs with Lightning. We'll first look at how we can achieve single channel
DLCs, and then routed one.
Single channel DLCs
=================
=================
Extra commitment output
====================
A simple way to add DLC capabilities to an LN channel is to simply add
extra outputs to the commitment transaction that can be used as inputs to
DLCs.
Pros:
* Little change required at the LN protocol level
Cons:
* every time the commitment transaction is updated, the adaptor signatures
of the contract(s) will need to be re-computed. While this might be fine
for simple binary contracts, it quickly becomes an issue for e.g. numerical
DLCs where adaptor signature computation can take several seconds and is
computationally intensive.
ANYPREVOUT
============
In a world where we have ANYPREVOUT available, we could use it to bind the
CETs to the commitment transactions without having to re-compute the
adaptor sigs when the commitment txs are updated.
Pros:
* Solves the adaptor recomputation issue
Cons:
* We don't have ANYPREVOUT and don't know when we will have it.
Sub-channels
===========
Another solution to the adaptor sigs recomputation issue is to have a
transaction before the LN commitment tx that provides an output for it, but
also for the DLCs. That way each sub-channel can update independently
without affecting others. I've written a draft specification for this
proposal [1], comments and feedback are welcome.
Pros:
* Solves the adaptor sigs recomputation without requiring anything new at
the Bitcoin layer
Cons:
* Requires changes to the LN state machine
* Unilateral close is more costly and takes more time
Routed DLCs
===========
===========
PTLC
====
This solution is described on Suredbits blog [3]. Essentially the idea is
to have each party initiate a payment to the other that is contingent on
knowledge of an oracle signature as well as a secret obtained from a
barrier escrow (required to make contract establishment atomic).
Pros:
* Enables routed DLCs
* Doesn't require adaptor signature recomputation
Cons:
* Requires a barrier escrow
* Requires fancy construction to make complex contracts
* Requires PTLC (not that big of a cons assuming LN will adopt them soonish)
* Requires locking collateral of all intermediary nodes for the DLC period.
Virtual channels (Donner)
====================
Credit to Lloyd for mentioning this during the last DLC meeting. Two
parties could create a virtual channel (in particular as desribed in [4])
and use it as a funding for a DLC. As the channel is unilaterally funded,
establishing a DLC would require a virtual channel in each direction and
some synchronization to ensure the DLC is atomically set up across both
channels. Adaptor signatures could be used to ensure this (I won't go into
details here, but again credit to Lloyd for coming up with this solution).
Pros:
* Enables Routed DLCs
* Doesn't require adaptor signature recomputation (assuming the virtual
channels are used only for a single DLC)
* Doesn't require anything new at the Bitcoin level
* "Easier" support for complex DLC
Cons:
* Would probably require starting implementation almost from scratch AFAIU
* Requires intermediary nodes to support Donner channels
* Requires locking collateral of all intermediary nodes for the DLC period.
Though intermediary nodes would be able to charge fees based on the virtual
channel lifetime and capacity so it's maybe not all that bad.
Conclusion
==========
==========
What I draw from this little summary is that achieving routed DLCs will
require a lot of implementation work.
Among the solutions for single channel DLC, while the ideal would be to
have ANYPREVOUT, the sub-channel approach seems a pretty good compromise to
have full featured DLC on Lightning. That being said, I think that there is
quite some work in common between the sub-channel and extra commitment
output approaches (implementing revocable DLCs), and if it turns out much
easier to implement the latter, it might be worth starting with it as a
first step.
Once again, I'd be happy to get peoples' thoughts and ideas on these! Also
if anybody is interested in participating in the development effort please
reach out.
Thibaut
[1] https://github.com/Tibo-lg/lightning-rfc/pull/1/files
[2]
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003278.html
[3] https://suredbits.com/discreet-log-contracts-on-lightning-network/
[4] https://eprint.iacr.org/2021/855.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailmanlists.org/pipermail/dlc-dev/attachments/20211105/6c511f45/attachment.htm>
More information about the dlc-dev
mailing list