discreet log contracts for lightning payment channels

[renepickhardt]

We created a high level overview of how DLCs can be used to mitigate the free option problem by creating CFDs.

I am not completely sure where you want to go with this repo but maybe our result / text can be one of the specifications of how to do DLCs in lightning:

https://hackmd.io/@lpQxZaCeTG6OJZI3awxQPQ/LN-DLC

[nkohen]

Hi Rene! Thanks for this :)

Could you elaborate a little on how this could be used to mitigate the free option problem? It is my understanding that this name is usually used when discussing the possibility of a multi-asset lightning network, but seeing as this proposal doesn't involve routing is the free option problem still an issue when using rainbow/synthetic assets?

[nkohen]

Also potentially relevant to future steps for LN + DLC integration once we have payment points is that we can route DLCs and compose them with other payment point magic, also contract re-negotiation/selling: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002234.html

[renepickhardt]

It is my understanding that this name is usually used when discussing the possibility of a multi-asset lightning network, but seeing as this proposal doesn't involve routing is the free option problem still an issue when using rainbow/synthetic assets?

Yes free options are a problem with multi assets. as far as I understandit reinbow / synthetic assets could also be one such class of multi assets having a value attached to them. In any case if we have a lightning network where we support channels with various assets it would be nice if we could swap them while routing to increase liquidity and path finding abilities. For that we would have to attach DLCs to lightning network channels.

I am not sure if this answers your question since I realize I am not sure what your question actually is.

[nkohen]

Okay, I think I understand now, I was always under the assumption that when two parties, say Alice and Bob, have a Rainbow channel between them, and Carol wants to route funds to Dave through this channel, she does not need to know that it is a Rainbow channel and she deals only in millisatoshis/lnbtc, and it is up to Alice and Bob to handle this using their agreed to (and hopefully enforced) conversion rates in such a way that lnbtc "enters" and lnbtc "exists" as well.

I see now that in order for this to work, Alice and Bob would have to have some way of mitigating long-held in-flight HTLCs as it could turn out that Bob and Carol are the same person or something like this which would allow Bob/Carol to have a free option.

That said, it is not clear to me how Discreet Log Contracts help in mitigating this problem as this problem is inherently a multi-channel routing problem, so if I am missing something here I'd love a clarification :)

[conduition]

Using DLCs on an existing lightning payment channel might be expensive and fragile at scale - at least, it would be if we implement DLCs+LN in the same way described in Dryja's original paper.

If a channel between two peers is used for normal Lightning Network payments while a DLC funding output is pending on the channel, the commitment transaction's TXID will change. This would invalidate the existing set of Adaptor-Signed CETs which spent from that commitment transaction.

Renegotiation

The channel peers must exchange a whole new set of CETs and Adaptor Signatures for every possible Oracle outcome over every DLC output in the channel, before signing a new commitment transaction for that channel. If this complex process cannot be completed, the commitment transaction cannot be signed and the payment will fail. Peers would need to do this twice for every payment: once to produce the commitment transaction with the LN payment's HTLC output, and another to produce the commitment transaction which unwinds the resolved HTLC payment into the channel balance outputs.

To "renegotiate" a DLC with $n$ possible outcomes, each party must construct $n$ CETs, compute $n$ Adaptor Signatures, and verify $n$ Adaptor Signatures, plus the refund transaction and its signatures. If a channel routes $p$ payments per second, this means both channel peers must construct, verify, and exchange $2p(n+1)$ transactions and signatures per second in addition to the existing overhead required for Lightning Network channel state updates. This complexity scales linearly for each pre-existing DLC output in the commitment transaction.

If a Lightning Network channel's commitment transactions are co-populated with a large number of DLC funding outputs, payments over that channel become slower and more expensive, both computationally and financially, because node operator could adjust their per-channel fee rates to match their computational expenditures. It's not unreasonable to foresee that if DLCs become popular tools on LN channels, a single channel might have dozens or hundreds of small DLC outputs locking up funds at any given time. Unlike payment HTLC outputs, a DLC output needs to stick around in the commitment TX output set until the oracle attests to an outcome, which could take weeks or months. Each DLC output might have hundreds or even thousands of CETs which would need to be re-signed twice for every payment through the channel.

I'm not sure at what point this "DLC-renegotiation" process would become unsustainable, but it does seem like a worthwhile consideration in choosing how we implement DLCs on Lightning.

---

How to resolve this? One naive way we could get binary outcomes to work would be if the commitment transaction pays out to a multisignature address which is a 1-of-2 multisig. The spending condition would basically be:

(alice && outcome_1_key) || (bob && outcome_2_key)

But this would be woefully disappointing. We've lost the opportunities of payout curves - now the contract is just an all-or-nothing wager with no chance for refund if the oracle goes bye-bye. And we haven't saved much computation by doing this - A contract like this as a normal DLC would only require 2 CETs to be renegotiated anyway.

I can't immediately think of any way (even a naive way) to avoid renegotiating while keeping all the nice properties of full-scale DLCs. If the commitment TXID changes unpredictably, there's no way to maintain the validity of child transactions which spend from it, which means the thousands of off-chain pre-signed CETs cannot remain valid.

[bonomat]

Hi @conduition ,

great to see that you are picking up this topic. We went down this path some time ago and built a PoC which adds the DLC directly to the commit transaction.

After talking to @Tibo-lg we came to the conclusion that this is not economically feasible if you run a routing node at the same time or if you have several DLCs created in a short period of time. Simplifying the DLC (e.g. using binary options) would definitely help but this takes away the fun... right? :D

@Tibo-lg came up with a great solution where he adds a split transaction into the mix which splits the original lightning channel into a lightning channel and a DLC channel. Both can then be updated independently.

He wrote a great article about this here: https://medium.com/crypto-garage/dlc-on-lightning-cb5d191f6e64 We wrote about our approach here: https://10101.substack.com/p/noncustodial-trading-with-10101

Eventually we went with Tibo's approach and are currently implementing it in https://github.com/get10101/10101/. Our launch is imminent :D

[conduition]

Thanks @bonomat, I appreciate the extra links. Splitting the channel is a very clever idea, not without drawbacks of course but for the purposes of reusing an existing lightning channel it meets the basic requirements.

I've been thinking about a way to enable off-chain routed DLCs which sounds similar to what 10101 is doing. The blog post from Thibaut describes the protocol for two parties to split a LN channel, which was very helpful. Your own substack post doesn't go into detail on how 10101 routes DLCs between peers. Is there anywhere I can read more about 10101's architecture? Where would i look to discuss a subject like this?

[Tibo-lg]

I've been thinking about a way to enable off-chain routed DLCs

AFAIK there is no really good way to enable routed DLCs, the only proposal I'm aware of is this one which requires PTLCs, is IMHO quite restrictive and requires a barrier escrow. If you have a better proposal I'd love to hear it!

[conduition]

@Tibo-lg Thanks for that! I'll take a closer look at that post soon as it has lots of tasty details i'd like to digest.

In the meantime I discovered the dlc-dev mailing list and sent out a summary of my high-level concept there. Although in this email i was omitting the concrete mechanics of setting up the routed DLC as I haven't yet formalized the steps. In theory it should be doable by working from the outside inward. Will post more once i have some time