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 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 > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
