From thibaut at cryptogarage.co.jp Tue Apr 28 09:33:35 2020 From: thibaut at cryptogarage.co.jp (LE GUILLY THIBAUT) Date: Tue, 28 Apr 2020 18:33:35 +0900 Subject: [Lightning-dev] DLC channels and integration in the Lightning Network Message-ID: Hi list, First let me introduce myself as this is my first time posting. My name is Thibaut and I?ve been working at Crypto Garage for some time, mainly focusing on DLC. With my colleagues Ichiro Kuwahara and Takatoshi Nakagawa, we have been researching on how to construct DLC channels, and how such channels could be integrated in the Lightning network. As there are currently quite some discussions around DLC, we thought that it was a good time to share the result of this research. You can find the paper on github ( https://github.com/p2pderivatives/offchain-dlc-paper/blob/master/offchaindlc.pdf ) , and I?ll try to summarize it here (if you?re not familiar with DLC I recommend going for the paper as I?ll assume some knowledge in the following , also it has nice figures and everything so nice to skim through as a support for the description here). We?d be happy to hear feedback from the community on the feasibility of the approach we propose, both theoretically and practically. Motivation ================================== At the moment, once a DLC expires, both parties need to close and open a new one in order to re-enter in a contract. This is wasteful as it requires at the minimum two extra on-chain transactions (one for mutual closing, and a new funding tx). So one would like to have a way to have actual DLC channels, where two parties can keep establishing contracts between themselves as long as the balance in the channel allows it. Creating such channels is less trivial than it may seem at first glance, as one tricky part is to ensure that no party can ever have the possibility of both enforcing the outcome of a previous contract or that of the latest contract (so they could pick the most favorable to them). I?ll refer to this issue as the ?free option? problem hereafter, but it shouldn?t be confused with the free option problem of atomic swaps. In addition, if we are to implement such DLC channels, we would like to avoid having to re-do all the work and instead take advantage of the existing Lightning Network infrastructure. Note that the integration solution we propose is generic and would work to integrate other types of layer 2 protocol in LN. It also permits the existence of multiple concurrent channels, so two parties could have multiple DLC at the same time using a single fund transaction. Note that one of our motivation was also to come up with something that doesn?t require any changes to the Bitcoin transaction structure or SIGHASH or any new cryptographic operation, as it is rather trivial to implement in an eltoo context for example. Related Work ================================== Juraj Bedn?r and Ren? Pickhardt previously proposed Lightning DLC channels [ 1]. Their construction works by adding an output to a LN commitment transaction, from which the regular set of DLC transactions can be attached. Our approach differs in two ways: 1. Our DLC channel construction can be made standalone, meaning they could be deployed outside (or alongside) of the LN 2. The integration with LN that we propose allow for more separation of concerns between the channels, as they can be updated separately without influencing each others (their construction requires re-building all transactions for any update, we only require this for opening/closing and re-balancing). Bedn?r and Pickhardt approach is similar to the one briefly described by Ben Carman of Suredbit in the first section of [2]. He then proposes routed DLC that require PTLC and barrier escrow. While our proposal only works for direct channels (so no routing), it also doesn?t require any intermediary, and only basic ECDSA. As already mentioned, both DLC channels and their integration in LN could be made much more easily in an eltoo world, as eltoo can be used as a generic framework for building off-chain contracts [3]. DLC Channels ================================== I?ll skip the part about the broken naive construction (that has the free option problem), and go directly for the one that actually works. The main trick revolves around adding two types of transaction to the regular DLC construction: 1. The first type of transaction is the update transaction. It?s pretty much the same as an LN commitment transaction, and serves a similar purpose, that is keeping the balance of the channel. It is also revokable , meaning that each party holds a different version. 2. The second type is the buffer transaction, which spends both outputs of the update transactions to produce one output that will be consumed by the Contract Execution Transactions (CETs). The main point of the buffer transaction is to solve the free option problem in the protocol. Using these two new transaction types we can now describe the update protocol (please refer to figure 2 of the paper for some illustration). I skip the establishment protocol here as the update protocol is the crispy part, but the establishment is described in the paper as well. 1. Alice and Bob generate the set of transactions (update, buffer, CETs and refund) for the new contract, with the update transactions having output values equal to the outcome of the previous contract, 2. Alice sends her signatures for Bob?s update transaction, all CETs and the refund transactions, 3. Bob sends his signatures for Alice?s update transaction, all CETs, the refund transactions, as well as the revocation key for his previous update transaction, 4. Alice sends the revocation key for her previous update transaction, as well as the signature for her buffer transaction, 5. Bob sends his signatures for both buffer transactions. 6. Alice sends her signature for Bob?s buffer transaction. An informal analysis of the protocol is provided in the paper (Section 3.2.4 ), but the main point is that it?s always the case that for both parties, either they can enforce the outcome of the previous contract (and so close the channel in case of an uncooperative counter party), either they can force their counter party into the new contract, but there is no point at which a party can pick which one to enforce (the free option problem). In the non-cooperative case, a DLC channel requires 5 on-chain transaction (from opening to close), while in the cooperative case it?s still only two. That means two more transactions in the worst case compared to the on-chain version, but we believe this is offset by the ability to establish consecutive contracts (even with two consecutive contracts, the number of transaction is reduced). Integration to the Lightning Network ================================== Our proposed solution to integrate the DLC channels in LN is quite simple, but to the best of our knowledge has not been proposed before (apologies if that ?s wrong, and happy to be corrected). The idea is to use a ?split? transaction, which spends the output of the fund transaction, and contains a single output for every channel to be created (a basic example would be one LN channel and one DLC channel), which works as the new funding for these channel. In the paper, we made this split transaction revokable so that it?s possible to reallocate funds between the channels, and close/open channels as desired. Writing this I realized it might also be possible to not make it revokable, which would make it less flexible but would remove the drawback of doubling the number of transactions to be created and monitored. The advantage of this construction is that you can support as many sub-channels as you want for a single fund transaction, and have the ability to rebalance between the channels. The disadvantage is that you need to create and keep track of twice as many transactions due to the revocation mechanism in the split transaction (though as just mentioned if you don?t want to rebalance and/or add/remove channels this issue is removed ). Conclusion and Questions ================================== We proposed a way to create DLC channels, and to integrate them in the Lightning Network. Both can be done with existing cryptographic constructs and Bitcoin transactions. We?d be happy to hear what people think of this approach, whether it is worth pursuing considering the recent development of ECDSA adaptor signatures which would enable simpler constructions, and how complex it would be to implement in practice. Regards, Thibaut [1] https://hackmd.io/@lpQxZaCeTG6OJZI3awxQPQ/LN-DLC [2] https://suredbits.com/discreet-log-contracts-on-lightning-network/ [3] https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-September/002136.html -------------- next part -------------- An HTML attachment was scrubbed... URL: