Re: [Lightning-dev] DLC channels and integration in the Lightning Network
Hi Lloyd, Thanks for taking the time to read! What we were trying to describe in this section is the failure to construct a DLC channel by using only a fund transaction (on-chain), CETs and a refund transaction (same as the on-chain version), but adding revocation secrets to the CETs and the refund transaction. So the signed transactions that Alice holds are the CETs and the refund transaction for the second DLC, but she cannot use them since the CETs require the oracle signature to be published and the refund transaction is timed lock to after the contract maturity. So Alice is stuck in the second DLC, but Bob still has the possibility to close the channel on the previous state (using a CET from the first DLC since he has not revealed the revocation secret). That's why we add the update and buffer transactions in the construction (the buffer transaction is required to prevent the parties from closing the channel with the update transaction before the maturity of the contract). Hope that clarifies a bit. Cheers, Thibaut On Wed, Apr 29, 2020 at 7:24 PM Lloyd Fournier wrote: > Hi Thibaut, > > Thanks for carrying out this research. I have not finished reading the > paper but have a question about what you call the "straw man" proposal > early on: > > "At the end of this protocol, both Alice and Bob have the set of signed > transactions for the second DLC, and the transactions for the previous one > are revoked. However, there is an issue at step 6. After sending her > revocation secret to Bob, Alice cannot anymore enforce the result from the > first contract. However, as Bob has not yet revealed his secret, he still > has the ability to do so, in addition to having the ability to enforce the > second one. If Bob is dishonest, he could thus choose not to reveal his > revocation key, and wait until just before the maturity of the second > contract to execute the one that is most favorable to him (he could also > potentially use the previous refund transaction if the time lock expired)." > > Since Alice has the signed transactions for the new state, if Bob refuses > to revoke the old state why can't she just post the new state on chain > immediately? This limits Bob's "option" and I thought is the optimal > solution whenever this problem occurs. > > Cheers, > > LL > > On Tue, Apr 28, 2020 at 5:43 PM LE GUILLY THIBAUT < > thib...@cryptogarage.co.jp> wrote: > >> 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
Re: [Lightning-dev] DLC channels and integration in the Lightning Network
Hi Thibaut, Thanks for carrying out this research. I have not finished reading the paper but have a question about what you call the "straw man" proposal early on: "At the end of this protocol, both Alice and Bob have the set of signed transactions for the second DLC, and the transactions for the previous one are revoked. However, there is an issue at step 6. After sending her revocation secret to Bob, Alice cannot anymore enforce the result from the first contract. However, as Bob has not yet revealed his secret, he still has the ability to do so, in addition to having the ability to enforce the second one. If Bob is dishonest, he could thus choose not to reveal his revocation key, and wait until just before the maturity of the second contract to execute the one that is most favorable to him (he could also potentially use the previous refund transaction if the time lock expired)." Since Alice has the signed transactions for the new state, if Bob refuses to revoke the old state why can't she just post the new state on chain immediately? This limits Bob's "option" and I thought is the optimal solution whenever this problem occurs. Cheers, LL On Tue, Apr 28, 2020 at 5:43 PM LE GUILLY THIBAUT < thib...@cryptogarage.co.jp> wrote: > 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
