Lightning Discreet Log Contract Channels
===
Juraj Bednár [e-mail]
René Pickhardt [e-mail]

:warning: Work in Progress :warning:

Last update June 20th, 2019

# Introduction and motivation
The goal of this paper is to find a good way to implement discreet log contracts for safe contract for difference on top of Lightning network. Onchain discreet log contracts provide a possibility to create CFDs, but the fees that would need to be paid for each update (renewal) are not trivial (DLCs would involve several transactions in case of renewal).

If two parties are entering a long-term periodically settled contract for difference, it means they would like to collaborate long-term and settle regularly. A solution for avoiding extra fees and for settlement payments that comes to mind is the Lightning network. We got inspired by the Rainbow Network paper[^first]. A more frequent settlement interval lowers the capital requirements and risk of stolen funds. Discreet log contracts eliminate this risk completely, but since they are onchain, they are expensive. Thus we propose a solution which combines frequent cheap settlement of Lightning/Rainbow network CFDs with the eventual settlement finality of DLCs in case the other party does not cooperate. Combining discreet log contracts with payment channels on the Lightning Network seems also to be a promising solution to the free option problem of cross chain atomic swaps with HTLCs[^second] on the Lightning Network.
[^first]:https://rainbownet.work.
[^second]:https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001752.html

# How to create a Lightning+DLC (LDLC) channel

## Funding transaction

We create Lightning DLC channel like any other lightning channel. The first transaction is the funding transaction and is a simple 2-of-2 multisig. Please note that most funding transactions currently have only one funder (either Alice or Bob), although dual funded channels should become part of the protocol with BOLT 1.1 specification.

## Commitment transaction
This is how standard commitment transaction looks like (Alice’s version):

Our flow with the commitment transaction is as follows - first outputs are the same. There might be more or fewer of them, depending on how many HTLC transactions are currently in transit.

We will just add one or more DLC funding outputs to the regular commitment transaction. This is a multisig DLC funding transaction with a possibility to penalize the second party if they publish an outdated commitment transaction.

From there we will attach normal DLC construction:

Normal flow is - the DLC is settled in lightning and the DLC flow (DLC output) either disappears or is updated with the current price and renewed (either for the same or next period).

If the counterparty disappears and the time of commitment passed (DLC Oracle revealed the price) the surviving party (Alice) publishes their last version of the commitment transaction to force close the channel. Then the DLC is funded (by the last output of force-close transaction). After a timelock and with the DLC Oracle’s signature, Alice can claim their settlement out of commited DLC, Bob gets paid as well.

## Detailed flow
### Opening
Alice and Bob want to open a LDLC channel.

First someone of them (let’s say Alice) opens a standard Lightning channel to the counterparty (they create a funding transaction and fund it). They have their first standard commitment transaction.

Here, we assume that we are starting by somewhat rebalanced channel, but if not, Alice can rebalance her channel through Bob (alternatives: Submarine swap, Bob opens a channel to Alice as well, rebalancing through Debnk - all should be supported at some point).

### Commitment construction
Bob wants to hold 1000 USD in his wallet (in BTC). Alice and Bob agree to settle on Friday noon. There’s an Oracle O publishing BTC/USD price on Friday noon. Oracle has a permanent public key X and a commitment R to some random nonce r that will be used to sign the Friday noon price.

Alice and Bob agree and first create a Lightning Commitment transaction with added DLC funding output. This DLC funding output has the same margin for price distribution (let’s say 20% of 1000USD in BTC) - so both Alice and Bob’s to_local and to_remote are deducted by the same amount which goes to DLC. They do not sign the transaction yet, first they will remember the TXID.

Then Alice and Bob create a DLC funding transaction out of the last output (using the last TXID and the number of the output). They do not sign it yet either.

Then Alice and Bob create their versions of price distribution transactions (knowing the TXID of the DLC funding transaction). There will be one transaction for every possible price of BTC/USD. They exchange them and the other party signs. Then each party signs their own created transactions.

Now both Alice and Bob have signed and stored price-commitment transactions for each price.

They can be sure that their funds will be safe and they sign DLC funding transaction.

Finally they sign the lightning commitment transaction.

### Continuous settlement
Let’s say it’s Wednesday and both parties would like to update the current state. They agree on price (TLSnotary/mutual agreement/…).

They distribute funds using the current price. Let’s say the price of BTC went up and Bob has to send Alice some BTC in order to stay in the 1000 USD position. The newly created Lightning commitment transaction accounts for this by substracting some of to_remote and adding it to to_local in Alice’s commitment transaction (and the mirror reverse on Bob’s side).

Now lightning channel reflects the current state of price on Wednesday. They both have agreed on the new settlement, so the DLC part has to be constructed again - the current price is neutral in the DLC contract, so the split of the collateral (margin) changes. As all transactions are recreated and finally new commitment transaction is signed, the state is updated.

Please note, that this does not have to be done often, only if both sides want to reflect the current price and make sure their capital is not locked for long. They also do not have to do this at all during the duration of the contract, but this construction would be used later.
### Renewal

It’s Friday morning and Alice and Bob decide to renew the contract until the next Friday noon. They first do “continuous settlement” as described above, but they commit to a new R published by the Oracle for the next friday noon settlement. Nothing else changes, the margin is still committed, although to_local and to_remote changed based on the current price.

Nothing is written on-chain.

### Friendly non-renewal

A friendly non-renewal is when one of the sides decides they do not want to continue with the contract. It’s Friday noon, both parties agreed to end the contract. They settled on lightning and the commitment transaction removed the DLC funding output. The channel is now a normal lightning channel without any DLC.
Again, nothing is written on-chain.

### Bob disappears (non-friendly non-renewal)

It’s Friday noon and Bob is not answering Alice’s continuous settlement requests. Alice broadcasts the last commitment transaction. After timelock, she broadcasts the DLC funding transaction and DLC contract settlement transaction for the published price. She then claims her output.

Also, the lightning channel at this point is automatically force-closed.

# Using channel factories to decouple channel state and discreet log contract commitment
The main problem with the construction above is the need to recreate all the transactions for DLC for every channel state update (creation of new commitment transaction). After introducing a soft fork for SIGHASH_NOINPUT eltoo channels which allow multiparty channels and large channels factories become possible and convenient solution. This is even improved by aggregating signatures as soon as Schnorr Signatures are being activated. First of all, it would allow easier construction of channels among multiple parties.

Channel factory is a multisig transaction that creates channels. The channel factories do not have to be between two parties and this allows for easier switching between peers with which we have DLC. Even with a two-party channel factory, we are able to move the DLC funding transaction out of channel state commitment transaction.

Please note, that any intermediary settlement also needs to recalculate the DLC state, because the “base price” will change.


Advantages over previous construction:
* Less computing work involved when using the channel as a normal Lightning channel
* If a multiparty channel factory is used, DLCs can be easily added or removed among many parties.

Disadvantages:
* In order for this construction to work, channel factories should be implemented by some Lightning node implementation and SIGHASH_NOINPUT soft fork has to be activated on Bitcoin network.

Note in case of a regular channel it is possible to extend BOLT 2 (The peer Protocol) to allow sharing of a channel into a regular lightning channel and a DLC. This behavior of a very small and specialized channel factory would be possible without BIP 118[^third] but just with some extension of the lightning network protocol. While there is some communication overhead to set up the DLC and maintain the split channel we believe this is currently the best approach as the extension of the current peer protocol could have in mind that it will be forward compatible with future channel factories as soon as we get eltoo channels.

[^third]: https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki